Существует миф, будто миграция в облако это простая процедура, как и переезд систем с одной платформы на другую. Но если мы говорим про сложные случаи с миграцией большого количества сервисов с минимальным даунтаймом, все становится не так радужно. А уж если подразумевается переезд со мной гипервизора так вообще. Долгое время это было серьезным ограничением для нас и для наших клиентов, пока не появился инструмент, позволяющий очень просто и быстро проводить миграции. Подробнее о нем дальше.
Переезд с одной облачной платформы на другую стандартная ситуация. Компании часто меняют провайдеров потому, что их не устраивает качество сервисов: либо реальные параметры не соответствуют заявленным в договоре, либо начинаются сбои, а техническая поддержка не реагирует по нескольку дней. Другая распространенная причина изменение ценовой политики.
Миграция проходит по одному и тому же сценарию: компания проводит конкурс, выбирает провайдера по ассортименту сервисов, характеристикам и ценам, а затем начинает переезд. На этом этапе и происходят многие технические проблемы.
С чем приходится сталкиваться
Хорошо, если целевое облако использует ту же платформу виртуализации, что и исходное. Так, при миграции из VMware на VMware достаточно сделать снапшот и загрузить его в новое облако. Это просто и, как правило, перенос проходит без неожиданностей. Для самой системы не меняется ничего, кроме IP-адресов и железа, на котором работает виртуализация.
А вот при переходе с VMware на гипервизор KVM задача усложняется, ведь KVM использует другой формат виртуальных машин. Чтобы преодолеть несовместимость, необходимо сделать дамп дисков и провести конвертацию. Попутно придется записать в виртуалку драйвера, которые позволят запуститься на новом гипервизоре.
На самом деле, как показывает практика, эти трудности вполне можно преодолеть, но долгое время переезд с одного гипервизора на другой фактически означал большой объем работы для инженеров и головную боль для клиентов. Такую миграцию не выполнить за несколько дней, а если инфраструктура большая, можно провозиться и больше недели. Чтобы сохранить консистентность данных в таких условиях, приходится уходить на продолжительный даунтайм.
Это при том, что даже несколько дней без рабочей облачной инфраструктуры означают огромные денежные и репутационные потери. А даунтайм, который растянулся на неделю это не просто страшно звучит, это катастрофа для многих клиентов.
Поэтому в идеале миграция должна проходить как можно быстрее и, по возможности, без остановки сервисов. Для этого можно было использовать, например, Carbonite Migrate, но мы взвесили все за и против и нашли более подходящее решение для миграции из облака в облако Hystax Acura.
Как работает Hystax Acura: теория
Этот инструмент работает с VMware, KVM и Hyper-V, поддерживает перенос с физических серверов и при этом не дорог. Так что мы используем его для автоматической миграции в Облако КРОК, бекапов, резервирования и аварийного восстановления инфраструктуры заказчиков. Во всех этих случаях архитектура и принцип работы Hystax Acura одинаковы.
С одной стороны, у нас есть source-окружение, исходное облако или физический сервер, где запущена инфраструктура пользователя. С другой стороны находится Облако КРОК. И стоит задача перенести данные с source на target.
На стороне source-окружения устанавливается один из трех репликационных агентов.
Два из них предназначены для Linux или Windows соответственно. Они устанавливаются внутрь виртуальной машины и работают как сервисы на уровне операционной системы. Третий предназначен специально для миграции с VMware. Он развертывается на уровне ESXi-хоста и позволяет реплицировать сразу все находящиеся вокруг виртуальные машины.
Репликационные агенты отправляют данные на target-облако на уровне блоков. Причем репликация происходит в фоновом режиме, без необходимости останавливать виртуальные машины в source-облаке.
Ресивер-сервис Hystax Acura принимает данные и также поблочно записывает в их свежесозданный том в Облаке КРОК. По окончании репликации мы снимаем снапшот. Эти снимки образуют цепочку ресторпойнтов.Консистентность данных для Windows-машин обеспечивает стандартная служба VSS (Volume Shadow Copy Service). Для Linux-агента разработчики Hystax выпустили собственный проприетарный драйвер, который дублирует функциональность VSS. Что касается VMware там используется СBT API.
После создания снапшота остается лишь подать команду на запуск реплицированной виртуальной машины на новом месте.
Прямо перед поднятием машины на target-облаке Acura проводит автоматическое V2V-преобразование. Это одна из основных вещей, которые необходимо сделать, чтобы машина завелась при смене гипервизора.
Acura инжектит в виртуальную машину новые драйвера, вырезает старые, если это необходимо, и подстраивает bootloader, чтобы виртуальная машина запустилась на КVM.
Длительность этого процесса зависит от размера машины. V2V-преобразование занимает считаные минуты и идет параллельно, если одновременно поднимается несколько виртуальных машин.
Запуск группы виртуальных машин осуществляется по заранее составленному DR-плану. Он включает в себя описание виртуалок, настройки сетей, и оркестрацию задание правильного порядка запуска взаимозависимых сервисов.
Ограничения Hystax Acura
Такой подход позволяет мигрировать в Облако КРОК практически с любой технологии, но у Hystax Acura есть и ограничения.
Так, в случае Linux работоспособность репликации и P2V/V2V преобразования зависит от версии ядра.
Выбор достаточно широк, но если нужного ядра не оказалось в списке поддерживаемых, придется подождать, пока Hystax не подготовит драйвера на заказ. Кроме того, репликационные агенты пока не умеют переносить Windows-системы, целиком развернутые на динамических дисках.
Миграция с Hystax Acura на практике
Hystax Acura делает процесс миграции в новое облако заметно легче. Настолько, что некоторые облачные провайдеры предлагают клиентам переехать к ним самостоятельно.
В принципе, графический интерфейс этого решения достаточно прост, чтобы разобраться без особой подготовки, но мы все равно все делаем сами и, как правило, через API. Мы заранее разрабатываем миграционный или DR-план, разворачиваем репликационных агентов, проводим тестовые миграции.
Конечно, мгновенных переездов не бывает, но теперь узким местом является не работа по портированию виртуальных машин с одного гипервизора на другой, которая занимает непредсказуемо много времени, а пропускная способность сети.
Больше всего времени уходит на передачу данных при первой репликации, но это предсказуемый процесс, и необходимое время рассчитывается при помощи простого калькулятора.
Небольшие сервисы реплицируются за несколько часов даже при достаточно скромном канале. В то время как перенос инфраструктуры крупного маркетплейса может занять несколько дней. К счастью, все это время сервисы продолжают работу, и мы можем позволить себе особо не спешить.
При следующих, инкрементальных репликациях Acura отсылает только дельты, изменения на виртуальных машинах, и репликация проходит намного быстрее. Поэтому RTO (recovery time objective), время, которое система будет недоступна во время переезда, фактически равняется скорости загрузки машин на target-стороне.
Скриншот DR-плана (json)
Перед окончательным переездом мы проводим тестовый запуск и замеряем, сколько времени нужно на загрузку. Так мы определяем, на какое время необходимо остановить сервисы на source-стороне, чтобы не потерять ни байта данных. Около десяти минут даунтайма, и гигантская инфраструктура готова принимать трафик в нашем облаке.
Что касается аварийного восстановления, то, по нашим подсчетам, RPO (recovery point objective время, за которое можно потерять данные), составляет три минуты для виртуалок на Linux и пять минут для Windows. Это впечатляющие показатели, и теперь вы знаете, какие технические решения позволяют добиться их на практике.
Если у вас остались вопросы по работе Hystax Acura и Облака КРОК в целом, не стесняйтесь оставлять их в комментариях или присылайте на почту: RSayfutdinov@croc.ru
