Когда вышла первая публикация на Хабре по теме DRaaS и миграции с VMware, организованных на базе OpenStack, в комментарии пользователя mikkisse была озвучена мысль: единственное очевидное преимущество решений на базе OpenStack — это их относительно низкая стоимость в сравнении с коммерческими предложениями. Другие пользователи (например, AntonVirtual) аккуратно (и не очень) намекали на то, что отсутствие лицензионных платежей придется компенсировать оплатой поддержки, которая обеспечила бы стабильность работы облака. А раз так, замечали третьи (такие как omnimod), лучше не экспериментировать, а отдаться старому-доброму вендору. Мы, в свою очередь, в комментариях обещали подробный рассказ о том, как именно реализуется миграция и/или DR с технологией Hystax Acura в обмен на благосклонное внимание mikkisse и других читателей, давших нам содержательную обратную связь. Выполняем взятое на себя обязательство.

DRaaS (Disaster Recovery as a Service): что это и зачем?

Эта услуга нужна большинству современных компаний, в которых автоматизированы бизнес-процессы. Если вашу серверную затопит, ИБП сгорит, а на город обрушится ураган, и только огоньки ЦОДов будут служить ориентирами в кромешной тьме, вам, очевидно, приятно будет осознавать, что резервные копии данных, которые вы наверняка делаете, в определенном порядке будут развернуты в прохладном уюте серверного зала одного из таких дата-центров. Disaster Recovery включает в себя как план восстановления инфраструктуры (который создается совместно специалистами сервис-провайдера и компании-заказчика), так и саму резервную площадку, и механизм восстановления.


Технически процесс Disaster Recovery организован также, как сервис миграции данных. На стороне сервис-провайдера создается резервная площадка, дублирующая (но не копирующая!) инфраструктуру клиента, — копируются виртуальные машины, связи между ними, сетевые настройки. Но сама платформа меняется. При этом данные и настройки, изменяемые на основной площадке, обновляются и на резервной. Синхронизация осуществляется с заранее заданной клиентом периодичностью. Таким образом, использование DR на OpenStack позволяет клиенту как посмотреть на сам процесс переноса данных, так и оценить по достоинству функциональность платформы OpenStack. Важно, что при этом основная площадка продолжает работу в штатном режиме.

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

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

Как это работает: шаг за шагом

Первый шаг — это создание DR-плана

Эксперты сервис-провайдера изучают инфраструктуру заказчика и по итогам создают драфт плана восстановления после сбоя. Дальше, совместно с клиентом, план корректируется, учитывая индивидуальные потребности компании. В среднем весь процесс подготовки плана для предприятия, использующего 300 виртуальных машин, занимает около двух с половиной недель. Собственно, такой же план готовится и для миграции. Мы исследуем особенности существующей у клиента архитектуры: топологию сети, настройки, связи и зависимости приложений, чтобы полностью воссоздать ее в том же виде на OpenStack.

Второй шаг — начальный перенос данных в облако (full-репликация) и тестовый запуск резервной площадки

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

Конкретный пример

Для наглядности будем оперировать конкретными цифрами. Допустим, у нас есть платформа виртуализации под управлением VMware vSphere, на которой крутятся 22 виртуалки. Задача — перенести данные с них на резервную площадку в ATLEX Virtual Datacenter.

На основную инфраструктуру клиента (а именно — на хост, где расположены виртуалки, которые нужно защитить) мы устанавливаем агент. Это линуксовая виртуальная машина, которая, собственно, и будет реплицировать клиентские виртуалки, — разработка наших партнеров, российского стартапа Hystax. Фактически мы даем заказчику ссылку на файл, который он загружает себе на vSphere, после чего агент начинает работать.

Он запускается и исследует все виртуальные машины вокруг себя. Спустя пару минут в интерфейсе Hystax Acura (так называется описываемое решение) о них появляется информация, которую агент обновляет с определенной периодичностью.

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


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

Важно: когда мы впервые поставили агента на инфраструктуру, все девайсы появляются в интерфейсе как незащищенные (unprotected). Мы выбираем, какие машины (все или несколько) мы хотим реплицировать, и запускаем первую полную репликацию. Ее, к слову, проводим минимум раз в месяц из соображений безопасности.

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

До момента востребования все реплицируемые данные лежат в облачном хранилище. Здесь применяется метод дедупликации, позволяющий сократить объем данных, а значит — конечную стоимость для клиента. То есть, если нам отдали 200 терабайт, то по факту может храниться всего 100, — и заказчик платит только за реально занимаемое место. Эффективнее применять этот метод, если реплицируемые машины работают на одной операционной системе или хранят повторяющиеся данные — тогда они будут отосланы и сохранены только один раз.
Если на основной инфраструктуре происходит авария, клиент (внимание, барабанная дробь!) просто нажимает на зеленую кнопку, и данные разворачиваются на резервной площадке. Да, она правда зеленая.

Думаете, что упало, то пропало? Тогда мы идем к вам!

Если у клиента “падает” инфраструктура, ему действительно нужно нажать на кнопку с надписью “Восстановить”. При этом он может как выбрать восстановление по заранее подготовленному DR-плану (если необходимо восстановить всю инфраструктуру), так и прямо в процессе восстановления создать новый план для нескольких машин (если из строя вышли несколько машин, например, и требуется восстановить только их). Здесь же можно указать дату и время — до какой точки во времени нужно восстановить инфраструктуру.


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

После того, как виртуальные машины будут восстановлены на резервной площадке, они получат соответствующий статус в интерфейсе. Администратор может запустить виртуалку и наоборот — завершить ее работу или вообще удалить.

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

Заключение

Есть вещи, которые показать — проще, чем рассказать о них. Тем не менее, мы попытались продемонстрировать вам теоретическую модель миграции данных с VMware на OpenStack. Возвращаясь к концепции сервиса: переезд на OpenStack позволяет получить тот же функционал и производительность, которые заказчики ценят в коммерческих решениях, но платить только за реально используемые ресурсы (по модели pay-as-you-go). При этом, нет необходимости мучить собственный ИТ-отдел вопросами реализации такого проекта, потому что все обязательства по миграции данных сервис-провайдер берет на себя.

Если же клиента не столько интересует вопрос сокращения расходов, сколько надежность имеющейся инфраструктуры, то, пожалуй, идеальным решением станет сервис восстановления после сбоев (Disaster Recovery). Заказчик получает возможность синхронизировать процессы на двух площадках: основной, работающей на коммерческой платформе виртуализации, и резервной — на OpenStack. На случай аварии в дата-центре, внешней вирусной атаки или землетрясения вы будете иметь готовый DR-план. Нажатие одной кнопки — и все ваши данные развернутся на резервной инфраструктуре с минимальным временем простоя, а это, в свою очередь, — сэкономит ваши деньги. В свободное от спасения вашего бизнеса время на резервной площадке вы можете, например, тестировать свои новые приложения.

Если остались вопросы — будем рады на них ответить в комментариях.