Circa 7 anni fa, i primi progetti trasferivano nel nostro cloud in modo semplice e diretto. Le immagini delle macchine virtuali venivano caricate su un server FTP o portate su dischi rigidi. Successivamente, attraverso un server di importazione speciale, le VM venivano caricate nel cloud.
Se per il cliente non è un problema spegnere la virtual machine per uno o due giorni (o non ci sono altre opzioni), si può procedere così. Ma se il downtime deve essere massimo di un’ora, questo metodo non è adatto. Oggi parlerò degli strumenti che aiutano a migrare nel cloud con il minimo downtime e di come si svolge il processo di migrazione da noi.
Migrazione con Veeam Backup and Replication
Veeam Backup and Replication è conosciuto da tutti come uno strumento per la creazione di backup e repliche. Lo utilizziamo per la migrazione tra le nostre piattaforme e per il trasferimento dei clienti dalla virtualizzazione privata al nostro cloud. Le macchine virtuali dei clienti vengono replicate sul nostro vCenter, dopo di che gli ingegneri le aggiungono al vCloud Director.
La replica primaria viene eseguita su una macchina virtuale accesa. A un orario concordato, la macchina dal lato del cliente viene spenta. La replica viene riavviata per trasferire le modifiche avvenute dall'ultima replica. Dopo di che, la macchina virtuale parte già nel nostro cloud.
Di solito, non passa più di mezz'ora da quando la macchina viene spenta nell'infrastruttura del cliente fino al suo riavvio nel nostro cloud, generalmente si tratta di 15–20 minuti.
Nel frattempo, la macchina virtuale originale rimane presso il cliente. Se qualcosa non funziona, è sempre possibile tornare indietro e riaccenderla. Per il cliente, questo metodo è anche comodo poiché non richiede l'utilizzo di Veeam.
Caso 1
Il cliente aveva la propria infrastruttura virtuale basata su VMware con 40 VM e 30 TB di spazio. L'hardware su cui era stato implementato il cluster era già obsoleto, e il cliente ha deciso di non affrontare l'acquisto di nuovo hardware, ma di migrare nel cloud pubblico. La richiesta di inattività dei sistemi critici non doveva superare un'ora. Come strumento è stata scelta Veeam Replication. Un vantaggio ulteriore era che il provider di servizi Internet del cliente era presente nel nostro datacenter, il che ha permesso di organizzare un buon canale. La migrazione ha richiesto circa un mese, con un'inattività durante il passaggio che è stata di massimo 30 minuti per un gruppo di macchine virtuali.
Migrazione tramite Veeam Cloud Connect
Veeam Cloud Connect è uno strumento che aiuta a configurare la replica delle macchine virtuali e a avviare repliche nel cloud del fornitore di servizi. Dopo l'aggiornamento nel anno è stata introdotta la possibilità di replicare le macchine virtuali direttamente in vCloud Director. L'unica condizione è che sul lato cliente deve essere installato il proprio Veeam Backup and Replication non inferiore alla versione 9. In breve (versione dettagliata ), il processo appare nel seguente modo.
In vCloud Director, si crea un'organizzazione con le risorse e le reti necessarie. In Veeam Cloud Connect, creiamo un account, il cliente si collega tramite il proprio Veeam B&R, seleziona il fornitore DataLine e l'organizzazione, e configura i lavori per la replica. Oltre al fatto che durante questa migrazione il downtime sarà entro i 15-20 minuti, il cliente non dipende in alcun modo dal supporto tecnico del fornitore e gestisce l'intero processo autonomamente: crea lavori per la replica, effettua la replica stessa, spegne le macchine e le riavvia nella nuova sede.
Caso 2
L'infrastruttura del cliente, da cui era pianificata la migrazione, si trovava in Bielorussia. Era necessario trasferire 90 VM con un volume totale di 27 TB, considerando che la connessione Internet era di 100 Mbit/s. Se avessimo fatto un backup e subito caricato nel nostro cloud, per alcune VM ci sarebbero voluti diversi giorni. Durante quel tempo, sarebbe cresciuto un grande delta, il che potrebbe aver avuto un impatto negativo sulle prestazioni delle macchine o, peggio ancora, lo spazio nel datastore sarebbe finito. Abbiamo agito nel seguente modo: inizialmente, il cliente ha effettuato un backup completo locale e ha trasferito una copia nel nostro cloud tramite Veeam Cloud Connect. Poi ha creato e trasferito un incremento nel cloud. La VM originale ha continuato a funzionare. Dopo aver spento la VM, il cliente ha effettuato un altro incremento e lo ha trasferito anche nel cloud. Da parte nostra, abbiamo ripristinato la VM dal backup completo e poi abbiamo applicato i due incrementi. Questo schema ha permesso di ridurre al minimo il downtime a 2 ore durante il passaggio alla nostra piattaforma.
Migrazione utilizzando VMware vCloud Availability
A marzo di quest'anno, VMware ha rilasciato vCloud Availability 3.0, che consente di migrare le macchine virtuali tra diverse nuvole (vCloud Director – vCloud Director) e dai stand privati di virtualizzazione del cliente verso il cloud (vCenter – vCloud Director). Il principale vantaggio è l'integrazione con l'interfaccia di vCloud Director. Questo semplifica notevolmente il processo di gestione della replica e riduce al minimo i tempi di inattività durante il failover.
Con questo strumento abbiamo migrato un nostro cliente dal nostro cloud di Mosca al nostro cloud di San Pietroburgo. Era necessario trasferire 18 macchine virtuali per un totale di 14 TB. È stata creata un'organizzazione per il cliente nel cloud di San Pietroburgo e sono state organizzate le reti necessarie. Successivamente, attraverso l'interfaccia di vCloud Director, il cliente è passato alle impostazioni di vCloud Availability, ha creato attività di replicazione e, nel momento a lui più conveniente, ha effettuato il failover sulla sede di San Pietroburgo. Il tempo di inattività durante il failover è stato di 12 minuti.
Schema di migrazione tra i cloud DataLine di San Pietroburgo e Mosca.
In vCloud Availability, there is a mechanism for migrating VMs from the client's site to our cloud. For this, a special vCloud Availability appliance is deployed in the client's vCenter. After a simple setup, a connection to the cloud is established, and migration tasks are configured. The client also independently manages the entire process, minimizing migration time.
Migration scheme of virtual machines from a private installation to the cloud.
VMware vCloud Availability has many other use case scenarios, which we will soon discuss in a separate article.
Preparation for migration
To choose the right tool and begin the migration, you need to clarify the following points:
Where we are migrating from. Se stai migrando da una soluzione privata, hai piena libertà nella scelta degli strumenti. Se invece stai lasciando un provider, la situazione è più complessa. Probabilmente, collegare le infrastrutture di due provider e semplicemente spostare la VM non sarà possibile per motivi di sicurezza. A volte, il provider dal quale il cliente intende migrare inizia a ostacolare il processo e a ritardarlo. Migrare da un provider può essere fatto nel modo tradizionale: scaricando la VM su dischi e FTP oppure migrando a livello applicativo. Quest'ultimo termine è solo indicativo, e si presenta all'incirca in questo modo.
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 allocate risorse nel nostro cloud. È stata organizzata la connettività di rete tra noi e l'infrastruttura del provider europeo. I server delle applicazioni sono stati ripristinati da zero, con le configurazioni necessarie applicate. Grandi database sono stati migrati attraverso il caricamento di backup nel nostro cloud. Successivamente, è stata impostata la replicazione tra i database sulle nostre e sulle piattaforme originali. All'orario concordato, abbiamo commutato sui database nel nostro cloud.
Volume dei dati e banda internet. Di solito chiediamo al cliente di fornire un'esportazione dai sistemi con le specifiche di memoria, CPU e dischi. Valutiamo se la larghezza di banda è sufficiente per inviare direttamente le repliche o i backup delle macchine virtuali.
Fermo consentito. Per diversi sistemi e, di conseguenza, per le macchine virtuali, il tempo di inattività può variare a seconda della loro criticità per il business. Di solito, il cliente arriva con requisiti specifici riguardo al fermo durante la migrazione, e sulla base di questo scegliamo lo strumento giusto e il piano di migrazione. Cerchiamo di pianificare il passaggio finale durante la notte o nei fine settimana, in modo che anche un breve fermo non sia percepito dagli utenti finali del cliente.
Sulla base di questi dati, possiamo scegliere lo strumento e procedere con la 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. Attraverso questa rete verranno copiati i virtual machine. Se si utilizza Veeam Backup e Replication, si tratta di un canale dedicato, più raramente – 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 solitamente vengono trasferite in gruppi e non in un solo giorno. Dopo che le VM sono state trasferite da noi e avviate, devono interagire con le macchine che rimangono ancora sul sito originale.
- Pianificazione della migrazione. Quando ci sono molte macchine, è sensato suddividerle in gruppi e trasportarle a lotti. Insieme al cliente, definiamo un piano che specifica quando e quali macchine vengono trasferite e quando sarà effettuata la replica finale e il passaggio al nuovo sito.
- Migrazione di prova. Migriamo 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 originale, diritti dell'account e altro. Questo test aiuta a evitare ritardi durante la migrazione reale.
Questo è tutto da parte mia. Lasciate domande nei commenti e condividete la vostra esperienza di migrazione.
Fonte: habr.com
