NSX-Overlay- und Edge-Routing

Die VMware-Lösung in Google Cloud verwendet VMware NSX, um softwarebasiertes Netzwerk (SDN) und Sicherheit für Ihre VMware Cloud Foundation (VCF)-Arbeitslast-VMs bereitzustellen. In diesem Dokument wird beschrieben, wie das NSX-Overlay-Netzwerk mit demGoogle Cloud -VPC-Underlay (Virtual Private Cloud) interagiert. Außerdem werden die Routingarchitekturen zwischen NSX Edge-Knoten und Ihrem VPC-Netzwerk verglichen.

Übersicht über NSX in Google Cloud

In der VMware-Lösung stellt das VPC-Netzwerk Google Cloud die physische und virtualisierte Grundlage für Ihre Bare-Metal-ESXi-Hosts (Compute Engine-z3-highmem-192-highlssd-metal-Instanzen) und Verwaltungs-Appliances bereit. VMware NSX befindet sich über diesem Underlay, um eine abstrahierte Netzwerktopologie für Ihre VCF-Arbeitslast-VMs bereitzustellen:

  • Geneve-Overlay-Kapselung: ESXi-Hosts und NSX Edge-Knoten richten TEP-Schnittstellen (Transport Endpoint) (vmk10 oder vmk3) im dedizierten VPC-Subnetz NSX-TEP ein. Der Traffic der Arbeitslast-VMs wird in Geneve-Pakete (UDP-Port 6081) gekapselt und zwischen Host-TEPs über das VPC-Underlay von Google Cloudmit einer maximalen Übertragungseinheit (MTU) von 8896 Byte weitergeleitet.
  • Entkoppelte IP-Adressierung: Arbeitslast-VMs, die mit NSX-Overlay-Segmenten verbunden sind, können beliebige IP-Adressbereiche verwenden, ohne IP-Adressen aus den zugrunde liegenden Google Cloud VPC-Subnetzen zu verbrauchen oder VPC-Subnetz-IP-Kontingente zu erreichen.
  • Mehrstufige Routing-Architektur:
    • Tier-1-Gateways (T1): Bieten Ost-West-Routing zwischen Overlay-Segmenten, lokalisierten DHCP-Diensten und Gateway-Firewallregeln.
    • Tier-0-Gateways (T0): Bieten Nord-Süd-Routing zwischen der NSX-Overlay-Umgebung und dem zugrunde liegenden VPC-Netzwerk von Google Cloud .
  • Verteilte Sicherheit: Die NSX Distributed Firewall (DFW) erzwingt zustandsorientierte Mikrosegmentierungsrichtlinien direkt auf der virtuellen Netzwerkschnittstellenkarte (vNIC) jeder Arbeitslast-VM, unabhängig davon, auf welchem Overlay-Segment oder ESXi-Host sich die VM befindet.

Underlay- und Overlay-Topologie

Die Netzwerkarchitektur ist in zwei verschiedene Ebenen unterteilt: das Google Cloud VPC-Underlay und das VMware NSX-Overlay, wie im folgenden Diagramm dargestellt (zum Vergrößern klicken):

Google Cloud -VPC-Underlay, das Z3-Instanzen und VCF-Appliances unter dem VMware NSX-Overlay hostet. Google Cloud -VPC-Underlay, das Z3-Instanzen und VCF-Appliances unter dem VMware NSX-Overlay hostet.

In der folgenden Tabelle sind die Komponenten und Verantwortlichkeiten der einzelnen Netzwerkschichten zusammengefasst:

Netzwerkschicht Primäre Komponenten Verantwortlichkeiten
Google Cloud VPC-Underlay
  • Bare-Metal-ESXi-Hosts (primäre NICs und dynamische NICs)
  • VCF-Verwaltungs-VMs (vCenter Server, SDDC Manager, NSX Manager-Cluster, VMware HCX)
  • VPC-Subnetze (Management, vSAN, vMotion, NSX-TEP, NSX-Uplink)
  • Regionale interne Load Balancer und Network Connectivity Center-Router-Appliances
  • Bietet IP-Erreichbarkeit zwischen ESXi-Host-VMkernel-Ports
  • Hostet VCF-Steuerungsebenen-Appliances direkt in VPC-Subnetzen
  • Überträgt gekapselte Geneve-Pakete zwischen ESXi-Host-TEPs und NSX Edge-TEPs
  • Verbindet die lokalen Netzwerke, Peering-VPCs undGoogle Cloud-Dienste
NSX SDN-Overlay
  • NSX-Edge-Cluster (logische Tier-0- und Tier-1-Router)
  • NSX-Overlay-Segmente
  • Arbeitslast-VMs
  • NSX Distributed Firewall (DFW) und Gateway Firewall
  • Bietet isolierte Layer-2-Domains und Ost-West-Routing für Arbeitslast-VMs
  • Gibt Arbeitslast-CIDR-Blöcke über Tier-0-Gateways an das VPC-Underlay weiter
  • Bietet Load Balancing, NAT und Nord-Süd-Edge-Sicherheit

Anwendungsfälle für erweiterte Architektur

Sie können Ihre NSX- und VPC-Topologien so strukturieren, dass sie unterschiedliche Isolations- und Mehrmandantenanforderungen unterstützen:

  • Konsolidierte Arbeitslastdomains in einer einzelnen VPC: Stellen Sie Ihre VCF-Verwaltungsdomain und eine oder mehrere VI-Arbeitslastdomains in einem einzelnenGoogle Cloud VPC-Netzwerk bereit. Jede Arbeitslastdomain verwendet dedizierte vSAN-, vMotion- und NSX-TEP-Subnetze innerhalb derselben VPC, während NSX Edge-Cluster für das Nord-Süd-Routing freigegeben oder isoliert werden.
  • Multi-VPC-Zuordnungen: Verbinden Sie separate NSX-Tier-0-Gateways oder separate NSX-Edge-Cluster mit isolierten VPC-Netzwerken von Google Cloud (z. B. separate VPCs für Produktionsarbeitslasten, Umkreisnetzwerke und freigegebene Dienste). Bei dieser Topologie bleiben strenge Firewall- und Routinggrenzen auf VPC-Ebene in Google Cloud erhalten, während die zentrale VCF-Lebenszyklusverwaltung beibehalten wird.

NSX Edge-Routing

Damit Traffic zwischen NSX-Overlay-Segmenten und Ihrem Google Cloud VPC-Netzwerk weitergeleitet werden kann, müssen NSX Edge-VMs Routen austauschen oder Pakete über das VPC-SubnetzNSX-Uplink weiterleiten. Sie können das Nord-Süd-Routing zwischen NSX-Tier-0-Gateways und Ihrem VPC-Netzwerk mit einer der folgenden Optionen konfigurieren:

Option 1: Statisches VPC-Routing (Aktiv/Standby)

In einer statischen Routingtopologie verwendet ein Aktiv/Standby-Paar von NSX Edge-Knoten eine Floating Virtual IP-Adresse (VIP) im VPC-Subnetz NSX-Uplink, das von einem regionalen internen Passthrough-Network-Load-Balancer bereitgestellt wird, wie im folgenden Diagramm dargestellt (zum Vergrößern klicken):

Statische VPC-Routen, die NSX-Overlay-Traffic über einen internen Load Balancer an aktive/Standby-NSX-Edge-Knoten weiterleiten. Statische VPC-Routen, die NSX-Overlay-Traffic über einen internen Load Balancer an aktive/Standby-NSX-Edge-Knoten weiterleiten.

  • Routingmechanismus: Sie erstellen benutzerdefinierte statische Routen in IhrerGoogle Cloud -VPC-Routentabelle, die Ihre NSX-Overlay-Arbeitslast-CIDR-Blöcke als Ziel und die Floating-VIP von NSX Edge (oder die Weiterleitungsregel des internen Load Balancers) als nächsten Hop angeben.
  • Hochverfügbarkeit: Wenn Sie einen regionalen internen Backend-Dienst mit der Hochverfügbarkeitsrichtlinie GARP_RA (oder einer Alias-IP-Bereichsübergabe) verwenden, wird der Traffic automatisch an den Standby-NSX-Edge-Knoten weitergeleitet, wenn der aktive Edge-Knoten ausfällt.
  • Anwendungsfall: Am besten geeignet für kleinere Bereitstellungen oder statische Overlay-Topologien, bei denen sich die CIDR-Blöcke der Arbeitslasten nicht häufig ändern und die Bandbreite eines einzelnen Edge-Geräts Ihren Durchsatzanforderungen entspricht.

Option 2: Dynamisches BGP-Routing mit der Network Connectivity Center-Router-Appliance (Aktiv-Aktiv)

Wenn Sie den dynamischen Routenaustausch und die horizontale Bandbreitenskalierung konfigurieren möchten, verwenden Sie das Border Gateway Protocol (BGP)-Peering zwischen Ihrem NSX-Tier-0-Gateway und Cloud Router mithilfe der Network Connectivity Center-Router-Appliance, wie im folgenden Diagramm dargestellt (zum Vergrößern klicken):

Cloud Router-Peering über BGP mit NSX Edge-Router-Appliances, die durch DRS-Affinitätsregeln an Z3-Hosts gebunden sind. Cloud Router-Peering über BGP mit NSX Edge-Router-Appliances, die durch DRS-Affinitätsregeln an Z3-Hosts gebunden sind.

  • Dynamischer Routenaustausch: Das NSX-Tier-0-Gateway bewirbt neu erstellte NSX-Overlay-Segment-CIDR-Blöcke automatisch über BGP an Cloud Router und lernt VPC- und lokale Routen (0.0.0.0/0 oder bestimmte Präfixe) über benutzerdefinierte Route Advertisements. Bei dieser Architektur sind keine manuellen Aktualisierungen statischer VPC-Routen erforderlich.
  • Aktiv-Aktiv-ECMP-Skalierung: Unterstützt ECMP-Routing (Equal-Cost Multi-Path) über bis zu acht aktive NSX Edge-Knoten pro Tier-0-Gateway, skaliert den Nord-Süd-Durchsatz und unterstützt Failover mit Bidirectional Forwarding Detection (BFD).
  • Anforderung für das Edge-to-Host-Pinning: Da eine NSX Edge-VM auf einem ESXi-Host ausgeführt wird, wird ihre virtuelle Uplink-Schnittstelle einer bestimmten dynamischen NIC auf der zugrunde liegenden Bare-Metal-Compute Engine-Instanz zugeordnet. Damit der Cloud Router BGP- und Datenebenen-Traffic an den genauen Bare-Metal-Host weiterleitet, auf dem sich die einzelnen NSX Edge-VMs befinden, müssen Sie VMware Distributed Resource Scheduler-Affinitätsregeln (VM-Host-Affinitätsregeln) konfigurieren, um jede NSX Edge-VM an den dafür vorgesehenen ESXi-Host anzuhängen.
  • Redundante BGP-Sitzungen: Konfigurieren Sie duale BGP-Sitzungen zwischen den Uplink-Schnittstellen jedes NSX Edge-Knotens im Subnetz NSX-Uplink und redundanten Cloud Router-Schnittstellen, um die kontinuierliche Verfügbarkeit der Steuerungsebene während Hostwartungsereignissen aufrechtzuerhalten.

Nächste Schritte