Selezionare le aree di Azure per una migrazione

Articolo
04/11/2024

Quando si esegue la migrazione di un ambiente esistente ad Azure, è necessario selezionare un'area di Azure o un set di aree per ospitare i componenti migrati. La selezione dell'area prevede i passaggi generali seguenti:

Esaminare le linee guida di selezione dell'area di Azure di base per comprendere come selezionare le aree di Azure che soddisfano i requisiti.
Inventario e documentare lo stato corrente dell'ambiente.
Implementare un approccio generale alla migrazione, ad esempio se eseguire in una singola area, usare più zone di disponibilità o usare più aree.
Valutare le modifiche del processo che potrebbero essere necessarie.
Pianificare un processo di migrazione.
Ottimizzare e promuovere le modifiche dei processi.

Questo articolo fornisce indicazioni su come scegliere le aree di Azure che soddisfano le esigenze di migrazione. Se non è già stato fatto, potrebbe essere necessario estendere le aree della zona di destinazione per supportare gli approcci in più aree.

Nota

Questo articolo illustra le considerazioni specifiche per le migrazioni dei carichi di lavoro. È anche necessario comprendere i principi generali per la selezione delle aree di Azure per qualsiasi organizzazione o carico di lavoro. Per altre informazioni, vedere Selezionare le aree di Azure.

Documentare la complessità dello scenario

Determinare se lo scenario richiede la documentazione e l'allineamento dei processi. L'approccio seguente consente di valutare le potenziali sfide e di stabilire un corso generale di azione:

Si consideri un'implementazione di governance e idoneità più affidabile.
Inventario delle aree geografiche interessate. Compilare un elenco dei paesi o delle aree interessate.
Documentare la base utente. La migrazione cloud influirà su dipendenti, partner o clienti nel paese o nell'area geografica identificata?
Data center e asset dei documenti. Lo sforzo di migrazione include gli asset nel paese o nell'area geografica identificata?
Documentare i requisiti di disponibilità e failover della versione del prodotto a livello di area.
Documentare i requisiti di resilienza per determinare se sono necessarie zone di disponibilità. In genere, si considerano i requisiti di resilienza per l'intero scenario, non per le singole aree.
Documentare i requisiti di sovranità e i requisiti di residenza dei dati. I carichi di lavoro con requisiti specifici di sovranità o residenza dei dati possono influire sulla scelta delle aree di Azure.

Durante il processo di migrazione, valutare come allineare le modifiche nei vari scenari e inventari. Nella tabella seguente viene illustrato un esempio di come documentare vari scenari.

Paese	Paese/area geografica	Dipendenti locali	Utenti esterni locali	Data center o risorse locali	Requisiti di sovranità dei dati
America del Nord	Stati Uniti	Sì	Partner e clienti	Sì	No
Nord America	Canada	No	Clienti	Sì	Sì
Europa	Germania	Sì	Partner e clienti	No: nessuna rete	Sì
Asia Pacifico	Corea del Sud	Sì	Partner	Sì	No

Perché la posizione degli utenti è rilevante?

Le organizzazioni che supportano gli utenti in più paesi o aree geografiche sviluppano soluzioni tecniche che rispondono al traffico degli utenti. In alcuni casi, le soluzioni implicano la localizzazione degli asset. In altri scenari, l'organizzazione potrebbe scegliere di implementare soluzioni WAN (Wide Area Network) globali per gestire diverse basi utente tramite soluzioni incentrate sulla rete. In entrambi i casi, i profili di utilizzo di utenti diversi possono influire sulla strategia di migrazione.

Ad esempio, se un'organizzazione supporta dipendenti, partner e clienti in Germania, ma attualmente non dispone di data center in Germania, l'organizzazione implementa probabilmente una soluzione line in lease. Questo tipo di soluzione instrada il traffico ai data center in altri paesi o aree geografiche. Questo routing esistente presenta un rischio significativo per le prestazioni percepite delle applicazioni sottoposte a migrazione. L'inserimento di più hop in una rete WAN globale stabilita e ottimizzata può creare la percezione di applicazioni sottoperformi dopo la migrazione. L'individuazione e la correzione di tali problemi può comportare ritardi significativi a un progetto.

Ognuna delle sezioni seguenti include indicazioni per affrontare questa complessità tra i prerequisiti e i processi di valutazione, migrazione e ottimizzazione. Comprendere i profili utente in ogni paese o area geografica è fondamentale per gestire correttamente questa complessità.

Perché la posizione dei data center è rilevante?

La posizione dei data center esistenti può influire sulla strategia di migrazione. Prendere in considerazione i fattori seguenti:

Decisioni relative all'architettura: uno dei primi passaggi della progettazione della strategia di migrazione consiste nel determinare l'area di destinazione. La posizione degli asset esistenti spesso influisce su questa determinazione. Inoltre, la disponibilità dei servizi cloud e il costo unitario di tali servizi possono variare tra le aree. Anche i requisiti di residenza dei dati, inclusi i requisiti di sovranità, potrebbero influenzare la decisione dell'architettura. La comprensione della posizione degli asset correnti e futuri influisce sulle decisioni relative all'architettura e può influenzare le stime del budget.

Dipendenze del data center: nella tabella della sezione Documentare la complessità dello scenario, gli scenari di esempio mostrano che probabilmente è necessario pianificare le dipendenze tra vari data center globali. Le organizzazioni che operano su questa scala potrebbero non documentare o comprendere chiaramente queste dipendenze. L'approccio dell'organizzazione alla valutazione dei profili utente consente di identificare alcune di queste dipendenze nell'organizzazione. Il team deve anche esplorare altri passaggi di valutazione che consentono di attenuare i rischi e le complessità derivanti dalle dipendenze.

Implementare un approccio generale

L'approccio seguente usa un modello basato sui dati per risolvere le complessità della migrazione globale. Se l'ambito di migrazione include più aree, il team di adozione del cloud deve valutare le considerazioni di idoneità seguenti:

Determinare se è possibile soddisfare i requisiti aziendali: usare più zone di disponibilità per determinare i requisiti per disponibilità elevata, resilienza, prestazioni e costi. Se questi requisiti non sono soddisfatti, valutare se è necessario un approccio in più aree.
Valutare la sovranità dei dati: la sovranità dei dati può richiedere la localizzazione di alcuni asset, ma molti asset non sono regolati da tali vincoli di conformità. Servizi come la registrazione, la creazione di report, il routing di rete, l'identità e altri servizi IT centrali possono essere ospitati come servizi condivisi tra più sottoscrizioni o aree. Valutare la sovranità dei dati usando un modello di servizio condiviso per tali servizi. Per una descrizione di questo approccio, vedere l'architettura di riferimento per una topologia hub-spoke con servizi condivisi.
Assicurarsi che l'ambiente venga ridimensionato: se si distribuiscono più istanze di ambienti simili, è possibile stabilire un team dedicato per le migrazioni dell'ambiente per creare coerenza, migliorare la governance e accelerare la distribuzione. La guida alla governance per imprese complesse stabilisce un approccio che consente di creare un ambiente scalabile in più aree.

Prerequisiti basati sui dati

Quando il team è a proprio agio con l'approccio di base e la conformità è allineato, prendere in considerazione questi prerequisiti basati sui dati:

Individuazione generale completa: completare la tabella in Complessità dei documenti per valutare la complessità della strategia di adozione del cloud.
Analizzare i profili utente per ogni paese o area geografica interessata: è importante comprendere il routing utente generale nelle prime fasi del processo di migrazione. La modifica delle righe di lease globali e l'aggiunta di connessioni come Azure ExpressRoute a un data center cloud possono comportare mesi di ritardi di rete. Indirizzare il routing degli utenti il prima possibile nel processo.
Completare una razionalizzazione iniziale del digital estate: se si introduce complessità in una strategia di migrazione, completare una razionalizzazione iniziale del digital estate. Per altre informazioni, vedere Che cos'è un digital estate?.
Usare l'assegnazione di tag per i requisiti del digital estate: stabilire criteri di assegnazione di tag per identificare qualsiasi carico di lavoro interessato dai requisiti di sovranità dei dati. Assicurarsi che i tag necessari inizino nella razionalizzazione del digital estate e che vengano sottoposti a migrazione degli asset.
Valutare un modello hub-spoke: i sistemi distribuiti spesso condividono dipendenze comuni. È spesso possibile risolvere le dipendenze condivise implementando un modello hub-spoke. Anche se l'implementazione di un modello hub-spoke non rientra nell'ambito del processo di migrazione, contrassegnare il modello da considerare durante le iterazioni future dei processi pronti.
Classificare in ordine di priorità il backlog di migrazione: se sono necessarie modifiche di rete per supportare la distribuzione di produzione di un carico di lavoro che supporta più aree, il team di strategia del cloud deve tenere traccia e gestire le escalation risultanti dalle modifiche di rete. Questo livello superiore di supporto esecutivo consente di accelerare il cambiamento liberando il team di strategia per riscrivere il backlog e assicurarsi che le modifiche di rete non blocchino i carichi di lavoro globali. Assegnare priorità ai carichi di lavoro globali solo al termine delle modifiche di rete.

Questi prerequisiti consentono di stabilire processi che possono risolvere la complessità durante l'esecuzione della strategia di migrazione.

Modifiche del processo di valutazione

Se lo scenario di migrazione prevede complessità globali di asset e di base utente, aggiungere attività chiave per valutare i candidati alla migrazione. Queste attività producono dati che consentono di chiarire gli ostacoli e i risultati per utenti e asset globali.

Azioni suggerite durante il processo di valutazione

Valutare le dipendenze tra data center: gli strumenti di analisi delle dipendenze in Azure Migrate consentono di individuare le dipendenze. Usare questi strumenti prima di iniziare la migrazione. Se lo scenario implica complessità globale, la valutazione delle dipendenze è un passaggio necessario nel processo di valutazione. È possibile usare il raggruppamento delle dipendenze per visualizzare le dipendenze e identificare gli indirizzi IP e le porte di tutti gli asset necessari per supportare il carico di lavoro.

Importante

Per identificare gli asset che si trovano in un data center secondario, è necessario un esperto di materia (SME) che comprenda gli schemi di posizionamento degli asset e degli indirizzi IP.
Valutare le dipendenze downstream e i client nella visualizzazione per comprendere le dipendenze bidirezionali.

Identificare l'impatto dell'utente globale: l'output dell'analisi dei profili utente prerequisiti deve identificare qualsiasi carico di lavoro interessato dai profili utente globali. Se un candidato alla migrazione è nell'elenco dei carichi di lavoro interessati, l'architetto della migrazione deve consultare le PMI di rete e operazioni. Questi esperti aiutano a convalidare le aspettative di routing e prestazioni di rete. Come minimo, l'architettura deve includere una connessione ExpressRoute tra il Network Operations Center più vicino e Azure. L'architettura di riferimento per le connessioni ExpressRoute consente di configurare le connessioni di rete necessarie.

Progettazione per la conformità: l'output dell'analisi dei profili utente prerequisiti deve anche identificare qualsiasi carico di lavoro interessato dai requisiti di sovranità dei dati. Durante le attività di architettura del processo di valutazione, l'architetto assegnato deve consultare le PMI di conformità. Questi esperti possono aiutare l'architetto a comprendere i requisiti per la migrazione e la distribuzione in più aree. Tali requisiti avranno un impatto significativo sulle strategie di progettazione. Le architetture di riferimento seguenti possono essere utili per la progettazione:

Avviso

Se si usa l'architettura di riferimento per ExpressRoute o le architetture di riferimento per le applicazioni, potrebbe essere necessario escludere elementi di dati specifici dai processi di replica per soddisfare i requisiti di sovranità dei dati. L'attività di esclusione di elementi dati specifici aggiunge un passaggio al processo di promozione.

Modifiche del processo di migrazione

Se si esegue la migrazione di un'applicazione che deve essere distribuita in più aree, il team di adozione del cloud deve tenere conto di alcune altre considerazioni. La progettazione di insiemi di credenziali e di configurazione e server di elaborazione di Azure Site Recovery è una delle due considerazioni seguenti. Altre due considerazioni sono le progettazioni della larghezza di banda di rete e la sincronizzazione dei dati.

Azioni suggerite durante il processo di migrazione

Progettazione dell'insieme di credenziali di Site Recovery: Site Recovery è lo strumento consigliato per la replica nativa del cloud e la sincronizzazione degli asset digitali in Azure. Site Recovery replica i dati relativi a ogni asset in un insieme di credenziali di Site Recovery. Questo insieme di credenziali è associato a una sottoscrizione specifica in un'area specifica e in un data center di Azure. Se si replicano gli asset in una seconda area, potrebbe essere necessario anche un secondo insieme di credenziali di Site Recovery.

Configurazione e progettazione del server di elaborazione: Site Recovery funziona con un'istanza locale di un server di configurazione e di elaborazione associato a un singolo insieme di credenziali di Site Recovery. Quando si usa questa configurazione, potrebbe essere necessario installare le seconde istanze di questi server nel data center di origine per facilitare la replica.

Progettazione della larghezza di banda di rete: durante la replica e la sincronizzazione in corso, i dati binari si spostano in rete dal data center di origine all'insieme di credenziali di Site Recovery nel data center di Azure di destinazione. Il processo di replica e sincronizzazione utilizza la larghezza di banda. La duplicazione del carico di lavoro in una seconda area raddoppia la quantità di larghezza di banda utilizzata.

In alcuni scenari la larghezza di banda è limitata. In altri casi, un carico di lavoro comporta una configurazione o una deviazione sostanziale dei dati. In questi casi, la replica dei dati in una seconda area può interferire con il tempo necessario per completare la migrazione. Più importante, questi vincoli possono influire sull'esperienza degli utenti o delle applicazioni che dipendono comunque dalla larghezza di banda disponibile nel data center di origine.

Sincronizzazione dei dati: lo svuotamento della larghezza di banda più grande spesso deriva dalla sincronizzazione della piattaforma dati. Se si distribuisce in più zone di disponibilità, è possibile usare servizi dati con ridondanza della zona che sincronizzano automaticamente i dati tra più zone di disponibilità. La distribuzione in più aree richiede spesso la sincronizzazione dei dati per mantenere allineate le applicazioni. Questo approccio è definito nelle architetture di riferimento per applicazioni Web in più aree e applicazioni multi-area a più livelli.

Se la sincronizzazione delle applicazioni è lo stato operativo desiderato per le applicazioni, è possibile sincronizzare la piattaforma dati di origine con ogni piattaforma cloud. Eseguire questa sincronizzazione prima di eseguire la migrazione dell'applicazione e degli asset di livello intermedio.

Ripristino di emergenza da Azure ad Azure: un'opzione alternativa potrebbe ridurre ulteriormente la complessità. Se si usa una distribuzione in due passaggi per soddisfare le esigenze di sequenza temporale e sincronizzazione dei dati, il ripristino di emergenza da Azure ad Azure potrebbe essere una soluzione accettabile. In questo scenario si esegue la migrazione del carico di lavoro al primo data center di Azure usando un singolo insieme di credenziali di Site Recovery e la configurazione e la progettazione del server di elaborazione. Dopo aver testato il carico di lavoro, è possibile ripristinare il carico di lavoro in un secondo data center di Azure dagli asset migrati.

Questo approccio riduce l'effetto sulle risorse nel data center di origine. Il ripristino di emergenza da Azure ad Azure sfrutta anche velocità di trasferimento veloci e limiti di larghezza di banda elevati tra i data center di Azure.

Nota

L'approccio di ripristino di emergenza da Azure ad Azure può aumentare i costi di migrazione a breve termine tramite costi di larghezza di banda in uscita più elevati.

Modifiche al processo di rilascio

Quando si risolve la complessità globale durante l'ottimizzazione e la promozione, è possibile che siano necessarie attività identiche in ogni area in cui si esegue la distribuzione. Se si usa una singola area, potrebbe essere comunque necessario replicare i test aziendali e i piani di modifica aziendali.

Azioni suggerite durante il processo di rilascio

Ottimizzazione del test preliminare: i test di automazione iniziali possono identificare potenziali opportunità di ottimizzazione, come per qualsiasi operazione di migrazione. Per i carichi di lavoro globali, testare in modo indipendente il carico di lavoro in ogni area. Le modifiche di configurazione secondarie nella rete o nel data center di Azure scelto possono influire sulle prestazioni.

Piani di modifica aziendale: creare un piano di modifica aziendale per qualsiasi scenario di migrazione complesso. Un piano di cambiamento aziendale consente di garantire una comunicazione chiara sulle modifiche apportate ai processi aziendali e alle esperienze utente. Il piano consente inoltre di garantire una comunicazione chiara sui tempi di attività necessarie per integrare le modifiche. In uno sforzo di migrazione globale, il piano deve includere considerazioni per gli utenti in ogni area geografica interessata.

Test aziendali: ogni area potrebbe richiedere anche test aziendali. I test aziendali consentono di garantire prestazioni adeguate e conformità ai modelli di routing di rete modificati.

Voli promozionali: la promozione avviene spesso come singola attività e il traffico di produzione viene immediatamente reindirizzato ai carichi di lavoro migrati. In un'operazione di rilascio globale, è consigliabile offrire promozioni in raccolte predefinite di utenti chiamati voli. I voli promozionali offrono al team di strategia del cloud e al team di adozione del cloud l'opportunità di osservare le prestazioni e migliorare il supporto per gli utenti in ogni area. È possibile controllare i voli promozionali a livello di rete. In particolare, è possibile modificare il routing di intervalli IP specifici dagli asset del carico di lavoro di origine agli asset appena migrati. Dopo aver eseguito la migrazione di una raccolta di utenti specificata, è possibile reindirizzare il gruppo successivo.

Ottimizzazione dei voli: uno dei vantaggi dei voli promozionali è che offrono osservazioni più approfondite e un'opportunità per ottimizzare gli asset distribuiti. Dopo che il primo volo usa correttamente la produzione per un breve periodo di tempo, è possibile perfezionare gli asset migrati quando le procedure operative IT lo supportano.