Накануне я писал о разработке методики для тестирования функционала и производительности средств миграции между гипервизорами. В первую очередь она нацелена на миграцию с использованием ПО резервного копирования, только по тому что этот вопрос сейчас волнует меня больше всего.
Из доступных средств которые приходят на ум стоит рассмотреть миграцию с использованием утилиты virt-v2v но она не поддерживает работу с esxi хостами на прямую, насколько я знаю ей нужен vCenter.
Я бы хотел сформулировать несколько выводов по полученным на текущий момент результатам тестирования миграции между vCenter и Росплатформой.
Самое первое что бросается в глаза это необходимость выключения машины для сбора образа Клонзилой. Это логично если знать что данное ПО представлено в виде LiveCD. Но с другой стороны возможно правильным будет выключить исходную машину в любом случае для предотвращения изменений на время миграции. Этот минус можно считать не существенным.
Клонзилла позволяет использовать сценарии выполнения, которые я не использовал, возможно это существенно сократит количество рутинных ручных операций. Но на текущий момент использование централизованного бэкапа всей платформы виртуализации целиком значительно упрощает процесс.
Клонзилла не имеет функционала разностного / инкрементного копирования. Не смотря на то, что как показали тесты инкрементное восстановление среди рассмотренных продуктов не возможно, инкрементный бэкап может существенно сократить окно простоя так как позволит выполнить быстрый инкрементный бэкап после начала downtime а не дожидаться полной копии.
Акронис в отличие от клонзилы и virt-v2v не позволяет копировать данные сразу же на место их бедующего хранения. Например Клонзилла позволяет как сохранить файлы на диск, так и установить тоннель 1к1 для одновременного восстановления целевой виртуальной машины.
Тест показал что акронис очень легко справляется с псевдослучайным набором данных и отлично их сжимает. В связи с этим мне пришлось расширить методику “вторым туром” для тех решений кто слишком хорошо упаковывает данные. Поэтому после создания псевдослучайного файла объемом 64 ГБ время бэкапа виртуальной машины практически не увеличилось.
Акронис дедуплицирует данные в рамках одной резервной копии (в рамках одной машины), поэтому время восстановления может быть существенно ниже клонзиллы, которая если честно не особо вникает что именно копирует и может разве что применить к файлу образа сжатие.
Такого понятия как инкрементное восстановление с LiveCD у акронис и у клонзиллы не существует. Время восстановления совершенно не зависит от наполнения виртуальной машины. Хотя такая функция поддерживается акронисом для виртуальных машин со включенной технологией VMware CBT
1), похоже аналог в Windows отсутствует. Данный вопрос требует детального изучения.
Итоговый вывод можно сделать следующий:
Если на предприятии используется централизованное ПО резервного копирования с возможностью восстановления через LiveCD или с наличием механизма BareMetall Restore я рекомендую начать с него, так как скорее всего сжатие дедупликация и инкрементное копирование позволят сократить время простоя.
Клонизилла пуленепробиваемый бесплатный метод резервного копирования и восстановления который может быть использован так же для переноса содержимого виртуальных дисков без погружения в детали конвертирования образов и интеграции с vCenter. Но в больших объемах я бы не стал его использовать, можно рекомендовать как вариант на случай если все остальные способы провалились. И забыл отметить что у клонзиллы нет зависимостей и время подготовки к миграции минимальное. Требуется только скачать LiveCD и можно начинать.