Acum 7 ani, cele mai vechi proiecte se mutau în cloud-ul nostru simplu și fără complicații. Imaginile mașinilor virtuale erau încărcate pe un server FTP sau erau aduse pe discuri dure. Apoi, printr-un server special de import, mașinile virtuale erau încărcate în cloud.
Dacă pentru client nu este o problemă să oprească mașina virtuală pentru o zi sau două (sau dacă nu există alte opțiuni), se poate face și așa. Dar dacă oprirea trebuie să dureze maximum o oră, atunci această metodă nu este adecvată. Astăzi voi vorbi despre ce instrumente ajută la migrarea în cloud cu un timp de nefuncționare minim și despre cum funcționează procesul de migrare la noi.

Migrarea cu ajutorul Veeam Backup and Replication
Toată lumea cunoaște Veeam Backup and Replication ca un instrument pentru crearea de backup-uri și replici. Noi îl folosim pentru migrarea între platformele noastre și pentru a transfera clienți de la virtualizarea privată la cloud-ul nostru. Mașinile virtuale ale clientului sunt replicate pe vCenter-ul nostru, după care inginerul le adaugă în vCloud Director.
Replicarea inițială se efectuează pe mașina virtuală activă. La un moment convenit, mașina de partea clientului este oprită. Replicarea este reluată pentru a transfera modificările apărute de la prima replicare. După aceea, mașina virtuală pornește deja în cloud-ul nostru.

De obicei, de la momentul opririi mașinii în infrastructura clientului și până la momentul activării în cloud-ul nostru nu trec mai mult de o jumătate de oră, ci mai degrabă 15–20 de minute.
În acest proces, pe site-ul clientului rămâne mașina virtuală originală. Dacă se întâmplă ceva neașteptat, se poate întotdeauna reveni și activa ea. Pentru client, acest mod este convenabil și pentru că nu necesită prezența Veeam.
Cazul 1
Clientul avea propria infrastructură virtuală bazată pe VMware – 40 de mașini virtuale cu un volum de 30 TB. Echipamentul pe care a fost desfășurat clusterul era deja învechit, iar clientul a decis să nu se mai complice cu achiziția de echipamente noi și să se mute în cloud-ul public. Cerința privind timpul de nefuncționare pentru sistemele critice a fost de maximum o oră. Ca instrument, a fost ales Veeam Replication. Un alt avantaj a fost că furnizorul de internet al clientului era prezent în centrul nostru de date, ceea ce a permis organizarea unei bune conexiuni. Migrarea a durat aproximativ o lună, timpul de nefuncționare în timpul comutării fiind de până la 30 de minute pentru un grup de mașini virtuale.
Migrarea cu ajutorul Veeam Cloud Connect
Veeam Cloud Connect – un instrument care ajută la configurarea replicării mașinilor virtuale și la lansarea replicilor în cloud-ul furnizorului de servicii. După actualizarea din anul acesta, a apărut posibilitatea de a replica mașinile virtuale direct în vCloud Director. Singura condiție este ca de partea clientului să existe un Veeam Backup and Replication desfășurat cu versiunea de 9 sau mai recentă. Pe scurt (versiunea detaliată ), procesul arată astfel.
În vCloud Director se creează o organizație cu resurse și rețele necesare. În Veeam Cloud Connect creăm un cont, clientul se conectează la acesta din Veeam B&R, alege furnizorul DataLine și organizația, configurând sarcinile pentru replicare. Pe lângă faptul că migrarea durează între 15–20 de minute, clientul nu depinde de suportul tehnic al furnizorului și gestionează întregul proces autonom: creează sarcini de replicare, realizarea replicării, oprește mașinile și le pornește în noua locație.

Caz 2
Infrastructura clientului, de unde era planificată migrarea, se afla în Belarus. Era necesar să transportăm 90 de VM cu un volum total de 27 TB, având în vedere că canalul de internet era de 100 Mbit/s. Dacă efectuăm backup-ul și îl transferăm imediat în cloud-ul nostru, pentru unele VM ar fi durat câteva zile. În acest timp, pe VM ar fi crescut o delta mare, ceea ce ar fi putut afecta negativ performanța mașinilor sau, și mai rău, să rămână fără spațiu pe datastore. Am procedat astfel: inițial, clientul a realizat un backup complet local și a transferat o copie în cloud-ul nostru prin Veeam Cloud Connect. Apoi a realizat și a transferat în cloud un incremental. Mașina virtuală originală continua să funcționeze. După oprirea VM, clientul a realizat încă un incremental și l-a transferat și pe acesta în cloud. De partea noastră, am desfășurat o mașină virtuală din backup-ul complet, apoi am aplicat cele două incrementale. Această schemă a permis în final să minimalizăm timpul de nefuncționare la 2 ore când am trecut pe platforma noastră.
Migrarea prin VMware vCloud Availability
În martie a acestui an, VMware a lansat vCloud Availability 3.0, care permite migrarea mașinilor virtuale între diferite clouduri (vCloud Director – vCloud Director) și de la standurile private de virtualizare ale clientului în cloud (vCenter – vCloud Director). Principalul avantaj este integrarea cu interfața vCloud Director. Acest lucru simplifică semnificativ procesul de gestionare a replicării și minimizează timpii de inactivitate în timpul comutării.
Cu ajutorul acestui instrument, am migrat unul dintre clienții noștri din cloudul nostru din Moscova în cloudul nostru din Sankt Petersburg. A fost necesar să mutăm 18 mașini virtuale cu o capacitate totală de 14 TB. Pentru client a fost creată o organizație în cloudul din Sankt Petersburg și au fost organizate rețelele necesare. Apoi, din interfața vCloud Director, clientul a trecut la setările vCloud Availability, a creat sarcini de replicare și s-a comutat pe platforma din Sankt Petersburg la un moment convenabil pentru el. Timpul de inactivitate în timpul comutării a fost de 12 minute.

Schema de migrare între cloudurile DataLine din Sankt Petersburg și Moscova.
În vCloud Availability există un mecanism de migrare a VM-urilor de la platforma clientului în cloudul nostru. Pentru aceasta, în vCenter-ul clientului se desfășoară un appliance special vCloud Availability. După o configurare simplă, se conectează la cloud și se configurează sarcinile de migrare. Clientul de asemenea gestionează întregul proces, iar timpul de migrare este minimizat.

Schema de migrare a mașinilor virtuale dintr-o instalație privată în cloud.
VMware vCloud Availability are multe alte scenarii de utilizare, și în curând vă vom povesti despre ele într-un articol separat.
Pregătirea pentru migrare
Pentru a alege instrumentul și a începe efectiv migrarea, trebuie să clarificăm următoarele aspecte:
De unde migrăm. Dacă migrați de la o soluție privată, aveți libertate totală în alegerea instrumentelor. Dacă părăsiți un furnizor, lucrurile devin mai complicate. Cel mai probabil, legarea infrastructurii a doi furnizori și pur și simplu mutarea VM-urilor nu va fi posibilă din motive de securitate. Uneori, furnizorul de la care clientul intenționează să plece începe chiar să facă probleme și câștigă timp. Părăsirea furnizorului se poate face în mod tradițional: prin descărcarea VM-urilor pe discuri și FTP sau migrând la nivel de aplicație. Numele ultimei metode este condițional, și arată cam așa.
Caz 3
A fost necesară migrarea sistemului SAP al clientului de la un furnizor european: 34 VM cu un volum de 54 TB. Clientului i-au fost alocate resurse în cloud-ul nostru. Între noi și infrastructura furnizorului european a fost organizată conectivitate de rețea. Serverele de aplicații au fost redeployment și configurate corespunzător. Baze de date mari au fost migrat prin încărcarea de backup-uri în cloud-ul nostru. Apoi, a fost configurată replicarea între bazele de date pe site-urile noastre și cele inițiale. La momentul convenit, am comutat pe bazele de date din cloud-ul nostru.
Volumul de date și canalul de internet. De obicei, cerem clientului să ne ofere o exportare a sistemelor cu parametrii de memorie, CPU, discuri. Evaluăm dacă canalul este suficient pentru a trimite direct replicile sau backup-urile mașinilor virtuale.
Timpul de nefuncționare acceptabil. Pentru diferite sisteme și, respectiv, mașini virtuale, acesta poate varia în funcție de criticitatea lor pentru afacere. De obicei, clientul vine cu cerințe clare în legătură cu timpul de nefuncționare în timpul migrației, iar pe baza acestora alegem instrumentul și planul de migrare potrivit. Ne străduim să planificăm comutarea finală pentru timpul de noapte sau weekenduri, astfel încât chiar și un timp de nefuncționare minor să nu fie observat de utilizatorii finali ai clientului.
Pe baza acestor date, se pot alege instrumentele și poate începe migrarea propriu-zisă. Iată ce se întâmplă mai departe.
- Configurarea conectivității de rețea. Organizăm conectivitatea de rețea între cloud-ul nostru și infrastructura clientului. Prin această rețea vor fi copiate mașinile virtuale. Dacă se folosește Veeam Backup and Replication, atunci este un canal dedicat, mai rar – un canal VPN. Dacă se folosește Veeam Cloud Connect, atunci totul trece prin internet sau același canal dedicat.
Apoi se configurează rețeaua pentru VM în cloud. Mașinile se mută de obicei în grupuri și nu într-o singură zi. După ce VM-urile au fost transferate la noi și au fost lansate, acestea trebuie să interacționeze cu mașinile care rămân încă pe site-ul inițial.
- Programul de migrare. Când sunt multe mașini, este rezonabil să le împărțim în grupuri și să le transportăm în loturi. Împreună cu clientul, stabilim un plan în care definim când și ce mașini se mută și când va avea loc replicarea finală și comutarea pe noua platformă.
- Migrarea de test. Migremos mașina virtuală de test și verificăm dacă totul este corect configurat: conectivitatea rețelei între locații, disponibilitatea mașinii virtuale pentru mașinile din locația inițială, drepturile contului și altele. Un astfel de test ajută la evitarea întârzierilor în etapa migrației în producție.
Asta e tot din partea mea. Întrebați în comentarii și povestiți despre experiența voastră cu migrarea.
Sursa: habr.com
