6.9.2 Живая миграция

В процессе живой миграции участвуют два работающих гипервизора – исходный, из которого должен быть осуществлен перенос и целевой – на который будет производиться перенос [1].

Ниже изложена инструкция по выполнению живой миграции. Дополнительный материал об использовании миграции на уровне хранилища изложен в Раздел 6.5.2.2.8.

Дополнительная информация по живой (блочной) миграции доступна по ссылке:

Примечания.

Подробная диаграмма последовательности вызовов доступна на сайте официальной документации OpenStack Nova.

6.9.2.1 Проверка связанности

Прежде всего, следует начать проверки IP-связанности вычислительных узлов, на которых функционируют исходный и целевой гипервизоры. Подключитесь к ВУ с исходным гипервизором и выполните команду:

# ping compute-opt

Далее, необходимо запустить ВМ и определить, на каком из доступных ВУ она работает. Выполните однотипные команды:

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.

Примечание

в Рукадмина д.б. информация о том, как это определить из Dashboard

Дальше следует определить, какой flavor использован для этой ВМ. Выполните команду:

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

6.9.2.2 Проверка доступности ресурсов

Проверьте, достаточно ли ресурсов на том узле, который содержит целевой гипервизор, выполнив команду:

$ 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         |
+--------------------+------------+-------+-----------+-----------+

Если разница между общим количестом и использованием каждого из ресурсов (cpu, memory_mb, disk_gb) позволяет размещение ВМ, обслуживаемой исходным гипервизором, то можно продолжить.

6.9.2.3 Подготовка конфигурации (гипервизора)

Однако, прежде чем запускать на выполнение команду миграции, необходимо разрешить демону libvirtd «слушать» входящие подключения (по сети). На том и другом гипервизорах необходимо добавить опцию, отвечающую за строку запуска демона, в файл конфигурации (системной службы) /etc/sysconfig/libvirtd:

LIBVIRTD_ARGS=»–listen»

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

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

Примечание.

Альтернативой последней настройке может быть использование сертификатов или Kerberos.

Выполните рестарт системной службы libvirtd (перезапуск гипервизора) на всех вычислительных узлах, для вступления в силу изменений в конфигурации:

systemctl restart libvirtd

Последний шаг настройки – исправление флагов миграции. Делается это также на всех вычислительных узлах. Выполните (с правами root) команду:

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

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

Для применения изменений необходимо перезапустить службу вычислений (Nova Compute). Выполните команнду:

systemctl restart openstack-nova-compute.service

6.9.2.4 Запуск процесса миграции

Выполните подготовку окружения (пройдите аутентификацию):

$ source keystonerc_admin

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

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

где

compute.test.local – ВУ, на котором функционирует целевой гипервизор.

Примечание.

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

# virsh domjobinfo instance-000000e3

6.9.2.5 Проверка результата миграции

При помощи команды nova show проверяется, на каком узле работает ВМ. Используйте эту команду до и после миграции, чтобы уточнить результат выполнения операции (живой) миграции:

$ nova show <vm_UUID> | grep  hypervisor

| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute-opt.test.local   |
$ nova live-migration --block-migrate <vm_UUID>

$ nova show <vm_UUID> | grep  hypervisor

| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.test.local       |

Различие в принадлежности ВМ с идентификатором vm_UUID к гипервизору говорит о том, что миграция выполнена успешно.

В журнале [2] должно появиться сообщение следующего вида:

<Дата_и_Время> 887 INFO nova.compute.manager [req-a09dc90b-8b69-4e15-8dee-f96ac7d197c3 6310882678344e8183f2d7e886088293 8cc74ebe8da94fe0a7ac6cf54f31b420 - - -] [instance: <vm_UUID>] Migrating instance to compute.test.local finished successfully.

6.9.2.6 Нештатные ситуации

В случае использования ОС 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 собран без поддержки ряда функций, включая те, что необходимы для живой миграции без общего хранилища. Чтобы обойти проблему, необходимо заменить пакет (qemu-kvm), подключив репозиторий oVirt (в котором хранится собранный пакет, содержащий необходимый функционал).

Внимание

а что в AlmaLinux ?

Выполните команды:

# 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.

6.9.2.7 Живая миграция с использованием двух хранилищ

В ОП TIONIX реализована возможность миграции блочных и файловых дисков между системами хранения, без останова работы виртуальных машин («на-лету»). В результате выполнения такого рода живой миграции (между устройствами разных типов) исходное стройство будет удалено автоматически, освободив при этом дисковое пространство, занимаемое ранее (виртуальным диском).

Внимание.

В демонстрируемом кейсе платформа использует сразу два типа устройств хранения – SATA и SAS. Устройства расположены на разных физических хранилищах (type1 и type2, соответсвенно).

Создайте виртуальную машину, корневой диск которой будет размещен на системе хранения второго типа (SAS). Диск не является эфмерным, т.е. он обслуживается как блочное, а не файловое устройство. На него следует установить образ гостевой ОС, после чего следует запустить виртуальную машину с этого (виртуального) диска.

После того как ВМ создана (с СХД второго типа) и активна, следует запустить процесс миграции диска ВМ, с одного хранилища на другое. В процессе миграции будет создана копия исходного объекта на системе хранения первого типа (type1), и произведена синхронизация состояния данных объектов.

Откройте консоль ВМ и убедитесь, что она все это время работает (активна) и доступна. Дождитесь синхронизации устройств хранения, пока не станет видно, что система начала подключать новый диск к гостевой ОС (система все еще работает с СХД второго типа).

Проверьте, зарегистрировано ли это устройство внутри операционной системы ? Должен быть виден диск /dev/vda1 и его параметры. Этот диск – корневой диск ВМ; с ним постоянно идет внутрисистемное взаимодействие.

Когда процесс миграции завершится, будет видно, что виртуальная машина работает уже с СХД первого типа, т.е. «переехала» (с одного хралища на другое).

Проверьте, что произошло внутри ВМ ?.. Должно быть очевидно, что новый диск полностью идентичем предыдущему, а гостевая ОС не обнаружила подмены хранилища. Проверьте состояние (гостевой) системы и убедитесь, что она нормально функционирует.

Сноски

[1]http://markelov.blogspot.com/2015/12/openstack.html, https://sugerent.tistory.com/507
[2]https://docs.openstack.org/nova/victoria/admin/manage-logs.html