VLANs und Subnetze in VMware Engine

Google Cloud VMware Engine erstellt ein Netzwerk pro Region, in der Ihr VMware Engine-Dienst bereitgestellt wird. Das Netzwerk ist ein einzelner TCP-Layer-3-Adressbereich mit standardmäßig aktiviertem Routing. Alle in dieser Region erstellten privaten Clouds und Subnetze können ohne zusätzliche Konfiguration miteinander kommunizieren. Sie können mit NSX 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

Sie müssen im NSX Manager ein Netzwerksegment für Ihre private Cloud erstellen. Pro Kunde und Region wird ein einzelner privater Layer-3-Adressbereich zugewiesen. 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 Ihrem VPC-Netzwerk (Virtual Private Cloud) überschneidet. Eine detaillierte Aufschlüsselung, wie VMware Engine Subnetz-IP-Adressbereiche zuweist, finden Sie unter Netzwerkanforderungen.

Alle Subnetze können standardmäßig miteinander kommunizieren, was den Konfigurationsaufwand für das Routing zwischen privaten Clouds verringert. East-West-Daten in privaten Clouds derselben Region bleiben im selben Layer-3-Netzwerk und werden über die lokale Netzwerkinfrastruktur innerhalb der Region übertragen. Für die Kommunikation zwischen privaten Clouds in einer Region ist kein ausgehender Traffic erforderlich. Bei diesem Ansatz wird die Leistung eines WANs oder des ausgehenden Traffics bei der Bereitstellung verschiedener Arbeitslasten in unterschiedlichen privaten Clouds desselben Projekts nicht verringert.

Verwaltungssubnetze, die in einer privaten Cloud erstellt wurden

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 Service Mesh zu ermöglichen.
  • NsxtHostTransport: VLAN und Subnetz für Host-Transport-Zone

CIDR-Bereich des HCX-Bereitstellungsnetzwerks

Wenn Sie in VMware Engine eine private Cloud erstellen, wird HCX automatisch in der privaten Cloud installiert. Sie müssen keinen dedizierten CIDR-Bereich mehr für HCX-Komponenten angeben. Stattdessen weist VMware Engine automatisch den erforderlichen Netzwerkbereich für HCX-Komponenten (z. B. HCX Manager, vMotion und WAN-Uplink) aus dem Management-CIDR-Bereich zu, den Sie für Ihre private Cloud angeben.

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 und 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, was eine schnelle Kommunikation ermöglicht.

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 das 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 Dienst-Subnetz 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 Bereich für die Netzwerkkonfiguration der vCenter-Oberfläche auf, wählen Sie Datacenter-dvs und dann New Distributed Port Group (Neue verteilte Portgruppe) aus.

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

Im Folgenden sind die kritischen Konfigurationswerte für verteilte Portgruppen aufgeführt:

  • 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) gibt die Bytezahl des größten Pakets an, 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 Standard-Private 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 1.370 Byte oder weniger. 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: