Guida alla decisione sulle aree di Azure

  • Articolo

Quando si progetta la strategia di migrazione ad Azure, è possibile scegliere tra molte aree di Azure in tutto il mondo. Ogni area di Azure presenta caratteristiche specifiche che rendono essenziale la scelta dell'area corretta per le risorse di Azure. Le considerazioni includono servizi, capacità, vincoli e sovranità disponibili:

  • Servizi disponibili: i servizi di Azure che è possibile distribuire in ogni area variano a seconda dei diversi fattori. Selezionare un'area per il servizio necessario per il carico di lavoro. Per altre informazioni, vedere Prodotti disponibili in base all'area.
  • Capacità: ogni area ha una capacità massima. La capacità massima di un'area può influire sui tipi di sottoscrizioni che possono distribuire i tipi di servizi e in quali circostanze. La capacità a livello di area è diversa da una quota di sottoscrizione. Se si pianifica una migrazione di data center su larga scala ad Azure, è possibile consultare il team del campo di Azure locale o il responsabile account di Azure per verificare che sia possibile eseguire la distribuzione su larga scala.
  • Vincoli: determinati vincoli vengono inseriti nella distribuzione dei servizi in determinate aree. Ad esempio, alcune aree sono disponibili solo per il backup o il failover. Altri vincoli importanti da considerare sono i requisiti di sovranità dei dati.
  • Sovranità: alcune aree sono dedicate a entità sovrane specifiche. Anche se tutte le aree sono aree di Azure, queste aree sovrane sono isolate dal resto di Azure. Non sono necessariamente gestiti da Microsoft e potrebbero essere limitati a determinati tipi di clienti. Queste aree sovrane sono:

Organizzazioni operanti in più aree geografiche

Un'organizzazione può operare in più aree geografiche per ottenere resilienza essenziale per le operazioni. La presenza di operazioni in più aree geografiche introduce una potenziale complessità nei formati seguenti:

  • Distribuzione degli asset
  • Profili di accesso utente
  • Requisiti di conformità
  • Resilienza a livello di area

La selezione dell'area è una parte fondamentale della strategia complessiva di adozione del cloud. Iniziare con le considerazioni sulla rete.

Considerazioni per la rete

Qualsiasi distribuzione cloud affidabile richiede una rete ben considerata che tenga conto delle differenze nelle aree di Azure. È consigliabile tenere conto dei fattori seguenti:

  • Le aree di Azure vengono distribuite in coppie. Ogni area è associata a un'altra area nello stesso limite geopolitico per garantire la resilienza se si verifica un errore irreversibile dell'area. Un'eccezione è Brazil South, associata a South Central US.

    Prendere in considerazione la distribuzione in aree abbinate come strategia di resilienza primaria e secondaria. Ecco altre informazioni da considerare:

    • Archiviazione di Azure supporta l'archiviazione con ridondanza geografica (GRS). Nell'archiviazione con ridondanza geografica di Archiviazione di Azure vengono archiviate tre copie dei dati nell'area primaria e altre tre copie vengono archiviate nell'area abbinata. Non è possibile cambiare l'abbinamento dell'archiviazione per gli scenari GRS.
    • I servizi basati su archiviazione di Azure con ridondanza geografica possono trarre vantaggio dalle aree abbinate. Le applicazioni e la rete devono essere configurate per supportare le aree abbinate.
    • Se non si prevede di sfruttare l'archiviazione con ridondanza geografica per soddisfare esigenze di resilienza locale, non si deve usare l'area abbinata come area secondaria. Se si verifica un errore a livello di area, viene eseguita una pressione intensa sulle risorse nell'area abbinata durante la migrazione delle risorse. È possibile evitare tale pressione recuperando in un sito alternativo e aumentando la velocità durante il ripristino.

    Avviso

    Non tentare di usare l'archiviazione con ridondanza geografica di Archiviazione di Azure per i backup o il ripristino delle macchine virtuali. Usare invece Backup di Azure, Azure Site Recovery e i dischi gestiti di Azure per supportare la resilienza per il carico di lavoro IaaS (Infrastructure as a Service).

    Per altre informazioni, vedere Aree abbinate di Azure.

  • Backup di Azure e Azure Site Recovery, unitamente all'architettura di rete, semplificano la resilienza a livello di area per le esigenze di backup dei dati e dell'infrastruttura IaaS. Assicurarsi che la rete sia ottimizzata, in modo che i trasferimenti di dati rimangano nel backbone Microsoft e usino il peering di rete virtuale, se possibile. Alcune organizzazioni di grandi dimensioni che dispongono di distribuzioni globali potrebbero invece usare Azure ExpressRoute Premium per instradare il traffico tra aree e potenzialmente risparmiare addebiti in uscita a livello di area.

  • I gruppi di risorse di Azure sono specifici delle aree di Azure. Tuttavia , le risorse in un gruppo di risorse spesso si estendono su più aree. In un errore a livello di area le operazioni del piano di controllo su un gruppo di risorse hanno esito negativo nell'area interessata, ma le risorse in altre aree del gruppo di risorse continuano a funzionare. La resilienza del gruppo di risorse in base all'area potrebbe influire sulla progettazione della rete e del gruppo di risorse.

  • Molti servizi PaaS (Platform as a Service) in supporto tecnico di Azure endpoint di servizio o collegamento privato di Azure. Entrambe queste soluzioni possono influire in modo significativo sulla progettazione della rete quando si considera la resilienza, la migrazione e la governance a livello di area.

  • Molti servizi PaaS si basano su specifiche soluzioni di resilienza a livello di area. Ad esempio, nelle distribuzioni per Azure SQL Database e Azure Cosmos DB è possibile eseguire facilmente la replica in più aree. Alcuni servizi di Azure, ad esempio DNS di Azure, non hanno dipendenze a livello di area. Quando si considerano i servizi che verranno usati nel processo di adozione del cloud, assicurarsi di comprendere chiaramente le funzionalità di failover e i passaggi di ripristino che potrebbero essere necessari per ogni servizio di Azure usato.

  • Oltre alla distribuzione in più aree per supportare il ripristino di emergenza, molte organizzazioni scelgono di eseguire la distribuzione in un modello attivo-attivo per evitare di basarsi sul failover. I vantaggi dell'uso di un modello attivo-attivo includono bilanciamento del carico globale, tolleranza di errore maggiore e incrementi delle prestazioni di rete. Per sfruttare questo modello, le applicazioni devono supportare l'esecuzione attiva-attiva in più aree.

Avviso

Le aree di Azure sono costrutti a disponibilità elevata. I contratti di servizio di Azure vengono applicati ai servizi in esecuzione in aree specifiche. Non è mai consigliabile eseguire la distribuzione con una dipendenza a singola area da applicazioni cruciali. Pianificare sempre le procedure di ripristino e mitigazione in caso di errori a livello di area.

Documentare la complessità dello scenario

Dopo aver considerato la topologia di rete, determinare se è necessaria una maggiore documentazione e l'allineamento dei processi. L'approccio seguente consente di valutare le potenziali sfide e di stabilire un corso generale di azione:

  • Prendere in considerazione una più solida preparazione e attuazione della governance.
  • Rilevare le aree geografiche interessate. Compilare un elenco dei paesi o delle aree geografiche interessate.
  • Documentare i requisiti di sovranità dei dati. I paesi o le aree geografiche identificate hanno requisiti di conformità che regolano la sovranità dei dati?
  • Documentare la base utenti. I dipendenti, i partner o i clienti nel paese/area geografica identificati saranno interessati dalla migrazione cloud?
  • Documentare i data center e gli asset. Sono presenti asset nel paese o nell'area geografica identificata che potrebbero essere inclusi nel lavoro di migrazione?
  • Documentare la disponibilità di SKU a livello di area e i requisiti di failover.

Allineare le modifiche durante il processo di migrazione per risolvere l'inventario iniziale. La tabella seguente illustra scenari di esempio che consentono di documentare i risultati:

Region Paese 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
America del Nord Canada No Clienti Sì Sì
Europa Germania Sì Partner e clienti No: nessuna rete Sì
Asia Pacifico Corea del Sud Sì Partner Sì No

Conoscere i requisiti di sovranità dei dati

In tutto il mondo, le organizzazioni governative hanno iniziato a stabilire la sovranità dei dati e le normative sulla privacy dei dati. Questi tipi di requisiti di conformità richiedono spesso la localizzazione in un paese o in un'area geografica specifica per proteggere i cittadini in tale posizione. In alcuni casi, i dati relativi ai clienti, ai dipendenti o ai partner devono essere archiviati in una piattaforma cloud nella stessa area dell'utente.

Affrontare questa sfida è stata una motivazione significativa per le migrazioni cloud per le organizzazioni che operano su scala globale. Per mantenere la conformità alla sovranità dei dati, alcune organizzazioni hanno scelto di distribuire asset IT duplicati nei provider di servizi cloud nell'area. Nella tabella precedente lo scenario tedesco è un buon esempio. Lo scenario include i clienti, i partner e i dipendenti, ma non gli attuali assensi IT in Germania. Questa organizzazione potrebbe scegliere di distribuire alcuni asset in un data center all'interno di un'area di regolamento sulla sovranità dei dati, potenzialmente usando i data center di Azure tedeschi. Una comprensione dei dati interessati dalle normative sulla sovranità dei dati regionali aiuta il team di adozione del cloud a comprendere l'approccio di migrazione migliore per l'organizzazione.

Perché la posizione degli utenti è rilevante?

Le organizzazioni che supportano gli utenti in più paesi/aree geografiche hanno sviluppato soluzioni tecniche che indirizzano il traffico utente. In alcuni casi, le soluzioni comportano la localizzazione degli asset. In altri scenari, l'organizzazione potrebbe scegliere di implementare soluzioni WAN (Wide Area Network) globali per affrontare le diverse basi utente tramite soluzioni incentrate sulla rete. In entrambi i casi, la strategia di migrazione potrebbe essere influenzata dai profili di utilizzo di utenti diversi.

Se un'organizzazione supporta dipendenti, partner e clienti in Germania senza avere attualmente data center in Germania, l'organizzazione probabilmente ha implementato una soluzione line in lease. Questo tipo di soluzione indirizza il traffico ai data center in altri paesi/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 delle applicazioni sottoperforming dopo la migrazione. L'individuazione e la correzione di tali problemi può comportare ritardi significativi a un progetto.

In ognuno dei processi seguenti, le linee guida per risolvere questa complessità sono incluse tra prerequisiti e processi di valutazione, migrazione e ottimizzazione. Comprendere i profili utente in ogni paese/area geografica è fondamentale per gestire correttamente questa complessità.

Perché la posizione dei data center è rilevante?

La posizione dei data center esistenti potrebbe influire su una strategia di migrazione. Prendere in considerazione i seguenti fattori:

Decisioni di architettura: determinare l'area di destinazione è uno dei primi passaggi della progettazione della strategia di migrazione. Questa determinazione spesso è influenzata dalla posizione degli asset esistenti. Inoltre, la disponibilità dei servizi cloud e il costo unitario di tali servizi potrebbe variare tra aree. Comprendere dove si trovano gli asset correnti e futuri influisce sulle decisioni sull'architettura e potrebbe influire sulle stime del budget.

Dipendenze del data center: gli scenari di esempio nella tabella in Complessità documento mostrano che probabilmente è necessario pianificare le dipendenze tra vari data center globali. Le dipendenze potrebbero non essere documentate o comprese chiaramente in molte organizzazioni che operano su questa scala. L'approccio dell'organizzazione alla valutazione dei profili utente consente di identificare alcune di queste dipendenze nell'organizzazione. Il team deve anche esplorare più 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 affrontare le complessità della migrazione globale. Quando l'ambito di una migrazione include più aree, il team di adozione del cloud deve tenere conto delle considerazioni seguenti sulla conformità:

  • La sovranità dei dati potrebbe richiedere la localizzazione di alcuni asset, ma molti altri potrebbero non essere regolamentati da tali vincoli di conformità. Gli elementi 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 più aree. Il team di adozione del cloud deve valutare la sovranità dei dati usando un modello di servizio condiviso per tali servizi, come descritto nell'architettura di riferimento per una topologia hub-spoke con servizi condivisi.
  • Quando si distribuiscono più istanze di ambienti simili, l'uso di una factory di ambiente può aiutare a 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 è confortevole con l'approccio di base e l'idoneità è allineato, prendere in considerazione alcuni prerequisiti basati sui dati:

  • Individuazione generale completa: completare la tabella in Complessità documento per valutare la complessità della strategia di adozione del cloud.
  • Analizzare i profili utente in ogni paese/area geografica interessato: è importante comprendere il routing utente generale all'inizio del processo di migrazione. La modifica delle linee di lease globali e l'aggiunta di connessioni come ExpressRoute a un data center cloud può comportare mesi di ritardi di rete. Indirizzare il routing utente all'inizio del processo il più possibile.
  • Completare una razionalizzazione iniziale del digital estate: quando la complessità viene introdotta in una strategia di migrazione, è necessario 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 dei tag per identificare qualsiasi carico di lavoro interessato dai requisiti di sovranità dei dati. I tag obbligatori devono iniziare nella razionalizzazione del digital estate e portare avanti per eseguire la migrazione degli asset.
  • Valutare un modello hub-spoke: i sistemi distribuiti condividono spesso dipendenze comuni. Spesso è possibile risolvere le dipendenze condivise implementando un modello hub-spoke. Sebbene l'implementazione di un modello hub-spoke sia fuori ambito per il processo di migrazione, contrassegnare il modello da considerare durante le iterazioni future dei processi pronti.
  • Priorità del backlog della migrazione: quando le modifiche di rete sono necessarie per supportare la distribuzione di produzione di un carico di lavoro che supporta più aree, il team della strategia cloud deve tenere traccia e gestire le escalation risultanti dalle modifiche alla rete. Il livello superiore di supporto esecutivo consente di accelerare il cambiamento liberando il team di strategia per riscrivere il backlog e assicurarsi che i carichi di lavoro globali non siano bloccati dalle modifiche di rete. 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

Quando l'organizzazione affronta le complessità di asset globali e di base degli utenti in uno scenario di migrazione, è necessario aggiungere alcune attività chiave per valutare i candidati alla migrazione. Queste attività producono dati utili a chiarire ostacoli e risultati per gli utenti e gli asset globali.

Azione suggerita durante il processo di valutazione

Valutare le dipendenze tra data center: gli strumenti di visualizzazione delle dipendenze in Azure Migrate consentono di individuare le dipendenze. Una procedura consigliata consiste nell'usare questi strumenti prima di iniziare la migrazione. Quando la complessità globale è coinvolta, diventa un passaggio necessario nel processo di valutazione. Tramite il raggruppamento delle dipendenze, la visualizzazione delle dipendenze consente di identificare gli indirizzi IP e le porte di tutti gli asset necessari per supportare il carico di lavoro.

Importante

  • Un esperto di materia che ha una conoscenza del posizionamento degli asset e degli schemi di indirizzi IP è necessario per identificare gli asset che si trovano in un data center secondario.
  • Per riconoscere le dipendenze bidirezionali è necessario valutare i client e le dipendenze downstream.

Identificare l'impatto dell'utente globale: gli output dall'analisi del profilo utente prerequisito devono identificare qualsiasi carico di lavoro interessato dai profili utente globali. Quando un candidato alla migrazione si trova nell'elenco dei carichi di lavoro interessati, l'architetto di migrazione deve consultare gli esperti del settore delle operazioni e delle reti. Questi esperti consentono di convalidare il routing di rete e le aspettative sulle prestazioni. 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à: gli output dall'analisi del profilo utente prerequisito devono 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 gli esperti in materia di conformità. Questi esperti possono aiutare l'architetto a comprendere eventuali requisiti per la migrazione e la distribuzione in più aree. Tali requisiti avranno un impatto significativo sulle strategie di progettazione. Le architetture di riferimento per le applicazioni Web multiregion e le applicazioni multiregion a più livelli possono essere utili per la progettazione.

Avviso

Quando 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 nel processo di promozione.

Modifiche del processo di migrazione

Quando 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 considerazioni. Le considerazioni sono costituite dalla progettazione, dalla progettazione, dalla configurazione e dal server di elaborazione di Azure Site Recovery, dalle progettazioni della larghezza di banda di rete e dalla sincronizzazione dei dati.

Azione suggerita durante il processo di migrazione

Progettazione dell'insieme di credenziali di Azure Site Recovery: Azure 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 alla risorsa in un insieme di credenziali di Site Recovery associato a una sottoscrizione specifica in un'area specifica e in un data center di Azure. Quando si esegue la replica di asset in una seconda area, potrebbe essere necessario anche un secondo insieme di credenziali di Site Recovery.

Progettazione del server di configurazione e elaborazione: Site Recovery funziona con un'istanza locale di una configurazione e un server di elaborazione, associato a un singolo insieme di credenziali di Site Recovery. La configurazione significa che potrebbe essere necessario installare una seconda istanza 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, si spostano i dati binari in rete, dal data center di origine al Site Recovery insieme di credenziali 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. Se la larghezza di banda è limitata o se un carico di lavoro comporta una configurazione o una deriva sostanziale dei dati, la replica dei dati in una seconda area potrebbe interferire con il tempo necessario per completare la migrazione. In particolare, questi vincoli potrebbero influire sull'esperienza degli utenti o delle applicazioni che dipendono ancora dalla larghezza di banda disponibile nel data center di origine.

Sincronizzazione dei dati: spesso il più grande svuotamento della larghezza di banda deriva dalla sincronizzazione della piattaforma dati. Come definito nelle architetture di riferimento per applicazioni Web multiregion e applicazioni multiregione a più livelli, la sincronizzazione dei dati spesso è necessaria per mantenere allineate le applicazioni. Se la sincronizzazione delle applicazioni è lo stato operativo desiderato per le applicazioni, è possibile sincronizzare la piattaforma dati di origine con ogni piattaforma cloud. È necessario eseguire questa operazione prima di eseguire la migrazione delle risorse dell'applicazione e del livello intermedio.

Ripristino di emergenza da Azure ad Azure: un'opzione alternativa potrebbe ridurre ulteriormente la complessità. Se le sequenze temporali e la sincronizzazione dei dati indicano che potrebbe essere necessario eseguire una distribuzione in due passaggi, il ripristino di emergenza da Azure ad Azure potrebbe essere una soluzione accettabile. Nello scenario si esegue la migrazione del carico di lavoro al primo data center di Azure usando un singolo insieme di credenziali Site Recovery e la configurazione o 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. L'approccio riduce l'effetto sulle risorse nel data center di origine e sfrutta velocità di trasferimento più veloci e limiti di larghezza di banda elevati tra i data center di Azure.

Nota

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

Modifiche dei processi di ottimizzazione e promozione

Quando si risolve la complessità globale durante l'ottimizzazione e la promozione, potrebbe essere necessario eseguire attività identiche in ognuna delle altre aree. Quando una singola distribuzione è accettabile, potrebbe essere comunque necessario replicare i test aziendali e i piani di modifica aziendali.

Azione suggerita durante il processo di ottimizzazione e promozione

Ottimizzazione pretesto: i test iniziali di automazione possono identificare le potenziali opportunità di ottimizzazione, come per qualsiasi sforzo 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 potrebbero influire sulle prestazioni.

Piani di modifica aziendale: per qualsiasi scenario di migrazione complesso, creare un piano di modifica aziendale. L'uso di un piano di modifica aziendale consente di garantire una comunicazione chiara sulle modifiche apportate ai processi aziendali e alle esperienze utente e sui tempi necessari per integrare le modifiche. In un'operazione di migrazione globale, il piano deve includere considerazioni per gli utenti in ogni area geografica interessata.

Test aziendali: oltre a un piano di modifica aziendale, i test aziendali potrebbero essere necessari in ogni area. I test aziendali in ogni area consentono di garantire prestazioni adeguate e conformità ai modelli di routing di rete modificati.

Voli promozionali: spesso, la promozione avviene 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 anteprima, che sono raccolte predefinite di utenti. L'uso dei voli promozionali offre 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. I voli promozionali vengono spesso controllati a livello di rete modificando il routing di intervalli IP specifici dagli asset del carico di lavoro di origine agli asset di cui è stata appena eseguita la migrazione. Dopo la migrazione di una raccolta specificata di utenti, è possibile reindirizzare il gruppo successivo.

Ottimizzazione dei voli: uno dei vantaggi dell'uso dei voli promozionali è che si hanno 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.