Wieso FreeNas nicht in VM unter Proxmox laufen lassen?

Danke für eure Antworten :)

Eine weitere Frage zum RAID Z2:

Ich kann ja einen Pool mit 2x RAIDZ2 erstellen, ja?! Wäre es dann quasi deutlich ausfallsicherer, wenn ich jeweils 2x6 Platten in einen Z2 Packe und das selbe nochmal, aber die beiden gemeinsam im selben Pool? Dann dürfen ja quasi bei jedem Z2 Raid 2 Platten von 6 ausfallen und es ist noch alles ok, oder?

Das OS und die VM´s würde ich wohl dann auf 2 Mirror SSD´s legen, da sind die wohl eh besser aufgehoben, da schneller und ich hau dafür nicht 8TB durch die ich da eh nie brauchen werden :-D

Wäre das vielleicht auch eine gute Option?
 
Ja, Proxmox und VMs auf einen SSD Mirror ist eine super Sache. Beachte dabei nur, dass da ZFS sehr schnell SSDs killen kann. Ich habe hier z.B. eine Write Amplification von Faktor 20 und die 30GB am Tag, welche in den VMs geschrieben werden sollen, werden dann zu 600GB am Tag, was die SSDs tatsächlich auf den NAND Flash schreiben müssen um diese 30GB zu speichern. Ganz schlimm kann das werden wenn du viele kleine Sync Writes hast. Da solltest du am besten Enterprise SSDs mit Powerloss-Protection und SLC/MLC NAND nehmen, welche für so etwas ausgelegt wurden. Die sind leider neu ziemlich teuer, aber gebraucht gut bezahlbar. Ich hatte meine gebraucht gekauft und die hatten trotz Abnutzung immer noch die 30-fache Lebenserwartung wie eine Consumer SSD für den selben Preis. Ohne Powerloss-Protection kann bei Sync Writes nicht der RAM-Cache in der SSD genutzt werden, was dazu führt, dass da keine Schreiboptimierungen mehr stattfinden können und die Write Amplification "explodiert".

Ein striped raidz2 (also wie Raid60) klingt gut als Kompromiss. Können 2-4 Platten ausfallen ohne Verlust, du hast doppelte Schreibrate im Vergleich zum einfachen raidz2 oder raidz3 also Performance schon etwas besser und Resilvern sollte sich in Grenzen halten. Lässt sicher später auch leichter erweitern, falls du noch einmal zusätzliche 6x 4TB hinzufügen willst und noch Platz für einen HBA da ist.

Raidz3 würde dir 36TB statt 32TB geben und es dürften 3 beliebige Platten ausfallen, aber das Resilvern würde auch ewig dauern und du hättest nur einfache Schreibrate.

Ein Mirrored Stripe würde deutlich mehr Performance geben (6-fache Schreibrate) aber du hättest nur 24TB statt 32TB und es dürften nur 1-6 Platten ausfallen. Wenn eine ungünstige Kombination ausfällt, dann reichen schon 2 Ausfälle und du verlierst Daten.

Ich bin nur gerade nicht sicher ob FreeNAS überhaupt ein striped raidz2 per GUI erstellen kann. Wüsste jetzt nicht das dort gesehen zu haben. Kann also sein, dass du da so ein Setup selbst per CLI anlegen musst.
 
Last edited:
Wie sieht das ganze aus, wenn ich das ZFS direkt im Proxmox laufen lassen würde? Was hat das bei diesem Setup für Vor- oder Nachteile?

Es ist echt Wahnsinn, wie viele Möglichkeiten sich da ergeben :-D
 
Wenn du ZFS direkt im Proxmox selbst laufen lässt würde ich TrueNAS und virtuelle Festplatten weglassen. Sonst hast du da unnötig einen Virtualisierungs-Layer zwischen. Das geht dann nicht nur auf die Zuverlässigkeit und Leistung sondern raubt dir wegen Padding-Overhead wohl auch noch Speicherplatz.
Da könntest du dann wie beim ganz normalen Debian manuell die Laufwerke partitionieren, formatieren, SMB einrichten und Co. Ist prinzipiell auch nicht verkehrt, aber du solltest schon Ahnung haben was du da tust, da das nicht gerade simpel ist. Gerade bei den Rechten, den SMB-Konfig-Dateien usw kann viel falsch machen, wenn man nicht vorher genau weiß, wie man das haben möchte und welche Parameter dafür zu benutzen sind.
Wenn der Sever daheim steht meist nicht so wild. In einer Firma oder auf einem Server im Web wäre ich da sehr vorsichtig. Wenn man da was unsicher einstellt hat nachher jeder im Internet/Firmen-LAN Zugriff auf sensible Kundendaten oder ähnliches.
 
Last edited:
Wie sieht das ganze aus, wenn ich das ZFS direkt im Proxmox laufen lassen würde? Was hat das bei diesem Setup für Vor- oder Nachteile?

Es ist echt Wahnsinn, wie viele Möglichkeiten sich da ergeben :-D
... Yep, mit jedem neuen Szenario ergeben sich auch neue Möglichkeiten ... :D

Es kommt darauf an, wie Du Dir den Endaufbau vorstellst. Wenn Du den Pool mit Proxmox erstellst, dann hast du zwei möglichen Szenarien:

Szenario 1: Proxmox wird als NAS "missbraucht"

Bei dieser Variante muss man die Freigaben entweder via CLI oder eine GUI wie Webmin installieren um die Shares und Backups zu verwalten, wie fireon schon erwähnt hat. Der Vorteil dieser Variante (wenn sie richtig läuft) ist, dass kein weiteres NAS System benötigt wird. Ich selber habe diese Variante versucht. Allerdings bin ich nicht so glücklich damit geworden (es kann aber auch sein, dass ich mich "saublöd" angestellt habe). Daher habe ich mich am Schluss für Szenario 2 entschieden

Szenario 2: Das NAS System wird vollständig virtualisiert.

In meinem Fall habe ich einen ZFS Pool unter Proxmox erstellt (RAID10, 24TB). Danach habe ich eine TrueNAS VM (ursprünglich FreeNAS) erstellt und ihr einige virtuelle 3TB Disks (ZFS RAID0) angehängt. Möglicherweise wären kleinere Disks besser gewesen, aber ich wollte mein altes NAS irgendwie virtuell abbilden. Der Vorteil eines vollständig virtualisierten NAS Servers ist, dass man diesem nur so viel Speicherplatz wie nötig zuweisen kann. Wird der Platz knapp, dann kann man eine weitere Disk anhängen und gut ist. Bei TrueNAS ist relativ einfach, dies zu bewerkstelligen. Auf diese Weise werden Ressourcen nicht "verschwendet", in den man sie nur einem System zuweist, wenn andere VMs auch einen Teil dieser Ressourcen benötigen würden (z. B. zusätzliche VMs erstellen oder Disks von bestehenden VMs vergrössern). Übrigens, von grösseren Disks würde ich abraten. Wie ich bereits erwähnt habe, kann man beim Einsatz von grossen virtuellen Disks in Probleme reinlaufen, wie z. B. dass Proxmox meldet, es sei kein Platz mehr verfügbar, wenn man die VM in einen anderen Node replizieren will.
 
Szenario 2: Das NAS System wird vollständig virtualisiert.

In meinem Fall habe ich einen ZFS Pool unter Proxmox erstellt (RAID10, 24TB). Danach habe ich eine TrueNAS VM (ursprünglich FreeNAS) erstellt und ihr einige virtuelle 3TB Disks (ZFS RAID0) angehängt. Möglicherweise wären kleinere Disks besser gewesen, aber ich wollte mein altes NAS irgendwie virtuell abbilden. Der Vorteil eines vollständig virtualisierten NAS Servers ist, dass man diesem nur so viel Speicherplatz wie nötig zuweisen kann. Wird der Platz knapp, dann kann man eine weitere Disk anhängen und gut ist. Bei TrueNAS ist relativ einfach, dies zu bewerkstelligen. Auf diese Weise werden Ressourcen nicht "verschwendet", in den man sie nur einem System zuweist, wenn andere VMs auch einen Teil dieser Ressourcen benötigen würden (z. B. zusätzliche VMs erstellen oder Disks von bestehenden VMs vergrössern). Übrigens, von grösseren Disks würde ich abraten. Wie ich bereits erwähnt habe, kann man beim Einsatz von grossen virtuellen Disks in Probleme reinlaufen, wie z. B. dass Proxmox meldet, es sei kein Platz mehr verfügbar, wenn man die VM in einen anderen Node replizieren will.
Von ZFS auf dem Host und ZFS im Gast wird aber eigentlich abgeraten. ZFS ist intern super kompliziert und fordernd und mit 2x ZFS muss dann alles doppelt gemacht werden. Dann hast du auch mindestens den doppelten Overhead, doppelte Paddingverluste, doppelte Write Amplification. Und ZFS will viel RAM, gerade wenn man große Pools wie beim NAS hat. Faustformel ist ja 4GB + 1GB je 1TB HDD-Rohkapazität. Wenn man nach der Faustformel geht wären das bei Inshield 52GB RAM für ZFS. Und wenn man ZFS doppelt betreibt dann wären das schon 104GB RAM.
Vermutlich läuft ZFS auch mit viel weniger RAM flüssig (hatte keine Probleme mit 16GB RAM bei 32TB auf dem Backup-NAS), wollte nur das Problem mal verdeutlichen.
Da würde ich wirklich erst Szenario 1 versuchen wenn du keine HDDs in die VM durchchreichen willst.
 
Last edited:
Von ZFS auf dem Host und ZFS im Gast wird aber eigentlich abgeraten. ZFS ist intern super kompliziert und fordernd und mit 2x ZFS muss dann alles doppelt gemacht werden. Dann hast du auch mindestens den doppelten Overhead, doppelte Paddingverluste, doppelte Write Amplification. Und ZFS will viel RAM, gerade wenn man große Pools wie beim NAS hat. Faustformel ist ja 4GB + 1GB je 1TB HDD-Rohkapazität. Wenn man nach der Faustformel geht wären das bei Inshield 52GB RAM für ZFS. Und wenn man ZFS doppelt betreibt dann wären das schon 104GB RAM.
Vermutlich läuft ZFS auch mit viel weniger RAM flüssig (hatte keine Probleme mit 16GB RAM bei 32TB auf dem Backup-NAS), wollte nur das Problem mal verdeutlichen.
Da würde ich wirklich erst Szenario 1 versuchen wenn du keine HDDs in die VM durchchreichen willst.
... Dass man davon abrät, ZFS sowohl auf dem Host als auch auf dem Gast zu verwenden, war mir nicht bekannt (ich lese auch zum ersten Mal davon). Aber ich habe mein virtuelles NAS mit ZFS seit einem Jahr am Laufen und konnte bis jetzt keine der geschilderten Probleme feststellen, weder beim RAM Verbrauch noch anderswo ... Vielleicht Glück gehabt ... ;)

Dennoch denke ich, dass InShield deinen Einwand ebenfalls berücksichtigen sollte ...
 
Der Overhead steigt halt linear bis exponentiell. Sagen wir mal du willst eine Datei speichern. Dann muss ZFS die Datei erst in kleine Teile zerlegen, für alle diese Teile Prüfsummen in der CPU/RAM erzeugen, dann gehen die Teile in eine Art Baum wo die Verästelungen noch berechnet werden müssen, dann werden alle auf die verschiedenen HDDs verteilt, dann werden die Paritätsdaten berechnet welche auch wieder auf Festplatten verteilt werden müssen. Dann wird nie etwas überschrieben da es ein Copy-On-Write Dateisystem ist, also sammeln sich immer mehr und mehr Daten an auch wenn die Menge der echten Daten garnicht zunimmt. Dann wird wieder viel Aufwand benötigt um festzustellen, was von den alten Daten nicht mehr gebraucht wird und weg kann. Dann wird noch sehr viel CPU-Leistung gebraucht da alle Teile ggf. noch erst komprimiert, verschlüsselt oder dedupliziert werden müssen. Dann verlierst du Kapazität da ZFS sehr viele Matadaten wie Prüfsummen, Parität usw. erzeugen muss. Gerade bei kleineren Volblocksize-Werten passen die Dateiteile dann nicht perfekt zu der LBA der HDDs und wegen schlechtem Padding nehmen dann alle Daten bis zu den doppelten Platz weg. Bei Sync Writes wird dann sogar alles doppelt auf die HDDs geschrieben, da alles erst einmal temporär gespeichert werden muss, dann wird das irgendwann wieder ausgelesen und erneut richtig geschrieben um Fragmentierung zu vermeiden. Dann das ganze Journaling.

Sagen wir mal das alles in Allem sorgt dafür, dass sich da bei ZFS die IOPS verzehnfachen (fiktive Zahl), im Vergleich zu etwas simplem wie FAT32.
Das ist auch der Grund, warum ZFS so viel RAM braucht. Das ist so ein enormer Aufwand mit so vielen IOPS, dass da die HDDs selbst total überfordert wären wenn alles ohne Caching direkt von den HDDs gelesen/geschrieben werden müsste. Daher wird so viel wie möglich im RAM getan um HDD-Operationen weitest gehend zu vermeiden. Und je mehr RAM man ZFS zur Verfügung stellt, desto besser kann es halt cachen.

Nutzt man ZFS auf ZFS dann müssen für jeden dieser bereits verzehnfachten Lese-/Schreiboperationen erneut 10 mal so viele Lese-/Schreiboperationen ausgeführt werden. Da verdoppelt sich dann nicht nur die CPU- und RAM-Auslastung, sondern verzehnfacht sich, da alle Operationen oben erneut für jede der bereits verzehnfachten Lese-/Schreiboperationen durchgeführt werden müssen. Und die Lese-/Schreiboperationen wären am Ende dann sogar verhundertfacht (10 * 10).

Ganz übel wäre das mit ZFS auf ZFS bei SSDs mit Sync Writes. 100-fache IOPS heißt dann auch, dass da die SSD 100 mal so schnell kaputt geht.
Bei HDDs hätte man eher das Problem, dass da die IOPS irgendwann zu hoch sein könnten und die Platten einfach nicht mehr mitkommen. Sequentielles Schreiben können HDDs zwar gut und schnell aber bei vielen kleinen Random Zugriffen wie bei ZFS können die schon bei einigen hundert KB/s in die Knie gehen. Ich hatte da selber mal Proxmox + VMs auf einem ZFS Mirror aus 2 HDDs am laufen und musste den durch SSDs ersetzen, da wegen der Write Amplification die IOPS so hoch wurden, dass da die HDDs im Leerlauf der VMs schon nicht mehr mitgekommen sind.

Also nicht, dass da ZFS auf ZFS nicht funktionieren würde. Es ist nur viel fehleranfälliger und extrem ineffizient.
Wenn möglich sollte man das so simpel wie möglich halten und unnötige Virtualisierungslayer oder Verschachtelungen von Dateisystemen vermeiden.
Ob man da nun SMB usw. mit ZFS direkt auf Proxmox laufen lässt oder ob man eine NAS-VM erstellt und die HDDs in die VM durchreicht ist da ziemlich egal. In beiden Fällen läuft da nur einmal ZFS direkt auf der physischen Hardware ohne unnötige Verschachtelungen oder Virtualisierungen.
Prinzipiell sagt man, man sollte Intelligentes wie ZFS lieber im Gast selbst laufen lassen da dieser besser weiß, wie man es optimal verwendet (Caching und so) aber wenn es nur um Dateifreigaben geht ist das glaube ich egal, da ja in beiden Fällen das gleiche passieren würde.

Man spart sich mit ZFS und Shares auf dem Host selbst halt eine VM, was etwas RAM und CPU-Zeit reduziert, da nicht ein zusätzliches Betriebsystem laufen muss. Dafür würde man sich mit einer NAS-VM das Leben aber wegen besserer GUI vereinfachen und der Fehlerfaktor Mensch wäre etwas aus dem Spiel genommen. Bei einem 48TB ZFS Pool ist das mit ZFS aber so aufwändig und ressourcenraubend, dass da ein schlankes Unix echt nicht mehr ins Gewicht fallen sollte. Wenn du schon 48GB RAM oder so als ARC für ZFS verwendest, dann machen die 500MB für FreeNAS den Kohl auch nicht mehr fett.

Also laufen tut irgendwie alles, ist halt eine Frage wie da jeder für sich seine Prioritäten setzt.
 
Last edited:
Der Overhead steigt halt linear bis exponentiell. Sagen wir mal du willst eine Datei speichern. Dann muss ZFS die Datei erst in kleine Teile zerlegen, für alle diese Teile Prüfsummen in der CPU/RAM erzeugen, dann gehen die Teile in eine Art Baum wo die Verästelungen noch berechnet werden müssen, dann werden alle auf die verschiedenen HDDs verteilt, dann werden die Paritätsdaten berechnet welche auch wieder auf Festplatten verteilt werden müssen. Dann wird nie etwas überschrieben da es ein Copy-On-Write Dateisystem ist, also sammeln sich immer mehr und mehr Daten an auch wenn die Menge der echten Daten garnicht zunimmt. Dann wird wieder viel Aufwand benötigt um festzustellen, was von den alten Daten nicht mehr gebraucht wird und weg kann. Dann wird noch sehr viel CPU-Leistung gebraucht da alle Teile ggf. noch erst komprimiert, verschlüsselt oder dedupliziert werden müssen. Dann verlierst du Kapazität da ZFS sehr viele Matadaten wie Prüfsummen, Parität usw. erzeugen muss. Gerade bei kleineren Volblocksize-Werten passen die Dateiteile dann nicht perfekt zu der LBA der HDDs und wegen schlechtem Padding nehmen dann alle Daten bis zu den doppelten Platz weg. Bei Sync Writes wird dann sogar alles doppelt auf die HDDs geschrieben, da alles erst einmal temporär gespeichert werden muss, dann wird das irgendwann wieder ausgelesen und erneut richtig geschrieben um Fragmentierung zu vermeiden. Dann das ganze Journaling.

Sagen wir mal das alles in Allem sorgt dafür, dass sich da bei ZFS die IOPS verzehnfachen (fiktive Zahl), im Vergleich zu etwas simplem wie FAT32.
Das ist auch der Grund, warum ZFS so viel RAM braucht. Das ist so ein enormer Aufwand mit so vielen IOPS, dass da die HDDs selbst total überfordert wären wenn alles ohne Caching direkt von den HDDs gelesen/geschrieben werden müsste. Daher wird so viel wie möglich im RAM getan um HDD-Operationen weitest gehend zu vermeiden. Und je mehr RAM man ZFS zur Verfügung stellt, desto besser kann es halt cachen.

Nutzt man ZFS auf ZFS dann müssen für jeden dieser bereits verzehnfachten Lese-/Schreiboperationen erneut 10 mal so viele Lese-/Schreiboperationen ausgeführt werden. Da verdoppelt sich dann nicht nur die CPU- und RAM-Auslastung, sondern verzehnfacht sich, da alle Operationen oben erneut für jede der bereits verzehnfachten Lese-/Schreiboperationen durchgeführt werden müssen. Und die Lese-/Schreiboperationen wären am Ende dann sogar verhundertfacht (10 * 10).

Ganz übel wäre das mit ZFS auf ZFS bei SSDs mit Sync Writes. 100-fache IOPS heißt dann auch, dass da die SSD 100 mal so schnell kaputt geht.
Bei HDDs hätte man eher das Problem, dass da die IOPS irgendwann zu hoch sein könnten und die Platten einfach nicht mehr mitkommen. Sequentielles Schreiben können HDDs zwar gut und schnell aber bei vielen kleinen Random Zugriffen wie bei ZFS können die schon bei einigen hundert KB/s in die Knie gehen. Ich hatte da selber mal Proxmox + VMs auf einem ZFS Mirror aus 2 HDDs am laufen und musste den durch SSDs ersetzen, da wegen der Write Amplification die IOPS so hoch wurden, dass da die HDDs im Leerlauf der VMs schon nicht mehr mitgekommen sind.

Also nicht, dass da ZFS auf ZFS nicht funktionieren würde. Es ist nur viel fehleranfälliger und extrem ineffizient.
Wenn möglich sollte man das so simpel wie möglich halten und unnötige Virtualisierungslayer oder Verschachtelungen von Dateisystemen vermeiden.
Ob man da nun SMB usw. mit ZFS direkt auf Proxmox laufen lässt oder ob man eine NAS-VM erstellt und die HDDs in die VM durchreicht ist da ziemlich egal. In beiden Fällen läuft da nur einmal ZFS direkt auf der physischen Hardware ohne unnötige Verschachtelungen oder Virtualisierungen.
Prinzipiell sagt man, man sollte Intelligentes wie ZFS lieber im Gast selbst laufen lassen da dieser besser weiß, wie man es optimal verwendet (Caching und so) aber wenn es nur um Dateifreigaben geht ist das glaube ich egal, da ja in beiden Fällen das gleiche passieren würde.

Man spart sich mit ZFS und Shares auf dem Host selbst halt eine VM, was etwas RAM und CPU-Zeit reduziert, da nicht ein zusätzliches Betriebsystem laufen muss. Dafür würde man sich mit einer NAS-VM das Leben aber wegen besserer GUI vereinfachen und der Fehlerfaktor Mensch wäre etwas aus dem Spiel genommen. Bei einem 48TB ZFS Pool ist das mit ZFS aber so aufwändig und ressourcenraubend, dass da ein schlankes Unix echt nicht mehr ins Gewicht fallen sollte. Wenn du schon 48GB RAM oder so als ARC für ZFS verwendest, dann machen die 500MB für FreeNAS den Kohl auch nicht mehr fett.

Also laufen tut irgendwie alles, ist halt eine Frage wie da jeder für sich seine Prioritäten setzt.
... Jetzt bin ich echt verwirrt ... o_O

Dass der zusätzliche Virtuallisierungs-Layer sich auf Performance des Systems auswirkt ist mir schon klar. Aber wenn die Auswirkung so gross ist, wie Du hier darstellst, dann müsste mein Node richtig "amoklaufen", was nicht der Fall ist. Ich habe zur Sicherheit sowohl CPU/RAM Auslastung als auch den "belegten" Diskplatz geprüft. Bei einer Belegung von ca. 8.5TiB und 9 laufenden VMs konnte ich jedoch keine Anomalien feststellen, weder beim CPU/RAM Verbrauch noch bei der Belegung im Pool. Und das nach einem Jahr.

Ich behaupte nicht, dass Du unrecht hast. Es kann sein, dass ich ein mehr Glück als Verstand mit meinem Setup hatte, oder dass die Auswirkungen sich erst zu einem späteren Zeitpunkt oder unter bestimmten Umständen (mehr als 80% Speicherplatzbelegung) manifestieren. Aber Ich kann zum heutigen Zeitpunkt auch nicht bestätigen, dass die von Dir geschilderten "Symptome" sich jemals bemerkbar gemacht hätten. Wie gesagt, ich bin nun verwirrt. Vielleicht kann jemand von Proxmox "ein bisschen Licht ins Dunkel" bringen ... ;)

Das einzige, was ich fairerweise erwähnen muss, ist die Tatsache, dass es bei I/O-lastige Tasks zu I/O-Delays kommt. Allerdings kann das eher mit der gewählten Hardware (keine SSDs) als mit der Kombination "ZFS im Host und Gast" zu tun. Aber ausschliessen lässt es sich auch nicht. Somit wären wir jedoch wieder beim Thema "Performace". Und wie ich bereits gesagt habe, kann ich nicht behaupten, dass ich bis jetzt massive Performanceprobleme hätte ... :D

Wie Du gesagt hast, geht es auf jeden Fall nicht darum, zu bestimmen, welche Lösung die beste ist, sondern nur darum, die möglichen Szenarien mit ihren Vor- und Nachteilen aufzuzeigen. Die Entscheidung darüber, welche Lösung es schlussendlich sein wird, kann nur InShield treffen ... ;)
 
Last edited:
Ich bin jetzt leider auch etwas verwirrt :D

Mein neuer Ansatz wäre jetzt: Proxmox auf 2 Enterprise SSD´s im ZFS1 Mirror zu installieren. Auf diesem dann von Proxmox erstellten local-lvm-thin würde ich dann alle meine VM´s installieren und ich hätte somit bei Proxmox und meinen VM´s alle Vorteile von ZFS. Ist das bis hier hin korrekt?

Dann würde ich eine TrueNas VM installieren und dort den LSI Controller mit den 12x4 TB Platten durchreichen und dort den eigentlichen ZFS Pool erstellen. Die 2 SSD´s hängen ja an einem anderen Controller (hintere Einschübe) soweit ich das beim R730xd von Dell beurteilen kann. Das sollte bis hier hin also auch korrekt sein, oder?

Die VM´s bekommen dann ihren ZFS Pool quasi über NFS wieder von der TrueNas VM geliefert und könnten dort Daten lesen und schreiben. Genauso wie externe NFS / Samba / iSCSI User.

Habe ich dann auch die von Dunuin beschriebenen Probleme? Leider steige ich da nicht ganz durch, wo genau da das Problem entstehen könnte.
 
Last edited:
Dass der zusätzliche Virtuallisierungs-Layer sich auf Performance des Systems auswirkt ist mir schon klar. Aber wenn die Auswirkung so gross ist, wie Du hier darstellst, dann müsste mein Node richtig "amoklaufen", was nicht der Fall ist. Ich habe zur Sicherheit sowohl CPU/RAM Auslastung als auch den "belegten" Diskplatz geprüft. Bei einer Belegung von ca. 8.5TiB und 9 laufenden VMs konnte ich jedoch keine Anomalien feststellen, weder beim CPU/RAM Verbrauch noch bei der Belegung im Pool. Und das nach einem Jahr.
Das mit dem 10x war wie gesagt eine fiktive Zahl, um das mit dem exponentiell ansteigenden Overhead zu verdeutlichen. Wenn das nur Faktor 2 oder 3 wäre, dann wäre es nur 2*2=4 oder 3*3=9 und nicht 10*10=100. Das wäre dann ja deutlich weniger gravierend in der Praxis. ZFS hat halt schon echt viel Overhead und das wird dann viel schlimmer, wenn man da dann noch ZFS mit ZFS verschachtelt. Was du aber klar merken müsstest ist der RAM verbrauch. Schließlich müsstest du einmal so um die 32GB RAM auf dem Proxmox-Host selbst für den ARC veranschlagt haben und dann noch einmal 32GB RAM im FreeNAS-Gast für den ARC. Ob man da dann 32GB oder 64GB für ZFS verliert finde ich schon ziemlich krass. Und dann macht es alles auch noch langsamer, weil alle Daten erst im einen ARC und dann noch einmal im anderen ARC gespeichert werden müssen. Ggf sogar noch ein drittes mal je nachdem was du da beim virtuellen SCSI controller für einen Cache-Mode gewählt hast. Und Linux/Unix buffert dann ja auch noch alle Dateizugriffe. Dann landet alles sogar 5 mal im Cache. Das sorgt dann ja auch alles wieder für Latenzen und Auslastung des RAMs.

Wenn du bei dir auf beiden ZFSs Deduplication und Verschlüsselung aktivieren, Kompression auf "gzip" und sync auf "always" stellen würdest, dann würde dein Server wohl wirklich nicht mehr laufen sobald ZFS da etwas zu speichern bekommt. Macht natürlich überhaupt kein Sinn da zweimal Kompression, Deduplication und Verschlüsselung zu nutzen. Wenigstens auf einer Seite sollte man das dann deaktivieren.
Alleine das Wechseln von lz4- auf gzip-Kompression bringt meinen Quad-Core-Xeon schon von rund 6% auf 80-90% Auslastung. Das doppelt und es würde gar nichts mehr laufen. Gzip nehme ich gerne für meine Datengrab-Datasets, wo es nicht auf Performance ankommt, da der Kompressionsfaktor doch etwas besser ist.

Mein neuer Ansatz wäre jetzt: Proxmox auf 2 Enterprise SSD´s im ZFS1 Mirror zu installieren. Auf diesem dann von Proxmox erstellten local-lvm-thin würde ich dann alle meine VM´s installieren und ich hätte somit bei Proxmox und meinen VM´s alle Vorteile von ZFS. Ist das bis hier hin korrekt?
Ja, "2 Enterprise SSD´s im ZFS1 Mirror" klingt gut. Aber du hast dann kein lvm-thin mehr sondern zfs.

Dann würde ich eine TrueNas VM installieren und dort den LSI Controller mit den 12x4 TB Platten durchreichen und dort den eigentlichen ZFS Pool erstellen. Die 2 SSD´s hängen ja an einem anderen Controller (hintere Einschübe) soweit ich das beim R730xd von Dell beurteilen kann. Das sollte bis hier hin also auch korrekt sein, oder?

Die VM´s bekommen dann ihren ZFS Pool quasi über NFS wieder von der TrueNas VM geliefert und könnten dort Daten lesen und schreiben. Genauso wie externe NFS / Samba / iSCSI User.

Habe ich dann auch die von Dunuin beschriebenen Probleme? Leider steige ich da nicht ganz durch, wo genau da das Problem entstehen könnte.
Nein, alles gut. Abgesehen davon, dass der Passthrough vom HBA ziemlich kompliziert ist, hört sich alles solide an, falls dein Dell das mitmacht.
Bei dem Setup wäre alles so, als hättest du einen zweiten Server nur für TrueNAS irgendwo rumstehen, wo du dann auf alles per NFS/SMB zugreifst. Nur das dieser zweite Server halt zum Teil virtuell ist. Aber das wichtigste, nämlich die HDDs, sind nicht virtuell sondern direkt per echter Hardware angeschlossen. Da solltest du eigentlich keinen Unterschied merken, ob du das so wie beschrieben virtualisierst oder ob es ein echter zweiter Server nur für TrueNAS wäre. Mal abgesehen von 150€ weniger im Jahr auf der Stromrechnung.

Was ich persönlich dabei auch wichtig finde:
Sollte mal der Server kaputt gehen, dann kannst du auch einfach alle 12 HDDs ausbauen, in einen beliebigen Rechner stecken, TrueNAS dort vom USB-stick booten, Pool importieren und schon hast du wieder ein lauffähiges NAS und kommst an alle deine Daten ran. Wenn du dann auch noch regelmäßig die Config-Datei von TrueNAS per WebGUI runterlädst und sicherst, dann kannst du die sogar auch noch mit ein paar Klicks imporieren und TrueNAS nutzt dann gleich auch noch alle alten Einstellungen bezüglich Netzwerk, Rechte, User, Shares, ...
Da kannst du dann in unter 1 Stunde schon wieder auf alle Daten per LAN zugreifen, sofern da bereits ein passender Reserverechner rumstehen sollte.
 
Last edited:
Vielen Dank für eure Antworten :)

Ja, "2 Enterprise SSD´s im ZFS1 Mirror" klingt gut. Aber du hast dann kein lvm-thin mehr sondern zfs.
Oh stimmt natürlich - dann ist es ja zfs ;-)

Nein, alles gut. Abgesehen davon, dass der Passthrough vom HBA ziemlich kompliziert ist, hört sich alles solide an, falls dein Dell das mitmacht.
Bei dem Setup wäre alles so, als hättest du einen zweiten Server nur für TrueNAS irgendwo rumstehen, wo du dann auf alles per NFS/SMB zugreifst. Nur das dieser zweite Server halt zum Teil virtuell ist. Aber das wichtigste, nämlich die HDDs, sind nicht virtuell sondern direkt per echter Hardware angeschlossen. Da solltest du eigentlich keinen Unterschied merken, ob du das so wie beschrieben virtualisierst oder ob es ein echter zweiter Server nur für TrueNAS wäre. Mal abgesehen von 150€ weniger im Jahr auf der Stromrechnung.
Also mit dem Passthrough hatte ich jetzt eigentlich keinerlei Probleme und im TrueNas werden die weiteren Daten der Festplatten (Seriennummern usw.) komplett erkannt und angezeigt. Bei den Festplatten sieht es für mich so aus, als ob ich die Kiste garnicht virtualisiert hätte.

Was ich persönlich dabei auch wichtig finde:
Sollte mal der Server kaputt gehen, dann kannst du auch einfach alle 12 HDDs ausbauen, in einen beliebigen Rechner stecken, TrueNAS dort vom USB-stick booten, Pool importieren und schon hast du wieder ein lauffähiges NAS und kommst an alle deine Daten ran. Wenn du dann auch noch regelmäßig die Config-Datei von TrueNAS per WebGUI runterlädst und sicherst, dann kannst du die sogar auch noch mit ein paar Klicks imporieren und TrueNAS nutzt dann gleich auch noch alle alten Einstellungen bezüglich Netzwerk, Rechte, User, Shares, ...
Da kannst du dann in unter 1 Stunde schon wieder auf alle Daten per LAN zugreifen, sofern da bereits ein passender Reserverechner rumstehen sollte.
Das finde ich auch sehr wichtig! Ist das dann tatsächlich so einfach? Ein Pool import geht dann so easy? Also es müssen nur alle Platten des Pools intakt sein und es spielt dann auch keine Rolle an welchem Adapter die Platten betrieben werden? Einfach Plattenimport im TrueNas starten und fertig?

Das wäre ja mal richtig klasse und ein weiterer Grund direkt auf ZFS und nicht auf irgendwelchen HW RAID Controller zu setzen ;-)

Ginge der Import bei jedem anderen Betriebssystem das ZFS kann auch "problemlos" zum Importieren? Z.B. direkt unter Proxmox?
 
Das finde ich auch sehr wichtig! Ist das dann tatsächlich so einfach? Ein Pool import geht dann so easy? Also es müssen nur alle Platten des Pools intakt sein und es spielt dann auch keine Rolle an welchem Adapter die Platten betrieben werden? Einfach Plattenimport im TrueNas starten und fertig?

Das wäre ja mal richtig klasse und ein weiterer Grund direkt auf ZFS und nicht auf irgendwelchen HW RAID Controller zu setzen ;-)

Ginge der Import bei jedem anderen Betriebssystem das ZFS kann auch "problemlos" zum Importieren? Z.B. direkt unter Proxmox?
Ja, Import ist wirklich so einfach. Hardware ist völlig egal und auch wo man die HDDs anschließt, solange das nicht an ein (Pseudo-)Hardware-Raid angeschlossen wird. Alles was den Pool angeht ist direkt auf den HDDs gespeichert und der "zfs import PoolName" Befehl geht einfach alle HDDs im PC durch und guckt ob da Daten drauf sind die zum Pool "PoolName" gehören. Falls ja und alle HDDs gefunden wurden, dann wird alles automatisch importiert und läuft dann. Dinge wie Mountpunkte, Optionen wie sich der Pool verhalten soll etc sind auch alle direkt auf den HDDs gespeichert und nicht extern in einer fstab wie sonst bei Linux.

Beachten musst du da nur 2 Dinge:
1.) ZFS ist nicht gleich ZFS. Einmal gibt es das originale ZFS vom Solaris-Unix, was aber komerziell ist und daher nicht bei Linux/FreeBSD verwendet wird. Dann gab es einen Fork von dem Solaris-ZFS, damit das Opensource FreeBSD-Unix auch ZFS nutzen kann. Das ist das ZFS was FreeNAS bis Version 11.3 nutzt. Dann gibt es recht neu noch ein drittes ZFS was man als "ZFS on Linux" kennt. Das ist wieder eine eigenständige neue Interpretation von ZFS und sollte ZFS nun auch auf Linux-Systeme bringen. "ZFS on Linux" ist das ZFS was auf Proxmox läuft und auch auf TrueNAS ab Version 12.0. Und von diesen 3 ZFS-Arten gibt es dann noch verschiedenste Versionsummern die aber alle abwärts- aber nicht aufwärtskompatibel sind. Also das Betriebssystem muss dann schon das richtige ZFS nutzen mit mindestens der Versionsnummer, mit dem die Pools zuletzt benutzt wurden.
2.) Im Gegensatz zu Proxmox nutzt FreeNAS bis Version 11.3 keine native Verschlüsselung, da das ZFS von FreeBSD das bisher nicht konnte. Da werden die Laufwerke dann erst per GELI verschlüsselt (so ähnlich wie LUKS auf Linux) und dann kommt da ZFS auf die vorher verschlüsselten Laufwerke. Wenn man die Verschlüsselung nutzt (ist bei der Pool-Erstellung voreingestellt meinte ich), dann muss man natürlich erst das mit GELI einrichten und die Keys haben, wenn man den Pool woanders einbauen möchte. Wie das bei TrueNAS ab 12.0 weiß ich leider nicht. Ich bleibe da lieber noch mindestens ein Jahr beim stabilen 11.3. Wenn du FreeNAS auf einem anderen Rechner per USB-Stick bootest, dann sollte der Pool-Import aber kein Problem sein. FreeNAS hat zu 99% alle Funktionen über die WebGUI erreichbar. Dazu gehören auch Pool-Import, Pool-Export, sowie Download und Upload von Encryption-Keys.

Da TrueNAS 12.0 und Proxmox beide "ZFS on Linux" nutzen sollte ein Pool eigentlich auf dem einen OS exportierbar und dann auf dem anderen OS importierbar sein. Ist aber nicht garantiert, da verschiedene ZFS Versionennummern nicht aufwärtskompatibel sind. Also hätte Proxmox z.B. Version 0.8.5 und TrueNAS Version 0.8.4, dann sollte es gut klappen den Pool von TrueNAS nach Proxmox umzuziehen aber nicht anders herum.
 
Oh vielen Dank, dass war sehr informativ!

Das natürlich das System wo man den Pool einbinden will, diese ZFS Art und Version (>=) unterstützen muss, versteht sich von selbst.

Das wusste ich auch nicht, dass alle Infos bezüglich ZFS direkt auf den Platten gespeichert sind. Aber gerade wenn man diesen Pool woanders hin transferieren will oder muss, ist das natürlich eine super Sache :)

Ich habe jetzt auf TrueNas gesetzt. Ich hoffe das stellt sich als stable heraus. Da es nur für Home ist, habe ich damit allerdings keine Bauchschmerzen. Wäre dann für einen späteren Pool Import auf z.B. Proxmox natürlich hilfreich, dass Proxmox und TrueNas beide ZFS on Linux nutzen. Dann bin ich dahingehend etwas flexibler.

Auch das es dann an keinerlei speziellen HW Controller gebunden ist, finde ich schon super. Das mag in einem Rechenzentrum keine Rolle spielen, wo die einfach 1:1 die selbe HW beschaffen. @ Home ist das nach ein paar Jahren evtl. nicht mehr ganz so easy.

Mit der Verschlüsselung habe ich mich noch garnicht auseinander gesetzt. Bisher bin ich sowas immer aus dem Weg gegangen, aus Angst um meine Daten im WortCase. Das macht es i.d.R. dann bei einer späteren Zugänglichkeit nicht leichter.

Aber in diesem Fall kann man die einfach bei Pool Erstellung generieren und ich muss mir lediglich den Key downloaden und irgendwo sicher aufbewahren? Beim Import werde ich dann zuerst nach dem Key gefragt und dann sucht er den Pool? Das ist alles?
 
Oh vielen Dank, dass war sehr informativ!

Das natürlich das System wo man den Pool einbinden will, diese ZFS Art und Version (>=) unterstützen muss, versteht sich von selbst.

Das wusste ich auch nicht, dass alle Infos bezüglich ZFS direkt auf den Platten gespeichert sind. Aber gerade wenn man diesen Pool woanders hin transferieren will oder muss, ist das natürlich eine super Sache :)

Ich habe jetzt auf TrueNas gesetzt. Ich hoffe das stellt sich als stable heraus. Da es nur für Home ist, habe ich damit allerdings keine Bauchschmerzen. Wäre dann für einen späteren Pool Import auf z.B. Proxmox natürlich hilfreich, dass Proxmox und TrueNas beide ZFS on Linux nutzen. Dann bin ich dahingehend etwas flexibler.

Auch das es dann an keinerlei speziellen HW Controller gebunden ist, finde ich schon super. Das mag in einem Rechenzentrum keine Rolle spielen, wo die einfach 1:1 die selbe HW beschaffen. @ Home ist das nach ein paar Jahren evtl. nicht mehr ganz so easy.

Mit der Verschlüsselung habe ich mich noch garnicht auseinander gesetzt. Bisher bin ich sowas immer aus dem Weg gegangen, aus Angst um meine Daten im WortCase. Das macht es i.d.R. dann bei einer späteren Zugänglichkeit nicht leichter.

Aber in diesem Fall kann man die einfach bei Pool Erstellung generieren und ich muss mir lediglich den Key downloaden und irgendwo sicher aufbewahren? Beim Import werde ich dann zuerst nach dem Key gefragt und dann sucht er den Pool? Das ist alles?
Ich weiß nicht wie das bei TrueNAS 12.0 ist.
Bei FreeNAS 11.3 läuft das so:
Beim Erstellen des Pool kann man wählen ob der verschlüsselt oder unverschlüsselt sein soll. Passwort muss man da dann erstmal keines angeben. Wenn man verschlüsselt wählt, dann erzeugt FreeNAS da eine Schlüsseldatei, speichert die lokal unverschlüsselt und fordert einen auf diese Schlüsseldatei runterzuladen und sicher zu speichern (Backuppen!). Das hilft dann zwar nicht, wenn jemand den Rechner klaut, da jeder ohne Passwort an die Daten kommt, aber man kann so eine defekte HDD einfach einschicken, ohne vorher alle Daten sichern schreddern zu müssen. Was ja bei großen HDDs durchaus Tage/Wochen dauern kann). Gerade bei SSDs praktisch, da diese sich ja bei zu viel Wearing in den Read-Only-Modus schalten können. Das hatte ich mal mit einer MicroSD, die ich dann nicht reklamieren konnte, da sich nichts mehr löschen ließ, aber man noch alle Dateien öffnen konnte.
Wenn man die verschlüsselt erstellt hat, dann kann man später im Nachhinein z.B. noch...:
1.) eine Backup-Schlüsseldatei erzeugen, damit man einen zweiten Key hat der den Pool im Notfall wieder entschlüsseln kann.
2.) ein zusätzliches Passwort festlegen. Dann wird die Schlüsseldatei zwar immer noch lokal unverschlüsselt gespeichert aber man kann den Pool nur entsprerren, wenn man zusätzlich ein Passwort angibt. Das würde dann auch vor Diebstahl schützen. Nach dem Booten sind die Pools dann gesperrt und man muss im WebUI erst auf "Unlock" klicken und das Passwort eintippen und danach wird man gefragt ob Dienste wie NFS, SMB usw automatisch neu gestartet werden sollen, damit diese auch die Daten aus den Pool nutzen können. Für diese Variante habe ich mich entschieden
3.) ein zusäzliches Passwort festlegen und FreeNAS sagen, dass es keine Schlüsseldateien lokal speichern soll. Funktioniert dann wie bei 2.) nur das man FreeNAS neben dem Passwort auch noch die Schlüsseldatei hochladen muss. Dies wäre prinzipiell am sichersten, aber mein Passwort-Safe kann keine Schlüsseldateien automatisch im Browser ausfüllen und ich mag nicht bei jedem Reboot die Schlüsseldatei aus meinem Passwort-Safe auf den Desktop kopieren, die dann per Browser hochladen und dann die Schlüsseldatei auf dem Desktop wieder richtig schreddern, dass da auf dem Rechner nichts mehr von der vorhanden ist.

Bei Proxmox musst du nicht den ganzen Pool verschlüsseln, sondern es gehen auch einzelne Datasets, da dort nicht GELI sondern die native Verschlüsselungsfunktion von ZFS genutzt wird. Es kann allerdings nicht das Systemlaufwerk verschlüsselt werden, da Linux offiziell kein ZFS unterstützt und ZFS nachträglich in den Kernel reingepatcht werden muss.
Bei der nativen ZFS-Verschlüsselung kannst du wählen ob du eine Schlüsseldatei oder ein Passwort zum verschlüsseln nutzen willst. Die verschlüsselten Datasets werden nicht automatisch eingehängt und müssen per CLI erst aufgeschlossen werden. Dafür kann man z.B. "zfs load-key -a && zfs mount -l -a" eingeben. Dann fragt er dich nach dem Passwort oder dem Ort der Schlüsseldatei für jedes verschlüsselte Dataset und hängt diese anschließend automatisch ein. Datasets können auch im nachhinein noch verschlüsselt werden, aber dabei ist zu beachten, dass bereits bestehende Daten auf dem Dataset unverschlüsselt bleiben und das dann nur für neue Dateien gilt.
 
Last edited:
Ich habe jetzt heute mal testweise einen Z2 Pool mit allen 12 Platten errichtet. Wenn ich darauf Nullen schreiben will mit
Code:
dd if=/dev/zero of=dd.tmp bs=2M count=20000
, dann schafft die Kiste gerade so mal 30MB/s im gesamten Pool! Nicht pro Platte. Der Fehler war auch schnell gefunden; die CPU war mit 20 Kernen überall komplett am Anschlag.

Dann habe ich einen neuen stripped Pool mit 2x 6 Platten jeweils im Z2 erstellt und ich habe eine enorm hohe Schreibrate und die CPU langweilt sich. Damit kann ich 100GB in ca. 44 Sekunden schreiben (ca. 2250MB/s).

Kann mir das einer erklären, warum das so ist??

Und vor allem: Warum ist die CPU load beim stripped Z2 ohne lz4 Compression bei ca. 90% pro Kern und mit lz4 Compression kaum vorhanden??

Für mein Verständnis hätte die CPU mit aktivierter Kompression ja viel mehr zu tun, also mit deaktivierter Kompression??
 
Ich habe jetzt heute mal testweise einen Z2 Pool mit allen 12 Platten errichtet. Wenn ich darauf Nullen schreiben will mit
Code:
dd if=/dev/zero of=dd.tmp bs=2M count=20000
, dann schafft die Kiste gerade so mal 30MB/s im gesamten Pool! Nicht pro Platte. Der Fehler war auch schnell gefunden; die CPU war mit 20 Kernen überall komplett am Anschlag.

Dann habe ich einen neuen stripped Pool mit 2x 6 Platten jeweils im Z2 erstellt und ich habe eine enorm hohe Schreibrate und die CPU langweilt sich. Damit kann ich 100GB in ca. 44 Sekunden schreiben (ca. 2250MB/s).

Kann mir das einer erklären, warum das so ist??

Und vor allem: Warum ist die CPU load beim stripped Z2 ohne lz4 Compression bei ca. 90% pro Kern und mit lz4 Compression kaum vorhanden??

Für mein Verständnis hätte die CPU mit aktivierter Kompression ja viel mehr zu tun, also mit deaktivierter Kompression??
Naja, einmal solltest du beim stripped Pool die doppelte Schreibrate haben. Und dann kann die Kompression schon viel ausmachen. LZ4 ist echt super und beschleunigt das System sogar meistens. Bei LZ4 guckt sich der Algorithmus die ersten paar Prozent einer Datei an. Wenn der dann meint da lässt sich kaum was mit Kompression rausholen, z.B. weil das vermutlich eine bereits komprimierte Datei ist, dann lässt LZ4 das Komprimieren einfach weg und es wird kaum CPU-Power benötigt. Lohnt sich das Komprimieren, dann hat es einen sehr effizienten Algorithmus der zwar nicht so super krass komprimieren kann, aber dafür auch sehr wenig auf die CPU geht. Super ist LZ4 z.B. wenn du eine IMG-/ISO-Datei speichern willst. Oft ist da die Datei z.B. 700MB groß aber echte Daten sind nur 100MB vorhanden und 600MB sind einfach Nullen. Diese Nullen lassen sich beim Komprimieren einfach "wegwerfen" und komprimiert ist die Datei dann nur noch 100MB oder kleiner.
Wenn man die Datei fast ohne Aufwand auf 1/7 der Größe komprimiert bekommt, dann muss ZFS auch entsprechend weniger auf die HDDs schreiben und die Schreibrate versiebenfacht sich im Vergleich zum Pool ohne Kompression der die vollen 700MB auf die HDDs schreiben müsste.

Mit dd if=/dev/zero of=dd.tmp bs=2M count=20000 hast du ja quasi eine perfekt komprimierbare Datei erstellt und wenn sich die 2MB Datei aus Nullen auf wenige KB komprimieren lässt, dann wird ja in der Summe auch fast nichts auf die HDDs geschrieben und die Schreibleistung ist enorm. Würdest du das gleiche mit Zufallszahlen statt Nullen (dd if=/dev/urandom of=dd.tmp bs=2M count=20000) versuchen würde es ganz anders ausgehen.

Da solltest du aber mal der Sache auf den Grund gehen, warum du nur 30MB/s ohne Kompression schaffst bzw. warum ZFS so einen krassen Overhead hat, dass da 20 Cores voll ausgelastet werden. Bei meinem Raidz1 mit 4x 8TB mit lz4 und Verschlüsselung kommen meine 4 Cores bei normalen Dateien meistens nur so auf 8% Auslastung. Irgendwas läuft da also falsch.

Mal die wichtigsten ZFS Optionen bezüglich Leistung:
1.) "sync=standard": erlaubt Sync Writes aber erzwingt/ignoriert diese nicht, so dass da die Software entscheiden kann, ob sie Sync Writes braucht oder Async auch reicht. Sync Writes machen alles extrem lahm und verursachen massig Wearing bei den SSDs, da alles doppelt auch die Laufwerke geschrieben werden muss (wenn keine extra SLOG-SSD vorhanden) und kein RAM-Caching geht. Man könnte da auch "sync=disabled" nehmen, dann würden alle Sync Writes einfach als Async Writes behandelt werden und alles wäre schneller. Ist da aber mal Strom weg oder der Kernel crasht, dann verlierst du auch Daten die eigentlich hätten sicher sein sollen, da das Programm denkt sie wären synchron gespeichert worden, was sie aber nicht sind und so mit dem flüchtigen RAM verloren gingen. Würde ich generell nicht raten zu tun am NAS. "sync=always" hingegen würde alle Async Writes als Sync Writes behandeln und damit die Sicherheit erhöhen aber alles auch extrem ausbremsen.
2.) "compression=lz4": Da würde ich eigentlich immer "lz4" nehmen und nie "off". LZ4 ist so effizient, dass es fast immer den Pool schneller macht. Selbst schneller als unkomprimiert, da der niedrige Kompressionsaufwand weniger bremst als was die geringere Dateigröße dann wieder beschleunigt. Ggf. wäre das neue "zstd" auch eine Option. Ich weiß allerdings nicht ob das inzwischen schon in TrueNAS 12.0 implementiert ist. Das wäre wohl so ein Zwischending aus der Geschwindigkeit von LZ4 und der besseren Kompressionsrate von gzip.
3.) "atime=off" und "relatime=off": Gerade bei SSDs oder wenn eine Datenbank mit vielen kleinen Schreibvorgängen läuft zu empfehlen. Mit der Einstellung müssen bei jedem Dateizugriff nicht erst die Metadaten aktualisiert werden, was sonst bei jeder Leseoperation auch eine Schreiboperation ausführen würde. Wenn man nur "relatime" aktiviert, dann sollte der zwar Zugriffszeiten schreiben, aber maximal 1 mal die Minute oder so.
4.) Dann wäre da noch die Verschlüsselung. Aktiviert sollte es ausbremsen, aber wenn die CPU AES-NI kann (und in den VM-Einstellungen das CPU Flag dafür gesetzt ist) dann geht dies wenigstens kaum auf die CPU und macht sich daher bei HDDs nicht groß bemerkbar. Bei SSDs kann das schon wieder anders aussehen, die schaffen ja ganz andere Geschwindigkeiten. Aber bei AES schaffen CPUs meist schon einige tausend MB/s. Ich glaube FreeNAS 11.3 konnte dir da auch ein Benchmark der Verschlüsselungsalgorithmen machen, um zu testen, was bei dir am schnellsten laufen würde.
5.) Die Deduplikation macht fast nie Sinn, außer man hat spezielle Fälle wie ein eigenes Dataset für eine Datenbank wo immer und immer wieder die gleichen Werte geschrieben werden müssen. Deduplikation braucht massig RAM (Faustformel 5GB pro 1TB Rohkapazität) und viel CPU-Zeit.

Dann gibt es noch 4 Arten wie du mit extra Hardware deinen HDD-Pool schneller machen kannst:
1.) Mehr RAM kaufen damit dein ARC größer sein kann. Je mehr RAM du ZFS gibst, desto mehr kann es cachen und desto besser die Leserate.
2.) Sollte der RAM sich nicht mehr erweitern lassen, dann könnte man dem Pool eine SSD als L2ARC hinzufügen. Damit würde das Cachen dann auch vom RAM auf die L2ARC-SSD ausgeweitet werden. Also ähnlich wie swap.
3.) Hat man viele Sync Writes kann man über eine zusätzliche SLOG-SSD nachdenken. Damit würden alle Sync Writes erst auf die schnelle SLOG-SSD geschrieben werden und später dann auf die HDDs. Ohne SLOG liegt das ZIL auf den HDDs und alles würde erst auf die HDDs geschrieben, dann später von den HDDs gelesen werden, um es dann noch einmal richtig auf die HDDs zu schreiben. Das kann schon sehr die Schreibrate erhöhen, aber halt auch echt nur für Sync Writes. Das meiste was man am NAS hat sollten Async Writes sein und da hilft ein SLOG auch nichts.
4.) Man kann dem Pool eine SSD als Special Device hinzufügen. Dann werden die vielen kleinen Metadaten nicht mehr auf den HDDs gespeichert sondern auf der schnelleren SSD. Das kann dann gesamt die Geschwindigkeit erhöhen.

Aber nicht vergessen auch hier auf Parität zu setzen. Fällt eine SSD aus dann ist der ganze Pool kaputt und alles auf den HDDs ist auch verloren. Da nimmt man dann besser auch gleich 2 oder 3 von. Und SSDs können von ZFS sehr schnell kaputt geschrieben werden, wenn man nicht gerade SSDs mit SLC Flash nimmt.
 
Last edited:

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!