Underlay-VPC-Netzwerk, Layer-2-MAC-Learning und DNS

In diesem Dokument werden die zugrunde liegende VPC-Netzwerkarchitektur (Virtual Private Cloud), die Layer-2-Broadcast-Emulation, die IP-Adressverwaltung (IPAM) und die DNS-Architektur (Domain Name System) in der VMware-Lösung auf Google Cloudbeschrieben.

In der VMware-Lösung werden VMware ESXi-VMkernel-Schnittstellen auf der Hostebene den primären und dynamischen virtuellen Netzwerkschnittstellen (vNICs) von Compute Engine zugeordnet. Jeder Host verwendet dedizierte VPC-Subnetze (Virtual Private Cloud), 802.1Q-VLAN-Tagging, Layer-2-MAC-Learning und internes IPAM.

Zentrale Subnetze und Trafficsegmentierung

Wenn Sie Netzwerkverkehrsklassen in VMware Cloud Foundation (VCF) isolieren möchten, müssen Sie dedizierte Underlay-Subnetze bereitstellen, wie im folgenden Diagramm dargestellt (zum Vergrößern klicken):

Z3-Instanz, die ESXi-VMkernel-Ports über einen Virtual Distributed Switch primären und dynamischen NICs zuordnet. Z3-Instanz, die ESXi-VMkernel-Ports über einen Virtual Distributed Switch primären und dynamischen NICs zuordnet.

Für einen Standard-VCF-Cluster sind mindestens vier dedizierte VPC-Subnetze erforderlich, wie in der folgenden Tabelle dargestellt:

Subnetzklasse Traffictyp VLAN-Zuordnung Zweck
Management (MGMT) Steuerung für Unterlage Nativ (nicht getaggt) Überträgt den Verwaltungs-Traffic des ESXi-Hosts (vmk0) und hostet SDDC Manager-, vCenter Server- und NSX Manager-Knoten.
vSAN Speicher Getaggt (z. B. VLAN 2) Überträgt den Speicherreplikations-Traffic zwischen lokalen ESXi-NVMe-SSDs (vmk2).
vMotion Live-Migration Getaggt (z. B. VLAN 3) Überträgt den Traffic der Live-Migration von virtuellen Maschinen zwischen ESXi-Hosts (vmk1).
NSX TEP Geneve-Overlay-TEP Getaggt (z. B. VLAN 4) Überträgt Host-zu-Host-Geneve-Overlay-Tunnelkapselungstraffic (vmk10).

Dynamische NIC- und VLAN-Konfiguration

Um mehrere Traffic-Klassen über Bare-Metal-Hostschnittstellen zu segmentieren, verwendet die Compute Engine dynamische NICs (virtuelle Unterschnittstellen), die mit der primären Netzwerkschnittstelle verknüpft sind:

  • Primäre Schnittstelle (nic0): Wird im nicht getaggten Verwaltungssubnetz bereitgestellt. Diese Schnittstelle verarbeitet den ersten Host-Boot, die ESXi Direct Console Benutzeroberfläche (DCUI) und den vmk0-Verwaltungstraffic.
  • Dynamische Schnittstellen (nic0.VLAN_ID): Werden während der Instanzbereitstellung mit expliziten --vlan-Metadaten an die primäre Schnittstelle angehängt und den entsprechenden VPC-Subnetzen zugeordnet.
  • VMware Virtual Distributed Switch (VDS)-Ausrichtung: Auf dem ESXi-Host werden Portgruppen auf dem VDS mit übereinstimmenden 802.1Q-VLAN-IDs getaggt. Ausgehende Frames, die vom Hypervisor getaggt wurden, werden direkt der entsprechenden dynamischen Compute Engine-Schnittstelle zugeordnet, um sie über das VPC-Netzwerk weiterzuleiten.

Physische Netzwerkredundanz

Obwohl Bare-Metal-Instanzen der Compute Engine dem ESXi-Hostbetriebssystem eine einzelne Netzwerkschnittstelle (nic0 / vmnic0) präsentieren, ist diese einzelne Schnittstelle eine Abstraktion, die von der softwaredefinierten Netzwerkschicht (SDN) von Google Cloud bereitgestellt wird.

In der zugrunde liegenden physischen Infrastruktur sind Netzwerkpfade redundant und verwenden optische Multipfad-Konnektivität in die Switching-Fabric des Rechenzentrums. Da die physische Transportschicht nicht auf Single-Path-Hardware angewiesen ist, müssen Sie kein NIC-Teaming auf Hypervisorebene für die Redundanz physischer Pfade konfigurieren. Wenn ein Hardwareereignis auf Hostebene auftritt, wird die Verfügbarkeit der Arbeitslast durch vSphere-Hochverfügbarkeit (HA) und Workflows zum Ersetzen von Knoten geschützt.

Layer-2-Emulation: ARP-Broadcasting und benutzerdefiniertes MAC-Lernen

Standard-Compute Engine-VM-Instanzen verwenden feste, algorithmisch abgeleitete MAC-Adressen (42:01:ac:...). Im Gegensatz dazu generieren VMware ESXi-Hosts, VMkernel-Ports und virtuelle Appliances benutzerdefinierte MAC-Adressen aus VMware-OUI-Bereichen (Organizationally Unique Identifier) wie 00:50:56:... oder 00:0c:29:....

Damit benutzerdefinierte VMware-MAC-Adressen und Gast-Broadcast-Traffic nativ unterstützt werden, muss für die Subnetze Ihres VPC-Netzwerk die Eigenschaft Subnetzmaske auflösen auf Nur primären Bereich mit Lernen übertragen (--resolve-subnet-mask=ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING) festgelegt sein, um VLAN-basiertes Netzwerk zu unterstützen. Wenn Sie die Layer-2-Netzwerkverbindung für Ihr Projekt auf die Zulassungsliste setzen möchten, öffnen Sie im Google Cloud Console-Supportcenter ein Support-Ticket mit den folgenden Informationen:

  • Produkt: Google Cloud VMware Engine
  • Priorität: P2
  • Kategorie: Network Connectivity
  • Auswirkungen auf das Geschäft: Allgemeine technische Frage
  • Geben Sie weitere Details an: Allowlist L2 network connectivity for my project, zusammen mit Ihrer Projekt-ID, Projektnummer und der Zielregion und -zone für Ihre Bereitstellung.

Subnetz-Broadcast-Modi

Compute Engine unterstützt die folgenden ARP-Broadcast-Modi für Subnetze:

  • ARP_BROADCAST_PRIMARY_RANGE: Sendet ARP- und Gratuitous ARP-Abfragen (GARP) an alle Instanzen, die mit dem Subnetz verbunden sind. Die Instanz, die die Ziel-IP-Adresse besitzt, antwortet direkt.
  • ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING: Erforderlich für die VMware-Lösung. Zusätzlich zum ARP-Broadcasting lernt und speichert Google Clouddynamisch Zuordnungen von IP- zu benutzerdefinierten MAC-Adressen. Wenn eine Zuordnung gelernt wird, verwendet Google Cloud die benutzerdefinierte VMware-MAC-Adresse als MAC-Zieladdresse für Traffic, der an diese IP-Adresse gesendet wird. Wenn für die primäre IP-Adresse eines Endpunkts keine benutzerdefinierte Zuordnung vorhanden ist, greift Google Cloudauf die standardmäßig von Google Cloudzugewiesene MAC-Adresse zurück. Pakete, die an andere nicht zugeordnete IP-Adressen gesendet werden, werden verworfen.

MAC-Lernmethoden

Google Cloud füllt und aktualisiert den benutzerdefinierten MAC-Adress-Cache mithilfe von zwei Mechanismen:

  • Gratuitous ARP (GARP): Überwacht das Subnetz auf GARP-Ankündigungen, die von ESXi-VMkernel-Ports und migrierenden virtuellen Appliances ausgegeben werden.
  • Aktives Prüfen: Prüft IP-Adressen im primären CIDR-Bereich des Subnetzes und verwendet Host-ARP-Antworten, um den MAC-Cache zu füllen.

Einschränkungen und Spezifikationen

Wenn Sie Subnetze mit ARP-Broadcasting und MAC-Learning konfigurieren, gelten die folgenden Einschränkungen:

  • Unveränderlichkeit: Sie müssen das Flag --resolve-subnet-mask angeben, wenn Sie das Subnetz erstellen. Diese Einstellung kann nach dem Erstellen des Subnetzes nicht mehr geändert werden.
  • Subnetzzweck und IP-Version: Wird nur in Subnetzen mit dem Zweck PRIVATE und reinen IPv4-CIDR-Bereichen unterstützt.
  • Größe des primären Bereichs: MAC-Learning wird nur für primäre IPv4-CIDR-Bereiche von /24 oder kleiner (z. B. /24, /25 oder /26) unterstützt. MAC-Learning wird für sekundäre CIDR-Bereiche nicht unterstützt.
  • Endpunktkontingent: Subnetze mit aktiviertem Broadcast-Modus unterstützen bis zu 64 verbundene VM-Netzwerkschnittstellen.
  • Kontingent für Broadcast-Subnetze: Jedes VPC-Netzwerk unterstützt bis zu 64 Broadcast-fähige Subnetze pro Region. Kontingenterhöhungen werden für dieses Limit nicht unterstützt.
  • Drosselung von ARP-Anfragen: ARP- und GARP-Anfragen, die 16 Abfragen pro Sekunde (QPS) in einem Subnetz mit 64 Instanzen überschreiten, werden verworfen, um die Fabric-Stabilität aufrechtzuerhalten.
  • DHCP- und Metadatenserver: DHCP-Anfragen (Dynamic Host Configuration Protocol), die von benutzerdefinierten MAC-Adressen gesendet werden, werden nicht unterstützt und verworfen. Der Compute Engine-Metadatenserver stellt nur standardmäßige, vonGoogle Cloudzugewiesene MAC-Adressen bereit, keine benutzerdefinierten gelernten MAC-Adressen.
  • Zielinstanzen: Zielinstanzen können nicht auf Netzwerkschnittstellen in Subnetzen verweisen, für die ARP-Broadcast aktiviert ist.
  • VPC-MTU: Legen Sie die maximale Übertragungseinheit (MTU) Ihres VPC-Netzwerk auf 8896 Byte fest und konfigurieren Sie Ihre VMware-VDS, VMkernel-Adapter und NSX-Profile so, dass sie 8896 Byte entsprechen. Weitere Informationen finden Sie unter Bekannte Probleme.

Führen Sie den folgenden Befehl aus, um ein Verwaltungssubnetz mit ARP-Broadcasting, MAC-Learning und aktiviertem privater Google-Zugriff mithilfe der Google Cloud CLI zu erstellen:

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

Ersetzen Sie vor dem Ausführen des Befehls Folgendes:

  • SUBNET_NAME: Der Name des neuen VPC-Subnetzes.
  • VPC_NAME: Der Name des Ziel-VPC-Netzwerk.
  • REGION: Die Google Cloud -Region, in der Sie das Subnetz erstellen.
  • SUBNET_RANGE: Der primäre IPv4-CIDR-Bereich von /24 oder kleiner (z. B. 10.200.0.0/24).

IP-Adressverwaltung (IPAM)

Die VMware-Lösung unterstützt drei Methoden zur IP-Adresszuweisung in Ihrem VPC-Netzwerk:

  • Sitzungsspezifisch (automatisch): Wird dynamisch aus dem VPC-Subnetzpool geleast und an den Lebenszyklus der Bare-Metal-Instanz gebunden. Hinweis: Während der Bereitstellung und Erweiterung des VCF-Clusters sortiert das VCF-Installationsprogramm vMotion- und vSAN-IP-Adressen und weist sie sequenziell zu. Bevorzugen Sie benutzerdefinierte oder reservierte IP-Zuweisungen, um eine vorhersehbare Host-zu-IP-Reihenfolge beizubehalten. Weitere Informationen finden Sie unter Bekannte Probleme.
  • Sitzungsspezifisch (benutzerdefiniert): Wird während der Bereitstellung der Instanz oder der dynamischen NIC explizit aus nicht zugewiesenen Adressen im Subnetzbereich angegeben.
  • Reservierte statische IP-Adressen: Zugewiesene VPC-IP-Adressobjekte, die unabhängig vom Instanzstatus in Ihrem Projekt reserviert bleiben. Verwenden Sie reservierte IP-Adressen für ESXi-Hostschnittstellen und Floating-Verwaltungs-Appliances (vCenter Server, SDDC Manager und NSX Manager-VIPs), um IP-Adresskonflikte während Wartungs- und Failover-Ereignissen zu vermeiden.

DNS-Architektur und Namensauflösung

VCF erfordert eine Forward- (A) und Reverse-DNS-Auflösung (PTR) für alle Bare-Metal-ESXi-Hosts, virtuellen Verwaltungs-Appliances und Clusterendpunkte. Fehlende oder falsch konfigurierte Forward- oder Reverse-DNS-Einträge führen dazu, dass die SDDC Manager-Aktivierung und die Zertifikatsvalidierungsprüfungen fehlschlagen.

DNS-Auflösung für die zugrunde liegende Infrastruktur (Hosts und Management Appliances)

Konfigurieren Sie die DNS-Auflösung für Bare-Metal-ESXi-Hosts und auf der zugrunde liegenden Infrastruktur gehostete Verwaltungs-Appliances (vCenter Server, SDDC Manager und NSX Manager) so:

  • Interner Cloud DNS-Resolver (169.254.169.254): Underlay-ESXi-Hosts und Verwaltungs-VMs können den DNS-Resolver für Google Cloud -Metadaten (169.254.169.254) abfragen, um in Cloud DNS verwaltete Google Cloud -Ressourcen und private Zonen aufzulösen.

  • DNS-Serverrichtlinien für eingehenden Traffic: Wenn Ihre Organisation zentrale Unternehmens-DNS-Server über Cloud Interconnect oder Cloud VPN verwendet, konfigurieren Sie eine Serverrichtlinie für eingehenden Traffic in Cloud DNS in einem Standardsubnetz (kein Layer-2-Broadcast) in Ihrer VPC. Underlay-Knoten können die IP-Adressen der eingehenden Weiterleitung abfragen, um sowohl private Google Cloud -Einträge als auch lokale Domains aufzulösen.

  • Reverse-Zonen (PTR): Erstellen Sie dedizierte private Reverse-Lookup-Zonen in Cloud DNS (z. B. 0.200.10.in-addr.arpa. für das Verwaltungssubnetz 10.200.0.0/24), damit alle FQDNs von ESXi-Hosts und Verwaltungs-Appliances in beide Richtungen aufgelöst werden.

DNS-Auflösung für Overlay-Gast-VMs

In der NSX-Overlay-Struktur bereitgestellte Arbeitslast-VMs befinden sich in Geneve-gekapselten logischen Netzwerken, die von der VPC-Underlay-Struktur entkoppelt sind:

  • Unternehmens-DNS-Server oder Richtlinien für eingehende Weiterleitungen: Konfigurieren Sie Gast-VMs so, dass sie Ihre Unternehmens-DNS-Server oder die statischen IP-Adressen Ihrer Cloud DNS-Serverrichtlinie für eingehenden Traffic abfragen, die über das NSX-Tier-0-Gateway erreichbar sind.
  • Einschränkung für link-lokale Metadatenadressen: Gast-VMs im NSX-Overlay können den link-lokalen Metadaten-Resolver (169.254.169.254) nicht direkt abfragen, da link-lokale Adressen nicht über Geneve-Overlay-Tunnel weitergeleitet werden.

Nächste Schritte