[English]Noch eine kleine Information für Administratoren eines Hyper-V-Clusters unter Windows Server 2019. Wie es ausschaut, hat Intel die RSC Unterstützung für alle NICs treiberseitig ab dem Release 1903 deaktiviert. Zudem werden Storage-Stacks Schreiboperationen als write-through ausgeführt, ein Caching wird umgangen. Ein Nutzer hat mich auf diese Sachverhalte hingewiesen.
Anzeige
Die Information von Blog-Leser Alexander F. liegt mir bereits seit Anfang des Monats vor. Alex hat mich per E-Mail auf den Sachverhalt aufmerksam gemacht über den er kürzlich gestolpert ist (danke dafür).
Intel RSC-Unterstützung für NICs in Hyper-V deaktiviert
In seiner Mail schreibt er: Ich bin gestern beim Update von einem 2019er Hyper-V Cluster über das folgende gestolpert.
So wie es aussieht, hat Intel die RSC Unterstützung für alle NICs, treiberseitig für den Server 2019 ab Release 1903 deaktiviert!
Das Kürzel RSC steht für Receive Segment Coalescing. Microsoft führte das Verfahren in Windows Server 2012 ein, um die Netzwerklast auf der Server-CPU zu reduzieren. Hintergrund ist, dass eintreffende Netzwerkpakete auf dem Netzwerkadapter (NIC) einen Interrupt der CPU zur Bearbeitung auslöst. Bei virtualisierten Gästen kann die Last durch diese eintreffenden Netzwerkpakete und damit die CPU sehr hoch werden. Das Receive Segment Coalescing (RSC) soll diese Belastung durch Auslagerung des Paket-Handlings an den Netzwerkadapter (Network Interface Card, NIC) reduzieren. Die NIC kann den Netzwerk-Traffic zu größeren Paketen zusammenfassen und an den Prozessor zur Verarbeitung weiterreichen. Eine Erläuterung zu diesem Thema findet sich in diesem Artikel. Microsoft hat in diesem Artikel ebenfalls einiges zu diesem Thema geschrieben. Alexander schreibt dazu:
Ich habe aber nirgends eine detailliertere Info gefunden, warum das jetzt auf einmal so ist. Na ja, den Sinn vom offloading in einer virtualisierten Umgebung habe ich noch nie so richtig verstanden.
Ich habe bei einigen Hyper-V Clustern in den letzten Monaten sämtliches Offloading auf den NIC's deaktiviert und habe danach von den entsprechenden Kunden bisher nur positives als Feedback bekommen.
Alexander hat das Ganze in der Spiceworks-Community in diesem Artikel etwas weiter ausgeführt. Aufgefallen ist ihm das Ganze, als er einen Hyper-V 2019 Cluster aktualisieren musste. Dabei hat er auch den neuesten Intel Netzwerktreiber mit Version 25.6 auf den beiden Knoten des Clusters installiert. Beim Überprüfen der NIC-Einstellungen in den erweiterten Einstellungen ist ihm nach dem Update aufgefallen dass die NIC bezüglich RSC nicht mehr zu konfigurieren waren. Das gibt sowohl auf den Intel X722 NICs als auch auf den Intel I350 NICs. Vor dem Update konnte er die RSC-Konfiguration noch in den NIC-Einstellungen abrufen und anpassen.
Anzeige
Hyper-V Storage-Stacks Schreiboperationen als write-through
Alexander hat in seiner Mail noch auf eine weitere Merkwürdigkeit in Verbindung mit Windows Server 2019 hingewiesen und schreibt dazu:
Ich habe Ende des Jahres noch eine weitere Schweinerei von Microsoft ab dem Server 2019 aufgedeckt. Ab [Windows] Server 2019 werden alle Schreiboperationen des Hyper-V Storage-Stacks, Richtung Endspeicher (RAID/SAN) hart als "write-through" getaggt.
Ganz unabhängig davon, was von die IO verursachende Software vorher festgelegt hat. Damit ist der Write-Back Cache eines jeden dahinterliegenden RAID-Controllers oder auch von einem SAN quasi mit Gewalt ausgehebelt.
Alexander hat das Ganze näher in diesem Spiceworks-Community-Post beschrieben. Er wies in seiner Mail noch darauf hin, dass der einzige Hinweis von Microsoft auf die Änderung im Dokument Hyper-V storage Caching layers and implications for data consistency – Windows Server | Microsoft Docs zu finden sei.
Anzeige
Buht mich aus aber ich finde die Entscheidung bezüglich des Cache Modus sogar richtig. Allerdings müsste das ordentlich kommuniziert werden. Wenn ich VMs im Cluster hochverfügbar betreibe dann sind die wichtig und ich kann einen Datenverlust eher nicht tolerieren. Selbst bei reduntanten Controllern besteht mit aktivem Writeback Cache die Gefahr eines Datenverlustes, nämlich dann wenn der aktive Controller selber stirbt. Ich möchte nicht miterleben was passiert wenn ein paar GB Schreiboperationen von mehreren VMs im Nirvana landen :) Storage ist nunmal der Dreh- und Angelpunkt bei der Hochverfügbarkeit.
Ich sehe aber auch gar keinen Grund bei Storage intensiven Anwendungen überhaupt über den Hyper-V Storage Stack zu gehen. Warum das ensprechende Volume nicht direkt per iSCSI in der VM verbinden? Wobei ich mich dann frage warum eine VM hochverfügbar sein muss wenn ich bereit bin einen Datenverlust in Kauf zu nehmen? Meine persönliche Meinung ist: Nicht jede VM muss hochverfügbar sein weil das eben auch Nachteile haben kann!
Hm, es gibt keinen Grund, warum Du ausgebuht werden müsstest! Du begründest deine Sicht der Dinge – aus meinem Blickwinkel logisch – und damit sind wir doch ein Stück weiter.
Moin,
> Buht mich aus aber ich finde die Entscheidung bezüglich des Cache Modus sogar richtig.
Ich hätte absolut nichts dagegen, wenn Microsoft standardmässig für weniger erfahrene User/Admins aus Sicherheitsgründen write-through per Standard fahren würde und für die erfahrenen Admins die Möglichkeit bieten würde, dieses Verhalten wieder so umzustellen, dass die tatsächlichen, von der darüberliegenden Applikation angeforderten Cachingvorgaben auch 1:1 an das nächste Storagesublevel (SAN / RAID-Controller & Co.) weitergereicht werden.
Jedoch gibt es diese Möglichkeit stand heute nicht, wodurch insbesondere bei nicht gerade günstigen Enterprisestoragesystemen ein Grossteil der Performance beim Schreiben auf der Strecke bleibt. Das gilt insbesondere bei einer HDD Bestückung, ist aber auch deutlich bei reiner SSD Bestückung zu spüren. Ich persönlich empfinde dieses Vorgehen ehrlich gesagt eher als „erzwungenen Kastration" 😡 und nicht als „weise Vorsichtsmassnahme" wie es Microsoft gerne verkaufen möchte.
Das Argument mit der Sicherheit beim Schreiben ist ab Server 2019 eh obsolet, weil ab diesem die Schreiboperationen standardmässig über den Softwarecache (RAM) abgewickelt werden. 😬
Sprich du startest einen Schreibvorgang auf einer 2019er VM, die durch den Schreibvorgang erzeugten Daten werden zuerst gegen den Softwarecache (RAM) der VM geschrieben und quittiert. Aus diesem Softwarecache (RAM) werden die Daten per „lazy write back" (Ein Horror für sich) an den Hyper-V Storagestack übergeben damit dieser, die vorher noch im unsicheren Softwarecache (RAM) auf der VM zwischengespeicherten Daten, dann ganz sicher per write-through and den darunterliegenden Storagesublevel (SAN, RAID & Co) weitereichen kann, weil deren RAM (meist gepuffert), im Vergleich zu dem RAM der VM (zu > 99,9 ungepuffert) ja um so vieles unsicher ist. 😖🥴 @Microsoft: Witz komm raus du bist umzingelt.
> Wenn ich VMs im Cluster hochverfügbar betreibe dann sind die wichtig und ich kann einen Datenverlust eher nicht tolerieren.
Das „Problem" mit dem write-through betrifft nicht nur Hyper-V Cluster, sondern auch einzelne Hyper-V Server oder auch Win 10 Workstations mit aktiviertem Hyper-V.
> Selbst bei redundanten Controllern besteht mit aktivem Writeback Cache die Gefahr eines Datenverlustes, nämlich dann wenn der aktive Controller selber stirbt.
Nein, das stimmt so pauschal auch nicht, vor allem nicht bei einem echten „Enterprise Storage". Ein richtiges Enterprise-HA-Storage synchronisiert immer auch den Write-Back Cache zwischen den Controllern!
Du kannst somit, z.B. bei einem HA Storage von Infortrend (Geheimtipp), mitten im Betrieb einfach einen der active/active Controller ziehen, ohne das etwas grossartig passiert, ja OK die Warn LED am SAN geht an und ein eventuell vorhandenes und funktionierendes Monitoring fängt vielleicht auch noch an zu blinken. 🙃
> Ich sehe aber auch gar keinen Grund bei Storage intensiven Anwendungen überhaupt über den Hyper-V Storage Stack zu gehen. Warum das entsprechende Volume nicht direkt per iSCSI in der VM verbinden?
😮, keine Gründe, die kann ich liefern.
Die meisten Hyper-V Cluster die wir bisher ausgeliefert haben bestehen aus 2-4 Nodes und einem AllFlash SAN. Jeder Nodes ist immer mit mindestens !!! 96 GB/s !!! per SAS am SAN angedockt, bei manchen Clustern sind die Nodes sogar mit 192 GB/s angebunden. Ganz ohne Netzwerkoverhead und ohne, dass ich mich mit RSS, RSC, Offloading & Co herumschlagen muss. 😁
Beste Grüsse aus BaWü
Alex
Danke für deine Ausführungen! An SAN in der Form habe ich nicht gedacht. Was es gibt noch was anderes als Ethernet :D
Das die Beschränkungen auch für Standalone Hosts gelten ist mehr als ärgerlich erklärt aber eine Beobachtung die ich im privaten gemacht habe.
Ich habe zwei 2019er Hyper-Vs mit NVME SSDs und 8 Kern i7 CPUs laufen. Die VMs darauf fühlen sich im Vergleich zu den VMs die auf Proxmox und alten Dualcore NUCs laufen immer etwas träge an…
Kann es sein das der 2012R2 Hyper-V auch mit Write-Through gearbeitet hat?
Moin,
> Kann es sein das der 2012R2 Hyper-V auch mit Write-Through gearbeitet hat?
jup, das ist korrekt.
Ich bin zuerst (mangels Dokumentation seitens des Herstellers, 😡@Microsoft) davon ausgegangen, dass dieses Problem nur beim Hyper-V 2019 auftritt. Jedoch wurde ich mittlerweile von Microsoft selbst, eines Besseren belehrt. Der Write-Through Murks ist leider bei allen Hyper-V Versionen implementiert. ☹
Grüsse aus BaWü
Alex
Moin Zusammen,
ich habe zu dem Thema Hyper-V und Write-Through gestern den folgenden Uservoice eröffnet.
https://windowsserver.uservoice.com/forums/295056-storage/suggestions/42600535-write-back-option-for-hyper-v
Solltet Ihr den erzwungenen Write-Through auch nicht lustig finden, dann stimmt bitte mit ab, danke.
Grüsse aus BaWü
Alex