Как мы проводим миграции в облако со сменой гипервизора и без даунтайма
Существует миф, будто миграция в облако — это простая процедура, как и переезд систем с одной платформы на другую. Но если мы говорим про сложные случаи с миграцией большого количества сервисов с минимальным даунтаймом, все становится не так радужно. А уж если подразумевается переезд со мной гипервизора — так вообще. Долгое время это было серьезным ограничением для нас и для наших клиентов, пока не появился инструмент, позволяющий очень просто и быстро проводить миграции. Подробнее о нем дальше.
Переезд с одной облачной платформы на другую — стандартная ситуация. Компании часто меняют провайдеров потому, что их не устраивает качество сервисов: либо реальные параметры не соответствуют заявленным в договоре, либо начинаются сбои, а техническая поддержка не реагирует по нескольку дней. Другая распространенная причина — изменение ценовой политики.
Миграция проходит по одному и тому же сценарию: компания проводит конкурс, выбирает провайдера по ассортименту сервисов, характеристикам и ценам, а затем начинает переезд. На этом этапе и происходят многие технические проблемы.
С чем приходится сталкиваться
Хорошо, если целевое облако использует ту же платформу виртуализации, что и исходное. Так, при миграции из 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
