Fa uns 7 anys, els primers projectes es van traslladar al nostre núvol de manera senzilla i sense pretensions. Les imatges de màquines virtuals es van penjar a un servidor FTP o es van lliurar en discs durs. Després, a través d'un servidor d'importació especial, les VM es van penjar al núvol.
Si no és un problema per al client apagar la màquina virtual durant un dia o dos (o no hi ha altres opcions), això es pot fer. Però si el temps d'inactivitat ha de ser d'un màxim d'una hora, aquest mètode no funcionarà. Avui us explicaré quines eines us ajudaran a migrar al núvol amb un temps d'inactivitat mínim i com funciona el nostre procés de migració.
Migració amb Veeam Backup and Replication
Tothom coneix Veeam Backup and Replication com una eina per crear còpies de seguretat i rèpliques. L'utilitzem per a la migració entre els nostres llocs i per transportar clients de la virtualització privada al nostre núvol. Les màquines virtuals del client es repliquen al nostre vCenter, després de la qual cosa l'enginyer les afegeix a vCloud Director.
La rèplica principal es produeix en una màquina virtual encesa. A l'hora convinguda, la màquina del costat del client s'apaga. La replicació es torna a executar per transferir els canvis que s'han produït des de la primera rèplica. Després d'això, la màquina virtual s'inicia al nostre núvol.
Normalment, des del moment en què s'apaga la màquina a la infraestructura del client fins que s'encén al nostre núvol, no passa més de mitja hora, sinó de 15 a 20 minuts.
En aquest cas, la màquina virtual original roman al lloc del client. Si de sobte alguna cosa va malament, sempre podeu tornar enrere i activar-lo. Aquest mètode també és convenient per al client, ja que no requereix que tingui Veeam.
Cas 1
El client tenia la seva pròpia infraestructura virtual basada en VMware: 40 VM amb una capacitat de 30 TB. L'equip en què es va desplegar el clúster ja estava obsolet, i el client va decidir no molestar-se en comprar-ne de nous i es va traslladar al núvol públic. El requisit de temps d'inactivitat per als sistemes crítics no va ser superior a una hora. Es va triar Veeam Replication com a eina. Un altre avantatge va ser que el proveïdor d'Internet del client estava present al nostre centre de dades, cosa que va permetre organitzar un bon canal. La migració va durar aproximadament un mes, el temps d'inactivitat durant el canvi va ser de fins a 30 minuts per grup de màquines virtuals.
Migra amb Veeam Cloud Connect
Veeam Cloud Connect és una eina que us ajuda a configurar la rèplica de màquines virtuals i llançar rèpliques al núvol del proveïdor de serveis. Després d'actualitzar a any, va ser possible replicar màquines virtuals directament a vCloud Director. L'única condició és que al costat del client, Veeam Backup and Replication s'hagi de desplegar com a mínim la versió 9. En resum (versió detallada ), aleshores tot el procés es veu així.
A vCloud Director, es crea una organització amb els recursos i xarxes necessaris. A Veeam Cloud Connect, creem un compte, el client s'hi connecta des del seu Veeam B&R, selecciona un proveïdor i una organització de DataLine i configura les tasques per a la replicació. A més del fet que durant aquesta migració, el temps d'inactivitat serà d'entre 15 i 20 minuts, el client no depèn de cap manera del suport tècnic del proveïdor i gestiona tot el procés de manera independent: crea tasques de rèplica, la rèplica mateixa s'apaga. les màquines i les engega al nou lloc.
Cas 2
La infraestructura del client, des d'on es va planificar la migració, es trobava a Bielorússia. Va ser necessari transportar 90 VM amb un volum total de 27 TB, malgrat que el canal d'Internet era de 100 Mbit/s. Si feu una còpia de seguretat i la pengeu immediatament al nostre núvol, per a algunes màquines virtuals trigarien diversos dies. Durant aquest temps, hauria crescut un gran delta a la VM, i això podria tenir un impacte negatiu en el rendiment de les màquines o, pitjor encara, s'hauria esgotat l'espai al magatzem de dades. Vam procedir de la següent manera: primer, el client va fer una còpia de seguretat local completa i en va transferir una còpia al nostre núvol mitjançant Veeam Cloud Connect. Llavors vaig fer i transferir l'increment al núvol. La màquina virtual original va continuar funcionant. Després d'apagar la VM, el client va fer un altre increment i també el va transferir al núvol. Al nostre costat, vam desplegar una màquina virtual a partir d'una còpia de seguretat completa i, després, hi vam fer dos increments. Aquest esquema va permetre, finalment, minimitzar el temps d'inactivitat a 2 hores en canviar al nostre lloc.
Migració amb VMware vCloud Availability
El març d'aquest any, VMware va llançar vCloud Availability 3.0, que permet migrar màquines virtuals entre diferents núvols (vCloud Director - vCloud Director) i des de suports de virtualització de clients privats al núvol (vCenter - vCloud Director). La principal comoditat és la integració amb la interfície de vCloud Director. Això simplifica molt el procés de gestió de la rèplica i minimitza el temps d'inactivitat durant els canvis.
Amb aquesta eina, vam migrar un dels clients del nostre núvol de Moscou al nostre núvol de Sant Petersburg. Va ser necessari transportar 18 màquines virtuals amb una capacitat total de 14 TB. Es va crear una organització per al client al núvol de Sant Petersburg i es van organitzar les xarxes necessàries. A continuació, des de la interfície de vCloud Director, el client va anar a la configuració de la disponibilitat de vCloud, va crear treballs de rèplica i va canviar al lloc de Sant Petersburg en un moment convenient per a ell. El temps d'inactivitat durant el canvi va ser de 12 minuts.
Esquema de migració entre els núvols de DataLine a Sant Petersburg i Moscou.
vCloud Availability té un mecanisme per migrar VMs del lloc del client al nostre núvol. Per fer-ho, es desplega una aplicació especial de disponibilitat de vCloud al vCenter del client. Després d'una configuració senzilla, us connecteu al núvol i configureu les tasques de migració. El client també gestiona tot el procés de manera independent i el temps de migració es redueix al mínim.
Esquema per migrar màquines virtuals d'una instal·lació privada al núvol.
VMware vCloud Availability té molts altres casos d'ús; aviat en parlarem en un article separat.
Preparació per a la migració
Per triar una eina i començar a migrar, heu de decidir els punts següents:
D'on migrem? Si esteu migrant des d'una solució privada, teniu total llibertat per triar les eines. Si us allunyeu del vostre proveïdor, és més complicat. El més probable és que enllaçar les infraestructures de dos proveïdors i simplement arrossegar i deixar anar una màquina virtual no funcionarà per motius de seguretat. De vegades, el proveïdor que el client està a punt de rebutjar comença a ser entremaliat i s'atura el temps. Podeu allunyar-vos del proveïdor de la manera antiga: carregant màquines virtuals a discs i FTP, o migrant a nivell d'aplicació. El nom d'aquest últim és condicional i sembla una cosa així.
Cas 3
Va ser necessari migrar el sistema SAP del client des d'un proveïdor europeu: 34 VMs amb una capacitat de 54 TB. Al client se li van assignar recursos al nostre núvol. La connectivitat de xarxa es va organitzar entre nosaltres i la infraestructura del proveïdor europeu. Els servidors d'aplicacions es van tornar a desplegar i es van renovar les configuracions necessàries. Es van migrar grans bases de dades mitjançant la càrrega de còpies de seguretat al nostre núvol. A continuació, es va configurar la replicació entre les bases de dades del nostre i dels llocs originals. A l'hora convinguda, vam canviar a les bases de dades al nostre núvol.
Volum de dades i canal d'Internet. Normalment demanem al client que proporcioni una càrrega per sistema amb paràmetres de memòria, CPU i disc. Avaluem si el canal és suficient per enviar directament rèpliques o còpies de seguretat de màquines virtuals.
Temps d'inactivitat acceptable. Per a diferents sistemes i, en conseqüència, màquines virtuals, pot ser diferent en funció de la seva criticitat empresarial. Normalment, el client ve amb requisits ja preparats per al temps d'inactivitat durant la migració, i en funció d'això seleccionem l'eina i el pla de migració adequats. Intentem programar el canvi final a la nit o els caps de setmana de manera que fins i tot els temps d'inactivitat menors no es notin als usuaris finals del client.
A partir d'aquestes dades, podeu seleccionar una eina i començar la migració. Aquí teniu el que passa a continuació.
- Configuració de la connectivitat de xarxa. Organitzem la connectivitat de xarxa entre el nostre núvol i la infraestructura del client. Les màquines virtuals es copiaran en aquesta xarxa. Si s'utilitza Veeam Backup and Replication, aquest és un canal dedicat, menys sovint un canal VPN. Si Veeam Cloud Connect, tot passa per Internet o pel mateix canal dedicat.
A continuació, la xarxa es configura per a la VM al núvol. Els cotxes solen moure's en grup i durant més d'un dia. Un cop les màquines virtuals ens han portat i llançades, s'han de comunicar amb les màquines que encara romanen al lloc original.
- Calendari de migració. Quan hi ha molts cotxes, té sentit dividir-los en grups i transportar-los per lots. Amb el client acordem un pla en el qual especifiquem quan i quines màquines es traslladaran i quan es realitzarà la replicació final i el canvi al nou lloc.
- Prova de migració. Migrem la màquina virtual de prova i comprovem si tot està configurat correctament: connectivitat de xarxa entre llocs, disponibilitat de la màquina virtual a les màquines del lloc d'origen, drets de compte, etc. Aquesta prova ajuda a evitar problemes en l'etapa de migració de combat.
Això és tot per a mi. Als comentaris, feu preguntes i expliqueu-nos la vostra experiència de migració.
Font: www.habr.com
