Share via

Considerazioni sulla rete per soluzione Azure VMware distribuzioni a doppia area

  • Articolo

Questo articolo descrive come configurare la connettività di rete quando vengono distribuiti soluzione Azure VMware cloud privati in due aree di Azure per scopi di resilienza di emergenza. Se sono presenti interruzioni di area parziali o complete, la topologia di rete in questo articolo consente ai componenti sopravvissuti (cloud privati, risorse native di Azure e siti locali) di mantenere la connettività tra loro e con Internet.

Scenario a doppia area

Questo articolo è incentrato su uno scenario tipico a doppia area, illustrato nella figura 1 seguente:

  • Una rete hub e spoke di Azure esiste in ogni area.
  • È stata distribuita una configurazione resiliente per ExpressRoute (due circuiti in due percorsi di peering diversi, con ogni circuito connesso alle reti virtuali hub in entrambe le aree). Le indicazioni fornite nelle sezioni seguenti rimangono invariate nel caso in cui la connettività VPN di fallback sia configurata.
  • Un soluzione Azure VMware cloud privato è stato distribuito in ogni area.

Diagramma della figura 1, che illustra lo scenario a doppia area illustrato in questo articolo.

Nota

Nello scenario di riferimento della figura 1, le due reti virtuali hub a livello di area sono connesse tramite peering reti virtuali globali. Anche se non è strettamente necessario, poiché il traffico tra reti virtuali di Azure nelle due aree potrebbe essere instradato sulle connessioni ExpressRoute, è consigliabile eseguire questa configurazione. Il peering reti virtuali riduce al minimo la latenza e ottimizza la velocità effettiva, perché rimuove la necessità di scorrere il traffico tramite i router perimetrali di ExpressRoute.

Modelli di comunicazione a due aree

Le sezioni successive descrivono la configurazione di rete soluzione Azure VMware necessaria per abilitare, nello scenario di doppia area di riferimento, i modelli di comunicazione seguenti:

soluzione Azure VMware connettività tra aree

Quando esistono più soluzione Azure VMware cloud privati, la connettività di livello 3 tra di esse è spesso un requisito per le attività, ad esempio il supporto della replica dei dati.

soluzione Azure VMware supporta in modo nativo la connettività diretta tra due cloud privati distribuiti in diverse aree di Azure. I cloud privati si connettono alla rete di Azure nella propria area tramite circuiti ExpressRoute, gestiti dalla piattaforma e terminati nelle posizioni di riunione di ExpressRoute dedicate. In questo articolo questi circuiti vengono definiti circuiti gestiti soluzione Azure VMware. soluzione Azure VMware circuiti gestiti non devono essere confusi con i normali circuiti distribuiti dai clienti per connettere i siti locali ad Azure. I circuiti normali distribuiti dai clienti sono circuiti gestiti dai clienti (vedere la figura 2).

La connettività diretta tra cloud privati si basa sulle connessioni Di copertura globale ExpressRoute tra circuiti gestiti soluzione Azure VMware, come illustrato dalla linea verde nel diagramma seguente. Per altre informazioni, vedere Esercitazione: Eseguire il peering degli ambienti locali per soluzione Azure VMware. L'articolo descrive la procedura per la connessione di un circuito gestito soluzione Azure VMware con un circuito gestito dal cliente. La stessa procedura si applica alla connessione di due circuiti gestiti soluzione Azure VMware.

Diagramma della figura 2, che mostra i cloud privati in aree diverse connesse tramite una connessione Di copertura globale tra circuiti ExpressRoute gestiti.

Connettività ibrida

L'opzione consigliata per connettere soluzione Azure VMware cloud privati ai siti locali è ExpressRoute Global Reach. Le connessioni a copertura globale possono essere stabilite tra i circuiti ExpressRoute gestiti dal cliente e soluzione Azure VMware circuiti ExpressRoute gestiti. Le connessioni a copertura globale non sono transitive, pertanto una mesh completa (ogni circuito gestito soluzione Azure VMware connesso a ogni circuito gestito dal cliente) è necessario per la resilienza di emergenza, come illustrato nella figura 3 seguente (rappresentata dalle linee arancioni).

Diagramma della figura 3, che mostra le connessioni a copertura globale che connettono i circuiti ExpressRoute gestiti dal cliente e i circuiti ExpressRoute della soluzione VMware.

Connettività di Rete virtuale di Azure

Azure Rete virtuale può essere connesso a cloud privati soluzione Azure VMware tramite connessioni tra gateway ExpressRoute e circuiti gestiti soluzione Azure VMware. Questa connessione è esattamente lo stesso modo in cui Azure Rete virtuale può essere connesso ai siti locali sui circuiti ExpressRoute gestiti dal cliente. Per istruzioni di configurazione, vedere Connettersi al cloud privato manualmente .

Negli scenari di doppia area è consigliabile creare una mesh completa per le connessioni ExpressRoute tra i due hub regionali Rete virtuale e i cloud privati, come illustrato nella figura 4 (rappresentata dalle linee gialle).

Diagramma della figura 4, che mostra che le risorse native di Azure in ogni area hanno connettività L3 diretta a soluzione Azure VMware cloud privati.

Connettività Internet

Quando si distribuisce soluzione Azure VMware cloud privati in più aree, è consigliabile usare opzioni native per la connettività Internet (SNAT) o gli INDIRIZZI IP pubblici (Managed Source Address Translation) fino a NSX-T. È possibile configurare l'opzione tramite il portale di Azure (o tramite modelli powerShell, interfaccia della riga di comando o ARM/Bicep) in fase di distribuzione, come illustrato nella figura 5 seguente.

Diagramma della figura 5, che mostra le opzioni native di soluzione Azure VMware per la connettività Internet nel portale di Azure.

Entrambe le opzioni evidenziate nella figura 5 forniscono a ogni cloud privato un breakout internet diretto nella propria area. Le considerazioni seguenti devono informare la decisione su quale opzione di connettività Internet nativa usare:

  • SNAT gestito deve essere usato negli scenari con requisiti di base e di sola uscita (volumi bassi di connessioni in uscita e nessuna necessità di controllo granulare sul pool SNAT).
  • Gli INDIRIZZI IP pubblici fino al bordo NSX-T devono essere preferiti negli scenari con grandi volumi di connessioni in uscita o quando è necessario un controllo granulare sugli indirizzi IP NAT. Ad esempio, che soluzione Azure VMware macchine virtuali usano SNAT dietro i quali indirizzi IP. Gli INDIRIZZI IP pubblici fino al bordo NSX-T supportano anche la connettività in ingresso tramite DNAT. La connettività Internet in ingresso non è illustrata in questo articolo.

La modifica della configurazione della connettività Internet del cloud privato dopo la distribuzione iniziale è possibile. Tuttavia, il cloud privato perde la connettività a Internet, azure Rete virtuale e siti locali mentre la configurazione viene aggiornata. Quando viene usata una delle opzioni di connettività Internet nativa nella figura 5 precedente, non è necessaria alcuna configurazione aggiuntiva in scenari di doppia area(la topologia rimane uguale a quella illustrata nella figura 4). Per altre informazioni sulla connettività Internet per soluzione Azure VMware, vedere Considerazioni sulla progettazione della connettività Internet.

Interruzione internet nativa di Azure

Se un internet edge sicuro è stato compilato in Azure Rete virtuale prima dell'adozione di soluzione Azure VMware, potrebbe essere necessario usarlo per l'accesso a Internet per soluzione Azure VMware cloud privati. L'uso di un internet edge sicuro in questo modo è necessario per la gestione centralizzata dei criteri di sicurezza di rete, l'ottimizzazione dei costi e altro ancora. I bordi di sicurezza Internet in Azure Rete virtuale possono essere implementati usando Firewall di Azure o firewall di terze parti e appliance virtuali di rete proxy disponibili nel Azure Marketplace.

Il traffico associato a Internet generato da soluzione Azure VMware macchine virtuali può essere attratto da una rete virtuale di Azure originando una route predefinita e annunciandolo, tramite il protocollo BGP (Border Gateway Protocol), al circuito ExpressRoute gestito dal cloud privato. Questa opzione di connettività Internet può essere configurata tramite il portale di Azure (o tramite i modelli powerShell, interfaccia della riga di comando o ARM/Bicep) in fase di distribuzione, come illustrato nella figura 6 seguente. Per altre informazioni, vedere Disabilitare l'accesso a Internet o abilitare una route predefinita.

Diagramma della figura 6, che mostra la configurazione soluzione Azure VMware per abilitare la connettività Internet tramite i bordi Internet in Azure Rete virtuale.

Le nvA perimetrali Internet possono avere origine la route predefinita se supportano BGP. In caso contrario, è necessario distribuire altre NVA con funzionalità BGP. Per altre informazioni su come implementare la connettività in uscita Internet per soluzione Azure VMware in una singola area, vedere Implementazione della connettività Internet per soluzione Azure VMware con Azure NVAs. Nello scenario a due aree descritte in questo articolo, è necessario applicare la stessa configurazione a entrambe le aree.

La considerazione chiave negli scenari a doppia area è che la route predefinita originata in ogni area deve essere propagata solo in ExpressRoute solo al soluzione Azure VMware cloud privato nella stessa area. Questa propagazione consente soluzione Azure VMware carichi di lavoro per accedere a Internet tramite un breakout locale (in area). Tuttavia, se si usa la topologia illustrata nella figura 4, ogni soluzione Azure VMware cloud privato riceve anche una route predefinita di uguale costo dall'area remota sulle connessioni ExpressRoute tra aree. Le linee tratteggiate rosse rappresentano questa propagazione predefinita tra aree indesiderate nella figura 7.

Diagramma della figura 7, che mostra le connessioni tra aree tra gateway ExpressRoute e circuiti ExpressRoute gestiti dalla soluzione VMware devono essere rimossi.

La rimozione delle soluzione Azure VMware connessioni ExpressRoute tra aree raggiunge l'obiettivo di inserire, in ogni cloud privato, una route predefinita per inoltrare le connessioni associate a Internet ad Azure edge nell'area locale.

Si noti che se le connessioni ExpressRoute tra aree (linee tratteggiate rosse nella figura 7) vengono rimosse, la propagazione tra aree della route predefinita si verifica comunque su Copertura globale. Tuttavia, le route propagate su Global Reach hanno un percorso AS più lungo rispetto a quelli di origine locale e vengono ignorate dal processo di selezione della route BGP.

La propagazione tra aree rispetto alla copertura globale di una route predefinita meno preferita offre resilienza contro gli errori del bordo Internet locale. Se il bordo Internet di un'area è offline, si arresta l'origine della route predefinita. In questo caso, la route predefinita meno preferita appresa dall'area remota viene installata nel cloud privato soluzione Azure VMware, in modo che il traffico associato a Internet venga instradato tramite l'interruzione dell'area remota.

La topologia consigliata per le distribuzioni a doppia area con interruzioni Internet nelle reti virtuali di Azure è illustrata nella figura 8 seguente.

Diagramma della figura 8, che mostra la topologia consigliata per le distribuzioni in doppia area con l'accesso in uscita a Internet tramite i bordi Internet.

Quando si hanno route predefinite in Azure, è necessario prestare particolare attenzione per evitare la propagazione nei siti locali, a meno che non sia necessario fornire l'accesso a Internet ai siti locali tramite un edge Internet in Azure. I dispositivi gestiti dal cliente che terminano i circuiti ExpressRoute gestiti dal cliente devono essere configurati per filtrare le route predefinite ricevute da Azure, come illustrato nella figura 9. Questa configurazione è necessaria per evitare di interrompere l'accesso a Internet per i siti locali.

Diagramma della figura 9, che mostra gli altoparlanti BGP che terminano i circuiti ExpressRoute gestiti dal cliente filtrano le route predefinite di Azure NVAs.

Passaggi successivi