Лет 7 назад самые первые проекты переезжали в наше облако просто и незатейливо. Образы виртуальных машин загружались на FTP-сервер, или их привозили на жестких дисках. Затем через специальный импорт-сервер ВМ загружали в облако.
Если для клиента не проблема выключить виртуалку на сутки-двое (или нет других вариантов), то можно и так. Но если простой должен быть максимум час, то такой способ не подойдет. Сегодня расскажу, какие инструменты помогут мигрировать в облако с минимальным простоем и про то, как устроен сам процесс миграции у нас.
Veeam Backup and Replication все знают как инструмент для создания бэкапов и реплик. Мы его используем для миграции между нашими площадками и для перевоза клиентов с приватной виртуализации к нам в облако. Виртуальные машины клиента реплицируются на наш vCenter, после инженер добавляет их в vCloud Director.
Первичная репликация выполняется на включенной виртуальной машине. В согласованное время машина на стороне клиента выключается. Репликация запускается еще раз, чтобы перенести изменения, которые произошли с момента первой репликации. После этого виртуальная машина стартует уже в нашем облаке.
Обычно с момента выключения машины на инфраструктуре клиента и до момента включения в нашем облаке проходит не более получаса, а скорее 15–20 минут.
При этом на площадке клиента остается исходная виртуальная машина. Если вдруг что-то идет не так, всегда можно откатиться и включить ее. Для клиента этот способ еще и удобен тем, что не требует от него наличия Veeam.
Кейс 1
У клиента была своя виртуальная инфраструктура на базе VMware – 40 ВМ объемом 30 Тб. Оборудование, на котором был развернут кластер, уже устарело, и клиент решил не связываться с закупкой нового и переехать в публичное облако. Требование к простою критичных систем было не более часа. В качестве инструмента выбрали Veeam Replication. Плюсом также было то, что интернет-провайдер клиента присутствовал в нашем ЦОДе, что позволило организовать хороший канал. Миграция заняла около месяца, простой при переключении составил до 30 минут на одну группу виртуальных машин.
Veeam Cloud Connect – инструмент, помогающий настраивать репликацию виртуальных машин и запускать реплики в облаке сервис-провайдера. После обновления в 2019 году появилась возможность реплицировать виртуальные машины сразу в vCloud Director. Единственное условие – на стороне клиента должен быть развернут свой Veeam Backup and Replication не ниже версии 9. Если кратко (подробная версия тут), то весь процесс выглядит следующим образом.
В vCloud Director создается организация с необходимыми ресурсами и сетями. В Veeam Cloud Connect мы создаем аккаунт, клиент к нему подключается из своего Veeam B&R, выбирает провайдера DataLine и организацию, настраивает задания для репликации. Помимо того, что при такой миграции простой будет в пределах 15–20 минут, клиент никак не зависит от техподдержки провайдера и управляет всем процессом самостоятельно: создает задания на репликацию, саму репликацию, выключает машины и запускает их старт на новой площадке.
Кейс 2
Инфраструктура клиента, откуда планировалась миграция, располагалась в Белоруссии. Нужно было перевезти 90 ВМ суммарным объемом 27 Тб, при том что интернет-канал был 100 мбит/сек. Если делать бэкап и сразу заливать его к нам в облако, то для некоторых ВМ это заняло бы несколько суток. За это время на ВМ выросла бы большая дельта, а это уже могло негативно повлиять на производительность машин или, еще хуже, место на датасторе закончилось. Действовали следующим образом: сначала клиент сделал локальный полный бэкап и перенес его копию к нам в облако через Veeam Cloud Connect. Потом сделал и перебросил в облако инкремент. Исходная виртуальная машина продолжала работать. После выключения ВМ клиент сделал еще один инкремент и также перенес в облако. На своей стороне мы развернули виртуальную машину из полного бэкапа, а потом докатили на нее два инкремента. Такая схема позволила в итоге минимизировать простой до 2 часов при переключении на нашу площадку.
В марте этого года VMware выпустила vCloud Availability 3.0, который позволяет мигрировать виртуальным машинам между разными облаками (vCloud Director – vCloud Director) и c частных стендов виртуализации клиента в облако (vCenter – vCloud Director). Основным удобством является интеграция с интерфейсом vCloud Director. Это значительно упрощает процесс управления репликацией и сводит к минимуму простой при переключении.
С помощью этого инструмента мы мигрировали одного из клиентов из нашего московского облака в наше облако в Питере. Нужно было перевезти 18 виртуальных машин суммарной емкостью 14 Тб. Для клиента была создана организация в питерском облаке и организованы необходимые сети. Далее из интерфейса vCloud Director клиент перешел к настройкам vCloud Availability, создал задания репликации и в удобное для него время переключился на питерскую площадку. Простой при переключении составил 12 минут.
Схема миграции между облаками DataLine в Питере и Москве.
В vCloud Availability есть механизм миграции ВМ с площадки клиента в наше облако. Для этого в vCenter клиента разворачивается специальный апплаенс vCloud Availability. После несложной настройки выполняется подключение к облаку и настраиваются задания миграции. Клиент также самостоятельно управляет всем процессом, и время миграции сводится к минимуму.
Схема миграции виртуальных машин из частной инсталляции в облако.
У VMware vCloud Availability много других сценариев использования, скоро расскажем про них в отдельной статье.
Чтобы выбрать инструмент и собственно приступить к миграции, нужно определиться со следующими моментами:
Откуда мигрируем. Если вы мигрируете с приватного решения, то у вас полная свобода в выборе инструментов. Если съезжаете от провайдера, то тут сложнее. Скорее всего, связать инфраструктуры двух провайдеров и просто перетащить ВМ не получится из-за соображений безопасности. Иногда провайдер, от которого клиент собирается отказаться, и вовсе начинает вредничать и тянет время. Съезжать от провайдера можно по-старинке: через выгрузку ВМ на диски и FTP или мигрировать на уровне приложения. Название последнего условно, и выглядит это примерно так.
Кейс 3
Нужно было мигрировать SAP-систему клиента от европейского провайдера: 34 ВМ объемом 54 Тб. Клиенту были выделены ресурсы в нашем облаке. Между нами и инфраструктурой европейского провайдера была организована сетевая связность. Сервера приложений были заново развернуты, с накатом нужных конфигураций. Большие базы данных мигрировали через загрузку бэкапов в наше облако. Далее была настроена репликация между базами данных на нашей и исходной площадках. В согласованное время мы переключили на базы данных в нашем облаке.
Объем данных и интернет-канал. Мы обычно просим клиента предоставить выгрузку по системам с параметрами памяти, CPU, дисков. Оцениваем, хватит ли канала, чтобы напрямую отправлять реплики или бэкапы виртуальных машин.
Допустимый простой. Для разных систем и, соответственно, виртуальных машин он может быть разным в зависимости от их критичности для бизнеса. Обычно клиент приходит с готовыми требованиями по простою при миграции, и на основании этого мы выбираем подходящий инструмент и план миграции. Мы стараемся планировать финальное переключение на ночное время или выходные, чтобы даже незначительный простой не был заметен для конечных пользователей клиента.
Исходя из этих данных можно выбирать инструмент и приступать к самой миграции. Вот что происходит дальше.
На этом у меня все. В комментариях задавайте вопросы и рассказывайте про свой опыт миграции.
Если для клиента не проблема выключить виртуалку на сутки-двое (или нет других вариантов), то можно и так. Но если простой должен быть максимум час, то такой способ не подойдет. Сегодня расскажу, какие инструменты помогут мигрировать в облако с минимальным простоем и про то, как устроен сам процесс миграции у нас.
Миграция с помощью Veeam Backup and Replication
Veeam Backup and Replication все знают как инструмент для создания бэкапов и реплик. Мы его используем для миграции между нашими площадками и для перевоза клиентов с приватной виртуализации к нам в облако. Виртуальные машины клиента реплицируются на наш vCenter, после инженер добавляет их в vCloud Director.
Первичная репликация выполняется на включенной виртуальной машине. В согласованное время машина на стороне клиента выключается. Репликация запускается еще раз, чтобы перенести изменения, которые произошли с момента первой репликации. После этого виртуальная машина стартует уже в нашем облаке.
Обычно с момента выключения машины на инфраструктуре клиента и до момента включения в нашем облаке проходит не более получаса, а скорее 15–20 минут.
При этом на площадке клиента остается исходная виртуальная машина. Если вдруг что-то идет не так, всегда можно откатиться и включить ее. Для клиента этот способ еще и удобен тем, что не требует от него наличия Veeam.
Кейс 1
У клиента была своя виртуальная инфраструктура на базе VMware – 40 ВМ объемом 30 Тб. Оборудование, на котором был развернут кластер, уже устарело, и клиент решил не связываться с закупкой нового и переехать в публичное облако. Требование к простою критичных систем было не более часа. В качестве инструмента выбрали Veeam Replication. Плюсом также было то, что интернет-провайдер клиента присутствовал в нашем ЦОДе, что позволило организовать хороший канал. Миграция заняла около месяца, простой при переключении составил до 30 минут на одну группу виртуальных машин.
Миграция с помощью Veeam Cloud Connect
Veeam Cloud Connect – инструмент, помогающий настраивать репликацию виртуальных машин и запускать реплики в облаке сервис-провайдера. После обновления в 2019 году появилась возможность реплицировать виртуальные машины сразу в vCloud Director. Единственное условие – на стороне клиента должен быть развернут свой Veeam Backup and Replication не ниже версии 9. Если кратко (подробная версия тут), то весь процесс выглядит следующим образом.
В vCloud Director создается организация с необходимыми ресурсами и сетями. В Veeam Cloud Connect мы создаем аккаунт, клиент к нему подключается из своего Veeam B&R, выбирает провайдера DataLine и организацию, настраивает задания для репликации. Помимо того, что при такой миграции простой будет в пределах 15–20 минут, клиент никак не зависит от техподдержки провайдера и управляет всем процессом самостоятельно: создает задания на репликацию, саму репликацию, выключает машины и запускает их старт на новой площадке.
Кейс 2
Инфраструктура клиента, откуда планировалась миграция, располагалась в Белоруссии. Нужно было перевезти 90 ВМ суммарным объемом 27 Тб, при том что интернет-канал был 100 мбит/сек. Если делать бэкап и сразу заливать его к нам в облако, то для некоторых ВМ это заняло бы несколько суток. За это время на ВМ выросла бы большая дельта, а это уже могло негативно повлиять на производительность машин или, еще хуже, место на датасторе закончилось. Действовали следующим образом: сначала клиент сделал локальный полный бэкап и перенес его копию к нам в облако через Veeam Cloud Connect. Потом сделал и перебросил в облако инкремент. Исходная виртуальная машина продолжала работать. После выключения ВМ клиент сделал еще один инкремент и также перенес в облако. На своей стороне мы развернули виртуальную машину из полного бэкапа, а потом докатили на нее два инкремента. Такая схема позволила в итоге минимизировать простой до 2 часов при переключении на нашу площадку.
Миграция с помощью VMware vCloud Availability
В марте этого года VMware выпустила vCloud Availability 3.0, который позволяет мигрировать виртуальным машинам между разными облаками (vCloud Director – vCloud Director) и c частных стендов виртуализации клиента в облако (vCenter – vCloud Director). Основным удобством является интеграция с интерфейсом vCloud Director. Это значительно упрощает процесс управления репликацией и сводит к минимуму простой при переключении.
С помощью этого инструмента мы мигрировали одного из клиентов из нашего московского облака в наше облако в Питере. Нужно было перевезти 18 виртуальных машин суммарной емкостью 14 Тб. Для клиента была создана организация в питерском облаке и организованы необходимые сети. Далее из интерфейса vCloud Director клиент перешел к настройкам vCloud Availability, создал задания репликации и в удобное для него время переключился на питерскую площадку. Простой при переключении составил 12 минут.
Схема миграции между облаками DataLine в Питере и Москве.
В vCloud Availability есть механизм миграции ВМ с площадки клиента в наше облако. Для этого в vCenter клиента разворачивается специальный апплаенс vCloud Availability. После несложной настройки выполняется подключение к облаку и настраиваются задания миграции. Клиент также самостоятельно управляет всем процессом, и время миграции сводится к минимуму.
Схема миграции виртуальных машин из частной инсталляции в облако.
У VMware vCloud Availability много других сценариев использования, скоро расскажем про них в отдельной статье.
Подготовка к миграции
Чтобы выбрать инструмент и собственно приступить к миграции, нужно определиться со следующими моментами:
Откуда мигрируем. Если вы мигрируете с приватного решения, то у вас полная свобода в выборе инструментов. Если съезжаете от провайдера, то тут сложнее. Скорее всего, связать инфраструктуры двух провайдеров и просто перетащить ВМ не получится из-за соображений безопасности. Иногда провайдер, от которого клиент собирается отказаться, и вовсе начинает вредничать и тянет время. Съезжать от провайдера можно по-старинке: через выгрузку ВМ на диски и FTP или мигрировать на уровне приложения. Название последнего условно, и выглядит это примерно так.
Кейс 3
Нужно было мигрировать SAP-систему клиента от европейского провайдера: 34 ВМ объемом 54 Тб. Клиенту были выделены ресурсы в нашем облаке. Между нами и инфраструктурой европейского провайдера была организована сетевая связность. Сервера приложений были заново развернуты, с накатом нужных конфигураций. Большие базы данных мигрировали через загрузку бэкапов в наше облако. Далее была настроена репликация между базами данных на нашей и исходной площадках. В согласованное время мы переключили на базы данных в нашем облаке.
Объем данных и интернет-канал. Мы обычно просим клиента предоставить выгрузку по системам с параметрами памяти, CPU, дисков. Оцениваем, хватит ли канала, чтобы напрямую отправлять реплики или бэкапы виртуальных машин.
Допустимый простой. Для разных систем и, соответственно, виртуальных машин он может быть разным в зависимости от их критичности для бизнеса. Обычно клиент приходит с готовыми требованиями по простою при миграции, и на основании этого мы выбираем подходящий инструмент и план миграции. Мы стараемся планировать финальное переключение на ночное время или выходные, чтобы даже незначительный простой не был заметен для конечных пользователей клиента.
Исходя из этих данных можно выбирать инструмент и приступать к самой миграции. Вот что происходит дальше.
- Настройка сетевой связности. Мы организуем сетевую связность между нашим облаком и инфраструктурой клиента. По этой сети будут копироваться виртуальные машины. Если используется Veeam Backup and Replication, то это выделенный канал, реже – VPN-канал. Если Veeam Cloud Connect, то все идет через интернет или тот же выделенный канал.
Затем настраивается сеть для ВМ в облаке. Машины обычно переезжают группами и не один день. После того как ВМ перенесли к нам и запустили, они должны взаимодействовать с машинами, которые все еще остаются на исходной площадке. - Расписание миграции. Когда машин много, разумно разбивать их на группы и перевозить партиями. Совместно с клиентом мы согласовываем план, в котором прописываем, когда и какие машины переезжают и когда будет выполнена финальная репликация и переключение на новую площадку.
- Тестовая миграция. Мигрируем тестовую виртуальную машину и проверяем, все ли правильно настроено: сетевая связность между площадками, доступность виртуальной машины для машин на исходной площадке, права учетной записи и прочее. Такой тест помогает избежать заминок на этапе боевой миграции.
На этом у меня все. В комментариях задавайте вопросы и рассказывайте про свой опыт миграции.
Комментарии (4)
Loxmatiymamont
22.11.2019 20:05И про переезд месяц: можно же было сделать локальный бекап, перетащить файлы и сделать или реплика сидинг. Рассматривали такой вариант?
akhodyrev Автор
25.11.2019 13:18Месяц на миграцию ушел из-за внутренних процедур и регламентов клиента — на практике это является основным «тормозом» миграции. Сам перенос не занимал много времени
Loxmatiymamont
А почему не quick migration вимом?
akhodyrev Автор
Как написано в статье, на площадке клиента остается исходная ВМ, которая является резевом.
Так как процессоры в нашем кластер и кластере клиента почти всегда отличаются, то все равно происходит выключение ВМ.