Datastore mit Festplatten

[schloegel-edv]

Hallo,

in der Doku wird ausdrücklich darauf hingewiesen, dass der Datastore mit SSDs besetzt werden soll. Gibt es denn echte Hinderungsgründe Festplatten einzusetzen?

• Eine Cache-SSD sollte man dann wenigstens einsetzen. Wie groß sollte die im Verhältnis zum Datastore denn sein? Was apssiert, wenn die defekt geht, lässt sich die Sicherung dann dennoch wiederherstellen und der Cache auswechseln?
• Könnte man auch externen Speicher als Datastore einbinden - eines NAS zum Beispiel - über NFS?

Danke im Voraus!

 

[Dunuin]

Hallo,

in der Doku wird ausdrücklich darauf hingewiesen, dass der Datastore mit SSDs besetzt werden soll. Gibt es denn echte Hinderungsgründe Festplatten einzusetzen?

• Eine Cache-SSD sollte man dann wenigstens einsetzen. Wie groß sollte die im Verhältnis zum Datastore denn sein? Was apssiert, wenn die defekt geht, lässt sich die Sicherung dann dennoch wiederherstellen und der Cache auswechseln?

Hängt davon ab was du als CacheSSD bezeichnest.
Versagt das "Special Device" sind alle Daten auf den HDDs weg. Dafür würde das Special Device aber auch bei Async Writes helfen.
L2ARC sollte maximal 10 mal so groß sein wie dein ARC. Der L2ARC kann ruhig ausfallen.
SLOG kann meistens ausfallen, aber im Worst Case kann man auch Daten von der HDD verlieren, wenn man den SLOG nicht spiegelt. SLOG macht aber wohl wenig Sinn, da ein SLOG nur bei Sync Writes hilft und PBS wohl eher Async Writes macht.

• Könnte man auch externen Speicher als Datastore einbinden - eines NAS zum Beispiel - über NFS?

Ich habe hier einen PBS Datastore auf einem NFS Share über 10Gbit Ethernet auf Raidz1 aus 4 HDDs. Ein voller Verify-Job dauert da 6 Stunden je TB und ein GC-Job 2 Stunden je TB. PBS braucht gute random IOPS da alles in Millionen von Chunks, die nur 512B-4M groß sind, gespeichert wird. Also quasi genau das, wo HDDs einfach schrecklich für sind. Und die zusätzlichen Latenzen von NFS helfen da auch nicht gerade bei den IOPS.

 

[fabian]

https://git.proxmox.com/?p=proxmox-...2f232e1f00efe2717a168043c7d82e61e;hb=HEAD#l71 enthaelt auch ein paar 'daumen mal pi' rechnungen dazu

 

[Dunuin]

https://git.proxmox.com/?p=proxmox-...2f232e1f00efe2717a168043c7d82e61e;hb=HEAD#l71 enthaelt auch ein paar 'daumen mal pi' rechnungen dazu

Auch mal eine Frage zu ZFS und Chunksize. Ich mache gerade mein NAS neu und bin gerade dabei meine PBS Datastores zu kopieren.

Was ich dem Rsync so grob entnehmen kann ist, dass da die meisten Chunks grob zwischen 2 und 4 MB sind, es aber auch kleinere Chunks gibt mit teils nur wenigen hundert KB.
Ich würde jetzt mal vermuten das waren dann 4MB Datenblöcke mit vielen Nullen, welche sich super per ZSTD komprimieren ließen.

Mein alter Datastore war ein ZFS Dataset mit 1M Recordsize und LZ4 Kompression. Kompressionsfaktor vom Dataset war da 1.06x.

Jetzt habe ich ein Dataset mit 128k Recordsize und sowohl mit LZ4 als auch ZSTD hat das Dataset nur noch einen Kompressionsfaktor von 1.03x.

ZSTD-Kompression vom Dataset macht also wohl keinen Sinn, weil ja schon PBS die Chunks mit ZSTD komprimiert. Da würde ich dann wieder auf LZ4 wechseln, was ja kaum Leistung braucht und gleich viel Platz einsparrt.

Wie sieht es aber bei PBS Workloads mit der optimalen Recordsize aus?

Ich hätte jetzts getippt 1M Recordzlsize wäre nicht schlecht, weil ich ja HDDs habe die eh ständig am IOPS-Limit liegen und so jeder Chunk aus weniger Records bestehen muss und daher ein Lesen/Schreiben eines Chunks weniger IO verursacht und der Datastore weniger fragmentiert sein sollte.

Wenn ich es richtig sehe sollten Chunks unter 1MB auch nicht so das große Problem sein, weil ZFS auch Records schreiben kann die kleiner als die Recordsize sind.
Wie ist es aber z.B. bei einem 1,1 MB Chunk? Wurde ZFS mit einer 1M Recordsize dann 1x 1MB + 1x 128k Records schreiben oder gleich 2x 1M Records? Da hätte man dann ja 900KB unnotig geschrieben/gelesen und eine 128k Recordsize die 11x 128k schreibt/liest wäre sinnvoller?

Und einen 2MB Chunk wurde man mit einer 128K Recordsize auch nicht schneller gelesen/geschrieben bekommen als mit einer 1M Recordsize, da PBS nicht partiell auf Chunks zugreift sondern immer den kompletten Chunk lesen/schreiben will?

Habt ihr da mal Benchmarks gemacht?Macht dann da eine Recordsize von 1M am meisten Sinn?

 

[fabian]

Auch mal eine Frage zu ZFS und Chunksize. Ich mache gerade mein NAS neu und bin gerade dabei meine PBS Datastores zu kopieren.

Was ich dem Rsync so grob entnehmen kann ist, dass da die meisten Chunks grob zwischen 2 und 4 MB sind, es aber auch kleinere Chunks gibt mit teils nur wenigen hundert KB.
Ich würde jetzt mal vermuten das waren dann 4MB Datenblöcke mit vielen Nullen, welche sich super per ZSTD komprimieren ließen.

klingt nach einer guten arbeitshypothese

Mein alter Datastore war ein ZFS Dataset mit 1M Recordsize und LZ4 Kompression. Kompressionsfaktor vom Dataset war da 1.06x.

Jetzt habe ich ein Dataset mit 128k Recordsize und sowohl mit LZ4 als auch ZSTD hat das Dataset nur noch einen Kompressionsfaktor von 1.03x.

ZSTD-Kompression vom Dataset macht also wohl keinen Sinn, weil ja schon PBS die Chunks mit ZSTD komprimiert. Da würde ich dann wieder auf LZ4 wechseln, was ja kaum Leistung braucht und gleich viel Platz einsparrt.

ja, fuer datastores zahlt sich der CPU overhead von zstd vermutlich nicht aus.

Wie sieht es aber bei PBS Workloads mit der optimalen Recordsize aus?

Ich hätte jetzts getippt 1M Recordzlsize wäre nicht schlecht, weil ich ja HDDs habe die eh ständig am IOPS-Limit liegen und so jeder Chunk aus weniger Records bestehen muss und daher ein Lesen/Schreiben eines Chunks weniger IO verursacht und der Datastore weniger fragmentiert sein sollte.

Wenn ich es richtig sehe sollten Chunks unter 1MB auch nicht so das große Problem sein, weil ZFS auch Records schreiben kann die kleiner als die Recordsize sind.

genau, recordsize ist eine obergrenze. die tatsaechliche blockgroesse muss immer ein vielfaches vom ashift sein (standard heutzutage 12 == 4k).

Wie ist es aber z.B. bei einem 1,1 MB Chunk? Wurde ZFS mit einer 1M Recordsize dann 1x 1MB + 1x 128k Records schreiben oder gleich 2x 1M Records? Da hätte man dann ja 900KB unnotig geschrieben/gelesen und eine 128k Recordsize die 11x 128k schreibt/liest wäre sinnvoller?

s.o. - recordsize ist eine obergrenze. dh. hier wuerden vermutlich 1x1MB als ein grosser record, und der rest als record mit groesse aufrunden auf naechstes vielfaches vom ashift wert gespeichert werden (plus entsprechende metadaten/indirekte records). "verschwendet" werden sollte also nur bis maximal ashift-1 an platz (auf ZFS ebene) - die platte selber kann natuerlich dann nochmal einen read-modify-write cycle machen wenn ihre (interne) blockgroesse groesser ist als die von ZFS, das ist aber im normalfall nur bei SSDs/NVMEs der fall.

Und einen 2MB Chunk wurde man mit einer 128K Recordsize auch nicht schneller gelesen/geschrieben bekommen als mit einer 1M Recordsize, da PBS nicht partiell auf Chunks zugreift sondern immer den kompletten Chunk lesen/schreiben will?

grosse records sind fuer PBS usage sicher besser (weil damit die chance steigt, dass die daten eines chunks sequentiell auf der platte landen, und die anzahl an indirekten records kleiner wird wenn ein chunk aus ein paar records besteht statt aus vielen), aber obs in der praxis einen grossen unterschied machen wird kann ich dir nicht sagen.

Habt ihr da mal Benchmarks gemacht?Macht dann da eine Recordsize von 1M am meisten Sinn?

benchmarks hab ich keine gemacht

 

[Dunuin]

klingt nach einer guten arbeitshypothese

ja, fuer datastores zahlt sich der CPU overhead von zstd vermutlich nicht aus.

genau, recordsize ist eine obergrenze. die tatsaechliche blockgroesse muss immer ein vielfaches vom ashift sein (standard heutzutage 12 == 4k).

s.o. - recordsize ist eine obergrenze. dh. hier wuerden vermutlich 1x1MB als ein grosser record, und der rest als record mit groesse aufrunden auf naechstes vielfaches vom ashift wert gespeichert werden (plus entsprechende metadaten/indirekte records). "verschwendet" werden sollte also nur bis maximal ashift-1 an platz (auf ZFS ebene) - die platte selber kann natuerlich dann nochmal einen read-modify-write cycle machen wenn ihre (interne) blockgroesse groesser ist als die von ZFS, das ist aber im normalfall nur bei SSDs/NVMEs der fall.

grosse records sind fuer PBS usage sicher besser (weil damit die chance steigt, dass die daten eines chunks sequentiell auf der platte landen, und die anzahl an indirekten records kleiner wird wenn ein chunk aus ein paar records besteht statt aus vielen), aber obs in der praxis einen grossen unterschied machen wird kann ich dir nicht sagen.

benchmarks hab ich keine gemacht

Danke, dann werde ich die Datasets auf LZ4 mit 1M Recordsize stellen und die Datastores noch einmal neu schreiben lassen.

"Spezial Devices" die ausschließlich Metadaten speichern scheinen sich übrigens nicht nur wegen GC/prune Jobs zu lohnen. Wenn ich viele kleinere Dateien per SMB lese dann habe ich 2,5 bis 3-fache Performance.
Also wenn die HDDs keine Metadaten mehr schreiben/lesen müssen, dann entlastet es diese schon enorm.

 

[fabian]

ja klar - der hauptvorteil vom special vdev ist dass du nicht mehr den preis fuer viele seeks fuer metadaten zugriffe/updates zahlen musst die hauen dir sonst den durchsatz bei klassischen festplatten sehr schnell zusammen.. fileserver profitieren hier natuerlich genauso, wenn nicht gerade nur riesige dateien drauf liegen

 

[Felix.]

Ich verwende recordsize=4M und erziele aktuell mit zstd eine compressratio von 1.21x bei ca. 1.2 TB im datastore, ca. 2200 Backups, Deduprate 111.32x.
Pool ist ein MIrror aus 2x 4TB Enterprise HDDs, kein Special Device oder Sonstiges mit dran.

Bin mit der Gesamtleistung absolut zufrieden, großartige Messungen habe ich keine vorgenommen.
Wenn jemand nen Befehl hat um z.B. die durchschnittlichen Chunk Sizes zu errechnen, führe ich das gerne mal aus und teile die Ergebnisse mit euch.

 

[Dunuin]

Als ein ...

cd /mnt/MeinDatastore/.chunks
find . -type f -print0 | xargs -0 ls -l | awk '{ n=int(log($5)/log(2)); if (n<10) { n=10; } size[n]++ } END { for (i in size) printf("%d %d\n", 2^i, size[i]) }' | sort -n | awk 'function human(x) { x[1]/=1024; if (x[1]>=1024) { x[2]++; human(x) } } { a[1]=$1; a[2]=0; human(a); printf("%3d%s: %6d\n", a[1],substr("kMGTEPYZ",a[2]+1,1),$2) }'

...ergibt bei mir:

Datastore 1:

 1k:    710
  2k:    499
  4k:    700
  8k:   1056
 16k:   1532
 32k:   2872
 64k:   4271
128k:   5809
256k:  10722
512k:  22991
  1M:  23191
  2M:  17315
  4M:   2915
  8M:     96
 16M:      3

Datastore 2:

 1k:    927
  2k:    766
  4k:   1112
  8k:   1816
 16k:   2836
 32k:   4970
 64k:   7620
128k:  10421
256k:  22231
512k:  42756
  1M:  86739
  2M:  71730
  4M:  28450
  8M:    233
 16M:      5

Recordsize von 4M wäre natürlich nett und könnte ich wohl auch per CLI erzwingen, aber lasse ich mal lieber, weil TrueNAS per webUI nicht mehr als 1M erlaubt. Nicht dass da dann TrueNAS durcheinander kommt.

Auszug aus der OpenZFS Dokumentation:

Larger record sizes​

Record sizes of up to 16M are supported with the large_blocks pool feature, which is enabled by default on new pools on systems that support it. However, record sizes larger than 1M is disabled by default unless the zfs_max_recordsize kernel module parameter is set to allow sizes higher than 1M. Larger record sizes than 1M are not well tested as 1M, although they should work. `zfs send` operations must specify -L to ensure that larger than 128KB blocks are sent and the receiving pools must support the large_blocks feature.

Gehe ich dann lieber mal auf Nummer sicher und bleibe bei 1M.

Edit:

zfs list -o space -r HDDpool
NAME                                                   AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
HDDpool/VeryLongDatasetName/VLT/NRM/PBS                2.91T   494G        0B    494G             0B         0B
HDDpool/VeryLongDatasetName/VLT/NRM/PBS_TMP            2.91T   481G        0B    481G             0B         0B
HDDpool/VeryLongDatasetName/VLT/NVR/PBS2               2.91T   122G        0B    122G             0B         0B
HDDpool/VeryLongDatasetName/VLT/NVR/PBS2_TMP           2.91T   118G        0B    118G             0B         0B

zfs get name,recordsize,compression,compressratio
NAME                                      PROPERTY       VALUE                                     SOURCE
HDDpool/VeryLongDatasetName/VLT/NRM/PBS  recordsize     128K                                     default
HDDpool/VeryLongDatasetName/VLT/NRM/PBS  compression    zstd                                     local
HDDpool/VeryLongDatasetName/VLT/NRM/PBS  compressratio  1.03x                                    -

HDDpool/VeryLongDatasetName/VLT/NRM/PBS_TMP  recordsize     1M                                           local
HDDpool/VeryLongDatasetName/VLT/NRM/PBS_TMP  compression    lz4                                          inherited from HDDpool
HDDpool/VeryLongDatasetName/VLT/NRM/PBS_TMP  compressratio  1.21x                                         -

HDDpool/VeryLongDatasetName/VLT/NVR/PBS2  recordsize     128K                                      default
HDDpool/VeryLongDatasetName/VLT/NVR/PBS2  compression    zstd                                      local
HDDpool/VeryLongDatasetName/VLT/NVR/PBS2  compressratio  1.04x                                     -

HDDpool/VeryLongDatasetName/VLT/NVR/PBS2_TMP  recordsize     1M                                            local
HDDpool/VeryLongDatasetName/VLT/NVR/PBS2_TMP  compression    lz4                                           inherited from HDDpool
HDDpool/VeryLongDatasetName/VLT/NVR/PBS2_TMP  compressratio  1.19x                                         -

Daraus würde folgen:

	Kompressionsfaktor:	Datengröße vor Kompression:	Datengröße nach Kompression:
Datastore mit 128K Recordsize:	1.03x	508,82 G	494G
Datastore mit 1M Recordsize:	1.21x	538,72 G	481G

Die höhere Kompressionsrate ist also irreführend, weil das erhöhen der Recordsize auch die unkomprimierte Datenmenge erhöht. Klingt dann zwar toll mit 0.18x mehr Kompressionsrate, aber 128K recordsize ist auch nur 2.7% und nicht 17.5% größer als eine Recordsize von 1M.

Klingt für mich also so, als wenn da ZFS dann doch mit einer größeren Recordsize öfter mit Nullen auffüllen muss.

 

[Felix.]

Hier noch die versprochene Aufzählung aus meinem Datastore:

  1k:   6112
  2k:   5090
  4k:   7282
  8k:  10199
 16k:  22877
 32k:  52426
 64k:  57533
128k:  59923
256k:  68144
512k: 125568
  1M: 185843
  2M: 150328
  4M:  67005
  8M:   2688
 16M:     21

1M vs 4M recordsize versetzt letztendlich sicher keine Berge, bislang entstanden allerdings auch keinerlei Probleme dadurch und da PBS ohnehin in 4M chunks "denkt", hielt ich das für sehr passend.
Letztendlich sind die Ersparnisse eher ein angenehmer Nebeneffekt, der tatsächliche Speicherplatzgewinn wird ja von PBS selbst realisiert durch die direkte Komprimierung und Deduplizierung der Chunks.