IBM Cloud VPC: Migrazione delle macchine virtuali d VMware e tramite trasferimento di rete in tempo reale
Eseguire la migrazione delle macchine virtuali di “ VMware ” ai server virtuali VPC di “ IBM Cloud ” tramite lo streaming dei dati del disco su una connessione “ Transit Gateway ”, utilizzando “ virt-v2v ”, riducendo al minimo i tempi di inattività e il trasferimento dei dati.
Componenti dell'architettura
I componenti dell'architettura di una migrazione di trasferimento di rete in tempo reale sono:
| Componenti dell'architettura | Descrizione |
|---|---|
| Transit Gateway | Collega l'ambiente VMware (Classic, NSX o VCFaaS ) al VPC. Questo fornisce il routing Layer 3 necessario alla macchina virtuale di origine (in VMware ) per comunicare con l'istanza del server virtuale di lavoro (in VPC). |
| Istanza del server virtuale del lavoratore | Simile al metodo 2, ma in questo caso si tratta di un puro ricevitore, che ascolta su una porta di rete i dati del disco in arrivo. |
| ISO dal vivo |
Una ISO avviabile che fornisce:
|
| Opzioni della sorgente di avvio |
|
Panoramica del processo di migrazione del trasferimento di rete in tempo reale
Il trasferimento in rete in tempo reale stabilisce un flusso di rete diretto TCP attraverso IBM Cloud Transit Gateway per copiare i blocchi del disco di origine VM nelle destinazioni di archiviazione a blocchi della VPC.
Prima di iniziare, assicurati di aver impostato il routing su IBM Cloud Transit Gateway, di aver configurato un'immagine ISO " Linux " attiva su VMware e di aver creato i volumi di archiviazione di destinazione VPC.
-
Provvedimento Transit Gateway
- Crea un file “ Transit Gateway ” in IBM Cloud
- Collegatelo all'ambiente VMware:
- Classic: Connessione diretta all'account Classic
- NSX: tunnel GRE verso i bordi NSX
- VCFaaS: Tunnel GRE verso i bordi di VCFaaS
- Configurazione del routing tra le reti VMware e le sottoreti VPC
- Testate a fondo la connettività prima della prima migrazione
-
Provisionare l'istanza del server virtuale Worker nella VPC
- Ubuntu o RHEL con risorse adeguate
- Creare volumi di destinazione utilizzando la tecnica dell'istanza di server virtuale effimera (Metodo 2, passaggi 2-4)
- Collegare i volumi di destinazione al worker
- Installare netcat:
apt-get install netcatoyum install nc
-
Preparare la fonte VM per il trasferimento
- Collegare la ISO live alla macchina virtuale in vCenter/VCFaaS
- Configurare l'ordine di avvio della macchina virtuale in modo che si avvii prima da CD/ISO
- Annotare la configurazione IP corrente per l'impostazione della rete nell'ambiente reale
-
Avvio della macchina virtuale sorgente da ISO
- Riavviare la macchina virtuale, che si avvia nell'ambiente live
- I dischi della macchina virtuale sono accessibili ma il sistema operativo non è in esecuzione (equivalente a un arresto pulito)
-
Configurazione della rete in ambiente live
- Individuare il nome dell'interfaccia di rete (può variare: eth0, ens192 e così via)
- Configurare IP e routing:
ip addr add 10.50.200.3/26 dev ens192 ip route add 0.0.0.0/0 via 10.50.200.1 ping 192.168.100.5 # Test connectivity to worker virtual server instance -
Avviare il trasferimento
- Sull'istanza del server virtuale Worker (avviare prima l'ascoltatore):
# Listen for incoming data, decompress, write to volume nc -l 192.168.100.5 8080 | gunzip | dd of=/dev/vdb bs=16M status=progress- Sulla macchina virtuale sorgente (in ISO live):
# Read disk, compress, send to worker dd if=/dev/sda bs=16M | gzip | nc -N -v 192.168.100.5 8080- Monitorare i progressi di entrambe le parti
- Il tempo di trasferimento dipende dalle dimensioni del disco e dalla larghezza di banda della rete
- La compressione offre in genere un miglioramento di 2-4x per i dischi del sistema operativo
-
Ripetere l'operazione per altri dischi
-
Per le macchine virtuali a più dischi, ripetere l'operazione per ogni disco:
# Worker (disk 2) nc -l 192.168.100.5 8080 | gunzip | dd of=/dev/vdc bs=16M status=progress # Source (disk 2) dd if=/dev/sdb bs=16M | gzip | nc -N -v 192.168.100.5 8080
-
-
Elaborazione post-trasferimento
- Verifica trasferimenti:
fdisk -l /dev/vdbsul lavoratore - Utilizzare facoltativamente virt-v2v per le trasformazioni:
virt-v2v-in-place -i disk /dev/vdb - Risciacquare i buffer:
blockdev --flushbufs /dev/vdb
- Verifica trasferimenti:
-
Creare un'istanza di server virtuale dai volumi
- Staccare i volumi dal lavoratore
- Creare l'istanza finale del server virtuale utilizzando il volume di avvio esistente (come nel Metodo 2, passo 8)
-
Arresto della macchina virtuale sorgente
- Dopo aver verificato che l'istanza del server virtuale si avvia correttamente, spegnere la macchina virtuale di origine
- Creare facoltativamente un'istantanea in VMware come punto di rollback
Vantaggi progettuali
La tabella seguente descrive i vantaggi progettuali della migrazione del trasferimento di rete in tempo reale.
| Vantaggio del design | Descrizione |
|---|---|
| Nessun costo aggiuntivo per l'esportazione | Elimina l'intera fase di esportazione: nessun tempo speso per esportare i VMDK, nessuno storage di esportazione necessario, nessun trasferimento delle esportazioni al VPC. |
| Utilizzo efficiente della rete | Lo streaming diretto con compressione utilizza in modo ottimale la larghezza di banda disponibile. |
| Capacità di migrazione parallela | Provisionate più istanze di server virtuali worker e migrate più macchine virtuali contemporaneamente, limitate solo dalla larghezza di banda della rete e dalle risorse dei worker. |
| Massima flessibilità | Facile da integrare con le trasformazioni di virt-v2v, supporta sia VCFaaS che vCenter, e funziona con qualsiasi macchina virtuale indipendentemente dal numero di dischi. |
| Stato del disco pulito | L'avvio da ISO garantisce che il sistema operativo di origine non sia in esecuzione, fornendo uno stato del disco pulito e coerente (simile a un'istantanea a freddo). |
Vincoli e limitazioni di progettazione
La tabella seguente descrive i vincoli e le limitazioni di una migrazione di trasferimento di rete in tempo reale.
| Limitazione o vincolo | Descrizione |
|---|---|
| Transit Gateway requisito | Richiede un investimento iniziale per impostare e testare la connettività di Transit Gateway. |
| Preparazione dell'ISO in tempo reale |
|
| Dipendenza dalla larghezza di banda della rete | La velocità di trasferimento è limitata dalla larghezza di banda della rete tra gli ambienti. Monitorare e pianificare di conseguenza. |
| Configurazione manuale della rete | Per ogni macchina virtuale di origine, è necessario configurare la rete nell'ambiente ISO live (può essere eseguita tramite script). |
| Non adatto alla migrazione a caldo | Si tratta di un approccio di migrazione a freddo: la macchina virtuale sorgente è offline durante il trasferimento. |
virt-p2v Integrazione
Red Hat virt-p2v è un ambiente specializzato per la conversione in tempo reale che si coordina con un server di conversione di destinazione per automatizzare lo streaming su disco e l'iniezione dei driver. virt-v2v
Prima di eseguire una migrazione con il comando virt-p2v , assicurati che sull'istanza worker della tua VPC sia in esecuzione virt-v2v in modalità di ascolto e che l'istanza di origine VM abbia montato l'ISO virt-p2v .
Red Hat virt-p2v ISO è stato creato appositamente per questo caso d'uso. Questa soluzione offre:
- Interfaccia grafica per la selezione dei dischi da trasferire
- Connettività di rete integrata a un ricevitore
virt-v2v - Iniezione automatica del driver e preparazione del sistema operativo
virt-p2v Processo di integrazione
- Avviare la macchina virtuale di origine da virt-p2v ISO
- Configurare la rete e connettersi all'istanza del server virtuale worker che esegue virt-v2v in modalità server
- virt-p2v trasferisce i dischi e virt-v2v li trasforma automaticamente
- I volumi risultanti sono pronti per essere collegati all'istanza del server virtuale
La migrazione con trasferimento di rete live è ideale per migrazioni su larga scala (oltre 10 macchine virtuali), per scenari in cui l'overhead dell'esportazione è proibitivo e quando si dispone dell'esperienza necessaria per configurare Transit Gateway e ambienti ISO live. Il costo di configurazione iniziale è più elevato, ma l'efficienza della migrazione per macchina virtuale è superiore.