Windows Server 2025 - RDMA - Folge 01 - Der Anfang des Grauens
Moin Zusammen,
vor ein paar Tagen hat sich ein Unternehmen bei mir gemeldet, welches ein paar Probleme mit deren nigelnagelneuem Server 2025 S2D Dual-Node Cluster haben.
Ähm, ja ich weiss, S2D und ich passen nicht wirklich zusammen. 🙃
Ich sollte mir primär jedoch auch nicht das S2D anschauen, sondern die RDMA-Strecken über die dieses laufen sollte/muss und das ist dann schon eher meine Spezialität. 😁
Das was ich dabei jedoch mal wieder erleben musste und auch in unserem eigenen Testlab 1:1 nachstellen konnte, ist einfach nur grausam und zwar insbesondere seitens Microsoft, aber auch seitens Intel, Broadcom und wahrscheinlich auch NVIDIA. 😔
By the Way … das Problem gibt es nicht wirklich erst seit Server 2025, sondern mindestens seit Server 2019. 😭
Aber ja, alles der Reihe nach.
Zu den groben Rahmenbedingungen.
Der entsprechende Kunde hatte je Node eine Intel E810-CQDA2 Netzwerkkarte, die je 2 100G Ports bereitstellt verbaut. Ferner sind die beiden Nodes über diese E810-CQDA2er NIC’s über ein DAC direkt miteinander verbunden, sprich, extern kein Switch dazwischen und intern auch kein vSwitch, was die Sache übrigens noch viel komplizierter und um einiges verwirrender machen würde. 😔
In unserem eigenen Testsystem stecken in den beiden Servern mitunter je eine E810-XXVDA2 NIC, sprich, eine Netzwerkkarte mit 2 x 25G Ports und da ich das, respektive die Probleme auch auf diesem System 1:1 nachvollziehen kann, würde ich diesen Beitrag auch darauf aufbauen.
Und auch unsere NIC’s sind direkt per DAC miteinander verbunden und auch an diesen hängt intern kein vSwitch dran. Sprich, fast 1:1 bis auf 25G VS 100G. 🙃
Ähm, ja, OK, ich muss jedoch auch erwähnen, dass ich an unseren E810-XXVDA2 NIC’s einiges umkonfigurieren musste um dieses Problem zu reproduzieren, da diese auch RDMA technisch, per Default ganz anders eingestellt sind, als die E810-CQDA2’s des entsprechenden Kunden. 😩
Zu den Feinheiten kommen ich jedoch etwas später.
Nun zu dem Problem, ja, OK, es ist genaugenommen nicht nur eins sondern mehrere, das das folgende genaugenommen nicht nur RDMA, sondern auch SR-IOV und auch VMQ betrifft. 😭
Aber das jetzt auch noch mit dazu zunehmen, würde die Sache noch komplizierter machen.
Ja, ja, ist ja schon gut, ich höre ja schon auf die Sache noch verwirrender zu machen, aber, dafür dass es so ist wie es ist, kann ich jetzt nicht wirklich was dafür … ☮️ … sondern eher Microsoft, Intel, Broadcom & Co.
Also, wenn man die Funktionalität von RDMA bei einer NIC auf einem Windows prüfen möchte, dann ist der PowerShell Befehl „Get-NetAdapterRdma“ mitunter eine der ersten Anlaufstellen.
Und wenn ich diesen Befehl auf einem unserer Testserver ausführe, dann bekomme ich bei E810-XXVDA2 das folgende zu sehen.
Und laut der folgenden aktuellsten Beschreibung von Microsoft …
https://learn.microsoft.com/de-de/powershell/module/netadapter/get-netad ...
… bedeutet diese Ausgabe …
… ahm, ja, genau so viel zu dem Thema vollständige Doku. 😭
Na ja, weiter oben in der „Description“ steht als Beschreibung ja wenigstens das folgende geschrieben.
Was übersetzt das folgende bedeutet …
… und eigentlich hätte Microsoft das selbst übersetzen sollen, da „de-de“ im Link, aber ja, trotz eigener KI die das ja auch machen könnte, wahrscheinlich auch viel besser als das was die selbst bisher gezaubert haben, bekommt MS das wohl selbst auch nicht mehr wirklich auf die Kette. 😔
Na ja, sei es drum, weiter geht’s.
Das „True“ unter „Enabled“ bedeutet bei „Get-NetAdapterRdma“, dass bei dem entsprechenden Adapter RDMA im Treiber aktiviert ist und das „True“ unter „Operational(State)“, bedeutet, respektive, sollte eigentlich bedeuten, dass auf der entsprechenden NIC RDMA auch betriebsbereit, sprich, funktionsfähig ist.
Dann gibt es bei Windows noch einen weiteren PowerShell-Befehl, mit dem man die RDMA Funktionalität, (eigentlich) prüfen kann und zwar mit „Get-SmbMultichannelConnection“, dazu muss man jedoch vorher eine SMB(-DIRECT) Verbindung über die entsprechende Strecke aufbauen und dann sieht die Ausgabe folgend aus, …
… sprich, auch laut dieser sollte RDMA funktionsfähig sein.
By the way, die Beschreibung des Outputs von „Get-SmbMultichannelConnection“ …
https://learn.microsoft.com/de-de/powershell/module/smbshare/get-smbmult ...
… ist seitens Microsoft leider genauso nichts aussagend, wie die von „Get-NetAdapterRdma“. 😔
Aber ja, auch mit „Get-SmbMultichannelConnection“ sagt mir der Server 2025, dass er bei der entsprechenden SMB-Verbindung RDMA benutzen könnte, sprich, dass RDMA zur Verfügung stehen würde.
Und spätestens an dieser Stelle, glauben leider viele, dass sie per SMB wirklich RDMA, sprich, SMB-Direct verwenden würden.
Tja, sorry, Pustekuchen, denn es gibt bei Windows nur eine Stelle mit der man, zumindest mit Bordmitteln feststellen kann ob RDMA, respektive, SMB-Direct wirklich funktioniert und zwar durch die Auswertung von ganz bestimmten Performance-Countern und zwar den folgenden.
Ach ja, by the way, bitte beachten, über diese Counter kann man leider auch nicht wirklich pro NIC die RDMA-Fähigkeit prüfen, da diese global sind, sprich für alle aktuellen RDMA Verbindungen gelten.
Ich habe dann in der Leistungsüberwachung die oben angesprochenen Counter konfiguriert und egal wie oft ich eine ca. 6GB grosse Datei über die entsprechende Strecke, die ja laut der oberen beiden PowerShell-Befehle RDMA fähig sein sollte, kopiert habe, habe ich immer nur das folgende Bild in der Leistungsüberwachung sehen dürfen.
Wie ihr sehen könnt, kein Ausschlag, sprich RDMA, respektive SMB-Direct ist so gesehen tot … 😔😭 … obwohl es ja laut der Ausgabe der zuvor angesprochen PowerShell-Befehle, eigentlich quicklebendig sein müsste.
Ja, wie soll ich das jetzt nur schreiben … ähm … RDMA hätte so nie wirklich funktionieren können!
Zum einen ist SR-IOV im BIOS der NIC’s deaktiviert und auch die Treiber sind seitens Intel, zumindest was die Default Einstellungen der E810-CQDA2 NIC’s angeht, auch nicht wirklich korrekt für einen RDMA Betrieb konfiguriert.
Daher würde ich stand jetzt mal gerne ein paar Fragen loswerden.
@microsoft
Warum behaupten die oben angesprochenen PowerShell Befehle, dass RDMA funktionieren würde, obwohl das technisch aufgrund nicht korrekter Konfiguration, überhaupt nicht der Fall sein kann? 🤨
Um es mal etwas direkter zu Fragen, seid ihr mittlerweile wirklich derart verblödet, dass ihr für euer eigenes S2D derart fundamentale Dinge nicht mal mehr halwegs ordentlich auf die Reihe bekommt? 😠
@intel
Warum sind die E810 NIC’s BIOS und auch Treiberseitig mal so mal so eingestellt? 🤨
@broadcom
Ähm ja, bisher seid ihr ja gut weggekommen, aber, kein Grund zur Freude, den insbesondere auch Euch, widme ich noch eine ganz spezielle Folge … kleiner Spoiler … grauenhafte BIOS-Settings und auch Doku. 😉😡
Allgemeiner Spoiler:
In der nächsten Folge werde ich etwas detaillierter auf die „suboptimalen“ Einstellungen der Intel NIC’s eingehen.
Und in der Zwischenzeit kann ja der einen oder andere, sprich, theoretisch alle Besitzer von z.B. S2D Systemen, mal prüfen, ob eure RDMA-Verbindungen auch wirklich RDMA bringen.
Gerne auch mit entsprechendem Feedback, danke.
So, jetzt muss ich mich auch mal um andere Dinge kümmern.
Gruss Alex
vor ein paar Tagen hat sich ein Unternehmen bei mir gemeldet, welches ein paar Probleme mit deren nigelnagelneuem Server 2025 S2D Dual-Node Cluster haben.
Ähm, ja ich weiss, S2D und ich passen nicht wirklich zusammen. 🙃
Ich sollte mir primär jedoch auch nicht das S2D anschauen, sondern die RDMA-Strecken über die dieses laufen sollte/muss und das ist dann schon eher meine Spezialität. 😁
Das was ich dabei jedoch mal wieder erleben musste und auch in unserem eigenen Testlab 1:1 nachstellen konnte, ist einfach nur grausam und zwar insbesondere seitens Microsoft, aber auch seitens Intel, Broadcom und wahrscheinlich auch NVIDIA. 😔
By the Way … das Problem gibt es nicht wirklich erst seit Server 2025, sondern mindestens seit Server 2019. 😭
Aber ja, alles der Reihe nach.
Zu den groben Rahmenbedingungen.
Der entsprechende Kunde hatte je Node eine Intel E810-CQDA2 Netzwerkkarte, die je 2 100G Ports bereitstellt verbaut. Ferner sind die beiden Nodes über diese E810-CQDA2er NIC’s über ein DAC direkt miteinander verbunden, sprich, extern kein Switch dazwischen und intern auch kein vSwitch, was die Sache übrigens noch viel komplizierter und um einiges verwirrender machen würde. 😔
In unserem eigenen Testsystem stecken in den beiden Servern mitunter je eine E810-XXVDA2 NIC, sprich, eine Netzwerkkarte mit 2 x 25G Ports und da ich das, respektive die Probleme auch auf diesem System 1:1 nachvollziehen kann, würde ich diesen Beitrag auch darauf aufbauen.
Und auch unsere NIC’s sind direkt per DAC miteinander verbunden und auch an diesen hängt intern kein vSwitch dran. Sprich, fast 1:1 bis auf 25G VS 100G. 🙃
Ähm, ja, OK, ich muss jedoch auch erwähnen, dass ich an unseren E810-XXVDA2 NIC’s einiges umkonfigurieren musste um dieses Problem zu reproduzieren, da diese auch RDMA technisch, per Default ganz anders eingestellt sind, als die E810-CQDA2’s des entsprechenden Kunden. 😩
Zu den Feinheiten kommen ich jedoch etwas später.
Nun zu dem Problem, ja, OK, es ist genaugenommen nicht nur eins sondern mehrere, das das folgende genaugenommen nicht nur RDMA, sondern auch SR-IOV und auch VMQ betrifft. 😭
Aber das jetzt auch noch mit dazu zunehmen, würde die Sache noch komplizierter machen.
Ja, ja, ist ja schon gut, ich höre ja schon auf die Sache noch verwirrender zu machen, aber, dafür dass es so ist wie es ist, kann ich jetzt nicht wirklich was dafür … ☮️ … sondern eher Microsoft, Intel, Broadcom & Co.
Also, wenn man die Funktionalität von RDMA bei einer NIC auf einem Windows prüfen möchte, dann ist der PowerShell Befehl „Get-NetAdapterRdma“ mitunter eine der ersten Anlaufstellen.
Und wenn ich diesen Befehl auf einem unserer Testserver ausführe, dann bekomme ich bei E810-XXVDA2 das folgende zu sehen.
Und laut der folgenden aktuellsten Beschreibung von Microsoft …
https://learn.microsoft.com/de-de/powershell/module/netadapter/get-netad ...
… bedeutet diese Ausgabe …
… ahm, ja, genau so viel zu dem Thema vollständige Doku. 😭
Na ja, weiter oben in der „Description“ steht als Beschreibung ja wenigstens das folgende geschrieben.
The Get-NetAdapterRdma cmdlet gets the remote direct memory access (RDMA) properties of an RDMA-capable network adapter. RDMA is a feature that enables network adapters to transfer data directly between each other without requiring the main processor of the system to be part of that transfer. This results in lower latency and lower processor utilization.
Was übersetzt das folgende bedeutet …
Das Cmdlet „Get-NetAdapterRdma“ ruft die RDMA-Eigenschaften (Remote Direct Memory Access) eines RDMA-fähigen Netzwerkadapters ab. RDMA ist eine Funktion, die es Netzwerkadaptern ermöglicht, Daten direkt untereinander zu übertragen, ohne dass der Hauptprozessor des Systems an dieser Übertragung beteiligt sein muss. Dies führt zu einer geringeren Latenzzeit und einer geringeren Prozessorauslastung.
… und eigentlich hätte Microsoft das selbst übersetzen sollen, da „de-de“ im Link, aber ja, trotz eigener KI die das ja auch machen könnte, wahrscheinlich auch viel besser als das was die selbst bisher gezaubert haben, bekommt MS das wohl selbst auch nicht mehr wirklich auf die Kette. 😔
Na ja, sei es drum, weiter geht’s.
Das „True“ unter „Enabled“ bedeutet bei „Get-NetAdapterRdma“, dass bei dem entsprechenden Adapter RDMA im Treiber aktiviert ist und das „True“ unter „Operational(State)“, bedeutet, respektive, sollte eigentlich bedeuten, dass auf der entsprechenden NIC RDMA auch betriebsbereit, sprich, funktionsfähig ist.
Dann gibt es bei Windows noch einen weiteren PowerShell-Befehl, mit dem man die RDMA Funktionalität, (eigentlich) prüfen kann und zwar mit „Get-SmbMultichannelConnection“, dazu muss man jedoch vorher eine SMB(-DIRECT) Verbindung über die entsprechende Strecke aufbauen und dann sieht die Ausgabe folgend aus, …
… sprich, auch laut dieser sollte RDMA funktionsfähig sein.
By the way, die Beschreibung des Outputs von „Get-SmbMultichannelConnection“ …
https://learn.microsoft.com/de-de/powershell/module/smbshare/get-smbmult ...
… ist seitens Microsoft leider genauso nichts aussagend, wie die von „Get-NetAdapterRdma“. 😔
Aber ja, auch mit „Get-SmbMultichannelConnection“ sagt mir der Server 2025, dass er bei der entsprechenden SMB-Verbindung RDMA benutzen könnte, sprich, dass RDMA zur Verfügung stehen würde.
Und spätestens an dieser Stelle, glauben leider viele, dass sie per SMB wirklich RDMA, sprich, SMB-Direct verwenden würden.
Tja, sorry, Pustekuchen, denn es gibt bei Windows nur eine Stelle mit der man, zumindest mit Bordmitteln feststellen kann ob RDMA, respektive, SMB-Direct wirklich funktioniert und zwar durch die Auswertung von ganz bestimmten Performance-Countern und zwar den folgenden.
Ach ja, by the way, bitte beachten, über diese Counter kann man leider auch nicht wirklich pro NIC die RDMA-Fähigkeit prüfen, da diese global sind, sprich für alle aktuellen RDMA Verbindungen gelten.
Ich habe dann in der Leistungsüberwachung die oben angesprochenen Counter konfiguriert und egal wie oft ich eine ca. 6GB grosse Datei über die entsprechende Strecke, die ja laut der oberen beiden PowerShell-Befehle RDMA fähig sein sollte, kopiert habe, habe ich immer nur das folgende Bild in der Leistungsüberwachung sehen dürfen.
Wie ihr sehen könnt, kein Ausschlag, sprich RDMA, respektive SMB-Direct ist so gesehen tot … 😔😭 … obwohl es ja laut der Ausgabe der zuvor angesprochen PowerShell-Befehle, eigentlich quicklebendig sein müsste.
Ja, wie soll ich das jetzt nur schreiben … ähm … RDMA hätte so nie wirklich funktionieren können!
Zum einen ist SR-IOV im BIOS der NIC’s deaktiviert und auch die Treiber sind seitens Intel, zumindest was die Default Einstellungen der E810-CQDA2 NIC’s angeht, auch nicht wirklich korrekt für einen RDMA Betrieb konfiguriert.
Daher würde ich stand jetzt mal gerne ein paar Fragen loswerden.
@microsoft
Warum behaupten die oben angesprochenen PowerShell Befehle, dass RDMA funktionieren würde, obwohl das technisch aufgrund nicht korrekter Konfiguration, überhaupt nicht der Fall sein kann? 🤨
Um es mal etwas direkter zu Fragen, seid ihr mittlerweile wirklich derart verblödet, dass ihr für euer eigenes S2D derart fundamentale Dinge nicht mal mehr halwegs ordentlich auf die Reihe bekommt? 😠
@intel
Warum sind die E810 NIC’s BIOS und auch Treiberseitig mal so mal so eingestellt? 🤨
@broadcom
Ähm ja, bisher seid ihr ja gut weggekommen, aber, kein Grund zur Freude, den insbesondere auch Euch, widme ich noch eine ganz spezielle Folge … kleiner Spoiler … grauenhafte BIOS-Settings und auch Doku. 😉😡
Allgemeiner Spoiler:
In der nächsten Folge werde ich etwas detaillierter auf die „suboptimalen“ Einstellungen der Intel NIC’s eingehen.
Und in der Zwischenzeit kann ja der einen oder andere, sprich, theoretisch alle Besitzer von z.B. S2D Systemen, mal prüfen, ob eure RDMA-Verbindungen auch wirklich RDMA bringen.
Gerne auch mit entsprechendem Feedback, danke.
So, jetzt muss ich mich auch mal um andere Dinge kümmern.
Gruss Alex
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669856
Url: https://administrator.de/contentid/669856
Ausgedruckt am: 29.11.2024 um 16:11 Uhr
Serie: DIE WINDOWS SERVER 2025 STORY
Windows Server 2025 - RDMA - Folge 01 - Der Anfang des GrauensWindows Server 2025 - Energieoptionen per GUIs nicht änderbar10Windows Server 2025 - NIC-Performance - Per Default sehr "durchwachsen"54Windows Server 2025 - HARDWAREANFORDERUNGEN - Ich habe da einige Fragen44