Operazione 'Migrazione': come avviene il trasferimento nel cloud di DataLine

Circa 7 anni fa, i primi progetti si trasferivano nel nostro cloud in modo semplice e diretto. Le immagini delle macchine virtuali venivano caricate su un server FTP, oppure venivano consegnate su dischi rigidi. Successivamente, tramite un server di importazione speciale, le VM venivano caricate nel cloud.

Se per il cliente non è un problema spegnere la virtual machine per un giorno o due (o se non ci sono altre opzioni), si può procedere in questo modo. Ma se il fermo deve essere al massimo di un'ora, questo metodo non è adatto. Oggi parlerò degli strumenti che possono aiutare a migrare nel cloud con un massimo di downtime e come è strutturato il processo di migrazione da noi.

Migrazione con Veeam Backup and Replication

Veeam Backup and Replication è conosciuto da tutti come strumento per creare backup e repliche. Lo utilizziamo per migrare tra le nostre sedi e per trasferire i clienti dalla virtualizzazione privata al nostro cloud. Le macchine virtuali del cliente vengono replicate sul nostro vCenter, dopodiché l'ingegnere le aggiunge a vCloud Director.

La replica iniziale viene eseguita su una macchina virtuale accesa. A un orario concordato, la macchina dal lato del cliente viene spenta. La replica viene avviata nuovamente per trasferire le modifiche avvenute dalla prima replica. Successivamente, la macchina virtuale viene avviata già nel nostro cloud.

Di solito, dal momento in cui si spegne la macchina nell'infrastruttura del cliente fino al momento in cui viene accesa nel nostro cloud non passano più di mezz'ora, anzi, piuttosto 15–20 minuti.

Nel frattempo, presso il cliente rimane la macchina virtuale originale. Se qualcosa non va come previsto, è sempre possibile tornare indietro e accenderla. Per il cliente questo metodo è anche vantaggioso poiché non richiede la presenza di Veeam.

Caso 1
Il cliente aveva la propria infrastruttura virtuale basata su VMware – 40 VM con un volume di 30 TB. 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 e di trasferirsi in un cloud pubblico. L'esigenza di downtime per i sistemi critici era di non più di un'ora. Come strumento è stata scelta Veeam Replication. Inoltre, è stato un vantaggio che il fornitore di servizi Internet del cliente fosse presente nel nostro centro dati, il che ha permesso di organizzare una buona connessione. La migrazione ha impiegato circa un mese, con un downtime di fino a 30 minuti per ogni gruppo di macchine virtuali.

Migrazione con Veeam Cloud Connect

Veeam Cloud Connect è uno strumento che aiuta a configurare la replicazione delle macchine virtuali e a avviare le repliche nel cloud del fornitore di servizi. Dopo l'aggiornamento nel 2019 anno è stata introdotta la possibilità di replicare le macchine virtuali direttamente in vCloud Director. L'unica condizione è che sul lato clienti deve essere implementato il proprio Veeam Backup and Replication non inferiore alla versione 9. In breve (versione dettagliata qui), l'intero processo appare come segue.

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 da Veeam B&R, seleziona il fornitore DataLine e l'organizzazione, quindi configura i job di replicazione. Oltre al fatto che con questa migrazione il downtime sarà di circa 15-20 minuti, il cliente non dipende in alcun modo dal supporto tecnico del fornitore e gestisce l'intero processo autonomamente: crea job di replicazione, la replicazione stessa, spegne le macchine e ne avvia l'accensione nella nuova sede.

Caso 2
L'infrastruttura del cliente, da cui era prevista la migrazione, si trovava in Bielorussia. Era necessario trasferire 90 VM per un volume totale di 27 TB, considerando che la banda internet era di 100 Mbit/s. Se si fosse effettuato un backup e successivamente caricato subito nel nostro cloud, per alcune VM ciò avrebbe richiesto diversi giorni. Durante quel tempo, la VM avrebbe accumulato un gran delta, il che potrebbe aver influito negativamente sulle prestazioni delle macchine o, peggio ancora, esaurito lo spazio nel datastore. Ci siamo mossi come segue: prima il cliente ha effettuato un backup completo locale e ha trasferito una copia nel nostro cloud tramite Veeam Cloud Connect. Poi ha effettuato e inviato un incremento nel cloud. La macchina virtuale originale ha continuato a funzionare. Dopo aver spento la VM, il cliente ha effettuato un altro incremento e l'ha trasferito nel cloud. Sul nostro lato abbiamo implementato una macchina virtuale dal backup completo, e poi abbiamo aggiunto due incrementi. Questa configurazione ha permesso di ridurre il downtime a 2 ore durante il passaggio nella nostra sede.

Migrazione tramite VMware vCloud Availability

A marzo di quest'anno, VMware ha rilasciato vCloud Availability 3.0, che consente di migrare macchine virtuali tra diversi cloud (vCloud Director – vCloud Director) e da stand privati di virtualizzazione dei clienti al cloud (vCenter – vCloud Director). La principale comodità è l'integrazione con l'interfaccia di vCloud Director. Questo semplifica notevolmente il processo di gestione della replicazione e riduce al minimo i tempi di inattività durante il cambiamento.

Con questo strumento abbiamo migrato uno dei clienti dal nostro cloud di Mosca al nostro cloud di San Pietroburgo. Era necessario trasferire 18 macchine virtuali con una capacità totale di 14 TB. Per il cliente è stata creata un'organizzazione nel cloud di San Pietroburgo e sono state organizzate le reti necessarie. Successivamente, dall'interfaccia di vCloud Director, il cliente è passato alle impostazioni di vCloud Availability, ha creato i compiti di replicazione e si è spostato sulla piattaforma di San Pietroburgo nel momento a lui più conveniente. Il tempo di inattività durante il cambio è stato di 12 minuti.

Schema di migrazione tra i cloud DataLine a San Pietroburgo e Mosca.

In vCloud Availability c'è un meccanismo di migrazione delle VM dalla piattaforma del cliente al nostro cloud. A questo scopo viene distribuito un appliance speciale di vCloud Availability nel vCenter del cliente. Dopo una semplice configurazione, viene stabilita la connessione con il cloud e sono impostati i compiti di migrazione. Inoltre, il cliente gestisce autonomamente l'intero processo, riducendo al minimo i tempi di migrazione.

Schema di migrazione delle macchine virtuali da un'installazione privata al cloud.

VMware vCloud Availability ha molti altri scenari di utilizzo, presto ne parleremo in un articolo separato.

Preparazione alla migrazione

Per scegliere lo strumento e iniziare la migrazione, è necessario definire i seguenti aspetti:

Da dove migriamo. Se stai migrando da una soluzione privata, hai piena libertà nella scelta degli strumenti. Se ti stai allontanando da un fornitore, la situazione è più complicata. È probabile che collegare le infrastrutture di due fornitori e semplicemente spostare le VM non sia possibile per motivi di sicurezza. A volte il fornitore da cui il cliente intende allontanarsi inizia a creare problemi e a perdere tempo. Uscire da un fornitore può avvenire nel modo tradizionale: tramite il trasferimento delle VM su dischi e FTP o migrando a livello applicativo. Quest'ultima modalità è detta così per convenzione e appare più o meno in questo modo.

Caso 3
È stato necessario migrare il sistema SAP del cliente da un fornitore europeo: 34 VM per un volume di 54 TB. Al cliente sono state assegnate risorse nel nostro cloud. È stata organizzata la connettività di rete tra noi e l'infrastruttura del fornitore europeo. I server delle applicazioni sono stati ridistribuiti, con l'applicazione delle configurazioni necessarie. Grandi basi di dati sono state migrate tramite il caricamento dei backup nel nostro cloud. Successivamente, è stata impostata la replicazione tra le basi di dati sulle nostre e sulla sede originale. All'orario concordato, abbiamo commutato le basi di dati nel nostro cloud.

Volume dei dati e canale internet. Di solito chiediamo al cliente di fornire un'estrazione dei sistemi con parametri di memoria, CPU e dischi. Valutiamo se il canale è sufficiente per inviare direttamente le repliche o i backup delle macchine virtuali.

Interruzione consentita. Per diversi sistemi e, di conseguenza, per macchine virtuali, può variare in base alla loro criticità per il business. Di solito, il cliente arriva con requisiti già definiti riguardo al fermo durante la migrazione, e sulla base di questi scegliamo lo strumento adeguato e il piano di migrazione. Cerchiamo di pianificare il passaggio finale durante la notte o nei fine settimana, in modo che anche un'interruzione minima non sia percepita dagli utenti finali del cliente.

In base a questi dati, è possibile scegliere lo strumento e procedere con la migrazione vera e propria. Ecco cosa succede dopo.

1. Impostazione della connettività di rete. Organizziamo la connettività di rete tra il nostro cloud e l'infrastruttura del cliente. Su questa rete verranno copiate le macchine virtuali. Se si utilizza Veeam Backup and Replication, si tratta di un canale dedicato, raramente di un canale VPN. Se si usa Veeam Cloud Connect, il tutto avviene tramite internet o lo stesso canale dedicato.

   Successivamente, viene impostata la rete per le VM nel cloud. Le macchine di solito si spostano 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 sulla sede originale.

2. Pianificazione della migrazione. Quando ci sono molte macchine, è ragionevole suddividerle in gruppi e trasportarle a lotti. Insieme al cliente, concordiamo un piano in cui dettagliamo quando e quali macchine vengono trasferite e quando sarà eseguita la replica finale e il passaggio alla nuova sede.
3. Migrazione di test. Migriamo una macchina virtuale di test e verifichiamo se tutto è correttamente configurato: connettività di rete tra i siti, disponibilità della macchina virtuale per le macchine nel sito di origine, diritti dell'account e altro. Questo test aiuta a evitare ritardi nella fase di migrazione in produzione.

Per quanto riguarda me, è tutto. Fate domande nei commenti e raccontate la vostra esperienza di migrazione.

Fonte: habr.com