Migrazione di IBM Cloud, VMware e VCF sui server virtuali VPC tramite RackWare RMM

Migrare le macchine virtuali IBM Cloud VMware VCF verso i server virtuali VPC utilizzando RackWare RMM, mantenendo gli indirizzi IP tramite Direct Sync e un server bridge.

La presente guida illustra come utilizzare il modulo di gestione di RackWare ( RMM ) per migrare le macchine virtuali automatizzate di IBM Cloud VCF verso istanze di server virtuali nel cloud privato virtuale (VPC) di IBM Cloud. È disponibile un'esercitazione associata che illustra il processo.

IBM Cloud VCF-Le licenze del sistema operativo delle macchine virtuali automatizzate sono a carico del cliente e non vengono fornite da. IBM Cloud Durante la creazione delle istanze del server virtuale di destinazione, prestare attenzione alle opzioni di provisioning relative all'opzione " Bring Your Own License ".

La maggior parte delle macchine virtuali ospitate su IBM Cloud VCF-Automated è collegata a segmenti overlay NSX che non dispongono di accesso nativo alle reti IBM Cloud Classic. Per garantire che le istanze dei server virtuali di destinazione abbiano gli stessi indirizzi IP delle macchine virtuali di origine, è necessario isolare il segmento overlay NSX e le sottoreti VPC delle istanze dei server virtuali di destinazione. È possibile ottenere questo risultato utilizzando le seguenti funzionalità di RMM:

  • Sincronizzazione diretta (Host Sync)- I dati vengono trasferiti direttamente dalla macchina virtuale di origine all'istanza del server virtuale di destinazione senza essere memorizzati sul server RMM. L' RMM e coordina l'operazione.
  • Passthrough - L'istanza del server virtuale di destinazione non può raggiungere direttamente la macchina virtuale di origine, pertanto RMM utilizza Secure Shell (SSH) per connettersi all'istanza del server virtuale di destinazione e, da lì, avviare un tunnel SSH inverso verso la macchina virtuale di origine. Flussi di dati: Origine → RMM → Destinazione, con l' RMM che funge da ripetitore/proxy di rete per il trasferimento dei dati.

Il sito RackWare RMM con un server bridge consente la migrazione tra reti isolate attraverso:

  1. Traduzione degli indirizzi di rete (NAT) del bridge: rende la sorgente accessibile all'indirizzo RMM tramite NAT
  2. Tunnel SSH inverso: consente all'istanza del server virtuale di destinazione di raggiungere la macchina virtuale di origine tramite il server RMM
  3. Autenticazione basata su chiave: l'istanza del server virtuale di destinazione utilizza la chiave SSH di RMM per autenticarsi sulla macchina virtuale di origine
  4. Sincronizzazione dei dati tramite tunnel: l'istanza del server virtuale di destinazione recupera i dati dalla macchina virtuale di origine attraverso il tunnel SSH protetto
  5. Installazione del bootloader: RMM rende il sistema di destinazione avviabile con una configurazione GRUB corretta

Il processo è elegante e consente una migrazione any-to-any mantenendo la sicurezza e l'isolamento della rete.

La presente guida non tratta un'alternativa alla sincronizzazione diretta, denominata sincronizzazione a stadi (fase 1 + fase 2):

  • Fase 1: Copiare i dati dall'origine al pool di archiviazione ZFS di RMM, memorizzandoli temporaneamente.
  • Fase 2: Copia dei dati dallo storage di RMM alla destinazione.

Si usa quando non si desidera la sincronizzazione diretta o quando si desidera disaccoppiare le operazioni di origine e destinazione.

Mantenere l'indirizzamento IP

La maggior parte delle migrazioni da macchine virtuali a server virtuali VPC richiede il mantenimento degli indirizzi IP nei carichi di lavoro migrati. Per la maggior parte delle macchine virtuali ciò è possibile; tuttavia, le sottoreti VPC dispongono di indirizzi IP riservati. Ad esempio, i seguenti elementi sono riservati su 192.168.10.0/24:

  • ibm-network-address: 192.168.10.0
  • ibm-default-gateway: 192.168.10.1
  • indirizzo ibm-dns: 192.168.10.2
  • ibm-reserved-address: 192.168.10.3
  • ibm-indirizzo-broadcast: 192.168.10.255

Pertanto, è possibile che sia necessario ri-IPare alcune macchine virtuali per ogni subnet.

Sistemi supportati

Rivedere la documentazione elencata nei riferimenti per gli ultimi sistemi operativi supportati, ma attualmente includono:

  • RHEL 5.2 fino a 5.11, 6.x, 7.x. 8.x, 9.x
  • Centos 5.2- 5.11, 6.x, 7.x, 8.x
  • Oracle Linux 5.6 attraverso 5.11, 6.x, 7.x, 8.x, 9.x
  • SLES 11 (compresa la versione a 32 bit)
  • SLES 12 (senza btrfs)
  • SLES 15 (senza btrfs)
  • Ubuntu 12 (compresa la versione a 32 bit), 14, 16, 18, 20, 22, 24
  • Debian 8, 9, 10, 11, 12
  • AlmaLinux 8, 9
  • Rocky Linux, 8, 9
  • Windows 2008 R2, 2012, 2016, 2019, 2022

Componenti dell'architettura

Questa guida:

  • Utilizza indirizzi IP di esempio per agevolare il trasferimento delle conoscenze; i vostri indirizzi IP saranno diversi.
  • Si concentra su una migrazione Linux ma Microsoft Windows è simile.
IBM Cloud VMware-Automated    Bridge Server              IBM Cloud VPC
┌──────────────┐             ┌───────────────┐          ┌───────────────┐
│              │             │ens192:        │          │               │
│  Source VM   │             │192.168.10.254 │          │  RMM Server   │
│ 192.168.10.11├────────────►│               │◄─────────┤  10.68.70.11  │
│              │             │   ens224:     │          │               │
└──────────────┘             │   10.134.54.62│          └───────────────┘
                             │               │                  │
                             └───────────────┘                  │
                                                                │
                                                        ┌───────▼───────┐
                                                        │  Target VSI   │
                                                        │ 192.168.10.11 │
                                                        └───────────────┘

Il diagramma qui sopra mostra una vista di collegamento logico dei componenti. Il nome bridge server è fuorviante, in quanto non utilizza il bridging di livello 2 ma il NAT di livello 3.

Fonte VM:

  • Posizione: IBM Cloud VCF Istanza automatizzata VMware
  • Esempio: VM in esecuzione Ubuntu 22.04
  • IP reale: 192.168.10.11 (segmento overlay NSX)
  • Accessibile tramite: VM ha accesso a Internet tramite SNAT e accesso nativo alla rete client ma non alla rete IBM Cloud

Server Bridge:

  • Scopo: fornisce connettività di rete di livello 3 tra reti isolate
  • Funzione: Utilizza SNAT per rendere accessibile alle reti IBM Cloud VPC il segmento di overlay NSX isolato
  • Interfacce:
    • ens192: 192.168.10.254- Rete interna ( 192.168.10.0/24 )
    • ens224: 10.134.54.62- Rete esterna ( 10.134.54.0/26 )

RMM Server:

  • Posizione: IBM Cloud VPC
  • Scopo: Orchestrare le operazioni di migrazione/sincronizzazione
  • IP: 10.68.70.11
  • Esegue: il software RackWare, ospita l'interfaccia utente, coordina il trasferimento dei dati, funge da proxy per le comunicazioni di rete in modalità passthrough

Obiettivo VSI

  • Posizione: IBM Cloud VPC
  • Esempio: Istanza server virtuale (VSI)
  • IP: 192.168.10.11
  • Scopo: Destinazione dei dati migrati

IBM Cloud Private Sottorete statica:

  • Posizione: IBM Cloud Classico
  • Esempio: Implementazione di una sottorete portatile /30 (4 IP)
  • IP: 10.194.177.82/30. IP utilizzabili: 10.194.177.82- 10.194.177.85
  • Scopo: Fornisce l'indirizzo IP per il NAT che la rete classica IBM Cloud instrada verso: 10.134.54.62 (IP del server bridge ens224 ). IBM l'infrastruttura di rete sa che il traffico destinato a 10.194.177.82/30 deve essere inviato a 10.134.54.62

Server ponte

Il server bridge utilizza iptables per fornire NAT:

  1. Quando RMM si collega a 10.194.177.82, il bridge traduce la destinazione in 192.168.10.11 (l'indirizzo IP reale della sorgente VM ).

  2. Quando l'origine VM risponde, sembra provenire dall'IP NAT 10.194.177.82

    Quando RMM cerca di raggiungere 10.194.177.82:

    1. RMM invia il pacchetto
      • SRC: 10.68.70.11
      • Ora legale: 10.194.177.82
    2. VPC Routes a Transit Gateway che instrada verso la rete Classic che sa che:
      • " 10.194.177.82 si trova nella sottorete 10.194.177.82/30 "
      • "Indirizza questa sottorete a 10.134.54.62 "
    3. Passo 3: Pacchetto consegnato al server bridge
      • Arriva su ens224 ( 10.134.54.62 )
      • DST: 10.194.177.82 (invariato)
    4. DNAT di iptables del ponte
      • iptables -t nat -A PREROUTING -i ens224 -d 10.194.177.82 -j DNAT --to-destination 192.168.10.11
    5. Pacchetto inoltrato alla sorgente VM
      • SRC: 10.68.70.11
      • DST: 192.168.10.11 (DNAT)

Requisiti della chiave SSH

Affinché il tunnel funzioni per il trasferimento dei dati, la destinazione deve autenticarsi all'origine. Il VSI di destinazione ha bisogno di una chiave privata SSH che corrisponda a una chiave pubblica presente nel file authorized_keys del sito VM di origine.

Luoghi chiave:

  • RMM: /root/.ssh/id_rsa Creati come parte del processo manuale successivo alla distribuzione di RMM
  • Target Linux VSI: /root/.ssh/id_rsa Deve essere la stessa chiave di RMM e trasferita tramite un processo RMM automatizzato
  • Fonte Linux VM: /home/rackware/.ssh/authorized_keys Creati nell'ambito del processo manuale di impostazione della fonte

Per i server Windows si utilizza l'utility RackWare SSHD. RackWare SSHD per Windows è un'implementazione leggera del server SSH confezionata come un programma di installazione MSI specifico per i sistemi Windows per consentire la connettività RackWare RMM. L'MSI, RWSSHDService_x64.msi, può essere scaricato direttamente dal server RMM all'indirizzo: https://<RMM_IP>/windows/RWSSHDService_x64.msi

Flusso di autenticazione

  1. RMM → Sorgente VM (via bridge server)
    • Utilizza: RMM 'chiave SSH
    • Autenticazione come: utente rackware
    • Scopo: Scoperta, montaggio del filesystem, pulizia
  2. RMM → Obiettivo VSI
    • Utilizza: RMM 'chiave SSH
    • Autenticazione come: utente root
    • Scopo: Creare tunnel, montare filesystem, trasferire dati
  3. VSI di destinazione → Sorgente VM (attraverso il tunnel)
    • Utilizza: Chiave SSH copiata (come quella di RMM )
    • Autenticazione come: utente rackware
    • Scopo: Trasferimento di dati

Core RackWare RMM Operazioni

Le operazioni principali di RackWare RMM per la migrazione sono le seguenti.

Scoprire/Esaminare

Scopo: raccogliere informazioni sulla fonte VM Processo:

  • L'utente fornisce l'indirizzo IP o il nome host DNS dell'origine VM. Nel nostro caso d'uso utilizziamo l'indirizzo IP NAT.
  • RMM si connette tramite SSH al server di origine VM
  • Esegue le query standard del sistema operativo per raccogliere i metadati:
    • Core della CPU, RAM, configurazione del disco
    • Partizioni e struttura dei volumi
    • Versione del sistema operativo e pacchetti installati
    • Configurazione della rete
    • Informazioni sull'applicazione
  • Metadati memorizzati nel CMDB (Configuration Management Database) di RMM
  • Utilizzato in seguito per i VSI di destinazione di AutoProvisioning, se necessario

Requisito della chiave: Le chiavi SSH devono essere configurate correttamente tra RMM e il server di origine

Cattura (approccio Store-and-Forward)

L'approccio Store-and-Forward non viene utilizzato in questo caso d'uso, poiché si utilizza l'approccio Direct Assign (Flex Sync/Host Sync).

Scopo: creare un'istantanea/clone dell'immagine di origine VM sul computer RMM Processo:

  • Prende l'istantanea LVM ( Linux ) o l'istantanea VSS (Windows) sull'origine VM
  • Il sistema operativo esegue il flush degli IO delle applicazioni su disco per garantire la coerenza
  • Il sistema operativo inserisce il segnalibro nel filesystem (non dannoso)
  • RMM copia i bit dell'immagine dall'istantanea statica all'archivio RMM
  • Vengono copiati solo i dati utilizzati (a livello di file, non di blocco)
  • Immagine memorizzata nella posizione di archiviazione del server RMM
  • Metadati aggiuntivi sull'immagine memorizzati nel CMDB

Funzioni chiave:

  • Non interrompe il server di origine (la produzione continua a funzionare)
  • Replica basata su file (non su settori/blocchi)
  • Supporta la compressione e la crittografia
  • Possibilità di specificare elenchi di inclusione/esclusione per dati selettivi

Assegna

Scopo: distribuire l'immagine catturata a un VSI di destinazione Processo:

  1. AutoProvision target VSI (o utilizzare un server pre-provisionato)
    • RMM utilizza i metadati di Discover per dimensionare il target in modo appropriato
    • Disposizioni VSI in VPC
  2. Connettersi al target utilizzando SSH
  3. Esaminare l'obiettivo
    • Verificare che il VSI di destinazione possa eseguire l'immagine VM di origine
    • Comprendere l'hardware sottostante
  4. Avvio in RackWare Microkernel
    • Distribuzione del microkernel al VSI di destinazione
    • Inserire nelle opzioni del bootloader
    • Avvio del target VSI dal microkernel
  5. Preparare il disco VSI di destinazione
    • Riformattare il disco
    • Ricreare la struttura del volume logico (corrispondenza esatta con l'origine)
    • Creare partizioni utilizzando l'algoritmo best-fit
  6. Immagine di trasferimento
    • Trasferire i bit dell'immagine dalla memoria RMM al VSI di destinazione
    • Iniettare i driver di dispositivo necessari per il nuovo hardware
    • Modificare facoltativamente la configurazione di rete per il VSI di destinazione
  7. Configurazione e riavvio
    • Configurare il bootloader per il sistema operativo attuale
    • Riavviare il sistema operativo replicato
  8. Verifica
    • Verificare che il VSI di destinazione si avvii correttamente
    • Verificare il corretto collegamento in rete
    • Verifica dei dati replicati correttamente
    • SSH nel server replicato usando le stesse credenziali dell'origine

Assegnazione diretta (chiamata anche Flex Sync o Host Sync)

Questo è l'approccio che utilizziamo in questo caso d'uso.

Scopo: Replicare direttamente dall'origine VM alla destinazione VSI senza archiviazione intermedia Processo:

  1. Combina la cattura e l'assegnazione in un'unica operazione
  2. Esegue tutte le funzioni di Discover
  3. Predispone il server di destinazione (o utilizza quello esistente)
  4. Prepara il server di destinazione
  5. Replica direttamente dal sito VM di origine al VSI di destinazione
  6. La connessione di rete può ancora passare attraverso il sito RMM (non è richiesta una connessione diretta da sorgente a destinazione)

Sincronizzazione (sincronizzazione delta)

Scopo: Aggiornare la destinazione con i soli dati modificati dell'origine VM Processo:

  1. Esegue l'istantanea su VM (LVM o VSS)
  2. Calcola il delta (solo i file modificati)
  3. Trasferisce a Target solo i dati modificati
  4. Aggiornamenti o:
    • Immagine catturata su RMM storage, OR
    • Esecuzione del server Target, OPPURE
    • Entrambi (immagine + server di destinazione)

Opzioni di sincronizzazione

  • Sincronizzazione fase I
    • Origine → RMM Memorizzazione (immagine catturata)
    • Aggiorna solo l'immagine memorizzata
  • Sincronizzazione fase II
    • RMM Memorizzazione → Server di destinazione
    • Aggiorna il target in esecuzione dall'immagine memorizzata
  • RMM Passaggio di testimone
    • Origine → RMM → Obiettivo
    • I dati passano attraverso RMM ma non persistono
    • Non è necessaria la memorizzazione su RMM
  • Sincronizzazione diretta
    • Origine → Destinazione (connessione diretta)
  • Sincronizzazione selettiva*
    • Sincronizzare solo file/directory specifici
    • Utilizza gli elenchi include/esclude
  • Mappatura di unità/directory
    • Mappare percorsi di origine specifici a percorsi di destinazione diversi

Motori sincronizzati:

  • RWSync (predefinito):
    • Agentless
    • Tolleranza alle interruzioni di rete
    • Gestisce aggiornamenti massicci e simultanei
    • Include il checksum finale
    • Più lento di TNG
  • TNG (avanzato):
    • Richiede l'installazione del tracker di file delta
    • Molto più veloce ed efficiente
    • Per server di grandi dimensioni, tassi di aggiornamento elevati, RPO aggressivo
    • Deve essere inserito nella whitelist dell'antivirus
    • Più sensibile alle interruzioni di rete
    • Non supporta i montaggi remoti di NFS /CIFS

Il processo di avvio del microkernel RackWare

Durante l'operazione di assegnazione, RMM avvia il VSI di destinazione in un microkernel RackWare e il disco di avvio viene riformattato, assicurandosi che i filesystem, i loro tipi e le loro dimensioni corrispondano a quelli dell'origine VM. RMM fa un tentativo di adattamento ottimale in base al layout del disco di destinazione e alle partizioni da inserire in base alla sorgente.

Distribuzione del microkernel

Quando RackWare prepara un VSI di destinazione per ricevere l'immagine replicata:

  • RMM distribuisce un microkernel RackWare sul VSI di destinazione
  • Questo microkernel "si inserisce nelle opzioni del Bootloader" del sistema operativo della piattaforma
  • Il microkernel si avvia dal bootloader (GRUB su Linux )

Il microkernel può essere considerato come un LiveCD, ed è un ambiente minimo avviabile:

  • Ospita i driver necessari per l'hardware di destinazione
  • Consente a RMM di comunicare con il server di destinazione
  • Consente la riformattazione del disco e la creazione di partizioni
  • Facilita l'effettivo trasferimento dei dati dall'origine alla destinazione
  • Configura il sistema per il nuovo ambiente hardware

Durante la fase di assegnazione, RackWare:

  1. Esegue l'avvio del VSI di destinazione nel microkernel (tramite la voce di GRUB)
  2. Riformatta il disco mentre si trova nel microkernel
  3. Ricrea la struttura della partizione corrispondente all'origine VM
  4. Crea i volumi logici per creare la struttura LVM
  5. Trasferisce i dati dell'origine VM al VSI di destinazione
  6. Inietta i driver necessari per l'hardware di destinazione
  7. Configura GRUB per avviare il sistema operativo attuale
  8. Riavvio nel sistema operativo replicato

RackWare modifica la configurazione di GRUB:

  • Aggiungere una voce di avvio temporanea del microkernel durante il processo di Assegnazione
  • Configurazione dei parametri di avvio corretti per il sistema operativo replicato
  • Impostare l'opzione di avvio predefinita per il sistema operativo replicato al termine del trasferimento
  • Gestione dei parametri del kernel necessari per il nuovo hardware

Per sistemi Windows:

  • Windows Boot Manager viene utilizzato al posto di GRUB
  • Si applica lo stesso concetto di microkernel
  • Il microkernel si inserisce nella configurazione di avvio di Windows
  • Dopo la replica, la configurazione di avvio punta al sistema operativo Windows replicato

L'ambiente microkernel consente a RackWare di:

  • Iniettare i driver di archiviazione appropriati
  • Iniettare i driver di rete
  • Configurare i driver di dispositivo per il nuovo hardware
  • Assicuratevi che il sistema operativo replicato possa avviarsi su hardware diverso

Il processo di replica per le sincronizzazioni delta, ovvero le sincronizzazioni successive, funziona allo stesso modo della sincronizzazione iniziale. La sincronizzazione delta viene eseguita dopo il riavvio del server di destinazione nel microkernel RackWare. Una volta completata la sincronizzazione delta, il VSI di destinazione verrà riavviato nel sistema operativo host,

Questo approccio al microkernel è un elemento di differenziazione fondamentale per RackWare, in quanto consente di gestire la complessità delle migrazioni multipiattaforma, multihypervisor e da fisico a virtuale avendo il controllo completo dell'ambiente di destinazione durante la fase critica di trasferimento e configurazione.

RackWare Passaggio con il processo di sincronizzazione diretta

Il processo avviene nel modo seguente:

  1. RMM Scopre la fonte VM
RMM → Bridge (10.194.177.82) → Source VM (192.168.10.11)
  • RMM si connette via SSH a 10.194.177.82 (IP NAT)
  • Il ponte si traduce in 192.168.10.11
  • RMM raccoglie i metadati: OS, filesystem, layout del disco, ecc.
  1. RMM Scopre il VSI di destinazione
RMM → Target VSI (192.168.10.11)
  • RMM si connette via SSH a 192.168.10.11
  • Esamina l'hardware e le capacità del target
  1. RMM Crea un tunnel SSH inverso verso il VSI di destinazione

L'automazione RMM crea un tunnel SSH inverso tra il VSI di destinazione e l'origine VM tramite il server RMM:

Target VSI (192.168.10.11)
  │
  └─ localhost:23 ──[SSH Tunnel]──► RMM ──► Bridge ──► Source VM:22

  1. RMM avvia la connessione SSH al VSI di destinazione

  2. Crea una porta di ascolto (23) sulla destinazione

  3. Qualsiasi connessione a localhost:23 sulla destinazione viene inoltrata:

    • Attraverso il tunnel SSH si torna a RMM
    • RMM inoltra a 10.194.177.82:22 (sorgente tramite bridge)
    • Bridge DNAT verso la sorgente effettiva

    Flusso visivo:

    Target:       [App tries localhost:23]
                       ↓
               [SSH tunnel to RMM]
                       ↓
RMM: [Receives and forwards to 10.194.177.82:22]
                       ↓
 Bridge: [DNAT: 10.194.177.82 → 192.168.10.11]
                       ↓
Source:   [Receives connection on port 22]

  4. Montare i file system

RMM monta i filesystem sia sull'origine che sulla destinazione usando comandi simili agli esempi seguenti:

Su Source VM (via bridge):

# RMM executes on source
mount --bind / /mnt/rackware/tmp.xxxxx

VSI su obiettivo (diretto):

# RMM executes on target
mount /dev/vda2 /mnt/rackware/tmp.yyyyy
  1. Trasferimento dati

RMM esegue il trasferimento dei dati sul VSI di destinazione per prelevare i dati dall'origine VM:

  1. Installazione di GRUB

RMM installa e configura GRUB sul target per l'avvio UEFI:

  • Copia i file del bootloader di GRUB
  • Genera grub.cfg con i parametri del kernel corretti
  • Crea voci di avvio UEFI
  • Configura i nuovi driver hardware
  1. Smontare i file system
# On both source and target
umount /mnt/rackware/tmp.xxxxx

  1. Chiudere il tunnel

  2. RMM chiude il tunnel SSH verso la destinazione

  3. La porta 23 smette di essere in ascolto sulla destinazione

  4. Rimuovere le utilità

# RMM removes temporary files from source and target
rm -rf /var/tmp/rackware/

Riferimenti