VLANs und Subnetze in VMware Engine

Google Cloud VMware Engine verwendet ein VMware Engine-Netzwerk,um eine Netzwerk verbindung zwischen einer oder mehreren privaten Clouds, Google Cloud Virtual Private Cloud Netzwerken und lokalen Netzwerken bereitzustellen. VMware Engine bietet zwei Netzwerktypen: Standard und Legacy. Standardnetzwerke sind die Standardeinstellung für Projekte, die im November 2023 oder danach erstellt wurden. Sie sind global und verwenden VPC-Netzwerk-Peering für die Verbindung. Legacy-Netzwerke sind nur in Projekten verfügbar, die vor November 2023 erstellt wurden. Sie sind regional und verwenden Private Service Access für die Verbindung. Weitere Informationen finden Sie unter VMware Engine-Netzwerke.

Unabhängig vom Netzwerktyp können Sie mit NSX-T Data Center Netzwerksegmente (Subnetze) für Ihre Arbeitslast-VMs erstellen.

VLANs und Subnetze

Verwaltungs-VLANs

Google erstellt für jede private Cloud ein VLAN (Layer-2-Netzwerk). Der Layer-2-Traffic bleibt innerhalb der Grenze einer privaten Cloud, sodass Sie den lokalen Traffic innerhalb der privaten Cloud isolieren können. Diese VLANs werden für die Verwaltung von Netzwerken verwendet. Für Arbeitslast-VMs müssen Sie im NSX Manager für Ihre private Cloud Netzwerksegmente erstellen.

Subnetze

Wenn Sie VMware Engine verwenden, erstellt Google Verwaltungssubnetze für Sie. Sie erstellen Arbeitslast-Subnetze mit NSX-T für Ihre Arbeitslast-VMs.

Arbeitslast-Subnetze

Für Ihre Arbeitslast-VMs müssen Sie im NSX Manager für Ihre private Cloud ein Netzwerksegment erstellen. Sie können jeden IP-Adressbereich konfigurieren, der sich nicht mit anderen Netzwerken in Ihrer privaten Cloud, Ihrem lokalen Netzwerk, Ihrem privaten Cloud-Verwaltungsnetzwerk oder Subnetz-IP-Adressbereichen in einem beliebigen VPC-Netzwerk (Virtual Private Cloud) überschneidet. Eine detaillierte Aufschlüsselung, wie VMware Engine Subnetz-IP-Adressbereiche für die Verwaltung zuweist, finden Sie unter Netzwerkanforderungen.

Innerhalb einer privaten Cloud können Arbeitslastnetzwerksegmente standardmäßig miteinander kommunizieren. Die Kommunikation zwischen privaten Clouds hängt vom VMware Engine-Netzwerktyp ab:

  • Standardnetzwerke:Die Kommunikation zwischen privaten Clouds erfolgt über VPC-Netzwerk-Peering und hängt von Ihrer VPC-Konfiguration ab.
  • Legacy-Netzwerke:East-West-Daten in privaten Clouds derselben Region bleiben im selben Layer-3-Netzwerk und werden über die lokale Netzwerkinfrastruktur innerhalb der Region übertragen.

Verwaltungs-Subnetze

Wenn Sie eine private Cloud erstellen, erstellt VMware Engine die folgenden Verwaltungssubnetze:

  • Systemverwaltung: VLAN und Subnetz für das Verwaltungsnetzwerk des ESXi-Hosts, DNS-Server, vCenter-Server
  • VMotion: VLAN und Subnetz für das vMotion-Netzwerk von ESXi-Hosts
  • VSAN: VLAN und Subnetz für das vSAN-Netzwerk von ESXi-Hosts
  • NsxtEdgeUplink1: VLAN und Subnetz für VLAN-Uplinks zu einem externen Netzwerk
  • NsxtEdgeUplink2:VLAN und Subnetz für VLAN-Uplinks zu einem externen Netzwerk
  • HCXUplink:Wird von HCX IX- (Mobilität) und NE-Appliances (Erweiterung) verwendet, um ihre Peers zu erreichen und die Erstellung des HCX Cloud Service Mesh zu ermöglichen.
  • NsxtHostTransport:VLAN und Subnetz für Host-Transport-Zone

Dienstsubnetze

Wenn Sie eine private Cloud erstellen, erstellt VMware Engine automatisch zusätzliche Dienstsubnetze. Sie können Dienstsubnetze für Bereitstellungsszenarien für Appliances oder Dienste verwenden, z. B. für Speicher, Sicherung, Notfallwiederherstellung, Medienstreaming sowie für einen hohen linearen Durchsatz und eine hohe Paketverarbeitung für auch die größten privaten Clouds. Die Namen der Dienstsubnetze sind:

  • service-1
  • service-2
  • service-3
  • service-4
  • service-5

Die Kommunikation zwischen VMs über ein Dienstsubnetz verlässt den VMware ESXi -Host direkt in die Google Cloud Netzwerkinfrastruktur, wodurch eine schnelle Kommunikation möglich ist.

Dienstsubnetze konfigurieren

Wenn VMware Engine ein Dienstsubnetz erstellt, wird kein CIDR-Bereich oder ‑Präfix zugewiesen. Sie müssen einen sich nicht überschneidenden CIDR-Bereich und ein Präfix angeben. Die erste verwendbare Adresse wird zur Gateway-Adresse. Wenn Sie einen CIDR-Bereich und ein Präfix zuweisen möchten, bearbeiten Sie eines der Dienstsubnetze.

Dienstsubnetze können aktualisiert werden, wenn sich die CIDR-Anforderungen ändern. Wenn Sie den CIDR eines vorhandenen Dienstsubnetzes ändern, kann dies zu einer Unterbrechung der Netzwerkverfügbarkeit für VMs führen, die mit diesem Dienstsubnetz verbunden sind.

Verteilte vSphere-Portgruppen konfigurieren

Wenn Sie eine VM mit einem Dienstsubnetz verbinden möchten, müssen Sie eine neue verteilte Portgruppe erstellen. Diese Gruppe ordnet die Dienstsubnetz-ID einem Netzwerknamen in einer privaten vCenter-Cloud zu.

Rufen Sie dazu den Abschnitt zur Netzwerkkonfiguration der vCenter-Oberfläche auf, wählen Sie Datacenter-dvs und dann Neue verteilte Portgruppe aus.

Nachdem die verteilte Portgruppe erstellt wurde, können Sie VMs anhängen, indem Sie in der Netzwerkkonfiguration der VM-Attribute den entsprechenden Namen auswählen.

Die folgenden Konfigurationswerte sind für verteilte Portgruppen entscheidend:

  • Portbindung: statische Bindung
  • Portzuweisung: elastisch
  • Anzahl der Ports: 120
  • VLAN-Typ: VLAN
  • VLAN-ID: die entsprechende Subnetz-ID im Abschnitt „Subnetze“ der Google Cloud VMware Engine-Oberfläche

Die maximale Übertragungseinheit (MTU) ist die Größe in Byte des größten Pakets, das von einem Netzwerkschichtprotokoll unterstützt wird, einschließlich Header und Daten. Um fragmentierungsbedingte Probleme zu vermeiden, empfehlen wir die folgenden MTU-Einstellungen:

  • Für VMs, die nur mit anderen Endpunkten innerhalb einer privaten Standard-Cloud kommunizieren, können Sie MTU-Einstellungen mit bis zu 8.800 Byte verwenden.

  • Für VMs, die nur mit anderen Endpunkten innerhalb einer erweiterten privaten Cloud kommunizieren, können Sie MTU-Einstellungen mit bis zu 8.600 Byte verwenden.

  • Verwenden Sie für VMs, die mit oder von einer privaten Cloud ohne Kapselung kommunizieren, die Standardeinstellung von 1.500 Byte MTU. Diese allgemeine Standardeinstellung ist für VM-Schnittstellen gültig, die Traffic so senden:

    • Von einer VM in einer privaten Cloud zu einer VM in einer anderen privaten Cloud
    • Von einem lokalen Endpunkt zu einer privaten Cloud
    • Von einer VM in einer privaten Cloud zu einem lokalen Endpunkt
    • Vom Internet zu einer privaten Cloud
    • Von einer VM in einer privaten Cloud zum Internet

  • Verwenden Sie für VMs, die mit oder aus dem Internet mit großen UDP-Trafficflüssen kommunizieren, die fragmentiert sind, eine MTU-Einstellung von mindestens 1.370 Byte. Diese Empfehlung gilt für die Kommunikation über öffentliche Verbindungen oder IP-Adressen, die von VMware Engine bereitgestellt werden. MSS Clamping löst generell Fragmentierungsprobleme bei TCP-basierten Trafficflüssen.

  • Berechnen Sie für VMs, die zu oder aus einer privaten Cloud mit Datenkapselung kommunizieren, die beste MTU-Einstellung auf der Grundlage von VPN-Endpunktkonfigurationen. Dies führt im Allgemeinen zu einer MTU-Einstellung von 1.350 bis 1.390 Byte oder weniger für VM-Schnittstellen, die Traffic auf folgende Weise senden:

    • Von einem lokalen Endpunkt zu einer privaten Cloud mit Datenkapselung
    • Von einer privaten Cloud-VM zu einem lokalen Endpunkt mit Datenkapselung
    • Von einer VM in einer privaten Cloud zu einer VM in einer anderen privaten Cloud mit Datenkapselung

Diese Empfehlungen sind besonders wichtig, wenn eine Anwendung die maximale Nutzlastgröße nicht steuern kann. Weitere Hinweise zur Berechnung des Datenkapselungs-Overheads finden Sie in den folgenden Ressourcen: