Die Netzwerkkonfiguration ist einer der komplexesten und schwierigsten Aspekte in der Server-Virtualisierung und zwingt jeden Administrator, entsprechendes Netzwerk Know How aufzubauen. Der Grund: während man physische Server und Hosts über dedizierte Switches verbindet - welche explizit unterschiedliche Hardwarekomponenten darstellen - passiert bei der Virtualisierung der Großteil der Netzwerkkommunikation, sowie das Einrichten der gesamten virtuellen Netzwerkinfrastruktur in der gleichen Host-Umgebung. Damit ist es wesentlich schwieriger Sicherheit, Verfügbarkeit und Segmentierung in Einklang zu bringen und dabei den Überblick zu behalten.
VMware vSphere unterstützt den Systemverwalter dabei in vielfältiger Weise und im Vergleich zu Hyper-V auch insofern besser, dass physische Netzwerkkarten, VMkernel-Adapter und vSwitches im Web Client oder im nativen vSphere-Client an gleicher zentraler Stelle konfiguriert werden.
Bei einem komplexen Virtual-Network-Stack, wie in vSphere lassen sich drei grundlegende Funktions- und Konfigurationsebenen unterscheiden:
Die Host-Ebene
In der Host-Ebene ( physische NICs) geht es um die physischen NICs in jedem ESXi-Host, sowie deren Hardware- und System-spezifische Konfiguration. Die umfasst auch das Zusammenfassen von jeweils mehreren physischen NICs zu einer logischen Einheit, zur Erhöhung der Verfügbarkeit oder der Bandbreite (Teaming, Failover). Die physischen Netzwerkadapter fungieren als Uplink-Adapter zu den virtuellen Switches. Physische Netzwerkadapter tragen VMware-intern die Bezeichnung vmnicX. Die Nummerierung beginnt bei 0 für den ersten Adapter, also vmnic0.
Welche Ziffer hier vergeben wird ist Sache der PCI-Nummer, wobei zuerst die Onboard-Adapter berücksichtigt werden und erst anschließend PCI-Karten. Die physischen Netzwerkkarten sind ihrerseits mit physischen Switches verbunden. Dabei ist es eine Frage des gesamten Netzwerkdesigns, ob ESXi mit oder ohne VLANs betrieben wird. Beides ist möglich, ebenso wie ein Mischbetrieb. Da bei einem Betrieb ohne VLANs jedes zu separierende Netzwerksegment physisch mit dem ESXi-Host verbunden werden muss, braucht der ESXI-Host hierbei mehr physische Netzwerkinterfaces.
In Die Hypervisor-Ebene
In der Hypervisor-Ebene (virtuelle Switches) findet die eigentliche Virtualisierung statt. Der Hypervisor sorgt nicht nur für das Einrichten und Betreiben virtueller Maschinen, sondern auch dafür, dass VMs untereinander, mit der Hardware und mit dem Rest der Welt kommunizieren können. Dies geschieht mit Hilfe virtueller Switches, welche quasi virtuelle Nachbildungen physischer Layer2-Switches sind. VSphere kennt seit der Version 4 zwei verschiedene Typen von vSwitches, nämlich den vNetwork Standard Switch (vSS) und den vNetwork Distrubuted Switch (vDS). Virtuelle Switches tragen in vSphere die Bezeichnung vSwitch0, vSwitch1, bzw. dvSwitch0, dvSwitch1 u.s.w.. Beim Erstellen eines vSwitches wird dieser über die Portgruppe "Physische Adapter (Uplink)" mit einem noch nicht verwendeten physischen Netzwerkadapter und ggf. einem oder mehreren noch freien Standby-Adaptern verbunden, d. h. beide Switch-Typen setzen physische Netzwerkkarten im Server als Uplinks voraus: die jeweilige physische Netzwerkkarte entspricht quasi dem Uplink-Port eines echten Switches. Nur über diese Verbindung - die Portgruppe "Uplink" - können virtuelle Maschinen nach außen kommunizieren.
Achtung: Es ist auch möglich, einen vSwitch ohne Uplink-Ports zu betreiben. Hier angeschlossene virtuelle Maschinen können dann nicht in das physische Netzwerk kommunizieren, allerdings kommunizieren alle an diesem Switch angeschlossenen virtuelle Maschinen direkt über den vSwitch miteinander. Anders herum ist es nicht möglich, dass ein physikalischer Adapter mit mehreren vSwitches verbunden ist.
VMkernel-Adapter
Jeder vSwitch besitzt auf der "anderen Seite" je nach Switch-Art zwischen 120 (vSS) und 4086 (vDS) Ports, an welche die virtuellen Netzwerkadapter der VMs über die Portgruppe "VM Network" angeschlossen werden können. Neben der Portgruppe VM Network gibt es noch weitere Portgruppen, die nicht mit vNICs, sondern je einem Kernel-Adapter mit der Bezeichnung vmk0, vmk1 u.s.w. verbunden werden. Sie dienen dazu, den Netzwerkverkehr für die einzelnen vom Kernel zur Verfügung gestellten Netzwerkservices separieren zu können. Neben dem per Default vorhandenen Portgruppen "Physische Adapter", "VM Network" und "Management Netzwork" sind das z. B. vMotion, Fault Tolerance oder Virtual SAN. Eine gute Übersicht der Zusammenhänge liefert die Abbildung "vSphere-Standard-Switch-Architektur" von VMware.
Allerdings ist die visuelle Darstellung eines virtuellen Switches im vSphere Web Client im Reiter Verwalten im Bereich Netzwerk des in der Bestandsliste markierten Hosts ebenfalls sehr gelungen.
Etwas weniger hübsch, aber genauso aussagekräftig ist die Darstellung in nativen vSphere Client. In der folgenden Abbildung sind drei Standard-Switches eingerichtet. Die vSwitches 0 und 1 korrespondieren mit physischen Netzwerkadaptern, wobei vSwitch0 das Management Netzwerk und das erste VM Network bedient, während vSwitch1 nur für vMotion zuständig ist. Der dritte vSwitch 2 hat keine Verbindung zum physischen Netzwerk. Hier sollen VMs angeschlossen werden, die nur untereinander kommunizieren dürfen.
Portgruppen
Die Portgruppen erleichtern übrigens auch die Live-Migration einer VM (vMotion) auf einen anderen ESXi-Hosts, weil dazu auf diesem lediglich gleich benannte Portgruppen existieren müssen. Das gilt nicht für die unterliegende Konfiguration des Ziel-Netzwerks. Diese kann durchaus anders aussehen. Portgruppen dienen auch der Konfiguration des virtuellen Netzwerks im Allgemeinen, weil sich mit ihrer Hilfe zahlreiche Netzwerk-Eigenschaften sämtlicher an der betreffenden Portgruppe angeschlossenen VMs gemeinsam einrichten lassen, etwa VLAN-IDs zuordnen oder den QoS einrichten.
Die VM Ebene
In der VM-Ebene schließlich geht es um die virtuellen Netzwerkkarten der virtuellen Maschinen, mit denen der Admin beim Einrichten einer virtuellen Maschine im Assistenten meist zuerst in Berührung kommt. Hier findet das Verbinden der virtuellen Netzwerkkarte mit einem Port in der Portgruppe VM Network des jeweiligen vSwitches statt. Der Vorgang gleich in der physischen Welt den Verbinden Netzwerkadapters im jeweiligen PC mithilfe eines Patchkabels mit dem physischen Switch. Fügt der Nutzer beispielsweise im Konfigurations-Editor einer virtuellen Maschine im Web Client eine neue virtuelle Netzwerkkarte hinzu, wird diese zwar bei nur einem einzigen vorhandenen vSwitch automatisch mit dem ersten, per Default vorhandenen VM Network verbunden, hat der Admin aber zuvor zwecks Segmentierung des virtuellen Netzwerks mehrere Portgruppen für VM Networks angelegt, stehen diese auch in den Einstellungen der virtuellen Netzwerkkarte als alternatives Verbindungsziel zur Verfügung, wie folgende Abbildung zeigt:
BU: Beim Verbinden der virtuellen Netzwerkkarte (vNIC) kann der Admin das Verbindungsziel abweichend von der Default-Einstellung auch frei wählen.
Schließt der Systemverwalter mehrere VM Networks an unterschiedlichen vSwitches an, kann er das Segmentieren seines VM-Networks darüber hinaus mithilfe unterschiedlicher physischer NICs gestalten.
Netzwerkdesign
Mit Kenntnis der grundlegenden Komponenten des virtuellen Netzwerks in VMware vSphere, wie physischen NICs (vmnetX), sowie virtuellen Switches (vSwitchX) samt VMkernel-Adaptern (vmkX) für die einzelnen Portgruppen und den eigentlichen vNICs in den VMs stehen dem Administrator fast alle Möglichkeiten zum Design seines virtuellen Netzwerks zur Verfügung, wie auch in der physischen Welt. Ein Beitrag über intelligentes, erweiterbares und ggf. redundantes Netzwerkdesign sprengt zwar den Rahmen des Beitrages, trotzdem hier ein paar Anregungen:
Für ein voll redundantes Design, müssten die physischen Netzwerkkarten jedes Hyper-V-Hosts jeweils paarweise auf je zwei physische Switches verteilt werden.
Für ein Design ohne VLANs ist es in kleinen Umgebungen übliche Praxis, für jeden Kernel-Adapter, also für Management Network, VM Network, Storage oder vMotion jeweils ein Paar physische Netzwerk-Adapter im Failover-Modus zu spendieren.
Die Summe benötigter NICs beläuft sich damit schon mal von vorne herein auf 8 Karten. Soll das VM Network selbst weiter segmentiert werden, kommen weitere NIC-Paare dazu, auch wenn es in einer Virtualisierungsumgebung technisch durchaus möglich ist, alle erwähnten Funktionalitäten auf einen physischen Adapter abzubilden, indem man mehrere Kernel-Adapter im gleichen vSwitch verwendet.
Failover und Lastverteilung
Verbindet man einen vSwitch mit zwei physischen Netzwerkkarten, bietet der Netzwerkverkehr der angeschlossenen VMs Redundanz oder Lastverteilung. Hierzu genügt es, z.B. im vSphere-Client im Reiter Konfiguration im Menü Netzwerk beim gewünschten vSwitch auf Eigenschaften zu klicken, dann zum Reiter Netzwerk zu wechseln und mit einem Klick auf Hinzufügen einen weiteren noch nicht verwendeten physischen Netzwerkadapter hinzuzufügen. Dieser wird per Default der Liste bei Aktive Adapter hinzugefügt. Möchte man dagegen Failover einrichten, verschiebt man den Adapter mit der Schaltfläche Nach unten in die Liste bei Standby Adapter.
Wiederrum visuell etwa hübscher gelingt die Prozedur im Web-Client: hier markiert man im Reiter Verwalten des betreffenden Hosts den gewünschten vSwitch im Menü Virtuelle Switches im Bereich Netzwerk und klickt dann in der Symbolleiste auf das dritte Symbol von links mit dem Titel "Physischen Netzwerkadapter, die mit dem ausgewählten Switch verbunden sind, verwalten". Im Dialog "Physische Netzwerkadapter für vSwitchX verwalten" klickt man dann auf das Plus-Symbol und wählt den gewünschten physischen NIC aus der angebotenen Liste aus, der dann automatisch bei Aktive-Adapter landet. Das Verschieben zu Standby-Adapter erledigt man dann mit dem blauen Pfeilsymbol für Nach unten.
Übrigens kommunizieren alle VMs, die am gleichen vSwitch angeschlossen sind untereinander stets direkt über den vSwitch, ohne Umweg über das physische Netzwerk, egal ob Uplink-Ports vorhanden sind oder nicht.
vSphere erlaubt zwar das Einrichten mehrerer Standard-vSwitches pro Host, je nach Anzahl physikalischer NICs im Server ist es aber wie gesehen sinnvollen, den Traffic zu segmentieren und gleichzeitig Failover zu gewährleisten, indem man einen vSwitch mit zwei physischen Adaptern verbindet und die einzelnen Netzwerke über separate Portgruppen anschließt. Das per Default eingerichtete Load Balancing lässt sich dann leicht auf Failover umstellen.
Einen neuen vSwitch einrichten
Eine explizite Funktion zum Einrichten eines vSwitches existiert in vSphere nicht. Stattdessen markiert man den gewünschten Host in der Bestandsliste, navigiert rechts zum Reiter Verwalten und klickt im vSphere Web Client in Tab Netzwerk auf das Symbol für Netzwerk hinzufügen ganz links oben. Der Admin hat dann die Wahl,
einen neuen "VMkernel Netzwerkadapter",
einen "physischen Netzwerkadapter"
oder eine "Portgruppe der virtuellen Maschine für einen Standard-Switch" einzurichten.
Bei allen drei Optionen erlaubt der Assistent im nächsten Schritt das Auswählen eines vSwitches als "Zielgerät" oder das Erstellen eines neuen vSwitches, an dem die zu erstellenden VM-Portgruppe, der zu erstellende Kernel-Adapter (z.B. für vMotion- oder vSAN-Traffic) oder die physische Netzwerkkarte angeschlossen werden soll.
Beim Erstellen eines neues vSwitches vergibt vSphere die zugehörige Nummer automatisch, z. B. vSwitch1. Bei den Optionen 1 und 3 wählt man im nächsten Schritt die an den neuen vSwitch anzuschließenden physischen Netzwerkadapter durch einen Klick auf das Plus-Symbol aus und ordnet ihn je nach Bedarf dem Bereich Aktive Adapter oder Standby-Adapter zu.
Will man einen vSwitch ohne Uplink erstellen, etwa für VM-Portgruppen, die nur untereinander und mit dem Host kommunizieren sollen, übergeht man den Schritt mit Weiter. Im Folgeschritt muss der Systemverwalter lediglich eine frei wählbare Netzwerkbezeichnung für den neuen vSwitch und ggf. die VLAN-ID vergeben, wenn mit VLANs gearbeitet werden soll.
Erstellt man einen neuen vSwitch im Zusammenhang mit einem neuen VMkernel-Netzwerkadapter, erwartet der Assistent nicht nur Bezeichnung und VLAN-ID, sondern bei IP-Einstellungen auch eine Auswahl, ob der Switch via IPv4, IPv6 oder Beides konfiguriert werden soll. Ferner muss der Admin beim Erstellen eines neuen VMkernel-Adapters bei verfügbare Dienste die einzelnen Netzwerk-Services auswählen, für die der vSwitch zuständig sein soll und mit dem zu erstellenden Kernel-Adapter korrespondieren, z. B. Management-Netzwerk, vMotion, Fault Tolerance oder VSAN.
Die vSwitch-Typen im Einzelnen
Wie gesehen gibt es in VMware vSphere zwei verschiedene virtuelle Switch-Typen, den vNetwork Standard Switch (vSS) und den vNetwork Distributed Switch (vDS). Beide bilden einen ISO-Layer-2-Ethernet-Switch ab, bieten aber nicht sämtliche Eigenschaften einen physischen Layer-2-Switches. So ist z. B. STP (Spanning Tree Protocol) nicht implementiert. Den Standard Switch gibt es schon seit der ESXi Version 3.0. Der Distributed Switch wurde von VMware mit ESXI 4.0 eingeführt und mit den vSphere-Versionen 5.0, 5.1, 5.5, sowie 6.0 stetig weiter entwickelt, bzw. mit zusätzlichen Funktionen ausgestattet. Er bietet als die moderne Technologie mehr Flexibilität und deutlich mehr Funktionen. Neben der grundlegenden Layer-2-Switch-Funktionalität, sowie VLAN-Support, NIC-Streaming, CDP-Unterstützung (Cisco Discovery Protocol) und "Traffic Shaping ausgehend", die auch der Standard-Switch bietet, unterstützt der Distributed Switch unter anderem "Traffic Shaping eingehend", Net Flow, LLDP, Port Mirroring, PVLAN, Traffic-Filter, SR-IOV, LACP/LAG-Support und außerdem eine große Anzahl an Funktionen zur Netzwerküberwachung und Fehlerbehebung. Die Einzelheiten listet VMware auf seiner Produktseite auf. Leider setzt die Verwendbarkeit des Distributed Switch mindestens eine Enterprise Plus Lizenz voraus.
Der vNetwork Distributed Switch
Neben dem größeren Funktionsumfang unterscheidet sich der Distributed Switch wie der Name schon sagt auch in seiner "Bereitstellungs-Philosophie". Er arbeitet nämlich über sämtliche verbundenen Hosts in einem Datencenter hinweg und erlaubt ein zentrales Bereitstellen, Verwalten und Überwachen von virtuellen Netzwerken. Konfiguriert der Nutzer einen vSphere Distributed Switch im vCenter, wird die einmal vorgenommene Konfiguration an alle Hosts im Datacenter weitergereicht, die dem Switch zugeordnet sind. Dies erleichtert z. B. bei der Migration virtueller Maschinen zwischen Hosts das Beibehalten einer konsistenten Netzwerkkonfiguration.
Richtet man beispielsweise vMotion mit Standard-Switches ein, muss der Systemverwalter auf Details achten, wie z. B. gleich benannten Portgruppen auf den vSwitch des Ziel-Hosts, damit die Migration funktioniert. Der vNetwork Distributed Switch (vDS) hingegen funktioniert quasi wie ein "übergeordneter" Konfigurationsort im vCenter. Der Systemverwalter muss nur noch ein Mal einen dvSwitch, mit den Portgruppen und den Uplinks einrichten und vCenter erstellt dann auf jeden dem vDS zugeordneten ESXi-Host einen korrespondierenden "gewöhnlichen" Virtual Switch. Ein Beispiel: möchte der Systemverwalter auf 10 ESXi-Hosts im Cluster jeweils 20 VLANs betreiben, müsste er mit Standard-Switches manuell mindestens 200 Portgruppen einrichten.
Fazit
Vergleicht man die Möglichkeiten der Konfiguration virtueller Netzwerke in VMware vSphere mit dem vergleichsweise simplen, relativ unsicheren und unflexiblen Erstellen je eines Bridge-Devices pro NIC auf Host-Seite, wie es bei einfachen KVM-Setups häufig zu finden ist, bietet der vNetwort-Stack von vSphere nahezu alle fortgeschrittenen Funktionen der physischen Welt.
Das gilt allerdings inzwischen (ab Hyper-V 3.1 in Windows Server 2012R2) auch für Microsoft und Citrix XenServer 6.5. Auch Red Hat Enterprise Virtualization bietet einen leistungsfähigen Virtual Network Stack. Bei anderen Open-Source-Virtualierungslösungen kann man oft nachhelfen und etwa nachträglich Open vSwitch installieren, etwa in der bei KMUs beliebten quelloffenen Enterprise Virtualisierungs-Lösung Proxmox Virtual Envrionment, was sehr gut dokumentiert ist. (hal)