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

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:

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

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