Тема миграции корпоративной IT-инфраструктуры с VMware vSphere на OpenStack активно обсуждается в русскоязычном сегменте глобальной сети. Часто споры сторонников и противников открытых решений носят религиозный характер, в сухом остатке главный аргумент за — отсутствие лицензионных отчислений. С другой стороны, основанную на открытом коде платформу критикуют за незрелость и фактическое отсутствие готового к употреблению в корпоративном сегменте продукта. Мы постараемся избежать обсуждения абстрактных облаков в вакууме и расскажем об имеющем практическую ценность сценарии перехода на OpenStack.
Кому это нужно?
Для начала нарисуем портрет типичного заказчика: обычно это средняя или крупная компания, имеющая инфраструктуру на решениях VMware. Это может быть корпоративный ЦОД, оборудование в арендованных стойках, инфраструктура как сервис (IaaS) и т.д. Деятельность потенциального заказчика зависит от IT, но IT не является его основным бизнесом. Стоимость лицензий VMware высока и поэтому вопрос снижения издержек стоит достаточно остро. Деньги здесь — очень важный фактор, но часто его перекрывают сложность миграции и специфика поддержки. Цену лицензий на проприетарное ПО руководители компании оправдывают уменьшением рисков, а сотрудники IT-департамента не всегда уверены в своих силах и рады переложить на вендора персональную ответственность за инфраструктуру хотя бы частично.
Ситуация меняется, когда простое резервное копирование уже не обеспечивает приемлемую скорость восстановления доступа к данным: даже полчаса простоя IT-инфраструктуры авиакомпании или крупного онлайн-ритейлера ведут к серьезным репутационным и финансовым потерям. Заказчику приходится думать о необходимости наличия резервной площадки и разработке плана восстановления после сбоев (disaster recovery plan, DRP). Если посмотреть статистику поисковых запросов, эта тема особенно актуальна для западных стран, но и в русскоязычном сегменте интернета ею начинают интересоваться.
Создание резервной площадки и внедрение DRP требуют увеличения затрат, что вызывает у владельцев бизнеса естественное желание сэкономить. Заказчику приходится выбирать между необходимостью снова нести деньги вендору и моделью DRaaS (Disaster Recovery as a service) на базе решений с открытым кодом — во втором случае цена вопроса ниже, но для принятия решения техническому директору компании нужен определенный уровень уверенности в своих силах. Разумеется, бросить нажитое за долгие годы и стройными рядами бежать на OpenStack согласятся только энтузиасты, более разумный подход предполагает последовательное движение с минимумом рисков и с вложениями, не сопоставимыми с текущими бюджетами. Здесь решения OpenStack имеют ряд преимуществ перед коммерческими продуктами — ниже мы расскажем о главных из них.
Резервная площадка с минимальными рисками
Для внедрения решения Disaster Recovery на базе OpenStack не придётся отказываться от привычной инфраструктуры. Используемая платформа продолжает работать, но появляется резервная площадка, на которую можно переключиться за минуты, минимизировав потери бизнеса в случае простоя основной.
Если вы хотите делать DR на решениях VMware, нужно в полном объёме оплатить ещё один комплект лицензий, купить VMware Site Recovery Manager (он обеспечивает синхронизацию данных и статусов критически важных приложений) и постоянно тратить деньги на поддержку. Построение новой площадки на технологиях OpenStack существенно снижает расходы, не влияя на работоспособность основной инфраструктуры: вы в любом случае уменьшаете риски, притом, по минимально возможной цене. Особенно если отдать резервную инфраструктуру на аутсорсинг сервис-провайдеру: покупая услугу DRaaS на основе открытых решений, заказчик заплатит один раз там, где за VMware придется платить трижды.
Снижение расходов на тестирование
Когда DR-площадка запущена, большую часть времени она стоит без дела (предполагается, что основная площадка работает более или менее стабильно) и служит своего рода страховкой. Держать её в пассиве бессмысленно, вполне логичным решением будет использовать резерв в качестве полигона для нагрузочного тестирования новых приложений в идентичном основному окружении. Тут уже идёт прямая экономия (а если резервная площадка отдана на аутсорсинг, то вы платите только за фактически используемые ресурсы) и достоверность тестирования будет максимально близкой к стопроцентной. Этого практически невозможно добиться в иных случаях, особенно если речь идёт о распределённых системах: создание идентичного рабочему тестового кластера стоит недёшево, тут же он постоянно наготове.
Если не видно разницы, зачем платить больше?
Дальше заказчик приходит к ситуации, когда у него есть площадки на VMware и OpenStack, а персонал IT-департамента имеет необходимую квалификацию для взаимодействия с обеими. Возникает закономерный вопрос: если в построенной на OpenStack инфраструктуре работают критически важные для бизнеса приложения, зачем платить за лицензии VMware?
Можно уйти от лицензионных платежей, оставив только сервисные выплаты, которые в случае с VMware все равно присутствуют — по сути DR-площадка является переходным звеном к полноценной миграции на OpenStack.
Сложности перехода
Перенос виртуальных машин с построенной на решениях VMware инфраструктуры в облако OpenStack — непростая техническая задача. До недавнего времени это сдерживало многих заказчиков, однако технология не зависящего от окружения автоматизированного трансфера уже доступна на российском рынке. Разработанная российской компанией Hystax платформа Acura позволяет без особых трудозатрат решать проблемы репликации, аварийного восстановления, а также миграции виртуальных машин и бизнес-приложений в частных облаках.
Технологическая зрелость
Отчасти критики правы, OpenStack нельзя назвать продуктом, скорее это набор кубиков, из которых можно построить инфраструктуру. Но если раньше каждый такой кубик нужно было обработать напильником для совместимости с остальными, то после выпуска релиза Mitaka ситуация переменилась: OpenStack в целом стал более стабильным и, если можно так выразиться, более продуктовым. Сейчас это скорее фирменный набор Lego, из которого без особых проблем собирается что угодно. Заказчику даже не нужны собственные компетенции в области OpenStack, поскольку на рынке доступны решения IaaS — сервис-провайдеры охотно предоставят ему созданную по индивидуальным запросам инфраструктуру под ключ и с оплатой только за фактически потребляемые ресурсы.
Богатый выбор вариантов развёртывания
Если у заказчика уже развёрнута инфраструктура на VMware, наверняка у него есть и своё оборудование, отказ от которого при полноценной миграции на OpenStack не имеет смысла. Есть разные способы решения этой проблемы: в процессе перевода основной площадки на OpenStack можно передать оборудование на colocation и сэкономить на обслуживании инженерной инфраструктуры. Если же заказчик уже вложился в корпоративный ЦОД, создать площадку можно и в собственных помещениях — многие предлагающие инфраструктуру в аренду провайдеры работают и как системные интеграторы, помогая клиентам реализовать гибридные варианты развертывания. К этой теме мы ещё вернёмся в следующих публикациях.
Итоги
Поэтапный вариант перехода с VMware на OpenStack оптимален, только он позволяет заказчику на каждом шаге уменьшать риски для бизнеса за минимально возможную цену. Начать процесс стоит с внедрения решения Disaster Recovery и создания полноценной резервной площадки. Но важно понимать, что DR — это не просто набор технологий, а в первую очередь сценарий, как и другие облачные решения. Здесь правильнее говорить скорее о логике, чем о программировании в чистом виде и основной задачей становится составление DR-плана, который в дальнейшем может служить и как план миграции. Что поднимается первым, что поднимается во вторую очередь, как отрабатывают виртуальные машины первой очереди запуск виртуальных машин второй очереди и т. д. и т. п. Решением этих практических вопросов мы займёмся в следующих статьях цикла — к сожалению, на русском языке подобных публикаций в сети почти нет.