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
Bei nur 4 Adaptern werden Cluster Heartbeat und CSV Network zusammengelegt.
Network Team
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.
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
1
2
3
|
New-NetLbfoTeam LACPtrunk onboard1,onboard2,onboard3,onboard4 -TeamingMode LACP -LoadBalancingAlgorithm Dynamic
|
auf dem LACP Trunk wird ein virtueller Switch erstellt. Die Bindung der IP Protokolle geht verloren.
1
2
3
|
New-VMSwitch vSwitch -MinimumBandwidthMode Weight -NetAdapterName LACPtrunk -AllowManagementOS 0
|
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.
1
2
3
|
Set-VMSwitch vSwitch -DefaultFlowMinimumBandwidthWeight 30
|
es wird jeweils ein virtueller Management und CSV/HB Adapter (vNic) auf dem VM Switch erstellt
1
2
3
4
|
Add-VMNetworkAdapter -ManagementOS -Name Management -SwitchName vSwitch
Add-VMNetworkAdapter -ManagementOS -Name CSV/HB -SwitchName vSwitch
|
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.
1
2
3
4
|
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName CSV/HB -Access -VlanId 8
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName Management -Access -VlanId 3
|
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.
1
2
3
4
|
Set-VMNetworkAdapter -ManagementOS -Name Management -MinimumBandwidthWeight 10
Set-VMNetworkAdapter -ManagementOS -Name CSV/HB -MinimumBandwidthWeight 10
|
Für die Kommunikation erhalten die vNics IP Adressen, nur das Management Lan erhält ein Gateway und Verweise auf die DNS Server.
1
2
3
4
5
6
7
8
|
# Set IP Address Management
New-NetIPAddress -InterfaceAlias "vEthernet (Management)" -IPAddress 10.10.1.27 -PrefixLength 24 -DefaultGateway 10.10.1.254
Set-DnsClientServerAddress -InterfaceAlias "vEthernet (Management)" -ServerAddresses 10.10.3.1, 10.10.3.2
# Set IP Address CSV/HB
New-NetIPAddress -InterfaceAlias "vEthernet (CSV HB)" -IPAddress 192.168.8.1 -PrefixLength 24
|
Einstellungen abfragen
1
2
3
4
5
6
7
8
9
10
11
12
13
|
# get DefaultFlowMinimumBandwidthWeight
Get-VMSwitch vSwitch | ft name,DefaultFlowMinimumBandwidthWeight
# get vLans
Get-VMNetworkAdapterVlan
# get Bandwith Percentage
Get-VMNetworkAdapter -ManagementOS -Name * | ft Name, VMName, MinimumBandwidthWeight, BandwidthPercentage, IsManagementOS, maximumbandwith
# get Adapter
Get-VMNetworkAdapter -all
|
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
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.
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
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.
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.
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
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)
1
2
3
4
5
6
7
|
# change base processor
Set-NetAdapterVmq -Name onboard1 -BaseProcessorNumber 1
Set-NetAdapterVmq -Name onboard2 -BaseProcessorNumber 1
Set-NetAdapterVmq -Name onboard3 -BaseProcessorNumber 1
Set-NetAdapterVmq -Name onboard4 -BaseProcessorNumber 1
|