Condividi tramite

Considerazioni sulla rete per le distribuzioni dual-region della soluzione Azure VMware

  • Articolo

Questo articolo descrive come configurare la connettività di rete quando i cloud privati della soluzione Azure VMware vengono distribuiti in due aree di Azure a scopo di resilienza di emergenza. Se sono presenti interruzioni parziali o complete a livello di area, 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 regione

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

  • In ogni area è presente una rete hub-spoke di Azure.
  • È stata distribuita una configurazione resiliente alle emergenze per Azure 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 cloud privato della soluzione Azure VMware è stato distribuito in ogni area.

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

Figura 1: Scenario a doppia regione che illustra come il peering di rete virtuale globale connette due reti virtuali in regioni diverse

Nota

Nello scenario di riferimento della Figura 1, le due reti virtuali dell'hub regionale sono connesse tramite peering VNet globale. Anche se non strettamente necessario, poiché il traffico tra reti virtuali di Azure nelle due aree potrebbe essere instradato tramite connessioni ExpressRoute, è consigliabile usare questa configurazione. Il peering VNet riduce al minimo la latenza e ottimizza la velocità effettiva, poiché elimina la necessità di instradare il traffico attraverso i router perimetrali meet-me di ExpressRoute.

Modelli di comunicazione in due regioni

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

Connettività tra aree della soluzione Azure VMware

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

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

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

Diagramma della figura 2, che mostra i cloud privati in diverse regioni connesse tramite una connessione Global Reach tra circuiti ExpressRoute gestiti.

Figura 2: Questo scenario di riferimento mostra i cloud privati della soluzione Azure VMware in aree diverse. Una connessione Global Reach collega direttamente i cloud tra i loro circuiti ExpressRoute gestiti.

Connettività ibrida

L'opzione consigliata per connettere i cloud privati di Azure VMware Solution ai siti locali è ExpressRoute Global Reach. È possibile stabilire connessioni Global Reach tra circuiti ExpressRoute gestiti dal cliente e circuiti ExpressRoute gestiti dalla soluzione Azure VMware. Le connessioni Global Reach non sono transitive, pertanto è necessaria una mesh completa (ogni circuito gestito della soluzione Azure VMware connesso a ogni circuito gestito dal cliente) per la resilienza ai disastri, come illustrato nella figura 3 seguente (rappresentata dalle linee arancioni).

Diagramma della figura 3, che mostra le connessioni Global Reach che connettono i circuiti ExpressRoute gestiti dal cliente e i circuiti ExpressRoute della VMware Solution.

Figura 3: Questo scenario di riferimento mostra le connessioni Global Reach tra circuiti ExpressRoute gestiti dal cliente e circuiti Azure VMware Solution ExpressRoute.

Connettività di rete virtuale di Azure

La rete virtuale di Azure può essere connessa ai cloud privati della soluzione Azure VMware tramite connessioni tra i gateway ExpressRoute e i circuiti gestiti della soluzione Azure VMware. Questa connessione è esattamente lo stesso modo in cui la rete virtuale di Azure può essere collegata ai siti locali attraverso circuiti ExpressRoute gestiti dal cliente. Per istruzioni di configurazione, vedere Connettersi al cloud privato manualmente.

Negli scenari in due aree è consigliabile usare una mesh completa per le connessioni ExpressRoute tra le due reti virtuali dell'hub a livello di area e i cloud privati, come illustrato nella figura 4 (rappresentata da linee gialle).

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

figura 4: questo scenario di riferimento mostra le risorse native di Azure in ogni area con connettività L3 diretta ai cloud privati della soluzione Azure VMware.

Connettività Internet

Quando si distribuiscono cloud privati della soluzione Azure VMware in più aree, è consigliabile usare opzioni native per la connettività a Internet (traduzione dell'indirizzo di rete di origine gestita, SNAT, o gli indirizzi IP pubblici fino al NSX-T). Entrambe le opzioni possono essere configurate tramite il portale di Azure (o tramite PowerShell, l'interfaccia della riga di comando o i modelli ARM/Bicep) in fase di distribuzione, come illustrato nella figura 5 seguente.

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

figura 5: questo screenshot evidenzia le opzioni native della soluzione Azure VMware per la connettività Internet nel portale di Azure.

Entrambe le opzioni evidenziate nella Figura 5 forniscono a ogni cloud privato un accesso diretto a Internet nella propria area. Le considerazioni seguenti devono informare la decisione relativa all'opzione di connettività Internet nativa da usare:

  • SNAT gestito deve essere usato in scenari con requisiti di base e di sola uscita (volumi bassi di connessioni in uscita e non è necessario un controllo granulare sul pool SNAT).
  • Gli indirizzi IP pubblici fino al limite NSX-T dovrebbero essere preferiti in scenari con grandi volumi di connessioni in uscita o quando si richiede un controllo granulare sugli indirizzi IP NAT. Ad esempio, quali VM della soluzione Azure VMware usano SNAT dietro quali indirizzi IP. Gli indirizzi IP pubblici fino alla rete perimetrale NSX-T supportano anche la connettività in ingresso tramite DNAT. La connettività Internet in ingresso non è descritta in questo articolo.

È possibile modificare la configurazione della connettività Internet di un cloud privato dopo la distribuzione iniziale. Tuttavia, il cloud privato perde la connettività a Internet, alla rete virtuale di Azure e ai siti locali durante l'aggiornamento della configurazione. Quando viene usata una delle opzioni di connettività Internet native nella figura 5 precedente, non è necessaria alcuna configurazione aggiuntiva negli scenari a doppia area (la topologia rimane uguale a quella illustrata nella figura 4). Per altre informazioni sulla connettività Internet per la soluzione Azure VMware, vedere considerazioni sulla progettazione della connettività Internet.

Interruzione internet nativa di Azure

Se una rete perimetrale Internet sicura è stata compilata nella rete virtuale di Azure prima dell'adozione della soluzione Azure VMware, potrebbe essere necessario usarla per l'accesso a Internet per i cloud privati della soluzione Azure VMware. 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. Le misure di sicurezza Internet nella rete virtuale Azure possono essere implementate utilizzando Firewall Azure o firewall di terze parti e appliance virtuali di rete e proxy disponibili in Azure Marketplace.

Il traffico associato a Internet generato dalle macchine virtuali della soluzione Azure VMware può essere attratto da una rete virtuale di Azure originando una route predefinita e annunciandola, tramite il protocollo BGP (Border Gateway Protocol), al circuito ExpressRoute gestito del cloud privato. Questa opzione di connettività Internet può essere configurata tramite il portale di Azure (o tramite PowerShell, l'interfaccia della riga di comando o i modelli 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 della soluzione Azure VMware per abilitare la connettività Internet tramite i bordi Internet nella rete virtuale di Azure.

figura 6: questo screenshot evidenzia la configurazione della soluzione Azure VMware che è necessario selezionare per abilitare la connettività Internet tramite i bordi Internet nella rete virtuale.

Le apparecchiature virtuali di rete perimetrale Internet possono originare la route predefinita se supportano BGP. In caso contrario, è necessario distribuire altre NVAs compatibili con BGP. Per altre informazioni su come implementare la connettività internet in uscita per la soluzione Azure VMware in una singola area, vedere Implementazione della connettività Internet per la soluzione Azure VMware con appliance virtuali di rete di Azure. Nello scenario in due aree descritte in questo articolo, è necessario applicare la stessa configurazione a entrambe le aree.

La considerazione chiave negli scenari a doppia regione è che la route predefinita originata in ciascuna regione deve essere propagata tramite ExpressRoute solo verso il cloud privato della soluzione Azure VMware nella stessa regione. Questa propagazione consente ai carichi di lavoro di Azure VMware Solution di accedere a Internet tramite un'uscita locale (nell'area). Tuttavia, se si usa la topologia illustrata nella figura 4, ogni cloud privato della Soluzione Azure VMware riceve anche una route predefinita a costo uguale dall'area remota attraverso le connessioni ExpressRoute interregionali. Le linee tratteggiate rosse rappresentano questa indesiderata propagazione della route predefinita tra regioni nella Figura 7.

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

figura 7: questo scenario di riferimento mostra le connessioni tra aree tra gateway ExpressRoute e circuiti ExpressRoute gestiti dalla soluzione Azure VMware che è necessario rimuovere per impedire la propagazione tra aree della route predefinita.

La rimozione delle connessioni ExpressRoute trans-regionali della soluzione Azure VMware ha l'obiettivo di inserire, in ogni cloud privato, una route predefinita per inoltrare le connessioni destinate a Internet verso l'internet edge di Azure nella regione locale.

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

La propagazione interregionale tramite Copertura globale di una route predefinita meno privilegiata offre resilienza contro i guasti del perimetro Internet locale. Se il nodo di rete di un'area va offline, smette di generare la rotta predefinita. In tal caso, la rotta predefinita meno preferita appresa dall'area remota viene installata nel cloud privato della soluzione Azure VMware, in modo che il traffico destinato a Internet venga instradato tramite l'uscita dell'area remota.

La topologia consigliata per le distribuzioni in due aree 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 due aree con accesso internet in uscita attraverso i bordi Internet.

figura 8: questo scenario di riferimento mostra la topologia consigliata per le distribuzioni a due aree con accesso in uscita Internet tramite i bordi Internet nella rete virtuale di Azure.

Quando si originano route predefinite in Azure, è necessario fare 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 internet edge 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 i nodi BGP che terminano i circuiti ExpressRoute gestiti dal cliente e filtrano le route predefinite delle appliance virtuali di rete di Azure.

Figura 9: Questo scenario di riferimento mostra i dispositivi Border Gateway Protocol che terminano i circuiti ExpressRoute gestiti dal cliente e filtrano le rotte predefinite delle appliance virtuali di rete di Azure.

Passaggi successivi