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 seit mehr als 20 Jahren selb­ständig als Redakteur und Autor für viele ehe­malige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buch­autor und IT-Consultant. Seit 5 Jahren ist Thomas neben seiner journa­listischen Tätig­keit haupt­beruflicher, selb­ständiger IT-Trainer für VMware und Microsoft.

    Seine Themen­schwer­punkte sind Virtua­lisierung und Cloud Com­puting, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zerti­fi­zierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas ist außerdem zertifi­zierter AWS Solu­tions Archi­tect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Admini­strator.

    Thomas führt aktuell jeden zwei­ten Mon­tag einen 4-tägigen Grund­lagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Infor­mationen und Anmel­dung über sein AWS-Blog.

    Ähnliche Beiträge

    Weitere Links