[IT-инфраструктура, Виртуализация, Хранение данных] Как мы проводим миграции в облако со сменой гипервизора и без даунтайма
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Извините, данный ресурс не поддреживается. :(
Существует миф, будто миграция в облако — это простая процедура, как и переезд систем с одной платформы на другую. Но если мы говорим про сложные случаи с миграцией большого количества сервисов с минимальным даунтаймом, все становится не так радужно. А уж если подразумевается переезд со мной гипервизора — так вообще. Долгое время это было серьезным ограничением для нас и для наших клиентов, пока не появился инструмент, позволяющий очень просто и быстро проводить миграции. Подробнее о нем дальше.
Переезд с одной облачной платформы на другую – стандартная ситуация. Компании часто меняют провайдеров потому, что их не устраивает качество сервисов: либо реальные параметры не соответствуют заявленным в договоре, либо начинаются сбои, а техническая поддержка не реагирует по нескольку дней. Другая распространенная причина — изменение ценовой политики.
Миграция проходит по одному и тому же сценарию: компания проводит конкурс, выбирает провайдера по ассортименту сервисов, характеристикам и ценам, а затем начинает переезд. На этом этапе и происходят многие технические проблемы.
С чем приходится сталкиваться
Хорошо, если целевое облако использует ту же платформу виртуализации, что и исходное. Так, при миграции из 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
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, IT-инфраструктура, Управление проектами, Софт] Какие проблемы может выявить аудит прав доступа и что с этим делать
- [Высокая производительность, Хранение данных, Компьютерное железо, Накопители, Настольные компьютеры] GOODRAM IRDM Pro gen.2: терабайтный SSD с приличными скоростями
- [Системное администрирование, Программирование, IT-инфраструктура, DevOps] Тонкости настройки CI/CD: как работает GitLab runner, когда использовать Docker-in-Docker и где пригодится Argo CD
- [Хранение данных, Хранилища данных] Сетевые хранилища NAS: зачем нужны и как выбрать подходящее?
- [IT-инфраструктура, Алгоритмы, Хранение данных, Tarantool] Raft в Tarantool. Как это работает и как этим пользоваться
- [IT-эмиграция] Год жизни в Дании (часть 1)
- [Open source, Системное администрирование, IT-инфраструктура] Подготовка к импортозамещению, или Куда бежать, на что смотреть и к кому обратиться за помощью
- [Виртуализация, Серверное администрирование, Тестирование игр, Облачные сервисы, Видеокарты] Как я Cyberpunk в облаке запускал: часть 1
- [Высокая производительность, Хранение данных, Компьютерное железо, Накопители] Прокачиваем сервер: SAS SSD против SATA- и NVMe SSD
- [IT-инфраструктура, Серверное администрирование, Конференции] DGTL Communications Meetup 21/01
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_virtualizatsija (Виртуализация), #_hranenie_dannyh (Хранение данных), #_migratsija (миграция), #_dauntajm (даунтайм), #_oblako_krok (Облако КРОК), #_hystax, #_blog_kompanii_krok_oblachnye_servisy (
Блог компании КРОК Облачные сервисы
), #_itinfrastruktura (
IT-инфраструктура
), #_virtualizatsija (
Виртуализация
), #_hranenie_dannyh (
Хранение данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:17
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Извините, данный ресурс не поддреживается. :(
Существует миф, будто миграция в облако — это простая процедура, как и переезд систем с одной платформы на другую. Но если мы говорим про сложные случаи с миграцией большого количества сервисов с минимальным даунтаймом, все становится не так радужно. А уж если подразумевается переезд со мной гипервизора — так вообще. Долгое время это было серьезным ограничением для нас и для наших клиентов, пока не появился инструмент, позволяющий очень просто и быстро проводить миграции. Подробнее о нем дальше. Переезд с одной облачной платформы на другую – стандартная ситуация. Компании часто меняют провайдеров потому, что их не устраивает качество сервисов: либо реальные параметры не соответствуют заявленным в договоре, либо начинаются сбои, а техническая поддержка не реагирует по нескольку дней. Другая распространенная причина — изменение ценовой политики. Миграция проходит по одному и тому же сценарию: компания проводит конкурс, выбирает провайдера по ассортименту сервисов, характеристикам и ценам, а затем начинает переезд. На этом этапе и происходят многие технические проблемы. С чем приходится сталкиваться Хорошо, если целевое облако использует ту же платформу виртуализации, что и исходное. Так, при миграции из 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 =========== Источник: habr.com =========== Похожие новости:
Блог компании КРОК Облачные сервисы ), #_itinfrastruktura ( IT-инфраструктура ), #_virtualizatsija ( Виртуализация ), #_hranenie_dannyh ( Хранение данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:17
Часовой пояс: UTC + 5