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

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

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

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

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

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

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

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

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

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

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

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

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

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

Весь проект занял 45...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF