Операция “Миграция”: как се извършва преместването в облака 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 TB. За клиента беше създадена организация в облак на Санкт Петербург и бяха организирани необходимите мрежи. След това от интерфейса на vCloud Director клиентът премина към настройки на vCloud Availability, създаде задания за репликация и в удобно за него време премина на петербургската площадка. Простой при прехвърлянето беше 12 минути.

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

В vCloud Availability има механизъм за миграция на ВМ от площадка на клиента към нашето облако. За целта в 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