Die NSX-Architektur in VCF 5.x basierte auf dem klassischen Modell: Ein Tier-0-Gateway diente als zentrale Nord-Süd-Komponente, darunter befanden sich Tier-1-Gateways für logische Routing-Domänen sowie Segmente als Netzwerke für die Workloads.
Dieses Architekturmodell existiert in VCF 9 weiterhin und wird jetzt als Segment Networking bezeichnet. Es wird weiterhin vollständig unterstützt, gilt aber nicht mehr als der primär empfohlene Ansatz. Daneben existiert auch das klassische VLAN Networking ohne NSX, bei dem Netzwerke direkt über VDS Port Groups konfiguriert werden. Dieses Modell bleibt unverändert möglich, bietet aber keine NSX-Funktionen.
An seine Stelle kommt das VPC (Virtual Private Cloud) Networking, das sich konzeptionell stärker an Public-Cloud-Modellen wie z.B. AWS oder Azure orientiert. Das VPC Networking ist nicht neu in VCF 9 und war bereits seit NSX Version 4.0 vorhanden, hatte aber bisher eine Nebenfunktion.
Warum kommt es zu diesem Wechsel?
Im klassischen Segment Networking müssen die Netzwerkadministratoren sämtliche Konfigurationen zentral durchführen: von Segmenten über Routing bis hin zu Firewall-Regeln. Dieses Modell ist zwar bewährt und seit Jahren etabliert, führt in der Praxis häufig zu einem operativen Engpass, da jede neue Applikationsumgebung und jeder neue Tenant einen Eingriff (eine Anapassung) durch das zentrale Netzwerkteam erfordert.
Das VPC Networking adressiert genau dieses Problem. Es ermöglicht Applikationsteams, ihre eigenen isolierten Netzwerkumgebungen eigenständig zu erstellen. Dies findet innerhalb klar vordefinierter Rahmenbedingungen statt, die das Netzwerkteam im Vorfeld festlegt: IP-Adressbereiche, Konnektivitätsprofile und Sicherheitsvorgaben. Innerhalb dieser Grenzen können Teams ihre Netzwerke selbst betreiben, ohne jedes Mal das Netzwerkteam einschalten zu müssen.
Segment Networking bleibt weiterhin die richtige Wahl für die Infrastrukturen, in denen zentrale Kontrolle über alle Netzwerkaspekte gewünscht ist und kein Self-Service-Modell benötigt oder bessergesagt vorgesehen wird.
Beide Modelle (VPC Networking oder Segment Networking) können in derselben VCF-Umgebung parallel existieren, allerdings nicht innerhalb einer einzelnen Workload Domain. Die Entscheidung für Segment Networking oder VPC Networking wird auf Workload-Domain-Ebene getroffen. Nach einem Upgrade von VCF 5.x auf VCF 9 kann eine bestehende Workload Domain entweder unverändert übernommen werden und im Segment Networking Modus laufen oder mit VPC Networking konfiguriert werden. Beide Domains teilen sich dabei denselben NSX Manager, arbeiten aber mit ihrem jeweiligen Netzwerkmodell.
Was ist eine VPC?
Wir haben VPC bereits ins Spiel gebracht, ohne zu erklären, was sich dahinter verbirgt. Eine Virtual Private Cloud (VPC) ist eine logisch isolierte Netzwerkdomäne innerhalb von NSX, die einem Team, einer Applikation oder einem Tenant zugewiesen wird. Jede VPC verfügt über ein eigenes VPC-Gateway, welches das Routing innerhalb der VPC übernimmt und den Datenverkehr in Richtung übergeordneter Routing-Komponenten weiterleitet. Funktional ist das VPC-Gateway mit einem Tier-1-Gateway vergleichen.
Innerhalb eines VPC gibt es drei Subnetz-Typen mit jeweils unterschiedlichen Konnektivitätsprofilen.
Ein Public Subnet ist nach außen direkt routbar. VMs in einem Public Subnet sind über das Transit Gateway von externen Endpunkten erreichbar, sofern das Routing im übergeordneten Provider Gateway entsprechend konfiguriert ist. Dies entspricht funktional einer klassischen DMZ.
Ein Private TGW Subnet (TGW steht für Transit Gateway und wird weiter erklärt) ist innerhalb der übergeordneten Routing-Domäne erreichbar, aber nicht von außen. Die Workloads in diesem Subnetz können andere VPCs desselben NSX-Projekts erreichen und auf gemeinsam bereitgestellte Dienste zugreifen. Der Zugriff auf externe Netzwerke erfolgt über NAT. Dies ist der typische Subnet-Typ für Applikations- und Datenbankserver, die untereinander kommunizieren müssen, aber nicht direkt von außen erreichbar sein sollen. Da die Isolation auf Projektebene sichergestellt ist, können IP-Adressbereiche dabei auch überlappend vergeben werden.
Ein Private Subnet ist vollständig isoliert und ausschließlich innerhalb der eigenen VPC erreichbar. Externe Kommunikation ist nur über explizit konfigurierte NAT-Regeln mit zugewiesenen externen IP-Adressen möglich.
Die Workloads in Private TGW Subnet und Private Subnet haben standardmäßig keine ausgehende Konnektivität nach außen. Der ausgehende Traffic erfordert entweder einen Active/Standby Centralized TGW mit aktiviertem „VPC Default Outbound NAT” im Konnektivitätsprofil oder eine manuelle Konfiguration von externen IP-Adressen bzw. NAT-Regeln.
VPC-Rollenmodell
Das VPC-Modell führt eine klare Rollentrennung ein. Es gibt drei Rollen, die jeweils auf einer anderen Hierarchieebene arbeiten.
Der Enterprise Admin ist die höchste operative Rolle im VPC-Modell. Er verbindet NSX mit der physischen Infrastruktur, definiert Projekte als erste Ebene inklusive zugewiesener Ressourcen und Verbrauchsobergrenzen (Quotas).
Der Project Admin ist ein Tenant innerhalb der Plattform. Er hat keinen direkten Zugriff auf die physische Infrastruktur und verteilt die Projektressourcen auf VPC-Ebene.
Der VPC Admin ist typischerweise derselbe Administrator, der auch die vSphere-Umgebung betreut. Solange er sich innerhalb der vorgegebenen Quoten bewegt, kann er Netzwerkressourcen eigenständig bereitstellen.
Transit Gateway
In NSX 4.x war eine VPC entweder direkt an einen Tier-0-Gateway oder an ein VRF (eine Virtuelle Routing-Instanz auf einem Tier-0) angehängt. In VCF 9 wird zwischen VPC und externer Anbindung eine neue logische Ebene eingeführt: der Transit Gateway (TGW).
Ein TGW verbindet mehrere VPCs innerhalb eines NSX-Projekts miteinander, aggregiert Routing-Informationen und leitet den Datenverkehr in Richtung der übergeordneten Infrastruktur weiter. Standardmäßig verfügt jedes NSX-Projekt über einen als Default bereitgestellten Transit Gateway.
Der Transit Gateway kann in zwei Modi betrieben werden, die sich in ihrer Infrastrukturabhängigkeit grundlegend unterscheiden:
- Centralized Transit Gateway (Centralized TGW)
- Distributed Transit Gateway (DTGW)
Centralized Transit Gateway
Der Centralized Transit Gateway (Centralized TGW oder C-TGW) läuft auf NSX Edge Nodes und stellt alle Netzwerkdienste bereit, die ein Transit Gateway bieten kann: SNAT, DNAT, Load Balancing und Gateway-Firewall.
Dieser Modus ist zwingend erforderlich, wenn Kubernetes-Plattformen wie VKS oder VCF Automation mit einer All Apps Organization (siehe Beitrag 2 dieser Serie) sowie Netzwerkdienste wie Load Balancing und NAT genutzt werden sollen. Der Betrieb von Centralized TGW erfolgt typischerweise im Active/Standby-Modus, insbesondere in Kombination mit Plattformdiensten.
Distributed Transit Gateway
Das Distributed Transit Gateway (DTGW) ist eine der zentralen Neuerungen in VCF 9. Es läuft direkt auf den ESXi-Hosts und benötigt keine NSX Edge Nodes.
Der Datenverkehr verlässt den Host direkt über die physische Netzwerkanbindung in Richtung Fabric. Dadurch wird die Latenz reduziert, die Anzahl der Netzwerk-Hops verringert und das Design erheblich vereinfacht.
Allerdings ist der Funktionsumfang eingeschränkt: SNAT, DNAT, Load Balancing und Gateway-Firewall stehen nicht mehr zur Verfügung. Der AVI Load Balancer ist verfügbar, allerdings ohne Client IP Transparency. Anstelle der klassischen NAT-Funktionalität wird mit direkt zugewiesenen IP-Adressen gearbeitet, wobei 1:1-NAT über externe IP-Adressen möglich ist.
Beim klassischen Centralized Transit Gateway macht der Netzwerkverkehr einer VM immer einen Umweg. Zuerst verlässt das Netzwerkpaket den ESXi-Host, dann geht es zu einem NSX Edge Node, einer separaten VM, die auf einem anderen Host läuft und erst von dort aus gelangt es ins physische Netzwerk. Das sind mindestens zwei Hops, bevor ein Paket den Weg nach außen überhaupt antritt. Beim Distributed Transit Gateway entfällt dieser Umweg vollständig. Der Verkehr verlässt den ESXi-Host direkt über dessen physische Netzwerkkarte in Richtung Top-of-Rack-Switch. Es gibt keine zwischengeschaltete Edge VM mehr.
Die Entscheidung zwischen beiden Modi ist somit eindeutig:
- wer erweiterte Netzwerkdienste oder Plattformintegration benötigt, wählt den Centralized TGW.
- wer einfache Kommunikation mit weniger Latenz und ohne Zusatzdienste betreiben möchte, wählt den Distributed TGW.
Die wichtigste Informationsquelle:
- VCF-Virtual-Networking-Technology-Reference-VCF9.0-v1.2.pdf
- Architectural Options in VMware Cloud Foundation -Networking Models