Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Fase di conversione
Quando si migrano componenti che archiviano dati, è necessario considerare se la coerenza dei dati sia un requisito fondamentale. In tal caso, potrebbe essere necessario bloccare l'ambiente di origine (ad esempio un blocco del database) prima di iniziare il processo di conversione. Il blocco del database può garantire che non vengano effettuate nuove transazioni nell'ambiente di origine. Tuttavia, il blocco potrebbe richiedere una finestra di inattività più ampia.
La conversione prevede generalmente le seguenti fasi:
Congelamento dell'importazione: blocca l'importazione di applicazioni e dati on-premise nel database. Ciò garantisce che la versione on-premise dell'applicazione non riceva nuove transazioni o dati durante la conversione.
Backup: effettua il backup finale del sistema on-premise. Se necessario, è possibile utilizzare questo backup per il rollback in caso di emergenza.
Sincronizzazione dati: completa la sincronizzazione finale dei dati tra l'ambiente on-premise e quello di destinazione (cloud).
Modifiche al routing: indirizza gli utenti verso l'ambiente cloud (ad esempio, aggiornando i record DNS o modificando gli obiettivi del sistema di bilanciamento del carico).
Test: verifica e convalida che tutto funzioni prima di contrassegnare la migrazione come completa.
Approccio di conversione
Esistono due approcci intermedi da prendere in considerazione: un all-at-once approccio o un approccio graduale. La chiave per scegliere l'approccio di conversione migliore è comprendere i requisiti aziendali e i vincoli tecnici. In questa sezione viene fornita una panoramica di entrambi gli approcci.
All-at-once approccio
Se segui l' all-at-onceapproccio, interrompi l'intera soluzione premendo un interruttore. Ad esempio, puoi farlo aggiornando il DNS o modificando un sistema di bilanciamento del carico. Quindi, tutti gli utenti e il traffico in tempo reale utilizzano immediatamente il nuovo sistema. Questo approccio può essere utile in scenari in cui non è possibile portare nuovi sistemi online a causa di un potenziale conflitto tra host e nomi, problemi di licenza o vincoli di autenticazione del dominio. Poiché il tempo è fondamentale, la cosa più importante è capire quando verrà richiesto o chi richiederà un failback. Ti consigliamo di pianificare un all-at-once approccio che includa test approfonditi delle prestazioni e, ove applicabile, test di regressione, in modo da poter convalidare le caratteristiche funzionali e non funzionali dell'applicazione.
Approccio graduale (implementazioni canary)
L'approccio graduale prevede una conversione graduale in un periodo di tempo definito. Questo approccio include monitoraggio e controlli continui per verificare se il sistema attuale è in grado di sostenere il carico e se ogni componente del sistema funziona come previsto. Un approccio graduale può aiutare a ridurre il rischio di potenziali problemi di conversione, poiché è possibile regolare le prestazioni del sistema in base al feedback. Inoltre, è più facile eseguire il rollback eventuali modifiche se si identificano problemi critici.
Scelta dell'approccio giusto
Per scegliere l'approccio giusto, identifica quanto segue:
Applicazioni e servizi dipendenti che fanno parte dello stesso gruppo di spostamento
Origini dati comuni che possono essere utilizzate tra applicazioni on-premise e migrate
Applicazioni e infrastrutture in grado di reindirizzare i carichi parziali verso endpoint diversi
Se disponi di un'applicazione che non può tollerare un aumento della latenza tra l'origine dati e i server delle applicazioni, questo è un chiaro indicatore della necessità di un approccio. all-at-once In questo scenario, puoi raggruppare tutte le risorse dell'applicazione (server e database) per evitare ripercussioni sulle prestazioni.
In un cutover graduale, si divide una percentuale dei server e dei servizi che costituiscono un'applicazione dall'insieme e si passa a far AWS sì che i server e i servizi rimanenti rimangano locali. Quindi, si indirizza il traffico client verso entrambi gli ambienti in base al bilanciamento del carico o alla politica DNS. La conversione graduale consente di ridurre al minimo l'impatto sugli utenti in modo che tale conversione riguardi il minor numero di utenti possibile. Se riesci a identificare un impatto, puoi modificare di conseguenza le percentuali di server e servizi. Tuttavia, un approccio di conversione graduale si basa sulla capacità delle applicazioni sottostanti di supportare l'approccio. Ti consigliamo di porti le seguenti domande:
-
L'applicazione ha più livelli (front-end, back-end, database) costituiti da coppie o gruppi di server resilienti che possono essere suddivisi?
-
L'accesso all'applicazione avviene tramite un sistema di bilanciamento del carico e il sistema di bilanciamento del carico supporta l'instradamento del traffico verso la rete e la rete locale? AWS
I server delle applicazioni possono essere migrati per AWS tollerare la latenza verso un database o un'altra dipendenza dal backend. Se il database viene interconnesso AWS, i server o i servizi che rimangono locali possono continuare a funzionare e funzionare come richiesto?
La possibilità di inviare una percentuale degli utenti ai server di nuova migrazione mantenendo al AWS contempo la capacità locale esistente offre un vantaggio fondamentale rispetto a un all-at-once approccio in termini di funzionalità di rollback. Poiché disponi di una combinazione di server migrati ed esistenti che servono l'applicazione con un carico ripartito tra loro, è facile e veloce ripristinare l'applicazione in caso di problemi. Nella maggior parte dei casi, è sufficiente modificare un sistema di bilanciamento del carico, una regola DNS o una policy. L'approccio graduale consente inoltre di aumentare gradualmente il carico di lavoro AWS, il che consente ai team addetti all'applicazione di valutare le prestazioni dell'applicazione e apportare gli aggiornamenti o le modifiche necessarie prima del trasferimento del pieno carico.
La scelta se sia preferibile tagliare contemporaneamente un'applicazione o una pila di applicazioni dipendenti o se utilizzare un approccio incrementale in cui server e servizi vengono suddivisi in più fasi è improbabile che sia una decisione. one-size-fits-all Di solito i clienti adottano i seguenti approcci:
-
Gli ambienti di sviluppo e test in grado di tollerare alcuni tempi di inattività trarranno vantaggio dalla semplicità e dal minor livello di impegno necessari per superare l'approccio. all-at-once
-
Al contrario, l'approccio graduale è più complesso e richiede molto tempo, ma in genere prevede tempi di inattività inferiori e opzioni di rollback più rapide. Per questo motivo, l'approccio graduale è più comunemente adottato per carichi di lavoro di produzione business-critical.
Ti consigliamo di dedicare del tempo alla comprensione dei sistemi di origine prima della finestra di modifica della conversione. Investendo più tempo nelle fasi iniziali di pianificazione, è possibile supportare vari processi, come la preparazione della conversione e la convalida post-migrazione. I clienti possono modificare gli indirizzi IP dei propri server durante la migrazione a. AWS In questo scenario, il fattore chiave da evitare è la presenza di indirizzi IP codificati all'interno dell'applicazione. Ti consigliamo di esaminare in modo olistico l'ambiente di origine, che può avere dipendenze sia a monte che a valle. Ad esempio, è più probabile che tu causi problemi ad altri sistemi che si connettono al servizio del quale hai eseguito la migrazione. Vale la pena valutare se sia utile spostare tutte le connessioni per utilizzare nomi di dominio completi (FQDN) o record DNS prima di iniziare la conversione.
Quando eseguire la conversione
In generale, il momento migliore per un evento di conversione è quello in cui si ha il minor numero di utenti, in quanto l'impatto aziendale sarà ridotto al minimo. Tuttavia, questo deve essere bilanciato dalla disponibilità di team di supporto durante la finestra di conversione. Hai bisogno di team di supporto che ti aiutino a risolvere i problemi potenziali. È anche importante considerare la data e l'ora della conversione, oltre a garantire la disponibilità delle parti interessate. Se alcune delle parti interessate non sono preparate e non sono disponibili alla data e all'ora previste, la conversione può subire ritardi.
Cosa testare prima della conversione
Se il tuo approccio alla migrazione lo consente, è consigliabile eseguire test funzionali e non funzionali prima della finestra di conversione. Ad esempio, puoi sfruttare gli strumenti di test del carico per verificare se il nuovo ambiente è configurato correttamente prima della finestra di conversione. In generale, i test durante questa fase non comportano interruzioni in quanto l' AWS ambiente non fornisce traffico in tempo reale.
Cosa non può essere testato prima della conversione
Potrebbe non essere possibile testare tutti gli scenari che si verificheranno in produzione a causa delle dipendenze con altre applicazioni. In questi casi, documenta i rischi potenziali, il modo in cui intendi identificarli e quali approcci di mitigazione corrispondenti adotterà il team in caso di esito negativo del test.
Revisione della prontezza operativa
Prima di trasferire l'applicazione a AWS, si consiglia di eseguire una verifica della fattibilità operativa. È qui che si valuta la completezza dei test, si convalida la capacità del team di monitorare e ricevere avvisi e si conferma che le parti interessate comprendono come supportare e mantenere il carico di lavoro. Ciò richiederà probabilmente la collaborazione con team aziendali e tecnici. Per ulteriori informazioni sulla prontezza operativa, consulta l'Operational Excellence Pillar of the AWS Well-Architected Tool Framework di AWS Well-Architected
Rollback
In determinate condizioni può essere necessario un rollback della migrazione. Per prepararti a un potenziale rollback, ti consigliamo di sviluppare un piano di rollback che includa quanto segue:
Checkpoint definiti che determinano un rollback durante la conversione se vengono soddisfatti determinati criteri predefiniti
Una strategia di rollback per la gestione del rollback e la gestione dei dati
Un punto di contatto che prenderà la decisione se correggere o annullare la migrazione
Rollback durante la conversione o senza nuovi dati
Se tu e le parti interessate decidete di eseguire un rollback senza che i dati vengano modificati, l'approccio di rollback può essere semplice: basta riprendere le istanze on-premise e quindi reindirizzare il traffico modificando il sistema di bilanciamento del carico o le configurazioni DNS.
Effettua il rollback con i dati modificati
Se viene avviato un rollback dopo una conversione riuscita e l'applicazione ha ricevuto nuove transazioni e dati, potrebbe essere necessario ripristinare i dati dall'ambiente cloud all'ambiente on-premise. In questo scenario, ti consigliamo di prendere in considerazione i seguenti approcci:
Approccio fallimentare: è probabile che il database locale diventi obsoleto dopo il cutover poiché il database successivo alla migrazione diventa il database principale. AWS È possibile utilizzare AWS Database Migration Service (AWS DMS)
per configurare un database di fail-forward, che replicherà i dati in un nuovo database locale. In caso di problemi, AWS DMS ripristina le applicazioni su un database di fail-forward designato anziché su un database locale obsoleto. Strategia di scrittura doppia: in questo caso, la logica dell'applicazione deve consentire la scrittura sia sul vecchio che sul nuovo database.
Backup nativo e ripristino: per valutare il tempo necessario per il ripristino, è possibile eseguire test di backup e ripristino utilizzando ambienti inferiori (ovvero ambienti non di produzione) durante la fase di pre-conversione.
