VLAN e subnet su VMware Engine

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

VLAN e subnet.

VLAN di gestione

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

Subnet

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

Per impostazione predefinita, tutte le subnet possono comunicare tra loro, riducendo l'overhead di configurazione per il routing tra cloud privati. dati est-ovest i cloud privati nella stessa regione rimangono nella stessa rete di livello 3 dei trasferimenti sull'infrastruttura di rete locale all'interno della regione. Il traffico in uscita non è richiesta per la comunicazione tra cloud privati in una regione. Questo approccio elimina qualsiasi peggioramento delle prestazioni WAN/in uscita nel deployment di diversi carichi di lavoro in più cloud privati dello stesso progetto.

Subnet di gestione create su un cloud privato

Quando crei un cloud privato, VMware Engine crea quanto segue di gestione delle subnet:

  • Gestione del sistema: VLAN e sottorete per la rete di gestione degli host ESXi, server DNS, vCenter Server
  • VMotion: VLAN e subnet per host ESXi Rete vMotion
  • 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 rispettivi peer e consentire la creazione del mesh di servizi HCX.
  • NsxtHostTransport:VLAN e subnet per la zona di trasporto host

Intervallo CIDR rete di deployment HCX

Quando crei un cloud privato su VMware Engine, HCX viene installato automaticamente sul cloud privato. Puoi specificare un intervallo CIDR di rete da utilizzare dai componenti HCX. Il prefisso dell'intervallo CIDR deve essere /26 o /27.

La rete fornita è suddivisa in tre subnet. HCX Manager è installato in dalla subnet HCX management. La subnet HCX vMotion viene utilizzata per il vMotion delle VM 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 le sottoreti di servizio per scenari di implementazione di appliance o servizi, come archiviazione, backup, ripristino di emergenza (DR), streaming di contenuti multimediali e fornitura di velocità effettiva lineare e elaborazione di pacchetti su larga scala anche per i cloud privati più grandi. I nomi delle sottoreti di servizio sono i seguenti:

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

La comunicazione tra le macchine virtuali tramite una subnet di servizio esce dall'host VMware ESXi direttamente nell'infrastruttura di rete di 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 e un prefisso CIDR, modifica una delle subnet del servizio.

Le subnet di servizio possono essere aggiornate se i requisiti CIDR cambiano. La modifica del 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 di vCenter, seleziona Datacenter-dvs e seleziona Nuovo gruppo di porte distribuite.

Dopo aver 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 del gruppo di porte distribuite:

  • Port binding (Associazione di porte): associazione statica
  • Allocazione delle porte: elastica
  • Numero di porte: 120
  • Tipo VLAN: VLAN
  • ID VLAN: l'ID subnet corrispondente all'interno della sezione delle 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, sia intestazioni che dati. Per evitare problemi correlati alla frammentazione, consigliamo il metodo le seguenti impostazioni di MTU.

Per le VM che comunicano solo con altri endpoint all'interno di un cloud privato, possono utilizzare impostazioni di MTU fino a 8800 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 da o verso un cloud privato con incapsulamento, calcolare la migliore impostazione MTU in base alle configurazioni degli endpoint VPN. In genere, questo comporta un'impostazione MTU di 1350-1390 byte o inferiore per le interfacce VM che inviano 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 sia in grado di controllare la dimensione massima del payload. Per ulteriori indicazioni sul calcolo dell'overhead di incapsulamento, consulta le seguenti risorse: