ZFS Pool mixed SSD/HDD: VMs/LXC nur auf SSD

[Mrt12]

Hallo,
Endlich habe ich Gelegenheit, meinen Heim-Bastelserver zu erneuern, was ich schon lange tun wollte.
Ich habe eine grössere Menge WD Ultrastar DC HC530 geschenkt bekommen (BJ 2019 und SMART ist OK). Ausserdem habe ich noch für sehr kleines Geld woanders ein paar SSDs bekommen, mit nur um die 1% wear:

- 3x HUSSL4040BSS600 (400 GB, 35 PBW)
- 6x S842E400 (ebenfalls 400 GB, 30 PBW)

Ich möchte nun auf dem Heimserver einen neuen Proxmox Node einrichten und dabei die Hard Disks als Datengrab nutzen, für Sachen wie Filme, Musiksammlung und so weiter. Die SSDs werde ich als "special device" nutzen und dann einen Dataset einrichten, mit "special_small_blocks = recordsize", sodass ich ein Dataset für die "heissen" Daten habe, wo ich mit arbeite. Also für den NAS Speicher kreiere ich dann 2 neue Datasets:

tank/fast -> hier wird "special_small_blocks=recordsize" gesetzt -> alle Daten landen auf den SSDs
tank/hdd -> hier wird "special_small_blocks=0" gesetzt -> alle Daten landen auf den HDDs und nur Metadaten auf den SSD

Den ZFS Pool wollte ich etwa so einrichten:

mirror-0 (14TB)
   HC530
   HC530
special (1200 GB)
 mirror-1
   HUSSL4040
   S842
 mirror-2
  HUSSL4040
  S842
 mirror-3
  HUSSL4040
  S842

Dann sind noch ein paar HC530 übrig, werde wohl einige davon verschenken und ein paar als Ersatz. Beim special device habe ich immer extra 2 verschiedene SSDs gepaart.

Den Special Device habe ich extra so gross gemacht, weil ich gerne erzielen möchte, dass sämtliche VMs und Container ebenfalls NUR auf den SSDs zu liegen kommen. Die Harddisks sollen also nur für die Daten benutzt werden, auf die man nicht soooo häufig zugreift, eben Filme, RAW Photosammlungen und sowas.

Kann ich Proxmox irgendwie so konfigurieren, dass er beim erstellen eines LXC oder einer VM ebenfalls "special_small_blocks=recordsize" nutzt, sodass die VMs und LXCs ausschliesslich von den SSDs rennen? ich bin mir grade nicht sicher, ob ich dazu unter "Datacenter", "Storage" einen "Directory" benutzen soll oder ob es noch eine bessere Lösung gibt. Ich glaube, mit "Directory" wird dann ein RAW file erstellt, wo ich nicht sicher bin, ob das so toll ist.

Und: welchen ashift verwende ich am besten für die SSDs? im Datenblatt ist nichts genaues spezifiziert; ich würde gern den ashift so wählen, dass die SSDs möglichst lange leben. Oder ist es bei diesen Modellen unter "Normalbedingungen" als NAS und VM Speicher überhaupt möglich, die SSDs kaputtzukriegen, und damit irrelevant welchen ashift man nutzt? ich habe leider noch keine Erfahrung mit solchen "Monster" SSDs. Riesen Teile. Und 30 PBW. Wahnsinn. Das Problem dürfte sein, wenn die SSDs mal ersetzt werden müssten, dafür Ersatz zu finden. Ich glaube, es war ein extremer Glücksfall; solche SSDs sind vermutlich im Normalfall unfassbar teuer. Seagate Nytro 400 GB habe ich gesehen ~700€ und hat allerdings "nur" / PBW, ist also deutlich "schwächer" als meine HUSSL4040. Wobei ich allerdings noch nicht einmal sicher bin, inwiefern die TBW/PBW Angabe wirklich Aussagekraft über die Zuverlässigkeit hat, da die SSD ja theoretisch schon vor Erreichen des Werts ausfallen könnte. Weiss da jemand was drüber?

 

[Dunuin]

tank/hdd -> hier wird "special_small_blocks=0" gesetzt -> alle Daten landen auf den HDDs und nur Metadaten auf den SSD

Nimm doch ein special_small_blocks von 4 bis 16K oder so für Dataset? HDDs würden ja auch davon profitieren, wenn wenigstens winzige Dateien ebenfalls auf der SSD landen und nur die größeren Dateien auf den HDDs.

Kann ich Proxmox irgendwie so konfigurieren, dass er beim erstellen eines LXC oder einer VM ebenfalls "special_small_blocks=recordsize" nutzt, sodass die VMs und LXCs ausschliesslich von den SSDs rennen?

Die Datasets von den LXCs bekommen die Konfigs von dem Eltern-Dataset vererbt. Du kannst ein beliebiges Dataset als ZFS Storage im webUI festlegen und dann für das Elterndataset deine special_small_blocks festlegen. Alle auf den ZFS Storage erstellten LXCs bekommen das dann vererbt.

Und: welchen ashift verwende ich am besten für die SSDs? im Datenblatt ist nichts genaues spezifiziert; ich würde gern den ashift so wählen, dass die SSDs möglichst lange leben. Oder ist es bei diesen Modellen unter "Normalbedingungen" als NAS und VM Speicher überhaupt möglich, die SSDs kaputtzukriegen, und damit irrelevant welchen ashift man nutzt?

Kein Hersteller verrät dir was da eine SSD intern für eine Blockgröße nutzt. Da kannst du nur Benchmarken mit verschiedenen Ashifts und dann anhand der Performance raten.
Im Zweifelsfall ashift=12 nehmen. Die meisten SSDs werden für 4K Sektorgröße über die Firmware optimiert sein. Am besten mit den Toola vom Hersteller nich die SSD auf 4K umformatieren, falls die für 512B optimiert im Einsatz waren.
Bei Enterprise SSD kann man meist in der Firmware wählen ob man 512B oder 4K will und 4K sollte besser performen.

Wobei ich allerdings noch nicht einmal sicher bin, inwiefern die TBW/PBW Angabe wirklich Aussagekraft über die Zuverlässigkeit hat, da die SSD ja theoretisch schon vor Erreichen des Werts ausfallen könnte. Weiss da jemand was drüber?

Also ich habe hier 21 ähnliche im Homelab alle zwischen 0 und 4% Wear und eine war mal plötzlich ohne Warnzeichen tot. Da hat sich dann wohl der Controller verabschiedet oder so weil laut SMART weil alles bis zum Schluss bestens...aber dafür hat man ja Mirrors und Reserve rumliegen.
Ordentliches Monitoring mit Notifications einrichten nicht vergessen, dass du das dann schnell mitbekommt. PVE warnt dich da nicht im webUI, wenn dir eine Disk ausfällt.
Z.B. über zfs-zed + postfix oder externe Monitoring-Software wie Zabbix.

 

[Mrt12]

Nicht doch ein special_small_blocks von 4 bis 16K oder so für Dataset? HDDs würden ja auch davon profitieren, wenn wenigstens winzige Dateien ebenfalls auf der SSD landen und nur die größeren Dateien auf den HDDs.



Die Datasets von den LXCs bekommen die Konfigs von dem Eltern-Dataset vererbt. Du kannst ein beliebiges Dataset als ZFS Storage im webUI festlegen und dann für das Elterndataset deine special_small_blocks festlegen. Alle auf den ZFS Storage erstellten LXCs bekommen das dann vererbt.



Kein Hersteller verrät dir was da eine SSD intern für eine Blockgröße nutzt. Da kannst du nur Benchmarken mit verschiedenen Ashifts und dann anhand der Performance raten.
Im Zweifelsfall ashift=12 nehmen. Die meisten SSDs werden für 4K Sektorgröße über die Firmware optimiert sein. Am besten mit den Toola vom Hersteller nich die SSD auf 4K umformatieren, falls die für 512B optimiert im Einsatz waren.
Bei Enterprise SSD kann man meist in der Firmware wählen ob man 512B oder 4K will und 4K sollte besser performen.



Also ich habe hier 21 ähnliche im Homelab alle zwischen 0 und 4% Wear und eine war mal plötzlich ohne Warnzeichen tot. Da hat sich dann wohl der Controller verabschiedet oder so weil laut SMART weil alles bis zum Schluss bestens...aber dafür hat man ja Mirrors und Reserve rumliegen.
Ordentliches Monitoring mit Notifications einrichten nicht vergessen, dass du das dann schnell mitbekommt. PVE warnt dich da nicht im webUI, wenn dir eine Disk ausfällt.
Z.B. über zfs-zed + postfix oder externe Monitoring-Software wie Zabbix.

Hmm ja das 4K special_small_blocks könnte man natürlich in Erwägung ziehen. Damit habe ich keine Erfahrung; ein special device mit special_small_blocks=0 hat aber gut funktioniert und gute Performance gebracht.

Ah ja, danke für den Tip, ich habe erst jetzt gesehen, dass ich auch ein einzelnes ZFS Dataset als Storage hinzufügen kann, ohne den "Umweg" über den "Directory"!

Wie kann ich die Blockgrössen der SSD umformatieren? Die HUSSL4040 SSD hat als einzige im Datenblatt eine Angabe, dass sie 512, 520, 528 und 4k Sektoren unterstützt. Kann ich das Umformieren mit sg_format machen?

Wie oft kommt das vor, dass ohne Vorwarnung im laufenden Betrieb so ein Controller stirbt? eigentlich sollte man doch meinen, dass so ein Controller nicht einfach so aussteigt. Eine CPU macht das im Normalfall ja auch nicht. Überhitzung? Spannungseinbrüche? ich habe aber in der Tat eine Publikation gefunden, wo das untersucht wurde, und dort wurde tatsächlich geschrieben, dass die TBW/PBW alleine kein guter Indikator für den SSD-Tod sind, sondern die meisten SSDs ausfielen, bevor die TBW erreicht wurden sind, durch Ausfall der Controller, also genau dein Symptom.

Was für SSDs hast du? kennst du die von mir benutzten SSDs, sind die gut? (sind eher älter, aber dafür dürften die Controller Firmware Bugs mittlerweile bekannt sein... :-D )
man findet im Freenas Forum einige Leute, die diese benutzen und offenbar zufrieden sind.

 

[news]

Wie kann ich die Blockgrössen der SSD umformatieren? Die HUSSL4040 SSD hat als einzige im Datenblatt eine Angabe, dass sie 512, 520, 528 und 4k Sektoren unterstützt. Kann ich das Umformieren mit sg_format machen?

Nun ein zpool destroy und dann den Pool neu anlegen!

 

[Mrt12]

Nun ein zpool destroy und dann den Pool neu anlegen!

Nein. Das ändert nur den ashift.
Die Blockgrösse, die die SSD hat,512/520/528/4k ist von zpool völlig unabhängig.

 

[news]

Ja, meine SSD erkennen 512 oder 4096 Byte und stellen sich darauf ein.
Denn pool kann man nur neu erzeugen, um den ashift auf 12 Bit ein zu stellen.

 

[Mrt12]

nein. Der ashift muss zu den Disks passen, die Disks stellen sich nicht ein sondern haben die fixe Sektorgrösse, die bei einigen Disks durch "low level format" in Grenzen geändert werden kann. Benutzt man den falschen ashift, dann tritt "write amplification" auf. Zb. bei ashift=12 aber Blockgrödse=512: da werden 8 Blöcke neu geschrieben, wenn de facto nur einer sich geändert hat.

 

[Dunuin]

Wie kann ich die Blockgrössen der SSD umformatieren? Die HUSSL4040 SSD hat als einzige im Datenblatt eine Angabe, dass sie 512, 520, 528 und 4k Sektoren unterstützt. Kann ich das Umformieren mit sg_format machen?

Normal muss man das der Firmware der SSD sagen über die Verwaltungstools die du für die SSD vom Hersteller bekommst.

Nun ein zpool destroy und dann den Pool neu anlegen!

Nein, gemeint ist nicht die ashift sondern wie die SSD-Firmware intern arbeitet. Da bringt Pool neu anlegen nichts (muss man aber später, da so ein umformatieren der SSD alles löscht).

Ja, meine SSD erkennen 512 oder 4096 Byte und stellen sich darauf ein.

Dann meinst du wohl die üblichen 512B logical, 4K "physical" Sektoren, welche die SSD angibt. Das ist abern nicht gemeint, sondern man sagt der Firmware, dass sie alles löschen und sich selbst für die jeweilige Sektorgröße optimieren soll. Wenn deine SSD 512B und 4K kann, dann macht sie nur eines von beiden gut. Was von beiden sie gut macht bestimmt man über die Verwaltungstools des Herstellers. Entweder du optimierst sie für 512B dann sind 4K lansamer oder für 4K und dann sind 512B lahmer. Wenn man mit ashift=12 arbeitet sollte man also sicherstellen, dass die nicht vom vorbesitzer (oder werkseitig) für 512B optimiert wurde.

 

[Mrt12]

Normal muss man das der Firmware der SSD sagen über die Verwaltungstools die du für die SSD vom Hersteller bekommst.

ich habe da von dem sg_format Programm gelesen. Ich bin mir im Moment nicht sicher, ob ich für diese doch eher älteren SSDs noch die Verwaltungstools finde :-/
sagt dir das was, sg_format?

 

[Mrt12]

Hallo,

so ich konnte endlich ein paar Tests machen.
Ich habe mal den Pool wie oben gezeigt konfiguriert, d.h. mit den Ultrastar HDDs habe ich einen Mirror gemacht. Mit den HUSSL4040 habe ich den ZFS Special Device realisiert und mit den S842 habe ich den SLOG realisiert. Jeweils zum Testen nur je 2 Disks als Mirror.

Ich möchte gerne diejenige Anordnung finden, mit der ich meine Performance maximieren kann, da ich am Schluss die VMs mit der schnellst möglichen Performance rennen lassen möchte.

Mit dieser Konfig habe ich rund 4500 fsyncs/second. Ich bin ein wenig enttäuscht von den S842 SSDs, da diese laut Datenblatt wesentlich mehr können sollten.
Ich habe noch nicht alle möglichen Kombinationen durchprobiert. Deshalb die Frage: kann ich bei geschickter Anordnnung die fsyncs maximieren?

Eigentlich sind das ja Enterprise SSDs. Die sollten 20k IOPS locker können sagt das Datenblatt.

Noch eine andere Frage; wenn ich die VM Images sowieso komplett auf den SSD habe (special_small_block=recordsize), brauche ich dann den SLOG überhaupt oder sind dann die sync writes automatisch auch auf den SSD?

 

[Dunuin]

Eigentlich sind das ja Enterprise SSDs. Die sollten 20k IOPS locker können sagt das Datenblatt.

Die 20K aus dem Datenblatt beziehen sich dann aber auch rohe Blöcke ohne Dateisystem. Hast du die fsync-Benchmarks mit ZFS gemacht? Dann kommen ja auf jeden Datenblock noch 2-3 Metadatenblöcke und die IO vervielfacht sich.

Noch eine andere Frage; wenn ich die VM Images sowieso komplett auf den SSD habe (special_small_block=recordsize), brauche ich dann den SLOG überhaupt oder sind dann die sync writes automatisch auch auf den SSD?

Dann eh auf den ZIL der SSDs. Den SLOG hättest du dann für die HDDs wenn du special_small_block kleiner recordsize/volblocksize hättest.

 

[Mrt12]

Ja, den fsync benchmark habe ich mit dem ZFS Pool gemacht:

pveperf /tank/

sind denn die 4500 ein guter Wert? wie hoch kann man da kommen? bin ich systembedingt limitiert weil ich SAS habe anstatt nvme?

Dann eh auf den ZIL der SSDs. Den SLOG hättest du dann für die HDDs wenn du special_small_block kleiner recordsize/volblocksize hättest.

diesen Satz habe ich leider nicht verstanden.

 

[Dunuin]

Standardmäßig hat jede Disk einen ZIL-Bereich wo die Sync Writes zwischengespeichert werden. Hast du ein SLOG-Laufwerk lagerst du diesen ZIL-Bereich auf eine extra Disk aus.

Bei Datasets variiere die Größe der Records zwischen 512B und deiner Recordsize. Setzt du da special_small_blocks auf z.B. 64K und die Recordsize auf 128K, dann landet eine 20KB Große Datei auf den Special Devices da dies einen 32K Record erzeugt. Eine 40KB große Datei würde einen 64K Record erzeugen und damit auf den Datendisks landen. Eine 1MB Datei würde dann acht 128K Records erzeugen die alle auf die Datendisks gehen.

Bei Zvols hast du immer eine feste Blockgröße, die Volblocksize. Ist die Volblocksize 16K dann erzeugt das immer 16K Blöcke. Setzt du die special_small_blocks auf 4K oder 8K würden alle Blöcke auf den Datendisks landen. Setzt du die Volblocksize auf 16K oder höher würden alle Blöcke auf auf Special Devices gespeichert werden.

 

[Mrt12]

Standardmäßig hat jede Disk einen ZIL-Bereich wo die Sync Writes zwischengespeichert werden. Hast du ein SLOG-Laufwerk lagerst du diesen ZIL-Bereich auf eine extra Disk aus.

Bei Datasets variiere die Größe der Records zwischen 512B und deiner Recordsize. Setzt du da special_small_blocks auf z.B. 64K und die Recordsize auf 128K, dann landet eine 20KB Große Datei auf den Special Devices da dies einen 32K Record erzeugt. Eine 40KB große Datei würde einen 64K Record erzeugen und damit auf den Datendisks landen. Eine 1MB Datei würde dann acht 128K Records erzeugen die alle auf die Datendisks gehen.

Bei Zvols hast du immer eine feste Blockgröße, die Volblocksize. Ist die Volblocksize 16K dann erzeugt das immer 16K Blöcke. Setzt du die special_small_blocks auf 4K oder 8K würden alle Blöcke auf den Datendisks landen. Setzt du die Volblocksize auf 16K oder höher würden alle Blöcke auf auf Special Devices gespeichert werden.

jup. Das ist mir klar. Danke trotzdem für die Erklärung.

Was passiert, wenn ich ein Zvol habe und die special small blocks auf >=16K setze - wo liegt der ZIL in diesem Fall?

 

[Dunuin]

Bin nicht sicher, aber ZIL sollte immer auf dem SLOG liegen, egal was da deine special_small_blocks ist. Special_small_blocks sollte dann nur entscheiden, wo die Daten aus dem RAM dann endgespeichert werden.
Also sync writes erst zu RAM+SLOG und Async Writes nur in RAM. Danach bei der txg vom RAM die Metadaten immer auf das Special Device und Daten je nach Recordsize/Volblocksize entweder auf Special Device oder Datendisks. Außer dein Special Device ist voll. Dann schwappen Daten+Metadaten auf die Datendisks über. Bei Daten glaube ich ab 75% und bei Metadaten bei 100%.

 

[Mrt12]

Bin nicht sicher, aber ZIL sollte immer auf dem SLOG liegen, egal was da deine special_small_blocks ist. Special_small_blocks sollte dann nur entscheiden, wo die Daten aus dem RAM dann endgespeichert werden.
Also sync writes erst zu RAM+SLOG uns Async Writes nur in RAM. Danach bei der txg vom RAM die Metadaten immer auf das Special Device und Daten je nach Recordsize/Volblocksize entweder auf Special Device oder Datendisks. Außer dein Special Device ist voll. Dann schwappen Daten+Metadaten auf die Datendisks über. Bei Daten glaube ich ab 75% und bei Metadaten bei 100%.

OK ja das wäre sinnvoll. Ich dachte, vielleicht kann man irgendwie steuern, ob der ZIL doch auf die SSD kommt, wenn man special_small_blocks irgendwie richtig setzt.

Sind die 4500 ein guter Wert für die fsyncs/second oder ist da noch Luft nach oben? was hat dein Setup? kann ich es irgendwie noch verbessern mit meiner Hardware?
oder wäre es allenfalls viel besser, 2 Pools zu erstellen, einer nur aus HDDs und einer nur aus SSDs?
mir gefällt der Gedanke nicht so, dass dann 2 Pools sich den RAM teilen müssen.
Ich möchte einfach für die VM und LXC die best mögliche Performance mit meiner Hardware raus holen

übrigens gibt es bei OpenZFS einen interessanten Pull Request, nämlich dass die ZIL Blöcke auch vom special device allokiert werden können. Sodass man den special device auch als SLOG nutzen kann. Das fände ich sehr gut :-D

 

[Dunuin]

übrigens gibt es bei OpenZFS einen interessanten Pull Request, nämlich dass die ZIL Blöcke auch vom special device allokiert werden können. Sodass man den special device auch als SLOG nutzen kann. Das fände ich sehr gut :-D

Du kannst auch so schon die selbe Disk für SLOG und Special Device benutzen. Nimmt man halt zwei Partitionen statt der ganzen Disk. Würde ich aber nicht wollen. ZIL/SLOG ist das was SSDs am schnellsten killt. Und Special Devices sind KEIN cache. Sterben dir die Special Devices weg, dann sind auch alle Daten auf den Datendisks weg.