Misure di mitigazione dei rischi e strategie di rollback per la migrazione a IBM Cloud VPC
Ridurre i rischi legati alla migrazione di IBM Cloud VPC — guasti di rete, danneggiamento dei dati, problemi di prestazioni — e implementare procedure di rollback.
Rischi comuni di migrazione
Le seguenti informazioni riguardano le difficoltà comuni che si possono incontrare dopo una migrazione.
Rischio: interruzione della connettività di rete
Sintomo: dopo la migrazione, il server virtuale non riesce a comunicare con altri sistemi.
Rilevamento: I test di connettività post-migrazione non riescono.
Correzione:
- Accedere tramite la console VNC (Virtual Network Computing) per risolvere i problemi
- Verificare la configurazione dell'interfaccia di rete virtuale (VNI) (indirizzo IP, gruppi di sicurezza)
- Controllare le tabelle di routing nella VPC e Transit Gateway
- Esaminare le regole del gruppo di sicurezza (utilizzare i log dei flussi VPC per vedere i pacchetti caduti)
Rollback: Riavviare i server virtuali VMware e aggiornare i DNS e i bilanciatori di carico in modo che puntino nuovamente a VMware.
Prevenzione:
- Testate a fondo la connettività di Transit Gateway prima della migrazione
- Verificare che le regole del gruppo di sicurezza consentano il traffico richiesto
- Test della risoluzione DNS nella VPC di destinazione
Rischio: l'applicazione non si avvia
Sintomo: il servizio applicativo non si avvia dopo la migrazione, oppure si avvia ma non funziona.
Rilevamento: Il servizio non si avvia o si avvia ma non supera i controlli di salute.
Soluzione:
- Controllare i log dell'applicazione per individuare eventuali errori
- Verifica dei file di configurazione
- Controllare le variabili d'ambiente
- Verificare la connettività del database
- Verificare la presenza di problemi di licenza
Rollback: Arresto dell'applicazione in VPC, riavvio in un ambiente VMware.
Prevenzione:
- Verificare che tutte le dipendenze siano migrate o accessibili tramite Transit Gateway.
- Testare le procedure di avvio delle applicazioni che si trovano nell'onda pilota.
- Documentate la configurazione specifica dell'applicazione che potrebbe essere necessario regolare.
Rischio: corruzione dei dati
Sintomo: dati corrotti, errori del file system o incoerenze dei dati dell'applicazione.
Rilevamento: Errori di controllo del file system, l'applicazione riporta errori di dati, il database non si avvia
Soluzione:
- Tentare una riparazione del file system
- Se la riparazione non riesce, riprovare la migrazione dal server virtuale di origine
- Verificare che il server virtuale di origine sia stato chiuso in modo pulito
Rollback: Eliminare il server virtuale VPC danneggiato, riavviare il server virtuale di origine e indagare sulla causa principale prima di riprovare la migrazione.
Prevenzione:
- Arresto pulito dei server virtuali prima della migrazione
- Verifica dei trasferimenti con checksum, ove possibile
- Utilizzare
blockdev --flushbufsprima di staccare i volumi
Rischio: degrado delle prestazioni
Sintomo: l'applicazione funziona peggio in VPC che in VMware.
Rilevamento: Aumento dei tempi di risposta e riduzione del throughput
Soluzione:
- Controllare le metriche di CPU, memoria, I/O del disco e larghezza di banda della rete
- Verificare che il profilo di archiviazione disponga di IOPS adeguati
- Verificare che il profilo di istanza disponga di una larghezza di banda di rete adeguata
- Verificare la presenza di problemi di configurazione dell'applicazione
- Considerare l'aggiornamento dei profili di istanza o di archiviazione
Rollback: In caso di criticità, eseguire il failback a VMware mentre si analizzano le prestazioni.
Prevenzione:
- Prestazioni di base in VMware prima della migrazione
- Selezionare i profili di istanza e di archiviazione appropriati, basati sulle linee di base
- Abilita l'allocazione della larghezza di banda dello storage in pool
Progettazione della strategia di rollback
Per determinare se è necessario eseguire il rollback, utilizzare i seguenti criteri.
- Più del 20% dei server virtuali in un'ondata non riesce ad avviarsi
- Le applicazioni critiche non superano i test funzionali
- Nei server virtuali migrati vengono rilevati dati corrotti
- Degrado delle prestazioni superiore al 50% rispetto alla linea di base senza una soluzione rapida
- Gli errori di configurazione dei gruppi di sicurezza espongono i servizi sensibili
Autorità decisionale di rollback:
- Definire chi può prendere la decisione di rollback
- Definire il percorso di escalation in caso di disaccordo tra i decisori
- Decisione di rollback del timebox
Procedure di rollback
La sezione seguente illustra le fasi della procedura di rollback.
Utilizzo della procedura di rollback della Fase 1
Prima di creare i server virtuali durante la migrazione, seguire i seguenti passaggi per utilizzare la procedura di rollback della Fase 1. Questo processo richiede circa 30 minuti.
- Fermare la migrazione.
- Scartare i server virtuali e i volumi dei lavoratori.
- Riavviare i server virtuali VMware.
- Aggiornare le comunicazioni di stato.
Utilizzo della procedura di rollback della Fase 2
Dopo i server virtuali creati durante la migrazione, ma prima del cutover DNS, seguite questi passaggi per utilizzare la procedura di rollback della Fase 2. Questo processo richiede circa 1 ora.
- Arresto ed eliminazione dei server virtuali migrati.
- Riavviare i server virtuali VMware.
- Verificare che i server virtuali VMware siano funzionanti.
- Aggiornare le comunicazioni di stato.
Utilizzo della procedura di rollback della Fase 3
Dopo il cutover del DNS durante la migrazione, i dati potrebbero cambiare. Per utilizzare la procedura di rollback della Fase 3, procedere come segue. A seconda delle dimensioni dei dati, questo processo richiede 2-4 ore.
- Interrompere i server virtuali, ma non eliminarli.
- Aggiornare i DNS e i bilanciatori di carico in modo che puntino a VMware.
- Riavviare i server virtuali VMware.
- Decisione sui dati:
- Se i dati non sono stati modificati, procedere con il rollback.
- Se i dati sono stati modificati nella VPC, è necessario sincronizzare i dati su VMware prima di poter eseguire il rollback.
- Sincronizzare i dati, se necessario.
- Verificare che i server virtuali VMware siano funzionanti.
- Dopo il periodo di verifica, eliminare i server virtuali VPC
Conservazione del server virtuale di origine
Per assicurarsi che i server virtuali di origine siano conservati, utilizzare le seguenti informazioni.
- Non eliminare i server virtuali VMware subito dopo la migrazione.
- Il periodo di conservazione è di 7-30 giorni, a seconda della vostra tolleranza al rischio.
- Creare le istantanee di VMware.
- Documentate le posizioni delle istantanee e le vostre politiche di conservazione.