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 ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige und aktuelle IT-Magazine sowie Blogs.
Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.
Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.
Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Informationen und Anmeldung über sein Azure-Blog.
Verwandte 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