VLAN e subnet su VMware Engine

Google Cloud VMware Engine utilizza una rete VMware Engine per fornire la connettività di rete tra uno o più cloud privati, reti Virtual Private Cloud e reti on-premise. Google Cloud VMware Engine offre due tipi di rete: standard e legacy. Le reti standard sono le impostazioni predefinite per i progetti creati a partire da novembre 2023, sono globali e utilizzano il peering di rete VPC per la connettività. Le reti legacy sono disponibili solo nei progetti creati prima di novembre 2023, sono regionali e utilizzano l'accesso privato ai servizi per la connettività. Per ulteriori informazioni, vedi Informazioni sulle reti VMware Engine.

Indipendentemente dal tipo di rete, puoi creare segmenti di rete (subnet) utilizzando NSX-T Data Center per le macchine virtuali (VM) del tuo 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 perimetro 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

Per le VM dei workload, devi creare un segmento di rete in NSX Manager per il tuo cloud 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 in qualsiasi rete Virtual Private Cloud (VPC) in peering. Per un'analisi dettagliata di come VMware Engine alloca gli intervalli di indirizzi IP delle subnet per la gestione, consulta Requisiti di rete.

All'interno di un cloud privato, i segmenti di rete dei workload possono comunicare tra loro per impostazione predefinita. La comunicazione tra i cloud privati dipende dal tipo di rete VMware Engine. Per le reti legacy, 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, senza richiedere l'uscita. Per le reti standard, la comunicazione tra i cloud privati viene eseguita tramite il peering di rete VPC e dipende dalla configurazione VPC.

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 Cloud 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 New Distributed Port Group (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 distribuite:

  • 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 o da 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 clamping 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 di 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: