Динамическая миграция – это перенос работающего инстанса с одного вычислительного узла на другой. Будучи крайне востребованной среди администраторов облачных сервисов, эта функция используется в основном для обеспечения нулевого времени простоя при обслуживании облака, а также может быть полезной для поддержания работоспособности, т.к. позволяет перенести работающие инстансы с сильно загруженного вычислительного узла на менее загруженный.
Планирование динамической миграции должно осуществляться на раннем этапе планирования и проектирования развертывания OpenStack. Необходимо учесть следующее:
•На сегодняшний день не все гипервизоры поддерживают миграцию в OpenStack, поэтому лучше проверить в списке HypervisorSupportMatrix, поддерживает ли ваш гипервизор возможность динамической миграции. К гипервизорам с поддержкой данной функции в настоящее время относятся, например, KVM, QEMU, XenServer/XCP и HyperV.
•При стандартном развертывании Openstack каждый вычислительный узел локально управляет своими инстансами в выделенной директории (например, /var/lib/nova/instances/), но для динамической миграции эта папка должна храниться централизованно и совместно использоваться всеми вычислительными узлами. Поэтому наличие файловой системы или хранилища блоков данных общего доступа – важное требование для осуществления динамической миграции. Для такого хранения данных необходимо корректно настроить распределенную файловую систему типа GlusterFS или NFS и запустить ее до начала миграции. Также для совместно используемой памяти можно применять такие протоколы хранения данных SAN, как Fibre Channel (FC) и iSCSI.
•Для предоставления прав доступа к файлам при пользовании централизованным хранилищем в общей памяти необходимо убедиться, что UID и GID пользователя Compute (nova) одинаковые на узле контроллера и на всех вычислительных узлах (при этом предполагается, что общая память размещается в узле контроллера). Кроме того, UID и GID идентификаторы libvirt-qemu также должны быть одинаковые на всех вычислительных узлах.
•Важно задать vncserver_listen=0.0.0.0, чтобы сервер vnc мог принимать соединения от всех вычислительных узлов независимо от того, где запущены инстансы. Если данное значение не задано, то с доступом к перенесенным инстансам через vnc могут быть проблемы, т.к. IP-адрес целевого вычислительного узла не будет соответствовать IP-адресу вычислительного узла-источника.
Приведенные ниже инструкции позволят выполнить динамическую миграцию при развертывании многорежимной платформы OpenStack с использованием гипервизора KVM, работающего на ОС Ubuntu 12.04 LTS, и файловой системы общего доступа NFS. Данное руководство предполагает, что развернутая и работающая многорежимная платформа уже настроена при помощи такой системы автоматической установки, как Mirantis Fuel. Руководство основано на испытаниях с использованием следующих компонентов: узел контроллера облака, сетевой узел, использующий сервис подключения к сети Neutron, а также два вычислительных узла.
Обращаю ваше внимание на то, что в руководстве не рассматриваются аспекты безопасности при проведении динамической миграции. Изучите этот важный вопрос самостоятельно и не воспринимайте данные инструкции как готовое руководство к действию с точки зрения обеспечения безопасности.
Руководство включает два этапа: первый – процедура внедрения NFS; второй – демонстрация динамической миграции.
Часть 1: Внедрение файловой системы общего доступа NFS
Узлом контроллера облака является сервер NFS. Цель – обеспечить совместное использование /var/lib/nova/instances всеми вычислительными узлами вашего кластера Openstack. Директория содержит файлы образа диска libvirt KVM для инстансов, размещенных в данном вычислительном узле. Если вы не используете облако в среде общего хранилища, данная директория будет уникальной для всех вычислительных узлов. Обратите внимание на то, что, если ваши инстансы уже работают в облаке до конфигурации динамической миграции, необходимо принять меры предосторожности во избежание блокировки этих инстансов.
Сделайте следующее на сервере NFS/узле контроллера:
1. Выполните установку сервера NFS.
root@vmcon-mn:~# apt-get install nfs-kernel-server
2. IDMAPD обеспечивает функциональность клиента и сервера ядра NFSv4 посредством трансляции ID пользователей и групп в их имена и наоборот. Измените /etc/default/nfs-kernel-server и задайте значение указанной опции = yes. Данный файл должен быть одинаковым и на клиенте, и на сервере NFS.
NEED_IDMAPD=yes # only needed for Ubuntu 11.10 and earlier
3. Убедитесь, что file /etc/idmapd.conf содержит следующее:
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
4. Чтобы расшарить /var/lib/nova/instances, добавьте следующее в /etc/exports:
192.168.122.0/24(rw,fsid=0,insecure,no_subtree_check,async,no_root_squash)
Где 192.168.122.0/24 – сетевой адрес вычислительных узлов (как правило, целевой сети данных) для вашего кластера OpenStack.
5. Задайте следующее значение бита ‘execute’ в расшаренной директории, чтобы qemu мог использовать образы внутри директорий при их экспорте в вычислительные узлы.
root@vmcom1-mn:~# chmod o+x /var/lib/nova/instances
6. Перезапустите сервисы.
root@vmcon-mn:~# service nfs-kernel-server restart
root@vmcon-mn:~# /etc/init.d/idmapd restart
Выполните следующие действия на каждом вычислительном узле:
1. Выполните установку сервисов клиента NFS.
root@vmcom1-mn:~#apt-get install nfs-common
2. Измените /etc/default/nfs-common и задайте значение указанной опции = yes.
NEED_IDMAPD=yes # only needed for Ubuntu 11.10 or earlier
3. Выполните монтирование файловой системы совместного доступа с сервера NFS.
mount NFS-SERVER:/var/lib/nova/instances /var/lib/nova/instances
Где NFS-SERVER – имя хоста/IP-адрес сервера NFS.
4. Чтобы не набирать это заново после каждого ребута, добавьте следующую строку в /etc/fstab:
nfs-server:/ /var/lib/nova/instances nfs auto 0 0
5. Проверьте все вычислительные узлы и убедитесь, что у прав доступа установлены указанные ниже значения. Это показывает, что на узле контроллера заданы правильные значения прав доступа при помощи приведенной выше команды chmod +x.
root@vmcom1-mn:~# ls -ld /var/lib/nova/instances/
drwxr-xr-x 8 nova nova 4096 Oct 3 12:41 /var/lib/nova/instances/
6. Убедитесь, что экспортируемую директорию можно смонтировать и что она смонтирована.
root@vmcom1-mn#mount –a -v
root@vmcom1-mn:~# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda1 6192704 1732332 4145800 30% /
udev 1991628 4 1991624 1% /dev
tmpfs 800176 284 799892 1% /run
none 5120 0 5120 0% /run/lock
none 2000432 0 2000432 0% /run/shm
cgroup 2000432 0 2000432 0% /sys/fs/cgroup
vmcon-mn:/var/lib/nova/instances 6192896 2773760 3104512 48% /var/lib/nova/instances
Проверьте, совпадает ли последняя строка с приведенной в списке. Она означает, что экспорт /var/lib/nova/instances с сервера NFS прошел корректно. Если этой строки нет, возможно, ваша файловая система общего доступа NFS работает с ошибками и нужно их исправить перед тем, как продолжить.
7. Обновите настройки libvirt. Измените /etc/libvirt/libvirtd.conf. Чтобы увидеть все возможные варианты, см. настройки libvirtd.
before: #listen_tls = 0
after: listen_tls = 0
before: #listen_tcp = 1
after: listen_tcp = 1
add: auth_tcp = «none»
8. Измените /etc/init/libvirt-bin.conf.
before: exec /usr/sbin/libvirtd -d
after: exec /usr/sbin/libvirtd -d -l
-l – сокращение от listen
9. Измените /etc/default/libvirt-bin.
before :libvirtd_opts=" -d"
after :libvirtd_opts=" -d -l"
10. Перезапустите libvirt. После выполнения данной команды, убедитесь в том, что перезапуск libvirt прошел успешно.
$ stop libvirt-bin && start libvirt-bin
$ ps -ef | grep libvirt
Прочие настройки
Вы можете пропустить описанные ниже действия, если динамическая миграция была запланирована с самого начала и основные требования выполнены, как указано во введении. Данные действия выполняются для того, чтобы убедиться, что nova UID и GID одинаковые на узле контроллера и на всех вычислительных узлах. Кроме того, одинаковыми должны быть и UID и GID идентификаторы libvirt-qemu на всех вычислительных узлах. Для этого нужно вручную изменить идентификаторы GID и UID для их унификации на вычислительных узлах и контроллере.
Сделайте следующее:
1. Проверьте значение nova ID на узле контроллера, затем сделайте то же на всех вычислительных узлах:
[root@vmcon-mn ~]# id nova
uid=110(nova) gid=117(nova) groups=117(nova),113(libvirtd)
2. Теперь, когда нам известны значения nova UID и GID, мы можем изменить их на всех вычислительных узлах, как показано ниже:
[root@vmcom1-mn ~]# usermod -u 110 nova
[root@vmcom1-mn ~]# groupmod -g 117 nova
Повторите данные действия для всех вычислительных узлов.
3. Сделайте то же самое для libvirt-qemu, но помните, что у узла контроллера нет данного пользователя, поскольку контроллер не запускает гипервизор. Убедитесь, что на всех вычислительных узлах одни и те же UID и GID для пользователя libvirt-qemu.
4. Поскольку мы поменяли UID и GID пользователей nova и libvirt-qemu, нужно убедиться, что это отражено во всех файлах, владельцами которых являются данные пользователи. Для этого сделайте следующее. Остановите сервисы nova-api и libvirt-bin на вычислительном узле. Замените на новые значения UID и GID во всех файлах, владельцами которых являются пользователь nova и группа пользователей nova, соответственно. Например:
[root@vmcom1-mn ~]#service nova-api stop
[root@vmcom1-mn ~]#service libvirt-bin stop
[root@vmcom1-mn ~]#find / -uid 106 -exec chown nova {} ; # note the 106 here is the old nova uid before the change
[root@vmcom1-mn ~]#find / -uid 104 -exec chown libvirt-qemu {} ; # note the 104 here is the old nova uid before the change
[root@vmcom1-mn ~]# find / -gid 107 -exec chgrp nova {} ; #note the 107 here is the old nova uid before the change
[root@vmcom1-mn ~]#find / -gid 104 -exec chgrp libvirt-qemu {} ; #note the 104 here is the old nova uid before the change
[root@vmcom1-mn ~]#service nova-api restart
[root@vmcom1-mn ~]#service libvirt-bin restart
Часть 2: Динамическая миграция виртуальной машины OpenStack.
После того, как кластер OpenStack и файловая система общего доступа NFS настроены должным образом, можно приступить к динамической миграции. Выполните следующие действия на узле контроллера:
1. Проверьте ID работающих инстансов.
nova list
root@vmcon-mn:~# nova list
+--------------------------------------+------+--------+------------------------+
| ID | Name | Status | Networks |
+--------------------------------------+------+--------+------------------------+
| 0bb04bc1-5535-49e2-8769-53fa42e184c8 | vm1 | ACTIVE | net_proj_one=10.10.1.4 |
| d93572ec-4796-4795-ade8-cfeb2a770cf2 | vm2 | ACTIVE | net_proj_one=10.10.1.5 |
+--------------------------------------+------+--------+------------------------+
2. Проверьте, на каких вычислительных узлах работают инстансы.
nova-manage vm list
root@vmcon-mn:~# nova-manage vm list
instance node type state launched image kernel ramdisk project user zone index
vm1 vmcom2-mn m1.tiny active 2013-10-03 13:33:52 b353319f-efef-4f1a-a20c-23949c82abd8 419303e31d40475a9c5b7d554b28a22f cd516c290d4e437d8605b411af4108fe None 0
vm2 vmcom1-mn m1.tiny active 2013-10-03 13:34:33 b353319f-efef-4f1a-a20c-23949c82abd8 419303e31d40475a9c5b7d554b28a22f cd516c290d4e437d8605b411af4108fe None 0
Мы видим, что виртуальная машина vm1 запущена на вычислительном узле 2 (vmcom2-mn), а vm2 – на узле 1 (vmcom1-mn).
3. Выполните динамическую миграцию. Мы осуществим перенос vm1 с id 0bb04bc1-5535-49e2-8769-53fa42e184c8 (полученным из приведенного выше списка nova), работающей на вычислительном узле 2, на вычислительный узел 1 (см. команду nova-manage в списке vm выше), vmcom1-mn. Обратите внимание на то, что это административная функция, поэтому, как правило, сначала нужно экспортировать переменные или исходный файл с учетными данными админа.
root@vmcon-mn:~# export OS_TENANT_NAME=admin
root@vmcon-mn:~# export OS_USERNAME=admin
root@vmcon-mn:~# export OS_PASSWORD=admin
root@vmcon-mn:~# export OS_AUTH_URL=«10.0.0.51:5000/v2.0/»
root@vmcon-mn:~# nova live-migration 0bb04bc1-5535-49e2-8769- 53fa42e184c8 vmcom1-mn
В случае успешного завершения команда nova live-migration ничего не возвращает.
4. Убедитесь в том, что миграция завершена, выполнив:
root@vmcon-mn:~# nova-manage vm list
instance node type state launched image kernel ramdisk project user zone index
vm1 vmcom1-mn m1.tiny active 2013-10-03 13:33:52 b353319f-efef-4f1a-a20c-23949c82abd8 419303e31d40475a9c5b7d554b28a22f cd516c290d4e437d8605b411af4108fe None 0
vm2 vmcom1-mn m1.tiny active 2013-10-03 13:34:33 b353319f-efef-4f1a-a20c-23949c82abd8 419303e31d40475a9c5b7d554b28a22f cd516c290d4e437d8605b411af4108fe None 0
Мы видим, что оба инстанса теперь работают на одном узле.
Заключение
Динамическая миграция важна для обеспечения нулевого времени простоя при обслуживании облака OpenStack, когда необходимо остановить некоторые из вычислительных узлов. Описанные выше действия по реализации совместного хранения данных и миграции запущенного инстанса были выполнены для демонстрации динамической миграции на облаке OpenStack Grizzly, работающем на базе ОС Ubuntu 12.04, с использованием файловой системы общего доступа NFS.
Оригинал статьи на английском языке
Автор: Mirantis_OpenStack
