vSwitch – Virtuelle Netzwerke mit System aufbauen

Wer vSphere in einer Enterprise-Umgebung einsetzt will, muss das Design seines virtuellen Netzwerks genauso sorgfältig zu planen, wie in der realen Welt. Nur so lassen sich Sicherheit, Ausfallsicherheit und Performance optimieren. Der vNetwork-Stack von vSphere bietet alles, was dazu notwendig ist. [...]

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.

Die Switch-Architektur in VMware vSphere/ESXi. (c) tecchannel.de

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.

Die visuelle vSwitch-Darstellung im nativen vSphere-Client. (c) tecchannel.de

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.


Mehr Artikel

Gregor Schmid, Projektcenterleiter bei Kumavision, über die Digitalisierung im Mittelstand und die Chancen durch Künstliche Intelligenz. (c) timeline/Rudi Handl
Interview

„Die Zukunft ist modular, flexibel und KI-gestützt“

Im Gespräch mit der ITWELT.at verdeutlicht Gregor Schmid, Projektcenterleiter bei Kumavision, wie sehr sich die Anforderungen an ERP-Systeme und die digitale Transformation in den letzten Jahren verändert haben und verweist dabei auf den Trend zu modularen Lösungen, die Bedeutung der Cloud und die Rolle von Künstlicher Intelligenz (KI) in der Unternehmenspraxis. […]

News

Richtlinien für sichere KI-Entwicklung

Die „Guidelines for Secure Development and Deployment of AI Systems“ von Kaspersky behandeln zentrale Aspekte der Entwicklung, Bereitstellung und des Betriebs von KI-Systemen, einschließlich Design, bewährter Sicherheitspraktiken und Integration, ohne sich auf die Entwicklung grundlegender Modelle zu fokussieren. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*