VLAN e subnet su VMware Engine

Google Cloud VMware Engine crea una rete per regione in cui viene deployato il servizio VMware Engine. La rete è un singolo spazio di indirizzi del livello 3 TCP con routing abilitato per impostazione predefinita. Tutti i cloud privati e le subnet creati in questa regione possono comunicare tra loro senza alcuna configurazione aggiuntiva. Puoi creare segmenti di rete (subnet) utilizzando NSX per le tue macchine virtuali (VM) del workload.

VLAN e subnet.

VLAN di gestione

Google crea una VLAN (rete di livello 2) per ogni cloud privato. Il traffico di livello 2 rimane all'interno del confine di un cloud privato, consentendoti di isolare il traffico locale all'interno del cloud privato. Queste VLAN vengono utilizzate per la rete di gestione. Per le VM dei carichi di lavoro, devi creare segmenti di rete su NSX Manager per il tuo cloud privato.

Subnet

Devi creare un segmento di rete in NSX Manager per il tuo cloud privato. A ogni cliente e regione viene assegnato un singolo spazio di indirizzi di livello 3 privato. Puoi configurare qualsiasi intervallo di indirizzi IP che non si sovrapponga ad altre reti nel tuo cloud privato, nella tua rete on-premise, nella tua rete di gestione del cloud privato o negli intervalli di indirizzi IP delle subnet nella tua rete Virtual Private Cloud (VPC). Per un'analisi dettagliata di come VMware Engine alloca gli intervalli di indirizzi IP delle subnet, consulta Requisiti di rete.

Per impostazione predefinita, tutte le subnet possono comunicare tra loro, riducendo il sovraccarico di configurazione per il routing tra icloud privatoi. I dati est-ovest tra i cloud privati nella stessa regione rimangono nella stessa rete di livello 3 e vengono trasferiti tramite l'infrastruttura di rete locale all'interno della regione. Non è necessaria alcuna uscita per la comunicazione tra cloud privati in una regione. Questo approccio elimina qualsiasi penalità di prestazioni WAN/di uscita durante il deployment di carichi di lavoro diversi in cloud privati diversi dello stesso progetto.

Subnet di gestione create su un cloud privato

Quando crei un cloud privato, VMware Engine crea le seguenti subnet di gestione:

  • Gestione del sistema:VLAN e subnet per la rete di gestione degli host ESXi, server DNS, vCenter Server
  • VMotion: VLAN e subnet per la rete vMotion degli host ESXi
  • VSAN:VLAN e subnet per la rete vSAN degli host ESXi
  • NsxtEdgeUplink1:VLAN e subnet per gli uplink VLAN a una rete esterna
  • NsxtEdgeUplink2:VLAN e subnet per gli uplink VLAN a una rete esterna
  • HCXUplink: utilizzato dalle appliance HCX IX (mobilità) e NE (estensione) per raggiungere i peer e consentire la creazione di HCX Service Mesh.
  • NsxtHostTransport:VLAN e subnet per la zona di trasporto host

Intervallo CIDR rete di deployment HCX

Quando crei un cloud privato su VMware Engine, VMware Engine installa automaticamente HCX sul cloud privato. Non è più necessario specificare un intervallo CIDR dedicato per i componenti HCX. Invece, VMware Engine alloca automaticamente lo spazio di rete richiesto per i componenti HCX (come HCX Manager, vMotion e WAN Uplink) dall'intervallo CIDR di gestione specificato per il tuo cloud privato.

Subnet di servizio

Quando crei un cloud privato, VMware Engine crea automaticamente subnet di servizio aggiuntive. Puoi scegliere come target le subnet di servizio per scenari di deployment di appliance o servizi, come archiviazione, backup, ripristino di emergenza, streaming di contenuti multimediali e fornitura di velocità effettiva lineare ed elaborazione di pacchetti su larga scala anche per i cloud privati più grandi. I nomi delle subnet di servizio sono i seguenti:

  • service-1
  • service-2
  • service-3
  • service-4
  • service-5

La comunicazione tra macchine virtuali in una subnet di servizio esce dall'host VMware ESXi direttamente nell'infrastruttura di networking Google Cloud , consentendo una comunicazione ad alta velocità.

Configurazione delle subnet di servizio

Quando VMware Engine crea una subnet di servizio, non alloca un intervallo o un prefisso CIDR. Devi specificare un intervallo e un prefisso CIDR che non si sovrappongano. Il primo indirizzo utilizzabile diventerà quello del gateway. Per allocare un intervallo CIDR e un prefisso, modifica una delle subnet del servizio.

Le subnet di servizio possono essere aggiornate se i requisiti CIDR cambiano. La modifica di un CIDR di subnet di servizio esistente potrebbe causare l'interruzione della disponibilità di rete per le VM collegate a quella subnet di servizio.

Configurazione dei gruppi di porte distribuite vSphere

Per connettere una VM a una subnet di servizio, devi creare un nuovo gruppo di porte distribuite. Questo gruppo mappa l'ID subnet del servizio a un nome di rete all'interno di un cloud privato vCenter.

Per farlo, vai alla sezione di configurazione di rete dell'interfaccia vCenter, seleziona Datacenter-dvs e poi Nuovo gruppo di porte distribuite.

Dopo aver creato il gruppo di porte distribuito, puoi collegare le VM selezionando il nome corrispondente nella configurazione di rete delle proprietà della VM.

Di seguito sono riportati i valori di configurazione critici del gruppo di porte distribuito:

  • Associazione di porte: associazione statica
  • Allocazione porte: elastica
  • Numero di porte: 120
  • Tipo di VLAN: VLAN
  • ID VLAN: l'ID subnet corrispondente nella sezione delle subnet dell'interfaccia Google Cloud VMware Engine

L'unità massima di trasmissione (MTU) è la dimensione in byte del pacchetto più grande supportato da un protocollo del livello di rete, che include intestazioni e dati. Per evitare problemi correlati alla frammentazione, ti consigliamo le seguenti impostazioni MTU:

  • Per le VM che comunicano solo con altri endpoint all'interno di un cloud privato standard, puoi utilizzare impostazioni MTU fino a 8800 byte.

  • Per le VM che comunicano solo con altri endpoint all'interno di un cloud privato esteso, puoi utilizzare impostazioni MTU fino a 8600 byte.

  • Per le VM che comunicano con o da un cloud privato senza incapsulamento, utilizza l'impostazione MTU standard di 1500 byte. Questa impostazione predefinita comune è valida per le interfacce VM che inviano traffico nei seguenti modi:

    • Da una VM in un cloud privato a una VM in un altro cloud privato
    • Da un endpoint on-premise a un cloud privato
    • Da una VM in un cloud privato a un endpoint on-premise
    • Da internet a un cloud privato
    • Da una VM in un cloud privato a internet

  • Per le VM che comunicano con internet con flussi di traffico UDP di pacchetti di grandi dimensioni sensibili alla frammentazione, utilizza un'impostazione MTU di 1370 byte o inferiore. Questo consiglio si applica alle comunicazioni che utilizzano connessioni pubbliche o indirizzi IP forniti da VMware Engine. Il blocco MSS in genere risolve i problemi di frammentazione con i flussi di traffico basati su TCP.

  • Per le VM che comunicano con o da un cloud privato con incapsulamento, calcola l'impostazione MTU migliore in base alle configurazioni degli endpoint VPN. In genere, ciò comporta un'impostazione MTU di 1350-1390 byte o inferiore per le interfacce VM che inviano il traffico nei seguenti modi:

    • Da un endpoint on-premise a un cloud privato con incapsulamento
    • Da una VM cloud privato a un endpoint on-premise con incapsulamento
    • Da una VM in un cloud privato a una VM in un altro cloud privato con incapsulamento

Questi consigli sono particolarmente importanti nei casi in cui un'applicazione non è in grado di controllare le dimensioni massime del payload. Per ulteriori indicazioni sul calcolo dell'overhead di incapsulamento, consulta le seguenti risorse: