Миграция с VMware на OpenStack без простоя инфраструктуры

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

Гипервизор VMware активно используется как крупными предприятиями, так и малым и средним бизнесом. Но все больше и больше клиентов задумываются о переносе своей инфраструктуры с VMware на другую платформу. Процесс миграции не так прост: необходимо приобрести совершенно новую платформу, заново создать архитектуру, а затем переконфигурировать и хосты, и рабочие нагрузки… Однако уже сегодня можно перейти с VMware на OpenStack в автоматическом режиме всего за несколько недель при минимальном времени простоя.

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

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

ПРОЕКТ МИГРАЦИИ

Один из проектов миграции с VMware на OpenStack был реализован для быстрорастущей итальянской компании, которая внутри своей инфраструктуры использовала VMware, а некритичные рабочие нагрузки размещала на мощностях нашего партнера, чешского провайдера Host-Telecom. На платформе VMware vSphere были развернуты 152 виртуальные машины с различными типами рабочих нагрузок: высокопроизводительные, транзакционные, базы данных и корпоративные.

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

ИТ-ИНФРАСТРУКТУРА

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

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

К тому же бизнес-приложения работали с конфиденциальными данными, поэтому на гостевые операционные системы и виртуальные машины не разрешалось устанавливать стороннее программное обеспечение. Репликацию приходилось делать с помощью внешних инструментов. Крайне важно было не вносить изменения в данные клиента. Для этого делались мгновенные снимки (см. подробнее раздел «Миграция в деталях»).

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

МЕХАНИКА РАБОТЫ

Сначала надо было собрать информацию об инфраструктуре и рабочих нагрузках. Далее мы обсудили с клиентом технические детали и общие вопросы сотрудничества. После этого пришла очередь подготовки проекта для проверки концепции (Proof of Concept, PoC, или прототип) и проработки сценариев миграции.

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

Весь проект занял 45 человеко-часов (учитывалась реальная занятость только архитектора и инженера, но не службы поддержки) и четыре недели времени, включая перенос всей рабочей нагрузки в облако OpenStack и кастомизацию решения по восстановлению после аварий (Disaster Recovery as a Service DRaaS). В эти четыре недели уложились, в частности, все согласования с клиентом.

Время простоя приложений было минимальным. Всего предусматривалось только одно окно обслуживания — около 3 часов. Для управления инфраструктурой и обучения работе с ним был реализован доступ к порталу самообслуживания. В итоге удалось добиться более высокой производительности, чем при использовании VMware.

СЦЕНАРИЙ МИГРАЦИИ

В процессе подготовки к миграции требовалось работать в тесном контакте с технической командой заказчика, чтобы понять топологию его бизнес-приложений и зависимости между различными компонентами. Предварительно в облаке Host-Telecom была создана необходимая сетевая инфраструктура: сначала развернуты агенты миграции, которые реплицировали компоненты бизнес-приложения и отправляли данные в хранилище, на сторону OpenStack. При этом был полностью настроен процесс репликации — в частности, задана периодичность создания копий и определена продолжительность хранения снимков.

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

МИГРАЦИЯ В ДЕТАЛЯХ

Миграция с VMware на OpenStack состоит из нескольких этапов:

  • репликация данных;
  • размещение снимков (snapshot) виртуальных машин в облачном хранилище;
  • трансформация virtual to virtual;
  • оркестрированный запуск миграции;
  • тестирование.

Миграция с VMware на OpenStack состоит из нескольких этапов.

Для репликации на каждом из хостов ESXi была развернута небольшая ВМ с ОС Ubuntu (всего 14 хостов ESXi). Эта виртуальная машина изучала конфигурации узла снаружи и реплицировала все машины вокруг. Она отслеживала изменившиеся блоки с помощью стандартного API-интерфейса (VMware Changed Blocks Tracking для создания снимков и дельт) и отправляла их в OpenStack. Копирование метаданных о ЦПУ, оперативной памяти и сетевых настройках помогло впоследствии организовать оркест рацию на стороне OpenStack. Мы реплицировали инфраструктуру, стремясь одновременно максимально автоматизировать процесс, поэтому эти данные были заимствованы из сущес твующей среды VMware.

Для хранения снимков использовалось объектное хранилище с S3-подобными API (Ceph или Swift). Копии размещались таким образом, чтобы каждая копия, полученная со стороны VMware, была отдельным объектом в хранилище, — это позволяет осущес твить дедупликацию.

V2V-трансформация стала важнейшей частью всего процесса переноса данных с VMware на OpenStack. Чтобы клиент мог перейти на KVM, для поддержки новой платформы пришлось внедрять драйверы VirtIO, сохранив те же настройки сети, что и в ESX. Это важно, потому что ESX и KVM читают и применяют сетевые настройки по-разному. Если просто поместить одну ВМ из VMware в KVM, ничего, кроме несоответствия сети, при ее загрузке не будет. Для сохранения сетевых настроек необходимо выполнить переконфигурацию и внедрить сетевые адаптеры в одни и те же виртуальные слоты.

КАК СОЗДАЕТСЯ МИГРАЦИОННЫЙ ПЛАН

Миграционный план подобен сценарию. Это jsonфайл, в котором хранится вся информация о виртуальных машинах, которые мы хотели бы развернуть (о процессорах, портах, IP-адресах, MAC-адресах и т. д.), а также об оркестрации и зависимостях между виртуальными машинами. Json-файл преобразуется в шаблоны Heat. Причем мы не используем и не требуем использовать Heat, установленный в составе целевого облака OpenStack. Вместо этого применяется ответвление («форк») проекта Heat, работающее в составе нашего продукта и адаптированное для поддержки не только OpenStack, но и других типов облаков.

Для каждой виртуальной машины автоматически запускается трансформация virtual to virtual. Мы создаем диск iSCSI для объектного хранилища, где собираемся размещать снимки, и создаем регулярные логические тома.

Последний шаг — организация нескольких тестовых миграций (для итальянской компании мы провели две миграции), чтобы убедиться в корректности работы облака. Далее выполняется последняя синхронизация с платформой на OpenStack, загружаются все виртуальные машины на OpenStack и изменяются записи DNS. После этого клиенты переключаются с VMware на OpenStack.

ЗАКЛЮЧЕНИЕ

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

tinedol2