Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo illustra come le zone di destinazione usano le aree di Azure. L'architettura della zona di destinazione di Azure è indipendente dall'area, ma è necessario specificare le aree di Azure per distribuire l'architettura della zona di destinazione di Azure. Le indicazioni seguenti descrivono come aggiungere un'area a una zona di destinazione esistente e fornisce anche considerazioni per la migrazione dell'ambiente Azure a un'area diversa.
In alcune situazioni, è consigliabile distribuire applicazioni in più aree di Azure per supportare i requisiti aziendali di disponibilità elevata e ripristino di emergenza. Potrebbe non essere necessario disporre di un'immediata necessità di applicazioni in più aree, ma è consigliabile progettare la piattaforma della zona di destinazione di Azure per supportare più aree, in particolare per la connettività, l'identità e i servizi di gestione. Assicurarsi di poter abilitare e supportare rapidamente le zone di destinazione delle applicazioni in più aree.
Per altre informazioni, vedere Selezionare le aree di Azure.
Zone di destinazione e 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. Queste risorse non vengono distribuite in un'area specifica 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:
- Un'area di lavoro di Azure Monitor Logs, incluse le soluzioni selezionate
- Un account di Automazione di Azure
- 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:
- Azure Virtual WAN, incluso un hub di rete Virtual WAN
- Reti virtuali di Azure
- gateway VPN
- Gateway di Azure ExpressRoute
- Firewall di Azure
- Piani di protezione DDoS di Azure
- Zone DNS private di Azure, incluse le zone per collegamento privato di Azure
- Gruppi di risorse, per contenere le risorse precedenti
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. Ad esempio, se si usa Azure Site Recovery per abilitare il ripristino di emergenza per le macchine virtuali, è possibile replicarli 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 raccomandazioni seguenti:
| Area | Raccomandazione |
|---|---|
| Gruppi di gestione | Nessuna azione necessaria. I gruppi di gestione non sono associati ad alcuna area. 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 in Criteri di Azure se sono stati assegnati criteri per negare la distribuzione delle risorse a tutte le aree specificando un elenco di aree di Azure "consentite". Aggiornare queste assegnazioni per consentire le distribuzioni di risorse nella nuova area da abilitare. |
| Controllo degli accessi in base al ruolo | Nessuna azione necessaria. Il RBAC di Azure non è legato a una specifica regione. |
| Monitoraggio e registrazione | Decidere se usare una singola area di lavoro di Monitoraggio dei log di Azure per tutte le regioni o creare più aree di lavoro per coprire varie regioni geografiche. Ogni approccio presenta vantaggi e svantaggi, inclusi i potenziali addebiti per la rete tra aree. Per altre informazioni, vedere Progettare l’architettura di un’area di lavoro Log Analytics. |
| Rete | Se distribuisci una topologia di rete, rete WAN virtuale o hub e spoke tradizionale, espandi 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 DNS (Domain Name System), potresti anche voler distribuire server di inoltro, se li utilizzi, nella nuova regione 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 richiedono alcuna azione. |
| Identità | Se hai distribuito Servizi di dominio Active Directory o Microsoft Entra Domain Services nella sottoscrizione di identità o spoke, espandi 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 aree di Azure supportano le zone di disponibilità e il modo in cui i servizi usati supportano le zone di disponibilità.
Microsoft Cloud for Sovranità ha delle linee guida per la restrizione dei servizi e delle 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 di alto livello
Quando si espande una zona di atterraggio di Azure in una nuova area, considerare di seguire i passaggi descritti in queste sezioni. Prima di iniziare, è necessario decidere in una nuova area di Azure o in più aree di Azure per espandersi.
Rete
Un'architettura del tipo hub-and-spoke tradizionale
Decidere se è necessaria una nuova sottoscrizione della zona di destinazione della piattaforma. È consigliabile che la maggior parte dei clienti usi le sottoscrizioni di connettività esistenti, anche quando usano più aree.
All'interno della sottoscrizione creare un nuovo gruppo di risorse nella nuova area di destinazione.
Creare una nuova rete virtuale hub nella nuova area di destinazione.
Se applicabile, distribuisci Azure Firewall o appliance virtuali di rete nella tua nuova rete virtuale hub.
Se applicabile, distribuire i gateway di rete virtuale per la connettività VPN o ExpressRoute e stabilire connessioni. Assicurarsi che i circuiti ExpressRoute e le posizioni locali seguano le raccomandazioni sulla resilienza Microsoft. Per ulteriori informazioni, vedere Progettazione del ripristino di emergenza tramite il peering privato di ExpressRoute.
Configurare il peering di rete virtuale tra la nuova rete virtuale hub e le altre reti hub virtuali.
Creare e configurare qualsiasi routing necessario, ad esempio il server di route di Azure o le route definite dall'utente.
Se necessario, distribuire server d'inoltro DNS per la nuova area di destinazione e collegarsi a eventuali zone DNS private per abilitare la risoluzione dei nomi.
- Alcuni clienti potrebbero configurare la risoluzione dei nomi nei controller di dominio di Active Directory di Windows Server all'interno della sottoscrizione della landing zone della piattaforma Identity.
Per ospitare i carichi di lavoro, è possibile quindi utilizzare il peering di rete virtuale per connettere le sottoreti della zona di atterraggio dell'applicazione alla nuova rete virtuale hub nella nuova area geografica.
Suggerimento
Gestore di Reti Virtuali può semplificare l'espansione e la gestione delle reti virtuali su larga scala in più regioni.
Architettura della rete WAN virtuale
Nell'rete WAN virtuale esistente creare un nuovo hub virtuale nella nuova area di destinazione.
Distribuire Firewall di Azure o altre appliance virtuali di rete supportate nel nuovo hub virtuale. Configurare l'intenzione e le politiche di instradamento della rete WAN virtuale per instradare il traffico attraverso il nuovo hub virtuale protetto.
Se applicabile, distribuire i gateway di rete virtuale per la connettività VPN o ExpressRoute nel nuovo hub virtuale e stabilire le connessioni. Assicurarsi che i circuiti ExpressRoute e le posizioni locali seguano le raccomandazioni sulla resilienza Microsoft. Per ulteriori informazioni, vedere Progettazione del ripristino di emergenza con il peering privato di ExpressRoute.
Creare e configurare qualsiasi altro routing necessario, ad esempio le route statiche dell'hub virtuale.
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 dell'area di approdo della piattaforma Identity.
Nelle distribuzioni di 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 usare il peering di rete virtuale per connettere gli spoke della zona di destinazione dell'applicazione alla nuova rete virtuale hub nella nuova area.
Identità
Suggerimento
Esaminare l'area di progettazione della zona di destinazione di Azure per la gestione delle identità e degli accessi.
Decidi se hai bisogno di una nuova sottoscrizione per la zona di atterraggio della piattaforma. È consigliabile che la maggior parte dei clienti utilizzi la sottoscrizione Identity esistente, anche quando usano più regioni.
Creare un nuovo gruppo di risorse nella nuova area di destinazione.
Creare una nuova rete virtuale nella nuova area di destinazione.
Stabilire il peering di rete virtuale con la rete virtuale del nuovo hub regionale nella sottoscrizione di Connettività.
Distribuire carichi di lavoro relativi ai servizi di identità, come le 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 le risorse di Azure in una nuova regione
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 o un'area geografica vicina, quindi viene avviata una nuova area di Azure nel paese o nell'area geografica di destinazione. È 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 articolo fornisce informazioni sulla migrazione dei componenti della zona di atterraggio del vostro ambiente. Per altre informazioni, 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, assicurati di controllare la presenza di eventuali assegnazioni di politiche che limitano le distribuzioni nella regione e aggiorna le politiche per consentire le distribuzioni nella nuova regione.
Risorse della zona di approdo regionale
Le risorse della zona di destinazione specifiche dell'area spesso richiedono una maggiore considerazione perché non è possibile spostare alcune risorse di Azure tra aree. Si consideri l'approccio seguente:
Aggiungere l'area di destinazione come area aggiuntiva alla zona di destinazione: per altre informazioni, vedere Aggiungere una nuova area a una zona di destinazione esistente.
Distribuire componenti centralizzati nell'area di destinazione: ad esempio, distribuire una nuova area di lavoro Log di Monitoraggio di Azure nell'area di destinazione in modo che i carichi di lavoro possano iniziare a usare il nuovo componente dopo la migrazione del carico di lavoro.
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 di Monitoraggio di Azure e altre risorse a livello di area.
Rimuovere le risorse nell'area di origine dopo aver completato la 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: usare Bicep, modelli di Azure Resource Manager (modelli arm), Terraform, scripting o un approccio simile per esportare e reimportare configurazioni complesse, ad esempio regole per Firewall di Azure.
Automazione: usare gli script per eseguire la migrazione delle risorse di Automazione tra aree.
ExpressRoute: valutare se è possibile usare lo SKU locale di ExpressRoute 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 basso costo rispetto ad altri SKU di ExpressRoute.