Migrazioni VMware Hybrid Cloud

Concetti e prassi ottimali per vMotion

HCX è essenzialmente un proxy bidirezionale di vMotion. Ogni istanza di HCX emula un singolo host VMware ESXi™ all'interno del data center vSphere, al di fuori di qualsiasi cluster. L'istanza HCX è un "fronte" per il componente cloud gateway fleet (CGW). È presente un host proxy per ogni sito HCX collegato al sito attualmente visualizzato. Quando viene avviato un vMotion verso un host remoto, l'host ESXi locale esegue la migrazione della macchina virtuale sull'host ESXi proxy locale.

Viene avviata una migrazione vMotion dall'host proxy ESXi remoto all'host ESXi fisico vSphere di destinazione mentre riceve dati dal CGW di origine attraverso il tunnel. Quando si utilizza vMotion, a differenza dell'opzione di migrazione in blocco, viene eseguita solo una singola operazione di migrazione di VM per volta. Di conseguenza, per molte macchine virtuali da migrare, si consiglia di utilizzare vMotion solo quando il tempo di inattività non è un'opzione o se esiste il rischio di riavviare la macchina virtuale. Tuttavia, come per vMotion standard, la VM può essere attiva durante il processo.

Un singolo vMotion raggiunge il suo limite massimo a circa 1.7 Gbps sulla LAN e 300 - 400 Mbps sulla WAN attraverso il WAN Optimizer. Questo non significa che 1,7 Gbps sulla LAN equivalgono a 400 Mbps sulla WAN tramite l'ottimizzatore WAN ma, piuttosto, che questi massimi sono stati osservati su specifici ambienti. Un ambiente di questo tipo consisteva in una rete vMotion LAN di 10 GB e di un uplink internet di 1 GB, in condivisione con il traffico web di produzione.

Utilizzare vMotion nei seguenti casi:

• Se la macchina virtuale è difficile da spegnere e avviare, o se il tempo di attività è lungo e può introdurre rischi spegnendo la macchina virtuale.
• Per qualsiasi applicazione di tipo cluster che richiede gli UUID del disco, come ad esempio i cluster RAC di Oracle. vMotion non modifica gli UUID del disco sulla destinazione.
• Se si desidera spostare una singola macchina virtuale il più rapidamente possibile.
• Se la migrazione programmata non è necessaria.

Concetti e prassi ottimali per la migrazione in blocco

La funzionalità di migrazione in blocco di HCX utilizza la replica vSphere per migrare i dati del disco durante la ricreazione della VM sull'istanza HCX vSphere di destinazione. Una migrazione di una VM comporta il seguente flusso di lavoro:

• Creazione di una nuova VM sul lato di destinazione e sui relativi dischi virtuali corrispondenti.
• Replica dei dati VM sulla nuova VM. La replica viene avviata non appena viene completata la procedura guidata, indipendentemente dalla pianificazione dello switch-over.
• Spegnimento della VM originale.
• Durante il periodo di spegnimento, si verifica la replica finale di qualsiasi modifica di dati.
• Accensione della nuova VM sul lato di destinazione.
• Ridenominazione e spostamento della VM originale nella cartella cloud in cui era stata spostata.

Sono di seguito indicati i vantaggi offerti dalla migrazione in blocco su vMotion:

• Migrazione di più VM simultaneamente.
• L'uso della larghezza di banda è più costante. vMotion può generare fluttuazioni nell'uso della larghezza di banda che sarebbero visibili come picchi e valli negli strumenti di monitoraggio della rete o nell'interfaccia utente di WAN Opt.
• Utilizzare la migrazione in blocco per ottenere un utilizzo complessivo della larghezza di banda di rete superiore a quello di un singolo vMotion.
• Pianifica la migrazione in blocco per passare alle VM appena migrate durante una finestra di interruzione pianificata.
• Consentire la migrazione di macchine virtuali che attualmente utilizzano funzioni della CPU virtuale diverse da quelle del cloud. La migrazione di vMotion potrebbe fallire in questi casi.

Sono di seguito indicati gli svantaggi comportati dalla migrazione in blocco su vMotion:

• La migrazione delle singole VM è molto più lenta che con vMotion.
• La VM è soggetta a un tempo di inattività per un breve lasso di tempo mentre la nuova VM clone viene attivata sul lato di destinazione.
• Le VM che dipendono dall'ordinamento dei dischi e dagli UUID disco (Oracle RAC) possono avere dei problemi e avere dei dischi che vengono visualizzati differentemente quando gli UID vengono modificati, cosa che potrebbe modificare i percorsi del sistema operativi ai dispositivi di disco virtuale.

Cluster di dischi condivisi

I cluster Oracle RAC, MS Exchange e MS-SQL sono esempi di applicazioni in cui due o più VM partecipano a un cluster che richiede un disco condiviso tra tutte le VM o tutti i nodi cluster. Il flag VMware® multi-writer deve essere abilitato su tutti i nodi VM per i dischi che fanno parte del cluster di applicazioni (dischi virtuali non-OS). Le macchine virtuali con il flag multiwriter abilitato per qualsiasi disco virtuale non sono supportate.

Esaminate le seguenti informazioni sulla migrazione di un cluster abilitato per i dischi virtuali multi-writer:

• vMotion viene utilizzato, in quanto vengono mantenute le mappature del disco e dell'UUID della macchina virtuale originale.
• Il cluster rimane attivo in uno stato degradato (nodo singolo) durante la migrazione.
• Il cluster subisce un tempo di inattività prima dell'avvio della migrazione e dopo il completamento della migrazione per riassemblare la configurazione multiwriter nelle VM del cluster.

Per migrare un cluster abilitato ai dischi multi-writer, completare i seguenti passaggi:

1. Spegni il cluster e tutti i nodi in base alla prassi ottimale per l'applicazione.
2. Annota l'ordine dei dischi, se l'applicazione lo richiede, in ogni VM del nodo per i dischi virtuali configurati multiwriter.
3. Per Oracle e qualsiasi altra applicazione che utilizza la funzione UUID del disco virtuale, accedere a un host ESXi ed eseguire il comando vmkfstools -J getuuid /vmfs/volumes/datastore/VM/vm.vmdk. Questo comando ottiene l'UUID di ogni file di disco virtuale che richiede il flag multi-writer impostato per il cluster. Questo passaggio è necessario se le migliori pratiche allineano gli ordini dei dischi con il modo in cui il percorso viene visualizzato nel sistema operativo. vMotion può riordinare i dischi (disk1, disk2, disk3) ma gli UUID rimangono gli stessi. Al termine della migrazione, utilizzare l'UUID annotato per mappare le informazioni del disco e ricreare l'ordine di denominazione del disco e l'ID SCSI, se necessario. Queste informazioni possono essere utili per la risoluzione dei problemi quando un'istanza Oracle ha molti dischi virtuali mappati.
4. Rimuovi i dischi virtuali da tutte le VM del cluster, fatta eccezione per quello ritenuto primario.
5. Rimuovere il flag multiwriter dalla macchina virtuale primaria del cluster (l'unica che possiede i dischi del cluster).
6. Accendi il cluster primario, se necessario, per un tempo di inattività minimo.
7. Migra tutti i nodi cluster con vMotion. Migra prima il cluster primario. Migra tutti gli altri nodi dopo che sono stati spenti.
8. Quando il disco primario proprietario del nodo completa la migrazione, spegnilo.
9. Se necessario, riassocia l'ordine dei dischi con i corretti UUID disco e ID SCSI. La riassociazione non è necessaria perché l'applicazione funzioni.
10. Riabilita l'indicatore multiwriter sul nodo primario.
11. Avviare il nodo primario e verificare il funzionamento.
12. Mappare il disco o abilitare il flag multi-writer su tutte le altre macchine virtuali del cluster e accenderle.
13. Verifica il restante funzionamento del cluster.

VM generali

Una volta creata la fiducia nel funzionamento di HCX, è necessario utilizzare la migrazione in blocco. La migrazione in blocco è necessaria per le applicazioni ridondanti. Ad esempio, i server web e laddove devono essere migrate molte centinaia o migliaia di VM.

VM che utilizzano NAS collegato direttamente

NFS è tipicamente utilizzato per condividere i dati tra molti server, ad esempio i contenuti dei server web. iSCSI può essere utilizzato tra i nodi delle macchine virtuali che consistono in un cluster di applicazioni come la posta elettronica o RDBMS ed è tipicamente più sensibile alla latenza rispetto a NFS.

In entrambi i casi, se la latenza può essere mantenuta bassa verso il centro dati IBM Cloud (< ~7 ms per iSCSI e qualsiasi cosa l'applicazione tolleri per NFS ) e consentendo che l'applicazione possa operare con una larghezza di banda di ~1 Gbps o meno, allora la rete NAS può essere estesa con HCX in una sede IBM Cloud. Successivamente, le macchine virtuali possono essere migrate o vMotioned con HCX.

Dopo la migrazione, è possibile eseguire il mirroring del volumi iSCSI con il sistema operativo a un'altra soluzione di archiviazione cloud locale e i dati NFS possono essere replicati a qualsiasi soluzione cloud. Esaminare le seguenti considerazioni:

• Latenza (iSCSI o tolleranza dell'applicazione per NFS)
• Larghezza di banda (~1 Gbps per ogni rete estesa)
• Larghezza di banda di collegamento sottostante

Dopo il ciclo di vita della migrazione, testare le applicazioni di sviluppo o di staging prima di tentare la migrazione in produzione. QoS può essere adottato per il traffico tunnel sottostante (UDP 500/4500) tra i dispositivi HCX L2C che supportano reti L2 estese sensibili alla latenza.