Введение
После приобретения VMware компанией Broadcom и последующих изменений в лицензионной политике и модели ценообразования многие предприятия начали пересматривать стоимость и архитектуру используемых платформ виртуализации. Благодаря схожему с VMware подходу к управлению, гибкой модели лицензирования и поддержке формата VMDK, ZStack стал одним из вариантов для компаний, рассматривающих замену VMware.
Однако сама по себе замена платформы — только начало. На практике возникает гораздо более важный вопрос: как безопасно и с минимальным простоем перенести работающие виртуальные машины VMware в среду ZStack?
VMware и ZStack используют разные технологии виртуализации и виртуальное оборудование, включая различия в форматах виртуальных дисков и типах виртуальных устройств. Поэтому простого копирования виртуальной машины между платформами недостаточно. На практике можно выделить два основных подхода:
Вариант 1: использовать встроенный сервис V2V-миграции ZStack — нативное решение платформы.
Вариант 2: использовать Vinchin Backup & Recovery и выполнить кросс-платформенную миграцию по схеме «резервное копирование + восстановление».
У этих подходов нет однозначно лучшего или худшего варианта. Их ключевое различие заключается в архитектуре миграции и уровне защиты данных. В этой статье мы с практической точки зрения разберём оба подхода, их основные этапы, сценарии применения и важные моменты, которые необходимо учитывать перед миграцией.
Три контрольных списка перед миграцией: сначала изучите инфраструктуру
Многие проблемы при миграции возникают не из-за используемого инструмента, а из-за недостаточной подготовки. Перед началом работ рекомендуется проверить следующие три группы параметров.
Первый контрольный список: проверка исходной среды VMware
Работоспособны ли vCenter и все ESXi-хосты? Если в инфраструктуре есть критические предупреждения или ошибки, рекомендуется устранить их до начала миграции.
Проверьте версию операционной системы и уровень установленных обновлений на переносимых виртуальных машинах — это напрямую связано с совместимостью драйверов. Для V2V-миграции ZStack поддерживаются определённые версии гостевых ОС VMware, включая RHEL/CentOS 4.x–7.x, SLES 11/12/15, Ubuntu 12–18, а также Windows 7/2003/2008/2012/2016.
Проверьте версии vCenter и ESXi. ZStack поддерживает определённые версии vCenter, включая 5.0, 5.1, 5.5, 6.0, 6.5, 6.7 и 7.0; версия vCenter и используемая версия ESXi должны соответствовать требованиям совместимости ZStack.
Установлены и работают ли на виртуальных машинах VMware Tools?
Сколько фактически используется дискового пространства? Перед миграцией рекомендуется удалить ненужные данные, чтобы уменьшить объём переносимых данных и общее время миграции.
Используют ли приложения привязку к определённым характеристикам физического оборудования? Например, если лицензия приложения привязана к MAC-адресу, после миграции может потребоваться дополнительная настройка.
Второй контрольный список: планирование ресурсов ZStack
Достаточно ли CPU, оперативной памяти и дискового пространства в целевом кластере ZStack для размещения переносимых виртуальных машин? Рекомендуется предусмотреть дополнительный резерв ресурсов.
Созданы ли заранее целевые сети (VLAN/VXLAN)? Нет ли конфликтов IP-адресов?
Особое внимание: подготовлена ли лицензия на сервис миграции ZStack? Это является одним из предварительных условий для использования нативной V2V-миграции.
Соответствует ли версия vCenter вашей среды требованиям совместимости ZStack?
Третий контрольный список: управление рисками и план отката
Окно простоя: при использовании нативной V2V-миграции ZStack исходная виртуальная машина будет выключена. Система сначала пытается корректно завершить работу ВМ, а при неудаче выполняет принудительное выключение. Поэтому заранее согласуйте с владельцами сервисов допустимую продолжительность простоя.
Резервное копирование перед миграцией: перед переносом критически важных виртуальных машин VMware обязательно создайте резервную копию. При использовании Vinchin резервное копирование является частью самого процесса миграции. При использовании нативного V2V-решения ZStack рекомендуется дополнительно создать снимок или использовать механизм снапшотов на уровне системы хранения.
Критерии отката: заранее определите условия, при которых необходимо выполнить откат, например если виртуальная машина не запускается в течение 30 минут после миграции или уровень ошибок критических интерфейсов превышает 5%. Это позволит избежать хаотичных действий после возникновения проблем.
Вариант 1: миграция VMware с помощью нативного V2V ZStack
Сервис V2V-миграции ZStack предназначен для переноса виртуальных машин между платформами. Основная логика заключается в следующем: ZStack подключает vCenter, после чего сервер миграции получает данные виртуальной машины VMware, преобразует их и записывает в целевое хранилище ZStack.
Предварительное условие: подключение vCenter к ZStack
Первым условием для использования V2V-миграции ZStack является подключение VMware vCenter к платформе ZStack.
Для этого войдите в консоль управления ZStack, перейдите в раздел управления облачными ресурсами и добавьте vCenter, указав учётные данные администратора.
⚠️ Важно: после добавления vCenter обязательно выполните синхронизацию данных вручную, чтобы актуальное состояние ресурсов vCenter было синхронизировано с ZStack.
Развёртывание сервера миграции
Перейдите в раздел «Эксплуатация платформы → Сервис миграции → Сервер миграции» и добавьте физический сервер в качестве сервера миграции.
Основные параметры:
Тип: выберите платформу VMware.
Физический сервер: выберите подготовленный вычислительный узел в целевом кластере.
Путь к кэшу: во время миграции системные и пользовательские данные виртуальной машины сначала кэшируются на сервере миграции, а затем импортируются в основное целевое хранилище. Убедитесь, что по указанному пути достаточно свободного пространства для временного хранения данных миграции. В ZStack также предусмотрен режим сжатия, который позволяет уменьшить объём кэшируемых данных и повысить эффективность использования пространства.
Сеть миграции (необязательно): если инфраструктура позволяет, рекомендуется выделить отдельную физическую сеть для трафика миграции, чтобы он не конкурировал с управленческим и пользовательским трафиком.
Практический совет: сервер миграции должен находиться в целевом кластере и обладать достаточными аппаратными ресурсами для выполнения V2V-операций. Недостаток ресурсов сервера миграции может негативно повлиять на скорость и стабильность процесса.
Создание задачи миграции
В разделе «V2V Migration» создайте новую задачу и выберите исходные виртуальные машины. Можно выбрать несколько ВМ одновременно. Затем настройте параметры целевой среды:
CPU и оперативную память можно изменить на этом этапе.
В качестве основного хранилища выберите целевое хранилище.
Сопоставление сетей: сопоставьте порт-группы VMware с соответствующими виртуальными сетями ZStack.
После отправки задачи ZStack сначала попытается корректно выключить виртуальную машину VMware, после чего начнёт копирование данных. Если штатное выключение завершится неудачей, система выполнит принудительное выключение.
⚠️ Это холодная (офлайн) миграция. Во время миграции исходная виртуальная машина находится в выключенном состоянии. Поэтому заранее согласуйте окно простоя с владельцами бизнес-сервисов.
Для крупных инфраструктур рекомендуется выполнять миграцию партиями: например, сначала перенести 5–10 некритичных виртуальных машин, проверить результат и только после этого переходить к критически важным системам.
Ключевые рекомендации по миграции согласно официальной документации ZStack
Во время V2V-миграции нельзя включать остановленную исходную виртуальную машину в vCenter, иначе задача миграции завершится ошибкой.
Во время V2V-миграции нельзя перезапускать сервер миграции, иначе задача миграции завершится ошибкой.
Для виртуальных машин Windows Server 2012 R2/Server 2016 необходимо заранее вручную отключить режим гибернации и выключить виртуальную машину перед созданием задачи миграции. Используйте команду:
powercfg -h off
Если исходная виртуальная машина содержит дополнительный диск данных, заранее убедитесь, что режим диска установлен в «Зависимый» (Dependent), иначе задача миграции завершится ошибкой.
Для виртуальных машин Windows с дополнительными дисками после миграции диски будут находиться в автономном (Offline) состоянии. Необходимо вручную перевести их в онлайн-режим.
Для виртуальных машин Linux/Windows с дополнительными дисками после миграции буквы дисков или их порядок могут измениться. Необходимо вручную восстановить исходный порядок. Поэтому рекомендуется заранее зафиксировать конфигурацию дисков исходной виртуальной машины.
Если виртуальная машина Linux использует старую версию kernel (например, RHEL 6.2 с kernel 2.x), режим VirtioSCSI для диска данных может не поддерживаться. После миграции необходимо вручную изменить режим диска на несовместимый с VirtioSCSI.
Для виртуальных машин Linux на CentOS 7.4 и более поздних версиях с загрузкой через UEFI после миграции система может войти в UEFI Shell. Для успешной загрузки операционной системы потребуется выполнить соответствующие команды.
Рекомендация: перед началом миграции последовательно проверьте все перечисленные условия. Это позволит существенно снизить вероятность ошибок и повторных попыток миграции.
Проверка после миграции: запуск — не конец
После успешного создания и запуска виртуальной машины в ZStack выполните последовательную проверку:
Проверьте вход в операционную систему — с помощью локальной учётной записи или доменной аутентификации.
Проверьте диски и точки монтирования — в Linux проверьте /etc/fstab, в Windows — «Управление дисками». Если порядок дисков изменился, вручную восстановите его в соответствии с предварительно сохранённой конфигурацией.
Проверьте состояние дисков Windows — если дополнительные диски находятся в автономном режиме, вручную переведите их в онлайн-режим через «Управление дисками».
Проверьте сетевые интерфейсы и IP-адреса — после миграции виртуальной машины Windows необходимо вручную обновить драйвер сетевого адаптера. Драйвер Windows VirtIO уже установлен в локальном каталоге, поэтому его можно найти и обновить автоматически. Также обратите внимание, что IP-конфигурация может быть потеряна, поэтому рекомендуется заранее сохранить сетевые настройки исходной ВМ.
Проверьте автоматический запуск приложений — базы данных, middleware, веб-сервисы и другие критически важные приложения.
Решение проблем с драйверами: при V2V-миграции ZStack поддерживает автоматическую установку драйверов Windows VirtIO для виртуальных машин Windows, что повышает эффективность работы сетевых и дисковых устройств. Если после миграции возникли проблемы, связанные с драйверами, можно подключить ISO-образ с драйверами VirtIO к виртуальной машине через консоль ZStack и выполнить необходимую настройку. Для старых версий ядра Linux, не поддерживающих VirtioSCSI, следуйте рекомендации из пункта 7 выше.
Вариант 2: миграция с помощью Vinchin Backup & Recovery
Архитектура Vinchin существенно отличается от нативной V2V-миграции ZStack. Vinchin не требует предварительно подключать vCenter к ZStack. Вместо этого резервная копия используется в качестве промежуточного источника данных для кросс-платформенного восстановления виртуальной машины VMware в ZStack.
Общий процесс выглядит следующим образом:
VMware → хранилище резервных копий → восстановление в ZStack
Подготовка среды
Сначала убедитесь, что Vinchin Backup & Recovery развёрнут и поддерживает необходимые операции:
VMware vCenter или ESXi добавлен в качестве источника резервного копирования.
ZStack добавлен в качестве целевой платформы восстановления.
В хранилище резервных копий достаточно места для размещения полной резервной копии виртуальной машины VMware.
Выберите виртуальную машину VMware, которую необходимо перенести, и создайте задачу полного резервного копирования. После завершения убедитесь, что задача имеет статус «Успешно», и выберите соответствующую точку восстановления в цепочке резервных копий.
Практический совет: если виртуальная машина содержит большой объём данных, создание резервной копии может занять значительное время. Рекомендуется выполнять резервное копирование в период минимальной нагрузки и контролировать производительность хранилища резервных копий.
Создайте новую задачу восстановления и в качестве целевой платформы выберите ZStack:
Выберите точку восстановления из созданной резервной копии.
Укажите целевой кластер ZStack, хост и хранилище.
Сопоставьте сети: сопоставьте сеть VMware с существующей виртуальной сетью ZStack.
При необходимости измените конфигурацию целевой виртуальной машины, например количество CPU и объём оперативной памяти.
После запуска задачи Vinchin выполняет восстановление данных и адаптацию конфигурации виртуальной машины в соответствии с целевой средой ZStack. Пользователю не требуется вручную экспортировать или преобразовывать файлы виртуальных дисков.
Особенности данного подхода
Ключевое отличие от нативной V2V-миграции ZStack заключается в том, что источником данных для миграции является резервная копия виртуальной машины VMware, а не непосредственно работающая виртуальная машина.
Это даёт несколько преимуществ:
Если восстановленная виртуальная машина ZStack не запускается, её можно удалить, изменить параметры восстановления и повторить операцию — ошибка на целевой стороне не приводит к изменению исходной виртуальной машины VMware.
После завершения миграции Vinchin может продолжить защищать виртуальные машины в ZStack, обеспечивая единый жизненный цикл: защита VMware до миграции → защита данных в процессе миграции → дальнейшая защита ZStack после миграции.
Сравнение двух подходов
| Критерий | Нативная V2V-миграция ZStack | Миграция с помощью Vinchin |
|---|
| Основной принцип | Прямое преобразование между платформами | Кросс-платформенное восстановление из резервной копии |
| Предварительные требования | Необходимо подключить vCenter к ZStack и иметь лицензию на сервис V2V | Не требуется подключать vCenter к ZStack; необходимо подключить обе платформы к Vinchin |
| Режим миграции | Офлайн-миграция: исходная ВМ должна быть выключена | Восстановление из резервной копии: резервная копия используется как источник данных, исходная ВМ напрямую не участвует в процессе миграции |
| Возможность отката | Перед миграцией необходимо самостоятельно создать резервную копию или снимок | Точка восстановления уже является точкой отката и может использоваться для повторного восстановления |
| Защита данных после миграции | Требует отдельного планирования | Vinchin может продолжить защищать виртуальные машины ZStack |
| Пакетная миграция | Поддерживается | Поддерживается пакетное восстановление |
| Типичные сценарии | Массовая замена платформы, когда процесс миграции управляется непосредственно ZStack | Гетерогенная инфраструктура, длительное сосуществование платформ, необходимость комплексной защиты данных и минимизации рисков миграции |
Заключение
Миграция VMware в ZStack — это не простое «копирование и вставка», а полноценный инфраструктурный проект, требующий предварительного планирования. Выбор подхода в первую очередь зависит от ваших требований:
Если ваша задача заключается в полной и однократной замене VMware на ZStack, а также у вас уже определено окно простоя и подготовлен план отката, нативная V2V-миграция ZStack может быть наиболее прямым вариантом с минимальным количеством промежуточных компонентов.
Если VMware и ZStack будут длительное время использоваться одновременно, либо речь идёт о критически важных системах, таких как базы данных и ERP, и вам необходимо иметь резервную копию на каждом этапе миграции, подход Vinchin позволяет объединить миграцию и защиту данных в единый процесс.
В любом случае следует помнить главное правило: при миграции производственной инфраструктуры всегда оставляйте возможность вернуться к исходной конфигурации.
