Circa 7 anni fa, i primi progetti sono stati trasferiti sul nostro cloud in modo semplice e intuitivo. Le immagini delle macchine virtuali venivano caricate su un server FTP o importate su dischi rigidi. Quindi, tramite uno speciale server di importazione, le VM venivano caricate sul cloud.
Se per il cliente non è un problema disattivare la macchina virtuale per un giorno o due (o non ci sono altre opzioni), allora è possibile. Ma se il tempo di inattività dovesse durare al massimo un'ora, questo metodo non funzionerà. Oggi vi spiegherò quali strumenti vi aiuteranno a migrare verso il cloud con tempi di inattività minimi e come organizziamo il processo di migrazione.
Migrazione con Veeam Backup and Replication
Veeam Backup and Replication è noto a tutti come strumento per la creazione di backup e repliche. Lo utilizziamo per la migrazione tra le nostre sedi e per spostare i clienti dalla virtualizzazione privata al nostro cloud. Le macchine virtuali dei clienti vengono replicate sul nostro vCenter, dopodiché il tecnico le aggiunge a vCloud Director.
La replica iniziale viene eseguita su una macchina virtuale in esecuzione. All'orario concordato, la macchina lato client viene spenta. La replica viene riavviata per trasferire le modifiche apportate dalla prima replica. Successivamente, la macchina virtuale viene avviata nel nostro cloud.
In genere, dal momento in cui una macchina viene spenta sull'infrastruttura del cliente fino a quando viene accesa nel nostro cloud, non passa più di mezz'ora, ovvero 15-20 minuti.
In questo caso, la macchina virtuale originale rimane sul sito del cliente. Se qualcosa va storto, è sempre possibile eseguire il rollback e riattivarla. Questo metodo è comodo anche per il cliente perché non richiede Veeam.
Caso 1
Il cliente disponeva di una propria infrastruttura virtuale basata su VMware: 40 VM con una capacità di 30 TB. Le apparecchiature su cui era distribuito il cluster erano già obsolete e il cliente ha deciso di non acquistare nuove apparecchiature e di passare a un cloud pubblico. Il downtime dei sistemi critici non superava l'ora. La scelta è ricaduta su Veeam Replication. Un altro vantaggio è stato la presenza del provider Internet del cliente nel nostro data center, il che ci ha permesso di organizzare un canale di comunicazione efficiente. La migrazione ha richiesto circa un mese e il downtime durante il passaggio è stato fino a 30 minuti per gruppo di macchine virtuali.
Migrazione con Veeam Cloud Connect
Veeam Cloud Connect è uno strumento che aiuta a configurare la replica delle macchine virtuali e ad avviare le repliche nel cloud del provider di servizi. Dopo l'aggiornamento a anno, è diventato possibile replicare le macchine virtuali direttamente su vCloud Director. L'unica condizione è che il lato client disponga di una propria Veeam Backup and Replication, versione 9 o successiva, distribuita. In breve (versione dettagliata) ), allora l'intero processo si presenta così.
In vCloud Director, viene creata un'organizzazione con le risorse e le reti necessarie. In Veeam Cloud Connect, creiamo un account, il cliente si connette tramite il proprio Veeam B&R, seleziona il provider DataLine e l'organizzazione e configura le attività di replica. Oltre al fatto che con una migrazione di questo tipo, il downtime sarà di soli 15-20 minuti, il cliente non dipende dal supporto tecnico del provider e gestisce l'intero processo in modo indipendente: crea le attività di replica, esegue la replica stessa, spegne le macchine e le avvia sul nuovo sito.
Caso 2
L'infrastruttura del cliente, da cui era stata pianificata la migrazione, si trovava in Bielorussia. Era necessario spostare 90 VM con un volume totale di 27 TB, dato che il canale Internet era a 100 Mbit/sec. Se si esegue un backup e lo si carica immediatamente sul nostro cloud, per alcune VM ci vorrebbero diversi giorni. Durante questo periodo, si verificherebbe un delta significativo sulla VM, con conseguente impatto negativo sulle prestazioni delle macchine o, peggio ancora, l'esaurimento dello spazio sul datastore. Abbiamo agito come segue: innanzitutto, il cliente ha eseguito un backup completo locale e ne ha trasferito una copia sul nostro cloud tramite Veeam Cloud Connect. Quindi ha eseguito e trasferito un incremento nel cloud. La macchina virtuale originale ha continuato a funzionare. Dopo aver spento la VM, il cliente ha eseguito un altro incremento e lo ha trasferito anch'esso nel cloud. Da parte nostra, abbiamo distribuito una macchina virtuale da un backup completo e poi vi abbiamo aggiunto due incrementi. Questo schema ci ha permesso di ridurre al minimo i tempi di inattività a 2 ore durante il passaggio alla nostra sede.
Migrazione con VMware vCloud Availability
A marzo di quest'anno, VMware ha rilasciato vCloud Availability 3.0, che consente la migrazione delle macchine virtuali tra diversi cloud (vCloud Director - vCloud Director) e da sistemi di virtualizzazione client privati al cloud (vCenter - vCloud Director). La principale comodità è l'integrazione con l'interfaccia di vCloud Director. Ciò semplifica notevolmente il processo di gestione della replica e riduce al minimo i tempi di inattività durante il passaggio da un sistema all'altro.
Abbiamo utilizzato questo strumento per migrare uno dei nostri clienti dal cloud di Mosca al cloud di San Pietroburgo. Dovevamo spostare 18 macchine virtuali con una capacità totale di 14 TB. È stata creata un'organizzazione per il cliente nel cloud di San Pietroburgo e sono state organizzate le reti necessarie. Quindi, dall'interfaccia di vCloud Director, il cliente è andato alle impostazioni di disponibilità di vCloud, ha creato attività di replica ed è passato al sito di San Pietroburgo in un momento opportuno. Il tempo di inattività durante il passaggio è stato di 12 minuti.
Schema di migrazione tra i cloud DataLine di San Pietroburgo e Mosca.
vCloud Availability dispone di un meccanismo per la migrazione delle VM dal sito del cliente al nostro cloud. A tale scopo, un'applicazione vCloud Availability dedicata viene distribuita nel vCenter del cliente. Dopo una semplice configurazione, viene stabilita una connessione al cloud e vengono configurate le attività di migrazione. Il cliente gestisce inoltre in modo indipendente l'intero processo, riducendo al minimo i tempi di migrazione.
Schema di migrazione di macchine virtuali da un'installazione privata al cloud.
VMware vCloud Availability ha molti altri casi d'uso, ne parleremo presto in un articolo separato.
Prepararsi alla migrazione
Per selezionare uno strumento e avviare effettivamente la migrazione, è necessario decidere i seguenti punti:
Da dove migriamo? Se si migra da una soluzione privata, si ha completa libertà nella scelta degli strumenti. Se si abbandona un provider, la situazione è più complessa. Molto probabilmente, non sarà possibile collegare le infrastrutture di due provider e semplicemente trascinare la VM per motivi di sicurezza. A volte il provider che il cliente sta per abbandonare inizia a comportarsi male e a perdere tempo. È possibile abbandonare un provider alla vecchia maniera: scaricando la VM su dischi e FTP o migrando a livello di applicazione. Il nome di quest'ultima opzione è arbitrario e assomiglia a questo.
Caso 3
Era necessario migrare il sistema SAP di un cliente da un provider europeo: 34 VM con una capacità di 54 TB. Al cliente sono state assegnate risorse nel nostro cloud. È stata organizzata la connettività di rete tra noi e l'infrastruttura del provider europeo. I server applicativi sono stati ridistribuiti, con le configurazioni necessarie implementate. Sono stati migrati database di grandi dimensioni caricando i backup nel nostro cloud. Quindi è stata configurata la replica tra i database sui nostri siti e quelli originali. Alla data concordata, siamo passati ai database nel nostro cloud.
Volume di dati e canale Internet. Solitamente chiediamo al cliente di fornire un dump dei sistemi con i parametri di memoria, CPU e dischi. Valutiamo se il canale è sufficiente per inviare direttamente repliche o backup delle macchine virtuali.
Tempi di inattività accettabili. Per sistemi diversi e, di conseguenza, macchine virtuali, la situazione può variare a seconda della loro criticità per l'azienda. Di solito, il cliente presenta requisiti predefiniti per i tempi di inattività durante la migrazione e, in base a questi, selezioniamo lo strumento e il piano di migrazione più appropriati. Cerchiamo di pianificare la migrazione finale durante la notte o nei fine settimana, in modo che anche i tempi di inattività più brevi non siano percepibili dagli utenti finali del cliente.
Sulla base di questi dati, è possibile selezionare uno strumento e procedere alla migrazione vera e propria. Ecco cosa succede dopo.
- Impostazione della connettività di rete. Organizziamo la connettività di rete tra il nostro cloud e l'infrastruttura del cliente. Le macchine virtuali verranno copiate su questa rete. Se si utilizza Veeam Backup and Replication, si tratta di un canale dedicato, meno spesso di un canale VPN. Se si utilizza Veeam Cloud Connect, tutto avviene tramite Internet o lo stesso canale dedicato.
Successivamente, viene configurata la rete per le VM nel cloud. Le macchine vengono solitamente spostate in batch e in un arco di tempo definito. Una volta trasferite e rese operative, le VM devono comunicare con le macchine ancora presenti nel sito originale.
- Calendario delle migrazioni. Quando ci sono molte macchine, ha senso suddividerle in gruppi e trasportarle in lotti. Insieme al cliente, concordiamo un piano in cui specifichiamo quando e quali macchine verranno spostate e quando verrà eseguita la replicazione finale e il passaggio al nuovo sito.
- Migrazione di prova. Eseguiamo la migrazione di una macchina virtuale di prova e verifichiamo che tutto sia configurato correttamente: connettività di rete tra i siti, accessibilità della macchina virtuale per le macchine sul sito di origine, diritti dell'account, ecc. Tale test aiuta a evitare intoppi nella fase di migrazione del combattimento.
Per ora è tutto. Fate domande e raccontateci la vostra esperienza di migrazione nei commenti.
Fonte: habr.com
