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-T 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-T Manager f�r Ihre private Cloud Netzwerksegmente erstellen.

Subnetze

Sie m�ssen im NSX-T 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�ts-) und NE (Erweiterung)-Appliances 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 k�nnen einen Netzwerk-CIDR-Bereich f�r die HCX-Komponenten angeben. Das CIDR-Bereichspr�fix muss /26 oder /27 sein.

Das bereitgestellte Netzwerk wird in drei Subnetze unterteilt. HCX Manager wird im Subnetz HCX-Verwaltung installiert. Das Subnetz HCX vMotion wird f�r vMotion bei virtuellen Maschinen zwischen Ihrer lokalen Umgebung und der privaten Cloud in VMware Engine verwendet. Das Subnetz HCX WANUplink wird zum Einrichten des Tunnels zwischen Ihrer lokalen Umgebung und der privaten Cloud in VMware Engine verwendet.

Dienstsubnetze

Wenn Sie eine private Cloud erstellen, erstellt VMware Engine automatisch zus�tzliche Dienstsubnetze. Sie k�nnen Dienst-Subnetze f�r Appliance- oder Dienstbereitstellungsszenarien wie Speicher, Sicherung, Notfallwiederherstellung, Medienstreaming und linearen Durchsatz und Paketverarbeitung in großem Maßstab für selbst die größten privaten Clouds verwenden. Die Namen der Dienstsubnetze lauten:

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

Die Kommunikation zwischen virtuellen Maschinen über ein Dienstsubnetz verlässt den VMware ESXi-Host direkt und wird in die Google Cloud-Netzwerkinfrastruktur geleitet. So ist eine schnelle Kommunikation möglich.

Dienstsubnetze konfigurieren

Wenn VMware Engine ein Dienstsubnetz erstellt, wird weder ein CIDR-Bereich noch ein 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. Bearbeiten Sie eines der Dienstsubnetze, um einen CIDR-Bereich und ein Präfix zuzuweisen.

Dienstsubnetze können aktualisiert werden, wenn sich die CIDR-Anforderungen ändern. Die Änderung eines vorhandenen Dienstsubnetze-CIDR kann zu einer Unterbrechung der Netzwerkverfügbarkeit für VMs führen, die an dieses Dienstsubnetz angehängt 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 in der vCenter-Benutzeroberfläche den Bereich „Netzwerkkonfiguration“ 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 den entsprechenden Namen in der Netzwerkkonfiguration der VM-Eigenschaften auswählen.

Die folgenden Konfigurationswerte sind für die verteilte Portgruppe kritisch:

  • Portbindung: statische Bindung
  • Portzuweisung: elastisch
  • Anzahl der Ports: 120
  • VLAN-Typ: VLAN
  • VLAN-ID: die entsprechende Subnetz-ID im Bereich für Subnetze der Google Cloud VMware Engine-Schnittstelle

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 privaten Cloud kommunizieren, k�nnen Sie MTU-Einstellungen mit bis zu 8.800�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

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: