Unraid oder TrueNAS für 4x 18TB Storage Only

x.treme

Captain
Registriert
Sep. 2008
Beiträge
3.238
Hallo zusammen,

folgendes Szenario:
  • UGreen 6-Bay Server mit Proxmox
  • Es soll eine NAS-VM erstellt werden, welche via PCI-Passthrough den SATA-Controller erhält
  • Virtuelle Maschinen etc. laufen direkt auf Proxmox, die NAS-VM soll wirklich nur ein NAS sein
  • Es sollen 4x 18TB genutzt werden. Keine Vergrößerung dieses Verbunds geplant. Redundanz äquivalent zu RAID5
  • Vollverschlüsselung

Welches OS würdet ihr hierfür empfehlen? Unraid, TrueNAS oder OMV?
Und welches Dateisystem in welcher Konfiguration?

Hinweis: Kein USV vorhanden oder angedacht. Außerdem wären noch 2 NVMe als Cache möglich.
Eine Unraid-Lizenz wäre vorhanden, also Preis ist hier irrelevant.

Danke euch!
 
  • Gefällt mir
Reaktionen: x.treme und herrhannes
TrueNAS mit ZFS. RaidZ1 würde da dann einem Raid5 entsprechen.
Ergänzung ()

madmax2010 schrieb:
Lohnt eigentlich erst, wenn du mindestens 40 Gbit/s Ethernet hast.. Sata ist 6 Gbit/s

Du kannst einfach die Storage Verwaltung in Proxmox nutzen
https://pve.proxmox.com/wiki/Storage

Einen ZFS Pool anlegen, und dann ensprechend so freigeben: https://github.com/bashclub/zamba-lxc-toolbox
(oder eine Dataset durch eine VM schleifen)
Oder so, direkt ist sinnvoller :D Bei ZFS lohnt sich ein SLOG aber schon, wenn man viele synchrone writes hat.
 
  • Gefällt mir
Reaktionen: Asghan
DXP6800 Pro?

Dann würde ich kein ZFS machen, d.h. TrueNAS wäre schonmal weitestgehend raus, da die Hardware kein ECC supportet. Dabei wäre ZFS eigentlich die naheliegende Lösung, das könntest du auch nativ in Proxmox machen, je nach dem was du mit der separaten NAS-VM genau erreichen möchtest. Empfehlen würde ich das ohne ECC-RAM aber nicht.
 
Meh, das ist richtig, für ZFS sollte man schon ECC haben.
 
  • Gefällt mir
Reaktionen: nazgul77 und H3llF15H
madmax2010 schrieb:
Lohnt eigentlich erst, wenn du mindestens 40 Gbit/s Ethernet hast.. Sata ist 6 Gbit/s

Du kannst einfach die Storage Verwaltung in Proxmox nutzen
https://pve.proxmox.com/wiki/Storage
Anbindung ist via 10 Gbit/s an meinen Tower-PC.
Bin von QNAP die GUI für Snapshots etc. gewohnt, daher hatte ich mich gegen ZFS direkt auf Proxmox zunächst gesträubt, aber wäre trotzdem ein Blick wert was mit den Hausmitteln da möglich ist.

Khorneflakes schrieb:
Genau, das DXP6800 Pro. Zwar mit 64GB mehr als genug RAM, aber korrekt: Kein ECC.
 
also wenn ZFS ohne ECC fehleranfällig ist,, dann ist das dateisystem ein no go
 
Ich hab Unraid bei mir mit dem NAS laufen und bin zufrieden :)
 
  • Gefällt mir
Reaktionen: Asghan
Nein, ist es nicht. Aber der Einsatz von ZFS ohne ECC ist trotzdem "highly discouraged" durch die Entwickler und das aus gutem Grund. Funktioniert natürlich, sollte man aber nicht machen.
 
Also soweit ich es bis jetzt verstanden habe:
ZFS hat eine starke Betonung auf Datenintegrität, und hier spielt auch ECC-RAM drauf ein.

Wenn man jedoch ZFS ohne ECC-RAM Nutzt, hat man dadurch keine höhere Wahrscheinlichkeit auf Datenverlust als bei anderen Dateisystemen.

Von daher verstehe ich jetzt die Aussage "Dann würde ich kein ZFS machen" nicht ganz? Heißt das im Umkehrschluss also, andere Dateisysteme sind ohne ECC-RAM sicherer als ZFS. Oder wird das nur so wiederholt, weil das Mantra "ZFS + ECC-RAM gehören zu sammen" sich so in den Köpfen eingeprägt hat?
 
  • Gefällt mir
Reaktionen: .fF
ZFS hat durch die regelmäßigen Scrubs eine höhere Anfälligkeit für Speicherfehler. Aber so richtig kritisch ist das vermutlich da auch nicht.
 
Zuletzt bearbeitet:
x.treme schrieb:
Heißt das im Umkehrschluss also, andere Dateisysteme sind ohne ECC-RAM sicherer als ZFS. Oder wird das nur so wiederholt, weil das Mantra "ZFS + ECC-RAM gehören zu sammen" sich so in den Köpfen eingeprägt hat?
Nein und nein. Tatsächlich ist es eher so, dass man argumentieren kann, dass man für alle Fileserver prinzipiell ECC verwenden sollte.

Das Problem ist lediglich die "Also ICH hatte ohne ECC noch nie Probleme"-Fraktion. Ob das wirklich stimmt, oder ob die Probleme einfach nur nicht erkannt wurden, bleibt dabei meistens unklar. Daher habe ich mir den eben genannten Punkt, dass man eigentlich immer ECC haben sollte, auch erstmal gespart.

Die TrueNAS- und ZFS-orientierten Foren sind voll davon und dem Thema schon seit langem überdrüssig.

Am Ende ist es eine Risikobewertung, die jeder für sich selbst durchführen muss. Wenn man sich bewusst gegen die best practices entscheiden will, dann kann man das natürlich machen. Sehr viele Leute gehen das Risiko mit billigen oder auch weniger billigen Consumer-NAS-Systemen ohne ECC ein.
 
herrhannes schrieb:
ZFS hat durch die regelmäßigen Scrubs eine höhere Anfälligkeit für Speicherfehler.
Die Frage ist: Wenn bei einem Scrub durch einen RAM-Fehler eine Checksummer falsch berechnet wird, und dadurch fälschlicherweise eine Datei als fehlerhaft erkannt wird, könnte sich dadurch eine tatsächliche Datenkorruption ergeben?

Falls nicht, ist ZFS dadurch nicht unsicherer als andere Dateisysteme ohne ECC-RAM ...

Ich stimme euch zwar zu - mit ECC-RAM wäre sicherlich besser. Aber das ist jetzt bei meiner Entscheidungsfindung leider keine Option 😉
 
Khorneflakes schrieb:
Aber der Einsatz von ZFS ohne ECC ist trotzdem "highly discouraged" durch die Entwickler
Hmm, komisch, ich habe genau das Gegenteil von Entwicklerseite im Kopf.

@x.treme

ZFS ohne ECC-RAM ist immer besser als ein anderes Dateisystem ohne ECC-RAM (abgesehen von Btrfs und ReFS, was etwa gleichwertig ist). Also besser ohne ECC, als gar nicht.


herrhannes schrieb:
ZFS hat durch die regelmäßigen Scrubs eine höhere Anfälligkeit für Speicherfehler.

Das macht keinen Sinn. Durch die regelmäßigen Scrubs (sofern man diese durchführt bzw. automatisiert laufen lässt) werden korrumpierte Daten eher gefunden. Ohne ZFS würde man diese idR einfach gar nicht finden. Was soll daran besser sein?

Was passieren kann, ist, dass eine falsche Prüfsumme angelegt wird und folglich korrekte Daten beim Scrub bzw. Lesen als fehlerhaft erkannt werden. Dem Ganzen kann man entgegen wirken, indem man zeitnah nach dem Schreiben einen Scrub macht, und Backup hat man ja eh. Der Fall ist also einerseits eher unwahrscheinlich, und andererseits idR kein Beinbruch.

Der absolute Worst Case wäre sicherlich, dass bei einem Scrub fehlerhafte Daten als korrekt erkannt werden, weil ein Bit der Prüfsumme im RAM kippt. Wie extrem unwahrscheinlich das ist (also dass eine passende Prüfsumme aus einem Bit-Fehler entsteht), sollte in etwa klar sein.

Ansonsten sehe ich keine Nachteile, die sich gegenüber einem Dateisystem ohne Prüfsummenfunktion ergeben. Es ist besser, eine kleine Unsicherheit bei der Fehlererkennung zu haben, als gar keine Fehler erkennen zu können. Somit ist ZFS auch ohne ECC-RAM sehr sinnvoll.


Dazu:

https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

Und siehe hier Matthew Ahrens:

https://web.archive.org/web/2016101...id=de9fc6603b3c90d1ba4d1325e7a3f472#p26303271
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Fusionator und x.treme
Und eben nicht korrumpierte als korrumpiert erkannt. Am Ende ist das aber vermutlich eher ein minimales Risiko.
Ergänzung ()

Generell ist ZFS aber wesentlich RAM-lastiger als andere FS.
 
Zuletzt bearbeitet:
Danke euch - dann wird es denke ich ZFS ;)

Unraid lohnt sich für mich nicht wirklich, da ich weder VM/Docker via Unraid nutzen werde, noch die Flexibilität bzgl. Speicher-Erweiterung benötige. Da spare ich mir die Lizenz für ein anderes Projekt auf.

Dann ist es vor allem die Frage, ob ich TrueNAS in einer VM mit PCIe-Passthrough nutzen werde (was natürlich eine zusätzliche Fehlerquelle ist), oder ich direkt auf Debian/Proxmox es einrichte, und mir vlt. noch irgend eine schöne GUI für Snapshot-Management etc. suche ;)
 
x.treme schrieb:
Falls nicht, ist ZFS dadurch nicht unsicherer als andere Dateisysteme ohne ECC-RAM ...
Vielleicht hilft das bei der Entscheidungsfindung:
There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
https://arstechnica.com/civis/threa...esystem-on-linux.1235679/page-4#post-26303271
https://openzfs.org/wiki/User:Mahrens

Nochmal ein länger Blobpost zu dem Thema:
https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
 
  • Gefällt mir
Reaktionen: Fusionator, Asghan, Khorneflakes und eine weitere Person
Ja den JRS-S Blog-Artikel habe ich mir eben durchgelesen, echt gut, der nimmt viele der ZFS Mythen bzgl Non-EEC-RAM auseinander, das macht die Entscheidung leichter 👍
 
  • Gefällt mir
Reaktionen: .fF
Zurück
Oben