Bandbreitenausnutzung bei 10 GBit/s-Netzwerkadaptern

Für die Verbindung von zwei physischen Hyper-V-Hosts eignet sich ein Ethernet-Netzwerk mit 10 GBit/s sehr gut. Denn wer im Zuge einer Live Migration ganze virtuelle Maschinen (VMs) umziehen möchte, der benötigt eine hohe Bandbreite, um den Umzug der VMs möglichst schnell zu absolvieren. Aber zudem ist noch ein virtueller Netzwerkadapter im „Verwaltungs-Betriebssystem“ nötig. Doch dann stehen nicht mehr die kompletten 10 GBit/s an Bandbreite für die Live Migration zur Verfügung. Zu diesem Themenkomplex erläutert John Savill die Konfiguration in seiner Testumgebung.

Das Thema Netzwerkverbindungen beim Hyper-V erweist sich in der Praxis als recht komplex. Denn zusätzlich zu den „normalen“ physischen Verbindungen kommen noch die virtuellen Netzwerkadapter sowie die Konfiguration des virtuellen Hyper-V-Switches mit ins Spiel. In der Testumgebung kommen zwei Hyper-V-Hosts zum Einsatz, die beide über einen Netzwerkadapter mit 10 GBit/s verfügen. Zunächst wurden beide 10-GBit/s-Adapter mit statischen IP-Adressen konfiguriert und es wurde zudem vorgesehen, dass die Live Migration über diese Netzwerkverbindung erfolgen soll. Zu diesem Zeitpunkt ist noch kein Hyper-V-Switch konfiguriert.

Eine Live Migration einer einzelnen virtuellen Maschine (VM) wird nicht die gesamte Bandbreite der 10-GBit/s-Verbindung aufbrauchen. Es wird in den meisten Fälle etwa bei 4 GBit/s bleiben. Sind aber mehr als nur eine gleichzeitige Live Migration aktiv, dann wird die gesamte verfügbare Bandbreite von 10 GBit/s benützt. Generell sollte man vorsehen, dass niemals mehr als vier gleichzeitige Live Migrations auf den beiden Hosts laufen dürfen. Im nächsten Schritt wurde ein virtueller Hyper-V-Switch erzeugt und danach einige virtuelle Netzwerkadapter angelegt, die für den Einsatz mit dem Verwaltungs-Betriebssystem gedacht sind. Der Autor hat dazu ein Video auf Youtube hochgeladen, das zeigt, wie sich das NIC Teaming beim Windows Server 2012 einsetzen lässt.

CPU-Belastung reduziert nutzbare Bandbreite

Einer dieser virtuellen Netzwerkadapter wird nun  für die Live Migration eingesetzt. Allerdings bekommt man nun nur ungefähr 4,5 GBit/s für die gleichzeitigen Live Migrations, die zuvor (ohne die virtuellen Netzwerkadapter) die kompletten 10 GBit/s nutzen konnten. Dieser Effekt lässt sich über die CPU-Belastung schlüssig erklären: Es fällt jede Menge an Prozessorarbeit an und die würde bei einer Kommunikation über ein 10-GBit/s-Netzwerk einen einzelner Prozessorkern überlasten und somit auch die Bandbreite entsprechend einschränken. Wenn man mehrere gleichzeitige Live Migrations ausführt  und dabei über die physische Netzwerkkarte geht, wird das RSS (Receive Side Scaling) eingesetzt. Diese Technik führt dazu, dass die Netzwerklast über mehrere Prozessorkerne auf dem Zielsystem für die Live Migrations verteilt wird. Das hat dann zur Folge, dass die komplette Bandbreite der Verbindung genutzt werden kann, denn der einzelne Prozessorkern ist dann nicht mehr der limitierende Faktor.

Eine einzelne Live Migration nutzt nur etwa 4 GBit/s und das lastet einen Prozessorkern komplett aus. Denn diese Last lässt sich nicht mit Hilfe des RSS verteilen, denn es handelt sich bei einer Live Migration um einen einzelnen Datenstrom und da muss die Reihenfolge der Pakete beibehalten werden.

Versucht man nun einen virtuellen Switch des Hyper-V für den Netzwerkadapter (also einen virtuellen Netzwerkadapter) einzusetzen, wird das RSS automatisch deaktiviert. Das ist auch nötig, denn das RSS und das VMq schließen sich gegenseitig aus und deswegen kann ein virtueller Switch beim Hyper-V das RSS nicht verwenden – denn er benötigt das VMq. Daher werden die gleichzeitigen Live Migrationen auf eine Bandbreite begrenzt, die in etwa bei 4 GBit/s liegt – das ist jedoch abhängig von der Geschwindigkeit der jeweiligen Prozessorkerne, die in einem System zum Einsatz kommen. Dabei ist allerdings eines zu beachten: Der begrenzende Faktor liegt immer auf der Seite des empfangenden Hosts – denn das RSS lässt sich dort ja nicht verwenden (denn in diesem Fall kommt ein virtueller Netzwerkadapter beim Hyper-V-Switch zum Einsatz). Und hier muss nun der gesamte Netzwerkverkehr von einem Prozessorkern abgearbeitet werden.

Parent Partition hat Sonderstellung

Der ausgehende Verkehr von einem Hyper-V-Host wird dagegen über alle verfügbaren Prozessorkerne verteilt. Die Werte für den empfangenden Host sind im Bild 1 zu sehen –da ist auch recht gut zu erkennen, dass der eine Prozessorkern ausgelastet ist.

Daher ist derzeit die einzige Möglichkeit, die komplette Bandbreite in Höhe von 10 GBit/s bei der Live Migration über einen virtuellen Switch des Hyper-V in der Parent Partition (also dem Verwaltungs-Betriebssystem), auszunutzen: Bei mehreren gleichzeitige Live Migrations muss man mehrere Hyper-V-Hosts als Empfänger angeben. Denn jedes Migrations-Ziel wird einen eigenen Prozessorkern verwenden über den es den eintreffenden Verkehr abarbeitet.

Hier sollte man aber eines beachten: Kommt in der Parent Partition – also dem Ausgangspunkt der Live Migration – ein virtueller Netzwerkadapter zum Einsatz und das Zielsystem nutzt einen physischen Netzwerkadapter, dann wird man die kompletten 10 GBit/s an Bandbreite ausnutzen können. Denn dann kann das empfangende System das RSS wieder verwenden, um die Last zu verteilen. Doch das ist in der Realität nicht besonders praktikabel: Üblicherweise wird man die Live Migration in beide Richtungen vorsehen, denn man weiß ja nie genau, welcher Host heruntergefahren werden soll. Und zudem möchte man ja gerne die kompletten 10 GBit/s ausnutzen können.

Andererseits muss man ehrlicherweise auch zugeben, dass einen Bandbreite um die 4 GBit/s auch schon eine gute Performance bei Live Migrations bietet. Und oftmals kommen die Verbindungen mit 10 GBit/s zum Einsatz, um andere Verkehrstypen zu unterstützen, wie etwa bei Clustern oder generellem VM-Netzwerkverkehr. Daher kann es durchaus vorkommen, dass die ungefähr 4 GBit/s für die bestehenden Anforderungen ausreichen.

Release 2 von Windows Server 2012 bringt keine Besserung

Selbst beim neuesten Windows Server-Betriebssystem, dem Windows Server 2012 Release 2 (R2), kann man nicht auf Abhilfe hoffen: Das System unterstützt zwar das „Virtual Receive Side Scaling“ (vRSS). Damit ist zwar der kombinierte Einsatz von RSS und VMq bei einem virtuellen Netzwerkadapter möglich und dann lässt sich die Last durch den Netzwerkverkehr auch auf mehrere Prozessorkerne verteilen. Doch diese Funktionalität steht beim R2 nur für die virtuellen Netzwerkadapter zur Verfügung, die eine VM benutzt und nicht für die virtuellen Netzwerkadapter, die das Verwaltungs-Betriebssystem (also die Parent Partition) verwendet. Bleibt zu hoffen, dass Microsoft in der nächsten Version nachbessert.

Bandbreitenbegrenzung beim NIC Teaming

Beim Einsatz von NIC Teaming werden mehrere physische Netzwerkadapter, meist die mit einem Durchsatz von 1 GBit/s, zu einer entsprechend „dickeren“ Netzwerkverbindung zusammengefasst. Will man die Live Migration über diese Schiene abwickeln, kommt es allerdings zu keiner Verbesserung: Nach wie vor stehen nur die 1 GBit/s zur Verfügung. Auch hier stellt sich die Frage, warum hier keine bessere Bandbreite benutzt werden kann.

Generell verwendet das NIC Teaming verschiedene Ansätze, um den Verkehr über die verfügbaren Netzwerkadapter (im Team) zu verteilen. Einer dieser Modi ist der „Hyper-V Port“. Er verteilt die virtuellen Netzwerkadapter der virtuellen Maschinen auf die verfügbaren Netzwerkadapter. Das ist eine passende Option, wenn man mehr VMs als Netzwerkadapter im Team hat. Allerdings sollte man diesen Modus nie für die Live Migration verwenden, denn dabei wird kein Verteilen des Verkehrs erfolgen.

Ein anderer Modus (ab Windows Server 2012) ist der „Address Hash“. Es handelt sich dabei um eine Kombination aus Quell- und Ziel-IP-Adresse plus der Quell- und Zielports (also um einen 4-Tuple Hash). Es lassen sich aber auch andere Modi mit Hilfe der Powershell auswählen und entsprechende Parameter (für den Load Balancing Algorithm) angeben, doch auch das würde das Ausgangsproblem nicht lösen. Generell ist beim Ausführen einer (oder auch mehrerer) Live Migration zwischen zwei Hosts die IP-Adresse und dir Port-Information zwischen den zwei Servern dieselbe für alle Live Migrations zwischen diesen beiden Systemen:

Die Quell- und Ziel-IP-Adresse sind gleich und die Live Migration benutzt immer den Port 6600.

Daher würde immer nur eine der Netzwerkkarten im Team benutzt werden (siehe Bild 2).

Das liegt wie gesagt nur am Verteilungsalgorithmus für alle Live Migrations zwischen den beiden Hosts.Nur wenn man mehrere gleichzeitige Live Migrations auf verschiedene Zielsysteme mit Hyper-V ausführt, lassen sich die mehreren Netzwerkkarten in einem Team ausnutzen. Angenommen vom Hyper-V-Host mit dem NIC Team werden drei gleichzeitige Live Migrations ausgeführt, von denen eine jede ein anderes Zielsystem für die Live Migration vorgesehen hat, dann lassen sich die mehreren physischen Netzwerkkarten des NIC Teams vernünftig nutzen.

Generell lässt sich zum NIC Teaming sagen: Immer wenn man viel Verkehr von selben Typ zwischen denselben beiden Hosts austauschen muss, wird beim NIC Teaming die Last nicht zwischen den verschiedenen Netzwerkadaptern verteilt. Denn es muss ja immer – sozusagen als oberste Prämisse – sichergestellt werden, dass die Reihenfolge der Datenpakete beibehalten wird. Nur wenn es einen Unterschied  beim Netzwerkverkehr bei den Faktoren Quell-, Ziel-IP-Adresse und Portnummer gibt, kann eine Verteilung auf verschiedene Netzwerkadapter im NIC Team erfolgen.

John Savill/rhh