considerazioni sulla progettazione della rete soluzione Azure VMware
soluzione Azure VMware offre un ambiente cloud privato VMware a cui gli utenti e le applicazioni possono accedere da ambienti o risorse locali e basati su Azure. I servizi di rete, ad esempio Azure ExpressRoute e le connessioni VPN (Virtual Private Network) offrono la connettività.
Prima di configurare l'ambiente di soluzione Azure VMware, è necessario esaminare alcune considerazioni sulla rete. Questo articolo fornisce soluzioni per i casi d'uso che possono verificarsi quando si usa soluzione Azure VMware per configurare le reti.
soluzione Azure VMware compatibilità con AS-Path Prepend
soluzione Azure VMware considerazioni relative all'uso di AS-Path Prepend per le configurazioni ExpressRoute ridondanti. Se si eseguono due o più percorsi ExpressRoute tra l'ambiente locale e Azure, prendere in considerazione le indicazioni seguenti per influenzare il traffico da soluzione Azure VMware verso la posizione locale tramite ExpressRoute GlobalReach.
A causa del routing asimmetrico, i problemi di connettività possono verificarsi quando soluzione Azure VMware non osserva AS-Path Prepend e quindi usa il routing ECMP (Equal-Cost MultiPath) per inviare il traffico verso l'ambiente su entrambi i circuiti ExpressRoute. Questo comportamento può causare problemi con i dispositivi di ispezione firewall con stato posizionati dietro circuiti ExpressRoute esistenti.
Prerequisiti
Per AS-Path Prepend, considerare i prerequisiti seguenti:
- Il punto chiave è che è necessario anteporre numeri ASN pubblici per influenzare il modo in cui soluzione Azure VMware instrada il traffico in locale. Se si antepone l'ASN privato, soluzione Azure VMware ignorerà il prepend e si verificherà il comportamento ECMP indicato in precedenza. Anche se si gestisce un ASN BGP privato locale, è comunque possibile configurare i dispositivi locali per l'uso di un ASN pubblico quando le route in sospeso sono in uscita, per garantire la compatibilità con soluzione Azure VMware.
- Progettare il percorso del traffico per gli ASN privati dopo che l'ASN pubblico venga rispettato da soluzione Azure VMware. Il circuito ExpressRoute soluzione Azure VMware non esegue lo striping di asn privati presenti nel percorso dopo l'elaborazione dell'ASN pubblico.
- Entrambi o tutti i circuiti sono connessi a soluzione Azure VMware tramite Copertura globale di Azure ExpressRoute.
- Gli stessi netblock vengono annunciati da due o più circuiti.
- Si vuole usare AS-Path Prepend per forzare la soluzione Azure VMware a preferire un circuito rispetto a un altro.
- Usare numeri ASN pubblici a 2 byte o a 4 byte.
Macchine virtuali di gestione e route predefinite dall'ambiente locale
Importante
soluzione Azure VMware le macchine virtuali di gestione non rispettano una route predefinita dall'ambiente locale per le destinazioni RFC1918.
Se si esegue il routing alle reti locali usando solo una route predefinita pubblicizzata verso Azure, il traffico proveniente dal server vCenter e dalle macchine virtuali NSX Manager usate per le destinazioni locali con indirizzi IP privati non seguirà tale route.
Per raggiungere il server vCenter e NSX Manager dall'ambiente locale, fornire route specifiche per consentire al traffico di avere un percorso di ritorno verso tali reti. Ad esempio, annunciare i riepiloghi RFC1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16).
Route predefinita per soluzione Azure VMware per l'ispezione del traffico Internet
Alcune distribuzioni richiedono l'ispezione di tutto il traffico in uscita da soluzione Azure VMware verso Internet. Sebbene sia possibile creare appliance virtuali di rete (APPLIANCE virtuali di rete) in soluzione Azure VMware, esistono casi d'uso in cui queste appliance esistono già in Azure e possono essere applicate per controllare il traffico Internet da soluzione Azure VMware. In questo caso, una route predefinita può essere inserita dall'appliance virtuale di rete in Azure per attirare il traffico da soluzione Azure VMware ed esaminare il traffico prima di uscire dalla rete Internet pubblica.
Il diagramma seguente descrive una topologia hub-spoke di base connessa a un cloud soluzione Azure VMware e a una rete locale tramite ExpressRoute. Il diagramma mostra come l'appliance virtuale di rete in Azure ha origine la route predefinita (0.0.0.0/0). Il server di route di Azure propaga la route a soluzione Azure VMware tramite ExpressRoute.
Importante
La route predefinita annunciata dall'appliance virtuale di rete verrà propagata alla rete locale. È necessario aggiungere route definite dall'utente per assicurarsi che il traffico proveniente da soluzione Azure VMware stia transitando attraverso l'appliance virtuale di rete.
La comunicazione tra soluzione Azure VMware e la rete locale si verifica in genere tramite Copertura globale di ExpressRoute, come descritto in Eseguire il peering degli ambienti locali per soluzione Azure VMware.
Connessione ivity tra soluzione Azure VMware e una rete locale
Esistono due scenari principali per la connettività tra soluzione Azure VMware e una rete locale tramite un'appliance virtuale di rete di terze parti:
- Le organizzazioni devono inviare traffico tra soluzione Azure VMware e la rete locale tramite un'appliance virtuale di rete (in genere un firewall).
- Copertura globale di ExpressRoute non è disponibile in una determinata area per interconnettere i circuiti ExpressRoute di soluzione Azure VMware e la rete locale.
Esistono due topologie che è possibile applicare per soddisfare tutti i requisiti per questi scenari: rete virtuale supernet e spoke di transito.
Importante
L'opzione preferita per la connessione di soluzione Azure VMware e ambienti locali è una connessione Copertura globale diretta di ExpressRoute. I modelli descritti in questo articolo aggiungono complessità all'ambiente.
Topologia di progettazione supernet
Se entrambi i circuiti ExpressRoute (per soluzione Azure VMware e in locale) vengono terminati nello stesso gateway ExpressRoute, è possibile presupporre che il gateway instrada i pacchetti tra di essi. Tuttavia, un gateway ExpressRoute non è progettato per farlo. È necessario rimuovere il traffico da un'appliance virtuale di rete in grado di instradare il traffico.
Esistono due requisiti per rimuovere il traffico di rete a un'appliance virtuale di rete:
L'appliance virtuale di rete deve annunciare una supernet per i prefissi soluzione Azure VMware e locali.
È possibile usare una supernet che include prefissi sia soluzione Azure VMware che locali. In alternativa, è possibile usare singoli prefissi per soluzione Azure VMware e in locale (sempre meno specifici dei prefissi effettivi annunciati tramite ExpressRoute). Tenere presente che tutti i prefissi supernet annunciati al server di route vengono propagati sia a soluzione Azure VMware che in locale.
Le route definite dall'utente nella subnet del gateway, che corrispondono esattamente ai prefissi annunciati da soluzione Azure VMware e in locale, causano il traffico da parte della subnet del gateway all'appliance virtuale di rete.
Questa topologia comporta un sovraccarico di gestione elevato per reti di grandi dimensioni che cambiano nel tempo. Considerare queste limitazioni:
- Ogni volta che viene creato un segmento di carico di lavoro in soluzione Azure VMware, potrebbe essere necessario aggiungere le route definite dall'utente per assicurarsi che il traffico proveniente da soluzione Azure VMware transiti attraverso l'appliance virtuale di rete.
- Se l'ambiente locale ha un numero elevato di route che cambiano, potrebbe essere necessario aggiornare la configurazione BGP (Border Gateway Protocol) e la configurazione UDR nella supernet.
- Poiché un singolo gateway ExpressRoute elabora il traffico di rete in entrambe le direzioni, le prestazioni potrebbero essere limitate.
- È previsto un limite di 400 route definite dall'utente di Azure Rete virtuale.
Il diagramma seguente illustra come l'appliance virtuale di rete deve annunciare prefissi più generici (meno specifici) e che includono le reti locali e soluzione Azure VMware. Prestare attenzione a questo approccio. L'appliance virtuale di rete potrebbe potenzialmente attirare il traffico che non dovrebbe, perché pubblicizzare intervalli più ampi (ad esempio, l'intera 10.0.0.0/8 rete).
Topologia di rete virtuale spoke di transito
Nota
Se i prefissi pubblicitari meno specifici non sono possibili a causa dei limiti descritti in precedenza, è possibile implementare una progettazione alternativa che usa due reti virtuali separate.
In questa topologia, invece di propagare route meno specifiche per attirare il traffico verso il gateway ExpressRoute, due appliance virtuali di rete diverse in reti virtuali separate possono scambiare route tra loro. Le reti virtuali possono propagare queste route ai rispettivi circuiti ExpressRoute tramite BGP e il server di route di Azure. Ogni appliance virtuale di rete ha il controllo completo sui prefissi propagati a ogni circuito ExpressRoute.
Il diagramma seguente illustra come viene pubblicizzata una singola 0.0.0.0/0 route per soluzione Azure VMware. Viene inoltre illustrato come i singoli prefissi soluzione Azure VMware vengono propagati alla rete locale.
Importante
Tra le appliance virtuali di rete è necessario un protocollo di incapsulamento, ad esempio VXLAN o IPsec. L'incapsulamento è necessario perché la scheda di rete dell'appliance virtuale di rete (NIC) apprende le route dal server di route di Azure con l'appliance virtuale di rete come hop successivo e crea un ciclo di routing.
Esiste un'alternativa all'uso di una sovrimpressione. Applicare schede di interfaccia di rete secondarie nell'appliance virtuale di rete che non apprendono le route dal server di route di Azure. Configurare quindi le route definite dall'utente in modo che Azure possa instradare il traffico all'ambiente remoto su tali schede di interfaccia di rete. Per altre informazioni, vedere Topologia di rete e connettività su scala aziendale per soluzione Azure VMware.
Questa topologia richiede una configurazione iniziale complessa. La topologia funziona quindi come previsto con un sovraccarico di gestione minimo. Le complessità della configurazione includono:
- È previsto un costo aggiuntivo per aggiungere un'altra rete virtuale di transito che include il server di route di Azure, un gateway ExpressRoute e un'altra appliance virtuale di rete. Le appliance virtuali di rete potrebbero anche dover usare dimensioni di macchine virtuali di grandi dimensioni per soddisfare i requisiti di velocità effettiva.
- Il tunneling IPsec o VXLAN è necessario tra le due appliance virtuali di rete, il che significa che le appliance virtuali di rete si trovano anche nel percorso dati. A seconda del tipo di appliance virtuale di rete in uso, può comportare una configurazione personalizzata e complessa su tali appliance virtuali di rete.
Passaggi successivi
Dopo aver appreso le considerazioni sulla progettazione della rete per soluzione Azure VMware, prendere in considerazione l'esplorazione degli articoli seguenti: