ECC-Ram und ZFS

  • Guckux kaneske


    Du schreibst ZFS "nur" mit ECC-Ram zu betreiben...


    Kannst Du das mal bitte näher ausführen? Mir ist das nicht "schlüssig", Speicherfehler im RAM vorzubeugen ist mir schon klar, aber der Zusammenhang mit Storage ist mir nicht bekannt - außer, daß fehlerhafte Daten aus dem Ram auf dem Storage landen - das ist dann aber ebenfalls für jedes andere filesystem gültig.

    ZFS wiederum selbst hat eine self-healing Funktion, diese funktioniert wiederum nur dann, wenn das Storage redundant aufgebaut ist (Raid1, Raid10, Raid5, Raid50 etc.)


    ZFS selbst zu verwenden hat in meinen Augen nur Vorteile - Nachteile sind, daß es für Performance Speicher braucht, mehr Speicher, nunja, gaaaanz viel Speicher - bei BSD kann man diesen auch "begrenzen/einschränken" über entsprechende kernel-parameter (linux kenn ich mich da nicht aus, würde es aber auch dort unterstellen wollen).

    Hintergrund ist, das ZFS seine Performance aus den zbufs (zfs-buffer) schöpft, so sollte man ein RAID10 nur mit raid1+raid1+raid1+raid1 erstellen und nicht mit raid1(raid0+raid0).

    Dedup sollte man gerade bei Speichermangel deaktivieren, oder eine SSD mit L2ARC cache einsetzen...


    Bei mir läuft jetzt seit >>10Jahren mein home-Server mit ZFS stabil und zuverlässig... auch beruflich (Ninja, die Server haben dort ECC ;) ) sehr gut :)

    Bye

    Stefan


  • Jo, hab ich mit aber auch nur erlesen:


    https://pthree.org/2013/12/10/…y-you-should-use-ecc-ram/


    zum Beispiel...

  • Seufz - hier wird der "generelle" Vorteil von ECC ausgeführt, als schließende chain in der Kette der Fehleranfälligkeiten, vergleichbar mit den SPOFs eines redundanten Systems oder gar eines HA-Clusters.

    Ich sehe in der Ausführung des von Dir genannten links keine "Abhängigkeit" von ECC zu ZFS, ZFS könnte man da auch durch jedes andere filesystem ersetzen und es wäre genauso gültig.

    Nur eben, daß ZFS das self-healing-feature implementiert hat um Fehlern in filesystem-Daten vorzubeugen.


    Die Aussage "ZFS nur mit ECC betreiben" halte ich in diesem Sinne überzogen, sie wäre gültig, wenn man ein HA-Storage aufbauen möchte, dann muss man aber die storage-controller ebenso redundant aufbauen, wie die storage-heads und alle Anbindungen und Verbindungen.


    Also so etwas wie es Oracle mit seinen Exadatas macht, 2 Exadata, 2 ZFS-Appliances, 2 Infini-Band (oder jetzt neu 2x 100Gb-switches), 2 Exastores.

    Alles in sich selbst nochmal redundant (also 2 Netzteile, 2 Storage HBAs, 2 Infini-Band HBAs, 2 Network HBAs etc. etc.).


    Wie geschrieben, die Aussage alleine zu beziehen auf den Zusammenhang ECC<->ZFS ist meiner Ansicht nach "überzogen" und in Bezug auf die Nennung eines spezifischen filesystems mit der Suggestion einer Bedingung, welche für das genannte filesystem sich nachteilig auswirkt. JEDES andere filesysteme hat die gleichen Abhängigkeiten zur fehlerfreien Datenlieferung aus dem Speicher!


    Bei solchen Aussagen sollte die GESAMTE Fehlerkette mit einbezogen werden, angefangen bei Enterprise-Festplatten bis hin zum Enterprise Backup-System.

    Bye

    Stefan


  • Mhm… Also ohne ECC hat man eine Kontrollinstanz weniger, das Risiko von korrupten Daten steigt und ZFS „verteilt“ die Fehler dann weiter. Das gilt aber auch nur, wenn man das in-Memory Management/Feature aktiviert? (1GB RAM pro 1TB)


    Wenn man nun, wie ich, auf neue und günstigere Hardware schielt, hat man entweder die Wahl zwischen 8th/9th gen Intel i3 mit iGPU, AMD Ryzen Pro mit iGPU, oder AMD Ryzen mit dGPU. Oder man spart sich das, nutzt kein ZFS und kann später auch nicht einfach so ein ZFS System aufsetzen. :/

  • so ganz steige ich durch Deinen Kommentar nicht durch :-?


    Ohne ECC und den damit verbunden Speicher-Bit-Fehlern speichert JEDES filesystem die fehlerhaft gelieferten fehlerhaft ab.


    Was meinst Du "in-Memory Management/Feature"?


    Wenn man günstige Hardware (wie Du und ich) einsetzt, kann man jederzeit ZFS einsetzen und kann die Vorteile des ZFS nutzen (einfach zu bedienendes Volumemanagement und coole Features für Sicherheit etc) und hat als eine der vielen möglichen Fehlerquellen wie bei allen anderen filesystemen den "Storagecontroller" (Rechner ohne ECC und seine Komponenten).

    Bye

    Stefan


  • Ja dein Kommentar kam just in dem Moment, als ich meinen geschrieben hatte :D

    Ich hatte mich mal versucht mit ZFS etwas auseinanderzusetzen, aber dank der Modularität ist es ja nicht ganz so einfach.


    Du hast recht, jedes Filesystem hat das Problem, dass es von Fehlerfreien Inhalten im RAM ausgeht. Es kann jederzeit im RAM zu Fehlern kommen und ECC ist nur eine weitere Hilfe diese Fehler rechtzeitig zu merken. Wird dann der Fehler übernommen, wird dieser als Fakt "weiterverbreitet".


    Vielleicht sollte man das Thema von einem anderen Standpunkt aus betrachten: Wie wichtig sind die auf dem NAS gespeicherten Daten und als wie teuer würde man Verlust durch Fehlerhafte Daten empfinden? Wenn man, so wie ich, das NAS als Speicher für die persönlichen Daten verwenden möchte, ist Backup, Redundanz und auch sowas wie ECC, oder weniger Wartungsaufwand die anfänglichen Mehrkosten wert? Mein Problem mit ECC Support ist tatsächlich die nicht mehr ganz so leichten Konfigurationen:


    Ein paar hoffentlich hilfreiche Links bezüglich ZFS :

  • Nett das dass so aufgearbeitet wird.

    Auch ist mir klar, dass ein NAS kein Backup ist.


    Trotzdem verstehe ich das anscheinend falsch, was Das Daten „Kaputtschreiben“ angeht?


    wie dem auch sei, für mich klingt ZFS gerade weil es so Speicher abhängig ist eher kritisch ohne ECC RAM.


    Ich will auch kein Rechenzentrum aufbauen, sondern möglichst schnelle und in sich sichere Daten haben ohne ständig alles in Gefahr sehen zu müssen.


    Geldbeutel mal auch mit einbezogen.


    Daher habe ich auch nun XEON E, ECC RAM und Server Board dankend angenommen und betreibe ein RAID 6 zu dem ich ausreichend Ersatzplatten liegen habe.


    Alles hinter einer USV und regelmäßig auf externen Datenpools gesichert.

  • Danke pebbly für die links - wenngleich sie mir nix Neues erzählen ;) (Ich mache mit ZFS rund 15 Jahre und habe manchen "Bug" miterlebt).


    Yep kaneske DEN direkten Zusammenhang von ZFS und ECC gibt es nicht ;) Wenn Dir günstig/kstl. ein ECC-basierender Server ins Haus gewandert ist, ist das schön, ich hätte hier auch zB ne Oracle/Sun 4150 und sogar 4170 haben können, war mir aber zu laut :D


    Wie Du schreibst, es ist auch ne Geldbeutel-Sache - und mein Serverchen "höre" ich nicht, und es braucht relativ wenig Strom... Man kann sogar bei ECC-Server den "Ram spiegeln" - aber alles darf in Relation gesetzt werden. Je mehr Aufwand ich betreibe, desto arbeitsintensiver ist das Teil, im Fehlerfall ebenso wie bei nem System-update.

    Ersatzfestplatten ist schön (mir schon passiert, daß im Raid5 eine hops gegangen ist und ih nicht zeitnah die Platte ersetzte, im Endresultat hat eine 2te nen Schlag gekriegt und mir sind "unwichtige" Daten erstmal hops gegangen :D ). Unter dem Strich - yep, daß beste NAS-Konzept bringt nichts, wenn man kein vernünftiges Backup hat - in meinem Falle versionsorientiertes Bänderbackup auf LTO-tapes (Datensicherheit für 10Jahre+). DA finden sich dann die wichtigen Daten.


    Zum ZFS und Speicherhungrigkeit, daß ist bei anderen System nicht viel anders, alles lebt vom Speicher, ZFS gilt halt als "gierig" :D (bei meinen 32GB idR die Hälfte bis 2/3 vom ZFS belegt).


    Wenn ich meinen privaten Server unter FreeBSD/ZFS vergleiche mit den beruflich betreuten (Solaris11/ZFS) dann sind letztere meinem Empfinden nach agiler und schneller, aber das sind auch eher Boliden - Enterprise halt...


    In meiner Vorgängerfirma hatten wir EMC-Storage mit NLSAS (Bear-Line SAS Platten, im Prinzip zertifizierte SATA-Disks) 4x 4TB in R5 Gruppen, da haben wir hochgerechnet, wenn die "voll" sind, wird bei einem Recovering (Austausch einer Festplatte) im Prinzip schon die Festplattenerrorquote erreicht (MTBF). Enterprise-Platten wiederum haben meist ne 10er Potenz (oder mehr) beim MTBF als Desktop-Platten - und trotz dessen hat sich google entschieden, in seiner Infrastruktur Desktop-HDs einzusetzen...

    Bye

    Stefan


  • ECC - ja, nein, ein muss, ein soll oder unnötig?


    Letzlich ist es die Entscheidung für jeden Einzelnen... die c't hat das Thema ECC mal beleuchtet (Bezahlartikel?)


    Für mich wesentliche Zitate:

    "Ein erheblicher Teil der Bitfehler sind also eher „Hard Errors“ mit Ursachen wie fehlerhafte DRAM-Chips, Kontaktprobleme bei Speichermodul- oder CPU-Steckfassungen und instabilen Mainboard-Spannungswandlern. Solche Fehler enttarnt wiederum nur die Analyse des ECC-Logs."

    Zudem entstehen wohl die meisten Bitfehler bei minderwertigen Speichermodulen, 80% sind Einzebitfehler -> 20% können nicht korrigiert werden...

    Auch bei neuen Fertigungsverfahren (Herstellung der Speicherchips) scheint ein höheres Qualitätsrisiko zu existieren und ein klassisches Resumeé wird gezogen: keep it simple, also je weniger Komponenten, je einfacher die Konfiguration, desto höher ist die Zuverlässigkeit.

    Bye

    Stefan