Write Back (safe) + Pure Storage – sinnvoll für produktive Windows-Server?

[j.gelissen]

Hallo zusammen,

wir betreiben Proxmox 9.1 mit einem Pure Storage FlashArray (iSCSI+ multipath, 25 Gbit) und mehrere Windows-Server (u. a. Terminalserver).

Zum Test habe ich bei einer VM den Cache auf „Write Back (safe)“ gestellt.
Mit CrystalDiskMark war die Performance (v. a. 4K Random Writes) bis zu 10× höher im Vergleich zu „No cache / Write through“.
Auch die Nutzer-Performance im Terminalserver ist merklich besser.

In der Doku wird das extra erwähnt und ich lese das als "mach das"

• For your virtual hard disk select "SCSI" as bus with "VirtIO SCSI single" as controller. Set "Write back" as cache option for best performance (the "No cache" default is safer, but slower) and tick "Discard" to optimally use disk space (TRIM). For the best performance, also make sure that IO Thread is enabled.

Meine Fragen:

1. Ist „Write Back (safe)“ in Kombination mit Pure Storage Array für produktive VMs unbedenklich? -> macht ihr das auch?!
2. Gibt es Best Practices oder Erfahrungen dazu?
3. Würdet ihr das global für Windows-Verwenden oder nur selektiv?
4. Empfehlungen für weitere Einstellungen? (SCSI-Controller, iothread, virtio usw.)

Umgebung:

• Proxmox 9.1
• Pure Storage FlashArray via iSCSI + multipath
• Windows Server 2019/2022
• Terminalserver + FSLogix
• USV vorhanden

Danke für eure Erfahrungen!

 

[Bu66as]

Hallo @j.gelissen,

die beobachtete Leistungssteigerung (insb. bei 4k Random Writes) ist bei Windows mit "Write Back" normal, da der Host die Schreibzugriffe im RAM puffert und gebündelt an das Storage weitergibt.

Zur Sicherheit:"Write Back" ist in Proxmox konsistenzsicher, da Flush-Befehle von Windows respektiert werden. Das einzige verbleibende Risiko ist ein harter Stromausfall des Hosts (Daten im RAM gehen verloren, bevor sie das Storage erreichen). Da eine USV vorhanden ist, ist dieses Risiko für Terminalserver meist vertretbar.

Empfohlene Settings für Pure Storage (iSCSI):

• Controller: VirtIO SCSI single
• Cache: Write back
• Discard: on (essenziell für FlashArray)
• IO Thread: on
• Async IO: io_uring

Du kannst das so produktiv nutzen.

 

[j.gelissen]

• Discard: on (essenziell für FlashArray)

Das ist aktuell bei mir aus weil bei der Migration ist das im Standard immer aus. Kann man das nachträglich aktivieren? Ist das gefährlich wenn es aus ist? Weil du geschrieben hast essenziell

 

[Bu66as]

@j.gelissen,

ja, Discard lässt sich nachträglich in den Hardware-Optionen der Disk aktivieren. Damit Windows die Änderung sicher als Feature der virtuellen Disk erkennt, ist ein kompletter Neustart (Stop/Start) der VM empfehlenswert.

Es ist nicht gefährlich für die Datenintegrität, wenn es aus ist. "Essenziell" bezog sich auf die Speichereffizienz: Ohne Discard (TRIM) erfährt das Pure Storage Array nie, wenn du Dateien in Windows löschst. Das Array behält die Datenblöcke belegt, und dein physischer Speicher läuft voll, obwohl Windows noch freien Platz anzeigt.

Nach dem Aktivieren und Neustart solltest du in Windows einmal die Laufwerksoptimierung (Defrag/Trim) manuell anstoßen, um den ungenutzten Platz rückwirkend freizugeben.

 

[j.gelissen]

@j.gelissen,

ja, Discard lässt sich nachträglich in den Hardware-Optionen der Disk aktivieren. Damit Windows die Änderung sicher als Feature der virtuellen Disk erkennt, ist ein kompletter Neustart (Stop/Start) der VM empfehlenswert.

Es ist nicht gefährlich für die Datenintegrität, wenn es aus ist. "Essenziell" bezog sich auf die Speichereffizienz: Ohne Discard (TRIM) erfährt das Pure Storage Array nie, wenn du Dateien in Windows löschst. Das Array behält die Datenblöcke belegt, und dein physischer Speicher läuft voll, obwohl Windows noch freien Platz anzeigt.

Nach dem Aktivieren und Neustart solltest du in Windows einmal die Laufwerksoptimierung (Defrag/Trim) manuell anstoßen, um den ungenutzten Platz rückwirkend freizugeben.

Wir nutzen Proxmox im Cluster mit iSCSI + Multipath auf einem Pure Storage Array und haben uns deshalb für LVM thick entschieden (Stabilität / Cluster-Tauglichkeit mit Multipath).

Jetzt zur Frage:

Wirkt Discard / TRIM in so einem Setup überhaupt bis zum Array?

Nach meinem Verständnis terminiert LVM thick UNMAP/Discard, d. h. selbst wenn:

• Discard an der VM-Disk in Proxmox aktiviert ist (VirtIO SCSI)
• im Gast fstrim (Linux) bzw. ReTrim (Windows) ausgeführt wird

…sieht das Pure Storage Array davon nichts, weil das LUN für das Array immer vollständig allokiert bleibt.

Heißt das im Umkehrschluss:

• ✔ Datenintegrität unkritisch
• keine echte Rückgabe von freiem Speicher an das Array
• ✔ nur logische Freigabe innerhalb des LV

Und wäre für echte Speicherfreigabe auf Pure Storage in Proxmox zwingend LVM-thin (oder ein anderes discard-fähiges Backend) nötig?

Bestätigt jemand diese Annahme aus der Praxis?

 

[Falk R.]

Wir nutzen Proxmox im Cluster mit iSCSI + Multipath auf einem Pure Storage Array und haben uns deshalb für LVM thick entschieden (Stabilität / Cluster-Tauglichkeit mit Multipath).

Jetzt zur Frage:

Wirkt Discard / TRIM in so einem Setup überhaupt bis zum Array?

Ja und auch nur da.

Nach meinem Verständnis terminiert LVM thick UNMAP/Discard, d. h. selbst wenn:

• Discard an der VM-Disk in Proxmox aktiviert ist (VirtIO SCSI)

geht bei allen Controllern nicht nur VirtIO

• im Gast fstrim (Linux) bzw. ReTrim (Windows) ausgeführt wird

Macht das OS selbst, sobald das Flag gesetzt ist, außer man hat noch Windows 2008 im Einsatz.

…sieht das Pure Storage Array davon nichts, weil das LUN für das Array immer vollständig allokiert bleibt.

Nicht wirklich, die Pure bekommt das schon mit. Wenn du natürlich den Speicher komplett reservierst, und mehr macht ein ThinProv. Storage nicht wenn man Thick im Storage auswählt, dann zeigt dein Storage das als belegt an, obwohl das Storage weiß, dass da keine Daten sind.

Heißt das im Umkehrschluss:

• ✔ Datenintegrität unkritisch
• keine echte Rückgabe von freiem Speicher an das Array

Die Pure bekommt das mit.

• ✔ nur logische Freigabe innerhalb des LV

Und wäre für echte Speicherfreigabe auf Pure Storage in Proxmox zwingend LVM-thin (oder ein anderes discard-fähiges Backend) nötig?

Du machts ja im Storage Thin, dann brauchst du das im Hypervisor nicht machen. LVM-thin ist auch nicht Clusterfähig.

Bestätigt jemand diese Annahme aus der Praxis?

In der Praxis habe ich sehr selten Pure in der Hand, da etwas teuer, aber bei Huawei Dorado, Dell Powerstore oder auch Storagevirtualisierung wie DataCore habe ich oft.
Da macht man ganz normale vDisks im Storage (Thin). Dann Klassisches LVM auf die LUN und dann kann man auch sehen wie Blöcke wieder freigegeben werden, wenn Discard bei der virtuelle Disk aktiviert ist.

 

[j.gelissen]

Ich hätte dazu noch eine abschließende Frage:

Wir arbeiten mit einer Pure Storage FlashArray (Pure Station Array) in Kombination mit iSCSI und Multipath. Zusätzlich ist vor dem Storage und den Servern eine USV geschaltet.

Unter diesen Voraussetzungen:
Ist es unkritisch bzw. empfehlenswert, auf allen Servern – inklusive der SQL-Server – Write Back Cache zu aktivieren?
Oder gibt es hierbei bestimmte Szenarien oder Workloads, bei denen man vorsichtig sein sollte?

Vielen Dank vorab für eure Einschätzungen.

 

[Falk R.]

Theoretisch kannst du das machen, ich aktiviere den Write Cache bei DB Servern aber nie. Wenn du eine Pure FA hast und keine Lizenzbeschräkungen im Storage dagegen sprechen, benutze lieber NVMe over TCP. Den Unterschied zu iSCSI merkst du bei DB Servern schon deutlich.

 

[j.gelissen]

Theoretisch kannst du das machen, ich aktiviere den Write Cache bei DB Servern aber nie. Wenn du eine Pure FA hast und keine Lizenzbeschräkungen im Storage dagegen sprechen, benutze lieber NVMe over TCP. Den Unterschied zu iSCSI merkst du bei DB Servern schon deutlich.

Glaube ich gerne, aber ich denke, den Write Cache zu aktivieren ist „auf die Schnelle“ deutlich schneller erledigt, als NVMe/TCP zu aktivieren, oder?

 

[Falk R.]

Glaube ich gerne, aber ich denke, den Write Cache zu aktivieren ist „auf die Schnelle“ deutlich schneller erledigt, als NVMe/TCP zu aktivieren, oder?

Ja schneller schon, aber nicht nachhaltiger.
Wenn du NVMe over TCP nutzt, hast du kein umständliches Multipating mehr, das macht das NVME Protokoll automatisch und die Performance von allen VMs verbessert sich. Daher stelle ich das bei jedem Kunden um, der ein Storage hat, wo das unterstützt wird.
Man muss halt neue Namespaces generieren und diese an den Host geben, dann die VMs auf die neuen Namespaces migrieren und danach die iSCSI Konfiguration löschen. Kein Hexenwerk, aber ist ein klein wenig Arbeit, die sich aber lohnt.

 

[LgAltair]

Hast du aber bei NVMe over TCP Snapshots Möglichkeiten? Nicht auf Storage Ebene sondern von Proxmox?

 

[Falk R.]

Hast du aber bei NVMe over TCP Snapshots Möglichkeiten? Nicht auf Storage Ebene sondern von Proxmox?

Genau so viel oder wenig wie bei iSCSI oder FC. Das Protokoll ist da egal, es geht ja darum ob man das Storage shared benutzt.
Bei shared LVM gibts den Snapshot Support (noch Experimentell), wenn man das unbedingt braucht. Aber ob man iSCSI oder NVMe nutzt hat nur einfluss auf Performance und ob man sich manuell ums multipathing kümmern muss.