Tags: vSphere, Load Balancing, Hochverfügbarkeit
Multiple-NIC-vMotion kann man problemlos auch auf einem Distributed vSwitch einrichten, was eine konsistente Konfiguration der beteiligten VMKernel-Adapter sogar erleichtert. Sie werden in diesem Fall indirekt über eine entsprechende VMKernel-Portgroup verteilt. Am Funktionsprinzip ändert sich aber dadurch nichts.
Für das Erstellen der eigentlichen Kernel-Adapter auf dem Distribution vSwitch (DVS) muss man derzeit noch den vSphere Web Client (Flash-Client) verwenden, der HTML5-basierte vSphere Client bietet diese Möglichkeit noch nicht.
Hier wiederholt man im Assistenten Add and Manage Hosts die Prozedur für das Erstellen neuer Kernel-Adapter für alle beteiligten Hosts oder benutzt den Template-Modus.
Das Resultat, die vom DVS erzeugten Standard-Switches (Hidden-Switches), kann man sich dann pro Host wieder im neuen vSphere Client ansehen.
Network-I/O-Control
Um eine bessere Auslastung der beteiligten NICs zu erreichen, könnten Inhaber einer Enterprise-Plus-Lizenz auch auf die Idee kommen, LACP (auch "Etherchannel" genannt) für den Lastausgleich zu verwenden, um die Bandbreite für vMotion-Vorgänge zu erhöhen.
Allerdings wird auch hier angesichts der Funktionsweise der Lastausgleichsvorgänge deutlich, dass Multi-NIC-vMotion eine bessere Leistung bietet als eine aggregierte Verbindungskonfiguration.
Der vMotion-Algorithmus verteilt nämlich den vMotion-Datenverkehr zwischen den verfügbaren VMkernel-NICs. Er berücksichtigt eine etwaige Failover-Netzwerkkonfiguration auf der physischen Ebene nicht für den Lastausgleich, auch wenn eine solche aus anderen Gründen Sinn macht (Default Interface). vMotion erwartet vielmehr, dass eine VMknic immer von einem einzigen aktiven physischen NIC unterstützt wird.
Werden also Daten an den VMknic gesendet, durchläuft der Datenverkehr immer eine dedizierte physische Netzwerkkarte. Hierbei ist wichtig zu verstehen, dass der vMotion-Verkehr tatsächlich durch alle beteiligten VMknics fließt.
Das Migrieren einer virtuellen Maschine von einem mit Multi-NIC-vMotion konfigurierten Quell- auf einen Ziel-Host mit nur einer einzigen vMotion-VMknic führt automatisch zur Verwendung nur eines einzigen VMKernel-Adapters auf dem Quell-Host.
Auch wenn die einzelnen NICs für vMotion mit zwei aktiven Uplinks (zum Beispiel Link Aggregation Groups (LAGs) im Falle von LACP) konfiguriert sind, wählt der Quell-vMotion-Vorgang immer nur einen VMknic zum Übertragen seiner Daten aus, wie folgende Illustration von Frank Dennemann zeigt:
Demnach bringt uns LACP bei vMotion nicht wirklich weiter, weil auch die Art des verwendeten Hashing-Algorithmus für den Lastausgleich eine Rolle spielt. Gemeint ist damit, wie der Datenverkehr auf die zusammengefassten Links verteilt wird. Bei Verwendung einer aggregierten Link-Konfiguration muss nämlich zwingend die IP-Hash-Lastausgleichsregel für die Portgruppe ausgewählt werden.
Möchte man zwei Etherchannels für das vMotion-Netzwerk verwenden, könnte man annehmen, dass 2x1 Gb/s in einer Pipe zusammengefasst besser sind als 2 x 1 Gb/s in einer Multiple-NIC-Konfiguration. Da sich vMotion aber wie gesehen immer nur um VMknics und nicht um einzelne physische NICs kümmert, wird der gesamte Datenverkehr an den VMknic gesendet.
Was aber auf einem DVS stattdessen durchaus Sinn macht, ist die Verwendung von VLANs mit verschiedenen Portgruppen zusammen mit Network I/O-Control (NIOC) und der Lastausgleichsrichtlinie, die auf der Auslastung der physischen NICs basiert (auch als lastbasiertes Teaming oder LBT bezeichnet).
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
- VMware vSphere: Hyperkonvergente Cluster einrichten, VMs hochverfügbar machen, Last verteilen mit DRS
- vSphere Proactive HA, Quarantäne-Modus und DRS mit vFlash
- VMware vSphere DRS: Affinitätsregeln
- Network Load Balancing (NLB) für Windows konfigurieren
- vSphere mit Tanzu auf Basis von vSphere-Networking (Distributed vSwitch) einrichten
Weitere Links