Während sich der erste Teil mit dem neuen Netzwerkmodell mit VPCs und Transit Gateway befasste, werden in diesem Beitrag die konkreten NSX-Komponenten behandelt, die im Betrieb eine Rolle spielen. NSX Manager, NSX Edge Cluster und Distributed Firewall.
NSX Manager
Der NSX Manager ist die zentrale Verwaltungskomponente für das gesamte NSX-Deployment. Er genau ist die Schnittstelle, über die Netzwerktopologien definiert, Sicherheitsrichtlinien konfiguriert und der Zustand der Netzwerkinfrastruktur überwacht wird. An seiner grundsätzlichen Rolle hat sich in VCF 9 nichts geändert.
In VCF 9 gibt es zwei Deployment-Optionen.
Der Single-Node (Singleton) NSX Manager ist ein einzelner Node ohne Cluster-Redundanz. In diesem Fall kann man sich auf vSphere HA verlassen. Im Falle eines Host-Ausfalls startet vSphere HA den NSX Manager auf einem anderen verfügbaren Host neu. Diese Option ist für kleinere Umgebungen, Edge-Standorte oder Test-Deployments absolut geeignet.
Für Produktionsumgebungen wird der 3-Node-Cluster empfohlen. Die Datenbank wird auf allen drei Knoten repliziert, sodass eine einzelne Cluster-Instanz entsteht. Wie für Cluster typisch wird eine Mehrheit von zwei aus drei Nodes für den vollständigen Betrieb benötigt. Beim Ausfall eines Nodes läuft der Cluster weiter, allerdings mit reduzierter Kapazität.
Anti-Affinity-Regeln von vSphere DRS verhindern, dass zwei NSX Manager Nodes auf demselben Host landen. Dadurch wird gewährleistet, dass alle drei Nodes auf unterschiedlichen ESXi-Hosts laufen.
Für den Zugriff auf den 3-Node-Cluster gibt es drei Optionen:
- Cluster VIP (Virtual IP)
- External Load Balancer
- Direkte Node-Adressierung
Die Cluster VIP ist der Standard und die empfohlene Konfiguration. Eine virtuelle IP-Adresse „schwebt“ zwischen den Nodes und wandert automatisch zu einem anderen Node, wenn der aktuelle Leader ausfällt. Bei der Cluster-VIP läuft immer nur ein Node als aktiver Eigentümer der virtuellen IP-Adresse. Alle API- und UI-Anfragen werden an diesen Node gesendet. Die beiden anderen Nodes sind zwar aktiv und synchronisiert, nehmen aber keine Anfragen über die VIP entgegen. Wenn der aktive Node ausfällt, übernimmt ein anderer Node die VIP.
Der External Load Balancer ist eine Alternative zur Cluster-VIP. Dabei verteilt ein externer Load Balancer die eingehende Anfragen aktiv auf alle drei Nodes. So muss nicht der einzige Node die gesamte Last tragen. Dies ist aber nur in Umgebungen mit sehr hoher Automatisierungslast relevant, wo viele parallele API-Anfragen erwartet werden.
Bei der direkten Node-Adressierung spricht man einen der drei Nodes direkt über seine individuelle Management-IP an. Da die Konfigurationsdatenbank zwischen allen Nodes synchronisiert wird, spielt es keine Rolle welcher Node antwortet, — das Ergebnis ist immer dasselbe.
Operative Änderungen
In VCF 9 gibt es zwei operative Änderungen, die den NSX Manager direkt betreffen. Erstens sind die NSX-Kernel-Module (VIBs) nun direkt im ESXi-Image enthalten. Dadurch entfallen separate Wartungsfenster für NSX-Host-Upgrades und Live Patching wird möglich.
Zweitens hat sich die Reihenfolge der Upgrades innerhalb einer VCF-Instanz geändert. In VCF 9 wird zunächst der NSX-Manager aktualisiert, noch bevor vCenter und die ESXi-Hosts an der Reihe sind. Ein eigenständiges NSX-Upgrade außerhalb des VCF Lifecycle Managements wird ab VCF 9 nicht mehr unterstützt.
NSX Edge Cluster
Der NSX Edge Cluster besteht aus spezialisierten VMs, den sogenannten Edge Nodes. Diese stellen zentrale Netzwerkdienste bereit, die nicht direkt auf den ESXi-Hosts ausgeführt werden können:
- Nord-Süd-Routing über den Tier-0 Gateway,
- NAT,
- Load Balancing,
- Gateway Firewall und
- VPN.
Ein Edge-Cluster besteht aus mindestens zwei Edge-Nodes. Dies ist eine harte Anforderung, ohne die NSX keinen funktionsfähigen Cluster aufbauen kann. Die Edge Nodes sind virtuelle Maschinen, die auf ESXi-Hosts im vSphere Edge Cluster ausgeführt werden.
Ihre Verteilung ist nicht dem Zufall überlassen. NSX Failure Domains stellen sicher, dass die beiden Nodes eines Active/Standby-Paares immer auf unterschiedlichen Hosts laufen.
In VCF 9 kommt die neue NSX Edge Host Affinity-Funktion hinzu. Damit können Edge Nodes an bestimmte Host-Gruppen gebunden werden. Dies ist wichtig für Umgebungen, in denen der Edge-Cluster über mehrere Racks verteilt ist, damit die Routing-Verbindung zwischen dem Edge Node und dem physischen Netzwerk (die sogenannte BGP-Session) nicht durch ungewollte vMotion-Migrationen unterbrochen wird.
Network Connectivity Workflow
In VCF 5.x wurden Edge Nodes über den SDDC Manager bereitgestellt. In VCF 9 übernimmt der neue Network Connectivity Workflow diese Aufgabe, der sowohl aus dem NSX-Manager als auch direkt aus vCenter heraus gestartet werden kann. Der alte SDDC Manager Edge Cluster Workflow wurde in VCF 9 entfernt, die SDDC-Manager-API bleibt aber für eine Übergangszeit verfügbar.
Der Workflow läuft in drei Schritten ab.
1. Zunächst wird der Gateway-Typ ausgewählt: „Centralized Connectivity” für das „Centralized Transit Gateway” mit Edge Nodes und vollem Funktionsumfang oder „Distributed Connectivity” für das „Distributed Transit Gateway” ohne Edge Nodes. Diese Entscheidung bestimmt, welche Netzwerkdienste in der Workload-Domain zur Verfügung stehen und kann nicht nachträglich geändert werden.
2. Im zweiten Schritt werden der Edge Cluster und die einzelnen Edge-Nodes konfiguriert. Dabei werden Name, Formfaktor, Management-IP, TEP-VLAN und Uplink-Mapping festgelegt.
3. Im dritten Schritt wird die Workload-Domain-Connectivity konfiguriert, also der Tier-0-Gateway mit seinen BGP- oder statischen Routing-Parametern sowie optionale VPC-External-IP-Blocks.
Der neue Workflow bietet gegenüber VCF 5.x mehrere praktische Verbesserungen. Das TEP (Tunnel Endpoint) VLAN kann jetzt für ESXi-Hosts und Edge Nodes gemeinsam genutzt werden. Die TEP IP-Vergabe unterstützt jetzt DHCP und IP Pools zusätzlich zu statischen Adressen. Jeder Edge Node bekommt eigene dedizierte Uplink Trunk dvPortgroups, die automatisch erstellt und verwaltet werden.
Mehrere Edge Nodes können parallel bereitgestellt werden. Die neue Clone-Option ermöglicht es zudem, einen konfigurierten Edge Node als Vorlage für weitere Nodes zu verwenden, wodurch sich der Deployment-Aufwand bei homogenen Umgebungen erheblich reduziert.
Gateway Firewall
In VCF 5.x war die Gateway Firewall standardmäßig aktiv, sobald ein Tier-0- oder Tier-1-Gateway bereitgestellt wurde, auch ohne konfigurierte Regeln. In VCF 9 ist sie dagegen opt-in und wird nur aktiviert, wenn sie explizit benötigt wird. Dadurch wird der Ressourcenverbrauch auf Edge Nodes reduziert und das Design wird klarer, also „Resource Efficiency by Design“.
Fortsetzung folgt…