Новый уровень свободы: миграция в zVirt с любой платформы

• Павел Князькин, архитектор, Orion soft

Сегодня я расскажу о миграции с разных платформ виртуализации, в том числе и о миграции физических серверов, к нам в zVirt.

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

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

Можно воспользоваться платными решениями, есть «Хайстекс», есть MIND. Пару тысяч «виртуалок» оплачиваем и переезжаем, все будет красиво.

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

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

К чему я это рассказываю? 26% бизнеса Orion soft в 2024 году — это замещение импортозамещения, как бы это ни звучало. Многие пытаются перейти и с российских платформ виртуализации в zVirt. Эти довольно большие цифры говорят о том, что заказчики сталкиваются с трудностями перехода. Нужно решать эти трудности.

Сегодня мы будем говорить о двух подходах к миграции. Первый — это безагентский из VMware, который есть у нас начиная с версии 4.1. И новый — агентский, про который сегодня подробно расскажу и покажу.

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

Основной акцент сегодня будет на агентском способе, но и безагентский тоже немного затронем. Возможно, кто-то еще с ним не сталкивался. Но и в целом подходы агентского и безагентского будут очень похожи. Повторюсь, в версии 4.5 будет доступна возможность переезда любых виртуальных машин из любых платформ виртуализации. Зарубежные, условно Xen, Hyper-V, VMware, российские, Space, Rasa, Red и так далее — любая платформа виртуализации подойдет.

Первый способ — безагентский. Подходит для конвертации только из VMware. Он присутствует у нас начиная с версии 4.1. Как это выглядит? У вас будут заранее подготовленные виртуальные машины — агент-отправитель, контроллер конвертации и агент-приемник.

Слева устанавливается заранее подготовленная виртуальная машина — агент-отправитель. Вы стартуете ее, указываете ее FQDN и ее IP-адрес, и она работает на платформе VMware. Также вы создаете пользователя, который будет работать и будет подключен к нам в платформу zVirt. Он необходим для работы с API. Далее разворачиваете контроллер и агент, тоже стартуете их. Это заранее подготовленные образы. У них у всех есть свое назначение. Не будем на этом останавливаться, я думаю, что уже многие знакомы.

Как происходит дальнейшая работа? Вы видите в zVirt актуальный список из виртуальных машин, которые есть в VMware. Создали новую «виртуалку» — увидели ее в списке в zVirt, удалили — она также будет удалена из списка.

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

Дальше вы смотрите, что репликация завершилась. Тут есть два варианта. Вы можете произвести дорепликацию изменений, которые произошли с последней реплики, отключив ее. Либо, если изменений не было, можно ее не отключать.

И далее запускаете процесс конвертации. Для вас он тоже достаточно простой. Вы указываете IP-адрес будущей машины. Если его не нужно, можно сделать по DHCP. Запускаете процесс конвертации. Мы автоматически добавляем драйвера VirtIO, VirtIO SCSI. Мы заменяем загрузочную область, если это необходимо при работе с теми или иными операционными системами. И через условные 5-10 минут у вас появляется сконвертированная виртуальная машина.

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

Это конвертация из VMware.

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

Что делает агент-отправитель? Он обращается внутрь вашей файловой системы и считывает данные дисков с помощью специального драйвера. Для Windows — это механизм Shadow Copy, для Linux — это драйвер на уровне файловой системы. Для консистентности мы используем механизм Freeze.

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

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

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

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

Как это будет выглядеть у нас в интерфейсе zVirt? Cправа появится новая кнопочка «Скачать внутренний агент», также здесь будет возможность добавить множество площадок. У вас их может быть очень-очень много, в зависимости от того, сколько вы хотите перевести виртуальных машин из каких платформ виртуализации.

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

Для Windows все просто. Мы скачиваем, выбираем тип агента Windows и устанавливаем его на операционную систему.

Для Linux может существовать два варианта. Это могут быть DKMS (драйвер создается во время установки), и предварительно собранный пакет. Проговорим про каждый из них последовательно и по очереди.

Первый метод простой. Это предварительно собранный пакет драйверов, который мы предоставляем вам вместе с агентом. На следующем шаге, если мы нажмем «Далее», то мы сможем его скачать. Этот метод не требует никакой установки дополнительных зависимостей, вы лишь устанавливаете сам агент. Но список поддерживаемых ядер будет все-таки ограничен. У нас есть коллега Михаил, он умеет самостоятельно собирать ядро из исходников. Если вы вдруг так же умеете, то этот метод, скорее всего, вам не подойдет. И если это вдруг какая-то специфичная версия, например, вы взяли образ Kaspersky с какой-то самосборной операционной системой и самосборным ядром, такой метод вам не подойдет.

Но для таких сложных инсталляций есть у нас метод с установкой зависимостей, и называется он DKMS. Пакет DKMS самостоятельно создает необходимые компоненты при установке, имеет огромную, очень широкую поддержку ядер и может перестраиваться при обновлении вами ядра. Условно, вы обновили Linux, у вас появилось новое ядро, и драйвер автоматически перестроит работу под это новое ядро. Этот метод мы будем рекомендовать тем, кто часто обновляется и не может воспользоваться предварительно собранным пакетом. Но здесь потребуется дополнительная установка пакетов. Вам будет указано, какие пакеты необходимо установить.

Далее, после установки агента, наша виртуальная машина, как и в безагентском методе, появится в списке для репликации.

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

Какие же преимущества нашего агентского метода? Самое первое — поддержка широкого спектра платформ виртуализации и операционных систем. Это могут быть и более старые, и более новые операционные системы. Это может быть любая платформа виртуализации. Главное — сама операционная система, которая есть внутри.

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

Поддерживается миграция настроек самой гостевой операционной системы.

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

Также добавлю, что в релизе 4.5 мы исправили работу с тонкими дисками. Возможно, если кто-то уже пользовался нашим методом, знает о том, что в zVirt диск приезжал тонкий, он отображался как тонкий, но размер его был как у предварительно размеченного диска. Мы этот момент поправили. Этого в релизе 4.5 больше нет, и это будет работать так, как задумано изначально.

Также было ограничение на работу с чанками в 2 Гб. Коллеги сталкивались с этой проблемой, мы ее полностью устранили, и теперь такого ограничения тоже нет. Это, я думаю, порадует многих.

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

Демонстрация (18:35-21:35)