Linee guida per VMware HCX Mobility Optimized Networking (MON)

Nota

VMware HCX Mobility Optimized Networking è ufficialmente supportato da VMware e soluzione Azure VMware da HCX versione 4.1.0.

Importante

Prima di abilitare HCX MON, leggere le limitazioni e le configurazioni non supportate seguenti:

Configurazioni di origine non supportate per HCX NE

Limitazioni per qualsiasi distribuzione HCX, incluso MON

VMware HCX Mobility Optimized Networking (MON) non è supportato con l'uso di un gateway di terze parti. Può essere usato solo con il gateway T1 connesso direttamente al gateway T0 senza un'appliance virtuale di rete. È possibile eseguire questa funzione di configurazione, ma non è supportata.

HCX Mobility Optimized Networking (MON) è una funzionalità facoltativa da abilitare quando si usano le estensioni di rete HCX (NE). MON offre un routing ottimale del traffico in determinati scenari per impedire la tromba di rete tra le risorse locali e basate sul cloud su reti estese.

Poiché MON è una funzionalità aziendale della funzionalità NE, assicurarsi di abilitare VMware HCX Enterprise tramite il portale di Azure.

Durante il ciclo di migrazione, MON ottimizza la mobilità delle applicazioni per:

• Ottimizzazione per la comunicazione tra macchine virtuali e VM L2 quando si usano reti estese

• Ottimizzazione ed evitare flussi di traffico asimmetrici tra locale, soluzione Azure VMware e Azure

Questo articolo illustra i casi d'uso specifici di soluzione Azure VMware per MON.

Ottimizzare i flussi di traffico tra segmenti standard e estesi sul lato cloud privato

In questo scenario viene eseguita la migrazione di VM1 al cloud usando ne, che offre una latenza ottimale per la macchina virtuale. Di conseguenza, VM1 richiede una bassa latenza a VM3 nel segmento soluzione Azure VMware locale. È stata eseguita la migrazione del gateway VM1 dall'ambiente locale alla soluzione Azure VMware (cloud) per garantire un percorso ottimale per il traffico (linea blu). Se il gateway rimane locale (linea rossa), si osserva un effetto di trombatura e una latenza più elevata.

Nota

Quando si abilita MON senza eseguire la migrazione del gateway di macchina virtuale sul lato cloud, non garantisce un percorso ottimale per il flusso del traffico. Non consente inoltre la valutazione delle route dei criteri.

Ottimizzare ed evitare flussi di traffico asimmetrici

In questo scenario si presuppone che venga eseguita la migrazione di una macchina virtuale dall'ambiente locale a soluzione Azure VMware e che partecipi al traffico L2 e il traffico L3 torna in locale per accedere ai servizi. Si presuppone anche che alcune comunicazioni tra macchine virtuali da Azure (nella rete virtuale connessa soluzione Azure VMware) possano raggiungere il soluzione Azure VMware cloud privato.

Importante

Il punto principale è pianificare ed evitare con attenzione i flussi di traffico asimmetrici.

Per impostazione predefinita e senza usare MON, una macchina virtuale in soluzione Azure VMware in una rete estesa senza MON può comunicare in locale usando il percorso preferito di ExpressRoute. In base ai casi d'uso dei clienti, è necessario valutare il modo in cui una macchina virtuale in un segmento esteso soluzione Azure VMware abilitato con MON deve tornare all'ambiente locale, tramite l'estensione di rete o il gateway T0 tramite ExpressRoute mantenendo i flussi di traffico simmetrici.

Se si sceglie il percorso NE, ad esempio, le route dei criteri MON devono indirizzare specificamente la subnet sul lato locale; in caso contrario, viene usata la route predefinita 0.0.0.0/0. Le route dei criteri sono disponibili nel segmento NE selezionando Avanzate.

Per impostazione predefinita, tutti gli indirizzi IP RFC 1918 sono inclusi nella definizione delle route dei criteri MON.

Questo comporta il tunneling di tutto il traffico in uscita RFC 1918 sul percorso NE e tutto il traffico Internet e pubblico instradato al gateway T0.

Le route dei criteri vengono valutate solo se viene eseguita la migrazione del gateway di macchina virtuale al cloud. L'effetto di questa configurazione è che qualsiasi subnet corrispondente per la destinazione viene sottoposto a tunneling sull'appliance NE. Se non corrisponde, vengono instradati attraverso il gateway T0.

Nota

La considerazione speciale per l'uso di MON in soluzione Azure VMware consiste nell'assegnare alle route /32 annunciate tramite BGP i peer, inclusi l'ambiente locale e Azure tramite la connessione ExpressRoute. Ad esempio, una macchina virtuale in Azure apprende il percorso di una macchina virtuale soluzione Azure VMware in un segmento abilitato soluzione Azure VMware MON. Dopo che il traffico restituito viene inviato al gateway T0 come previsto, se la subnet restituita è una corrispondenza RFC 1918, il traffico viene forzato su NE anziché sul T0. Quindi in uscita su ExpressRoute in Azure sul lato locale. Ciò può causare confusione per i firewall con stato nel comportamento di routing intermedio e asimmetrico. È anche consigliabile determinare il modo in cui le macchine virtuali nei segmenti NE MON dovranno accedere a Internet, tramite il gateway T0 in soluzione Azure VMware o solo tramite l'NE in locale. In generale, tutte le route dei criteri predefinite devono essere rimosse per evitare il traffico asimmetrico. Abilitare le route dei criteri solo se l'infrastruttura di rete è stata configurata in modo da tenere conto e impedire il traffico asimmetrico.

Le route dei criteri MON possono essere eliminate con nessuna definizione. In questo modo tutto il traffico in uscita viene instradato al gateway T0.

Le route dei criteri MON possono essere aggiornate con una route predefinita (0.0.0.0/0). Questo comporta il tunneling di tutto il traffico in uscita sul percorso NE.

Come descritto nei diagrammi precedenti, l'importanza consiste nell'associare una route dei criteri a ogni subnet richiesta. In caso contrario, il traffico viene instradato su T0 e non sottoposto a tunneling sull'NE.

Per altre informazioni sulle route dei criteri, vedere Percorsi dei criteri di rete ottimizzati per la mobilità.