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:

Leaf-Spine ist die standardmäßige Bereitstellungstopologie für Datencenter-Netzwerke für 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

  • 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.

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:

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

Funktion

VMware Cloud Foundation-Instanzen mit einer einzelnen Verfügbarkeitszone

VMware Cloud Foundation-Instanzen mit mehreren Verfügbarkeitszonen

Verwaltung – erste Verfügbarkeitszone

  • 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

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

  • 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

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

Verwaltung – 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

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 Netzwerkbereitstellungstopologie des Datencenters für VMware Cloud Foundation. Berücksichtigen Sie die Netzwerkbandbreite, die Konfiguration des Zugriffsports, Jumbo-Frames, Routing-Konfiguration und DHCP-Verfügbarkeit 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 ist über zwei 25-GbE-Ports auf redundante Weise mit den Top-of-Rack (ToR)-Switches des SDDC-Netzwerks-Fabrics verbunden. 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 1. Logisches Design des physischen Leaf-Spine-Netzwerks
Jeder ESXi-Host ist über zwei 25-GbE-Ports auf redundante Weise mit den ToR-Switches des SDDC-Netzwerks-Fabrics verbunden. ToR-Switches sind mit der Spine verbunden.

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 sowie zu netzwerkbezogenen Anforderungen wie DNS und NTP.

Tabelle 3. 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 4. 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 150 ms beträgt.

Für die folgenden Funktionen ist eine Latenz von weniger als 150 ms erforderlich:

  • Cross-vCenter Server vMotion

  • NSX-Verbund

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 5. 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:

  • 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 eine dynamische IP-Zuweisung anstelle einer statischen IP-Pool-Adressierung nutzen.

  • Stellen Sie sicher, dass Endpoints über eine persistente TEP-IP-Adresse verfügen.

  • In VMware Cloud Foundation ist die TEP-IP-Zuweisung über DHCP für erweiterte Bereitstellungstopologien wie eine Verwaltungsdomäne mit mehreren Verfügbarkeitszonen erforderlich.

  • Statische Pools in NSX Manager unterstützen nur eine einzelne Verfügbarkeitszone.

Ein DHCP-Server muss im TEP-VLAN verfügbar sein.

VCF-NET-RCMD-CFG-005

Legen Sie die Lease-Dauer für den DHCP-Bereich für das Host-Overlay-Netzwerk auf mindestens 7 Tage fest.

Die IP-Adressen der Host-Overlay-VMkernel-Ports werden mithilfe eines DHCP-Servers zugewiesen.

  • Host-Overlay-VMkernel-Ports haben keinen administrativen Endpoint. Daher können Sie DHCP für die automatische IP-Adresszuweisung verwenden. Wenn Sie das Subnetz ändern oder erweitern müssen, ist es einfacher, den DHCP-Geltungsbereich zu ändern als einen IP-Pool zu erstellen und ihn den ESXi-Hosts zuzuweisen.

  • DHCP vereinfacht die Konfiguration eines Standard-Gateways für Host-Overlay-VMkernel-Ports, wenn sich Hosts innerhalb desselben Clusters auf separaten Layer-2-Domänen befinden.

Erfordert die Konfiguration und Verwaltung eines DHCP-Servers.

VCF-NET-RCMD-CFG-006

Legen Sie die mit ESXi-Netzwerkkarten verbundenen Trunk-Ports als Trunk-PortFast fest.

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-007

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.

Tabelle 6. Empfehlungen für das Design physischer Leaf-Spine-Netzwerke für Stretched Cluster mit VMware Cloud Foundation

Empfehlungs-ID

Designempfehlung

Begründung

Auswirkung

VCF-NET-RCMD-CFG-008

Stellen Sie Hochverfügbarkeit für den DHCP-Server oder DHCP-Hilfsdienst bereit, der für VLANs verwendet wird, die DHCP-Dienste benötigen, die zwischen Verfügbarkeitszonen ausgedehnt sind.

Stellen Sie sicher, dass ein Failover-Vorgang einer einzelnen Verfügbarkeitszone keine Auswirkungen auf die DHCP-Verfügbarkeit hat.

Erfordert die Konfiguration eines hochverfügbaren DHCP-Servers.

Tabelle 7. 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-009

Stellen Sie BGP-Routing zwischen allen VMware Cloud Foundation-Instanzen bereit, die in einer NSX Federation-Einrichtung verbunden sind.

BGP ist das unterstützte Routing-Protokoll für NSX Federation.

Keine.