Операција „Миграција“: како да се преселите во облакот DataLine

Пред околу 7 години, првите проекти се преселија во нашиот облак едноставно и непретенциозно. Сликите на виртуелната машина беа поставени на FTP сервер или беа доставени на хард дискови. Потоа, преку специјален сервер за увоз, VM-ите беа поставени на облакот.

Ако не е проблем клиентот да ја исклучи виртуелната машина ден или два (или нема други опции), тогаш тоа може да се направи. Но, ако времето на застој треба да биде максимум еден час, тогаш овој метод нема да работи. Денес ќе ви кажам кои алатки ќе ви помогнат да мигрирате во облакот со минимален прекин и како функционира самиот процес на миграција.

Миграција со Veeam Backup и Replication

Секој го знае Veeam Backup and Replication како алатка за креирање резервни копии и реплики. Го користиме за миграција помеѓу нашите сајтови и за транспорт на клиенти од приватна виртуелизација до нашиот облак. Виртуелните машини на клиентот се реплицираат на нашиот vCenter, по што инженерот ги додава во директорот на vCloud.

Примарната репликација се јавува на вклучена виртуелна машина. Во договореното време, машината од страна на клиентот е исклучена. Репликацијата работи повторно за да ги пренесе промените што се случиле од првата репликација. По ова, виртуелната машина започнува во нашиот облак.

Обично, од моментот кога машината е исклучена на инфраструктурата на клиентот до моментот кога е вклучена во нашиот облак, не поминува повеќе од половина час, туку 15-20 минути.

Во овој случај, оригиналната виртуелна машина останува на локацијата на клиентот. Ако одеднаш нешто тргне наопаку, секогаш можете да се вратите назад и да го вклучите. Овој метод е погоден и за клиентот со тоа што не бара од него да има Veeam.

Случај 1
Клиентот имаше своја виртуелна инфраструктура базирана на VMware - 40 VM со капацитет од 30 TB. Опремата на која беше распореден кластерот веќе беше застарена, а клиентот одлучи да не се мачи да купува нови и се пресели во јавниот облак. Барањето за застој за критичните системи не беше повеќе од еден час. Како алатка беше избрана Veeam Replication. Друг плус беше тоа што интернет-провајдерот на клиентот беше присутен во нашиот центар за податоци, што овозможи да се организира добар канал. Миграцијата траеше околу еден месец, застојот за време на префрлувањето беше до 30 минути по група виртуелни машини.

Мигрирајте со Veeam Cloud Connect

Veeam Cloud Connect е алатка која ви помага да поставите репликација на виртуелната машина и да стартувате реплики во облакот на давателот на услуги. По ажурирањето на 2019 година, стана возможно да се реплицираат виртуелните машини директно на директорот на vCloud. Единствениот услов е дека на страната на клиентот, Veeam Backup и Replication мора да бидат распоредени најмалку верзија 9. Накратко (детална верзија тука), тогаш целиот процес изгледа вака.

Во директорот на vCloud, се создава организација со потребните ресурси и мрежи. Во Veeam Cloud Connect, создаваме сметка, клиентот се поврзува со неа од неговиот Veeam B&R, избира провајдер и организација на DataLine и ги конфигурира задачите за репликација. Покрај фактот дека за време на таквата миграција, времето на застој ќе биде во рок од 15-20 минути, клиентот на кој било начин не зависи од техничката поддршка на давателот и самостојно управува со целиот процес: создава задачи за репликација, самата репликација, се исклучува машините и ги стартува на новата локација.

Случај 2
Инфраструктурата на клиентот, од каде што беше планирана миграцијата, се наоѓаше во Белорусија. Беше неопходно да се транспортираат 90 VM со вкупен волумен од 27 TB, и покрај тоа што интернет каналот беше 100 Mbit/sec. Ако направите резервна копија и веднаш ја прикачите на нашиот облак, тогаш за некои VM ќе бидат потребни неколку дена. За тоа време, голема делта би пораснала на VM, а тоа би можело да има негативно влијание врз перформансите на машините или, уште полошо, просторот на продавницата за податоци би бил снема. Постапивме на следниов начин: прво, клиентот направи локална целосна резервна копија и префрли копија од неа во нашиот облак преку Veeam Cloud Connect. Потоа направив и го префрлив инкрементот во облакот. Оригиналната виртуелна машина продолжи да работи. По исклучувањето на VM, клиентот направи уште едно зголемување и исто така го префрли на облакот. Од наша страна, распоредивме виртуелна машина од целосна резервна копија, а потоа навивавме два чекори врз неа. Оваа шема на крајот овозможи да се минимизира времето на застој до 2 часа кога се префрлате на нашата страница.

Миграција со достапност на VMware vCloud

Во март оваа година, VMware објави vCloud Availability 3.0, кој ви овозможува да мигрирате виртуелни машини помеѓу различни облаци (vCloud Director - vCloud Director) и од виртуелизација на приватни клиенти до облакот (vCenter - vCloud Director). Главната погодност е интеграцијата со интерфејсот vCloud Director. Ова во голема мера го поедноставува процесот на управување со репликација и го минимизира времето на застој при префрлување.

Користејќи ја оваа алатка, мигриравме еден од клиентите од нашиот московски облак во нашиот облак во Санкт Петербург. Беше неопходно да се транспортираат 18 виртуелни машини со вкупен капацитет од 14 TB. Беше создадена организација за клиентот во облакот Санкт Петербург и беа организирани потребните мрежи. Следно, од интерфејсот vCloud Director, клиентот отиде до поставките за достапност на vCloud, креираше работни места за репликација и се префрли на страницата во Санкт Петербург во погодно време за него. Прекинот за време на префрлувањето беше 12 минути.

Шема за миграција помеѓу облаците DataLine во Санкт Петербург и Москва.

Достапноста на vCloud има механизам за мигрирање на VM од страницата на клиентот во нашиот облак. За да го направите ова, специјална апликација за достапност на vCloud е распоредена во vCenter на клиентот. По едноставното поставување, се поврзувате со облакот и ги конфигурирате задачите за миграција. Клиентот исто така управува со целиот процес независно и времето на миграција е сведено на минимум.

Шема за мигрирање на виртуелни машини од приватна инсталација во облак.

VMware vCloud Availability има многу други случаи на употреба; наскоро ќе зборуваме за нив во посебна статија.

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

За да изберете алатка и всушност да започнете со мигрирање, треба да одлучите за следниве точки:

Од каде мигрираме? Ако мигрирате од приватно решение, тогаш имате целосна слобода во изборот на алатки. Ако се оддалечите од вашиот провајдер, тогаш е покомплицирано. Најверојатно, поврзувањето на инфраструктурите на два провајдери и едноставното влечење и пуштање на VM нема да функционира поради безбедносни причини. Понекогаш давателот на услуги што клиентот ќе го одбие почнува да биде палав и да застане со времето. Можете да се оддалечите од провајдерот на старомоден начин: со поставување на VM на дискови и FTP или со мигрирање на ниво на апликација. Името на второто е условно, и изгледа вака.

Случај 3
Беше неопходно да се мигрира SAP системот на клиентот од европски провајдер: 34 VM со капацитет од 54 TB. На клиентот му беа доделени ресурси во нашиот облак. Беше организирано мрежно поврзување помеѓу нас и инфраструктурата на европскиот провајдер. Апликативните сервери беа повторно распоредени, со превртени потребните конфигурации. Големи бази на податоци беа мигрирани преку поставување резервни копии во нашиот облак. Следно, репликацијата беше конфигурирана помеѓу базите на податоци на нашите и оригиналните сајтови. Во договореното време, се префрливме на бази на податоци во нашиот облак.

Обем на податоци и Интернет канал. Ние обично бараме од клиентот да обезбеди поставување по систем со параметри на меморија, процесор и диск. Проценуваме дали каналот е доволен за директно испраќање реплики или резервни копии на виртуелни машини.

Прифатливо застој. За различни системи и, соодветно, виртуелни машини, може да биде различно во зависност од нивната деловна критичност. Обично клиентот доаѓа со готови барања за застој за време на миграцијата, и врз основа на тоа ја избираме соодветната алатка и планот за миграција. Се обидуваме да го закажеме последното префрлување ноќе или за време на викендите, така што дури и малите прекини не се забележливи за крајните корисници на клиентот.

Врз основа на овие податоци, можете да изберете алатка и да ја започнете самата миграција. Еве што се случува понатаму.

1. Поставување мрежно поврзување. Ние организираме мрежно поврзување помеѓу нашиот облак и инфраструктурата на клиентот. Виртуелните машини ќе се копираат преку оваа мрежа. Ако се користи Veeam Backup and Replication, тогаш ова е посветен канал, поретко VPN канал. Ако Veeam Cloud Connect, тогаш сè оди преку Интернет или истиот посветен канал.

   Потоа мрежата е конфигурирана за VM во облакот. Автомобилите обично се движат во групи и повеќе од еден ден. Откако ќе ни се донесат VM и ќе бидат пуштени во употреба, тие мора да комуницираат со машините што сè уште остануваат на првобитната локација.

2. Распоред за миграција. Кога има многу автомобили, има смисла да се поделат во групи и да се транспортираат во серии. Заедно со клиентот, се согласуваме за план во кој одредуваме кога и кои машини ќе се движат и кога ќе се изврши конечната репликација и префрлање на новата локација.
3. Тест миграција. Ја мигрираме тестната виртуелна машина и проверуваме дали сè е правилно конфигурирано: мрежно поврзување помеѓу локациите, достапност на виртуелната машина до машините на изворната локација, права на сметката итн. Овој тест помага да се избегнат пречки во фазата на борбена миграција.

Тоа е се за мене. Во коментарите, поставувајте прашања и кажете ни за вашето искуство со миграцијата.

Извор: www.habr.com