Share via


Abilitare la connettività da 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 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.

soluzione Azure VMware con Copertura globale in locale e interruzione separata per Internet con IP pubblico AVS

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.

Profilo cliente

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

Componenti dell'architettura

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.

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, fare riferimento alla sezione Ispezione traffico e annuncio di route predefinito.

Considerazioni

  • 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).

Uscita da AVS con NSX-T o appliance virtuale di rete

Copertura di ispezione del traffico Progettazione della soluzione consigliata Considerazioni Interruzione Internet
- Ingresso Internet
- Uscita Internet
- Traffico verso e 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 HTTPs.

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 Abilita 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

Uscita da soluzione Azure VMware a 0.0.0.0/0 annuncio pubblicitario da locale

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.

Integrazione dell'appliance virtuale di rete di terze parti 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.

Considerazioni sulla zona di destinazione

Questa sezione fa riferimento alle procedure consigliate per l'integrazione di AVS con la zona di destinazione di Azure.

Server di route di Azure

Il server di route di Azure (ARS) 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, ovvero è possibile 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 meccanismo di transito del firewall 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 Azure

  • Eseguire 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 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

Connettività VPN da locale

Anche se è consigliabile un circuito Expressroute, è possibile connettersi ad AVS dall'ambiente locale con IP edizione Standard C 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.

soluzione Azure VMware con transito tra Expressroute e Gateway VPN locale

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.

soluzione Azure VMware con ispezione del traffico in Azure con appliance virtuale di rete di terze parti

L'annuncio di route predefinito da Azure è possibile con appliance virtuali 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, tuttavia l'uso di un dispositivo con supporto BGP di terze parti funzionerà. 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

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 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

soluzione Azure VMware sottoscrizione e organizzazione del gruppo di risorse

Passaggi successivi

Osservare quindi altri modelli di progettazione per stabilire la connettività al soluzione Azure VMware