VLAN e subnet su VMware Engine

Google Cloud VMware Engine crea una rete per regione in cui è stato eseguito il deployment del servizio VMware Engine. La rete è un singolo spazio di indirizzi TCP 3 con il routing abilitato per impostazione predefinita. Tutti i cloud privati e le subnet create in questa regione possono comunicare tra loro senza alcuna configurazione aggiuntiva. Puoi creare segmenti di rete (subnet) utilizzando NSX-T per le macchine virtuali (VM) del carico di lavoro.

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 dei confini 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 in NSX-T Manager per il cloud privato.

Subnet

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

Tutte le subnet possono comunicare tra loro per impostazione predefinita, riducendo l'overhead della configurazione per il routing tra cloud privato. I dati est-ovest nei cloud privati nella stessa regione rimangono nella stessa rete di livello 3 e vengono trasferiti sull'infrastruttura di rete locale all'interno della regione. Non è richiesto alcun traffico in uscita per la comunicazione tra cloud privati in una regione. Questo approccio elimina eventuali penalizzazioni in termini di prestazioni WAN/in 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 uplink VLAN a una rete esterna
  • NsxtEdgeUplink2: VLAN e subnet per uplink VLAN a una rete esterna
  • HCXUplink:utilizzato dalle appliance HCX IX (mobilità) e NE (estensione) per raggiungere i peer e consentire la creazione del mesh di servizi HCX.
  • NsxtHostTransport: VLAN e subnet per la zona di trasporto dell'host

Intervallo CIDR rete di deployment HCX

Quando crei un cloud privato in VMware Engine, HCX viene installato automaticamente nel cloud privato. Puoi specificare un intervallo CIDR di rete per l'utilizzo da parte dei componenti HCX. Il prefisso dell'intervallo CIDR deve essere /26 o /27.

La rete fornita è suddivisa in tre subnet. HCX Manager è installato nella subnet HCX management. La subnet HCX vMotion viene utilizzata per la vMotion di macchine virtuali tra l'ambiente on-premise e il cloud privato VMware Engine. La subnet HCX WANUplink viene utilizzata per stabilire il tunnel tra l'ambiente on-premise e il cloud privato VMware Engine.

Subnet di servizio

Quando crei un cloud privato, VMware Engine crea automaticamente subnet di servizio aggiuntive. Puoi scegliere come target subnet di servizio per scenari di deployment di appliance o servizi, come archiviazione, backup, ripristino di emergenza (RE), streaming di contenuti multimediali e fornitura di velocità effettiva lineare ad alta scalabilità e di elaborazione di pacchetti anche per i cloud privati con scalabilità maggiore. I nomi delle subnet di servizio sono i seguenti:

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

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

Configurazione delle subnet di servizio

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

Le subnet di servizio possono essere aggiornate se i requisiti CIDR cambiano. La modifica di un CIDR di una subnet di servizio esistente può causare l'interruzione della disponibilità della 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 di servizio a un nome di rete all'interno di un cloud privato vCenter.

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

Una volta creato il gruppo di porte distribuite, 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 dei gruppi di porte distribuite:

  • Port binding: associazione statica
  • Allocazione delle porte: elastica
  • Numero di porte: 120
  • Tipo VLAN: VLAN
  • ID VLAN: l'ID subnet corrispondente nella sezione subnet dell'interfaccia di 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 relativi alla frammentazione, consigliamo le seguenti impostazioni MTU.

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

Per le VM che comunicano da o verso un cloud privato senza incapsulamento, utilizza l'impostazione MTU standard a 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 da o verso un cloud privato con incapsulamento, calcola l'impostazione MTU migliore in base alle configurazioni degli endpoint VPN. In genere, questo determina un'impostazione MTU di 1350-1390 byte o inferiore per le interfacce VM che inviano traffico nei modi seguenti:

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

Questi suggerimenti sono particolarmente importanti nei casi in cui un'applicazione non sia in grado di controllare la dimensione massima del payload. Per ulteriori indicazioni sul calcolo dell'overhead di incapsulamento, consulta le seguenti risorse: