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

[floh8]

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.

 

[Falk R.]

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.

 

[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

 

[IsThisThingOn]

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.

 

[floh8]

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.

 

[IsThisThingOn]

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.

 

[Falk R.]

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.

 

[floh8]

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.

 

[floh8]

Hab gerade diesen Beitrag gefunden: https://forums.truenas.com/t/some-insights-and-generalizations-on-the-openzfs-write-throttle/1084
Der thematisiert die Problematik nochmal aus einer anderen Richtung. Sehr interessant.

 

[s.meier77]

Ich habe den Thread auf Grund einer Suche nach ZFS und Proxmox gefunden und würde gerne 2 Sachen korrigieren.

Ein SLOG beschleunigt sync writes.

Nein, Ein slog ansich beschleunigt überhaupt nichts. Das auslagern des ZIL auf ein schnelles extra Device beschleunigt die Antwort von ZFS, dass die Daten geschrieben wurden. Die sync Daten würden normalerweise in das ZIL geschrieben, welches auf die normalen HDDs verteilt ist. Da diese (normalen HDDS) bei einem extra SLOG nicht mehr die normalen Daten UND das ZIL schrieben müssen, bechleunigt das synchrone und asychrone (wenn es viele synchrone Schreibvorgänge gibt) Schreibvorgänge auf die normalen HDDs.
Denn:

sync writes landen nicht im RAM sonder im ZIL.

nein. Sync Writes landen genauso im RAM wie Async Writes. Sync Writes landen nur ZUSÄTZLICH im ZIL (beziehungsweise im SLOG-Device)
Und das Dateisystem meldet die sync writes erst als abgeschlossen, wenn sie in den nichtflüchtigen Speicher geschrieben sind. Wenn der ZIL nun auf einem schnellen extra Device liegt, hat das 2 Vorteile. Erstens der normale Speicher wird von den zusätzlichen Schreibvorgängen entlastet und die ZIL-Daten können schnell geschrieben werden. Das führt dazu dass das Gerücht entstanden ist das slog wäre ein Cache....

Das SLOG ist das ZIL auf einem extra Device.

Gelesen wird vom ZIL/SLOG allerdings im Normalfall NICHT! Das Schreiben der sync writes erfolgt vom RAM aus auf die langsamen HDD's. Wenn diese Schreibvorgänge abgeschlossen sind, wird das SLOG/ZIL wieder überschrieben. Nur im Fehlerfall, wenn es notwendig ist sychrone Schreibvorgänge zu recovern, wird vom ZIL/SLOG gelesen.

2 * 10 = 20GBit
20 * 5s = 100 GBit
100GBit / 8 = 12,5 GB

Das würde reichen.

 

[IsThisThingOn]

Nein, Ein slog ansich beschleunigt überhaupt nichts.

Ok, ich hätte anstelle von

Ein SLOG beschleunigt sync writes.

schreiben sollen:
Ein SLOG verschiebt den ZIL (nur sync writes) vom pool auf ein anderes Gerät.

bechleunigt das synchrone und asychrone

Nein, das ist falsch. Ein SLOG beschleunigt async nie. Niemals. Async berührt das SLOG noch nicht mal.
Schneller als async (RAM) geht nicht.

https://jrs-s.net/2019/05/02/zfs-sync-async-zil-slog/

 

[s.meier77]

Nein, das ist falsch. Ein SLOG beschleunigt async nie. Niemals. Async berührt das SLOG noch nicht mal.
Schneller als async (RAM) geht nicht.

Jein. Auch async writes müssen auf die "normalen" Platten geschrieben werden. Wenn es viele sync write Anforderungen gibt und die "normalen" Platten durch das SLOG entlastet sind können auch die async writes aus dem RAM in manchen Situationen schneller geschrieben werden. Ja, async writes "berühren" das ZIL (egal wo das liegt) nicht.