vSphere-Netzwerkdesign für VMware Cloud Foundation

VMware Cloud Foundation verwendet vSphere Distributed Switch für virtuelle Netzwerke.

Logisches vSphere-Netzwerkdesign für VMware Cloud Foundation

Berücksichtigen Sie beim Entwurf des vSphere-Netzwerks die Konfiguration der vSphere Distributed Switches, verteilten Portgruppen und VMkernel-Adapter in der VMware Cloud Foundation-Umgebung.

vSphere Distributed Switch-Design

Der Standardcluster in einer Arbeitslastdomäne verwendet einen einzelnen vSphere Distributed Switch mit einer Konfiguration für die Datenverkehrsarten des Systems, Systemdatenverkehrstypen, NIC-Gruppierung und MTU-Größe.

VMware Cloud Foundation unterstützt NSX-Overlay-Datenverkehr über einen einzelnen vSphere Distributed Switch pro Cluster. Zusätzliche Distributed Switches werden für andere Datenverkehrstypen unterstützt.

Bei Verwendung von vSAN ReadyNodes müssen Sie die Anzahl der vSphere Distributed Switches zur Bereitstellungszeit der Arbeitslastdomäne definieren. Nach der Bereitstellung können Sie keine weiteren vSphere Distributed Switches mehr hinzufügen.

Tabelle 1. Konfigurationsoptionen für vSphere Distributed Switch für VMware Cloud Foundation

vSphere Distributed Switch-Konfiguration	Optionen der Verwaltungsdomänen	Optionen der VI-Arbeitslastdomäne	Vorteile	Nachteile
Einzelner vSphere Distributed Switch für Hosts mit zwei physischen Netzwerkkarten	Ein vSphere Distributed Switch für jeden Cluster, wobei der gesamte Datenverkehr zwei Uplinks verwendet.	Ein vSphere Distributed Switch für jeden Cluster, wobei der gesamte Datenverkehr zwei Uplinks verwendet.	Erfordert eine Mindestanzahl an physischen Netzwerkkarten und Switch-Ports.	Für den gesamten Datenverkehr werden dieselben beiden Uplinks verwendet.
Einzelner vSphere Distributed Switch für Hosts mit vier oder sechs physischen Netzwerkkarten	Ein vSphere Distributed Switch für jeden Cluster mit vier Uplinks bei Verwendung der vordefinierten Profile im Workbook „Bereitstellungsparameter“ in VMware Cloud Builder zur Bereitstellung des Standardverwaltungsclusters. Ein vSphere Distributed Switch für jeden Cluster mit vier oder sechs Uplinks bei Verwendung der VMware Cloud Builder-API zum Bereitstellen des Standardverwaltungsclusters.	Ein vSphere Distributed Switch für jeden Cluster mit vier oder sechs Uplinks.	Bietet Unterstützung für die Trennung des Datenverkehrs über verschiedene Uplinks hinweg.	Sie müssen zusätzliche physische Netzwerkkarten und Switch-Ports zur Verfügung stellen.
Mehrere vSphere Distributed Switches	Maximal zwei vSphere Distributed Switches bei Verwendung der vordefinierten Profile im Workbook „Bereitstellungsparameter“ in VMware Cloud Builder zur Bereitstellung des Standardverwaltungsclusters. Maximal 16 vSphere Distributed Switches pro Cluster. Sie verwenden die VMware Cloud Builder-API, um den Standardverwaltungscluster mithilfe von Kombinationen aus vSphere Distributed Switches und Konfigurationen physischer Netzwerkkarten bereitzustellen, die im Workbook „Bereitstellungsparameter“ nicht als vordefinierte Profile verfügbar sind. Sie können nur einen der vSphere Distributed Switches für NSX-Overlay-Datenverkehr verwenden.	Maximal 16 vSphere Distributed Switches pro Cluster. Sie können nur einen der vSphere Distributed Switches für NSX-Overlay-Datenverkehr verwenden.	Bietet Unterstützung für die Trennung des Datenverkehrs über verschiedene Uplinks oder vSphere Distributed Switches hinweg. Bietet Unterstützung für die Trennung des Datenverkehrs in verschiedenen physischen Netzwerk-Fabrics.	Sie müssen zusätzliche physische Netzwerkkarten und Switch-Ports zur Verfügung stellen. Komplexer mit zusätzlichem Konfigurations- und Verwaltungsaufwand.

Design der verteilten Portgruppe

VMware Cloud Foundation benötigt mehrere Portgruppen auf dem vSphere Distributed Switch für eine Arbeitslastdomäne. Die VMkernel-Netzwerkadapter für die NSX-Host-TEPs sind mit dem Host-Overlay-Netzwerk verbunden, benötigen jedoch keine dedizierte Portgruppe auf dem Distributed Switch. Der VMkernel-Netzwerkadapter für NSX-Host-TEP wird automatisch erstellt, wenn VMware Cloud Foundation den ESXi-Host als NSX-Transportknoten konfiguriert.

Tabelle 2. Konfiguration der verteilten Portgruppe für VMware Cloud Foundation

Funktion	Teaming-Richtlinie	Konfiguration
VM-Verwaltung Hostverwaltung vSphere vMotion vSAN NFS (nicht anwendbar für den Standardcluster der Verwaltungsdomäne)	Anhand der physischen Netzwerkkartenauslastung routen.	Empfohlen.
	Failover-Erkennung: Nur Verbindungsstatus Failback: Ja Tritt nur bei Sättigung des aktiven Uplinks auf. Switch-Benachrichtigung: Ja	Empfohlen.
Host-Overlay	Nicht zutreffend.	Nicht zutreffend.
Edge-Uplinks und Overlay	Explizite Failover-Reihenfolge verwenden.	Erforderlich.
Edge-RTEP (nur NSX-Verbund)	Nicht zutreffend.	Nicht zutreffend.

Design des VMkernel-Netzwerkadapters

Die VMkernel-Netzwerkschicht bietet Konnektivität für Hosts und verarbeitet den Systemdatenverkehr für Verwaltung, vSphere vMotion, vSphere HA, vSAN, NFS usw.

Tabelle 3. VMkernel-Adapter für Arbeitslast-Domänenhosts

VMkernel-Adapterdienst	Verbundene Portgruppe	Aktivierte Dienste	Empfohlene MTU-Größe (Byte)
Management	Verwaltungsportgruppe	Verwaltungsdatenverkehr	1500 (Standard)
vMotion	vMotion-Portgruppe	vMotion-Datenverkehr	9000
vSAN	vSAN-Portgruppe	vSAN	9000
NFS	NFS-Portgruppe	NFS	9000
Host-TEPs	Nicht anwendbar	Nicht anwendbar	9000

Datenpfadmodi in vSphere Distributed Switch

vSphere Distributed Switch unterstützt drei Datenpfadmodi: „Standarddatenpfad“, „Erweiterter Datenpfad-Interrupt“ und „Erweiterter Datenpfad“. Beim Modus „Datenpfad“ handelt es sich um einen Netzwerk-Stack-Modus, der auf einem vSphere Distributed Switch konfiguriert wird, wenn während der Installation von NSX in einem ESXi-Cluster ein NSX-Transportknotenprofil angewendet wird. Jeder Datenpfadmodus weist Leistungsmerkmale auf, die für eine bestimmte Arbeitslast geeignet sind, die im Cluster ausgeführt wird. Die folgende Tabelle enthält Details zu den verschiedenen in VMware Cloud Foundation verfügbaren Modi sowie empfohlene Typen von Cluster-Arbeitslasten für jeden Modus.

Tabelle 4. Datenpfadmodi für VMware Cloud Foundation

Name des Datenpfadmodus	Beschreibung	Anwendungsfälle	Anforderungen
Standard	Der Standarddatenpfad wird standardmäßig installiert. Er wurde für Anwendungen mit großen Flows entwickelt. Die CPU-Nutzung im Standarddatenpfad ist bedarfsgesteuert. Für Anwendungen mit hohen Anforderungen an die Paketverarbeitung, wie z. B. NSX Edge, muss der Standarddatenpfad deutlich optimiert werden.	Arbeitslastdomänen oder -cluster berechnen	Die Kombination aus Treiber und Firmware muss im VMware-Kompatibilitätshandbuch für E/A-Geräte enthalten sein und die folgenden Funktionen unterstützen: Geneve-Offload Geneve Rx/Tx-Filter oder RSS
Erweiterter Datenpfad-Interrupt (Wird als Erweiterter Datenpfad – Standard auf der NSX Manager-Benutzeroberfläche bezeichnet)	Der Modus „Erweiterter Datenpfad-Interrupt“ ist ein leistungsorientierter Datenpfad, der die Flexibilität der bedarfsgesteuerten CPU-Nutzung des vorhandenen Standarddatenpfads und DPDK-ähnliche Funktionen (Data Plane Development Kit) für die Leistung kombiniert. In diesem Modus wird die Kernnutzung für die Paketverarbeitung je nach Bedarf automatisch hoch- und herunterskaliert. „Erweiterter Datenpfad-Interrupt“ verfügt über bewährte Leistungsmerkmale, insbesondere für kleinere Flows, die sich hauptsächlich auf die Paketverarbeitung konzentrieren, wie z. B. NSX Edge, ohne dass zusätzliche Optimierung erforderlich ist.	vSphere-Cluster, auf denen NSX Edge-Knoten ausgeführt werden	Die Kombination aus Treiber und Firmware muss im VMware-Kompatibilitätshandbuch für E/A-Geräte mit „Erweiterter Datenpfad – Unterstützung für Interrupt-Modus“ enthalten sein
Erweiterter Datenpfad (Wird als Erweiterter Datenpfad – Leistung auf der NSX Manager-Benutzeroberfläche bezeichnet)	Der Modus „Erweiterter Datenpfad“ ist ein leistungsorientierter Datenpfad, der DPDK-ähnliche Leistungsfunktionen nutzt, einschließlich dedizierter CPU-Kerne für die Verarbeitung von Netzwerkdatenpfaden. Dieser Modus eignet sich hervorragend für Arbeitslasten, bei denen die Datenverkehrsmuster und die Leistungsanforderungen genau definiert sind. Dieser Modus ist in Bezug auf die Kernzuteilung festgelegt, und eine automatische bedarfsgesteuerte Skalierung nach unten oder oben findet nicht statt. Die dem Datenpfad zugewiesenen Kerne stehen für Arbeitslasten auch dann nicht zur Verfügung, wenn kein Netzwerkdatenverkehr vorhanden ist. Es besteht die Möglichkeit, dass nicht genügend Kerne für die Paketverarbeitung vorhanden sind, es sei denn, die Kerne wurden passend zur Arbeitslast vorab zugewiesen.	Telekommunikations- oder NFV-Arbeitslasten	Die Kombination aus Treiber und Firmware muss im VMware-Kompatibilitätshandbuch für E/A-Geräte mit „Erweiterter Datenpfad – Unterstützung für Abfragemodus“ enthalten sein.

Anforderungen und Empfehlungen für das vSphere-Netzwerkdesign für VMware Cloud Foundation

Überprüfen Sie die Anforderungen und Empfehlungen für vSphere-Netzwerke in VMware Cloud Foundation, wie z. B. Konfiguration einer verteilten Portgruppe, MTU-Größe, Port-Bindung, Teaming-Richtlinie und datenverkehrsspezifische Netzwerkfreigaben.

Anforderungen an das vSphere-Netzwerkdesign für VMware Cloud Foundation

Sie müssen die folgenden Designanforderungen an Ihr vSphere-Netzwerkdesign für VMware Cloud Foundation erfüllen.

Tabelle 5. Anforderungen an das vSphere-Netzwerkdesign für eine VI-Arbeitslastdomäne mit einem Computing-Cluster mit mehreren Racks für VMware Cloud Foundation

Anforderungs-ID	Designanforderung	Begründung	Auswirkung
VCF-VDS-L3MR-REQD-CFG-001	Erstellen Sie für jedes Rack im Cluster eine Portgruppe auf dem vSphere Distributed Switch für folgende Datenverkehrstypen: Hostverwaltung vSAN vSphere vMotion	Erforderlich für die Verwendung separater VLANs pro Rack.	Keine.

Empfehlungen für das vSphere-Netzwerkdesign für VMware Cloud Foundation

In Ihrem vSphere-Netzwerkdesign für VMware Cloud Foundation können Sie bestimmte Best Practices für vSphere Distributed Switch und verteilte Portgruppen anwenden.

Tabelle 6. Empfehlungen für das vSphere-Netzwerkdesign für VMware Cloud Foundation

Empfehlungs-ID	Designempfehlung	Begründung	Auswirkung
VCF-VDS-RCMD-CFG-001	Verwenden Sie einen einzelnen vSphere Distributed Switch pro Cluster.	Reduziert die Komplexität des Netzwerkdesigns.	Verringert die Anzahl der vSphere Distributed Switches, die pro Cluster verwaltet werden müssen.
VCF-VDS-RCMD-CFG-002	Geben Sie einen vSphere Distributed Switch nicht für mehrere Cluster frei.	Ermöglicht unabhängige Lebenszyklusverwaltung der vSphere Distributed Switches pro Cluster. Verkleinert die Fehlerdomäne.	Für mehrere Cluster müssen mehrere vSphere Distributed Switches verwaltet werden.
VCF-VDS-RCMD-CFG-003	Konfigurieren Sie die MTU-Größe des vSphere Distributed Switch auf 9000 für Jumbo-Frames.	Unterstützt die MTU-Größe, die für Arten des Systemdatenverkehrs erforderlich ist. Verbessert den Durchsatz des Datenverkehrs.	Beim Anpassen der MTU-Paketgröße müssen Sie auch den gesamten Netzwerkpfad (VMkernel-Ports, virtuelle Switches, physische Switches und Router) so konfigurieren, dass er dieselbe MTU-Paketgröße unterstützt.
VCF-VDS-RCMD-DPG-001	Verwenden Sie die flüchtige Port-Bindung für die Verwaltungsportgruppe der VM.	Wird die flüchtige Port-Bindung verwendet, kann die vCenter Server-Instanz wiederhergestellt werden, die den Distributed Switch verwaltet. Das VM-Verwaltungsnetzwerk ist für einen reinen Computing-Cluster mit mehreren Racks in einer VI-Arbeitslastdomäne nicht erforderlich.	Berechtigungen und Steuerelemente auf Portebene gehen während des Ein-/Ausschaltzyklus verloren, und es wird kein Verlaufskontext gespeichert.
VCF-VDS-RCMD-DPG-002	Verwenden Sie die statische Port-Bindung für alle Nicht-Verwaltungsportgruppen.	Die statische Bindung stellt sicher, dass eine virtuelle Maschine eine Verbindung mit demselben Port auf dem vSphere Distributed Switch herstellt. Diese Konfiguration bietet Unterstützung für Verlaufsdaten sowie für die Überwachung auf Portebene.	Keine.
VCF-VDS-RCMD-DPG-003	Verwenden Sie den Teaming-Algorithmus Route based on physical NIC load für die Verwaltungsportgruppe der VM. Das VM-Verwaltungsnetzwerk ist für eine L3-Multi-Rack-Bereitstellung im Nur-Computing-Modus nicht erforderlich.	Reduziert die Komplexität des Netzwerkdesigns, erhöht die Ausfallsicherheit und kann sich an fluktuierende Arbeitslasten anpassen.	Keine.
VCF-VDS-RCMD-DPG-004	Verwenden Sie den Teaming-Algorithmus Route based on physical NIC load für die ESXi-Verwaltungsportgruppe.	Reduziert die Komplexität des Netzwerkdesigns, erhöht die Ausfallsicherheit und kann sich an fluktuierende Arbeitslasten anpassen.	Keine.
VCF-VDS-RCMD-DPG-005	Verwenden Sie den Teaming-Algorithmus Route based on physical NIC load für die vSphere vMotion-Portgruppe.	Reduziert die Komplexität des Netzwerkdesigns, erhöht die Ausfallsicherheit und kann sich an fluktuierende Arbeitslasten anpassen.	Keine.
VCF-VDS-RCMD-DPG-006	Verwenden Sie den Teaming-Algorithmus Route based on physical NIC load für die vSAN-Portgruppe.	Reduziert die Komplexität des Netzwerkdesigns, erhöht die Ausfallsicherheit und kann sich an fluktuierende Arbeitslasten anpassen.	Keine.
VCF-VDS-RCMD-NIO-001	Aktivieren Sie Network I/O Control für den vSphere Distributed Switch des Verwaltungsdomänen-Clusters. Aktivieren Sie Network I/O Control in dedizierten vSphere-Clustern für NSX Edge-Knoten nicht.	Erhöht die Stabilität und Leistung des Netzwerks.	Bei falscher Konfiguration kann Network I/O Control die Netzwerkleistung für kritische Datenverkehrstypen beeinträchtigen.
VCF-VDS-RCMD-NIO-002	Legen Sie den Anteilswert für den Verwaltungsdatenverkehr auf Normal fest.	Wenn die Standardeinstellung „Normal“ beibehalten wird, wird der Verwaltungsdatenverkehr höher priorisiert als vSphere vMotion, aber niedriger als vSAN-Datenverkehr. Der Verwaltungsdatenverkehr ist wichtig, da er sicherstellt, dass die Hosts auch während eines Netzwerkkonflikts verwaltet werden können.	Keine.
VCF-VDS-RCMD-NIO-003	Legen Sie den Anteilswert für vSphere vMotion-Datenverkehr auf „Niedrig“ fest.	Während eines Netzwerkkonflikts ist der vSphere vMotion-Datenverkehr nicht so wichtig wie VM- oder Speicherdatenverkehr.	Während eines Netzwerkkonflikts wird für die Ausführung von vMotion mehr Zeit als gewöhnlich benötigt.
VCF-VDS-RCMD-NIO-004	Legen Sie den Anteilswert für virtuelle Maschinen auf „Hoch“ fest.	Virtuelle Maschinen sind das wichtigste Objekt im SDDC. Wenn Sie die Standardeinstellung „Hoch“ beibehalten, wird sichergestellt, dass sie immer Zugriff auf die benötigten Netzwerkressourcen haben.	Keine.
VCF-VDS-RCMD-NIO-005	Legen Sie den Anteilswert für vSAN-Datenverkehr auf „Hoch“ fest.	Während eines Netzwerkkonflikts benötigt vSAN-Datenverkehr garantierte Bandbreite zur Unterstützung der VM-Leistung.	Keine.
VCF-VDS-RCMD-NIO-006	Legen Sie den Anteilswert für andere Datenverkehrstypen auf „Niedrig“ fest.	Standardmäßig verwendet VMware Cloud Foundation keine anderen Datenverkehrstypen wie vSphere FT-Datenverkehr. Daher kann für diese Datenverkehrstypen die niedrigste Priorität festgelegt werden.	Keine.