Zukunft gestalten: VCF 9 Netzwerkdesign und das Ende des Legacy L2

VMware Cloud Foundation (VCF) 9 ist keine Wahl mehr – es ist eine Direktive. In der Post-Broadcom-Landschaft ist die Ära der „Pick-and-Choose“-Lizenzen für einzelne vSphere- oder vSAN-Produkte vorbei. Sie wurde ersetzt durch ein monolithisches Full-Stack-Mandat, das Netzwerk-Ingenieure zwingt, das Rechenzentrum als eine einzige programmierbare Entität zu betrachten. Wer immer noch versucht, sein physisches Fabric mit handgestrickten VLANs und Legacy L2 Extensions zu entwerfen, ist nicht nur hinter der Zeit; er entwirft einen Fehlerpunkt, der unter dem Gewicht der obligatorischen NSX- und vSAN ESA-Integration von VCF 9 zusammenbrechen wird.

Die Post-Broadcom Realität: VCF 9 als Strategisches Fundament

Der Übergang zu VCF 9 stellt eine grundlegende Änderung in unserer Herangehensweise an das SDDC (Software-Defined Data Center) dar. Zuvor wurde NSX oft als „Overlay-Option“ für fortgeschrittene Umgebungen behandelt. In VCF 9 ist NSX der Motor, das Getriebe und das Dashboard. Broadcom hat die Lizenzierung so optimiert, dass die Kostenunterschiede zwischen vSphere-only und VCF bewusst so gestaltet sind, dass sie eine Migration erzwingen. Für den Netzwerk-Ingenieur bedeutet dies, dass das physische Underlay unsichtbar, robust und ausschließlich L3-basiert sein muss.

Wir betrachten eine Designphilosophie, bei der das Netzwerk durch VCF Services und nicht durch Hardware-Schnittstellen definiert wird. Mit der Abschaffung des Legacy vSAN (Original Storage Architecture - OSA) zugunsten der Express Storage Architecture (ESA) sind die Netzwerkanforderungen in die Höhe geschnellt. Wenn Sie nicht mindestens 25GbE als absoluten Einstiegspunkt verwenden – wobei 100GbE der Standard für VCF 9-Cluster ist – hungern Sie die NVMe-basierte ESA nach dem Durchsatz aus, den sie benötigt, um ihr IOPS-Potenzial auszuschöpfen.

NSX-T ist tot, es lebe NSX Project Antrea und VPCs

In VCF 9 haben sich die Netzwerk-Konstrukte weiterentwickelt. Wir sehen einen starken Fokus auf das NSX Virtual Private Cloud (VPC)-Modell. Dies ist nicht nur Marketing-Nomenklatur; es ist eine strukturelle Änderung in der Handhabung von Multi-Tenancy. Anstelle komplexer Tier-0/Tier-1-Verschachtelungen, die Ingenieure nur schwer visuell erfassen konnten, behandelt VCF 9 jeden Tenant oder Anwendungsbereich als VPC, indem der T1-Router in ein Self-Service-Consumption-Modell abstrahiert wird.

Aus Design-Perspektive erfordert dies ein Umdenken beim Edge Cluster. In älteren Versionen mag man mit kleinen Edge-VMs davongekommen sein. In VCF 9, insbesondere bei der Unterstützung von Hochleistungs-vSAN ESA-Traffic und Multi-AZ Failover, müssen Ihre Edge Nodes mindestens in den Größen „Large“ oder „X-Large“ skaliert werden, um die DPDK (Data Plane Development Kit)-Anforderungen zu erfüllen. Für einen Standard 4-Node Management Cluster empfehlen wir mindestens zwei 100GbE-fähige Edge Nodes, um zu verhindern, dass die Nord-Süd-Grenze zu einem Engpass wird.

Das VCF 9 Underlay: L3 Fabric oder Untergang

Wenn Sie immer noch MLAG/VPC (Virtual Port Channels) in Ihre ESXi-Hosts für etwas anderes als den initialen PXE-Boot oder OOB-Management nutzen, erzeugen Sie technische Schulden, die Sie nicht mehr begleichen können. VCF 9 gedeiht mit einer reinen L3 Leaf-Spine-Architektur. Wir befürworten ein BGP-to-the-Host-Modell unter Verwendung des NSX Federated Modells oder zumindest EBGP zwischen Ihren Tier-0 Gateways und Ihren Top-of-Rack (ToR) Switches.

Betrachten Sie eine typische VCF 9-Bereitstellung mit Dell VxRail- oder HPE Synergy-Nodes. Ihre physikalische Konfiguration sollte wie folgt aussehen:

! Sample Leaf Switch BGP Configuration (Arista EOS style)
router bgp 65001
   router-id 10.0.0.1
   maximum-paths 64
   neighbor VCF_EDGE_PEERS peer-group
   neighbor VCF_EDGE_PEERS remote-as 65002
   neighbor VCF_EDGE_PEERS bfd
   neighbor 10.1.1.2 peer-group VCF_EDGE_PEERS
   neighbor 10.1.1.3 peer-group VCF_EDGE_PEERS
   redistribute connected
! Ensure MTU 9000 is set everywhere for vSAN ESA and Geneve Overlays

Ohne ein MTU von 9000 (Jumbo Frames) End-to-End zerfällt die Geneve-Kapselung in NSX, was zu einem 30-40%igen Leistungsverlust führt. In VCF 9 ist dies nicht nur „empfohlen“ – es ist zwingend erforderlich für die vSAN ESA Gesundheitsprüfungen.

vSAN ESA: Das Netzwerk ist die Backplane

Die Abhängigkeit von VCF 9 von vSAN ESA verändert die Durchsatzberechnung. Anders als beim alten Disk-Group-Modell verwendet ESA eine Single-Tier-Architektur, bei der jede Disk eine Performance-Disk ist. Dies erzeugt massive Bursts von Ost-West-Traffic während Resynchronisationsereignissen. Wir planen nicht mehr für 10Gbps-Spitzen. Wir planen für 40-60Gbps dauerhafte Lasten während eines Node-Ausfalls.

Um dies zu unterstützen, muss Ihr VCF 9 Netzwerkdesign Network Partitioning priorisieren. Auch wenn wir einen collapsed N-VDS (NSX Virtual Distributed Switch) auf den Hosts verwenden, müssen Sie NIOC (Network I/O Control) nutzen, um Bandbreite für den vSAN System Traffic zu garantieren. Wenn der vSAN-Traffic über vMotion- oder Overlay-Traffic nicht ordnungsgemäß priorisiert wird, führt dies zu SCSI-Timeouts und „All Paths Down“ (APD)-Szenarien, wenn das Netzwerk überlastet ist.

Multi-AZ Design und Regionale Föderation

Eine zentrale Säule von VCF 9 ist die vereinfachte Multi-Availability Zone (Multi-AZ) Architektur. Broadcom hat die Bereitstellung von Stretched Clustern optimiert, aber die zugrundeliegenden Netzwerkanforderungen bleiben streng. Für einen VCF 9 Stretched Cluster benötigen Sie:

• < 5ms Round Trip Time (RTT) für die Management- und Workload-Ebenen.
• < 1ms RTT für vSAN ESA Stretched Traffic (dies ist die harte Grenze).
• Mindestens 10Gbps dedizierte Bandbreite zwischen den Standorten für den Witness-Traffic und die Replikation.

In VCF 9 bewegen wir uns weg von L2 Stretched VLANs auf der physikalischen Ebene. Stattdessen verwenden wir NSX Federation, um Segmente über Standorte hinweg zu spannen. Dies ermöglicht eine lokale Ingress/Egress-Optimierung (unter Verwendung von BGP Local Preference), sodass der Traffic nicht zum primären Standort „zurückpin“ muss, wenn eine VM in die sekundäre AZ verschoben wurde. Wenn Sie unseren Deep Dive zu NSX Federation-Architekturen nicht gelesen haben, müssen Sie überprüfen, wie der Global Manager mit Site-Ausfällen umgeht, bevor Sie eine VCF 9-Einführung planen.

Security: Identitätsbasiertes Distributed Firewalling (IDFW)

Sicherheit in VCF 9 ist nicht nur Mikro-Segmentierung; es ist die Integration der Distributed Firewall (DFW) mit modernen Identitätsanbietern. Das VCF 9 Compliance-Framework schreibt vor, dass der gesamte Management Traffic von der Inbetriebnahme an mithilfe von NSX DFW-Regeln isoliert werden muss. Sie verwenden keine Hardware-Firewalls mehr für Ost-West-Traffic zwischen Management-VMs. Der Overhead, Traffic zu einer physischen Palo Alto- oder FortiGate-Appliance zu schicken, ist in einer High-Density VCF 9-Umgebung inakzeptabel.

Nutzen Sie stattdessen den NSX Distributed IDS/IPS. Mit VCF 9 werden diese Signaturen automatisch über die Broadcom Cloud aktualisiert, sodass das Netzwerk in Echtzeit auf laterale Bewegungsbedrohungen reagieren kann, ohne einen einzigen VLAN-Tag oder eine Firewall-Regel zu ändern. Dies ist die „Zero-Trust“-Architektur, die Projekte seit einem Jahrzehnt versprechen und die nun durch die VCF 9 Automatisierungs-Engine realisiert werden.

Die Kosten der Ignoranz: Lizenzierung und Hardware-Angleichung

Reden wir über Zahlen. Eine VCF 9-Lizenz ist teuer – oft das 2-3fache der Kosten von Legacy vSphere Enterprise Plus auf Pro-Core-Basis (mit einem Minimum von 16 Cores). Wenn Sie diese Software auf veralteten 10GbE-Netzwerken bereitstellen, zahlen Sie effektiv eine „Stupid Tax“. Sie bezahlen für Hochleistungssoftware, die durch 500-Dollar-Top-of-Rack-Switches ausgebremst wird.

Um den ROI einer VCF 9-Investition zu realisieren, muss die Hardware stimmen. Das bedeutet Intel Ice Lake- oder Sapphire Rapids-CPUs, mindestens 1 TB RAM pro Node und Mellanox ConnectX-6- oder höhere NICs. Diese NICs unterstützen Uptane/Hardware Offloads, die für die NSX-Performance entscheidend sind. Ohne Hardware-Offloading würde die Host-CPU 20-30% ihrer Zyklen nur für die Verarbeitung von Geneve-Kapselungspaketen aufwenden, was die VM-Konsolidierungsrate mindert.

Fazit

Das VCF 9 Netzwerkdesign ist eine Übung in rücksichtsloser Vereinfachung der physikalischen Ebene, um extreme Komplexität und Agilität auf der virtuellen Ebene zu ermöglichen. Die Zeiten des manuellen Trunkings und des Spanning Tree-Tunings sind vorbei. Ihre Aufgabe ist es nun, eine grundsolide L3 „Dark Pipe“ bereitzustellen, die es NSX und vSAN ESA ermöglicht, das zu tun, wofür sie gebaut wurden: eine hochleistungsfähige, selbstheilende und sichere Cloud-Plattform bereitzustellen.

Bei TechLeague sind wir darauf spezialisiert, Unternehmen bei der Bewältigung dieser risikoreichen Migrationen zu unterstützen. Ob Sie mit dem Übergang zu NSX VPCs kämpfen oder Ihr Fabric für vSAN ESA neu aufbauen müssen, wir bieten die tiefgehende Engineering-Expertise, die die Broadcom-Dokumentation außen vor lässt. Erkunden Sie unsere maßgeschneiderten Beratungs- und Schulungspakete, um sicherzustellen, dass Ihre VCF 9-Reise nicht in einem Performance-Engpass endet.