Операция “Миграция”: как протича преминаването в облака DataLine

Преди 7 години най-ранните проекти лесно и безпроблемно преминаваха в нашето облако. Образите на виртуалните машини се качваха на FTP сървър или се носеха на твърди дискове. След това, с помощта на специален импорт сървър, ВМ се зареждаха в облака.

Ако на клиента не му е проблем да изключи виртуалката за ден-два (или няма други опции), може и така. Но ако престоят трябва да е максимум час, този метод не е подходящ. Днес ще разкажа за инструментите, които помагат за миграция в облака с минимален престой и как протича самият процес на миграция при нас.

Миграция с помощта на 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) и от частни виртуализационни системи на клиента в облака (vCenter – vCloud Director). Основното удобство е интеграцията с интерфейса на vCloud Director. Това значително улеснява процеса на управление на репликацията и минимизира времето за престой при превключване.

С помощта на този инструмент мигрирахме един от клиентите от нашето московско облако в нашето облако в Санкт Петербург. Трябваше да пренесем 18 виртуални машини с общ капацитет от 14 Тб. За клиента беше създадена организация в питерското облако и бяха организирани необходимите мрежи. След това от интерфейса на vCloud Director клиентът премина към настройките на vCloud Availability, създаде задачи за репликация и в удобно за него време се превключи на площадката в Санкт Петербург. Времето за престой при превключване беше 12 минути.

Схема за миграция между облаците DataLine в Санкт Петербург и Москва.

В vCloud Availability има механизъм за миграция на ВМ от площадката на клиента в нашето облако. За целта в клиента's vCenter се разгръща специален аплаенс vCloud Availability. След несложна настройка се изпълнява свързването с облака и се настройват задачи за миграция. Клиентът също така самостоятелно управлява целия процес, като времето за миграция се свежда до минимум.

Схема за миграция на виртуални машини от частна инсталация в облака.

VMware vCloud Availability има много други сценарии за употреба, скоро ще разкажем за тях в отделна статия.

Подготовка за миграция

За да изберете инструмент и всъщност да започнете миграцията, трябва да решите следните моменти:

От къде мигрираме. Ако мигрирате от частно решение, имате пълна свобода в избора на инструменти. Ако се отделяте от доставчик, то тук е по-сложно. Вероятно няма да успеете просто да свържете инфраструктурите на двамата доставчици и да преместите ВМ поради съображения за сигурност. Понякога доставчикът, от който клиентът смята да се откаже, дори започва да създава трудности и забавя процеса. Можете да се отделяте от доставчика по старомоден начин: чрез експортиране на ВМ на дискове и FTP или да мигрирате на ниво приложение. Името на последното е условно и изглежда по следния начин.

Случай 3
Трябваше да мигрираме SAP системата на клиента от европейски доставчик: 34 ВМ с обем от 54 Тб. На клиента бяха предоставени ресурси в нашето облак. Беше организирана мрежова свързаност между нас и инфраструктурата на европейския доставчик. Серверите на приложенията бяха разположени отново, с налагане на необходимите конфигурации. Големите бази данни бяха мигрирани чрез качване на резервни копия в нашето облак. След това беше настроена репликация между базите данни в нашата и изходната площадка. В уговореното време ние превключихме на базите данни в нашето облак.

Обем на данни и интернет канал. Обикновено молим клиента да предостави износ по системите с параметри на памет, CPU и дискове. Оценяваме, дали каналът е достатъчен, за да изпращаме директно реплики или резервни копия на виртуални машини.

Допустимо време на забавяне. За различни системи и, съответно, виртуални машини, той може да бъде различен в зависимост от критичността им за бизнеса. Обикновено клиентът идва с готови изисквания за времето на забавяне при миграция, а на база на това избираме подходящ инструмент и план за миграция. Стремим се да планираме финалното превключване за нощно време или през уикенда, така че дори незначително забавяне да не бъде забелязано от крайния потребител.

С оглед на тези данни може да се избере инструмент и да се премине към самата миграция. Ето какво се случва след това.

1. Настройка на мрежова свързаност. Организираме мрежова свързаност между нашето облак и инфраструктурата на клиента. През тази мрежа ще бъдат копирани виртуалните машини. Ако се използва Veeam Backup and Replication, то това е отделен канал, по-рядко - VPN канал. Ако Veeam Cloud Connect, то всичко минава през интернет или същия отделен канал.

   След това се настройва мрежата за ВМ в облака. Машините обикновено се преместват групово и не за един ден. След като ВМ бъдат пренесени при нас и стартирани, те трябва да взаимодействат с машините, които все още остават на изходната площадка.

2. График на миграцията. Когато машините са много, е разумно да ги разделим на групи и да ги преместим на партиди. Взаимно с клиента съгласуваме план, в който описваме, кога и кои машини се преместят и кога ще бъде извършена финалната репликация и превключване на новата площадка.
3. Тестова миграция. Мигрираме тестова виртуална машина и проверяваме дали всичко е настроено правилно: свързаност между площадките, достъпност на виртуалната машина за машините на изходната площадка, права на акаунта и други. Такъв тест помага да се избегнат забавяния на етапа на бойна миграция.

С това приключвам. В коментарите задавайте въпроси и споделяйте опита си от миграцията.

Източник: habr.com