Tags: vSphere, Netzwerk, Load Balancing
Das von VMware schon 2003 entwickelte vMotion erlaubt einen unterbrechungslosen Umzug von laufenden virtuellen Maschinen zwischen ESXi-Servern, etwa für die Hardware-Wartung oder zur manuellen bzw. automatischen (DRS) Lastverteilung. Die parallele Nutzung mehrerer Netzwerkkarten beschleunigt diesen Vorgang.
vMotion ist das eigentliche Killer-Feature, das aus einem Produkt für die Server-Konsolidierung eine Business-Continuity-Lösung machte. Mit vMotion muss nämlich ein Rechenzentrum keinen Ausfall von Anwendungen mehr hinnehmen, nur weil einige Infrastrukturkomponenten ersetzt werden müssen.
VMware hat das vMotion-Feature über die Jahre immer weiter ausgebaut. Hier die technologische Timeline zu vMotion bis vSphere 6.0, noch ohne Encrypted vMotion, das in der Version 6.5 hinzukam:
Grundlegendes Netzwerk-Design für vMotion
Vor vSphere 5 war das Entwerfen eines vMotion-Netzwerks relativ einfach. Man wählte nach Möglichkeit die schnellste physische Netzwerkkarte aus und fügte diese einem vMotion-Kernel-Adapter (VMknic) hinzu. So unterstützte beispielsweise schon vSphere 4.x Netzwerke mit 1 GB und 10 GB.
Die Einrichtung in Kurzform:
- VMkernel-Adapter auf einen Standard-vSwitch erstellen
- vMotion-Checkbox aktivieren
- IP-Adresse von Quell- und Ziel-Host im gleichen Subnetz, ggf. auch gleiches VLAN
- Zuweisen einer physikalischen NIC
Multiple-NIC-vMotion
vSphere verteilt seit der Version 5.x vMotion-Vorgänge stets auf alle dafür verfügbaren Netzwerkkarten. Das gilt sowohl für eine einzelne als auch für mehrere gleichzeitige VM-Migrationen. So lässt sich durch Verwenden mehrerer NICs die Dauer eines vMotion-Vorgangs reduzieren.
Das bietet gleich mehrere Vorteile:
Manuelle vMotion-Prozesse: Weist man dem vMotion-Prozess indirekt mehr Bandbreite zu, verkürzt das allgemein die Migrationszeiten.
DRS-Lastausgleich: Aufgrund der kürzeren Zeit pro Migration und der höheren Anzahl der gleichzeitigen vMotion-Prozesse reduziert DRS bei Multiple-NIC-vMotion die Anzahl der Lastausgleichsvorgänge zwischen zwei Lastausgleichsläufen.
Dies kommt wiederum dem Load-Balancing des Clusters insgesamt zugute. Ein besserer Lastausgleich bewirkt eine höhere Verfügbarkeit von Ressourcen für die virtuellen Maschinen, was zu einer besseren Leistung für die Anwendungen führt.
Wartungsmodus: Kürzere Migrationszeiten bedeuten auch, dass ein einzelner Host weniger Zeit benötigt, um in den Wartungsmodus zu wechseln. Mit einem höheren Konsolidierungsgrad nimmt insgesamt die Zeit zu, die für die Migration aller virtuellen Maschinen vom Host erforderlich ist.
Multi-NIC-Setup
Der VMotion-Prozess nutzt für den Lastausgleich immer den VMKernel-Port (VMknic), anstatt Pakete direkt an eine physische Netzwerkkarte zu senden. Um also mehrere NICs für vMotion verwenden zu können, benötigt man mehrere VMKernel-Adapter.
Dabei ist für die Failover-Reihenfolge und Lastausgleichsrichtlinie Folgendes zu berücksichtigen:
- Jeder VMknic darf nur eine aktive Netzwerkkarte verwenden. Damit ist die einzige zulässige Lastausgleichsrichtlinie "Route basierend auf dem ursprünglichen virtuellen Port" (Route based on virtual port id).
- Dieses Setup schließt die beiden Regeln für den physischen NIC-Lastausgleich ("IP-Hash" oder "Lastausgleichsrichtlinie basierend auf der physischen Last (LBT)" (nur für Distributed vSwitch) aus. Damit ist die einzige sinnvolle Failover-Reihenfolge Active/Standby.
Der Grund dafür liegt in der Funktionsweise des vMotion-Lastausgleichs, der seinen eigenen Algorithmus nutzt und nicht über eine der beiden physischen Lastausgleichsregeln erfolgt. Unter anderem deswegen wird der vMotion-Traffic auf einem eigenen VMKernel-Adapter mit "vMotion" getaggt.
Da vMotion davon ausgeht, dass unter jeder VMknic nur eine einzelne physische NIC liegt, stellt das Senden von Daten über einen bestimmten VMknic sicher, dass vMotion die Daten über exakt diesen dedizierten physischen NIC überträgt.
Konfiguriert man hingegen die physischen NICs in einem Lastausgleichsmodus (IP Hash-Regel mit zwei aktiven VMknic), dann kann das die Logik auf der Ebene von vMotion beeinträchtigen. Dieses kann dann nämlich nicht vorhersagen, welche physische Netzwerkkarte vom VMknic verwendet wird.
Unter Umständen wird dann der gesamte VMotion-Datenverkehr über dieselbe Netzwerkkarte gesendet, selbst wenn Motion die Daten an verschiedene VMknics schickt.
In der obigen Abbildung werden trotzdem zwei Netzwerkkarten pro VMKernel-Adapter für vMotion verwendet, hier aber jeweils einer davon als Failover-Adapter. Dieser kann bei Ausfall des aktiven Adapters die Last übernehmen. Der Lastausgleich findet trotzdem über die Kernel-Adapter statt.
Wollte man für vMotion nur einen VMKernel-Adapter mit zwei aktiven physischen Netzwerkkarten konfigurieren, dann würde der Konfigurationsdialog dies zwar nicht verhindern, aber der gesamte vMotion-Traffic liefe aber dann immer nur über ein und dieselbe physische NIC.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet seit mehr als 20 Jahren selbständig als Redakteur und Autor für viele ehemalige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buchautor und IT-Consultant.
Seit 5 Jahren ist Thomas neben seiner journalistischen Tätigkeit hauptberuflicher, selbständiger IT-Trainer für VMware und Microsoft.
Seine Themenschwerpunkte sind Virtualisierung und Cloud Computing, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zertifizierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas ist außerdem zertifizierter AWS Solutions Architect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Administrator.
Thomas führt aktuell jeden zweiten Montag einen 4-tägigen Grundlagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Informationen und Anmeldung über sein AWS-Blog.
Ähnliche Beiträge
- vMotion mit mehreren NICs: Verbindungsgeschwindigkeit, Failover-Anordnung, Standard-Schnittstelle
- Network Load Balancing (NLB) für Windows konfigurieren
- vSphere mit Tanzu auf Basis von vSphere-Networking (Distributed vSwitch) einrichten
- VMware vSphere: Hyperkonvergente Cluster einrichten, VMs hochverfügbar machen, Last verteilen mit DRS
- vMotion-Tuning: Network I/O-Control und eigener TCP/IP-Stack
Weitere Links