Hyper-V Converged Network

die Ausgangssituation ist ein Hyper-V Cluster, mit 2x 10Gbit im Backend für den iSCSI Traffic, und 4x 1Gbit im Frontend per Node.

Das Fronend ist mit 4x 1Gbit an mehrere Switche in einem Stackverbund angebunden. 

Klassisch wäre die Erstellung folgender Netze

  • VM Worklan (VM Gast dediziert)
  • Hyper-V Host Management Lan (Monitoring und Backup)
  • Cluster Heartbeat
  • Cluster Shared Volume (CSV)
  • Live Migration

hyper-v converged network fabric windows server 2012 r2 iscsi live migration csv heartbeat management failover cluster

Bei nur 4 Adaptern werden Cluster Heartbeat und CSV Network zusammengelegt.

Network Team

hyper-v converged network fabric windows server 2012 r2 iscsi live migration csv heartbeat management failover cluster bandwith limit

in diesem Beispiel werden die iSCSI Backend Netze für die Live-Migration genutzt. Eine Limitierung der Bandbreite erfolgt mit SMB Bandwith Limit.

Im Frontend wird der Ausfall einer Verbindung zum Teil abgefangen. Fällt das HB/CSV Netzwerk aus, übernimmt das Management Lan den Cluster Heartbeat. Der CSV Traffic wird aufgrund der niedrigeren Metric (kein konfiguriertes Gateway) über die beiden iSCSI Netze erfolgen. Fällt das Management Lan aus, wird der Clusterbetrieb nicht beeinträchtigt, dafür ist der Server nicht mehr erreichbar. Die Management Ports der Hyper-V Hosts sollten daher nicht am gleichen Switch verbunden werden. Für das VM Worklan stehen zwei Redundante Ports zur Verfügung. Der Ausfall einer Verbindung minimiert nur die Bandbreite der virtuellen Maschinen.

Converged Network

das folgende Beispiel zeigt die Konfiguration eines Converged Networks. Die vier Gigabit Nics werden gebündelt, und federn den Ausfall von drei Nics ab.

hyper-v converged network fabric windows server 2012 r2 iscsi live migration csv heartbeat management failover cluster bandwith limit

aus den 4x 1GB onboard Nics wird ein LACP Trunk (Trunk bei HP, Port Channel bei Cisco) erstellt. Der Switch muss analog dazu angepasst werden. Der Adapter vermindert seine Bandbreite mit Ausfall einer Nic, bleibt aber online

auf dem LACP Trunk wird ein virtueller Switch erstellt. Die Bindung der IP Protokolle geht verloren.

dem VM Switch wird eine relative Gewichtung zugewiesen. Diese garantiert die mindest zur Verfügung stehende Bandbreite. Alle Adapter ohne Gewichtung, inklusive später darauf verbundener VMs, fallen in diesen Default Pool.

es wird jeweils ein virtueller Management und CSV/HB Adapter (vNic) auf dem VM Switch erstellt

zur Trennung der Netze, wird den virtuellen Adaptern für Management und CSV/HB jeweils eine vlan ID zugewiesen. Adapter ohne vlan, inklusive VMs, fallen in das default vlan, das dem Trunk am physikalischen Switch zugewiesen ist.

die vNics erhalten eine relative Gewichtung, und werden damit nicht dem Default Pool angerechnet. Eine Zuweisung an einen Adapter einer bestimmen VM ist dann möglich, wenn dieser erstellt wurde. Mit „Get-VMNetworkAdapter -VMName * “ werden vorhandene VM Adapter ausgegeben.

In der aktuellen Konfiguration ergeben sich damit jeweils 20% für das Management sowie CSV/HB, und 60% für den Default Pool. Eine Begrenzung nach oben wäre mit der Option MaximumBandwidth möglich.

Für die Kommunikation erhalten die vNics IP Adressen, nur das Management Lan erhält ein Gateway und Verweise auf die DNS Server.

Einstellungen abfragen

 

Performance

so schön die ganze Geschichte mit den dynamischen Bandbreiten ist, muss man auch eine Einschränkung erwähnen. Sobald ein VM Switch auf der Nic bzw. dem LACP Team installiert wird, geht der support für RSS (Receive Side Scaling) verloren, und VMQ (Virtual Machine Queues) wird aktiviert.

LACP Team ohne VM Switch

perfmon windows lacp network

Die Last verteilt sich über vier TCP Streams der 4 Nics (SMB Multichannel). LACP und der Switch Independent Mode weisen hier (rote Linie) ein ähnliches Bild auf. Mit 4x 1GB Karten werden rund 400MB/second erreicht. Bei meinen Servern sind die lokalen Platten der Flaschenhals.

cpu 2012r2

An den vier CPU Ausschlägen sieht man, dass RSS genau das tut, was es soll. Es gleicht die Last über mehrere TCP Streams aus.

 

LACP Team mit  VM Switch

perfmon windows lacp network

nach dem Erstellen des VM Switches sieht das Bild ganz anders aus. Von den vier Nics arbeitet nur noch eine, eine Lastverteilung findet nicht mehr statt.

 

2012r2 cpu

Da jetzt nur noch ein TCP Stream aktiv ist, wird auch nur ein CPU Kern beansprucht, dafür aber auch stärker. Der maximale Durchsatz bei 1Gigabit Karten (obwohl 4 Stück) beträgt damit 125MB/second.

SMB Multichannel

Haben die Server eine weitere Möglichkeit miteinander zu kommunizieren, z.B. ein CSV/HB Lan, wird ein weiterer TCP Stream über diese Verbindung aufgebaut. Die Last verteilt sich dann über die vNic des LACP und der physischen Nic des CSV/HB und auf Seiten des Prozessors auf mehrere Cores. Ob die Nic virtuell ist, oder am gleichen VM Switch hängt, spielt dabei keine Rolle.

Sobald die Server stärkere 10Gbit Verbindungen haben, werden diese für die Kommunikation untereinander genutzt. Sind die Nics RSS-Capable werden mehrere Streams pro Adapter aufgebaut.

get-smbclientnetworkinterface rss powershell

wie oben bereits erwähnt, geht nach dem Aktivieren eines vSwitches die RSS Capability für die vNics verloren. VM Gast Systeme, die auf den VM Switch connected sind, haben diese Einschränkung nicht. Die vNics der Hosts sowie der VMs haben virtuelle 10Gbit, unabhängig davon auf welcher Physik diese aufgesetzt sind.

Prozessor

powershell get-netadaptervmq

mit dem Powershell Befehl Get-NetAdapterVmq wird angezeigt, dass innerhalb der VMQ Funktion der Processor 0:0 für die Verarbeitung genutzt wird

Es ist sinnvoll  „CPU 0“ für Systemressourcen frei zu lassen. Mit folgendem Befehl wird der mindest zu verwendende Kern definiert (Core 1 oder höher)

 

powershell get-netadaptervmq

 

 

2012r2 cpu

 

Holger Wache

Holger Wache