Rete VPC underlay, apprendimento MAC di livello 2 e DNS

Questo documento descrive il networking Virtual Private Cloud (VPC) sottostante, l'emulazione di trasmissione di livello 2, la gestione degli indirizzi IP (IPAM) e l'architettura del Domain Name System (DNS) nella soluzione VMware su Google Cloud.

Nella soluzione VMware, il networking a livello di host mappa le interfacce VMkernel di VMware ESXi alle interfacce di rete virtuale (vNIC) principali e dinamiche di Compute Engine. Ogni host utilizza subnet Virtual Private Cloud (VPC) dedicate, tagging VLAN 802.1Q, apprendimento MAC di livello 2 e IPAM interno.

Subnet principali e segmentazione del traffico

Per isolare le classi di traffico di rete in VMware Cloud Foundation (VCF), devi eseguire il provisioning di subnet underlay dedicate, come mostrato nel seguente diagramma (fai clic per ingrandire):

Mappatura delle porte VMkernel ESXi dell'istanza Z3 tramite un Virtual Distributed Switch alle NIC principali e dinamiche. Mappatura delle porte VMkernel ESXi dell'istanza Z3 tramite un Virtual Distributed Switch alle NIC principali e dinamiche.

Un cluster VCF standard richiede almeno quattro subnet VPC dedicate, come mostrato nella tabella seguente:

Classe di subnet Tipo di traffico Mappatura VLAN Finalità
Gestione (MGMT) Controllo del sottostrato Nativo (senza tag) Trasporta il traffico di gestione degli host ESXi (vmk0) e ospita i nodi SDDC Manager, vCenter Server e NSX Manager.
vSAN Archiviazione Con tag (ad esempio, VLAN 2) Trasporta il traffico di replica dello spazio di archiviazione tra gli SSD NVMe locali di ESXi (vmk2).
vMotion Migrazione live Con tag (ad esempio, VLAN 3) Trasporta il traffico di migrazione live delle macchine virtuali tra gli host ESXi (vmk1).
NSX TEP TEP overlay Geneve Con tag (ad esempio VLAN 4) Trasporta il traffico di incapsulamento del tunnel di overlay Geneve host-to-host (vmk10).

Configurazione di NIC dinamiche e VLAN

Per segmentare più classi di traffico tra le interfacce host bare metal, Compute Engine utilizza NIC dinamiche (interfacce virtuali secondarie) associate all'interfaccia di rete principale:

  • Interfaccia principale (nic0): viene eseguito il provisioning sulla subnet di gestione non codificata. Questa interfaccia gestisce l'avvio iniziale dell'host, l'interfaccia utente della console diretta (DCUI) di ESXi e il traffico di gestione di vmk0.
  • Interfacce dinamiche (nic0.VLAN_ID): collegate all'interfaccia principale con metadati --vlan espliciti durante il provisioning dell'istanza e mappate alle subnet VPC corrispondenti.
  • Allineamento di VMware Virtual Distributed Switch (VDS): sull'host ESXi, i gruppi di porte sul VDS sono contrassegnati con ID VLAN 802.1Q corrispondenti. I frame in uscita contrassegnati dall'hypervisor vengono mappati direttamente all'interfaccia dinamica di Compute Engine corrispondente per l'inoltro attraverso la rete VPC.

Ridondanza della rete fisica

Sebbene le istanze bare metal di Compute Engine presentino una singola interfaccia di rete (nic0 / vmnic0) al sistema operativo host ESXi, questa singola interfaccia è un'astrazione fornita dal livello di networking software-defined (SDN) di Google Cloud .

Nell'infrastruttura fisica sottostante, i percorsi di rete sono ridondanti e utilizzano la connettività ottica multi-percorso nella struttura di switching del data center. Poiché il livello di trasporto fisico non si basa su hardware a percorso singolo, non è necessario configurare il NIC teaming a livello di hypervisor per la ridondanza del percorso fisico. Se si verifica un evento hardware a livello di host, la disponibilità del workload è protetta dai workflow di alta affidabilità (HA) e sostituzione dei nodi di vSphere.

Emulazione di livello 2: trasmissione ARP e apprendimento MAC personalizzato

Le istanze VM di Compute Engine standard utilizzano indirizzi MAC fissi, derivati in modo algoritmico (42:01:ac:...). Al contrario, gli host VMware ESXi, le porte VMkernel e le appliance virtuali generano indirizzi MAC personalizzati da intervalli di Organizationally Unique Identifier (OUI) VMware (come 00:50:56:... o 00:0c:29:...).

Per supportare in modo nativo gli indirizzi MAC VMware personalizzati e il traffico di trasmissione guest, la soluzione VMware richiede che le subnet della rete VPC abbiano la proprietà Risolvi subnet mask impostata su Trasmetti solo l'intervallo principale con apprendimento (--resolve-subnet-mask=ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING) per supportare il networking basato su VLAN. Per inserire nella lista consentita la connettività di rete di livello 2 per il tuo progetto, apri un ticket di assistenza nel Centro assistenza della consoleGoogle Cloud con le seguenti informazioni:

  • Prodotto: Google Cloud VMware Engine
  • Priorità: P2
  • Categoria: connettività di rete
  • Impatto aziendale: domanda tecnica generale
  • Fornisci maggiori dettagli: Allowlist L2 network connectivity for my project, oltre all'ID progetto, al numero di progetto e alla regione e alla zona di destinazione del deployment

Modalità di trasmissione della subnet

Compute Engine supporta le seguenti modalità di trasmissione ARP della subnet:

  • ARP_BROADCAST_PRIMARY_RANGE: trasmette query ARP e Gratuitous ARP (GARP) a tutte le istanze connesse alla subnet. L'istanza proprietaria dell'indirizzo IP di destinazione risponde direttamente.
  • ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING: obbligatorio per la soluzione VMware. Oltre alla trasmissione ARP, Google Cloud apprende e memorizza nella cache in modo dinamico le mappature da IP a MAC personalizzato. Quando viene appresa una mappatura, Google Cloud utilizza l'indirizzo MAC VMware personalizzato come indirizzo MAC di destinazione per il traffico inviato a quell'indirizzo IP. Se non esiste una mappatura personalizzata per l'indirizzo IP principale di un endpoint, Google Cloudutilizza l'indirizzo MAC predefinito assegnato da Google Cloud; i pacchetti inviati a qualsiasi altro indirizzo IP non mappato vengono ignorati.

Metodi di apprendimento MAC

Google Cloud compila e aggiorna la cache degli indirizzi MAC personalizzati utilizzando due meccanismi:

  • Gratuitous ARP (GARP): monitora la subnet per rilevare gli annunci GARP emessi dalle porte VMkernel ESXi e dalle appliance virtuali in fase di migrazione.
  • Sondaggio attivo: esegue il probe degli indirizzi IP nell'intervallo CIDR principale della subnet e utilizza le risposte ARP dell'host per compilare la cache MAC.

Vincoli e specifiche

Quando configuri le subnet con trasmissione ARP e apprendimento MAC, si applicano i seguenti vincoli:

  • Immutabilità: devi specificare il flag --resolve-subnet-mask quando crei la subnet. Non puoi modificare questa impostazione dopo aver creato la subnet.
  • Scopo della subnet e versione IP: supportato solo su subnet con uno scopo PRIVATE e intervalli CIDR solo IPv4.
  • Dimensionamento dell'intervallo principale: l'apprendimento MAC è supportato solo sugli intervalli CIDR IPv4 principali di /24 o inferiori (ad esempio /24, /25 o /26). L'apprendimento MAC non è supportato sugli intervalli CIDR secondari.
  • Quota di endpoint: le subnet con modalità di trasmissione abilitate supportano fino a 64 interfacce di rete VM connesse.
  • Quota di subnet di trasmissione: ogni rete VPC supporta fino a 64 subnet abilitate per la trasmissione per regione. Gli aumenti di quota non sono supportati per questo limite.
  • Limitazione delle richieste ARP: le richieste ARP e GARP che superano le 16 query al secondo (QPS) su una subnet con 64 istanze vengono ignorate per mantenere la stabilità del fabric.
  • Server DHCP e dei metadati: le richieste DHCP (Dynamic Host Configuration Protocol) inviate da indirizzi MAC personalizzati non sono supportate e vengono ignorate. Il server di metadati di Compute Engine espone solo gli indirizzi MAC predefiniti assegnati daGoogle Cloud, non gli indirizzi MAC appresi personalizzati.
  • Istanze target: le istanze target non possono fare riferimento a interfacce di rete in subnet con trasmissione ARP abilitata.
  • MTU VPC: imposta l'unità massima di trasmissione (MTU) della rete VPC su 8896 byte e configura VMware VDS, gli adattatori VMkernel e i profili NSX in modo che corrispondano a 8896 byte. Per saperne di più, vedi Problemi noti.

Per creare una subnet di gestione con trasmissione ARP, apprendimento MAC e accesso privato Google abilitato utilizzando Google Cloud CLI, esegui questo comando:

gcloud compute networks subnets create SUBNET_NAME \
    --network=VPC_NAME \
    --region=REGION \
    --range=SUBNET_RANGE \
    --resolve-subnet-mask=ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING \
    --enable-private-ip-google-access

Prima di eseguire il comando, sostituisci quanto segue:

  • SUBNET_NAME: il nome della nuova subnet VPC.
  • VPC_NAME: il nome della rete VPC di destinazione.
  • REGION: la regione Google Cloud in cui stai creando la subnet.
  • SUBNET_RANGE: l'intervallo CIDR IPv4 principale di /24 o inferiore (ad esempio, 10.200.0.0/24).

Gestione degli indirizzi IP (IPAM)

La soluzione VMware supporta tre metodi di allocazione degli indirizzi IP all'interno della tua rete VPC:

  • Temporaneo (automatico): concesso in leasing dinamicamente dal pool di subnet VPC e associato al ciclo di vita dell'istanza bare metal. Nota: durante l'attivazione e l'espansione del cluster VCF, il programma di installazione VCF ordina e assegna gli indirizzi IP vMotion e vSAN in sequenza. Preferisci allocazioni IP personalizzate o riservate per mantenere un ordinamento host-IP prevedibile. Per saperne di più, vedi Problemi noti.
  • Temporaneo (personalizzato): specificato esplicitamente dagli indirizzi non allocati nell'intervallo di subnet durante il provisioning dell'istanza o della NIC dinamica.
  • Indirizzi IP statici prenotati: oggetti indirizzo IP VPC allocati che rimangono prenotati nel progetto indipendentemente dallo stato dell'istanza. Utilizza indirizzi IP riservati per le interfacce host ESXi e le appliance di gestione mobili (VIP di vCenter Server, SDDC Manager e NSX Manager) per evitare conflitti di indirizzi IP durante gli eventi di manutenzione e failover.

Architettura DNS e risoluzione dei nomi

VCF richiede la risoluzione DNS in avanti (A) e inversa (PTR) per tutti gli host ESXi bare metal, le appliance virtuali di gestione e gli endpoint del cluster. I record DNS di inoltro o inversi mancanti o configurati in modo errato causano errori nei controlli di attivazione di SDDC Manager e di convalida dei certificati.

Risoluzione DNS underlay (host e appliance di gestione)

Configura la risoluzione DNS per gli host ESXi bare metal e le appliance di gestione ospitate nell'underlay (vCenter Server, SDDC Manager e NSX Manager) come segue:

  • Resolver interno di Cloud DNS (169.254.169.254): gli host ESXi e le VM di gestione dell'underlay possono eseguire query sul resolver DNS dei metadati Google Cloud (169.254.169.254) per risolvere le risorse Google Cloud e le zone private gestite in Cloud DNS.

  • Policy dei server DNS in entrata: se la tua organizzazione utilizza server DNS aziendali centralizzati su Cloud Interconnect o Cloud VPN, configura una policy dei server in entrata in Cloud DNS in una subnet standard (non broadcast di livello 2) all'interno del VPC. I nodi underlay possono eseguire query sugli indirizzi IP degli agenti di forwarding in entrata per risolvere sia i record Google Cloud privati sia i domini on-premise.

  • Zone inverse (PTR): crea zone di ricerca inversa private dedicate in Cloud DNS (ad esempio 0.200.10.in-addr.arpa. per la subnet di gestione 10.200.0.0/24) in modo che tutti i nomi di dominio completi (FQDN) dell'host ESXi e dell'appliance di gestione vengano risolti in entrambe le direzioni.

Risoluzione DNS della VM guest overlay

Il deployment delle macchine virtuali dei workload nell'overlay NSX viene eseguito in reti logiche incapsulate in Geneve, disaccoppiate dall'underlay VPC:

  • Server DNS aziendali o policy degli agenti di inoltro in entrata: configura le VM guest per eseguire query sui server DNS aziendali o sugli indirizzi IP statici della policy dei server in entrata di Cloud DNS raggiungibili tramite il gateway NSX Tier-0.
  • Vincolo dell'indirizzo dei metadati link-local: le VM guest nell'overlay NSX non possono eseguire query direttamente sul resolver dei metadati link-local (169.254.169.254) perché gli indirizzi link-local non vengono instradati attraverso i tunnel di overlay Geneve.

Passaggi successivi