Progettazione di reti multiregione

Questo articolo illustra come progettare Azure reti che si estendono su più aree. Una rete multiregione offre disponibilità elevata in caso di interruzioni a livello di area, serve gli utenti distribuiti geograficamente con una latenza inferiore e supporta i requisiti di residenza dei dati normativi.

Informazioni su questo articolo

Questo articolo illustra la ridondanza della zona e la ridondanza a livello di area, le strategie di routing tra aree, le scelte della topologia dell'hub per le distribuzioni di più aree, i modelli di failover attivo-attivo e attivo-passivo e le considerazioni sulla latenza di replica.

Chi ha bisogno di questo articolo

Leggere questo articolo se l'ambiente corrisponde a una di queste condizioni:

  • Il carico di lavoro richiede una protezione per il ripristino di emergenza dal guasto completo di un'area di Azure.
  • Servi utenti in più aree geografiche e devi ridurre al minimo la latenza di rete.
  • I requisiti normativi o di conformità impongono che i dati rimangano entro limiti geografici specifici.
  • Gli obiettivi di continuità aziendale definiscono un obiettivo del tempo di ripristino (RTO) che una singola area non può soddisfare da sola.

Se il carico di lavoro opera in una singola area e le distribuzioni con ridondanza della zona soddisfano i requisiti di disponibilità, potrebbe non essere necessario ancora una progettazione multiregione. Inizia con una topologia hub-and-spoke o rete WAN virtuale in una regione, per poi estenderla in un secondo momento.

Focus lift-and-shift: i carichi di lavoro legacy spesso non possono funzionare in modalità active-active tra più aree geografiche. Pianificare il ripristino di emergenza con Azure Site Recovery e un hub nell'area di ripristino anziché una progettazione attiva completa.

Focus sulla modernizzazione: distribuire app rivolte ai clienti in configurazione attiva-attiva in due aree geografiche con SKU con ridondanza tra zone, usando uno spazio di indirizzi non sovrapposto in modo che le aree geografiche possano eseguire il peering, se necessario.

Focus multi-cloud: usare la rete WAN virtuale di Azure per connettere più regioni e filiali e pianificare l'instradamento tra regioni insieme al transito multi-cloud.

Azure servizi e funzionalità

La tabella seguente elenca i servizi e le funzionalità di Azure che abilitano la rete multiregione:

Servizio o funzionalità Ruolo nella progettazione di più aree Ulteriori informazioni
Gestione traffico di Azure Routing del traffico basato su DNS tra aree per qualsiasi protocollo Panoramica di Gestione traffico
Frontdoor di Azure Bilanciamento del carico globale HTTP/HTTPS con rete CDN e WAF al perimetro Panoramica di Frontdoor
Peering reti virtuali globale Connettività privata e a larghezza di banda elevata tra reti virtuali in aree diverse Peering di reti virtuali
Copertura globale di ExpressRoute Connette i siti locali tra loro tramite il backbone Azure Copertura globale di ExpressRoute
rete WAN virtuale di Azure (multi-hub) Transito globale gestito da Microsoft con instradamento automatico tra hub Transito globale della rete WAN virtuale
gestione rete virtuale di Azure (AVNM) Automatizza la topologia di peering tra aree e la gestione dei gruppi di rete Panoramica di AVNM

Perché la multiregione richiede più reti virtuali

Una rete virtuale (VNet) si estende su una singola area. Le subnet all'interno di tale rete virtuale si estendono su tutte le zone di disponibilità nell'area, ma la rete virtuale stessa non può estendersi attraverso i limiti dell'area. La rete multiregione significa quindi distribuire più reti virtuali, una o più per area e connetterle con servizi tra aree.

Diagramma che mostra una topologia active-active a due aree geografiche con Frontdoor di Azure e WAF che instradano il traffico in ingresso globale verso le aree Europa occidentale e Stati Uniti orientali, ciascuna delle quali contiene una rete virtuale hub con Firewall di Azure e Azure Bastion connessa tramite peering a una rete virtuale spoke del carico di lavoro, con il peering reti virtuali globale sul backbone Microsoft che collega le due aree.

Questo vincolo fondamentale forma ogni progettazione di più aree:

  • Ogni regione necessita di un proprio spazio di indirizzamento della VNet (che non si sovrapponga a quello delle altre regioni per il peering).
  • Il traffico tra regioni richiede un meccanismo di connettività esplicito: peering globale di VNet, inter-hub di rete WAN virtuale o routing basato su gateway.
  • I servizi di bilanciamento del carico globale (Gestione traffico o Frontdoor) indirizzano gli utenti alla distribuzione a livello di area corretta.

Per indicazioni sulla pianificazione di subnet e indirizzi, vedere Pianificazione degli indirizzi IP.

Zone di disponibilità rispetto alla ridondanza regionale

Prima di progettare una topologia a più aree, comprendere i due livelli di ridondanza dell'infrastruttura in Azure:

livello Protegge da Meccanismo Example
Zone di disponibilità Errore singolo del data center all'interno di un'area Separare fisicamente i data center con alimentazione, raffreddamento e rete indipendenti Firewall di Azure con ridondanza di zona distribuito in 3 zone
Ridondanza a livello di area Guasto totale della regione (calamità naturale, interruzione estesa) Distribuzione di carichi di lavoro in due o più aree Azure Applicazione Web attiva-attiva negli Stati Uniti orientali e negli Stati Uniti occidentali

Iniziare con la ridondanza della zona. Le distribuzioni con ridondanza della zona proteggono dagli scenari di errore più comuni (problemi dei singoli data center) senza la complessità del routing in più aree. Aggiungi ridondanza a livello di area geografica quando la tua azienda richiede la protezione da interruzioni che interessano un'intera area geografica o quando è necessario supportare utenti distribuiti geograficamente.

Riferimento per i servizi di rete con ridondanza di zona

La tabella seguente illustra le opzioni di distribuzione con ridondanza della zona per i servizi di rete principali. Distribuirli in ogni area in cui vengono eseguiti i carichi di lavoro:

Service Opzione con ridondanza tra zone Note
Firewall di Azure Eseguire la distribuzione tra zone di disponibilità Distribuisce in tutte e 3 le zone dell'area
Bilanciatore di carico standard Front-end con ridondanza tra zone Comportamento predefinito per lo SKU Standard
Gateway di applicazioni v2 Distribuzione a ridondanza di zona Richiede SKU Standard_v2 o WAF_v2
Gateway VPN Attiva-attiva con SKU con ridondanza della zona Usare SKU con suffisso AZ (VpnGw1AZ, VpnGw2AZ, ecc.)
ExpressRoute Gateway SKU con ridondanza della zona Usare ErGw1AZ, ErGw2AZ o ErGw3AZ
Azure Bastion Ridondanza della zona (anteprima) SKU Basic, Standard e Premium
NAT Gateway (StandardV2) Con ridondanza della zona SKU StandardV2 richiesto; lo SKU Standard è disponibile solo a livello di zona

Come scegliere un approccio di routing del traffico tra aree

Usare la tabella decisionale seguente per selezionare il servizio appropriato per il routing del traffico tra aree:

Requisiti Servizio consigliato Come funziona
Failover o distribuzione del carico in più aree per qualsiasi protocollo (HTTP, TCP, UDP) Gestione traffico di Azure Restituisce l'indirizzo IP dell'endpoint migliore tramite la risoluzione DNS. Il client si connette direttamente all'endpoint. La velocità di failover dipende dal TTL DNS (in genere da 30 a 300 secondi).
Bilanciamento del carico HTTP/HTTPS globale con CDN, WAF e failover rapido Frontdoor di Azure Terminare le connessioni in corrispondenza dei punti di presenza perimetrali ( PoP). Instrada le richieste al back-end integro più vicino. Fornisce il failover a livello di connessione (in pochi secondi, senza dipendere dal TTL del DNS).
Traffico privato di backend tra regioni (replicazione, API interne) Peering reti virtuali globale Connette le VNets tra aree geografiche diverse tramite la rete backbone Microsoft. Il peering non è transitivo; ogni relazione di peering è esplicita. Si applicano addebiti per il trasferimento dati per GB.
Connettività da sito a sito locale tramite Azure Copertura globale di ExpressRoute Connette due circuiti ExpressRoute in modo che le posizioni locali comunichino attraverso il backbone Microsoft senza attraversare i router hub.

Tip

Combinare questi servizi. Ad esempio, usare Frontdoor per il traffico HTTP rivolto agli utenti e il peering di reti virtuali globale per la replica backend tra aree geografiche.

Come scegliere una topologia hub multi-regione

Dopo aver deciso di estendere la rete tra aree, scegliere un modello hub per la gestione della connettività tra aree:

Fattore Hub per regione (tradizionale) WAN virtuale con più hub
Connettività tra aree Il cliente configura il peering delle reti virtuali globale tra gli hub regionali e gestisce gli instradamenti definiti dall'utente Routing automatico tra hub: tutti gli hub rete WAN virtuale interconnettono per impostazione predefinita
Management Controllo completo del cliente sul routing, sulle regole del firewall e sul peering infrastruttura dell'hub gestito da Microsoft con la gestione basata su criteri
Ideale per Organizzazioni che necessitano di un controllo dettagliato del routing, di NVA personalizzate o di investimenti preesistenti nell'hub Organizzazioni con molte aree, oltre 30 siti di succursale o preferenza per l'infrastruttura gestita
Transito globale Richiede il peering esplicito e la configurazione UDR tra ogni coppia di hub Integrato: il traffico tra due hub qualsiasi viene instradato automaticamente
Scaling Aggiungere manualmente hub e peering (AVNM può automatizzare) Aggiungere hub tramite la configurazione di rete WAN virtuale: gli aggiornamenti del routing avvengono automaticamente
Modello di costi Risorse della rete virtuale dell'hub (firewall, gateway, peering) fatturate separatamente Prezzi unitari di rete WAN virtuale più risorse connesse

Per un confronto dettagliato tra hub-spoke e rete WAN virtuale in una singola area, vedere Topologia hub-spoke e rete WAN virtuale.

Considerazioni relative alla progettazione

Focus sulla progettazione multi-area lift-and-shift

  • Per i carichi di lavoro legacy che non possono estendersi tra zone o aree geografiche, progettare una strategia di ripristino di emergenza anziché un'architettura attiva-attiva: replicare con Azure Site Recovery in un'area geografica di ripristino.
  • Creare un hub nell'area di ripristino che rispecchia l'hub primario in modo che il traffico di failover abbia gli stessi servizi condivisi.
  • Usare Gestione traffico di Azure o failover DNS per reindirizzare gli utenti durante un'interruzione a livello di area.
  • Mantenere lo spazio di indirizzi dell'area di ripristino non sovrapposto con l'area primaria per evitare conflitti durante il failover e qualsiasi peering successivo.

Modernizzare l'approccio progettuale multiregionale

  • Distribuire i carichi di lavoro rivolti ai clienti in modalità attiva-attiva in due regioni con SKU a ridondanza di zona per ottenere il massimo livello di resilienza.
  • Assegnare intervalli di indirizzi non sovrapposti alle regioni primaria e di backup, in modo che gli spoke attivo-attivo possano usare successivamente il peering di reti virtuali globale senza dover riassegnare gli indirizzi.
  • Scegliere il livello di distribuzione in base al tipo di app: Frontdoor di Azure per le app Web e Gestione traffico per app non Web, distribuendo gli endpoint pubblici a livello di area.
  • Proteggi gli endpoint pubblici di ogni area geografica con il firewall dell'hub (SNAT e DNAT), in modo che il traffico in ingresso venga ispezionato prima di raggiungere i servizi back-end.

Focus sulla progettazione cross-cloud multi-area

  • Usa rete WAN virtuale di Azure per interconnettere più regioni di Azure, filiali ed edge cloud con routing automatico di tipo any-to-any.
  • Pianificare intervalli di indirizzi riepilogati e non sovrapposti tra aree e cloud, in modo che il routing di transito rimanga semplice.
  • Terminare le connessioni IPsec tra cloud in hub protetti a livello di area e consentire rete WAN virtuale gestire il routing tra hub.
  • Distribuisci il traffico in ingresso pubblico tra le regioni usando Front Door o Traffic Manager e mantieni l'ispezione su ogni firewall hub regionale.

Prerequisiti

Prima di progettare una rete multiregione, assicurarsi di disporre di:

  • Distribuzione e test di una topologia a singola area. Iniziare con hub-spoke o rete WAN virtuale.
  • Requisiti definiti per la disponibilità elevata e il ripristino di emergenza: RTO, obiettivo del punto di ripristino (RPO) e requisiti di conformità.
  • È stato creato un piano di indirizzi IP non sovrapposto in tutte le aree. Vedere Pianificazione degli indirizzi IP.
  • Sono stati identificati i carichi di lavoro che richiedono la ridondanza regionale rispetto alla sola ridondanza di zona.

Modelli di distribuzione attivo-attivo e attivo-passivo

Il modello di distribuzione multiregionale determina il modo in cui il traffico scorre durante il normale funzionamento e in caso di guasto di un'area geografica:

Active-active

Entrambe le aree gestiscono il traffico contemporaneamente. Un servizio di bilanciamento del carico globale, ad esempio Gestione traffico o Frontdoor, distribuisce le richieste tra aree in base alla prossimità, alle prestazioni o al peso.

Quando usare active-active:

  • L'applicazione può gestire le richieste in qualsiasi area senza dipendenze di stato specifiche dell'area.
  • È necessario il valore RTO più basso possibile (il failover è immediato perché l'area integra serve già il traffico).
  • Si vuole usare la capacità in entrambe le aree durante il normale funzionamento (efficienza dei costi).

Considerazioni sulla rete:

  • Entrambe le aree devono avere un'infrastruttura di rete identica, inclusi firewall, gateway e servizi di bilanciamento del carico.
  • La replica dei dati tra aree deve mantenere aggiornate entrambe le distribuzioni.
  • Il TTL DNS e gli intervalli delle sonde di integrità determinano la rapidità con cui Traffic Manager reindirizza il traffico. Front Door offre un failover a livello di connessione più rapido.

Active-passive

Un'area (primaria) gestisce tutto il traffico. L'area secondaria rimane pronta, ma non gestisce le richieste dell'utente fino a quando non viene eseguito un evento di failover.

Quando usare active-passive:

  • L'applicazione ha requisiti rigorosi per l'area di scrittura o non può replicare facilmente lo stato.
  • I vincoli di costo impediscono l'esecuzione simultanea della capacità completa in due aree.
  • La tolleranza RTO prevede il tempo necessario per attivare la regione secondaria.

Considerazioni sulla rete:

  • L'infrastruttura di rete dell'area passiva può usare livelli più piccoli o capacità ridotta fino al failover.
  • Il failover automatizzato richiede probe di integrità con soglie appropriate (evitare il flapping).
  • Testare regolarmente il failover. Le configurazioni di rete nella regione passiva possono deviare se non vengono verificate.
  • Mantieni sincronizzate le tabelle di routing e le regole NSG tra regioni. Usare i modelli di infrastruttura come codice per assicurarsi che l'area passiva corrisponda al comportamento di sicurezza dell'area primaria.
  • Effettuare il preprovisioning di gateway VPN o ExpressRoute nell'area passiva. Il provisioning del gateway può richiedere 20-45 minuti. È troppo lento per la maggior parte degli obiettivi RTO.

Scelta tra rete attiva-attiva e attiva-passiva

La scelta tra rete attiva-attiva e attiva-passiva influisce sul ridimensionamento della rete, sui costi e sulla complessità operativa:

Consideration Active-active Active-passive
Capacità della rete Capacità completa in entrambe le aree Capacità ridotta nell'area passiva (scalabilità in caso di failover)
Provisioning del gateway Sempre attivo in entrambe le regioni Preconfigurato, ma può utilizzare livelli inferiori
Sincronizzazione dei dati tra aree Traffico di replica bidirezionale continuo Replicazione asincrona unidirezionale verso lo standby
Regole del firewall Set di regole identici, entrambi applicati attivamente Set di regole identici, ma set passivo raramente utilizzato
Indirizzi IP Entrambe le regioni annunciano al bilanciatore del carico globale Solo l'area primaria annuncia fino al verificarsi del failover
Rischio operativo Inferiore: entrambi i percorsi vengono continuamente esercitati Alto: il percorso passivo potrebbe deviare o avere configurazioni non testate

Replica e latenza dei dati

La replica tra aree introduce la latenza di rete che influisce sulla progettazione dell'applicazione. Le aree di Azure all'interno della stessa area geografica presentano in genere una latenza di andata e ritorno compresa tra 1 e 10 ms per le coppie vicine (ad esempio, East US ed East US 2) e tra 30 e 70 ms per le coppie distanti (ad esempio, East US e West US). Le coppie di aree transatlantiche o transpacifiche possono superare i 100 ms.

Considerazioni principali sulla progettazione:

  • Topologia di replica: Scegliere la replica sincrona solo per le coppie di aree con bassa latenza (< 10 ms). Usare la replica asincrona per coppie distanti per evitare una riduzione delle prestazioni dell'applicazione.
  • Pianificazione della larghezza di banda: Stimare i requisiti di throughput della replica e tenere conto dei costi di trasferimento dei dati per GB di Global VNet Peering. La replicazione di grandi volumi tra regioni distanti può generare costi significativi per il traffico in uscita.
  • Risoluzione dei conflitti: I modelli attivi-attivi con scritture bidirezionali richiedono strategie di risoluzione dei conflitti a livello di applicazione o database. La rete fornisce connettività, ma le applicazioni devono gestire i conflitti di scrittura.
  • Endpoint privati per la replica PaaS: Quando si esegue la replica di Azure SQL, Cosmos DB o Archiviazione tra aree, usare endpoint privati in ogni area per mantenere il traffico di replica nel backbone Microsoft ed evitare l'esposizione a Internet pubblica.

Considerazioni sui costi

La rete multiregione aumenta i costi tramite l'infrastruttura duplicata e il trasferimento dei dati tra aree. Pianificare il budget in base a questi driver di costo principali:

  • Trasferimento dati tra aree geografiche: Il peering globale di reti virtuali e il traffico tra hub di rete WAN virtuale comportano addebiti per GB per i dati che attraversano i confini tra aree geografiche. Il traffico intra-area geografica tra reti virtuali in peering nella stessa area geografica non prevede costi aggiuntivi all'interno della stessa zona ed è addebitato a una tariffa inferiore per il traffico tra zone.
  • Dispositivi di rete duplicati: Ogni regione richiede firewall, bilanciatore del carico e istanze gateway dedicati. Le distribuzioni attive-attive raddoppiano questi costi. Le distribuzioni attive-passive possono ridurre i costi usando livelli più piccoli nell'area di standby e aumentando le prestazioni durante il failover.
  • Tariffe per il bilanciamento del carico globale: Sia Traffic Manager che Front Door addebitano costi in base al numero di query DNS o di richieste elaborate. Front Door addebita anche il trasferimento dei dati dai PoP periferici ai backend.
  • ExpressRoute e Gateway VPN: le progettazioni di più aree richiedono spesso istanze del gateway in ogni area. I circuiti ExpressRoute che connettono più regioni comportano tariffe mensili per porta e addebiti a consumo per GB per i dati.
  • Ottimizza sfruttando la località del traffico: Progetta i tier applicativi per ridurre al minimo le chiamate tra regioni. Mantenere le repliche in lettura con il calcolo in ogni area per ridurre la larghezza di banda della replica e le query sensibili alla latenza.

Considerazioni relative alla sicurezza

Una rete multiregione introduce considerazioni sulla sicurezza oltre alle distribuzioni a singola area:

  • Il traffico rimane sul backbone Microsoft. Tutto il traffico interregionale tramite Global VNet Peering o la connettività inter-hub di rete WAN virtuale attraversa la rete backbone Microsoft, non Internet pubblico.
  • Distribuisci firewall a ridondanza di zona in ogni regione. Ogni hub a livello di area necessita di un'istanza del firewall per l'ispezione del traffico. Distribuisci i firewall tra le zone di disponibilità per garantire la sicurezza in caso di guasti di una zona.
  • Frontdoor WAF offre sicurezza perimetrale. Quando si usa Frontdoor, il relativo Web application firewall integrato controlla il traffico prima che raggiunga qualsiasi distribuzione a livello di area. In questo modo viene fornito un primo livello di difesa sul perimetro di rete.
  • Pianifica attentamente il failover DNS. Il failover di Traffic Manager dipende dal TTL del DNS. I TTL più brevi consentono un failover più veloce, ma aumentano il volume di query DNS. Frontdoor fornisce failover a livello di connessione che non dipende dalla scadenza della cache DNS del client.
  • Il traffico di Global Reach di ExpressRoute resta privato. Il traffico tra siti locali connessi tramite Copertura globale non tocca mai la rete Internet pubblica. Rimane sulla rete backbone di Microsoft fra i circuiti.
  • Proteggere i canali di replica tra aree. Il traffico di replica del back-end tramite il peering globale di reti virtuali è privato per impostazione predefinita, ma applicare gruppi di sicurezza di rete e crittografia per i dati sensibili in transito.

Se la progettazione di più aree include scenari specifici illustrati altrove in questa guida, vedere:

Ulteriori informazioni

Per altre informazioni sui servizi e sui concetti illustrati in questo articolo, vedere le risorse seguenti:

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Connettersi alla rete locale: dopo aver pianificato il ripristino di emergenza, stabilire la connettività VPN o ExpressRoute all'ambiente locale.

Nel prossimo percorso di modernizzazione:

Progettare i modelli di ingresso Internet: determinare il modo in cui il traffico dei clienti raggiunge le applicazioni tra le aree primarie e di backup.

Il prossimo passo nel tuo percorso multicloud:

Configurare i tunnel crittografati negli altri cloud: dopo la pianificazione di più aree, configurare la connettività VPN tra cloud.

  • Last updated on