Introduzione
Nell’era digitale odierna, la migrazione di dati e asset è diventata un passaggio cruciale nello sviluppo continuo delle imprese. La migrazione delle macchine virtuali VMware non è soltanto un’attività tecnica, ma un vero e proprio progetto che coinvolge molteplici aspetti. Richiede di analizzare in modo approfondito le informazioni sugli asset esistenti, pianificare con attenzione il percorso della migrazione dei dati, eseguire specifiche operazioni e garantire una transizione senza interruzioni delle attività aziendali durante il processo. Il successo di questa operazione dipende non solo dal supporto di tecnologie all’avanguardia e da una pianificazione meticolosa, ma anche da una profonda comprensione e visione dei processi aziendali e dell’architettura dei dati.
Questo articolo approfondirà strategie, strumenti, processi e best practice per la migrazione dei dati delle VM, con l’obiettivo di fornire ai lettori una guida completa che aiuti le imprese a portare a termine con successo questo compito fondamentale. Vedremo come costruire basi solide per lo sviluppo futuro delle aziende attraverso una migrazione attentamente pianificata.
Sangfor mette a disposizione quattro metodi di migrazione per gli utenti VMware, in grado di soddisfare le esigenze di vari scenari:
- Migrazione gestita da VMware: utilizza la piattaforma cloud/virtualization di Sangfor per gestire il vCenter ai fini della migrazione dei dati.
- Migrazione point-to-point agentless: utilizza gli strumenti di migrazione Sangfor per connettersi a vCenter ed eseguire la migrazione dei dati.
- Migrazione point-to-point con agent: utilizza strumenti di migrazione che si connettono agli agent plugin per effettuare la migrazione dei dati basata su replica dei dati.
- Migrazione con agent e hot backup: utilizza strumenti di migrazione che si connettono agli agent plugin per una migrazione basata su tecnologia CDP.
Raccolta e valutazione delle informazioni chiave prima della migrazione
Prima di eseguire la migrazione delle macchine virtuali VMware, è necessario effettuare una raccolta dettagliata delle informazioni per definire il piano di migrazione, che include:
- Modelli di server fisici, storage esterno, apparati di rete, ecc.: valutare il supporto per l’infrastruttura di storage e di rete esistente. Se le apparecchiature in uso hanno raggiunto la fine del ciclo di vita o risultano incompatibili con la nuova piattaforma, è opportuno considerare l’adozione di un nuovo resource pool.
Per l’elenco di compatibilità hardware e software della piattaforma cloud/virtualization di Sangfor, fare riferimento qui.
- Versione di vCenter/ESXi: valutare se supporta la connessione a VDDK utilizzando la modalità di migrazione senza agent. In caso contrario, adottare un approccio basato su agent. La tabella seguente mostra le versioni supportate da Sangfor per la migrazione agentless.
Elenco di compatibilità della piattaforma VMware (metodo agentless): VMware ESXi 5.5 / 6.0 / 6.5 / 6.7 / 7.0 / 7.0.2; vSphere 5.5 / 6.0 / 6.5 / 6.7 / 7.0 / 7.0.2
- Tipologia di applicazioni aziendali, carico, finestra di downtime: valutare il downtime accettabile per le applicazioni aziendali e determinare il metodo di migrazione più adatto per ciascuna macchina virtuale applicativa. L’ambiente reale può variare a causa delle differenze di prestazioni di rete e storage. La tabella seguente fornisce dati di test di laboratorio a scopo di riferimento.
| Sistema operativo | Metodo di migrazione | Tempo di switch |
|---|---|---|
| Windows Server | Migrazione gestita | 7 minuti 8 secondi |
| Migrazione point-to-point (senza agent) | 5 minuti 7 secondi | |
| Migrazione point-to-point (con agent) | 3 minuti 27 secondi | |
| Migrazione hot backup SCMT | 1 minuto 22 secondi | |
| Linux | Migrazione gestita | 8 minuti 22 secondi |
| Migrazione point-to-point (senza agent) | 2 minuti 51 secondi | |
| Migrazione point-to-point (con agent) | 4 minuti 6 secondi | |
| Migrazione hot backup SCMT | 1 minuto 13 secondi |
- Versione del sistema operativo: evitare l’uso di versioni obsolete non più supportate. In tal caso, considerare un percorso di migrazione che preveda la sostituzione del sistema operativo. La tabella seguente mostra la compatibilità di alcuni sistemi operativi.
| Metodo di migrazione | IP sorgente | IP destinazione | Porta destinazione | Protocollo | Descrizione del servizio porta |
|---|---|---|---|---|---|
| Windows | Windows XP SP2 | 32/64 | BIOS | ✓ | ✓ |
| Windows 7 | 32/64 | BIOS | ✓ | ✓ | |
| Windows 8 | 32/64 | BIOS | ✓ | ✓ | |
| Windows 10 | 32 | BIOS | ✓ | ✓ | |
| Windows 10 | 64 | BIOS/UEFI | ✓ | ✓ | |
| Windows 11 | 64 | BIOS/UEFI | ✓ | ✓ | |
| Windows Server 2003 SP1 | 32/64 | BIOS | ✓ | ✓ | |
| Windows Server 2003 R2 | 32/64 | BIOS | ✓ | ✓ | |
| Windows Server 2008 | 32/64 | BIOS | ✓ | ✓ | |
| Windows Server 2008 R2 | 64 | BIOS | ✓ | ✓ | |
| Windows Server 2012 | 64 | BIOS/UEFI | ✓ | ✓ | |
| Windows Server 2012 R2 | 64 | BIOS/UEFI | ✓ | ✓ | |
| Windows Server 2016 | 64 | BIOS/UEFI | ✓ | ✓ | |
| Windows Server 2019 | 64 | BIOS/UEFI | ✓ | ✓ | |
| Windows Server 2022 | 64 | BIOS/UEFI | ✓ | ✓ | |
| SUSE | SUSE Linux Enterprise 11 SP3 | 32 | BIOS | ✓ | ✓ |
| SUSE Linux Enterprise 11 SP3 | 64 | BIOS/UEFI | ✓ | ✓ | |
| SUSE Linux Enterprise 11 SP4 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat | Red Hat Enterprise Linux 5.6 | 32/64 | BIOS | ✓ | ✓ |
| Red Hat Enterprise Linux 5.7 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 5.8 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 5.9 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 5.10 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 5.11 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 6.0 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 6.1 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 6.2 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 6.3 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 6.4 | 32/64 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 6.5 | 32 | BIOS | ✓ | ✓ | |
| Red Hat Enterprise Linux 6.5 | 64 | BIOS/UEFI | ✓ | ✓ | |
| Red Hat Enterprise Linux 6.6 | 32 | BIOS | ✓ | ✓ |
- Formato dei dispositivi virtuali e tipo di file system: valutare il supporto alla migrazione dei dati. I file system generali sono sostanzialmente supportati, e i supporti disco grezzi non necessitano di essere migrati ma possono essere rimappati per l’uso. La tabella seguente mostra l’elenco di supporto per dischi e file dallo strumento di migrazione Sangfor.
| Lista dei dischi e file system supportati | |
|---|---|
| File | ext2, ext3, ext4, xfs, FAT, FAT32, NTFS, ReFS |
| Formato del dispositivo | LVM, GPT, MBR, Dynamic volume, Spanned volume, Striped volume |
- Policy delle porte di rete: verificare la policy delle porte di rete e aprire, se necessario, le porte di gestione e di trasferimento dati tra sorgente e destinazione della migrazione per prevenire eventuali fallimenti. La tabella seguente mostra, a titolo di esempio, le condizioni di comunicazione delle porte per ciascun metodo di migrazione.
| Metodo di Migrazione | IP Sorgente | IP Destinazione | Porta Destinazione | Protocollo | Descrizione Service Port |
|---|---|---|---|---|---|
| Migrazione Gestita VMware | Piattaforma Sangfor | vCenter | 443 | TCP | Emettere comandi alla Management Platform |
| Piattaforma Sangfor | ESXi | 902 | TCP | Eseguire il trasferimento dei dati della VM | |
| Gestione Task Migrazione SCMT | PC di Gestione | Server | 22 | TCP | Accesso al Backend del Server di Migrazione |
| PC di Gestione | Server | 80,443 | TCP | Accesso al Servizi Web del Server | |
| Migrazione Point-to-Point SCMT (senza agent) | Server SCMT | vCenter | 443 | TCP | Emettere comandi alla Management Platform |
| Server SCMT | ESXi | 902 | TCP | Eseguire il trasferimento dei dati della VM | |
| Migrazione Point-to-Point SCMT (con agent) | Sorgente/Destinazione | Server SCMT | 80 | TCP | Scaricare il plugin agent (possibile importazione manuale) |
| Sorgente/Destinazione | Server SCMT | 20000~20047 | TCP | Connessione agent al server | |
| Sorgente | Destinazione | 20000~20047 (qualsiasi) | TCP | Sincronizzare la porta di trasferimento dati | |
| Server SCMT | Destinazione | 26000~26600 | TCP | Trasferire informazioni di controllo durante lo switch point-to-point | |
| Migrazione SCMT Live Backup (con agent) | Sorgente/Destinazione | Server SCMT | 80 | TCP | Scaricare il plugin agent (possibile importazione manuale) |
| Sorgente/Destinazione | Server SCMT | 20000~20003 | TCP | Connessione agent al server | |
| Destinazione | Server SCMT | 20000~20003 | TCP |
|
- Informazioni sulla rete di migrazione: valutare l’impatto sulla rete aziendale in base alla larghezza di banda durante il trasferimento della migrazione, e calcolare e pianificare il tempo complessivo di lavoro della migrazione. La tabella seguente fornisce esempi per alcune migrazioni di sistema.
- Configurazione delle risorse di sistema e tasso di utilizzo: valutare se il sistema operativo necessita di aggiustamenti delle risorse e della configurazione dopo la migrazione. Considerando l’impatto del binding delle applicazioni, il principio è solo espandere e non ridurre.
Migrazione gestita VMware basata su tecnologia agentless
La piattaforma cloud/virtualization di Sangfor possiede funzionalità integrate per gestire VMware, supportando la migrazione delle macchine virtuali VMware verso una nuova piattaforma tramite la gestione del vCenter, richiamando l’interfaccia VDDK. Consente la migrazione batch dei sistemi in stato “powered-on”, e nella fase finale della migrazione la macchina virtuale sorgente viene spenta per completare il processo. L’intero procedimento adotta un metodo simile a vMotion, semplificando e rendendo efficiente l’operazione di migrazione.
Passaggi chiave per la migrazione gestita VMware:
- La piattaforma cloud/virtualization di Sangfor si connette a vCenter; è necessario aprire le porte 443 e 902 tra la piattaforma Sangfor e vCenter, compatibili con le versioni di vCenter dalla 5.0 alla 7.0.2.
- Dopo il completamento della connessione gestita, selezionare più macchine virtuali aziendali per la migrazione batch. Durante il processo, un massimo di due macchine virtuali viene migrato contemporaneamente, mentre le restanti sono messe in coda. La velocità complessiva di migrazione dipende dalla qualità della rete e dalla velocità dello storage.
- All’interno della piattaforma Sangfor, configurare le attività di migrazione, definendo per ciascuna macchina virtuale post-migrazione il luogo di esecuzione, la connessione di rete, il limite di velocità di migrazione, la trasmissione compressa, ecc., e avviare il task di migrazione della macchina virtuale.
- Nella fase finale della migrazione, dopo il completamento della conversione del formato dell’immagine della macchina virtuale, la piattaforma avvia automaticamente la macchina virtuale per l’iniezione dei driver e l’ottimizzazione della configurazione, mentre la macchina virtuale sorgente viene spenta (non eliminata), e il business viene instradato verso l’accesso della macchina virtuale di destinazione.
- Verificare che l’accesso al sistema sia normale, a conferma del completamento della migrazione. In caso di accesso anomalo e necessità di rollback, è possibile spegnere la macchina virtuale di destinazione e riavviare la macchina VMware originale per ripristinare il business.
Precauzioni per la migrazione gestita VMware:
- Scenari non migrabili: le macchine virtuali VMware montate con LUN di storage esterno, RDM di tipo bare disk, mapping di USBKEY, ecc., non possono essere catturate dagli snapshot VDDK e non possono essere migrate verso la piattaforma Sangfor tramite migrazione gestita. Si consiglia di smontare prima della migrazione e di rimontare/mappare manualmente sulla nuova macchina virtuale dopo la migrazione.
- Modifiche alla configurazione di migrazione: la migrazione gestita replica completamente la macchina virtuale sorgente sulla nuova piattaforma, includendo CPU, memoria, IP, hostname, storage e altre risorse, senza modifiche. Se sono necessarie modifiche, queste devono essere configurate manualmente durante l’avvio delle applicazioni. L’indirizzo MAC e l’UUID della macchina virtuale dopo la migrazione cambieranno; se alcune applicazioni dipendono da MAC o UUID per l’autorizzazione o il binding di funzioni, è necessario modificare la configurazione sulla piattaforma dopo la migrazione.
- Evitare l’impatto delle snapshot: la migrazione gestita si basa sulle snapshot per catturare e confrontare le differenze dei dati dei VMDK. Durante l’intero processo di migrazione vengono eseguite più operazioni di snapshot, che possono avere un impatto significativo sulle prestazioni delle applicazioni aziendali. Pertanto, per la migrazione di workload ad alta intensità, è necessario richiedere una finestra di downtime specifica prima di procedere.
- Migrazione con spegnimento e switch: l’intero processo di migrazione gestita è completamente automatizzato. Dopo l’avvio del task di migrazione, comprensivo di trasferimento dati, avvio della macchina di destinazione e switch di rete, tutte le operazioni vengono eseguite automaticamente dal sistema. Ad eccezione dello spegnimento manuale e della verifica del corretto funzionamento del business, non è richiesto alcun intervento umano. Il vantaggio è che l’operazione di migrazione risulta semplice, mentre lo svantaggio è che eventuali modifiche di configurazione non sono controllabili e esiste un rischio di spegnimento della macchina sorgente. Se le applicazioni aziendali sono particolarmente sensibili alla continuità o richiedono un controllo dettagliato del processo di switch, si consiglia di utilizzare lo strumento SCMT per la migrazione.
Riepilogo della tecnologia di migrazione da VMware a Sangfor
In questo articolo ci siamo concentrati sui punti salienti della soluzione di migrazione dei dati delle macchine virtuali VMware. Se desideri approfondire tutti i metodi di migrazione, contattaci!