Рассмотрим
на практике что стоит за кнопкой "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
1 комментарий:
Virt-SIG уже позаботился: в extras для CentOS 7 появился пакет centos-release-qemu-ev, который добавляет в систему репозиторий c qemu-kvm-ev.
Отправить комментарий