vMotion mit mehreren NICs: Verbindungsgeschwindigkeit, Failover-Anordnung, Standard-Schnittstelle

    vSphere vMotionMöchte man vMotion mit Last­ausgleich über mehrere VMKnic be­treiben, dann muss jede physische Netzwerk­karte im gesamten vMotion-Netzwerk auf allen Hosts eines Clusters auf die gleiche Weise konfiguriert sein. Zu den relevanten Para­metern zählen hier Ver­bindungs­geschwin­digkeit, MTU oder Duplex-Modus.

    vCenter Server ist in Bezug auf korrekt konfiguriertes vMotion sehr konservativ und reduziert die Anzahl gleichzeitiger vMotion-Vorgänge auf nicht konsistent konfigurierten Hosts automatisch auf 2, unabhängig von der verfügbaren Band­breite.

    Natürlich müssen auch sämtliche  vMotion-VMknics im selben Subnetz sein, denn vMotion unterstützt keine ge-routeten Topologien, auch wenn es theoretisch möglich wäre, statische Routen festzulegen.

    NIC-Zahl

    Eine Erhöhung der NIC-Zahl für vMotion führt nicht automatisch zu mehr gleichzeitig möglichen vMotion-Vorgängen, auch wenn die Verwendung mehrerer Netzwerk­karten die verfügbare Bandbreite für VM-Migration erhöht.

    Grundsätzlich sind immer nur vier gleichzeitige vMotion-Vorgänge bei Verwendung eines 1-GBit-Adapters und maximal acht bei 10-Gbit-Uplinks möglich. Die Erhöhung der Bandbreite verringert jedoch die Dauer jeder einzelnen vMotion. Eine korrekte Multi-NIC-vMotion-Konfiguration sähe demnach so aus:

    Der Lastausgleich erfolgt auf Ebene der VM-Kernel-Adapter und nicht der physischen NICs.

    Verbindungsgeschwindigkeit

    Die maximal vier bzw. acht gleichzeitigen vMotion-Vorgänge auf einem Host mit einem Netzwerk von 1 GBit/s bzw. 10 GBit/s hängen von der erkannten Verbindungs­geschwindig­keit ab. Die Betonung liegt auf "erkannt".

    Als Beispiel sei HPEs Flex-Technologie angeführt. Diese setzt ein hartes Limit für die Flexibilität, was dazu führt, dass die gemeldete Verbindungs­geschwindig­keit der konfigurierten Bandbreite auf der virtuellen Flex-Verbindung entspricht oder sogar darunter liegt.

    In diesem Fall bietet HPE Flex zwar mehr Bandbreite pro VMotion-Prozess, erhöht jedoch nicht die Anzahl gleichzeitiger VMotion-Operationen.

    Die vMotion-Grenzwerte für mehrere NICs werden immer von der langsamsten verfügbaren NIC bestimmt. Nimmt der Nutzer also eine 1Gb/s-Netzwerk­karte in seine 10-Gb/s-VMotion-Konfiguration auf, ist dieser Host auf maximal vier gleichzeitige VMotion-Vorgänge beschränkt.

    Failover-Anordnung

    Die vernünftigste Failover-Order bei Multiple-NIC-vMotion ist Active/Standby. Dabei drängt sich allerdings die Frage auf, warum nicht einfach Active/Unused nehmen? Schließlich ist das für iSCSI-Storage-Multipathing auf Basis des Software-iSCSI-Adapters und mehreren VMKnics für die so erzwungene dedizierte Portbindung so erforderlich.

    Denkt man etwas genauer darüber nach, könnte man meinen, dass die Standby-Option keinen Vorteil bringt, weil der Lastausgleich ja gar nicht auf Basis der physischen Adapter abgewickelt wird und jeder VMKernel-Adapter ohnehin nur auf einer NIC arbeitet. Der Grund, trotzdem Active/Failover zu wählen, liegt in der Wahl des so genannten Default-Interfaces. Dazu müssen wir etwas ausholen.

    Default-Interface

    Für den Lastausgleich von VMotion ist ein eigener Algorithmus zuständig. Da sich vMotion auf die VMknic-Schicht statt auf die physische Schicht konzentriert, kümmert sich die vMotion-Lastausgleichslogik aber nicht um den Verbindungs­status oder den Zustand der physischen Netzwerk­karte.

    Ein physischer Standy-Adapter für einen VMotion-VMKernel-Adapter verhindert beim Ausfall einer physischen NIC, dass vMotion seinen Default-VMKernel-Adapter behält.

    Der Algorithmus wählt einfach nur geeignete VMknics für die Verteilung von Netzwerk­paketen und geht dabei davon aus, dass die VMknics grundsätzlich Konnektivität haben. Allerdings deklariert der vMotion-Algorithmus, auch wenn er mehrere VMknics zum Lastausgleich des Daten­verkehrs verwendet, immer genau einen davon als so genannte Standard­schnittstelle und bevorzugt diese für die "Verwaltung" der Verbindung.

    Daher ist es bei VMKernel-Adaptern mit  mehrere physische Netzwerk­karten sinnvoll, den Ausfall einer physischen Netzwerk­karte durch ein Standby-Interface zu kompensieren, weil das Default-Interface dann weiter verfügbar bleibt und keine Verbindungs­probleme auftreten, wenn das es eine physische Netzwerk­karte verliert.

    Jumbo-Frames

    VMware empfiehlt in seinen im Rahmen der optimalen Vorgehensweisen für vMotion-Netzwerke außerdem das Aktivieren einer MTU von 9000 (Jumbo Frames) für alle Netzwerk­geräte im vMotion-Pfad.

    Das schließt nicht nur die physischen Netzwerk­karten ein, sondern auch physische und virtuelle Switches.

    Eine Multi-NIC-vMotion-Konfiguration ist insgesamt etwas komplexer als vMotion-Netzwerke mit einzelnen NICs. Allerdings profitiert man insgesamt von ihr in vielerlei Hinsicht. Durch die Beschleunigung von vMotion kann DRS mehr Last­ausgleichs­vorgänge pro Aufruf planen, und durch die größere Bandbreite kann der Host den Übergang zum Wartungsmodus schneller abschließen.

    Keine Kommentare