Design der physischen Netzwerkinfrastruktur für VMware Cloud Foundation

Das Design des physischen Datencenter-Netzwerks umfasst die Definition der Netzwerktopologie für die Verbindung physischer Switches und ESXi-Hosts, die Ermittlung der Switch Port-Einstellungen für VLANs und Link-Aggregation und den Routing-Entwurf.

Ein softwaredefiniertes Netzwerk (SDN) wird mit Komponenten des physischen Datencenters vernetzt und verwendet diese. Ein SDN wird mit Ihrem physischen Netzwerk vernetzt, um den Ost-West-Transit im Datencenter und den Nord-Süd-Transit zu und von den SDDC-Netzwerken zu unterstützen.

Es gibt mehrere typische Bereitstellungstopologien für Datencenter-Netzwerke:

• Core-Aggregation-Zugriff

• Leaf-Spine

• Hardware-SDN

Hinweis:

Bei Leaf-Spine handelt es sich um die standardmäßige Bereitstellungstopologie für Datencenter-Netzwerke in VMware Cloud Foundation.

VLANs und Subnetze für VMware Cloud Foundation

Konfigurieren Sie Ihre VLANs und Subnetze gemäß den Richtlinien und Anforderungen für VMware Cloud Foundation.

Beachten Sie beim Entwerfen der VLAN- und Subnetzkonfiguration für Ihre VMware Cloud Foundation-Bereitstellung die folgenden Richtlinien:

Tabelle 1. VLAN- und Subnetzrichtlinien für VMware Cloud Foundation

Alle Bereitstellungstopologien	Mehrere Verfügbarkeitszonen	NSX-Verbund zwischen mehreren VMware Cloud Foundation-Instanzen	VI-Arbeitslastdomäne mit einem Computing-Cluster mit mehreren Racks
Stellen Sie sicher, dass Ihre Subnetze so skaliert sind, dass eine Erweiterung möglich ist, da eine Erweiterung zu einem späteren Zeitpunkt zu einer Unterbrechung führen kann. Verwenden Sie die IP-Adresse der dynamischen Schnittstelle für Virtual Router Redundancy Protocol (VRPP) oder Hot Standby-Routing Protocol (HSRP) als Gateway. Verwenden Sie den RFC 1918-IPv4-Adressbereich für diese Subnetze und teilen Sie ein Oktett nach VMware Cloud Foundation-Instanz und ein Oktett nach Funktion zu.	Bei Netzwerksegmenten, die zwischen Verfügbarkeitszonen ausgeweitet werden, muss die VLAN-ID die folgenden Anforderungen erfüllen: Sie muss in beiden Verfügbarkeitszonen mit denselben Layer-3-Netzwerksegmenten identisch sein. Sie muss über ein Layer-3-Gateway am ersten Hop verfügen, das hochverfügbar ist und somit den Ausfall einer gesamten Verfügbarkeitszone toleriert. Für Netzwerksegmente desselben Typs, die sich nicht zwischen Verfügbarkeitszonen erstrecken, kann die VLAN-ID identisch oder zwischen den Zonen unterschiedlich sein.	Ein RTEP-Netzwerksegment muss über eine VLAN-ID und einen Layer-3-Bereich verfügen, die für die VMware Cloud Foundation-Instanz spezifisch sind. In einer VMware Cloud Foundation-Instanz mit mehreren Verfügbarkeitszonen muss das RTEP-Netzwerksegment zwischen den Zonen ausgeweitet und derselben VLAN-ID und demselben IP-Bereich zugewiesen werden. Alle Edge-RTEP-Netzwerke müssen untereinander erreichbar sein.	Verwenden Sie den RFC 1918-IPv4-Adressbereich für diese Subnetze und teilen Sie ein Oktett nach Rack und ein Oktett nach Netzwerkfunktion zu.

Wenn VLANs und Subnetze für VMware Cloud Foundation bereitgestellt werden, müssen sie die folgenden Anforderungen gemäß der VMware Cloud Foundation-Topologie erfüllen:

Abbildung 1. Auswählen eines VLAN-Modells für Host- und Verwaltungs-VM-Datenverkehr

Tabelle 2. VLANs und Subnetze für Verfügbarkeitszonen und Instanzen für VMware Cloud Foundation

Funktion	VMware Cloud Foundation-Instanzen mit einer einzelnen Verfügbarkeitszone	VMware Cloud Foundation-Instanzen mit mehreren Verfügbarkeitszonen
VM-Verwaltung	Erforderlich bei Trennung von der Hostverwaltung Hochverfügbares Gateway innerhalb der -Instanz	Erforderlich bei Trennung von der Hostverwaltung Muss innerhalb der Instanz ausgeweitet werden Hochverfügbares Gateway für mehrere Verfügbarkeitszonen innerhalb der Instanz
Hostverwaltung – erste Verfügbarkeitszone	Erforderlich Hochverfügbares Gateway innerhalb der -Instanz	Erforderlich Hochverfügbares Gateway für mehrere Verfügbarkeitszonen innerhalb der Instanz
vSphere vMotion – erste Verfügbarkeitszone	Erforderlich Hochverfügbares Gateway innerhalb der -Instanz	Erforderlich Hochverfügbares Gateway in der ersten Verfügbarkeitszone innerhalb der Instanz
vSAN – erste Verfügbarkeitszone	Erforderlich für den Standardcluster der Verwaltungsdomäne Hochverfügbares Gateway innerhalb der -Instanz	Erforderlich Hochverfügbares Gateway in der ersten Verfügbarkeitszone innerhalb der Instanz
Host-Overlay – erste Verfügbarkeitszone	Erforderlich Hochverfügbares Gateway innerhalb der -Instanz	Erforderlich Hochverfügbares Gateway in der ersten Verfügbarkeitszone innerhalb der Instanz
NFS	Erforderlich, wenn NFS als Prinzipalspeicher in der VI-Arbeitslastdomäne verwendet wird	Nicht unterstützt
Uplink01	Erforderlich Gateway optional	Erforderlich Gateway optional Muss innerhalb der Instanz ausgeweitet werden
Uplink02	Erforderlich Gateway optional	Erforderlich Gateway optional Muss innerhalb der Instanz ausgeweitet werden
Edge-Overlay	Erforderlich Hochverfügbares Gateway innerhalb der -Instanz	Erforderlich Muss innerhalb der Instanz ausgeweitet werden Hochverfügbares Gateway für mehrere Verfügbarkeitszonen innerhalb der Instanz
Hostverwaltung – zweite Verfügbarkeitszone	Nicht erforderlich	Erforderlich Hochverfügbares Gateway in der zweiten Verfügbarkeitszone innerhalb der Instanz
vSphere vMotion – zweite Verfügbarkeitszone	Nicht erforderlich	Erforderlich Hochverfügbares Gateway in der zweiten Verfügbarkeitszone innerhalb der Instanz
vSAN – zweite Verfügbarkeitszone	Nicht erforderlich	Erforderlich Hochverfügbares Gateway in der zweiten Verfügbarkeitszone innerhalb der Instanz
Host-Overlay – zweite Verfügbarkeitszone	Nicht erforderlich	Erforderlich Hochverfügbares Gateway in der zweiten Verfügbarkeitszone innerhalb der Instanz
Edge-RTEP	Nur für NSX-Verbund erforderlich Hochverfügbares Gateway innerhalb der -Instanz	Nur für NSX-Verbund erforderlich Muss innerhalb der Instanz ausgeweitet werden Hochverfügbares Gateway für mehrere Verfügbarkeitszonen innerhalb der Instanz
Management und Zeuge – Zeugen-Appliance an einem dritten Standort	Nicht erforderlich	Erforderlich Hochverfügbares Gateway am Zeugenstandort

Tabelle 3. VLANs und Subnetze für Multi-Rack-Bereitstellungen mit VMware Cloud Foundation

Funktion	VMware Cloud Foundation-Instanzen mit einer VI-Arbeitslastdomäne mit einem Computing-Cluster mit mehreren Racks	VMware Cloud Foundation-Instanzen mit NSX Edge-Multi-Rack-Verfügbarkeit
VM-Verwaltung	Nicht erforderlich als „Nur Computing“	Erforderlich bei Trennung von der Hostverwaltung Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack
Hostverwaltung	Pro Rack erforderlich Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack	Pro Rack erforderlich Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack
vSphere vMotion	Pro Rack erforderlich Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack	Pro Rack erforderlich Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack
vSAN	Pro Rack erforderlich Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack	Pro Rack erforderlich, wenn vSAN verwendet wird Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack
Host-Overlay	Pro Rack erforderlich Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack	Pro Rack erforderlich Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack
NFS	Nicht unterstützt	Erforderlich, wenn NFS als Prinzipalspeicher für die Cluster mit den NSX Edge-Knoten verwendet wird.
Uplink01	Nicht erforderlich	Pro Rack erforderlich
Uplink02	Nicht erforderlich	Pro Rack erforderlich
Edge-Overlay	Nicht erforderlich	Pro Rack erforderlich Hochverfügbares Gateway auf den ToR-Switches oder Leaf-Knoten im Rack

Anforderungen und Empfehlungen für das Design für physische Leaf-Spine-Netzwerke für VMware Cloud Foundation

Bei Leaf-Spine handelt es sich um die standardmäßige Bereitstellungstopologie für Datencenter-Netzwerke in VMware Cloud Foundation. Berücksichtigen Sie die Netzwerkbandbreite, die Trunk-Port-Konfiguration sowie die Jumbo-Frames- und Routing-Konfiguration für NSX in einer Bereitstellung mit einer einzelnen oder mehreren VMware Cloud Foundation-Instanzen.

Logisches Design des physischen Leaf-Spine-Netzwerks

Jeder ESXi-Host verfügt über redundante Konnektivität zu den ToR-Switches (Top-of-Rack) des SDDC-Netzwerk-Fabric durch zwei oder mehr Ports mit einer empfohlenen Geschwindigkeit von 25-GbE oder höher. Die ToR-Switches sind so konfiguriert, dass sie alle erforderlichen VLANs mithilfe eines 802.1Q-Trunks bereitstellen. Diese redundanten Verbindungen nutzen Funktionen in vSphere Distributed Switch und NSX, um sicherzustellen, dass keine physische Schnittstelle überlastet ist und verfügbare redundante Pfade verwendet werden.

Abbildung 2. Logisches Design des physischen Leaf-Spine-Netzwerks

Anforderungen und Empfehlungen für physische Leaf-Spine-Netzwerke

Die Anforderungen und Empfehlungen für die Leaf-Spine-Netzwerkkonfiguration bestimmen das physische Layout und die Verwendung von VLANs. Sie enthalten auch Anforderungen und Empfehlungen für Jumbo-Frames und netzwerkbezogene Anforderungen wie DNS, NTP und Routing.

Tabelle 4. Anforderungen für das Design physischer Leaf-Spine-Netzwerke für VMware Cloud Foundation

Anforderungs-ID	Designanforderung	Begründung	Auswirkung
VCF-NET-REQD-CFG-001	Verwenden Sie keine EtherChannel-Konfiguration (LAG, LACP oder vPC) für ESXi Host-Uplinks.	Vereinfacht die Konfiguration von Top-of-Rack-Switches. Mit vSphere Distributed Switch verfügbare Gruppierungsoptionen bieten Lastausgleich und Failover. EtherChannel-Implementierungen weisen möglicherweise anbieterspezifische Einschränkungen auf.	Keine.
VCF-NET-REQD-CFG-002	Verwenden Sie VLANs, um physische Netzwerkfunktionen zu trennen.	Unterstützt physische Netzwerkkonnektivität, ohne dass viele Netzwerkkarten erforderlich sind. Isoliert die verschiedenen Netzwerkfunktionen im SDDC, sodass Sie differenzierte Dienste haben und den Datenverkehr nach Bedarf priorisieren können.	Erfordert eine einheitliche Konfiguration und Präsentation auf allen Trunks, die den ESXi-Hosts zur Verfügung gestellt werden.
VCF-NET-REQD-CFG-003	Konfigurieren Sie die VLANs als Mitglieder eines 802.1Q-Trunks.	Alle VLANs werden auf denselben physischen Netzwerkadaptern auf den ESXi Hosts verfügbar.	Optional kann das Verwaltungs-VLAN als natives VLAN fungieren.
VCF-NET-REQD-CFG-004	Legen Sie die MTU-Größe auf mindestens 1.700 Byte (empfohlen 9.000 Byte für Jumbo-Frames) auf den physischen Switch-Ports, vSphere Distributed Switches, vSphere Distributed Switch Portgruppen und N-VDS Switches fest, die die folgenden Datenverkehrstypen unterstützen: Overlay (Geneve) vSAN vSphere vMotion	Verbessert den Durchsatz des Datenverkehrs. Unterstützt Geneve, indem die MTU-Größe auf mindestens 1.600 Byte erhöht wird. Geneve ist ein erweiterbares Protokoll. Die MTU-Größe kann mit zukünftigen Funktionen zunehmen. Während 1.600 Byte ausreichen, bietet eine MTU-Größe von 1.700 Byte mehr Raum zum Erhöhen der Geneve-MTU-Größe, ohne dass die MTU-Größe der physischen Infrastruktur geändert werden muss.	Beim Anpassen der MTU-Paketgröße müssen Sie auch den gesamten Netzwerkpfad (VMkernel-Netzwerkadapter, virtuelle Switches, physische Switches und Router) so konfigurieren, dass er dieselbe MTU-Paketgröße unterstützt. In einer Umgebung mit mehreren Verfügbarkeitsbereichen muss die MTU auf dem gesamten Netzwerkpfad zwischen den Zonen konfiguriert werden.

Tabelle 5. Anforderungen für das Design physischer Leaf-Spine-Netzwerke 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-NET-L3MR-REQD-CFG-001	Stellen Sie für eine VI-Arbeitslastdomäne mit einem Computing-Cluster mit mehreren Racks separate VLANs pro Rack für jede Netzwerkfunktion bereit. Hostverwaltung vSAN vSphere vMotion Host-Overlay	Ein Layer-3-Leaf-Spine-Fabric verfügt über eine Layer-3-Begrenzung an den Leaf-Switches in jedem Rack und bildet eine Layer-3-Begrenzung zwischen Racks.	Erfordert zusätzliche VLANs für jedes Rack.
VCF-NET-L3MR-REQD-CFG-002	Für eine VI-Arbeitslastdomäne mit einem Computing-Cluster mit mehreren Racks müssen die Subnetze für jedes Netzwerk pro Rack routingfähig und für die Leaf-Switches in den anderen Racks erreichbar sein. Hostverwaltung vSAN vSphere vMotion Host-Overlay	Stellt sicher, dass der Datenverkehr für jedes Netzwerk zwischen Racks weitergeleitet werden kann.	Erfordert eine zusätzliche physische Netzwerkkonfiguration, damit Netzwerke zwischen Racks geroutet werden können.

Tabelle 6. Anforderungen für das Design physischer Leaf-Spine-Netzwerke für NSX-Verbund in VMware Cloud Foundation

Anforderungs-ID	Designanforderung	Begründung	Auswirkung
VCF-NET-REQD-CFG-005	Legen Sie die MTU-Größe auf den Komponenten des physischen Netzwerks zwischen den VMware Cloud Foundation-Instanzen für die folgenden Datenverkehrstypen auf mindestens 1.500 Byte fest (1.700 Byte bevorzugt, 9.000 Byte empfohlen für Jumbo-Frames). NSX Edge RTEP	Jumbo-Frames sind zwischen VMware Cloud Foundation-Instanzen nicht erforderlich. Eine erhöhte MTU verbessert jedoch den Datenverkehrsdurchsatz. Durch die Erhöhung der RTEP-MTU auf 1.700 Byte wird die Fragmentierung für Arbeitslastpakete mit Standardgröße zwischen VMware Cloud Foundation-Instanzen minimiert.	Beim Anpassen der MTU-Paketgröße müssen Sie auch den gesamten Netzwerkpfad konfigurieren, also virtuelle Schnittstellen, virtuelle Switches, physische Switches und Router, um dieselbe MTU-Paketgröße zu unterstützen.
VCF-NET-REQD-CFG-006	Stellen Sie sicher, dass die Latenz zwischen VMware Cloud Foundation-Instanzen, die in einem NSX-Verbund verbunden sind, weniger als 500 ms beträgt.	Für den NSX-Verbund ist eine Latenz von weniger als 500 ms erforderlich.	Keine.
VCF-NET-REQD-CFG-007	Stellen Sie eine geroutete Verbindung zwischen den NSX Manager-Clustern in VMware Cloud Foundation-Instanzen bereit, die in einem NSX-Verbund verbunden sind.	Das Konfigurieren des NSX Verbunds erfordert Konnektivität zwischen den NSX Global Manager-Instanzen, NSX lokalen Manager-Instanzen und NSX Edge-Clustern.	Sie müssen jeder Fehlerdomäne eindeutige routingfähige IP-Adressen zuweisen.

Tabelle 7. Empfehlungen für das Design physischer Leaf-Spine-Netzwerke für VMware Cloud Foundation

Empfehlungs-ID	Designempfehlung	Begründung	Auswirkung
VCF-NET-RCMD-CFG-001	Verwenden Sie zwei ToR-Switches für jedes Rack.	Unterstützt die Verwendung von zwei 10-GbE-Links (25 GbE oder höher empfohlen) zu jedem Server, bietet Redundanz und reduziert die allgemeine Designkomplexität.	Erfordert zwei ToR-Switches pro Rack, was die Kosten erhöhen kann.
VCF-NET-RCMD-CFG-002	Implementieren Sie die folgende physische Netzwerkarchitektur: Mindestens ein 25-GbE-Port (mindestens 10 GbE) auf jedem ToR-Switch für ESXi-Host-Uplinks (Host zu ToR). Layer-3-Gerät, das BGP unterstützt.	Bietet Verfügbarkeit während eines Switch-Ausfalls. Bietet Unterstützung für das dynamische BGP-Routing-Protokoll	Schränkt möglicherweise die Hardwareauswahl ein. Erfordert eine Dynamische Routing-Protokollkonfiguration im physischen Netzwerk.
VCF-NET-RCMD-CFG-003	Verwenden Sie ein physisches Netzwerk, das für die BGP-Routing-Nachbarschaft konfiguriert ist.	Unterstützt Designflexibilität für das Routing von Arbeitslasten mit mehreren Sites und Mehrmandantenfähigkeit. BGP ist das einzige dynamische Routing-Protokoll, das für NSX Federation unterstützt wird. Unterstützt Failover zwischen ECMP Edge-Uplinks.	Erfordert eine BGP-Konfiguration im physischen Netzwerk.
VCF-NET-RCMD-CFG-004	Weisen Sie dauerhafte IP-Konfigurationen für NSX-Tunnel-Endpoints (TEPs) zu, die dynamische IP-Pools anstelle statischer IP-Pool-Adressierung nutzen.	Stellen Sie sicher, dass Endpoints über eine persistente TEP-IP-Adresse verfügen. In VMware Cloud Foundation wird die TEP-IP-Zuweisung mithilfe von statischen IP-Pools für alle Topologien empfohlen. Mit dieser Konfiguration werden alle Anforderungen für externe DHCP-Dienste entfernt.	Wenn Sie dem Cluster weitere Hosts hinzufügen, muss die Anzahl der statischen IP-Pools unter Umständen erhöht werden.
VCF-NET-RCMD-CFG-005	Konfigurieren Sie die mit ESXi-Netzwerkkarten verbundenen Trunk-Ports als Trunk-PortFast.	Reduziert die Zeit für den Übergang der Ports in den Weiterleitungszustand.	Bei diesem Design wird zwar kein STP verwendet.Bei Switches ist STP jedoch in der Regel standardmäßig konfiguriert.
VCF-NET-RCMD-CFG-006	Konfigurieren Sie VRRP, HSRP- oder eine andere Layer-3-Gateway-Verfügbarkeitsmethode für diese Netzwerke. Management Edge-Overlay	Stellen Sie sicher, dass die VLANs, die zwischen Verfügbarkeitszonen ausgeweitet werden, mit einem hochverfügbaren Gateway verbunden sind. Andernfalls führt ein Ausfall im Layer-3-Gateway zu einer Unterbrechung des Datenverkehrs im SDN-Setup.	Erfordert die Konfiguration einer Hochverfügbarkeitstechnologie für die Schicht-3-Gateways im Datencenter.
VCF-NET-RCMD-CFG-007	Verwenden Sie separate VLANs für die Netzwerkfunktionen für jeden Cluster.	Passt die Größe der Layer-2-Broadcast-Domäne an einen einzelnen vSphere-Cluster an.	Erhöht die Gesamtzahl der VLANs, die für eine VMware Cloud Foundation-Instanz erforderlich sind.

Tabelle 8. Empfehlungen für das Design physischer Leaf-Spine-Netzwerke für die Skalierung und Leistung eines dedizierten Edge für VMware Cloud Foundation

Empfehlungs-ID	Designempfehlung	Begründung	Auswirkung
VCF-NET-DES-RCMD-CFG-001	Implementieren Sie die folgende physische Netzwerkarchitektur: Zwei 100-GbE-Ports auf jedem ToR-Switch für ESXi-Host-Uplinks (Host zu ToR). Layer-3-Gerät, das BGP unterstützt.	Unterstützt die Anforderungen für hohe Bandbreite sowie Pakete pro Sekunde für umfangreiche Bereitstellungen.	Erfordert Netzwerk-Switches mit 100 GbE.

Tabelle 9. Empfehlungen für das Design physischer Leaf-Spine-Netzwerke für NSX-Verbund in VMware Cloud Foundation

Empfehlungs-ID	Designempfehlung	Begründung	Auswirkung
VCF-NET-RCMD-CFG-008	Stellen Sie BGP-Routing zwischen allen VMware Cloud Foundation-Instanzen bereit, die in einer NSX-Verbundeinrichtung verbunden sind.	BGP ist das unterstützte Routing-Protokoll für NSX Federation.	Keine.
VCF-NET-RCMD-CFG-009	Stellen Sie sicher, dass die Latenz zwischen VMware Cloud Foundation-Instanzen, die in einem NSX-Verbund verbunden sind, weniger als 150 ms für die Arbeitslastmobilität beträgt.	Für die folgenden Funktionen ist eine Latenz von weniger als 150 ms erforderlich: Cross-vCenter Server vMotion	Keine.