VMware

VCF9 – die Grundlagen der Netzwerk-Architektur

Veröffentlicht am

In den beiden vorherigen Beiträgen ging es um das neue Netzwerkmodell von VCF 9 und die Beschreibung der operativen NSX-Komponenten. Dieser Beitrag dient als konzeptionelle Grundlage und bildet somit das Fundament für Teil 1 und Teil 2.

Was ist ein Overlay?

Die meisten klassischen Rechenzentrumsnetze basieren auf VLANs, bei denen die physische Netzwerkinfrastruktur auf mehrere logische, voneinander unabhängige Teilnetzwerke aufgeteilt wird. Ein VLAN ist an die physische Netzwerkinfrastruktur gebunden. Jeder Switch auf dem Pfad muss das VLAN kennen. Die Anzahl ist auf 4094 nutzbare VLAN-IDs begrenzt und eine Erweiterung über Standortgrenzen hinweg ist mit hohem Aufwand verbunden. In einer Umgebung, in der Applikationsteams im Self-Service eigene, isolierte Netze erstellen sollen, stellt dieses Modell ein Hindernis dar.

NSX löst dieses Hindernis mithilfe eines Overlay-Netzwerks. Die Grundidee dabei ist, dass das logische Netzwerk vollständig von der physischen Verkabelung entkoppelt ist. Die virtuellen Netzwerke der Workloads existieren nur noch als Software-Konstrukt. Das physische Netzwerk, das sogenannte Underlay, muss lediglich IP-Konnektivität zwischen den Hosts bereitstellen und einen ausreichend großen MTU unterstützen. Aus Sicht des OSI-Modells spannt NSX virtuelle Layer-2- und Layer-3-Netze auf.

Technisch basiert das Overlay-Netzwerk auf der Kapselung. Ein Ethernet-Frame, den eine VM verschickt, wird beim Verlassen des Hosts in ein zusätzliches Transportpaket verpackt und am Zielhost wieder entkapselt. Das physische Netzwerk sieht dabei nur die äußere Hülle, also den normalen IP-/UDP-Verkehr zwischen den TEPs, und muss nichts über die darin transportierten logischen Netze wissen. NSX verwendet für die Kapselung das Geneve-Protokoll. Die Endpunkte, zwischen denen diese Kapselung stattfindet, werden als TEPs (Tunnel Endpoints) bezeichnet.

Geneve und die TEPs

Geneve steht für „Generic Network Virtualization Encapsulation” (RFC 8926) und wird, wie bereits erwähnt, als Kapselungsprotokoll für den Overlay-Verkehr verwendet. Es hat in NSX das ältere VXLAN abgelöst und unterscheidet sich von diesem vor allem durch ein erweiterbares Metadatenfeld im Header. NSX nutzt dieses Feld, um zusätzliche Informationen wie die Zugehörigkeit zu einem logischen Segment oder Kontextinformationen für die Distributed Firewall zu transportieren. Geneve verwendet außerdem eine logische Netzwerkkennung, die theoretisch bis zu 16 Millionen logische Segmente ermöglicht, im Gegensatz zu 4094 verfügbaren VLAN-IDs, und dabei weitgehend unabhängig von der physischen Netzwerktopologie ist.

Ein TEP (Tunnel Endpoint) ist der Punkt, an dem die Geneve-Kapselung beginnt und endet. Jeder ESXi-Host, der über NSX-Overlay kommuniziert, besitzt mindestens einen TEP. Auch jeder Edge-Knoten hat eigene TEPs. Im Kern ist ein TEP eine IP-Adresse auf einem dedizierten VMkernel-Interface (beim Host) bzw. einer internen Schnittstelle auf dem Edge Node.

Es funktioniert wie folgt: verschickt beispielsweise VM1 auf Host A ein Paket an VM2 auf Host B, läuft das so ab: Der TEP von Host A nimmt den Frame der VM, verpackt ihn in ein Geneve-Paket mit der TEP-IP von Host B als Ziel, und schickt ihn als gewöhnlichen IP-Verkehr durch das physische Netz. Der TEP von Host B empfängt das Paket, entfernt die Geneve-Kapselung und stellt den ursprünglichen Frame an VM2 zu. Aus Sicht der beiden VMs befinden sie sich im selben Netz, tatsächlich liegen zwischen ihnen mehrere physische Switches.

Die TEP-IP-Vergabe wurde in VCF 9 flexibler. Wie in Teil 2 beschrieben, unterstützt der neue Network Connectivity Workflow neben statischen Adressen jetzt auch DHCP und IP Pools, und das TEP-VLAN kann von ESXi-Hosts und Edge Nodes gemeinsam genutzt werden. Mit VCF 9.1 lässt sich der Overlay-TEP zudem direkt aus vCenter wie ein gewöhnlicher VMkernel-Adapter konfigurieren, was die ESXi-Hostkonfiguration an einer zentralen Stelle bündelt.

Die TEPs sind ausschließlich für die Konnektivität zuständig und transportieren Pakete zwischen den Transport Nodes. Die Sicherheit, also das Filtern dieser Pakete, übernimmt die Distributed Firewall. Beide Funktionen arbeiten zusammen, sind innerhalb von NSX jedoch getrennte Mechanismen.

Management, Control und Data Plane

In NSX, wie in den meisten anderen SDN-Produkten, werden die Funktionen in drei Ebenen aufgeteilt.

Management Plane

Die Management Plane ist die Konfigurations- und Verwaltungsebene. Sie wird durch den NSX Manager repräsentiert und kann über die NSX-eigene UI und API bedient werden, in VCF 9 zunehmend auch aus vCenter und VCF Operations heraus.

Wenn ein Administrator ein Segment anlegt, eine Firewall-Regel definiert oder eine VPC erstellt, landet diese Konfiguration (Absicht) zunächst hier. Die Management Plane übersetzt die Konfiguration anschließend in einen realisierbaren Zustand und übergibt ihn an die Control Plane.

Control Plane

Die Control Plane verteilt den Netzwerkzustand. Sie berechnet, welcher Host welche Informationen über das aktuelle Netzwerk benötigt, an welchem TEP welche VM hängt, welche MAC-Adresse wo zu erreichen ist und wie die Routing-Tabellen aussehen müssen. Anschließend schiebt sie diesen Zustand an die ausführenden Komponenten. NSX unterteilt die Control Plane in zwei Teile:

Die Central Control Plane (CCP) läuft im NSX Manager und ist die zentrale Recheninstanz.

Die Local Control Plane (LCP) läuft auf jedem Transport Node, also auf jedem ESXi-Host und jedem Edge Node, und setzt den von der CCP empfangenen Zustand lokal um.

Data Plane

Die Data Plane ist die ausführende Ebene des Netzwerks. Sie ist keine einzelne Komponente (Dienst, VM oder Prozess), sondern umfasst die Komponenten, die den eigentlichen Paketverkehr verarbeiten und die von der Control Plane berechneten Zustände umsetzen. Dazu gehören die ESXi-Hosts mit ihren TEPs und ihrem verteilten Forwarding, sowie die Edge Nodes und weiteren Transport Nodes.

Ein Transport Node ist ein System, das am NSX-Datenverkehr teilnimmt und Teil des Overlays ist. Dazu gehören sowohl ESXi-Hosts als auch Edge Nodes. (mehr dazu weiter im Text)

Edge Nodes sind spezialisierte Transport Nodes für zentrale Netzwerkdienste wie Tier-0-Routing, NAT oder den Übergang ins physische Netzwerk. In der Praxis werden sie meist als virtuelle NSX-Edge-Appliances auf ESXi betrieben oder als Bare-Metal-Edge auf dedizierter Hardware.

Aus Hochverfügbarkeitssicht ist die Trennung dieser drei Ebenen entscheidend. Fällt die Management Plane aus, sind keine Konfigurationsänderungen mehr möglich. Fällt die Control Plane aus, können keine neuen Zustandsänderungen mehr verteilt werden. Der bestehende Datenverkehr läuft jedoch weiterhin, da die Data Plane mit dem zuletzt bekannten Zustand autonom weiterarbeitet. Erst der Ausfall einzelner Data-Plane-Komponenten kann unmittelbar den Paketverkehr beeinträchtigen.

Kommunikationspfade: Manager > Edge > Host > VM

Die drei Ebenen spiegeln sich auch in den Kommunikationspfaden zwischen den NSX-Komponenten wider. Der Konfigurationsfluss läuft dabei von oben nach unten. Der NSX Manager nimmt die gewünschte Konfiguration entgegen, die Central Control Plane (CCP) berechnet daraus den benötigten Netzwerkzustand und verteilt ihn an die Local Control Plane (LCP) auf den ESXi-Hosts und Edge Nodes. Diese setzen den empfangenen Netzwerkzustand anschließend lokal um.

Der eigentliche Datenverkehr läuft dagegen direkt zwischen den Transport Nodes. Dabei unterscheidet NSX grundsätzlich zwischen zwei Verkehrsrichtungen: Ost-West- und Nord-Süd-Verkehr.

Ost-West vs. Nord-Süd

Der Ost-West-Verkehr bezeichnet die Kommunikation zwischen Workloads innerhalb der NSX-Umgebung (VM zu VM). Dieser Verkehr verlässt die NSX-Umgebung nicht.

Die Kommunikation wird folgendermaßen auf den ESXi-Hosts abgewickelt: Liegen Quelle und Ziel auf demselben Host, bleibt das Paket im Hypervisor. Liegen sie auf verschiedenen Hosts, geht es über den Geneve-Tunnel von TEP zu TEP, wie oben beschrieben.

Das Routing zwischen logischen Segmenten erledigt dabei der Distributed Router. Der Distributed Router ist eine verteilte Routingfunktion von NSX. Er läuft direkt auf den ESXi-Hosts und übernimmt das Routing zwischen logischen Segmenten lokal auf dem Host. In diesem Fall wird weder ein Edge Node noch ein Umweg über eine zentrale Instanz benötigt.

Beim Nord-Süd-Verkehr handelt es sich um die Kommunikation zwischen der NSX-Umgebung und der Außenwelt, also dem physischen Netzwerk, anderen Rechenzentren und dem Internet. Dieser Verkehr muss die Grenze des Overlays überschreiten, und genau das ist die Aufgabe des Tier-0 Gateway, welches auf den Edge Nodes läuft.

Das Tier-0 Gateway baut per BGP eine Routing-Nachbarschaft („Peering“) zum physischen Router bzw. Top-of-Rack-Switch auf und tauscht darüber automatisch Routinginformationen aus.

Transport Zones

Mit Transport Zones wird definiert, auf welchen Transport Nodes logische Netzwerke verfügbar sind. Damit legen sie fest, welche ESXi-Hosts und Edge Nodes bestimmte Segmente nutzen und transportieren können. Ein Segment ist nur auf den Transport Nodes vorhanden, die der entsprechenden Transport Zone zugeordnet sind. Es gibt zwei Typen der Transport Zonen.

Die Overlay Transport Zone umfasst die Geneve-basierten Segmente, das eigentliche Overlay, in dem die Workloads betrieben werden.

Die VLAN Transport Zone umfasst VLAN-basierte Netze und wird vor allem für die Uplinks der Edge Nodes zum physischen Netzwerk verwendet, also an den Stellen, an denen der Tier-0 sein BGP-Peering aufbaut.

Ein Transport Node kann mehreren Transport Zones gleichzeitig angehören. Dadurch ist es möglich, Netzwerke gezielt auf bestimmte Hosts oder Edge Nodes zu beschränken, anstatt sie unnötig über die gesamte NSX-Umgebung auszudehnen.

HA-Modi: Active/Standby und Active/Active

Die Dienste auf einem Edge Cluster lassen sich in zwei Hochverfügbarkeitsmodi betreiben.

Im Active/Standby-Modus ist stets nur ein Edge Node aktiv. Auf dem zweiten Node wird der Zustand synchron gehalten und im Falle eines Ausfalls der auf der aktiven Node übernimmt er dessen Rolle.

Dieser Modus ist für zustandsbehaftete Dienste wie NAT, Gateway-Firewall oder Load Balancing zwingend erforderlich, da diese einen konsistenten Verbindungszustand voraussetzen. Dieser lässt sich nicht ohne Weiteres auf mehrere aktive Knoten verteilen.

Im Active/Active-Modus sind mehrere Edge Nodes gleichzeitig aktiv und teilen die Last untereinander. Das erhöht den Durchsatz, eignet sich jedoch nur für zustandsloses Routing.

Mit VCF 9.1 wurde die Skalierbarkeit dieses Modells weiter ausgebaut. Das Tier-0 Gateway wurde die Obergrenze für Active/Active- von zwei auf acht Edge Nodes erweitert, wodurch sich der Nord-Süd-Durchsatz deutlich erhöhen lässt.

Placement Modelle

Wo die Edge Nodes laufen bzw. platziert werden, ist eine Designentscheidung, für die es drei gängige Optionen gibt:

Dediziertes Modell: Die Edge Nodes laufen in einem eigenen Edge-Cluster, der sowohl vom Management als auch vom Compute getrennt ist. Dieses Modell ist zwar das „sauberste“, aber auch ressourcenintensivste und somit ideal für größere produktive Umgebungen.

Collapsed Management/Edge Modell: In diesem Fall teilen sich die Edge Nodes und die Management-Komponenten dieselben Hosts. Dies ist ein weit verbreiteter Kompromiss für kleinere bis mittlere Umgebungen, in denen sich ein eigener Edge-Cluster wirtschaftlich nicht lohnt.

Collapsed Compute/Edge Modell: Die Edge Nodes laufen auf denselben Hosts wie die eigentlichen Compute-Workloads (User-VMs). Das kann zwar Hardware-Ressourcen sparen, setzt aber eine strikte Ressourcenplanung voraus, damit die kritischen Edge-Routing-Dienste nicht mit den Workloads der User um Ressourcen konkurrieren.

Das Gesamtbild

Kommt noch…

Hier finden Sie ein offizielles Poster zur Architektur von VMware Cloud Foundation.

Quellen

, , , , , , , , , ,