Abilitare la connettività dalla soluzione Azure VMware
Introduzione
In questo modello di progettazione, il traffico ha un percorso dedicato sul backbone Microsoft dal data center locale al cloud privato della soluzione Azure VMware (AVS). Questa connessione avviene tramite Expressroute Global Reach, un meccanismo che fornisce un percorso diretto tra le connessioni gestite dal cliente, che possono quindi connettersi ai circuiti Expressroute dedicati ad AVS. Il cloud privato ha anche un breakout separato e isolato da NSX Edge a Internet, in modo che questo traffico non attraversi ExpressRoute.
Importante
Se oggi ci si trova in un'area in cui Copertura globale non è supportata, il transito dall'ambiente locale al cloud privato AVS è possibile distribuendo un gateway Expressroute in Azure. Per fornire la transitività end-to-end, è necessaria un'appliance virtuale nella rete virtuale dell'hub. Consultare la sezione Ispezione del Traffico & Annuncio di Percorso Predefinito.
Profilo cliente
Questa architettura è ideale per:
- Bassa latenza, uscita nativa dai data center definiti dal software (SDDC) della soluzione Azure VMware verso Internet.
- Indirizzare il traffico dall'ambiente locale direttamente ad Azure tramite Expressroute o VPN.
- Servizi L4/L7 in ingresso per carichi di lavoro in SDDC, ad esempio HTTPS
Il traffico, che passa attraverso i router NSX AVS, descritto in questa progettazione include:
- Soluzione Azure VMware in reti virtuali native di Azure
- Soluzione Azure VMware su Internet
- Soluzione Azure VMware per data center locali
Componenti dell'architettura
Implementare questo scenario con:
- Bilanciatore di carico avanzato NSX
- IP pubblico per uscita verso Internet dalla soluzione Azure VMware per la traduzione degli indirizzi di origine e di destinazione (SNAT/DNAT)
Nota
Anche se NSX Advanced Load Balancer (Avi) offre capacità di gestione del traffico in entrata direttamente all'interno di NSX, è possibile ottenere questa funzionalità anche con WAF o Gateway app v2 in Azure.
Decisione chiave
Questo documento presuppone e consiglia l'annuncio di route predefinito da locale o AVS. Se è necessario che la route predefinita provenga da Azure, vedere la sezione Ispezione del Traffico & Annuncio della Route Predefinita.
Considerazioni
- Abilitare l'indirizzo IP pubblico fino a NSX Edge nel portale di Azure. Ciò consente connessioni dirette a bassa latenza alla soluzione Azure VMware e la possibilità di ridimensionare il numero di connessioni in uscita.
- Applicare la creazione di regole del firewall NSX.
- Usare il bilanciatore di carico avanzato NSX per distribuire uniformemente il traffico ai carichi di lavoro.
- Abilitare Protezione Flood (Distribuita e Gateway).
Uscita da AVS tramite NSX-T o NVA
Copertura di ispezione del traffico | Progettazione consigliata della soluzione | Considerazioni | Interruzione Internet |
---|---|---|---|
- Ingresso Internet - Uscita Internet - Traffico verso un data center locale - Traffico verso la rete virtuale di Azure - Traffico all'interno della soluzione Azure VMware |
Usare NSX-T o un firewall NVA di terze parti nella soluzione Azure VMware.
Usare NSX-T Load Balancer avanzato per traffico HTTP/S o NSX-T Firewall per il traffico non HTTP/S. IP pubblico per uscita su Internet nella soluzione Azure VMware, SNAT e DNAT. |
Scegliere questa opzione per annunciare la route 0.0.0.0/0 dal cloud privato della soluzione Azure VMware.
Abilitare l'indirizzo IP pubblico fino al NSX Edge nel portale Azure. Questa opzione consente connessioni a bassa latenza ad Azure e la possibilità di ridimensionare il numero di connessioni in uscita. |
Soluzione Azure VMware |
Uscita dalla soluzione Azure VMware tramite l'annuncio 0.0.0.0/0 dall'infrastruttura locale
Copertura di ispezione del traffico | Progettazione consigliata della soluzione | Considerazioni | Interruzione Internet |
---|---|---|---|
- Ingresso Internet - Uscita Internet - Al datacenter locale |
Usare un'appliance virtuale locale Per il traffico HTTP/S, usare NSX Advanced Load Balancer o Application Gateway in Azure. Per il traffico non HTTP/S, usare il firewall distribuito NSX. Abilitare l'indirizzo IP pubblico nella soluzione Azure VMware. |
Scegliere questa opzione per pubblicizzare la route 0.0.0.0/0 dai datacenter locali. |
In sede |
Importante
Alcuni appliance tradizionali di VMware usano l'inserimento del servizio per posizionare gli appliance nel router del livello 0. Il provisioning dei router di livello 0 viene effettuato e gestito da Microsoft e non è utilizzabile dagli utenti finali. Tutti i dispositivi di rete e i servizi di bilanciamento del carico devono essere posizionati al livello 1. La sezione successiva illustra la propagazione del percorso predefinito da un dispositivo di partecipante nel sistema AVS.
Integrazione dell'appliance virtuale di rete (NVA) di terze parti in AVS
L'integrazione con appliance di terze parti è possibile con un'attenta considerazione. In questo progetto, le appliance virtuali di rete (NVA) di terze parti si trovano dietro uno o più router perimetrali T-1.
È responsabilità degli utenti portare una licenza e implementare tutte le funzionalità a disponibilità elevata native del dispositivo.
Tenere presenti i limiti quando si sceglie questa implementazione. Ad esempio, è previsto un limite massimo di otto schede di interfaccia di rete virtuale in una macchina virtuale. Per ulteriori informazioni su come inserire gli NVA in AVS, vedere: NSX-T modelli di firewall
Nota
Microsoft non supporta l'uso della rete ottimizzata per la mobilità quando vengono usate NVAs di terze parti.
Considerazioni sulla zona di atterraggio
Questa sezione fa riferimento alle procedure consigliate per l'integrazione di AVS con la zona di destinazione di Azure.
Azure Route Server
Azure Route Server (ARS) è utilizzato per propagare dinamicamente le route apprese da AVS e fornire il collegamento tra sedi ai gateway VPN. Le reti virtuali con peering alla rete virtuale in cui si trova ARS apprendono anche dinamicamente le route, consentendo di apprendere le route da AVS ad ambienti Hub e Spoke in Azure. I casi d'uso per il server di route di Azure includono:
Propagazione dinamica della rotta
- Informazioni su route specifiche da AVS a reti virtuali locali tramite BGP (Border Gateway Protocol). Le VNET interconnesse possono quindi apprendere anche le rotte.
- Integrazione NVA di terze parti
- Eseguire il peering di ARS con gli NVAs in modo tale da non dover utilizzare le route definite dall'utente per ogni segmento AVS per filtrare il traffico.
- Il traffico di ritorno dalle reti virtuali con peering richiede una route definita dall'utente verso l'interfaccia locale del firewall.
- Meccanismo di transito da Expressroute a gateway VPN
- Il gateway VPN deve essere di tipo da sito a sito e configurato in Active-Active
Per usare il server di route di Azure, è necessario:
Abilitare Branch to Branch
Usa il riepilogo delle route per > 1000 route o usa il flag
NO_ADVERTISE BGP communities
, a cui si fa riferimento nelle domande frequenti sul server di route di AzureEseguire il peering dell'appliance virtuale di rete con asn specifici non di Azure. Ad esempio, poiché ARS usa 65515, nessun'altra appliance nella rete virtuale può usare tale asn (numero di sistema autonomo).
Nessun supporto per IPV6
Integrazione con Azure NetApp Files
Azure NetApp Files (ANF) offre un archivio dati collegato alla rete tramite il protocollo NFS. ANF si trova in una rete virtuale di Azure e si connette ai carichi di lavoro nell'AVS. Usando archivi dati NFS supportati da Azure NetApp Files, è possibile espandere l'archiviazione anziché ridimensionare i cluster.
- Creare volumi di Azure NetApp Files usando le funzionalità di rete standard per consentire una connettività ottimizzata tramite ExpressRoute FastPath dal cloud privato AVS.
- Distribuire ANF in una subnet delegata
- La distribuzione Hub & Spoke supporta l'SKU di ER GW fino a 10 Gbps
- Lo SKU Ultra & ErGw3AZ è necessario per superare i limiti di velocità della porta del gateway.
- Lettura del traffico in ingresso e scrittura del traffico in uscita attraverso ExpressRoute. Il traffico in uscita su circuiti Expressroute ignora il gateway e passa direttamente al router perimetrale
- Gli addebiti in ingresso/uscita vengono eliminati da AVS, ma si verifica un addebito in uscita se i dati passano tra reti virtuali con peering.
- Usare un gateway ExpressRoute dedicato per Azure Netapp Files, non usare un gateway ExpressRoute condiviso/centralizzato.
- Non inserire un firewall o un'appliance virtuale di rete nel percorso dei dati tra Azure NetApp Files e la soluzione Azure VMware.
- Attualmente è supportato solo NFS v3.
Se viene visualizzata una latenza imprevista, assicurarsi che il cloud privato AVS e la distribuzione ANF siano assegnati allo stesso AZ (Zone di Disponibilità di Azure). Per garantire un'elevata disponibilità, creare volumi ANF in zone di disponibilità (AZ) separate e abilitare Cross Zone Replication
.
Importante
Microsoft non supporta Fastpath per l'hub VWAN di Azure protetto in cui la velocità massima possibile della porta è di 20 Gbps. Prendere in considerazione l'uso della rete virtuale hub & spoke se è necessaria una velocità effettiva maggiore. Vedere come collegare gli archivi dati di Azure Netapp Files agli host della soluzione Azure VMware qui
Connettività VPN da locale
Anche se è consigliabile un circuito ExpressRoute, è possibile connettersi ad AVS dall'ambiente locale con IPSEC usando un VNET hub di transito in Azure. Questo scenario richiede un gateway VPN e un server di route di Azure. Come indicato in precedenza, il server di route di Azure abilita la transitività tra il gateway VPN e il gateway Expressroute AVS.
Ispezione del traffico
Come illustrato in precedenza, l'annuncio di route predefinito avviene da AVS con l'indirizzo IP pubblico fino all'opzione NSX Edge, ma è anche possibile continuare a pubblicizzare la route predefinita dall'ambiente locale. Il filtro del traffico end-to-end da locale ad AVS è possibile con il firewall posizionato in uno di questi endpoint.
L'annuncio di route predefinito da Azure è possibile con un'appliance virtuale di rete di terze parti in una rete virtuale hub o quando si usa la rete WAN virtuale di Azure. In una distribuzione hub-spoke, Azure Firewall non è utilizzabile perché non supporta BGP; tuttavia, è possibile utilizzare un dispositivo di terze parti con funzionalità BGP. Questo scenario funziona per controllare il traffico da:
- Da locale ad Azure
- Da Azure a Internet
- Da AVS a Internet
- Trasferimento da AVS ad Azure
Una NVA (Network Virtual Appliance) di terze parti nella rete virtuale hub ispeziona il traffico tra AVS e Internet e tra AVS e le reti virtuali di Azure.
Requisiti di ispezione del traffico | Progettazione consigliata della soluzione | Considerazioni | Interruzione Internet |
---|---|---|---|
- Accesso a Internet - Uscita verso Internet - Verso il data center in locale - Verso la rete virtuale di Azure |
Usare soluzioni firewall di terze parti in una rete virtuale hub con Azure Route Server.
Per il traffico HTTP/S, usare il gateway applicativo di Azure. Per il traffico non HTTP/S, usare una NVA di firewall di terze parti in Azure. Usare un'appliance virtuale di rete (NVA) firewall di terze parti in sede. Distribuire soluzioni firewall di terze parti in una rete virtuale hub con il server di route di Azure. |
Scegliere questa opzione per pubblicizzare la route 0.0.0.0/0 da una NVA (Network Virtual Appliance) nella rete virtuale dell'hub di Azure a una soluzione Azure VMware. |
Azzurro |
Informazioni aggiuntive
- Accedere a vCenter usando la macchina virtuale Bastion + Jumpbox - Se si accede a vCenter dall'ambiente locale, assicurarsi di avere una route dalle reti locali alla rete di gestione AVS /22. Verificare che il percorso sia corretto nella CLI digitando
Test-NetConnection x.x.x.2 -port 443
- Considerazioni su DNS: se si usano endpoint privati, seguire le indicazioni riportate qui: Configurazione DNS dell'endpoint privato di Azure | Microsoft Learn
Passaggi successivi
- Per altre informazioni su come passare dalla VPN locale alla soluzione Azure VMware, vedere l'articolo seguente VPN per il transito exR:
- Per altre informazioni sulla soluzione Azure VMware nelle reti hub-spoke, vedere Integrare la soluzione Azure VMware in un'architettura hub-spoke.
- Per altre informazioni sui segmenti di rete di VMware NSX-T Data Center, vedere Configurare i componenti di rete NSX-T Data Center usando la soluzione Azure VMware.
- Per altre informazioni sul server router di Azure, vedere la panoramica del prodotto Che cos'è il server di route di Azure?
Osservare quindi altri modelli di progettazione per stabilire la connettività alla soluzione Azure VMware