vSphere vMotion: LACP und Distributed vSwitch


    Tags: , ,

    vMotion in Mulit-NIC-KonfigurationMultiple-NIC-vMotion kann man problem­los auch auf einem Distributed vSwitch ein­richten, was eine kon­sistente Konfi­guration der be­teiligten VMKernel-Adapter sogar er­leichtert. Sie werden in diesem Fall in­direkt über eine ent­sprechende VMKernel-Portgroup verteilt. Am Funk­tions­prinzip ä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öglich­keit noch nicht.

    Neuen VMKernel-Adapter für vMotion erstellen

    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.

    Übersicht über die VMKernel-Adapter für vMotion

    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 Funktions­weise der Last­ausgleichs­vorgänge deutlich, dass Multi-NIC-vMotion eine bessere Leistung bietet als eine aggregierte Ver­bindungs­konfi­guration.

    Der vMotion-Algorithmus verteilt nämlich den vMotion-Datenverkehr zwischen den verfügbaren VMkernel-NICs. Er berücksichtigt eine etwaige Failover-Netzwerk­konfiguration 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 Netzwerk­karte. 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) konfi­guriert sind, wählt der Quell-vMotion-Vorgang immer nur einen VMknic zum Übertragen seiner Daten aus, wie folgende Illustration von Frank Dennemann zeigt:

    Der vMotion wählt an der Quelle nur einen VMknic aus, auch wenn die NICs für vMotion mit zwei aktiven Uplinks konfiguriert sind.

    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 zusammen­gefassten Links verteilt wird. Bei Verwendung einer aggregierten Link-Konfiguration muss nämlich zwingend die IP-Hash-Last­ausgleichs­regel 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 zusammen­gefasst 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 Last­ausgleichs­richtlinie, 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

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet ist seit fast 30 Jahren selb­ständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehe­malige 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 zerti­fi­zierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grund­lagenkurse 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 Infor­mationen und Anmel­dung über sein Azure-Blog.

    Verwandte Beiträge

    Weitere Links