Abilitare la connettività da soluzione Azure VMware
In questo modello di progettazione il traffico ha un percorso dedicato sul backbone Microsoft dal data center locale al cloud privato soluzione Azure VMware (AVS). Questa connessione avviene tramite Copertura globale expressroute, un meccanismo che fornisce un percorso diretto tra il cliente gestito, che può 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 nell'hub Rete virtuale (VNET). Vedere la sezione Ispezione del traffico e Annuncio predefinito della route.
Questa architettura è ideale per:
- Bassa latenza, in uscita in modo nativo dal data center SDDC (software-defined) soluzione Azure VMware a 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 alle reti virtuali native di Azure
- soluzione Azure VMware a Internet
- soluzione Azure VMware ai data center locali
Implementare questo scenario con:
- Un servizio di bilanciamento del carico avanzato NSX
- Indirizzo IP pubblico per Internet breakout da soluzione Azure VMware per la conversione degli indirizzi di origine e di destinazione (SNAT/DNAT)
Nota
Anche se NSX Advanced Load Balancer (Avi) offre funzionalità in ingresso direttamente all'interno di NSX, questa funzionalità è anche possibile con WAF o Gateway app v2 in Azure.
Questo documento presuppone e consiglia l'annuncio di route predefinito da locale o AVS. Se è necessario che la route predefinita provenga da Azure, fare riferimento alla sezione Ispezione traffico e annuncio di route predefinito.
- Abilitare l'indirizzo IP pubblico fino a NSX Edge in portale di Azure. Ciò consente connessioni dirette a bassa latenza a soluzione Azure VMware e la possibilità di ridimensionare il numero di connessioni in uscita.
- Applicare la creazione della regola del firewall NSX.
- Usare il servizio di bilanciamento del carico avanzato NSX per distribuire uniformemente il traffico ai carichi di lavoro.
- Abilitare la protezione flood (distribuita e gateway).
Copertura di ispezione del traffico | Progettazione della soluzione consigliata | Considerazioni | Interruzione Internet |
---|---|---|---|
- Ingresso Internet - Uscita Internet - Traffico verso un data center locale - Traffico verso Azure Rete virtuale - Traffico all'interno di soluzione Azure VMware |
Usare NSX-T o un firewall dell'appliance virtuale di rete di terze parti in soluzione Azure VMware. Usare NSX-T Advanced Load Balancer per HTTP o NSX-T Firewall per il traffico non HTTP/S. IP pubblico per internet breakout da soluzione Azure VMware, SNAT e DNAT. |
Scegliere questa opzione per annunciare la 0.0.0.0/0 route dal cloud privato soluzione Azure VMware. Abilitare l'indirizzo IP pubblico fino a NSX Edge in portale di Azure. Questa opzione consente connessioni a bassa latenza ad Azure e la possibilità di ridimensionare il numero di connessioni in uscita. |
Soluzione Azure VMware |
Copertura di ispezione del traffico | Progettazione della soluzione consigliata | Considerazioni | Interruzione Internet |
---|---|---|---|
- Ingresso Internet - Uscita Internet - Al data center locale |
Usare un'appliance virtuale locale Per il traffico HTTP/S, usare NSX Advanced Load Balancer o gateway applicazione in Azure. Per il traffico non HTTP/S, usare il firewall distribuito NSX. Abilitare l'indirizzo IP pubblico in soluzione Azure VMware. |
Scegliere questa opzione per annunciare la 0.0.0.0/0 route dai data center locali. |
Locale |
Importante
Alcune appliance VMware tradizionali usano l'inserimento del servizio per inserire appliance nel router di 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 di route predefinita da un dispositivo di entità in AVS.
L'integrazione con appliance di terze parti è possibile con un'attenta considerazione. In questa progettazione, le appliance virtuali di rete 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 altre informazioni su come inserire appliance virtuali di rete in AVS, vedere Modelli firewall NSX-T
Nota
Microsoft non supporta l'uso della rete ottimizzata per la mobilità quando vengono usate appliance virtuali di rete di terze parti.
Questa sezione fa riferimento alle procedure consigliate per l'integrazione di AVS con la zona di destinazione di Azure.
Il server di route di Azure viene usato per propagare dinamicamente le route apprese da AVS e fornire connettività da ramo a ramo a Gateway VPN. Le reti virtuali con peering alla rete virtuale in cui ars vive anche in modo dinamico apprendono 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 route:
- Informazioni su route specifiche da AVS a reti virtuali locali tramite BGP (Border Gateway Protocol). Le reti virtuali con peering possono quindi apprendere anche le route.
- Integrazione dell'appliance virtuale di rete di terze parti
- Eseguire il peering di ARS con appliance virtuali di rete in modo che non siano necessarie route definite dall'utente per ogni segmento AVS per filtrare il traffico.
- Il traffico restituito dalle reti virtuali con peering richiede una route definita dall'utente (route definite dall'utente) all'interfaccia locale del firewall
- Meccanismo di transito da Expressroute a Gateway VPN
- 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 to Branch
Usare il riepilogo delle route per > 1000 route o usare
NO_ADVERTISE BGP communities
flag a cui viene fatto 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
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 in 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 abilitare la connettività ottimizzata dal cloud privato AVS tramite ExpressRoute FastPath
- Distribuire ANF in una subnet delegata
- La distribuzione hub&spoke supporta lo SKU di ER GW fino a 10 Gbps
- Lo SKU Ultra & ErGw3AZ è necessario per ignorare i limiti di velocità delle porte del gateway
- Lettura del traffico in ingresso e traffico di scrittura in uscita tramite 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.
- Attualmente è supportato solo NFS v3.
Se viene visualizzata una latenza imprevista, assicurarsi che il cloud privato AVS e la distribuzione ANF siano aggiunti allo stesso az (Azure zone di disponibilità). Per la disponibilità elevata, creare volumi ANF in zone di accesso 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 soluzione Azure VMware qui
Anche se è consigliabile un circuito Expressroute, è possibile connettersi ad AVS dall'ambiente locale con IPSEC usando una rete virtuale dell'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.
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, Firewall di Azure non è possibile perché non parla BGP, ma è possibile usare un dispositivo con funzionalità BGP di terze parti. Questo scenario funziona per controllare il traffico da:
- Da locale ad Azure
- Da Azure a Internet
- Da AVS a Internet
- Da AVS ad Azure
Un'appliance virtuale di rete di terze parti nella rete virtuale hub controlla il traffico tra AVS e Internet e tra AVS e reti virtuali di Azure
Requisiti di ispezione del traffico | Progettazione della soluzione consigliata | Considerazioni | Interruzione Internet |
---|---|---|---|
- Ingresso Internet - Uscita Internet - Al data center locale - Ad Azure Rete virtuale |
Usare soluzioni firewall di terze parti in una rete virtuale hub con il server di route di Azure. Per il traffico HTTP/S, usare app Azure lication Gateway. Per il traffico non HTTP/S, usare un'appliance virtuale di rete del firewall di terze parti in Azure. Usare un'appliance virtuale di rete del firewall di terze parti locale. Distribuire soluzioni firewall di terze parti in una rete virtuale hub con il server di route di Azure. |
Scegliere questa opzione per annunciare la 0.0.0.0/0 route da un'appliance virtuale di rete nella rete virtuale dell'hub di Azure a un soluzione Azure VMware. |
Azure |
- 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 la route nell'interfaccia della riga di comando 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
- Per altre informazioni su come passare dalla VPN locale alla soluzione Azure VMware, vedere l'articolo sulla procedura seguente per il transito da VPN a ExR:
- Per altre informazioni sulla soluzione Azure VMware in 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 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à al soluzione Azure VMware