Routing overlay e perimetrale NSX

La soluzione VMware su Google Cloud utilizza VMware NSX per fornire networking software-defined (SDN) e sicurezza per le macchine virtuali (VM) dei workload VMware Cloud Foundation (VCF). Questo documento descrive come il networking overlay NSX interagisce con l'underlay Virtual Private Cloud (VPC) diGoogle Cloud e confronta le architetture di routing tra i nodi NSX Edge e la tua rete VPC.

Panoramica di NSX in Google Cloud

Nella soluzione VMware, la rete VPC Google Cloud fornisce l'underlay fisico e virtualizzato per gli host ESXi bare metal (istanze Compute Engine z3-highmem-192-highlssd-metal) e le appliance di gestione. VMware NSX si trova sopra questo underlay per fornire una topologia di rete astratta per le VM dei workload VCF:

  • Incapsulamento overlay Geneve: gli host ESXi e i nodi NSX Edge stabiliscono interfacce Transport Endpoint (TEP) (vmk10 o vmk3) sulla subnet VPC NSX-TEP dedicata. Il traffico delle VM dei workload viene incapsulato in pacchetti Geneve (porta UDP 6081) e instradato tra i TEP host sull'underlay VPC Google Cloudutilizzando un'unità massima di trasmissione (MTU) di 8896 byte.
  • Indirizzamento IP disaccoppiato: le VM dei workload connesse ai segmenti di overlay NSX possono utilizzare intervalli di indirizzi IP arbitrari senza consumare indirizzi IP dalle subnet VPC Google Cloud sottostanti o raggiungere le quote IP delle subnet VPC.
  • Architettura di routing multilivello:
    • Gateway di livello 1 (T1): forniscono il routing est-ovest tra i segmenti di overlay, i servizi DHCP localizzati e le regole firewall del gateway.
    • Gateway di livello 0 (T0): forniscono il routing nord-sud tra l'ambiente di overlay NSX e la rete VPC Google Cloud sottostante.
  • Sicurezza distribuita: il firewall distribuito (DFW) NSX applica policy di microsegmentazione stateful direttamente alla scheda di interfaccia di rete virtuale (vNIC) di ogni VM del workload, indipendentemente dal segmento di overlay o dall'host ESXi su cui risiede la VM.

Topologia underlay e overlay

L'architettura di rete è divisa in due livelli distinti: l'underlay VPC Google Cloud e l'overlay VMware NSX, come mostrato nel seguente diagramma (fai clic per ingrandire):

Underlay VPCGoogle Cloud che ospita istanze Z3 e appliance VCF sotto l'overlay VMware NSX. Underlay VPCGoogle Cloud che ospita istanze Z3 e appliance VCF sotto l'overlay VMware NSX.

La tabella seguente riassume i componenti e le responsabilità di ogni livello di rete:

Livello di rete Componenti principali Responsabilità
Google Cloud Underlay VPC
  • Host ESXi bare metal (NIC principali e NIC dinamiche)
  • VM di gestione VCF (vCenter Server, SDDC Manager, cluster NSX Manager, VMware HCX)
  • Subnet VPC (Management, vSAN, vMotion, NSX-TEP, NSX-Uplink)
  • Bilanciatori del carico interni regionali e appliance router di Network Connectivity Center
  • Fornisce la raggiungibilità IP tra le porte VMkernel dell'host ESXi
  • Ospita le appliance del control plane VCF direttamente sulle subnet VPC
  • Trasporta i pacchetti Geneve incapsulati tra i TEP dell'host ESXi e i TEP di NSX Edge
  • Connette le reti on-premise, i VPC in peering e i serviziGoogle Cloud
Overlay SDN NSX
  • Cluster NSX Edge (router logici di livello 0 e livello 1)
  • Segmenti di overlay NSX
  • VM workload
  • NSX Distributed Firewall (DFW) e Gateway Firewall
  • Fornisce domini di livello 2 isolati e routing est-ovest per le VM dei workload
  • Annuncia i blocchi CIDR dei workload all'underlay VPC tramite i gateway Tier-0
  • Fornisce il bilanciamento del carico, il NAT e la sicurezza perimetrale nord-sud

Casi d'uso di architettura avanzata

Puoi strutturare le topologie NSX e VPC per supportare diversi requisiti di isolamento e multi-tenancy:

  • Domini workload consolidati in un unico VPC: esegui il deployment del dominio di gestione VCF e di uno o più domini workload VI all'interno di un'unica rete VPCGoogle Cloud . Ogni dominio del workload utilizza subnet vSAN, vMotion e NSX-TEP dedicate all'interno dello stesso VPC, condividendo o isolando i cluster NSX Edge per il routing nord-sud.
  • Mappature multi-VPC: connetti gateway NSX Tier-0 distinti o cluster NSX Edge separati a reti VPC Google Cloud isolate (ad esempio, VPC separati per workload di produzione, reti perimetrali e servizi condivisi). Questa topologia preserva i confini rigidi di firewall e routing a livello di VPC in Google Cloud , mantenendo al contempo la gestione centralizzata del ciclo di vita di VCF.

Routing NSX Edge

Per instradare il traffico tra i segmenti di overlay NSX e la tua rete VPC Google Cloud , le VM NSX Edge devono scambiare route o inoltrare pacchetti tramite la subnet VPC NSX-Uplink. Puoi configurare il routing nord-sud tra i gateway NSX di livello 0 e la tua rete VPC utilizzando una delle seguenti opzioni:

Opzione 1: routing statico VPC (attivo-standby)

In una topologia di routing statico, una coppia attiva-standby di nodi NSX Edge utilizza un indirizzo IP virtuale (VIP) mobile sulla subnet VPC NSX-Uplink preceduta da un bilanciatore del carico di rete passthrough interno regionale, come mostrato nel seguente diagramma (fai clic per ingrandire):

Route statiche VPC che indirizzano il traffico di overlay NSX tramite un bilanciatore del carico interno ai nodi NSX Edge attivi-standby. Route statiche VPC che indirizzano il traffico di overlay NSX tramite un bilanciatore del carico interno ai nodi NSX Edge attivi-standby.

  • Meccanismo di routing: crei route statiche personalizzate nella tabella di routing VPCGoogle Cloud che specificano i blocchi CIDR del workload di overlay NSX come destinazione e il VIP mobile di NSX Edge (o la regola di forwarding del bilanciatore del carico interno) come hop successivo.
  • Alta affidabilità: quando utilizzi un servizio di backend interno regionale con la policy ad alta affidabilità GARP_RA (o un trasferimento dell'intervallo IP alias), il traffico viene reindirizzato automaticamente al nodo NSX Edge in standby se il nodo Edge attivo non funziona.
  • Caso d'uso: ideale per deployment più piccoli o topologie di overlay statiche in cui i blocchi CIDR dei workload non cambiano di frequente e la larghezza di banda single-edge soddisfa i requisiti di throughput.

Opzione 2: routing BGP dinamico utilizzando l'appliance router di Network Connectivity Center (modalità attiva/attiva)

Per configurare lo scambio dinamico delle route e la scalabilità della larghezza di banda orizzontale, utilizza il peering BGP (Border Gateway Protocol) tra il gateway NSX Tier-0 e router Cloud utilizzando l'appliance router di Network Connectivity Center, come mostrato nel seguente diagramma (fai clic per ingrandire):

Peering del router Cloud su BGP con appliance router NSX Edge assegnate agli host Z3 tramite regole di affinità DRS. Peering del router Cloud su BGP con appliance router NSX Edge assegnate agli host Z3 tramite regole di affinità DRS.

  • Scambio dinamico di route: il gateway NSX Tier-0 annuncia automaticamente i blocchi CIDR dei segmenti di overlay NSX appena creati al router Cloud tramite BGP e apprende le route VPC e on-premise (0.0.0.0/0 o prefissi specifici) tramite annunci di route personalizzate. Questa architettura elimina gli aggiornamenti manuali delle route statiche VPC.
  • Scalabilità ECMP attivo-attivo: supporta il routing ECMP (Equal-Cost Multi-Path) su un massimo di otto nodi NSX Edge attivi per gateway Tier-0, scalando il throughput nord-sud e supportando il failover con BFD (Bidirectional Forwarding Detection).
  • Requisito di associazione edge-to-host: poiché una VM NSX Edge viene eseguita all'interno di un host ESXi, la sua interfaccia di uplink virtuale viene mappata a una NIC dinamica specifica nell'istanza Compute Engine bare metal sottostante. Per assicurarti che il router Cloud inoltri il traffico BGP e del piano dati all'host bare metal esatto in cui si trova ogni VM NSX Edge, devi configurare le regole di affinità di VMware Distributed Resource Scheduler (DRS) (regole di affinità VM-Host) per assegnare ogni VM NSX Edge all'host ESXi designato.
  • Sessioni BGP ridondanti: configura sessioni BGP doppie tra le interfacce di uplink di ogni nodo NSX Edge nella subnet NSX-Uplink e le interfacce router Cloud ridondanti per mantenere la disponibilità continua del control plane durante gli eventi di manutenzione dell'host.

Passaggi successivi