Aree della zona di destinazione
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 Log di Monitoraggio di Azure, 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 rete WAN virtuale, incluso un hub rete WAN virtuale
- Reti virtuali di Azure
- gateway VPN
- Gateway 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 | Elemento consigliato |
|---|---|
| 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 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 di Monitoraggio di Azure per tutte le aree o creare più aree di lavoro per coprire varie aree geografiche. Ogni approccio presenta vantaggi e svantaggi, inclusi i potenziali addebiti per la rete tra aree. Per altre informazioni, vedere Progettare un'architettura dell'area di lavoro Log Analytics. |
| Rete | Se si distribuisce una topologia di rete, rete WAN virtuale o hub e spoke tradizionale, 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 dns (Domain Name System), è anche possibile distribuire 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 richiedono alcuna azione. |
| Identità | Se sono stati distribuiti Dominio di Active Directory Services o Microsoft Entra Domain Services nella sottoscrizione di identità o spoke, 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 aree e i servizi supportano le zone di disponibilità.
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
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.
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, distribuire Firewall di Azure o appliance virtuali di rete nella 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 altre informazioni, vedere Progettazione per il ripristino di emergenza con il peering privato di ExpressRoute.
Stabilire il peering di rete virtuale tra la nuova rete virtuale hub e le altre reti virtuali hub.
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 zona di destinazione di Identity Platform.
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.
Suggerimento
Rete virtuale Manager può semplificare l'espansione e la gestione delle reti virtuali su larga scala in più aree.
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 rete WAN virtuale criteri di routing e finalità di routing 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 altre informazioni, vedere Progettazione per il 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 della zona di destinazione di Identity Platform.
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.
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.
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 alla rete virtuale dell'hub di area appena creata nella sottoscrizione Connessione ivity.
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 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 destinazione dell'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, 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é 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.
Passaggio successivo
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per