Привет, Хабр!

Это снова Евгений Шилкин и Степан Татауров, эксперты дивизиона инфраструктуры Группы Rubytech. В прошлой статье мы разобрали подходы к миграции, посмотрели, какие есть альтернативные решения, и обмолвились парой фраз про MIND Migrate Guest. 

В этой статье — практическая часть, она будет посвящена именно MIND.

Что из себя представляет процесс миграции с точки зрения алгоритма и чем он отличается от простого переноса между серверами? Сейчас разберемся.

Способы переноса виртуальной машины (ВМ) между серверами виртуализации

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

Миграция может проходить по двум сценариям:

1. Между различными платформами — об этом способе пойдет речь ниже.

2. Внутри одной платформы — например, для балансировки нагрузки между гипервизорами или для реализации сценариев отказоустойчивости. Но сегодня не об этом.

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

Вот типовая схема ключевых элементов:

1. На исходную ВМ устанавливается специализированный агент миграции для захвата данных на уровне ОС.

2. На целевой платформе виртуализации разворачивается «пустая» ВМ — ресивер с аналогичной операционной системой.

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

4. Через веб-интерфейс настраивается связка «Источник – Целевая ВМ» и запускается процесс репликации.

5. Выполняется полное копирование блоков данных дисков с исходной ВМ на целевую без остановки сервисов.

6. После передачи основного объема данных инструмент переходит в режим отслеживания изменений. Все изменения, возникающие в процессе работы ОС, непрерывно передаются на целевую ВМ.

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

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

В отличие от агентской миграции, этот процесс является дискретным и обычно выполняется по следующей схеме:

1. На целевой платформе настраивается подключение к источнику. Выполняется проверка ресурсов и сетевой связанности.

2. Виртуальная машина на источнике выключается. Начинается процесс копирования ее виртуальных дисков. В этот момент диски часто «упаковываются» или сжимаются, что требует времени.

3. Поскольку разные платформы используют разные форматы дисков, система автоматически преобразует файлы данных, чтобы они стали «понятными» для новой среды.

4. Файлы описания ВМ (процессоры, память, сеть) также пересчитываются под стандарты целевой платформы.

5. В целевой среде регистрируется новая ВМ, к которой подключаются конвертированные диски. Производится первый запуск и проверка работоспособности.

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

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

Пришло время посмотреть на MIND в деле! 

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

Для миграции мы выбрали MIND Migrate Guest. Это универсальное решение, совместимое с большинством платформ виртуализации. Само тестирование мы решили провести для более глубокого изучения принципов работы агентской миграции между различными платформами виртуализации: VMware, zVirt, «РЕД ВИРТ» и VMmanager.

Стенд и сценарии тестирования

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

1. Веб-сервер на базе РЕД ОС: две виртуальные машины (сервер и клиент) с графическим интерфейсом. На сервере развернут полноценный веб-сервис в среде Docker, включающий СУБД PostgreSQL, веб-сервер Nginx и backend-часть на Python 3.

2. Домен на базе Windows: две виртуальные машины, имитирующие классическую офисную инфраструктуру. Включает контроллер домена на базе Windows Server 2019 и клиентскую рабочую станцию на Windows 10, введенную в этот домен. На клиентской ВМ на рабочем столе расположена папка с важными файлами.

3. Файловая нагрузка на базе ОС Astra Linux: отдельная виртуальная машина, выступающая в роли хранилища. Содержит объемный файл со случайными значениями для проверки переноса больших файлов.

У всех ВМ были следующие параметры:

В зависимости от типа ОС (Windows или Linux) у всех виртуальных машин совпадали характеристики. ВМ-приемники создавались с аналогичными параметрами. Сетевой адаптер внутри платформы виртуализации поддерживает максимальную скорость в 10 Гбит/с.

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

Схема с расположением виртуальных машин на тестовых серверах выглядит так:

Стенд развернули на четырех одинаковых серверах:

Проводим тестовую миграцию

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

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

Собственно, миграция

Ниже описан ход миграции одной виртуальной машины. Такой процесс повторялся для всех ВМ:

1. Подготовили ВМ-приемники, на них установили агенты. ОС на приемниках ставилась в минимальной конфигурации, а в ОС семейства Linux — без графического интерфейса.

2. Создали задание на миграцию, в котором указали все необходимые параметры:

   • диски;

   • сетевые параметры (имена адаптеров, IP-адреса, MAC-адреса);

   • параметры синхронизации и автоматическое начало миграции;

   • дополнительные параметры, например, «выключить источник после миграции»;

3. Запустили миграцию (подробности ниже, не все случилось с первого раза);

4. Проверили результаты миграции.

Результаты тестирования

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

1. Первые пару миграций провалились из-за неправильных настроек сети. На разных платформах виртуализации по-разному эмулируются сетевые адаптеры, и в ОС семейства Linux это важный момент. Например, на исходной платформе виртуализации сетевой адаптер был eth0, а на целевой — ens192. При первых миграциях мы это не учли, и при настройке задания на миграцию использовали пункт «копировать настройки» полностью из источника. Да, самонадеянно, но попробовать стоило.

2.  При выборе настроек доступны различные варианты. Например, можно оставить настройки приемника нетронутыми во избежание проблем. Как результат — в конфигурационном файле IP-адрес будет присвоен не тому адаптеру, и сеть на виртуальной машине не будет работать. Да, это все быстро чинится, но при миграции важного сервера такое недопустимо.

3. Также мы столкнулись с проблемой в Linux-системах и им подобных: если selinux включен, его надо полностью выключить перед миграцией. Это есть в документации, но в первый раз мы это пропустили просчитались, и целевая ВМ сломалась. Для автоматизации подготовки целевой ВМ перед миграцией предусмотрены скрипты, которые можно выполнять на любом этапе миграции. А при наличии отключенного selinux он автоматически включается после выполнения миграции.

В результате на всех виртуальных машинах мы успешно провели миграцию и вся полезная нагрузка полностью сохранилась — сработало. При миграции у всех ВМ сохранились старые IP-адреса, что позволило поддержать сетевую связность на всех ВМ. Средняя скорость передачи данных между виртуальными машинами составила 886 МБ/с (~7 Гбит/с).

При миграции подготовительные и завершающие операции занимают фиксированные 4-5 минут, сама передача данных для диска 30ГБ длится примерно 35 секунд, что дает общее время миграции около 6 минут. Для ВМ с диском 90ГБ процесс занимает порядка 7 минут, из которых сетевое копирование длится около двух минут. При правильной настройке сети эти показатели можно сильно улучшить, но это не было самоцелью. Ключевым было — разобраться, как все устроено.

Из интересного

При миграции ярко проявилась особенность MIND Migrate: передача данных идет напрямую между ВМ-источником и целевой ВМ без участия контроллера. Это позволяет развернуть узел управления в облаке, куда доступ есть по IP-адресу, а сами виртуальные машины могут быть недоступны с контроллера — например, они могут находиться за NAT-сетью. Это же и позволяет передавать большие объемы данных при прямом подключении между исходной и целевой ВМ.

А еще имейте в виду, что MIND Migrate умеет самостоятельно распознавать платформу виртуализации, на которую выполняется миграция, и автоматически устанавливать требуемые драйвера. Например, для Windows нужно установить отдельно драйвер VirtIO для сетевых подключений этого типа. В нашем случае платформа миграции делает это автоматически, а не просто перекидывает диск и оставляет вас в ситуации «может, заработает, может, нет — дальше сами».

Еще из удобств — гибкие сетевые настройки при формировании задания на миграцию. Есть кнопки, которые позволяют использовать настройки источника, приемника, также можно вручную указать требуемые параметры. Например, после нажатия кнопки «оставить данные из источника» требовалось переименовать сетевой адаптер. То есть IP- и MAC-адреса берутся из источника, при этом название интерфейса надо было оставить от целевой ВМ.

Вместо вывода

Проведенные тесты подтвердили: агентская миграция — это универсальный способ, который будет успешно работать в большинстве сценариев (материалы MIND уверяют, что даже включая случаи переноса данных на уровне ОС с bare metal на любой гипервизор или облако). Этот метод нивелирует различия между платформами, обеспечивая корректную работу систем вне зависимости от исходного гипервизора или «железа».

Результаты тестирования можно применить и в проектах перехода на ПАК Скала^р. В таком сценарии MIND Migrate обеспечивает перенос виртуальных машин и полезной нагрузки, а ПАК выступает в роли заранее интегрированной целевой инфраструктуры. Это позволяет разделить две задачи: автоматизировать саму миграцию и одновременно сократить объем работ по развертыванию и согласованию компонентов новой платформы. 

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