vege - stock.adobe.com

NSX-T und vSphere: Die verschiedenen virtuellen Switch-Typen

NSX-T unterstützt sowohl N-VDS- als auch VDS-Switches. Doch N-VDS erfordert eigene Netzwerkadapter, während VDS alle Adapter eines einzigen Switches für alle Netzwerktypen nutzt.

Das NSX-T Data Center von VMware unterstützt ESXi-, KVM- und Bare-Metal-Server sowie Edge-Maschinen, die sich um Routing und Services kümmern. Alle benötigen einen virtuellen Layer 2 Switch in der Software. Mit NSX-T Version 3 und vSphere 7 können Sie nun beide virtuelle NSX-Switch-Typen – N-VDS und VDS – verwenden, um das Networking in NSX-T und vSphere 7 zu erleichtern.

Bei einer vSphere-Installation verfügen ESXi-Hosts über einen virtuellen Layer 2 Switch, bei dem es sich entweder um einen Standard- oder einen verteilten Switch handelt. Standard- und verteilte Switches besitzen unterschiedliche Skalierungsmöglichkeiten und Funktionen, transportieren jedoch beide Ethernet-Frames zu und von virtuellen Maschinen (VM) und dem physischen Netzwerk.

Wenn Sie die Netzwerkvirtualisierung mit dem NSX-T Data Center von VMware implementieren, muss ein separater Software-Stack den VM-Traffic managen. In einem Software-defined Data Center (SDDC) steuert die Virtualisierungssoftware das logische Switching.

Wenn Sie NSX-T Version 3 mit vSphere 7 ausführen, können Sie zwei verschiedene Arten von Switches nutzen: den NSX-T Virtual Distributed Switch (N-VDS) und den vSphere 7 Virtual Distributed Switch (VDS). Der N-VDS-Switch benötigt eigene Netzwerkadapter. Mit VDS hingegen lassen sich alle vier Netzwerkadapter eines einzigen Switches für alle Netzwerktypen verwenden.

Was Sie über den N-VDS-Switch wissen müssen

Der erste NSX-T-Switch ist der N-VDS-Switch, der ESXi-, KVM- und Bare-Metal-Server sowie Edge-Maschinen unterstützt. Abbildung 1 zeigt einen ESXi-Host, der mit einem verteilten Switch namens dvSwitch01 sowie einem NSX-T N-VDS-Switch namens Prod-Overlay-NVDS konfiguriert ist.

Abbildung 1: Switch-Konfiguration mit verteiltem Switch und NSX-T N-VDS-Switch unter vSphere ESXi.
Abbildung 1: Switch-Konfiguration mit verteiltem Switch und NSX-T N-VDS-Switch unter vSphere ESXi.

In Abbildung 1 lässt sich einer der Nachteile von N-VDS erkennen: Jeder Switch benötigt seine eigenen Netzwerkadapter. Diese Abbildung zeigt vier Uplinks auf dem verteilten Switch sowie die Adapter vmnic4 und vmnic5 auf dem N-VDS-Switch.

Dies ist ein ähnliches Problem wie bei KVM- und Bare-Metal-Servern sowie Edge-Maschinen, da jeweils nur ein Uplink je Switch verwenden werden kann. Für KVM-, Bare-Metal- und Edge-Maschinen ist N-VDS aber die einzige Wahl. Somit müssen Sie sich für das effizienteste Design entscheiden, in der Regel also ein Switch pro Transportknoten. Dadurch wird sichergestellt, dass Sie alle Adapter auf diesem Switch nutzen können.

Sie müssen ein Design erstellen, das dem erforderlichen Durchsatz und der maximalen Redundanz bei Ausfällen entspricht, wenn Sie den N-VDS-Switch verwenden. In Abbildung 1 verwendet vSphere vier Adapter für normale Networking-Zwecke und nur zwei Adapter für NSX-T. Wenn der NSX-T-Traffic den Großteil Ihrer Workloads ausmacht, sind zwei Adapter für den verteilten Switch und vier Adapter für N-VDS eine effizientere Aufteilung.

ESXi bietet mit VDS einen weiteren Switch-Typ, bei dem Sie sich nicht entscheiden müssen, wie Ihr System die Netzwerkadapter aufteilt.

NSX-T 3.0 mit vSphere 7 ermöglicht den VDS-Switch

Wenn Sie NSX-T 3 und vSphere 7 zusammen ausführen, können Sie jetzt sowohl den VDS von vSphere 7 als auch den N-VDS von NSX-T für das Networking verwenden, NSX-T fügt Ihrem Host keinen Switch hinzu, wenn Sie VDS implementieren. Vielmehr ersetzt NSX-T den vorhandenen verteilten Switch durch einen NSX-Switch.

In Abbildung 2 sehen Sie denselben verteilten Switch (dvSwitch01) wie in Abbildung 1. Nun ist er jedoch als NSX-Switch gekennzeichnet. Der Switch dvSwitch01 verfügt über die gleichen Netzwerkfunktionen wie vMotion und Management.

Abbildung 2: Verteilter vSphere-7-Switch, konfiguriert als NSX-VDS-Switch.
Abbildung 2: Verteilter vSphere-7-Switch, konfiguriert als NSX-VDS-Switch.

Das NSX-Networking funktioniert jetzt mit dem VDS-Switch. Das heißt, Sie können alle vier Netzwerkadapter des Switches für alle Netzwerktypen verwenden. Dies bietet ausreichend Bandbreite für alle Traffic-Typen und maximale Redundanzmöglichkeiten. Wenn Sie einen Host mit mehr Adaptern ausstatten, kann das System sie für alle Workloads nutzen.

VDS ist nur verfügbar, wenn Sie NSX-T 3 zusammen mit vSphere 7 einsetzen. Wenn Sie vSphere 6 und eine beliebige Version von NSX-T 2.x verwenden, ist N-VDS Ihre einzige Option. Wenn Sie ein Upgrade auf vSphere 7 mit NSX-T 3 durchführen, bleibt Ihr vorhandener N-VDS in Betrieb, und Sie können Ihren N-VDS auf VDS migrieren.

Ob Sie das Upgrade ohne Workload-Ausfallzeiten durchführen können, hängt von der Anzahl der Netzwerkadapter ab, die Ihren Hosts zur Verfügung stehen. Bei nur zwei Adaptern sollten Sie Ihre Workloads nicht auf nur einem Adapter ausführen und den anderen nutzen, um den VDS-Switch einzurichten.

Es ist besser, ein Wartungsfenster einzurichten, in dem die Workloads vom Netzwerk getrennt werden können. Auf diese Weise können Sie ein Transportprofil für den gesamten Cluster nutzen, das alle Hosts neu konfiguriert.

Alternativ dazu ist auch ein Host-weiser Ansatz möglich. Sie können VMs zwischen Hosts migrieren, was eine Rolling Migration durch einen Cluster erleichtert.

So erstellen und konfigurieren Sie NSX-Switches

NSX-T erstellt sowohl die N-VDS- als auch die VDS-Switches auf ESXi-Hosts in ähnlicher Weise. Bei vier Hosts in einem Cluster kann das System ein Transportknotenprofil verwenden. Das Transportknotenprofil konfiguriert die gesamte Definition des Switches und implementiert ihn dann auf allen Hosts im Cluster. In Abbildung 3 sehen Sie ein Beispiel für die Konfiguration einer VDS-Definition mit den notwendigen Details, wie Name und Switch-Typ.

Abbildung 3: Konfiguration einer VDS-Switch-Definition im Transportknotenprofil.
Abbildung 3: Konfiguration einer VDS-Switch-Definition im Transportknotenprofil.

Das Erstellen von N-VDS verläuft ähnlich. Wie in Abbildung 3 dargestellt, ist die Transportzone ein wesentlicher Bestandteil der N-VDS-Einrichtung. Die Transportzone legt den Umfang des Networkings fest und bestimmt, wo Segmente – oder logische Switches – verfügbar sind.

Abbildung 3 zeigt eine Transportzone namens Prod-Overlay-TZ. Das bedeutet, dass allen Hosts in allen Clustern, die die Transportzone nutzen, dieselben logischen Switches zur Verfügung stehen, um Ihren Layer-2-Networking-Bereich zu definieren.

Der Switch in Abbildung 3 verwendet eine Overlay-Transportzone. Die andere Art von Transportzone ist für VLANs, was bedeutet, dass VMs direkt mit VLANs verbunden werden, die Sie im physischen Netzwerk definieren müssen. Diese Switches sind technisch gesehen den normalen vSphere-Switches ähnlich.

Beim Overlay Networking ändert sich das Verhalten des Switches, da es einen VMkernel-Port mit der Bezeichnung Tunnel Endpoint (TEP) gibt. Dieser kapselt den Traffic von VMs und transportiert diesen Traffic zu anderen Transportknoten, etwa Hypervisoren. Dadurch unterscheiden sich NSX-Switches von normalen vSphere-Switches, weil sie sich viel einfacher automatisieren und skalieren lassen.

Es ist unwahrscheinlich, dass VMware den N-VDS-Switch aus NSX-T zugunsten des VDS mit vSphere 7 entfernen wird. Dies liegt daran, dass Bare-Metal-Server, KVM-Hosts und Edge-Maschinen weiterhin auf den N-VDS-Switch für Networking und Routing angewiesen sind.

Abbildung 4 zeigt, wie gerade ein N-VDS-Switch auf einer Edge-VM angelegt wird. Hierbei ergeben sich einige ähnliche Konfigurationen wie bei einem Switch auf einem ESXi-Host. Der N-VDS-Switch ist Teil einer Transportzone und wird mit einer TEP-Adresse konfiguriert, um am Overlay und Encapsulation Networking teilzunehmen.

Abbildung 4: Erstellen eines NSX-Edge-Switches.
Abbildung 4: Erstellen eines NSX-Edge-Switches.

Da KVM, Bare Metal und der Edge im Vergleich zu ESXi über unterschiedliche Software-Stacks haben, ist der N-VDS-Switch auf absehbare Zeit die einzige Option.

Erfahren Sie mehr über Server- und Desktop-Virtualisierung

ComputerWeekly.de
Close