[SOLVED] Verständnisfrage über zfs zil/slog writeback an die zfs gurus

floh8

Renowned Member
Jul 27, 2021
1,060
117
73
Hallo Gemeinschaft,

wenn es um zfs zil und slog geht, findet man ja viele Hinweise im Netz, aber immer nichts Konkretes, woran man sich gut orientieren kann. Auch Erklärungen zu Funktionsweisen sind rar, deshalb stelle ich hier mal paar Fragen. Vielleicht kann ja einer weiterhelfen.

Ausgangssystem ist ein zfs Storage für Virtualisierung über NFS für Mix-Anwendungen. Es gibt 8 SSDs mit 500 GB Größe und ca. 500MB/s Schreibleistung die als SLOG in einem VDEV Mirror genutzt werden sollen. Als auch 16 HDDS mit 150MB/s und 4 TB, die auch als Raid10 im Backend genutzt werden. Die Anbinduung des Storage sind 2x 10GBit/s.
Wenn jetzt die Anwender mal richtig Schreib-Power geben und die Netzwerkbandbreite voll ausnutzen, kommen am Storsge 2x 1,25 GB/s brutto an. Die würden, weil ja sync-writes, im SLOG landen. Dieser kann 2 GB/s wegschreiben, also schafft nicht alles, dazu müßte man 2 SSDs mehr haben. Nun habe ich gelesen, dass zfs nach spätestens 5 sec die Daten aus dem slog auf das Backend schreibt. Nach 5s wären das 10 GB, die wegzuschreiben wären. Nun kann das Backend nur 1 GB/s wegschreiben. Was passiert jetzt genau? Das System wartet ja nicht 10 s bis das erledigt ist. Jetzt kommen ja auch weiterhin Daten an. Wo werden die hingeschrieben? Muss das SLOG dann mind. 2x 10 GB groß sein, damit zfs weiter Daten annehmen kann? Wenn die Datenflut aber nicht abebbt, muss der Netzwerkadapter ja irgendwie Pause machen, weil nix mehr geht. Die Daten stauen sich ja. Mich würde interressieren, wie das im Detail vor sich geht.
Meine Beispieldaten sind hoffentlich fehlerfrei und nachvollziehbar.

Eine weitere Frage wäre natürlich: Wie groß muss mind. der SLOG sein, wenn man 2x 10 GBit/s Anbindung hat.
 
Das Sizing musst du dir selbst ausdenken und am besten testen. Wenn die SSDs 500MB/s schreiben können, dann schaffen die das garantiert nicht wenn da kleine I/Os kommen.
Wenn dein Schreibchache voll ist, wird gedrosselt auf das Niveau der Datendisks. Manchmal hat man aber einen kleinen Delay drin wo die Leistung noch mehr einbricht und sich dann auf HDD Niveau einpendelt.
Außerdem müssen die User erst einmal so viele Daten produzieren.

P.S. wenn du ein Storage für VMs bauen willst wo echte Server mit mehreren Leuten drauf liergen, dann nimm auf keinen Fall große 3,5" HDDs. Die schaffen nicht sehr viele I/O was bei VMs wichtiger ist und die Zugriffszeiten sind auch deutlich schlechter. Für ein Homelab wäre die Konfiguration OK.
 
  • Like
Reactions: UdoB
Das System wartet ja nicht 10 s bis das erledigt ist.
Nach meinem Verständnis: Doch. Allerdings erst beim zweiten "Paket".

Aus meinem Gedächtnis: es gibt zwei (tatsächlich wohl bis zu drei) Transaction Groups pro Pool. In eine wird geschrieben, die andere wird "jetzt gerade" weggeschrieben und geleert.

Wenn die zweite noch nicht wieder leer ist, und die erste bereits wieder voll ist oder die 5 Sekunden vergangen sind... klemmt es.

Das Kürzel zum Suchen ist "zfs txg", mein erster Treffer ist https://www.delphix.com/blog/zfs-fundamentals-transaction-groups
 
Last edited:
  • Like
Reactions: Falk R.
wenn es um zfs zil und slog geht, findet man ja viele Hinweise im Netz, aber immer nichts Konkretes, woran man sich gut orientieren kann.
https://www.truenas.com/community/threads/the-path-to-success-for-block-storage.81165/

Es gibt 8 SSDs mit 500 GB Größe und ca. 500MB/s Schreibleistung die als SLOG in einem VDEV Mirror genutzt werden sollen.
Was für SSDs? Ich vermute, das ist kein gutes Setup für SLOG. Ich glaube du hast SLOG falsch verstanden.

SLOG enthält exklusiv sync writes. Async writes sind schnell dank RAM, sync writes landen nicht im RAM sonder im ZIL.
Der ZIL ist auf dem pool oder auf einen extra device SLOG.

Du brauchst also eine oder zwei SSDs (mirror ist nicht zwingend nötig, ZIL wird nur im Falle eines Crashes gelesen, du müsstest gleichzeitig auch noch ein SLOG Ausfall haben), die schnell sync writes können.

Alle consumer SSD sind extrem langsam im sync schreiben, schlimmstenfalls lügt sogar der Controller.
Eine einzelne gute PLP SSD oder Intel Optane performt deutlich besser.

Eine weitere Frage wäre natürlich: Wie groß muss mind. der SLOG sein, wenn man 2x 10 GBit/s Anbindung hat.
Ist natürlich abhängig davon, wie viel Sync writes überhaupt reinkommen. Aber angenommen es sind nur sync writes:
2 * 10 = 20GBit
20 * 5s = 100 GBit
100GBit / 8 = 12,5 GB

Der SLOG müsste 12,5GB gross sein.

Aber wie @Falk R. bereits richtig gesagt hat, IO ist vermutlich wichtiger. Du wirst ja nicht GBs an Bilder per sync writes auf die VMs schreiben ;) Den Durchsatz zu messen halte ich darum für wenig Aussagekräftig.
 
Last edited:
Danke für die Antworten. Also über transcation groups hatte ich bereits gelesen. Der Link war nochmal sehr informativ.
Zusammenfassend kann man also sagen:

- ein SLOG federt nur Schreibspitzen ab. Wenn dauerhaft das Netz ausgelastet ist, dann sollte man auf Full Flash gehen.
- das SLOG sollte mind. Netzwerkauslastung für 5 sec mal 3 Transaction Groups groß sein, damit ist man auf der sicheren Seite.
Das wären hier 3x 5x 2x 1,25 GB = 37,5 GB.
 
Last edited:
  • Like
Reactions: UdoB
ein SLOG federt nur Schreibspitzen ab.
Ein SLOG beschleunigt sync writes.
Wenn dauerhaft das Netz ausgelastet ist, dann sollte man auf Full Flash gehen.
Klar, flash ist tendenziell viel schneller und darum besser geeignet für Blockstorage.

Vielleicht hilft es, sich von dem Gedanken zu lösen, alles in einem pool zu haben. Ich habe schnelle nvme mirros für VMs, aber meine (sequenziellen) Daten können auch auf einem langsamen RAIDZ2 pool liegen.
 
Wenn du es 100% richtig machen willst musst du bei der Anwendung anfangen. Wie viel Traffic wird erzeugt und welche Latenzen sind erwünscht oder maximal duldbar.
Dann guck welches Wachstum erwartet wird und welchen Schutz du deinen Daten gönnen möchtest. Dann kannst du dir ausrechnen was dein Speicher leisten muss und dann fröhliches Shoppen gehen.
Leider werden oft erst die Disks gekauft und dann mal gucken wie man das beste raus bekommt.

Wenn du verrätst was du vor hast und was ungefähr an Traffic erwartet wird, können wir gern beim richtigen Sizing behilflich sein.
 
Wenn du verrätst was du vor hast und was ungefähr an Traffic erwartet wird, können wir gern beim richtigen Sizing behilflich sein.
War wirklich nur zum Verständnis. Die Daten waren nur ein Beispiel. Es ging um kein konkreten Anwendungsfall. Ich weiß, dass man hier im Forum schnelle und praxisnahe Hilfe bekommt. Das zeigen glaube ich auch die Nutzerstatistiken.:)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!