Pianificare la migrazione del carico di lavoro da Amazon Web Services (AWS) ad Azure

Questo articolo fa parte di una serie su come eseguire la migrazione di un carico di lavoro da Amazon Web Services (AWS) ad Azure.

La fase di pianificazione è costituita da questi passaggi:

L'obiettivo della fase di pianificazione è comprendere il carico di lavoro AWS esistente dal punto di vista tecnico e aziendale, in modo da poter creare in modo sicuro un piano per replicarlo in Azure.

Valutare il carico di lavoro DI AWS

Per creare un sistema paragonabile in Azure, è prima necessario comprendere appieno il sistema corrente. Valutarlo da più prospettive per assicurarsi di progettare un'implementazione di Azure che soddisfi allo stesso modo le esigenze di utenti, operatori, sviluppatori, conformità e stakeholder aziendali.

1. Documentare l'architettura del carico di lavoro esistente: Documentare e verificare completamente l'architettura del carico di lavoro. Includere tutte le dipendenze del carico di lavoro, ad esempio configurazioni di rete, flussi di dati e integrazioni esterne.

2. Autenticazione e autorizzazione dei documenti: Includere le configurazioni di gestione delle identità e degli accessi (IAM) nella valutazione. La documentazione completa su come AWS gestisce l'autenticazione e l'autorizzazione è fondamentale per progettare un equivalente di Azure sicuro e funzionale.

3. Usare gli strumenti di individuazione: Usare strumenti specifici di AWS, ad esempio l'individuazione del carico di lavoro in AWS, per visualizzare il carico di lavoro AWS. Questo strumento usa i dati di AWS Config e AWS Systems Manager per identificare i componenti, le dipendenze e le relazioni del carico di lavoro. Usare gli strumenti di Azure, ad esempio Azure Migrate, per individuare altri componenti del carico di lavoro AWS e fornire raccomandazioni specifiche di Azure.

4. Identificare i flussi critici: Eseguire il mapping di interazioni e flussi di lavoro essenziali per utenti e sistemi. Quando si progetta l'architettura di destinazione nella sezione successiva, queste informazioni consentono di classificare in ordine di priorità le attività di affidabilità e proteggere i componenti più importanti e con impatto in caso di errore.

5. Creare un inventario dettagliato: Creare un elenco delle esigenze dell'ambiente AWS corrente per eseguire il carico di lavoro, inclusi tutti i server, i componenti di archiviazione, i database e i servizi. Includere anche modelli di utilizzo, metriche delle prestazioni e requisiti di licenza.

6. Coinvolgere esperti in materia (PMI): Oltre agli strumenti di individuazione automatizzati, coinvolgere gli esperti in tutto il team del carico di lavoro per individuare dipendenze nascoste, relazioni tra componenti complessi e stato sensibile. Gli strumenti spesso mancano componenti critici, ad esempio script pianificati, integrazioni non documentate o configurazioni legacy. Una conversazione con le PMI può rivelare queste sfumature e prevenire comportamenti imprevisti durante la migrazione. Includere il loro input nel piano di migrazione e nel runbook.

7. Valutare le competenze del team: Concentrarsi sulla mappatura delle funzionalità equivalenti. Identificare le competenze già usate dal team in AWS e allinearle ai servizi e agli strumenti di Azure equivalenti. Includere il training di Azure nella sequenza temporale del progetto per preparare i team operativi e del carico di lavoro. Questo approccio riduce l'attrito e crea fiducia in Azure perché l'esperienza esistente in AWS si traduce direttamente nel nuovo ambiente.

8. Documentare gli impegni esistenti: Documentare la baseline delle prestazioni definita del carico di lavoro, tra cui velocità effettiva, latenza, percentuali di errore e utilizzo delle risorse. Se questi indicatori di prestazioni chiave (KPI) non sono disponibili, raccogliere queste metriche dall'ambiente AWS per stabilire questa baseline. Questi indicatori KPI vengono usati nella fase di valutazione dopo la migrazione per verificare che il carico di lavoro in Azure venga eseguito come in AWS.

   Verificare se sono presenti contratti di servizio o obiettivi a livello di servizio associati al carico di lavoro. Questi impegni per gli utenti o gli stakeholder non cambiano in base alla piattaforma cloud. Ad esempio, se l'obiettivo del tempo di ripristino (RTO) in AWS è di 45 minuti, è necessario progettare il carico di lavoro in Azure per avere anche un RTO di 45 minuti.

9. Documentare il monitoraggio e gli avvisi correnti: Documentare come monitorare attualmente il carico di lavoro in AWS. Ad esempio, è possibile utilizzare metriche, allarmi o dashboard di CloudWatch. Pianificare un monitoraggio equivalente di Azure per l'ambiente di destinazione. È possibile usare i log di Azure Monitor, le metriche o i dashboard di Application Insights. Coinvolgere il team operativo in questa valutazione in modo che siano pronti per implementare e gestire avvisi e monitoraggio basati su Azure.

Progettare un'architettura simile a quella in Azure

Molti carichi di lavoro moderni basati sul cloud usano servizi gestiti o serverless anziché macchine virtuali (VM) per molte delle relative funzioni. Se il carico di lavoro AWS usa servizi gestiti, ad esempio Amazon Elastic Kubernetes Service (EKS) o Amazon Elastic Container Service (ECS), è necessario trovare la corrispondenza migliore in Azure per il caso d'uso. In alcuni casi, Azure potrebbe avere più servizi tra cui scegliere, ad esempio app in contenitori. Scegliere il servizio più simile. Ad esempio, non cambiare le piattaforme di orchestrazione dei contenitori durante la migrazione.

Il diagramma seguente mostra un esempio di architettura simile per un carico di lavoro Kubernetes in AWS e Azure.

Per iniziare a mappare l'architettura like-for-like, prima creare una base solida.

Iniziare con la rete. Discuti i requisiti di rete del carico di lavoro con il team della piattaforma. Questa discussione deve trattare l'architettura di destinazione e la connettività di migrazione. AWS Transit Gateway funge da hub di rete con Amazon Virtual Private Cloud (VPC) come rete satellite. Nella progettazione della zona di atterraggio dell'applicazione Azure, il team della piattaforma fornisce le reti virtuali spoke ai team del carico di lavoro. Queste reti spoke comunicano con altre reti interne ed esterne tramite l'hub o la rete WAN virtuale di Azure.

Per scambiare dati durante la migrazione, è possibile usare una rete privata virtuale da sito a sito (VPN) o Azure ExpressRoute con AWS Direct Connect. È possibile fare affidamento su una VPN da sito a sito per migrazioni più piccole o di tipo PoC (Proof of Concept). È consigliabile usare ExpressRoute con AWS Direct Connect per migrazioni su scala di produzione o trasferimenti di dati di grandi dimensioni. Se si usano entrambe le opzioni per una maggiore affidabilità, usare la VPN da sito a sito per il failover.

Per altre informazioni, vedere Eseguire la migrazione della rete da AWS ad Azure.

Dopo aver pianificato la rete, seguire questa procedura:

1. Identificare i servizi di Azure. Usare la guida al confronto delle risorse di AWS per Azure per scegliere i componenti di Azure del carico di lavoro. Compilare i POC per ottenere fiducia o aiutare a scegliere i componenti e la relativa configurazione. Usare le guide al servizio Azure Well-Architected Framework per garantire che l'architettura simile sia equivalente a livello funzionale e ottimizzata secondo le caratteristiche della piattaforma e le migliori pratiche su Azure.

2. Pianificare la gestione delle identità. Pianificare come gestire l'identità e l'accesso in Azure per gli utenti e per le operazioni del carico di lavoro. Se il carico di lavoro usa ruoli AWS IAM o provider di identità federati, determina il modo in cui questi ruoli si traducono in ruoli di Microsoft Entra ID, identità gestite o entità servizio. Esaminare eventuali nomi di risorse Amazon (ARN) hardcoded, criteri IAM o integrazioni di identità nell'applicazione. Se si ignora il mapping delle identità, è possibile che si verifichino problemi di accesso dopo la migrazione o integrazioni non funzionanti. L'integrazione con i provider di identità partner rappresenta una sfida durante le migrazioni. Se possibile, consolidare la gestione delle identità passando a Microsoft Entra ID.

3. Documentare le decisioni relative alla migrazione. Documentare le risorse che non vengono migrate e le decisioni prese relative all'architettura.

4. Ridurre i rischi. Identificare i componenti o i flussi ad alto rischio e compilare i POC in base alle esigenze per testare e attenuare tali rischi. Eseguire l'analisi della modalità di errore sui componenti per individuare in modo proattivo potenziali punti di errore e valutare il modo in cui influiscono sull'affidabilità del carico di lavoro. I componenti di Azure potrebbero avere nuove modalità di errore o avere esito negativo in modo diverso rispetto alle rispettive controparti in AWS.

5. Verificare la disponibilità. Controllare la disponibilità e la capacità del servizio di Azure nell'area preferita, soprattutto se si prevede di usare tipi di risorse specializzati. Quando si seleziona l'area di destinazione, allinearla strettamente con l'area AWS corrente. La migrazione a un'area di Azure geograficamente simile consente di mantenere una latenza coerente.

6. Convalidare i requisiti. Se si decide di usare Azure Migrate, esaminare la matrice di supporto di Azure Migrate per assicurarsi che le istanze di AWS soddisfino i requisiti di sistema operativo e configurazione. Se non si usa Azure Migrate, controllare manualmente la compatibilità del carico di lavoro con i servizi di Azure. Questo controllo include la verifica delle versioni del sistema operativo supportate, delle dimensioni delle macchine virtuali, delle configurazioni del disco e delle dipendenze di rete.

7. Soddisfare i requisiti di conformità e sicurezza. Mantenere un comportamento di sicurezza identico nel carico di lavoro. Assicurarsi che l'implementazione di Azure corrisponda alle aspettative di sicurezza, ad esempio l'applicazione di patch alla sicurezza del sistema operativo, l'isolamento della rete, l'ispezione in ingresso e in uscita, l'accesso con privilegi minimi, l'analisi statica del codice e le pianificazioni dei test di penetrazione.

   Assicurarsi che qualsiasi infrastruttura temporanea, connessioni di rete e processi creati per facilitare la migrazione soddisfi anche le aspettative di sicurezza. Le migrazioni possono essere caotiche e un errore o una scorciatoia nella sicurezza durante la migrazione potrebbe causare un incidente.

   Il modello di sicurezza usato da AWS è notevolmente diverso dal modello di sicurezza di Azure. Per altre informazioni, vedere Eseguire la migrazione dei servizi di sicurezza da AWS.

Sviluppare e documentare un piano di migrazione e creare un runbook

Sviluppare un piano di migrazione e creare un runbook per la migrazione da AWS ad Azure. Scegliere una strategia di cutover, selezionare gli approcci di migrazione dei dati in base ai requisiti dell'obiettivo del punto di ripristino (RPO) e documentare le procedure in un runbook dettagliato. Creare un piano completo approvato dagli stakeholder che riduce al minimo il rischio e garantisce una transizione controllata.

La strategia di cutover

Pianificare come tagliare il traffico di produzione dall'ambiente AWS all'ambiente Azure. Gli approcci seguenti sono i più comuni:

• Migrazione di Big Bang: È possibile eseguire la migrazione e cambiare tutto contemporaneamente durante una finestra di manutenzione.
• Migrazione in più fasi: Eseguire la migrazione incrementale dei componenti del carico di lavoro.
• Migrazione blu-verde (scelta consigliata): Due ambienti vengono eseguiti in parallelo e si passa al traffico dopo la convalida.

Differenze principali a colpo d'occhio

Per mantenere basso il rischio e semplificare il rollback, scegliere un approccio blu-verde. In questo scenario si mantengono due ambienti. Il blu è l'ambiente corrente (AWS) e il verde è il nuovo ambiente (Azure).

Nello scenario blu-verde si pianifica una finestra di migrazione, si esegue il carico di lavoro in AWS durante la migrazione e si sposta il traffico in Azure dopo un'esecuzione asciutta completata. Entrambi gli ambienti vengono eseguiti in parallelo durante la migrazione, quindi è possibile tornare al traffico verso AWS in caso di problemi nell'ambiente Azure. In questo scenario è necessaria anche una strategia di rollback per lo stato che potrebbe subire dei cambiamenti. Considerare i database e tipi di stato meno evidente, come elementi ancora da elaborare nelle code dei messaggi.

Se il carico di lavoro è più complesso e si vuole ridurre al minimo i rischi, è possibile combinare la strategia blu-verde con un approccio canary per deviare il traffico. L'approccio di tipo canary instrada una piccola percentuale di traffico verso il nuovo ambiente, aumentando gradualmente. L'approccio canary aumenta la complessità della migrazione perché lo stato attivo deve esistere sia in AWS che in Azure durante la transizione.

Se i componenti di AWS coesistono con componenti eseguiti in Azure, è consigliabile applicare modelli come la facciata Strangler Fig come parte di una strategia di cutover controllata. Questi livelli aggiuntivi di riferimento indiretto vengono implementati nella fase successiva della migrazione.

L'approccio blu-verde introduce un compromesso sui costi. Si comportano costi per entrambi i provider di servizi cloud durante la transizione. Per la maggior parte dei team, i costi aggiuntivi sono utili perché la strategia blu-verde riduce i rischi e il carico operativo.

Pianificare una finestra di manutenzione

È consigliabile negoziare una finestra di manutenzione generosa durante la fase di pianificazione per qualsiasi strategia di cutover usata. Una finestra sufficiente rispetta la natura sensibile delle attività di migrazione e considera la perdita di funzionalità durante la migrazione. Usare questo tempo di inattività pianificato per sviluppare piani che riducono il rischio di perdita di dati, danneggiamento dei dati o esperienze utente incoerenti. Ad esempio, usare questo tempo per svuotare i messaggi di Amazon Simple Queue Service (SQS).

Se il carico di lavoro ha un budget di interruzione, è consigliabile escludere la finestra di migrazione da tale budget e riservarla per problemi post-migrazione. Considera come questa decisione influisce sugli SLA contrattuali.

Scegliere la strategia di migrazione dei dati

La strategia di migrazione dei dati dipende dalla quantità di dati, dal tipo di archiviazione dei dati e dai requisiti di utilizzo. Scegliere tra la migrazione offline (backup e ripristino) e la replica in tempo reale.

Allinea la strategia con l'RPO del tuo carico di lavoro. Riferirsi all'RPO del carico di lavoro per guidare le decisioni durante la fase di dismissione e quando si sceglie una strategia di migrazione del database. L'RPO è la quantità massima di perdita di dati che è possibile accettare come parte del cutover. Ad esempio, un RPO potrebbe consentire non più di cinque minuti di perdita di dati durante il cutover. Ridurre al minimo il rischio di perdita di dati arrestando le operazioni di modifica dello stato all'interno del carico di lavoro prima del cut over.

Minore è il valore RPO, più è necessario prendere in considerazione la replica continua o i backup recenti e le finestre di manutenzione. Gli RPO inferiori possono anche aumentare i costi e il lavoro necessario per eseguire la migrazione dei dati.

Eseguire la migrazione del database. Valutare gli strumenti di AWS e Azure per la migrazione del database. Ad esempio, è possibile usare Azure Data Studio per replicare Amazon Relational Database Service (Amazon RDS) per SQL Server nel database SQL di Azure. Questa funzionalità supporta la replica continua da Amazon RDS al database SQL. In alternativa, è possibile usare AWS Database Migration Service (AWS DMS), che fornisce la replica continua e l'acquisizione dei dati delle modifiche fino a quando non si esegue il cut-over.

Nella maggior parte degli scenari, la migrazione dei dati avviene in più fasi. Ad esempio, è possibile eseguire una migrazione iniziale per il test e la convalida, seguita da una migrazione completa finale o dalla sincronizzazione continua per garantire l'aggiornamento dei dati. Questo approccio consente ai team di convalidare il comportamento delle applicazioni in Azure prima del cutover finale. Riduce anche il rischio di perdita di dati e supporta la pianificazione del rollback.

Trasferire i dati di archiviazione. Prendere in considerazione le opzioni seguenti per trasferire i dati di archiviazione da Amazon Simple Storage Service (Amazon S3) ad Azure.

Pianificare una finestra di manutenzione. Pianifica una finestra dedicata per i passaggi finali di cutover e decommissionamento. Documentare e comunicare con gli stakeholder prima di iniziare la migrazione. Includere il tempo per un possibile rollback e un passaggio al sistema DNS (Domain Name System).

Documento in un manuale operativo

Documentare le informazioni seguenti in un runbook da condividere con tutti i team e gli stakeholder coinvolti nella migrazione.

Sequenza di passaggi: Documentare la sequenza di passaggi a livello generale. Definire i passaggi esatti, la sequenza e l'intervallo di migrazione. Includere la finestra di manutenzione pianificata nella documentazione. Prendere in considerazione l'inclusione di una corsa secca, soprattutto per i cutover complessi. Documentare la strategia di rollback, la durata del TTL del DNS e come testare le metriche di successo.

Configurazione di sicurezza e rete: Includere tutte le modifiche alle regole del firewall, le porte necessarie e gli aggiornamenti ai gruppi di sicurezza di rete (NSG) o ai gruppi di sicurezza delle applicazioni necessari per supportare la connettività di Azure. Documentare eventuali eccezioni temporanee o sostituzioni necessarie durante il cutover e assicurarsi che le procedure di rollback tengano conto di queste modifiche.

Criteri di accettazione per l'approvazione: Definire il significato di un'operazione stabile e renderlo misurabile. Ad esempio, concordare che dopo il cutover, Azure deve essere eseguito per un numero specifico di minuti o ore senza errori e a condizione che il carico di lavoro passi tutti i test.

Criteri e passaggi del trigger di rollback: Documentare le condizioni esatte che attivano un rollback nell'ambiente AWS. Ad esempio, avviare un rollback se una funzionalità critica è inattiva o il sistema si trova in uno stato danneggiato, ad esempio una percentuale specifica al di sotto della baseline, per più di un numero specificato di minuti. Documentare le procedure di rollback.

A seconda delle modifiche dello stato, i rollback possono essere più complessi rispetto alla mitigazione del problema in Azure. I tentativi di mitigazione non riusciti potrebbero complicare anche un rollback. Comprendere quando risolvere un problema e quando eseguire il rollback delle modifiche per ridurre i rischi durante la migrazione.

Modifiche alla configurazione del client: Identificare e documentare tutti gli elementi di configurazione rivolti al client che influiscono sulla migrazione del carico di lavoro. Questi elementi includono endpoint DNS, flussi di autenticazione e stringhe di connessione. Coinvolgere i team client in anticipo e comunicare le modifiche, le sequenze temporali e le responsabilità imminenti.

Modifiche al traffico e al routing: Pianificare e documentare in dettaglio le modifiche al routing del traffico. Definire esattamente come aggiornare i record DNS, la configurazione del servizio di bilanciamento del carico e le regole di routing per indirizzare il traffico ad Azure. Prendere in considerazione qualsiasi valore TTL configurato perché determina la durata della propagazione delle modifiche DNS.

Molte applicazioni e script fanno riferimento a nomi di dominio completi (FQDN) per endpoint, API e servizi. Se i nomi di dominio completi cambiano in modo imprevisto durante la migrazione, le integrazioni possono interrompersi. Come parte della pianificazione del routing e del cutover, inventariare tutti i nomi di dominio completi usati dal carico di lavoro. Decidere se conservare i nomi esistenti tramite l'inoltro DNS o aggiornare le configurazioni dell'applicazione per l'uso di nuovi nomi di dominio completi di Azure. Per i servizi pubblici, pianificare attentamente il cutover DNS per ridurre al minimo i tempi di inattività e garantire una transizione senza problemi.

Esaminare il piano con gli stakeholder e riconciliare le aspettative diverse. Includere i team di gestione dei rischi e della sicurezza IT fin dall'inizio e assicurarsi che approvino il piano. Un workshop congiunto in questa fase può contribuire a ridurre al minimo i ritardi nelle fasi successive.

Dopo che gli stakeholder e i decision maker esaminano e accettano il piano e il runbook, passare alla fase di preparazione.

Output e artefatti

Al termine della fase di pianificazione, dovrebbero essere presenti gli elementi seguenti:

• Diagramma dell'architettura di destinazione
• Registri delle decisioni architetturali (ADRs)
• Budget e stime dei costi
• Runbook di migrazione e cronologia
• Approvazione degli stakeholder del piano di migrazione

Checklist

Passo successivo