Живая Миграция На Openstack

Живая миграция — это перенос работающего экземпляра с одного вычислительного узла на другой.

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

Планирование динамической миграции следует выполнять на ранних стадиях планирования и проектирования развертывания OpenStack. Обратите внимание на следующее: •Сегодня не все гипервизоры поддерживают переход на OpenStack, поэтому лучше свериться со списком.

ГипервизорПоддержкаMatrix поддерживает ли ваш гипервизор живую миграцию.

Гипервизоры, которые в настоящее время поддерживают эту функцию, включают, например, 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: 1. Установите сервер NFS. root@vmcon-mn:~# apt-get install nfs-kernel-server 2. IDMAPD обеспечивает функциональность клиента и сервера для ядра NFSv4 путем преобразования идентификаторов пользователей и групп в их имена и наоборот. Отредактируйте /etc/default/nfs-kernel-server и установите для указанной опции значение Yes. Этот файл должен быть одинаковым как на клиенте, так и на сервере NFS. NEED_IDMAPD=yes # требуется только для Ubuntu 11.10 и более ранних версий 3. Убедитесь, что файл /etc/idmapd.conf содержит следующее: [Картирование] Никто-Пользователь = никто Никто-Группа = 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:~# перезапуск службы nfs-kernel-server root@vmcon-mn:~# /etc/init.d/idmapd перезапуск Выполните следующие действия на каждом вычислительном узле: 1. Установите клиентские службы NFS. root@vmcom1-mn:~#apt-get install nfs-common 2. Измените /etc/default/nfs-common и установите значение указанной опции = yes. NEED_IDMAPD=yes # требуется только для Ubuntu 11.10 или более ранней версии 3. Подключите общую файловую систему с сервера NFS. смонтировать NFS-СЕРВЕР:/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 3 октября 12:41 /var/lib/nova/instances/ 6. Убедитесь, что экспортированный каталог можно смонтировать и что он смонтирован.

root@vmcom1-mn#mount –a -v root@vmcom1-mn:~# df -k Файловая система Использовано 1 КБ блоков Доступно Использование% Установлено на /dev/vda1 6192704 1732332 4145800 30% / udev 1991628 4 1991624 1% /dev tmpfs 800176 284 799892 1%/запуск нет 5120 0 5120 0% /запуск/блокировка нет 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 .

до: #listen_tls = 0 после: Listen_tls = 0 до: #listen_tcp = 1 после: Listen_tcp = 1 добавить: auth_tcp = «нет» 8. Измените /etc/init/libvirt-bin.conf. до: exec /usr/sbin/libvirtd -d после: exec /usr/sbin/libvirtd -d -l -l – сокращение от «слушать» 9. Измените /etc/default/libvirt-bin. до :libvirtd_opts=" -d" после :libvirtd_opts=" -d -l" 10. Перезапустите libvirt. После выполнения этой команды убедитесь, что libvirt успешно перезапущен.

$ остановить libvirt-bin && запустить libvirt-bin $ пс -эф | grep libvirt

Другие настройки

Эти шаги выполняются для того, чтобы гарантировать, что UID и GID nova одинаковы на узле контроллера и на всех вычислительных узлах.

Кроме того, идентификаторы UID и GID libvirt-qemu должны быть одинаковыми на всех вычислительных узлах.

Для этого вам необходимо вручную изменить GID и UID, чтобы унифицировать их на вычислительных узлах и контроллере.

Сделайте следующее: 1. Проверьте значение nova ID на узле контроллера, затем сделайте то же самое на всех вычислительных узлах: [root@vmcon-mn ~]# идентификатор 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 стоп [root@vmcom1-mn ~]#service libvirt-bin стоп [root@vmcom1-mn ~]#find / -uid 106 -exec chown nova {} \; # обратите внимание, что 106 — это старый идентификатор nova до изменения [root@vmcom1-mn ~]#find / -uid 104 -exec chown libvirt-qemu {} \; # обратите внимание, что 104 — это старый идентификатор nova до изменения [root@vmcom1-mn ~]# find / -gid 107 -exec chgrp nova {} \; #обратите внимание на 107, это старый идентификатор nova до изменения [root@vmcom1-mn ~]#find / -gid 104 -exec chgrp libvirt-qemu {} \; #обратите внимание на 104, это старый идентификатор nova до изменения [root@vmcom1-mn ~]#service nova-api restart [root@vmcom1-mn ~]#service libvirt-bin restart

Часть 2. Живая миграция виртуальной машины OpenStack.

Выполните следующие действия на узле контроллера: 1. Проверьте идентификаторы запущенных экземпляров.

список нова root@vmcon-mn:~# список нова +--------------------------------------+------+--------+------------------------+ | удостоверение личности | Имя | Статус | Сети | +--------------------------------------+------+--------+------------------------+ | 0bb04bc1-5535-49e2-8769-53fa42e184c8 | вм1 | АКТИВНЫЙ | net_proj_one=10.10.1.4 | | d93572ec-4796-4795-ade8-cfeb2a770cf2 | вм2 | АКТИВНЫЙ | net_proj_one=10.10.1.5 | +--------------------------------------+------+--------+------------------------+ 2. Проверьте, на каких вычислительных узлах работают ваши экземпляры.

список виртуальных машин nova-manage root@vmcon-mn:~# список виртуальных машин nova-manage экземпляр тип узла состояние запущенный образ ядро ramdisk индекс зоны пользователя проекта vm1 vmcom2-mn m1.tiny active 03.10.2013, 13:33:52 b353319f-efef-4f1a-a20c-23949c82abd8 419303e31d40475a9c5b7d554b28a22f cd516c290d4e437d8605b 4 11af4108fe Нет 0 vm2 vmcom1-mn m1.tiny active 03.10.2013, 13:34:33 b353319f-efef-4f1a-a20c-23949c82abd8 419303e31d40475a9c5b7d554b28a22f cd516c290d4e437d8605b 4 11af4108fe Нет 0 Мы видим, что виртуальная машина vm1 работает на вычислительном узле 2 (vmcom2-mn), а виртуальная машина vm2 работает на узле 1 (vmcom1-mn).

3. Выполните живую миграцию.

Мы перенесем виртуальную машину 1 с идентификатором 0bb04bc1-5535-49e2-8769-53fa42e184c8 (полученную из списка nova выше), работающую на вычислительном узле 2, на вычислительный узел 1 (см.

команду nova-manage в списке виртуальных машин выше), vmcom1-mn. Обратите внимание, что это административная функция, поэтому обычно вам сначала потребуется экспортировать переменные или исходный файл с учетными данными администратора.

root@vmcon-mn:~# экспорт OS_TENANT_NAME=admin root@vmcon-mn:~# экспорт OS_USERNAME=admin root@vmcon-mn:~# экспорт OS_PASSWORD=admin root@vmcon-mn:~# экспорт 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 экземпляр тип узла состояние запущенный образ ядро ramdisk индекс зоны пользователя проекта vm1 vmcom1-mn m1.tiny active 2013-10-03 13:33:52 b353319f-efef-4f1a-a20c-23949c82abd8 419303e31d40475a9c5b7d554b28a22f cd516c290d4e437d8605b 4 11af4108fe Нет 0 vm2 vmcom1-mn m1.tiny active 03.10.2013, 13:34:33 b353319f-efef-4f1a-a20c-23949c82abd8 419303e31d40475a9c5b7d554b28a22f cd516c290d4e437d8605b 4 11af4108fe Нет 0 Мы видим, что оба экземпляра теперь работают на одном узле.

Заключение

Вышеупомянутые шаги по реализации совместного использования данных и миграции работающего экземпляра были выполнены для демонстрации живой миграции в облаке OpenStack Grizzly под управлением Ubuntu 12.04 с использованием системы общего доступа к файлам NFS. Оригинальная статья по-английски Теги: #Mirantis #Mirantis #openstack #open source #dynamic #compute node #cloud #hypervisor #kvm #QEMU #XenServer/XCP #hyperv #glusterfs #nfs #nfs #fibre Channel (fc) #iscsi #Fuel #grizzly #open источник

• Насколько Безопасно Программное Обеспечение Безопасности Вашего Пк?

  19 Oct, 24

• Как Включить Или Отключить Брандмауэр Microsoft Windows?

  19 Oct, 24

• Polywed - Технология, Повышающая Эффективность Искусственного Оплодотворения

  19 Oct, 24

• И Еще Раз Об Ответственности

  19 Oct, 24

• Faq.net — Бесплатная Программа Для Заметок Для Windows С Обновленным Дизайном

  19 Oct, 24

• Есть Ли Gamedev На Сахалине? Конец

  19 Oct, 24

• Сноуден В Россию, Хаммонд В Тюрьму

  19 Oct, 24

• Используем Консоль По Полной

  19 Oct, 24

• Вигерс, Ты Ошибаешься! Еще Раз Об Итеративной И Инкрементальной Разработке

  19 Oct, 24

• Lincut — Простой И Удобный Способ Сохранить Ваши Любимые Сайты

  19 Oct, 24