Мигрируем ВМ между центрами данных в zVirt: особенности и ограничения механизма

Вопрос о миграции виртуальных машин рано или поздно становится актуален практически в любых средах виртуализации. Инструменты для этого в рамках одного кластера были в zVirt и раньше. В версии 4.4 мы добавили механизм миграции между кластерами. А в версии 5.0 мы представили миграцию между центрами данных и благодаря этому закрыли практически все сценарии миграции ВМ и их компонентов, к которым привыкли пользователи VMWare.

Я Стас Борисов, архитектор в команде zVirt Orion soft. В этой статье я расскажу, какие проблемы решает новый механизм и наглядно покажу, как выполнить «переезд» между центрами данных. Кроме того, мы подробно поговорим о существующих ограничениях этого инструмента и обсудим, что делать, если с вы ними столкнулись.

Для начала разберемся, в чем разница между различными схемами миграции виртуальных машин. Ведь любой процесс «переезда»  ВМ на другую площадку, сервер или хранилище сводится к тому, что сначала ваша машина запускается на одном сервере, а потом — на другом, сначала работает с данными из одного хранилища, а потом — из другого. Разница в том, насколько просто это реализовать. Инструменты миграции помогают оптимизировать процесс, снизить даунтайм и избежать ошибок. Это особенно интересная задача при переезде между двумя центрами данных, так как вы физически не можете сделать общим их дисковое пространство без дополнительного (и часто дорогостоящего) программного или аппаратного решения.

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

Переноса ВМ VM13 из Центра Данных #1 в Центр Данных #2 при помощи буферного домена хранения NFS

Подобные процедуры требуют множества дополнительных шагов для администратора и могут привести к длительным даунтаймам. 

Чтобы избежать этого, мы реализовали в zVirt механизм миграции виртуальных машин между центрами данных. Его схема приведена ниже. 

Процесс живой миграции ВМ VM13 посредством взаимодействия модуля zVirt backend со стеком KVM/QEMU

Новая схема подразумевает создание задачи на миграцию с учетом существующей инфраструктуры как исходного центра данных, так и конечного. При онлайн-миграции ВМ приезжают в реальном времени. Процесс миграции  использует механизм QEMU/KVM «грязные страницы» (dirty pages) для консистентного перемещения данных памяти и дисков ВМ. Тут нужно понимать, что пропускная способность сети миграции должна позволять реплицировать большой объем данных, которые могут измениться после старта процедуры миграции.

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

Пользователь формирует задачу на «холодную» миграцию и перемещение ВМ  

Кому нужна миграция ВМ между центрами данных

Недавно один из наших заказчиков, крупный российский банк, успешно развернул систему виртуализации zVirt. Там были запущены хосты, установлены системы хранения. Через некоторое время для масштабирования потребовалось добавлять новые виртуальные пространства — но уже не в существующий центр данных, а в новый. Возникла задача переноса существующих ВМ, причем максимально быстро и без потерь данных. Здесь и понадобился новый инструмент миграции за счет своей возможности перенести ВМ так, чтобы пользователи этого даже не заметили.

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

Инфраструктура другого нашего заказчика из финансового сектора состоит из множества хостов с внутренними дисками без внешнего хранилища. Конечно, можно бы использовать SDS, но заказчик не хотел идти на дополнительные затраты — ведь у него и так все работает. При этом каждый хост фактически представляет собой «мини центр данных». И здесь вполне применима новая схема миграции. Она позволяет сбалансировать нагрузку, а также переносить виртуальные машины, если хост, например, переводится на обслуживание. 

Процесс миграции

Теперь посмотрим, как именно реализовать процесс миграции ВМ между центрами обработки данных. Приготовьтесь: будет много скринов.

Итак, у нас есть задача мигрировать несколько ВМ из одного центра данных в другой.

Три ВМ:

• 1C-BACKUP-01

• 1C-CORP-DB-01

• 1C-CORP-DB-02

Исходный центр данных: Site1_DataCenter1

Исходный кластер: site1_DC1_cluster1

Исходные домены хранения: DRHW01_replication, DRHW02_replication

Целевой центр данных: Site1_DataCenter2

Целевой  кластер: site1_DC2_cluster1

Целевой домен хранения: DC2_FC_StorageDomain1

Переходим в интерфейс администратора WebUI, находим нам нужные ВМ. Структурирование ВМ при помощи папок дает нам возможность группировать их «по смыслу» и оперативно находить нужные:

Для задачи миграции набора ВМ необходимо выделить нужные ВМ и перейти в раздел «Дополнительные действия» > «Миграция между центрами данных» 

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

Тут время сделать паузу и проговорить про текущее ограничение — пока не поддерживается миграция ВМ с включенным режимом высокой доступности (HA), его придется временно отключить. 

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

Для успешной миграции нам потребуется временно отключить режим HA для набора мигрируемых ВМ, делается это в свойствах ВМ («Изменить» > «Высокая доступность»):

Снять высокую доступность необходимо со всех мигрируемых ВМ. Если ВМ достаточно много, то упростить задачу поможет наш функциональность массового изменения свойств высокой доступности, найти ее можно в разделе «Дополнительные действия» > «Высокая доступность»:

Переходим в раздел и снимаем чекбокс с «Высокая доступность», нажимаем «Далее» и по итогу применяем конфигурацию для выбранных ВМ:

Теперь нам ничего не помешает запустить процесс миграции ВМ между центрами данных, возвращаемся к действию «Миграция между центрами данных»:

Теперь визард успешно прошел проверку и предлагает нам заполнить целевые параметры для миграции:

Определяем параметры миграции:

Центр данных — целевой центр данных

Кластер назначения — целевой кластер

Профиль CPU — название профиля CPU целевого кластера

Хост назначения — необязательный параметр, определяет хост для запуска ВМ, значение «Автоматически» позволяет платформе виртуализации выбрать любой доступный хост в целевом кластере.

Сеть для миграции — выбор сети для выполнения процесса миграции. Значение «Автоматически» установит сеть миграци с ролью «Сеть миграции».

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

Продолжаем заполнять параметры нашей миграции. Далее необходимо задать целевой профиль для каждого сетевого интерфейса ВМ:

Для успешной миграции ВМ и дальнейшей ее сетевой доступности между исходными и целевыми хостами должна быть L2 сетевая связность.

Идем дальше и определяем целевой домен хранения для дисков ВМ. Для ускорения процесса можно воспользоваться множественным выбором всех дисков и назначением целевого домена хранения в несколько кликов. Мой случай простой: из нескольких исходных доменов хранения мигрирую в один целевой:

Нажимаем «Далее», финализируем нашу задачу проверкой и отправляем на исполнение:

Процесс запущен. Статус выполнения можно наблюдать в разделе списка виртуальных машин:

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

Для получения подробной информации о процессе миграции можно перейти в раздел «Управление» > «Задачи ВМ»:

Видим три активных задачи миграции выбранных ВМ. Раскрытие каждой задачи позволит определить детали процесса миграции.

Спустя некоторое время, которое зависит от размера мигрируемых ВМ и пропускной способности сети миграции, ВМ успешно переместятся в целевой центр данных.

Успешность процедуры подтвердят завершенные задачи и статусы ВМ:

Диски ВМ теперь находятся в домене хранения DC2_FC_StorageDomain1, а сами ВМ — в кластере site1_DC2_cluster1. Все это объекты центра данных Site1_DataCenter2.

На этом миграция завершена. Далее кратко перечислю ограничения, о которых упоминал выше. 

Особенности и ограничения механизма

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

1. Лимиты

Максимальное количество мигрируемых ВМ в рамках одного визарда: 10

Максимальное количество одновременно запущенных миграций на хосте: 2

2. Наличие снапшота

Мы не можем проводить миграцию ВМ, у которых есть снапшоты. Если у ВМ есть активный снимок перед миграцией, его нужно удалить.

3. Включенный режим HA

Пока режим HA не поддерживается для мигрируемых ВМ, необходимо сначала отключить его. Впрочем, мастер миграции напомнит вам об этом, как было в примере моего кейса миграции. Скоро планируем снять это ограничение.

4. ВМ Hosted Engine 

ВМ с ролью Hosted Engine пока невозможно мигрировать между центрами данных.

5. Проброс физических устройств

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

6. Локальное хранилище 

Миграция ВМ невозможна, если целевой центр данных имеет мастер-домен локального хранилища или миграция выполняется на домен с типом «локальное хранилище».

7. Изменение типа диска с RAW на QCOW

При миграции RAW тонкого диска (динамически расширяемого) с файлового хранилища в блочное тип диска изменится с RAW на QCOW,

8. Миграция тонких дисков в блочный домен хранения

При миграции в блочный домен хранения необходимо убедиться, что в целевом домене хранения достаточно места для размещения диска с учетом его полного размера (Virtual size). 

9. Отмена «холодной» или офлайн миграции

На данный момент отмена запущенной «холодной» миграции недоступна: необходимо дождаться полного завершения задачи. Мы работаем над улучшением этой возможности.

10. Наблюдаемость «холодной» или офлайн миграции

Визуально наблюдать за процессом переноса дисков пока нет возможности, будет исправлено в ближайших релизах.

11. Параметры ВМ и дисков

При миграции сбрасываются параметры ВМ/дисков/сети.

ВМ:

• выделенные хосты (Dedicated Hosts)

• группы сходства (Affinity Groups)

• метки сходства (Affinity Labels)

Диски/сети:

• квоты (QoS)

12. Миграция между программно-определяемыми сетями возможна только в соответствии со следующей таблицей

Заключение

Как показывает опыт наших пользователей, фича уже с первых дней оказалась востребованной, помогает коллегам экономить время и не уводить ВМ в длительный даунтайм даже в сложных схемах «переезда». А мы тем временем продолжаем дорабатывать возможности инструментов zVirt и работаем над ускорением процесса миграции.