Привет, Хабр! Меня зовут Павел Князькин, я системный архитектор в Orion soft, занимаюсь развитием платформы виртуализации zVirt. Сегодня мы поговорим о миграции виртуальной инфраструктуры.
Миграция с иностранных платформ виртуализации, таких как VMware, HyperV, XEN, а иногда даже и с других отечественных систем виртуализации становится актуальной задачей для многих организаций. Но их останавливают трудности перехода: нужно каким-то образом переместить ВМ из одной платформы виртуализации в другую.
В этой статье я подробно разберу механизмы миграции в zVirt и покажу, что перенести ВМ можно достаточно быстро, удобно и без лишних сложностей. Сравню агентский и безагентский подходы, расскажу, как произвести конвертацию физического сервера в ВМ (P2V) и объясню, почему необязательно платить за миграцию каждой «машины».
Почему иногда миграция — это долго, больно и дорого
Допустим, перед вами стоит задача перевезти 500 ВМ из VMware в отечественную среду. Посмотрим на стандартный набор инструментов, которым обычно пользуются инженеры. Вариантов не так много.
Ручная миграция. Экспортируете ВМ в OVA-файл, конвертируете ВМ, импортируете в целевую платформу (+ внутри гостевой ОС удаляете старые драйверы и ставите новые). Звучит просто, но на практике ВМ может запуститься с первого раза, а может потребовать долгой отладки. На сотнях ВМ это может превратиться в недели ручной работы.
Специализированный платный софт. Российские решения вроде Hystax и MIND Software автоматизируют процесс и делают его более предсказуемым. Но проблема в лицензионной модели: вы обычно платите за количество ВМ, то есть за миграцию каждой отдельной машины.
Через резервное копирование. Решения для бэкапа есть у всех. Сам процесс понятен: делаем резервную копию ВМ на исходной платформе, затем восстанавливаем ее уже на целевой. В этом случае передача данных занимает много времени и требует простоя сервисов, а это для всех головная боль. Почти всегда приходится вручную ставить новые драйверы или удалять старые. Еще может потребоваться промежуточное хранилище для копий. Для небольших внедрений такой способ подойдет, но для более масштабных задач уже не так удобно и выгодно.
Мы посмотрели на эти проблемы миграции глазами заказчиков. Понятно, что если миграция превращается в отдельный долгий и дорогой проект, то компании будут откладывать переход на новое решение.
Поэтому, во-первых, инструменты миграции мы включили в базовую поставку zVirt. Не нужно покупать дополнительные лицензии и платить за переезд каждой ВМ. Во-вторых, мы стараемся упростить эту задачу для всех наших заказчиков, вне зависимости от их исходной ситуации. В версии zVirt 4.5 мы добавили новый v2v-конвертер. Он умеет работать не только с VMware, но и с другими системами виртуализации, включая отечественные. По сути, у нас сейчас два основных подхода к миграции: безагентский и агентский.
Дальше я разберу каждый метод подробно: когда какой использовать, как они технически устроены и в чем их плюсы.
Безагентский метод для VMware
Этот метод доступен в zVirt начиная с версии 4.1. Работает только с VMware vCenter и ESXi начиная с версии 6.0.3U2. Если у вас другой гипервизор, этот способ не подойдет. Подробная документация представлена у нас на сайте.
Как устроена архитектура
Метод называется безагентским, потому что не требует установки ПО внутрь каждой гостевой ОС. Работаем на уровне гипервизора через API VMware.
Для работы нужны три компонента, все это готовые образы виртуальных машин:
Агент-отправитель. Разворачиваете его на стороне VMware. При старте указываете FQDN или IP-адрес, создаете пользователя для доступа к VMware API;
Контроллер конвертации. Управляющий компонент на стороне zVirt, который координирует весь процесс;
Агент-приемник. Принимает данные и записывает их на диски в целевом хранилище zVirt.
Агенты и контроллер могут работать через сеть L2 или L3. Выбирайте оптимальный для вашей инфраструктуры.
Как это работает
Далее в графическом интерфейсе zVirt вы увидите динамически обновляющийся список из виртуальных машин среды VMware. Создали новую ВМ в VMware, она появилась в списке zVirt. Удалили, и она исчезла из списка. То есть синхронизация происходит автоматически.
Шаг 1: репликация. Выбираете нужную ВМ и запускаете репликацию. zVirt создает контрольную точку (snapshot) на стороне VMware и начинает передавать данные. Диски копируются в фоновом режиме. Все это время исходная ВМ продолжает работать на VMware.
Шаг 2: статус репликации. Когда первичная копия передана, статус меняется. ВМ все еще работает на VMware, но у вас уже есть ее копия в zVirt и Вы видите, когда была сделана реплика.
Шаг 3: инкрементная репликация (если необходимо). Перед запуском задачи на конвертацию рекомендуется выключить ВМ на целевой площадке и запустить репликацию ВМ, чтобы синхронизировать накопленные изменения. Эта репликация будет инкрементной, то есть будут переданы только изменения. Время инкрементной репликации значительно меньше, чем первичная репликация ВМ.
Шаг 4: при необходимости вы можете (с помощью сервиса cloud-init) указать IP адрес будущего сетевого адаптера внутри ВМ на zVirt.
Шаг 5: конвертация. Запускаете финальную конвертацию, для вас она будет происходить в автоматическом режиме. Преобразование ВМ заключается в модификации загрузочного раздела и добавлении драйверов VirtIO. Через 5-10 минут получаете готовую к запуску ВМ.
Список поддерживаемых операционных систем: Windows Server 2008 R2 и выше, Windows 7 и выше, RHEL, Debian, Ubuntu, CentOS и российские ОС. Весь список доступен здесь. Когда выходят новые версии, мы тестируем совместимость и обновляем данные.
Что в итоге вы получаете:
Автоматическую установку драйверов. Не придется делать это вручную на каждой ВМ;
Выключать ВМ нужно во время инкрементной репликации (если она требуется) и конвертации;
Высокую скорость конвертации;
Можно конвертировать до 20 ВМ одновременно;
В Linux есть проброс IP-адреса в новую ВМ через Cloud-Init.
Универсальный агентский метод
Агентский метод мы добавили в версию zVirt 4.5. Это универсальный подход: Вы можете с его помощью достаточно просто переехать с любой зарубежной платформы (Hyper-V, Xen, VMware и др.), с Российской системы (Space, ROSA, RED, Basis и др.) или даже с физического сервера (P2V).
В чем главное отличие от безагентского метода? Здесь мы работаем не с гипервизором, а на уровне самой операционной системы. На каждую машину, которую нужно перенести, устанавливается специальный агент-отправитель. Если раньше у нас была ВМ в качестве такого отправителя, то теперь уже «агент-отправитель» ставится внутри каждой ВМ.
Как это работает
Шаг 1. Ставите внутренний агент на гостевую ОС.
Шаг 2. Агент инициирует соединение с контроллером конвертации на стороне zVirt и передает информацию: сколько оперативной памяти, сколько CPU, какие есть диски.
Агент читает данные прямо с файловой системы:
Для Windows: используется штатный механизм Shadow Copy (VSS);
Для Linux: работает драйвер на уровне файловой системы;
Для обеспечения консистентности мы используем механизм Freeze (fsfreeze), который замораживает операции записи.
После подготовки данных начинается репликация, и содержимое файловой системы по сети передается на целевую площадку.
Консистентность данных и другие нюансы
Возможно, тут у вас возник вопрос: «А какие данные мы реплицируем? Те, что на диске, или те, что в памяти?». Вопрос правильный. Мы реплицируем только те данные, которые находятся внутри файловой системы вашей ВМ — на диске. Содержимое оперативной памяти не передается. Для полной консистентности приложений (например, баз данных) перед финальной дельта-синхронизацией вам необходимо остановить продуктивные сервисы (сервисы СУБД, веб-серверы и т.д.). Это заставит приложения сбросить буферы из памяти на диск, и мы успешно передадим эти данные.
Первый важный момент: в безагентском методе для финальной синхронизации Вы можете выключить ВМ, и система дописывает изменения с момента последней репликации. В агентском методе наоборот: выключать машину нельзя. Агент работает внутри запущенной операционной системы, если вы выключите ВМ, он остановится и не сможет передавать данные.
Второй важный момент: нужна прямая сетевая связность между исходной ВМ и контроллером репликации zVirt. В безагентском методе трафик шел через инфраструктуру гипервизоров, здесь же сама гостевая операционная система обращается напрямую к целевой площадке.
Как это все выглядит в интерфейсе
В интерфейсе zVirt появляется кнопка «Скачать внутренний агент». Вы можете добавить несколько исходных площадок для миграции. Их число зависит только от масштаба вашей задачи и разнообразия платформ, с которых вы переносите машины.
Нажимаете кнопку, выбираете операционную систему.
Для Windows:
Скачиваете MSI-пакет. Можно установить вручную или развернуть через GPO/SCCM для большого парка машин. При установке агент автоматически привязывается к вашей инсталляции zVirt. Список поддерживаемых версий доступен по ссылке.
Для Linux:
Из-за разнообразия ядер и дистрибутивов предлагаем два варианта установки драйвера:
Вариант простой: предварительно собранный пакет
Устанавливается быстро. Это бинарный пакет драйверов, которые мы предоставляем вместе с агентом. Не требует компиляторов, заголовков ядра и зависимостей.
Но есть нюанс: список поддерживаемых ядер ограничен теми, под которые собран модуль. Для стандартных Ubuntu LTS, CentOS, RedOS проблем нет. А вот если у вас кастомные ядра (например, защищенные образы со специфичными сборками), этот вариант не подойдет.
Вариант простой, но с установкой зависимостей: DKMS
Поддерживает практически любые ядра. Этот способ мы рекомендуем для систем, которые регулярно обновляются или не поддерживаются стандартным пакетом.
Пакет DKMS самостоятельно создаст необходимые компоненты при установке. Он имеет широкую поддержку ядер Linux и будет перестраивать драйвер при обновлении ядра. Для этого на машине должны быть установлены DKMS, средства сборки и заголовки ядра.
После установки агента ваша ВМ появляется в списке для репликации. Дальше процесс такой же, как в безагентском методе: выбираете машину, запускаете репликацию, ждете завершения.
Переезд P2V
Главный плюс агентского метода — в его универсальности. И он работает даже с физическими серверами. Разберу подробнее, как устроен P2V.
Раз агент работает на уровне операционной системы, ему все равно, запущена ли она на гипервизоре или на «физическом железе». Вы просто устанавливаете агент на физический сервер так же, как на ВМ. После установки он появляется в списке zVirt, и дальше все стандартно: запускаете репликацию, агент читает файловую систему и передает данные на целевую площадку.
Сценарий может быть интересен многим. Ведь часто есть какой-нибудь старый физический сервер с критичным приложением. Например, 1С на Windows Server 2008 R2 или самописное приложение с утерянными исходниками, то есть системы, которые рискованно переустанавливать. Агентский метод переносит их в виртуальную среду без изменений.
Какие еще улучшения добавили
В версии 4.5 мы доработали некоторые моменты на основе фидбека от заказчиков и пользователей. Во-первых, исправили работу с тонкими дисками. Раньше в zVirt диск приезжал со статусом «тонкий», но по факту в хранилище он занимал место как «предварительно размеченный». Теперь тонкие диски мигрируют корректно, оставаясь тонкими и на целевой платформе. Во-вторых, мы сняли ограничения на размер чанка в 2 ТБ. То есть на объем данных, который система передает за одну итерацию при репликации, теперь можно передавать большие объемы за раз.
Если вы уже мигрировали на новую платформу виртуализации, расскажите в комментариях, с какими проблемами столкнулись и что можно было бы улучшить. Ваш опыт и пожелания постараемся учесть в следующих релизах.
