Pianificazione delle ondate di migrazione dei server virtuali su IBM Cloud VPC

Pianificare le fasi di migrazion IBM Cloud VPC e mappando le dipendenze delle macchine virtuali ( VM ), stimando la velocità e programmando le finestre di cutover per gli stack applicativi.

Pianificazione della dipendenza

Prima di avviare le onde di migrazione, è necessario mappare le seguenti dipendenze dell'applicazione:

Basato sui livelli:

  • Livello web → Livello app
  • Livello app → Livello database
  • Livello database → Storage e servizi condivisi

Applicazione incrociata:

  • Autenticazione
  • Monitoraggio
  • Backup
  • Aggregazione dei log
  • DNS e NTP

Strumenti per la scoperta:

  • VMware vRealize Network Insight ( ) vRNI
  • Strumenti di mappatura delle dipendenze delle applicazioni
  • Analisi del flusso di rete
  • Documentazione manuale dei proprietari delle applicazioni

Per ogni server virtuale, registrare le seguenti informazioni nel piano di migrazione:

  • Dipendenze in entrata
  • Dipendenze in uscita
  • Risorse condivise

Progettazione dell'onda di migrazione di prova

La prima ondata di migrazione è quella di prova (pilota). Per implementare un'ondata di test di successo, è necessario attenersi alle seguenti informazioni:

Rappresentazione corretta dei vostri server virtuali:

  • Server virtuale a disco singolo Linux
  • Server virtuale multi-disco Linux
  • Server virtuale Windows a disco singolo
  • Server virtuale Windows multidisco
  • Applicazione con dipendenze (applicazione a 3 livelli)

Utilizzare opzioni a "rischio minimo":

  • Implementare la migrazione in un ambiente non di produzione. Oppure, utilizzare un ambiente di produzione con ampie finestre di manutenzione.
  • Conoscere la procedura di rollback delle applicazioni.

Eseguire una migrazione completa:

  • Test completo end-to-end dei metodi scelti
  • Nota sui tempi di migrazione rispetto ai tempi stimati
  • Scoperta di problemi non riscontrati in fase di test

Criteri di successo della migrazione:

  • Tutti i server virtuali si avviano con successo
  • Le applicazioni funzionano correttamente
  • Verifica della connettività di rete
  • Le prestazioni soddisfano o superano la linea di base
  • Nessuna perdita o corruzione di dati
  • La documentazione della migrazione è completa e accurata

Linee guida per la struttura dell'onda

Raggruppamento basato su subnet:

Ricordate che non è possibile estendere una subnet tra VMware e VPC. Ciò significa che è necessario eseguire le seguenti operazioni:

  • Raggruppare i server virtuali per sottorete
  • Migrare intere sottoreti in un'unica ondata o sapere che è necessario eseguire nuovamente l'IP di alcuni server virtuali
  • Pianificare in anticipo la mappatura della sottorete alla sottorete VPC

Raggruppamento di stack di applicazioni per applicazioni multitier:

  • Se possibile, migrare l'intero stack in un'unica ondata.
  • Se la migrazione è troppo grande, migrare prima il database, poi le applicazioni e così via.
  • Mantenere la connettività tra i livelli migrati e quelli non migrati tramite IBM Cloud Transit Gateway.

Raggruppamento di stack di applicazioni per il sequenziamento consapevole delle dipendenze:

  • Migrare innanzitutto i servizi di infrastruttura (DNS, monitoraggio, backup).
  • Migrare i servizi condivisi prima delle applicazioni di cui hanno bisogno.
  • Considerare gli effetti di ogni onda e valutare l'impatto in caso di fallimento.

Capacità di migrazione parallela:

Il metodo 3 Trasferimento in rete dal vivo(consigliato per la Scala) eccelle in questo caso:

  • Provisionare più istanze di server virtuale worker
  • Migrare più server virtuali contemporaneamente
  • Limitato dalla larghezza di banda della rete e dalle risorse dell'istanza del server virtuale del lavoratore
  • Tipico: 4-8 migrazioni contemporanee per istanza di server virtuale worker

Struttura di esempio dell'onda di prova

L'esempio seguente mostra una migrazione di 50 server virtuali.

Ondata 0 (test): 5 server virtuali

  • 1x Disco singolo Linux (test Metodo 1)
  • 1x Multi-disco Linux (test Metodo 2)
  • 1x Windows a disco singolo (Metodo 1 con sysprep)
  • 1x Windows a più dischi (Metodo 2 con virt-v2v )
  • 1x applicazione di test a 3 livelli (metodi 2 e 3, full stack)

Ondata 1 (infrastruttura): 8 server virtuali

  • server DNS
  • Monitoraggio dei server
  • Host di salto o server bastione
  • File server condivisi migrati all'archiviazione file VPC

Ondata 2 (applicazione A): 12 server virtuali

  • Livello database (3 server virtuali)
  • Livello app (6 server virtuali)
  • Livello Web (3 server virtuali)
  • Sottorete 10.50.10.0/24 → Sottorete VPC 10.240.10.0/24

Ondata 3 (Applicazione B): 10 server virtuali

  • Database e app tier combinati (4 server virtuali)
  • Livello Web (6 server virtuali)
  • Sottorete 10.50.20.0/24 → Sottorete VPC 10.240.20.0/24

Ondata 4 (Applicazione C): 15 server virtuali

  • Applicazione multitier di grandi dimensioni
  • Sottorete 10.50.30.0/24 → Sottorete VPC 10.240.30.0/24

Progettazione della finestra di transizione

Ogni onda ha bisogno di una finestra di cutover ben definita.

Tempistica pre-cutover (da 7 giorni al giorno della migrazione):

  • Finalizzare il piano d'onda e il runbook
  • Confermare la connettività di Transit Gateway
  • Provisionare le istanze di server virtuale worker e i volumi di destinazione
  • Comunicare la finestra di cutover alle parti interessate
  • Ridurre il TTL del DNS per i servizi in fase di migrazione
  • Notifica agli utenti della finestra di manutenzione

Esecuzione del cutover ( T-0 )

Le seguenti informazioni descrivono le fasi del cutover.

Fase 1: sospensione e migrazione (ore 0-4)

  1. Svuotare le connessioni: rimuovere dai bilanciatori di carico e attendere la chiusura delle sessioni.
  2. Arresto graduale delle applicazioni
  3. Arresto dei server virtuali o avvio da ISO live per il Metodo 3
  4. Iniziare il trasferimento del disco
  5. Monitorare i progressi del trasferimento

Fase 2: trasformazione e fornitura (ore 4-6)

  1. Eseguire virt-v2v, se necessario, per iniettare i driver
  2. Verifica dei trasferimenti su disco (fdisk, checksum)
  3. Sciacquare i buffer e staccare i volumi dal worker
  4. Creare le istanze di server virtuale dai volumi migrati
  5. Avvia le istanze del server virtuale

Fase 3: Convalida e cutover (ore 6-8)

  1. Avviare le istanze del server virtuale e accedere attraverso la console VNC, se necessario
  2. Verificare la configurazione di rete e modificarla se necessario
  3. Avvio delle applicazioni
  4. Test funzionali (applicazione funzionante, dati accessibili)
  5. Aggiungere ai bilanciatori di carico e aggiornare il DNS
  6. Monitora le prestazioni dell'applicazione

Fase 4: stabilizzazione (ore 8-12)

  1. Monitoraggio dei problemi
  2. Verificare la connettività esterna
  3. Controllare i log dell'applicazione per individuare eventuali errori
  4. Confronto delle prestazioni con la linea di base

Punti di decisione per il rollback della migrazione:

  • Dopo la Fase 1: rollback semplice (riavvio dei server virtuali VMware )
  • Dopo la Fase 2: difficoltà media (scartare le istanze del server virtuale, riavviare i server virtuali VMware, ripristinare il DNS)
  • Dopo la Fase 3: Difficile (potrebbero esserci nuovi dati nella VPC, è necessaria una sincronizzazione dei dati con VMware )

Raccomandazione per la progettazione: Definire punti di controllo espliciti per l'accesso e il non accesso. Esempi:

  • Dopo la Fase 2, se più del 20% delle istanze del server virtuale non si avvia, è necessario eseguire un rollback.
  • Dopo la Fase 3, se i test funzionali dell'applicazione falliscono, implementare un rollback.
  • Dopo la Fase 4, se le prestazioni sono inferiori di oltre il 30% rispetto alla linea di base, indagare, ma non implementare un rollback.

Stima della velocità di migrazione

Stimare il tempo di migrazione per server virtuale per pianificare dimensioni e finestre d'onda realistiche. Il seguente calendario è realizzabile, ma è necessario consultare il sito PoC prima della migrazione vera e propria.

Componenti temporali:

Esportare le stime dei tempi utilizzando i metodi 1-2:

  • server virtuale da 100 GB: 20-30 minuti
  • server virtuale da 500 GB: 2-3 ore
  • Dipende dalle prestazioni dello storage VMware

Stima dei tempi di trasferimento:

  • Rete: 100 GB = 20-25 minuti
  • Rete: 500 GB = 90-120 minuti
  • Metodo 3 con compressione: spesso 2 o 3 volte più veloce grazie alla compressione

Stime dei tempi di trasformazione con virt-v2v:

  • Linux: 5-10 minuti
  • Windows: 10-20 minuti
  • Dipende dalle prestazioni dell'istanza del server virtuale worker

Stime dei tempi di provisioning:

  • Creazione dell'istanza del server virtuale: 5 minuti
  • Avvio e configurazione di rete: 5-10 minuti

Esempi di tempi stimati:

Piccolo server virtuale Linux (1 disco, 100 GB, Metodo 3):

  • Nessuna esportazione: 0 minuti
  • Trasferimento con compressione: 25 minuti
  • Trasformazione: 5 minuti
  • Provisioning: 10 minuti
  • Totale: 40 minuti

Stima dei tempi del server virtuale Windows di grandi dimensioni utilizzando il metodo 2 con 4 dischi, 1 TB in totale:

  • Esportazione: 3 ore
  • Trasferimento: 2 ore
  • Trasformazione ( virt-v2v ): 20 minuti
  • Provisioning: 10 minuti
  • Totale: 5.5 ore

Efficienza della migrazione parallela utilizzando entrambi i metodi 3 e 4 per la stima dei tempi:

  • 4x server virtuali da 100 GB che vengono migrati in parallelo
  • 30 minuti ciascuno
  • Tempo d'onda totale: 35 minuti, che includono i tempi di avvio e spegnimento

Rispetto alla migrazione di 4x, i server virtuali da 100 GB vengono migrati in serie:

La durata totale dell'onda è di 120 minuti

Il parallelismo offre un miglioramento di 3-4 volte in questo scenario.