Architektur

Dieses Dokument bietet eine Übersicht über die Architektur der VMware-Lösung in Google Cloud.

Die VMware-Lösung führt VMware Cloud Foundation (VCF) 9.1 auf dedizierten Compute Engine-Bare-Metal-Instanzen in Ihrem Google Cloud -Projekt aus. Die Bare-Metal-Instanzen stellen eine direkte Verbindung zu Ihrem VPC-Netzwerk (Virtual Private Cloud) her und verwenden lokale NVMe-SSDs für den VMware vSAN-Speicher.

Das folgende Diagramm zeigt die allgemeine Architektur der VMware-Lösung in einem Nutzerprojekt und wie sie einer VCF-Flotte zugeordnet wird (zum Vergrößern klicken):

Z3-Bare-Metal-Instanzen im VPC-Netzwerk eines Nutzerprojekts, die VCF-Verwaltungs- und Arbeitslastdomains zugeordnet sind. Z3-Bare-Metal-Instanzen im VPC-Netzwerk eines Nutzerprojekts, die VCF-Verwaltungs- und Arbeitslastdomains zugeordnet sind.

Abstimmung der Infrastrukturkomponenten

Die VMware-Lösung richtet die Google Cloud -Infrastrukturkonstrukte so an VCF-Komponenten aus:

  • Google Cloud -Nutzerprojekt und VPC-Netzwerk (Virtual Private Cloud): Dient als übergeordnete administrative Grenze, die Ihr VPC-Netzwerk, Ihre Subnetze, Firewallregeln und Rechenressourcen enthält.
  • Bare-Metal-Knoten und ESXi-Hosts: Dedizierte Bare-Metal-Instanzen von Compute Engine (z3-highmem-192-highlssd-metal) mit lokalen NVMe-SSDs, auf denen VMware ESXi ausgeführt wird.
  • Platzierungsrichtlinien und vSphere-Cluster: Mit den Richtlinien für verteilte Platzierung von Compute Engine wird die physische Verteilung von Instanzen innerhalb einer Zone gesteuert, um vSphere-Cluster vor lokalen Hardwarestörungen zu schützen.
  • Verfügbarkeitsdomains und vSAN-Fehlerdomains: Logische Ressourcengruppierungen innerhalb einer Zone, die eine physische Hardwareisolation bieten und 1:1 auf VMware vSAN-Fehlerdomains abgebildet werden.

In der folgenden Tabelle sind die unterstützten Compute Engine-Bare-Metal-Maschinentypen zusammengefasst:

Maschinentyp vCPUs (physische Kerne) Speicher (GiB) Lokaler NVMe-SSD-Speicher (TiB) Netzwerkbandbreite
z3-highmem-192-highlssd-metal 192 (96) 1.536 70,31 200 Gbit/s

Netzwerkarchitektur

Die VMware-Lösung stellt Bare-Metal-Hosts und Verwaltungs-Appliances direkt in Ihrem VPC-Netzwerk bereit, wie im folgenden Diagramm dargestellt (zum Vergrößern klicken):

Cloud DNS-Zonen, regionale interne Load Balancer, zonale NEGs und Layer-2-Subnetze, die Z3-Hosts verbinden. Cloud DNS-Zonen, regionale interne Load Balancer, zonale NEGs und Layer-2-Subnetze, die Z3-Hosts verbinden.

Underlay-VPC-Netzwerk und Schnittstellenzuordnung

Das Underlay-Netzwerk ordnet physische und virtuelle Schnittstellen zwischen Compute Engine und VMware ESXi so zu:

  • Zuordnung von Hardware- zu virtuellen Schnittstellen: Jeder Bare-Metal-Host stellt eine Verbindung über eine 200-Gbit/s-Netzwerkschnittstelle her. Compute Engine stellt diese Schnittstelle ESXi als primäre virtuelle Netzwerkschnittstelle (nic0) für nicht getaggten Verwaltungstraffic und dynamische Unterschnittstellen (nic0.2, nic0.3, nic0.4 und zusätzliche VLAN-Schnittstellen) für 802.1Q-VLAN-getaggten Traffic zur Verfügung.
  • Trafficsegmentierung: Der VMware Virtual Distributed Switch (VDS) trennt VMkernel-Ports über dedizierte regionale VPC-Subnetze, einschließlich vmk0 für die Verwaltung, vmk1 für vMotion, vmk2 für vSAN-Speicher und vmk10 (oder vmk3) für NSX-Tunnelendpunkte (TEPs).
  • Layer-2-Emulation und dynamisches MAC-Lernen: Bestimmte VPC-Subnetze fangen ARP- (Address Resolution Protocol) und GARP-Frames (Gratuitous ARP) ab. Diese Funktion programmiert die Andromeda-Datenebene von Google Cloud so, dass VMware-MAC-Adressen dynamisch gelernt und Layer-2-Broadcast-Domänen über Instanzen hinweg emuliert werden.

Weitere Informationen finden Sie unter Underlay-VPC-Netzwerk, Layer-2-MAC-Learning und DNS.

Load Balancing mit Hochverfügbarkeit für VCF-Appliances

Virtuelle Verwaltungs-Appliances werden auf dem VPC-Underlay ausgeführt und verwenden das Load Balancing von Google Cloudfür Hochverfügbarkeit:

  • Bereitstellung von Layer-3-Underlay-Appliances: Verwaltungs-Appliances, die direkten VPC-Zugriff erfordern, z. B. vCenter Server, SDDC Manager und geclusterte NSX Manager-Knoten, befinden sich direkt in Underlay-VPC-Subnetzen.
  • Fast IP Move (GARP_RA): Da ein geroutetes VPC-Netzwerk nicht auf das MAC-Learning physischer Switches angewiesen ist, verwendet die VMware-Lösung regionale interne Passthrough-Network-Load-Balancer und regionale Backend-Dienste, um vMotion-Mobilität und Failover zu unterstützen. Wenn eine Verwaltungs-Appliance zu einem anderen ESXi-Host migriert oder ein Failover ausführt, gibt die Appliance einen GARP-Frame aus und der Load Balancer leitet den Traffic der virtuellen IP-Adresse (VIP) sofort an die Ziel-Hostschnittstelle weiter.

Weitere Informationen finden Sie unter Hochverfügbarkeits-Load-Balancing für VCF-Appliances.

Overlay-Architektur und Nord-Süd-Routing

VMware NSX verwaltet das Arbeitslastnetzwerk und stellt über eines von zwei Routingmodellen eine Verbindung zum VPC-Underlay her:

  • Entkoppelte Overlay-Fabric: VMware NSX abstrahiert das Arbeitslastnetzwerk, indem der Gast-VM-Traffic in Geneve-Frames über Host-TEPs gekapselt wird. Durch diese Kapselung werden die IP-Adressbereiche der Arbeitslasten und die Richtlinien für verteilte Firewalls (DFW) vom VPC-Underlay entkoppelt.
  • Statisches VPC-Routing (Aktiv/Standby): Statische VPC-Routen leiten CIDR-Bereiche für Overlay-Arbeitslasten an eine freigegebene Floating-VIP weiter, die von einem regionalen internen Passthrough-Network-Load-Balancer bereitgestellt wird.
  • Dynamisches BGP-Routing mit Network Connectivity Center (aktiv-aktiv): Bis zu acht NSX-Tier-0-Edge-Knoten richten externe BGP-Peering-Sitzungen (eBGP) mit Cloud Router-Instanzen ein. Dazu wird das Router-Appliance-Modell von Network Connectivity Center verwendet. Dieses Design unterstützt ECMP-Routing (Equal-Cost Multi-Path) und den automatischen Präfixaustausch.

Weitere Informationen finden Sie unter NSX-Overlay und Edge-Routing.

Speicherarchitektur

Bare-Metal-Instanzen von Compute Engine enthalten direkt angehängte lokale NVMe-SSDs, die als physischer Speicher für Ihre hyperkonvergente Infrastruktur dienen. Jeder z3-highmem-192-highlssd-metal-Host stellt dedizierten lokalen NVMe-SSD-Speicher direkt für VMware ESXi bereit.

Sie verwenden VMware vSAN Express Storage Architecture (ESA) als primäre hyperkonvergente Speicherplattform. vSAN ESA ist für lokale NVMe-Flash-Geräte optimiert und unterstützt Komprimierung, Verschlüsselung und RAID-5/RAID-6-Erasure-Coding. Außerdem werden vSAN-Fehlerdomains 1:1 den Google Cloud -Verfügbarkeitsdomains in Ihrer Platzierungsrichtlinie zugeordnet, um die physische Fehlerisolation im gesamten Cluster aufrechtzuerhalten.

Zusätzlicher Datei- und Blockspeicher

Wenn Sie die Speicherkapazität unabhängig skalieren möchten, ohne Bare-Metal-Computing-Knoten hinzuzufügen, können Sie Ihre Umgebung so mit Google Cloud NetApp Volumes verbinden:

  • NFS-Datenspeicher: Stellen Sie NetApp Volumes-NFS-Volumes als zusätzliche vSphere-Datenspeicher mit Unterstützung für Volume-Snapshots, Klonen und Replikation bereit.
  • iSCSI-Blockspeicher: Hängen Sie NetApp Volumes-iSCSI-LUNs für Gastbetriebssysteme und Arbeitslastspeichererweiterungen an, indem Sie Multipathing über Ihr VPC-Netzwerk verwenden.

Nächste Schritte