Рассмотрим на практике что стоит за кнопкой “Live Migrate Instance” веб-интерфейса и как работает живая миграция виртуальных машин в OpenStack. Сразу оговоримся что для инициации вам понадобятся привилегии администратора облака, поскольку для пользователя информация об облаке скрыта, в том числе и о конкретных гипервизорах на которых запускаются виртуальные машины. Различные балансировки нагрузки и миграции в OpenStack — вне области ответственности пользователя.

Сервис OpenStack Nova поддерживает живую миграцию виртуальных машин в двух вариантах:

  • С общей системой хранения данных. Виртуальная машина перемещается между двумя вычислительными узлами с общим хранилищем к которым оба узла имеют доступ. В качестве общего хранилища может выступать например NFS или Ceph. Сюда же можно отнести вариант когда не используются временные диски (ephemeral disk), а в качестве единственной системы хранения при создании виртуальных машин используется Cinder.
  • Без общей системы хранения данных. Более простой в настройке вариант который мы рассмотрим далее. В этом случае на миграцию требуется больше времени, поскольку виртуальная машина копируется целиком с узла на узел по сети.

Для выполнения упражнения вам понадобятся два работающих гипервизора. Начните с проверки IP-связанности между вычислительными узлами:

[root@compute ~]# ping compute-opt
PING compute-opt.test.local (192.168.122.215) 56(84) bytes of data.
64 bytes from compute-opt.test.local (192.168.122.215): icmp_seq=1 ttl=64 time=0.302 ms
64 bytes from compute-opt.test.local (192.168.122.215): icmp_seq=2 ttl=64 time=0.363 ms
^C

Теперь запустим виртуальную машину и  определим на котором из узлов она работает.

$ nova hypervisor-servers compute.test.local
+----+------+---------------+---------------------+
| ID | Name | Hypervisor ID | Hypervisor Hostname |
+----+------+---------------+---------------------+
+----+------+---------------+---------------------+
$ nova hypervisor-servers compute-opt.test.local
+------------------+-------------------+---------------+------------------------+
| ID               | Name              | Hypervisor ID | Hypervisor Hostname    |
+------------------+-------------------+---------------+------------------------+
| 9e319540-9a67-.. | instance-000000df | 2             | compute-opt.test.local |
+------------------+-------------------+---------------+------------------------+

Мы видим что виртуальная машина работает на узле compute-opt. Дальше определим какой flavor использовался для этой виртуальной машины:

$ nova show 9e319540-9a67-4563-9aad-132c64faa1b1 | grep flavor
| flavor | m2.tiny (98cb36fb-3541-415b-9835-bfc7e73546e3) |

и достаточно ли ресурсов на узле, куда мы хотим мигрировать виртуальную машину:

$ nova host-describe compute.test.local
+--------------------+------------+-----+-----------+---------+
| HOST               | PROJECT    | cpu | memory_mb | disk_gb |
+--------------------+------------+-----+-----------+---------+
| compute.test.local | (total)    | 4   | 3952      | 49      |
| compute.test.local | (used_now) | 0   | 512       | 0       |
| compute.test.local | (used_max) | 0   | 0         | 0       |
+--------------------+------------+-----+-----------+---------+

Как мы видим ресурсов достаточно. Однако прежде чем отдавать команду на миграцию необходимо разрешить демону libvirtd слушать входящие подключения по сети. На обоих гипервизорах добавим опицю:

LIBVIRTD_ARGS="--listen"

в файл /etc/sysconfig/libvirtd, отвечающую за строку запуска демона. Следующим шагом в конфигурационном файле /etc/libvirt/libvirtd.conf разрешим подключение без аутентификации и шифрования:

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

Альтернативой могло бы быть использование сертификатов или Kerberos. Рестартуем libvirtd на вычислительных узлах:

# systemctl restart libvirtd

Последнее что нужно поправить — это флаги миграции. Делается это также на всех вычислительных узлах:

# crudini --set /etc/nova/nova.conf DEFAULT block_migration_flag VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

Данное изменение необходимо, поскольку флаги по умолчанию включают в себя TUNELLED, который не работает с обновленным кодом NBD (Network Block Device) в QEMU. Для применения изменений необходимо рестаротовать сервис nova-compute:

# systemctl restart openstack-nova-compute.service

Теперь можно отдать команду на живую миграцию, обязательно указав опцию –block-migrate, которая отвечает за миграцию без общего дискового хранилища:

$ source keystonerc_admin
$ nova live-migration --block-migrate 9e319540-9a67-4563-9aad-132c64faa1b1 compute.test.local

Однако, в случае использования CentOS и дистрибутива RDO мы живой миграции не увидим, а получим ошибку в файлах журнала nova-compute:

2015-12-05 23:07:49.391 31600 ERROR nova.virt.libvirt.driver

 [req-4986043d-abf4-40c4-85d4-7c6b3d235986 6310882678344e8183f2d7e886088293

 8cc74ebe8da94fe0a7ac6cf54f31b420 - - -] [instance: 7c505c55-69a8-493c-a119-cba65d58e3bb]

 Live Migration failure: internal error: unable to execute QEMU command 'migrate':

 this feature or command is not currently supported

Это связано с тем, что в CentOS пакет qemu-kvm собран без поддержки ряда функций, включая необходимые для живой миграции без общего хранилища. В дальнейшем CentOS Virt-SIG возможно это исправит, но пока нам необходимо заменить пакет qemu-kvm, подключив репозиторй oVirt, где он присутствует с нужным функционалом:

# yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm
# yum -y install qemu-kvm-ev

В результате пакеты qemu-kvm, qemu-kvm-common и qemu-img будут заменены. Снова можно повторить команду, указав идентификатор виртуальной машины, которую мы хотим мигрировать. При помощи nova show проверим на каком узле работает виртуальная машина до и после миграции:

$ nova show 1d95d3e3-338e-4681-bcb8-d549d1fa1a4c | grep  hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute-opt.test.local   |
$ nova live-migration --block-migrate 1d95d3e3-338e-4681-bcb8-d549d1fa1a4c
$ nova show 1d95d3e3-338e-4681-bcb8-d549d1fa1a4c | grep  hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.test.local       |

Как мы видим, миграция на этот раз прошла удачно. В журнале должно появиться сообщение подобное следующему:

2015-12-05 23:29:54.298 887 INFO nova.compute.manager

 [req-a09dc90b-8b69-4e15-8dee-f96ac7d197c3 6310882678344e8183f2d7e886088293

 8cc74ebe8da94fe0a7ac6cf54f31b420 - - -] [instance: 1d95d3e3-338e-4681-bcb8-d549d1fa1a4c]

 Migrating instance to compute.test.local finished successfully.

Во время самого процесса миграции на узле-источнике можно следить за ходом ее выполнения при помощи команды virsh:

[root@compute-opt ~]# virsh domjobinfo instance-000000e3
Job type:         Unbounded   
Time elapsed:     1084         ms
Data processed:   25.162 MiB
Data remaining:   1.726 GiB
Data total:       2.016 GiB
Memory processed: 25.162 MiB
Memory remaining: 1.726 GiB
Memory total:     2.016 GiB
Memory bandwidth: 240.426 MiB/s
Constant pages:   69765       
Normal pages:     6276        
Normal data:      24.516 MiB
Expected downtime: 46           ms
Setup time:       2            ms