vSphere vMotion: LACP und Distributed vSwitch

    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).

    Keine Kommentare