Microsoft Storage Spaces Direct (S2D) mit 25 und 100 Gb/s RDMA Netzwerk | Hyper-V Server Blog

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

Jan Kappen
 

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitet seitdem bei der Rachfahl IT-Solutions GmbH & Co. KG.
Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure.
Im April 2015 wurde Jan Kappen im Bereich “File System Storage” für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

  • Chris sagt:

    Hallo, danke für den Artikel

    Wie sieht es Bezüglich Bandbreitenreservierung aus wenn LiveMigration auch über SMB konfiguriert wird? Kann man dann Storage und LiveMigration-Traffic noch unterschiedliche Reservierungen zuordnen, z.B. Storage 60, LiveMigration 40?

  • Jan Kappen sagt:

    Hallo Chris,
    das ist mit Hilfe von dem SMB Bandwidthlimit möglich. Das ist ein Feature, was installiert werden muss, danach kann das per PowerShell konfiguriert werden (https://technet.microsoft.com/de-de/library/dn467373(v=wps.630).aspx).
    Gruß, Jan

  • Sebastin Lehrmann sagt:

    Hi,

    dank für diesen klasse Bericht.
    Ich stehe kurz vor der Umsetzung eine Projektes mit S2D. Zum Einsatz kommen ebenfalls R730xd von Dell.
    Du hattest geschrieben, dass deine Umgebung vorher mit 10GB lief. Hattest du dort ebenfalls RDMA genutzt?
    Mit stellt sich nämlich aktuelle die Frage, ob ich zwingend RDMS nutzen muss oder nicht!?

    Danke im Voraus und Gruß
    Sebastian

  • Carsten Rachfahl sagt:

    Hi Sebastian,

    in der Regel empfehlen wir RDMA Karten (wobei es einige wenige Ausnahmen gibt). Um vieviel Hosts geht es, was willst du machen Hyper-converged oder Converged, welche Performance erhostst du dier?

    Gruß Carsten

  • Sebastian sagt:

    Hallo Carsten,

    danke für dein Feedback.
    Ich plane ein hyper-converged System mit vier Hosts.
    Die Hosts sind von Dell geplant. Problem ist, dass die Hosts SFP+ Controller verbaut haben, ich aber keine Möglichkeit habe, diese zu nutzen. Es wäre eine Neuanschaffung von SFP+ Switchen nötig und dies möchte ich umgehen.

    Jetzt habe ich, meines Erachtens, drei Möglichkeiten:

    1. Verzicht auf RDMA, also die Nutzung “normaler” 10GB NICs.
    2. Eine RDMA fähige NIC über RJ45 (aktuell habe ich aber noch keine finden können! Von Mellanox soll es die Connect X-3 Pro auch mit RJ45 geben, aber gefunden habe ich sie noch nicht (Dell auch nicht))
    3. Nutzung von SFP+ zu RJ45 Transceiver. (hier bin ich mir nicht sicher, ob das technisch möglich ist!?)

    Wie du vielleicht rausgelesen hast, möchte ich das Ganze über 10GB abwickeln.

    Danke im Voraus und beste Grüße
    Sebastian

  • Carsten Rachfahl sagt:

    Hi Sebastian,

    du Kannst du Chelsio 10 GBit Karten mit iWarp (das zweite Protokol welchens RDMA über Ethernet bereitstellt) nehmen. Vorteil deine Switche brauchen keine besonderen Features zu unterstützen. Schau mal in mein Webinar Hyper-V Deepd Dive – Netzwerk rein https://www.hyper-v-server.de/lp-webinar-archiv/ .

    Carsten

  • >