Microsoft Storage Spaces Direct (S2D) mit 25 und 100 Gb/s RDMA Netzwerk
Wir haben aktuell die Möglichkeit, mit RDMA-Netzwerkkarten und Geschwindigkeiten von 25 bzw. 100 Gb/s zu arbeiten, und möchten dies in diesem Artikel einmal beschreiben. Die verfügbare Hardware besteht aus zwei Dell R730xd-Systemen, die zu einem Storage Spaces Direct-Cluster konfiguriert wurden. In jedem Server stehen aktuell 128 GB RAM zur Verfügung, zu Beginn der Einrichtung werden zwei 1 GbE und zwei 10 GbE Ports zur Verbindung untereinander genutzt, weiterhin stehen zwei 1 GbE Ports für die VM-Switch zur Verfügung. Wir haben Zugriff auf zwei 25 GbE Single Port Netzwerkkarten pro Server sowie eine 100 GbE Dual Port Netzwerkkarte der Firma Mellanox. Die 25 GbE NICs sind Mellanox-Karten vom Typ ConnectX-4 Lx, die 100 GbE NICs sind Karten der Reihe ConnectX-4.
NIC1 und NIC2 sind zu einem Management-Team zusammengefasst, über diese Verbindung erfolgt eine RDP-Verbindung auf diese Systeme.
Die beiden ConnectX-3 Pro-Adapter werden aktuell zur Anbindung der Server untereinander per SMB3 genutzt, jede Karte hat eine eigene IP-Adresse in einem eigenen Subnetz. Das Failover Cluster sieht im Netzwerk wie folgt aus.
Ich habe im Failover Cluster eine VM angelegt und mit 100 GB an RAM ausgestattet. In den Einstellungen der Livemigration habe ich die SMB-Option konfiguriert, um die SMB3 Multichannel-Funktion nutzen zu können. Nun müssen wir noch die RDMA-Einstellungen setzen und konfigurieren.
Wir beginnen damit, die Karten auf den aktuellen Treiberlevel anzuheben. Dies geschieht durch einen Download der aktuellsten Treiber von der Mellanox-Seite, um direkt zur Ethernet-Treiber-Seite zu gelangen können Sie den folgenden Link benutzen: Mellanox.com
Nach der Installation und einem Neustart der Server muss nun eine Konfiguration für die erfolgreiche Nutzung von RDMA gemacht werden. Zu diesem Zweck benutzen wir das folgende PowerShell-Skript:
# Hinzufügen des DCB-Feature
Add-WindowsFeature Data-Center-Bridging -IncludeAllSubFeature -IncludeManagementTools
# DCBx deaktivieren
Set-NetQosDcbxSetting -Willing 0 -Confirm:$false
# Erstellung der QoS Richtlinien
New-NetQosPolicy „SMB“ -NetDirectPortMatchCondition 445 -PriorityValue8021Action 5
New-NetQosPolicy „DEFAULT“ -Default -PriorityValue8021Action 5
New-NetQosPolicy „TCP“ -IPProtocolMatchCondition TCP -PriorityValue8021Action 1
New-NetQosPolicy „UDP“ -IPProtocolMatchCondition UDP -PriorityValue8021Action 1
# Priority Flow Control (PFC) einschalten für unsere Konfiguration
Enable-NetQosFlowControl -Priority 5
Disable-NetQosFlowControl 0,1,2,3,4,6,7
# Einschalten von RDMA für die RoCE-Karten
Get-NetAdapter -Name „Slot 3“ | Enable-NetAdapterRdma
Get-NetAdapter -Name „Slot 3 2“ | Enable-NetAdapterRdma
# Reservierung von SMB-Traffic (optional)
# New-NetQoSTrafficClass „SMB“ -Priority 5 -Bandwidth 60 -Algorithm ETS
# Setzen von RoCE v1
Set-MlnxDriverCoreSetting -RoceMode 1.0 -Confirm:$false
Das Skript installiert im ersten Schritt das benötigte Feature Data-Center-Bridging, danach wird die DCBx-Funktion deaktiviert. Diese würde eine Konfiguration in der Switch automatisch auf die Client-Karte übertragen, in unserem Fall möchten wir dies nicht haben. Danach werden vier neue Richtlinien erstellt: SMB, DEFAULT, TCP und UDP. Diese Richtlinien werden jeweils mit einer Priorität ausgestattet, im nächsten Schritt aktivieren wir die QoSFlowControl für Priorität 5, weiterhin erfolgt eine Deaktivierung für alle anderen Prioritäten. Welche Priorität genutzt wird ist egal, solange auf allen Geräten die gleiche Priorität genutzt wird. Wir haben uns für 5 entschieden, Microsoft z.B. setzt in Demos und Beispielen häufig die 3 ein.
Danach erfolgt eine Aktivierung von RDMA für die beiden ConnectX-3 Karten, weiterhin wird die Version von RoCE auf 1 gesetzt. Die Nutzung von einer Bandbreitenreservierung ist optional, ich habe in meinem Fall keine Reservierung gesetzt.
Ich habe nun eine VM erstellt mit 100 GB Hauptspeicher. Bei einer Livemigration sehen wir die folgenden Tätigkeiten im Task Manager:
Der Traffic ist nicht sichtbar, dies ist schon mal ein gutes Zeichen dafür, dass RDMA genutzt wird. Genauer können wir den Traffic und das Verhalten der Livemigration sehen, wenn wir zum Perfmon greifen. Dort gibt es speziell für RDMA Counter, mit denen man einige wertvolle Informationen bekommt.
Dies kann man entweder direkt live betrachten
oder mit Hilfe der Data Collector Sets mitschneiden lassen. Das Ergebnis des Mitschnitts zeigt sehr gut, wie die Datenrate bei der Livemigration der 100 GB an RAM-Daten bei über 1.000.000.000 Bytes/sec auf beiden Karten liegt. Umgerechnet in dies 980,50 MByte/sec oder 0,96 GByte/sec auf jeder Karte bzw. 7844 Mbit/sec oder 7,66 Gbit/sec. Die CPU-Belastung lag bei dieser Bandbreite bei durchschnittlich 2,614 % (für das gesamte System, nicht ausschließlich für die Livemigration) und bei maximal 6,913 %.
Nun werden die beiden 10 GbE-Adapter deaktiviert und die 25 GbE-Adapter werden in Betrieb genommen. Damit ich nicht dauernd alle Adapter umändern muss, habe ich hier zwei andere IP-Bereiche genutzt. Die Nutzung von zwei unterschiedlichen Subnetzen ist wichtig, da ich die beiden Server direkt miteinander verkabelt habe, da wir "nur" eine 100 GbE Switch zur Verfügung haben. Eine Nutzung wäre auch mit den mitgelieferten Breakout-Kabeln möglich, eine direkte Verkabelung ist aber schneller und günstiger.
Wir müssen beachten, dass wir für die neuen Karten ebenfalls die RDMA-Funktion einschalten, da diese sonst nicht genutzt wird. Überprüfen kann man dies mit dem PowerShell-Befehl
Get-NetAdapterRDMA
Wir beginnen nun eine Livemigration unserer VM und messen erneut die Performance und Dauer mit Hilfe des Performance Monitors.
Wie man in der Grafik erkennen kann, bewegt sich die Dauer der Livemigration nur noch bei 23 Sekunden (streng genommen sogar noch weniger, vorne ist eine Sekunde Luft ;)). Als maximale Bandbreite wird 3.053.520.588 Bytes/sec erreicht, das sind 22,75 Gbit/sec. Pro Karte. Gleichzeitig. Sehr schick :)
Weiterhin lässt sich erkennen, dass die CPU-Belastung (unten der gelbe Verlauf) erneut sehr gering bleibt und bei durchschnittlich 1,959 % liegt.
Nun steigern wir uns erneut und nehmen die 100 GbE-Karten in Betrieb. Alleine um die Höhe der maximal möglichen Bandbreite mal zu betrachten: 100 Gbit/sec sind 12,5 GByte/s oder auch 2,7 Single Layer DVDs pro Sekunde, die dort übertragen werden könnten. Umgerechnet auf CDs wären dies 18,2 Stück pro Sekunde oder auch alternativ 8888,88 Disketten ;)
Bevor wir mit den 100 GbE Adaptern starten können, müssen wir noch etwas überprüfen, nämlich die Konfiguration der Adapter. Neben einer Ethernet-Kommunikation können die Karten auch Infiniband, was wir allerdings nicht nutzen möchten. Sichtbar wird dies z.B. bei einem Vergleich der beiden Karten in der Systemsteuerung.
In dem Bild können wir oben die Karte als Ethernet-Adapter sehen, unten als Inifiniband-Adapter. Umstellen können wir dies mit einem Guide, der auf der Mellanox-Seite zu finden ist: Getting started with ConnectX-4 100Gb/s Adapter for Windows
In diesem Artikel wird beschrieben, wie man die Art des Controllers feststellen und ändern kann. Kleiner Tipp: Sehen Sie keine Karten bei der Abfrage mittels mst, überprüfen Sie die Secure Boot-Option. Ist diese eingeschaltet, so kann der Status nicht geändert werden, da keine Karten sichtbar sind. In diesem Fall muss Secure Boot temporär abgeschaltet werden, danach ist eine Konfiguration möglich.
Eine Ausgabe der Eigenschaften mit "mlxconfig -d mt4115_pciconf0 q" zeigt, dass hier Infiniband konfiguriert ist.
Umstellen können wir den Adapter-Typ mit dem Befehl
mlxconfig -d /dev/mst/mt4115_pciconf0 set LINK_TYPE_P1=2 LINK_TYPE_P2=2
Nach einem Neustart der Server und einer erneuten Überprüfung sehen wir, dass sich der Status der Karte geändert hat und wir nun mit einer Ethernet RoCE-Karte arbeiten statt mit einem Infiniband-Adapter.
Nach dem Neustart der Server können wir nun auch erkennen, dass die Karten einen Link bekommen und konfiguriert werden können.
Wir starten nun die Livemigration unserer VM und beobachten erneut das Verhalten auf den beiden Netzwerkkarten. Ohne eine weitere Anpassung und Optimierung benötigt die VM mit ihren 100 GB RAM 15 Sekunden.
Man kann hier erkennen, dass die maximale Bandbreite von einem Port bei 4.715.224.014 Byte lag, das sind 4.496 MByte/sec bzw. 4,39 GByte/s. Umgerechnet in Gbit/sec kommen wir hier auf 35,13 Gbit/sec pro Port, zusammen liegen wir hier bei knapp 70 Gbit/s (der gleichzeitige Maximalwert liegt etwas darunter, dazu kommen wir gleich).
Da wir in den Systemen "nur" 128 GB RAM verbaut haben, kann ich leider keine VM mit mehr RAM anlegen. Die Aufteilung des verfügbaren Speichers auf zwei VMs mit jeweils 50 GB führt zu einer Verringerung der maximalen Bandbreite pro Port auf 3.162.614.677 Byte/s.
Ich ändere nun die Paket-Größe der beiden Karten von 1514 auf 9216 um zu schauen, ob dies zu einer Änderung der Bandbreite führt. Nach einer erneuten Livemigration können wir sehen, dass die maximale Bandbreite bei einer höheren Paketgröße sogar noch sinkt auf 4.236.683.684 Bytes/sec:
Woran liegt diese Begrenzung? Ein Test mit den Mellanox-eigenen Tool zeigt das folgende Ergebnis:
Die Lösung: Wir haben die Karte aktuell zwar in einem x16-Slot, dieser scheint allerdings nur mit einer x8-Bandbreite angebunden zu sein. Nach einem Umbau der beiden Karten in einen anderen Slot sehen die Werte wie folgt aus:
Eine Livemigration mit unserer VM bringt die folgenden Resultate
Man kann erkennen, dass wir eine maximale Bandbreite von knapp 5 GByte/s auf den beiden Karten (jeweils) haben, das sind knapp 80 Gbit/s und somit mehr als die Beschränkung vor dem Umbau der Karte in einen anderen PCIe-Slot.
Als nächstes starte ich auf beiden Karten einen Benchmark-Test, der gleichzeitig läuft. Hier erreiche ich auf den beiden Karten als Maximalwert 8.221.793.402 bzw. 7.233.213.004 Bytes/s, das sind 7,66 bzw. 6,74 GByte/s gleichzeitig. Somit kommen wir auf 115,2 Gbit/s auf beiden Karten gemeinsam, hier sind wir schon wieder in der Region, bei der ein PCIe x16-Slot in der dritten Generation seine Begrenzung hat (128 Gbit/s).
