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

Меня зовут Павел Зимин. Я системный инженер в VK Cloud. Этой статьей мы начинаем серию публикаций о правильной и безопасной миграции компонентов виртуальной инфраструктуры между облаками, в которой дадим пошаговые алгоритмы и подсветим возможные нюансы. 

И начнем с миграции виртуальных машин — рассмотрим на примере переезда из AWS в VK Cloud, как подготовиться, какой стек использовать и что конкретно делать.

Подготовка к миграции: чек-лист и план миграции

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

В своей практике мы выработали простой чек-лист из обязательных этапов подготовки. 

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

• Аудит сети. Важно определить топологию целевой сети: учесть внешние IP-адреса и проверить пропускную способность канала. От этого зависит скорость миграции. Также подобный аудит дает возможность пересмотреть существующую топологию и строить на новой платформе уже оптимизированную реализацию.

• Оценка объема данных. Здесь определяем количество мигрируемых дисков и их параметры.

• Создание бэкапов. Для многих очевидный, но от этого не менее важный этап. Резервная копия нужна на случай, если в процессе миграции что-то пойдет не так.

После этого можно переходить непосредственно к проработке и планированию миграции. Здесь также есть обязательные, на наш взгляд, этапы.

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

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

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

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

При этом сама миграция состоит из трех основных стадий:

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

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

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

От теории к практике: подготовка инфраструктуры

Теперь от обзора общих принципов перейдем к практике.

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

Для контекста немного о ней.

В нашей демоинфраструктуре есть:

• балансировщики;

• кластер Kubernetes;

• база данных PostgreSQL;

• объектное хранилище S3;

• внешние и внутренние пользователи (внутренний работает с ВМ напрямую, а внешний — через балансировщик);

• инстансы ВМ (EC2 Instance в терминологии AWS) с Windows и Linux.

Примечание: Подобную инфраструктуру можно считать типовой, поэтому мы будем ее использовать и в следующих статьях серии при описании принципов миграции Kubernetes, БД и S3.

В рамках обзора понимание исходной инфраструктуры важно только для того, чтобы выстроить аналогичный ИТ-ландшафт в облаке VK Cloud. 

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

Инструмент для миграции

В качестве основного инструмента для репликации и миграции ВМ мы используем «Хайстекс Акура», который есть в маркетплейсе VK Cloud. Это автоматизированное ПО, с помощью которого можно перенести ИТ-инфраструктуру в VK Cloud в режиме реального времени без остановки рабочих нагрузок на ней. Инструмент позволяет переносить все типы рабочих мощностей и приложений как с виртуальных, так и с физических платформ.

Одно из преимуществ «Хайстекс Акура» — широкая совместимость. Так, инструмент поддерживает OpenStack, VMware, Amazon Web Services, Google Cloud Platform, Microsoft Azure, Oracle Cloud, Alibaba Cloud, Hyper-V, а также платформы российских провайдеров. 

Более того, миграция выполняется бесплатно — тарифицируется только инфраструктура, которая нужна для функционирования агента «Хайстекс Акура».

Миграция виртуальных машин

Итак, приступим к пошаговому описанию алгоритма миграции.

Заходим в личный кабинет VK Cloud. Переходим в раздел «Виртуальные сети» и подраздел «Сети». Создаем сеть. 

Для примера называем ее demo и присваиваем маску (диапазон адресов) 24 (10.0.0.0/24). Мы будем использовать ее в качестве целевой.

Далее подключаем «Хайстекс Акура» в облаке VK Cloud. После установки на почту приходит ссылка на личный кабинет «Хайстекс Акура», логин и пароль от него. Из этого личного кабинета будет выполняться большинство действий по миграции.

Переходим по ссылке из письма и авторизуемся в личном кабинете «Хайстекс Акура». Заходим в раздел Migrate.

Здесь в интерфейсе все интуитивно понятно. Один из ключевых элементов для миграции — панелька визарда, на которую вынесены все шаги миграции:

1. Установка репликационных агентов.

2. Конфигурирование репликационных настроек.

3. Запуск репликации ВМ.

4. Создание миграционного плана.

5. Запуск ВМ на новой платформе.

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

Итак, перейдем непосредственно к миграции в соответствии с вышеупомянутыми шагами.

Установка репликационных агентов

В «Хайстекс Акура» есть два вида агентов:

1. Внешние (устанавливаются на гипервизор) — для VMware и OVirt.

2. Внутренние (ставятся непосредственно внутрь ВМ) — для Windows и Linux.

В нашем случае доступна работа только с внутренними агентами. Причина в том, что для работы с внешними агентами надо иметь доступ к облачному гипервизору и его администрированию. Поэтому этот вариант отпадает.

В нашей исходной инфраструктуре две ВМ — на Windows и Linux. И «Хайстекс Акура» закрывает эти сценарии.

Начнем с установки агента на ВМ под управлением Windows, развернутую в облаке AWS.

1. На панели визарда на главном экране «Хайстекс Акура» нажимаем Install replication agents. Выбираем Windows и жмем Next.

   

2. Здесь предлагается выбрать группу машин. В рамках нашего примера оставляем значение по умолчанию. Жмем Next.

   

3. Нажимаем Download Agent и копируем ссылку на скачивание агента.

   

4. Подключаемся к ВМ на Windows в облаке AWS и скачиваем агент «Хайстекс Акура» по полученной ранее ссылке. Важно: машина должна иметь доступ в интернет или для нее должно быть настроено копирование данных через прокси-сервер.

5. Устанавливаем агент, используя подсказки инсталлятора.

   

6. После установки агента на ВМ возвращаемся в личный кабинет «Хайстекс Акура», где ВМ уже видна в списке на миграцию со статусом Discovered.

   

7. Открываем меню Action для данной ВМ и выбираем Start Replication — запускаем репликацию.

   

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

Пока выполняется репликация, можем заняться второй ВМ — в этот раз на Linux. Алгоритм для нее несколько отличается.

1. На панели визарда на главном экране «Хайстекс Акура» нажимаем Install replication agents. Выбираем Linux и жмем Next.

   

2. Далее нам предлагается выбрать группу машин (оставляем Default) и тип дистрибутива — на выбор доступны Ubuntu и CentOS. Выбираем Debian/Ubuntu (.deb package). Также можно выбрать тип драйвера — доступен большой перечень предварительно собранных драйверов под разные конфигурации, а также есть возможность собрать агента непосредственно на машине. Выбираем второй вариант (DKMS): он предпочтительнее, поскольку системы могут часто обновляться и версии ядер могут отличаться. Поэтому практичнее выполнять сборку агента непосредственно на ВМ. Нажимаем Next.

   

3. После этого мы попадаем на страницу, где доступна ссылка на скачивание агента и подробные инструкции с пошаговым описанием необходимых действий.

   

4. Подключаемся к ВМ с Linux в облаке AWS.

   

5. Начинаем установку агента. Для этого, согласно предложенной чуть раньше инструкции, устанавливаем дополнительные пакеты, чтобы собрать агент на этой машине. Важно: тут и далее нужную команду можно просто скопировать из интерфейса «Хайстекс Акура».

   

6. Далее, используя предложенную команду, запускаем скачивание агента для его сборки. В нашем случае версия ядра 5.15.0-1055.

   

7. После скачивания запускаем установку агента.

   

8. Дожидаемся запуска агента и подтверждения об успешном завершении установки.

9. Переходим в личный кабинет «Хайстекс Акура», где ВМ уже видна в списке на миграцию со статусом Discovered. 

10. Открываем меню Action для данной ВМ и выбираем Start full Replication — запускаем репликацию.

Конфигурирование репликационных настроек

После подготовки агентов через интерфейс «Хайстекс Акура» можно настроить дополнительные параметры репликации. Для этого открываем меню Action для данной ВМ и выбираем Edit Replication schedule.

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

Создание плана миграции

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

Создание плана миграции обязательно, поскольку к текущему моменту мы скопировали только диски, а нам нужно описать параметры ВМ, с которыми они будут созданы в VK Cloud: CPU, RAM, сеть и другие.

Для этого на странице миграции в «Хайстекс Акура» нажимаем Bulk actions и выбираем пункт Generate Migration plan.

Здесь через интерфейс с помощью подсказок можно легко назначить для ВМ флейвор (конфигурацию), сеть, подсеть и IP-адрес.

Примечательно, что совсем не обязательно вручную настраивать эти параметры для каждой отдельной ВМ: «Хайстекс Акура» позволяет эти процессы автоматизировать. Так, для продвинутых пользователей здесь также есть возможность через вкладку Expert загрузить уже подготовленный план миграции со всеми параметрами для всех мигрируемых ВМ. 

Также у «Хайстекс Акура» есть REST API, через который, используя скрипты, можно автоматизировать большинство выполняемых нами действий.

После настройки плана миграций для обоих ВМ (на Linux и Windows) присваиваем плану название. 

После этого запускаем непосредственно создание ВМ в облаке VK Cloud.

Статус создания ВМ также можно отслеживать через интерфейс «Хайстекс Акура».

Скорость создания ВМ во многом зависит от объема данных. Это нужно учитывать при планировании технических окон.

Проверка и запуск ВМ

После завершения подготовки ВМ также в интерфейсе «Хайстекс Акура» будет отображен соответствующий статус (Active).

Для проверки ВМ переходим в личный кабинет VK Cloud, раздел «Облачные вычисления» и подраздел «Виртуальные машины», где уже создана ВМ на базе Linux. 

Отсюда же (через интерфейс VK Cloud) можно не только посмотреть общую информацию о виртуальной машине, но и напрямую подключиться к ней через консоль.

ВМ на Linux готова — можно вводить логин и пароль и работать.

С ВМ на Windows аналогичная история: после завершения создания ВМ в «Хайстекс Акура» она будет отображена в перечне машин в личном кабинете VK Cloud, и к ней также можно будет подключиться.

Что в итоге

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

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

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

В следующих материалах серии мы рассмотрим алгоритм миграции Kubernetes, баз данных и объектного S3-хранилища. Оставайтесь с нами!

VK Cloud предлагает российским компаниям помощь в переходе на безопасную облачную платформу отечественного провайдера. В течение 2 месяцев наши клиенты могут оценить преимущества платформы VK Cloud бесплатно. Для этого достаточно оставить заявку и отправить нам чек об оплате сервисов Microsoft Azure, AWS или Google Cloud за февраль 2024 года.

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