Aree della zona di destinazione

L'architettura della zona di destinazione di Azure è indipendente dall'area. Tuttavia, viene chiesto di specificare le aree di Azure per distribuire l'architettura della zona di destinazione di Azure. Questo articolo illustra come le zone di destinazione usano le aree di Azure. Illustra anche come aggiungere un'area a una zona di destinazione esistente e alcune considerazioni quando si esegue la migrazione del patrimonio di Azure a un'area diversa.

Per altre indicazioni sulla scelta delle aree di Azure, vedere Selezionare le aree di Azure.

Come le zone di destinazione usano le aree di Azure

Le zone di destinazione di Azure sono costituite da un set di risorse e configurazione. Alcuni di questi elementi, ad esempio gruppi di gestione, criteri e assegnazioni di ruolo, vengono archiviati a livello di tenant o di gruppo di gestione all'interno dell'architettura della zona di destinazione di Azure, quindi queste risorse non vengono "distribuite" in una determinata area e vengono invece distribuite a livello globale. Tuttavia, è comunque necessario specificare un'area di distribuzione perché Azure tiene traccia di alcuni metadati delle risorse in un archivio metadati a livello di area.

Altre risorse vengono distribuite a livello di area. A seconda della configurazione della zona di destinazione, potrebbero essere presenti alcune o tutte le risorse distribuite a livello di area seguenti:

• Area di lavoro Log Analytics (incluse le soluzioni selezionate)
• Account di Automazione
• Gruppi di risorse (per le altre risorse)

Se si distribuisce una topologia di rete, è anche necessario selezionare un'area di Azure in cui distribuire le risorse di rete. Questa area può essere diversa dall'area usata per le risorse elencate nell'elenco precedente. A seconda della topologia selezionata, le risorse di rete distribuite possono includere:

• Rete WAN virtuale di Azure (ad esempio hub di rete WAN virtuale)
• Reti virtuali di Azure
• gateway VPN
• Gateway ExpressRoute
• Firewall di Azure
• Piani di protezione DDoS di Azure
• Zone DNS privato di Azure, tra cui per collegamento privato di Azure
• Gruppi di risorse, per contenere le risorse elencate in precedenza

Nota

Per ridurre al minimo l'effetto delle interruzioni a livello di area, è consigliabile inserire le risorse nella stessa area del gruppo di risorse. Per altre informazioni, vedere Allineamento della posizione del gruppo di risorse.

Aggiungere una nuova area a una zona di destinazione esistente

È consigliabile prendere in considerazione una strategia in più aree, dall'inizio del percorso cloud o espandendosi in più aree di Azure dopo aver completato la distribuzione iniziale dell'architettura della zona di destinazione di Azure. Se ad esempio si abilita il ripristino di emergenza per le macchine virtuali tramite Azure Site Recovery, è possibile replicarle in un'area di Azure diversa. Per aggiungere aree di Azure all'interno dell'architettura della zona di destinazione di Azure, prendere in considerazione le aree e le raccomandazioni seguenti:

Area	Elemento consigliato
Gruppi di gestione	Nessuna azione necessaria. I gruppi di gestione non sono associati a un'area e non è consigliabile creare una struttura del gruppo di gestione in base alle aree.
Sottoscrizioni	Le sottoscrizioni non sono associate a un'area.
Criteri di Azure	Apportare modifiche qui se sono stati assegnati criteri per negare la distribuzione delle risorse in tutte le aree specificando un elenco di aree di Azure "consentite". Tali assegnazioni devono essere aggiornate per consentire le distribuzioni di risorse nella nuova area da abilitare.
Controllo degli accessi in base al ruolo	Nessuna azione necessaria. Il controllo degli accessi in base al ruolo di Azure non è associato ad alcuna area.
Monitoraggio e registrazione	Decidere se usare una singola area di lavoro Log Analytics per tutte le aree o creare più aree di lavoro per coprire aree geografiche diverse. Esistono vantaggi e svantaggi di ogni approccio, inclusi i potenziali addebiti di rete tra aree. Per altre informazioni, vedere Progettare un'architettura dell'area di lavoro Log Analytics.
Rete	Se è stato distribuito un hub-spoke tradizionale, una topologia di rete oppure una rete WAN virtuale, espandere la rete nella nuova area di Azure. Creare un altro hub di rete distribuendo le risorse di rete necessarie nella sottoscrizione di connettività esistente nella nuova area di Azure. Azure Rete virtuale Manager può semplificare l'espansione e la gestione delle reti virtuali su larga scala in più aree. Dal punto di vista del DNS, è anche possibile distribuire i server d'inoltro, se usati, nella nuova area di Azure. Usare i server d'inoltro per le reti virtuali spoke nella nuova area per la risoluzione. Le zone DNS di Azure sono risorse globali e non associate a una singola area di Azure, quindi non è necessario eseguire alcuna operazione.
Identità	Se sono stati distribuiti Dominio di Active Directory Services o Microsoft Entra Domain Services nella sottoscrizione/spoke delle identità, espandere il servizio nella nuova area di Azure.

Nota

È anche consigliabile usare le zone di disponibilità per la disponibilità elevata all'interno di un'area. Controllare se le zone di disponibilità sono supportate nelle aree scelte e per i servizi da usare.

Microsoft Cloud for Sovranità include linee guida per limitare i servizi e le aree geografiche. È possibile usare queste linee guida per applicare la configurazione del servizio per aiutare i clienti a soddisfare le esigenze di residenza dei dati.

Approccio generale

Quando si espande una zona di destinazione di Azure in una nuova area, prendere in considerazione la procedura descritta in queste sezioni. Prima di iniziare, è necessario decidere in una nuova area di Azure o in più aree di Azure per espandersi.

Rete

Architettura hub &spoke tradizionale

Suggerimento

Esaminare l'area di progettazione della zona di destinazione di Azure per l'architettura hub-spoke tradizionale.

1. Decidere se è necessaria una nuova sottoscrizione della zona di destinazione della piattaforma. È consigliabile che la maggior parte dei clienti usi le sottoscrizioni di Connessione ivity esistenti, anche quando usano più aree.
2. All'interno della sottoscrizione creare un nuovo gruppo di risorse nella nuova area di destinazione.
3. Creare una nuova rete virtuale hub nella nuova area di destinazione.
4. Se applicabile, distribuire Firewall di Azure o appliance virtuali di rete nella nuova rete virtuale hub.
5. Se applicabile, distribuire i gateway di rete virtuale per la connettività VPN e/o ExpressRoute e stabilire connessioni. Assicurarsi che i circuiti ExpressRoute e le posizioni locali seguano le raccomandazioni sulla resilienza di Microsoft. Per altre informazioni, vedere Progettazione per il ripristino di emergenza con il peering privato di ExpressRoute.
6. Stabilire il peering di rete virtuale tra la nuova rete virtuale hub e le altre reti virtuali hub.
7. Creare e configurare qualsiasi routing necessario, ad esempio il server di route di Azure o le route definite dall'utente.
8. Se necessario, abilitare la risoluzione dei nomi distribuendo server d'inoltro DNS per la nuova area di destinazione e collegando eventuali zone DNS private.
   • Alcuni clienti potrebbero configurare la risoluzione dei nomi nei controller di dominio Active Directory all'interno della sottoscrizione della zona di destinazione di Identity Platform.

Per ospitare i carichi di lavoro, è quindi possibile connettere gli spoke della zona di destinazione dell'applicazione alla nuova rete virtuale hub nella nuova area usando il peering di rete virtuale.

Suggerimento

Azure Rete virtuale Manager può semplificare l'espansione e la gestione delle reti virtuali su larga scala in più aree.

Architettura della rete WAN virtuale

Suggerimento

Esaminare l'area di progettazione della zona di destinazione di Azure per rete WAN virtuale architettura.

1. Nella rete WAN virtuale esistente creare un nuovo hub virtuale nella nuova area di destinazione.
2. Distribuire Firewall di Azure o altre appliance virtuali di rete supportate nel nuovo hub virtuale. Configurare i criteri di routing e finalità di routing di Azure rete WAN virtuale per instradare il traffico attraverso il nuovo hub virtuale protetto.
3. Se applicabile, distribuire i gateway di rete virtuale per la connettività VPN e/o ExpressRoute nel nuovo hub virtuale e stabilire connessioni. Assicurarsi che i circuiti ExpressRoute e le posizioni locali seguano le raccomandazioni sulla resilienza di Microsoft. Per altre informazioni, vedere Progettazione per il ripristino di emergenza con il peering privato di ExpressRoute.
4. Se applicabile, creare e configurare qualsiasi altro routing necessario, ad esempio le route statiche dell'hub virtuale.
5. Se applicabile, distribuire server d'inoltro DNS per la nuova area di destinazione e collegarsi a qualsiasi zona DNS privata per abilitare la risoluzione.
   • Alcuni clienti potrebbero configurare la risoluzione dei nomi nei controller di dominio Active Directory all'interno della sottoscrizione della zona di destinazione di Identity Platform.
   • Nelle distribuzioni rete WAN virtuale deve trovarsi in una rete virtuale spoke connessa all'hub virtuale tramite una connessione di rete virtuale, seguendo il modello di estensione dell'hub virtuale.

Per ospitare i carichi di lavoro, è quindi possibile connettere gli spoke della zona di destinazione dell'applicazione al nuovo hub virtuale della rete WAN virtuale nella nuova area usando le connessioni di rete virtuale.

Identità

Suggerimento

Esaminare l'area di progettazione della zona di destinazione di Azure per la gestione delle identità e degli accessi.

1. Decidere se è necessaria una nuova sottoscrizione della zona di destinazione della piattaforma. È consigliabile che la maggior parte dei clienti usi la sottoscrizione identity esistente, anche quando usano più aree.
2. Creare un nuovo gruppo di risorse nella nuova area di destinazione.
3. Creare una nuova rete virtuale nella nuova area di destinazione.
4. Stabilire il peering di rete virtuale alla rete virtuale dell'hub di area appena creata nella sottoscrizione Connessione ivity.
5. Distribuire carichi di lavoro di identità, ad esempio macchine virtuali del controller di dominio Active Directory, nella nuova rete virtuale.
   • Potrebbe essere necessario eseguire una configurazione maggiore dei carichi di lavoro dopo il provisioning, ad esempio i passaggi di configurazione seguenti:
     • Alzare di livello le macchine virtuali del controller di dominio Active Directory al dominio Active Directory esistente.
     • Creare nuovi siti e subnet di Active Directory.
     • Configurare le impostazioni del server DNS come server d'inoltro condizionale.

Spostare la proprietà di Azure in una nuova area

In alcuni casi, potrebbe essere necessario spostare l'intero patrimonio di Azure in un'area diversa. Si supponga, ad esempio, di aver distribuito la zona di destinazione e i carichi di lavoro in un'area di Azure in un paese/area geografica vicina e quindi si avvii una nuova area di Azure nel paese/area geografica di origine. È possibile scegliere di spostare tutti i carichi di lavoro nella nuova area per migliorare la latenza di comunicazione o per rispettare i requisiti di residenza dei dati.

Nota

Questo documento fornisce solo informazioni sulla migrazione dei componenti della zona di destinazione dell'ambiente. Per altre informazioni sulla rilocazione dei componenti del carico di lavoro, vedere Rilocare i carichi di lavoro cloud.

Configurazione della zona di destinazione globale

La maggior parte della configurazione della zona di destinazione distribuita a livello globale non deve in genere essere modificata quando si spostano le aree. Tuttavia, assicurarsi di verificare la presenza di eventuali assegnazioni di criteri che limitano le distribuzioni dell'area e aggiornano i criteri per consentire le distribuzioni nella nuova area.

Risorse della zona di destinazione a livello di area

Le risorse della zona di destinazione specifiche dell'area spesso richiedono una maggiore considerazione perché alcune risorse di Azure non possono essere spostate tra aree. Si consideri l'approccio seguente:

1. Aggiungere l'area di destinazione come area aggiuntiva alla zona di destinazione. Seguire le indicazioni in Aggiungere una nuova area a una zona di destinazione esistente.
2. Distribuire componenti centralizzati nell'area di destinazione. Ad esempio, distribuire una nuova area di lavoro Log Analytics nell'area di destinazione in modo che i carichi di lavoro possano iniziare a usare il nuovo componente quando viene eseguita la migrazione.
3. Eseguire la migrazione dei carichi di lavoro dall'area di origine all'area di destinazione. Durante il processo di migrazione del carico di lavoro, riconfigurare le risorse in modo da usare i componenti di rete dell'area di destinazione, i componenti di identità, l'area di lavoro Log Analytics e altre risorse a livello di area.
4. Rimuovere le risorse nell'area di origine al termine della migrazione.

Quando si esegue la migrazione delle risorse della zona di destinazione tra aree, prendere in considerazione i suggerimenti seguenti:

• Usare l'infrastruttura come codice: la configurazione complessa, ad esempio le regole per Firewall di Azure, può essere esportata e reimportata usando Bicep, modelli arm, Terraform, scripting o un approccio simile.
• Automazione di Azure: Automazione di Azure fornisce indicazioni e script per facilitare la migrazione tra più regioni delle risorse di Automazione di Azure.
• ExpressRoute: valutare se è possibile usare ExpressRoute Local nell'area di destinazione. Se gli ambienti locali si trovano nella stessa area metropolitana dell'area di Azure, ExpressRoute Local può offrire un'opzione a costo inferiore rispetto ad altri SKU di ExpressRoute.

Passaggi successivi

Migliorare la governance della zona di destinazione