[Kaufberatung] SSD Auswahl für kleines sparsames SSD NAS (ASPM, PLP, usw.)

repairman

Neuling
Thread Starter
Mitglied seit
03.01.2023
Beiträge
4
Moin,
ich bin grade dabei mir ein neues SSD basiertes NAS zusammenzubauen bin mir aber noch nicht sicher mit der Auswahl der SSDs und würde mich freuen wenn jemand Lust hat da mal dürberzugucken und seinen Senf zu abzugeben. Ich habe mal (viel zu langatmig vermutlich) notiert was ich möchte und vorhabe und am Ende folgt ein als TLDR meine eigentliche Frage. Danke schonmal.

Ausgangslage:
Aktuell nutze ich seit einigen Jahren eine Synology Diskstation DS218Play mit zwei alten 2TB die ich rumfliegen hatte im RAID 0 (sic.). Ein NAS mit eigener Cloud, CalDAV, CardDAV und sowas hat sich damit für mich sehr bewährt, aber dieses (quasi Test-) NAS ist mir mittlerweile so zu unsicher, zu laut, zu stromhungrig, zu lahm und nicht zuletzt geht mir die proprietäre Software etwas auf den Keks.

Nutzung:
Das NAS wird erstmal privat von meiner Familie genutzt und für meine Selbstständigkeit als Ingenieur (keine großen Datenmengen, eher Schlaltpäne, CAD Dateien und sowas). Wir machen keine Videobearbeitung oder sowas. Ich plane auch keine großen VMs auf dem NAS laufen zu lassen, vermutlich nur Nextcloud und PiHole. Das NAS soll komplett verschlüsselt sein. Ich brauche realistisch ca. 8TB Speicher damits in Zukunft nicht irgendwann dünn wird. Es soll jedoch auch die Möglichkeit geben das NAS evtl. irgendwann (deutlich) auszurüsten, siehe unten.
Als Betriebsystem plane ich TrueNAS Scale oder Core einzusetzen.

Ausgewählte Komponenten:
Mainboard Fujitsu/Kontron D3644-B
CPU: i3-9100
RAM: 1x 32GB DDR4-2666V-ECC
Netzteil: Corsair RM550x
NIC: Onboard 1GbE
Bootdrive: Samsung 860 Pro SATA 256GB (bestand)
M.2 Risercard: Asus Hyper M.2 X16 Gen 4 (bestand)

Zielsetzungen:
Langlebigkeit:
Zur Einordnung, mein Daily Driver ist ein 2009er Mac Pro (natürlich aufgerüstet, 12 Core, 96GB RAM, bla bla bla…) und das neueste Notebook bei uns im Haus ist ein 2012er MacBook Pro, wir nutzen unsere Geräte gern sehr lange und wollen das auch mit dem NAS tun. Einerseits da es nachhaltiger ist nicht ständig neue Hardware zu produzieren und zu „entsorgen“ aber auch weil ich erstmal meine Ruhe haben will und mich am besten die nächsten Jahre (zumindest für den Eigenbedarf) nicht mehr mit dem Thema NAS beschäftigen möchte. Ich möchte keine Bastel NAS bei dem es wie bei einer Modelleisenbahn mehr um den Spaß am Basteln geht. Deshalb möchte ich erstens hochwertige Komponenten verbauen (das Mainboard ist z.B. made in Germany und für 24/7 Betrieb konzipiert), zweitens eine robuste Datensicherhitsstrategie verfolgen (ECC, Read-only Versionierung, offsite Backup, usw.) und drittens lieber alles etwas überdimensionieren. Wenn mir das langfristig Nerven spart ist es nicht so schlimm, dass das in der Anschaffung teurer ist.

Stromverbrauch:
Das NAS wird den allergrößten Teil seiner Zeit vermutlich im Idel verbringen, da es aktuell nur von zwei Personen genutzt wird und auch nicht für Videoschnitt oder sowas.
Ich habe das Mainboard explizit gewählt, da es im „Die sparsamsten Systeme (<30W Idle)“ Thread eines der im Idle sparsamsten Boards mit ECC Support ist (damit kommen Leute in Richtung 5-7W). Ebenso sieht es beim Netzteil aus. Deshalb habe ich auch einen 32GB RAM Riegel gewählt statt 2x 16GB. Auf Dual Chanel kann ich erstmal verzichten und ein Rigel verbraucht weniger als zwei.
Abgesehen davon das ich aus umweltperspektive Energie sparen will kostet mich mit meinem Ökostrom Tarif aktuell auch jedes Watt Dauerleistung übers Jahr gut 6€, Tendenz steigend.

Lautstärke:
Der Hauptgrund für ein all SSD NAS ist neben dem Stromverbrauch vor allem die Lautstärke. Das NAS steht in meinem Büro, ich dem ich als selbstständiger Ingenieur schon einige Zeit täglich verbringe und das Festplattengeräusch meines aktuellen NAS nervt ziemlich, da ich oft auch keine Musik oder sowas höre beim arbeiten. Deshalb soll das NAS passiv gekühlt und SSD basiert sein.

Aufrüstbarkeit:
Da wir planen mittelfristig ein ein Wohnprojekt zu ziehen fände ich es schön wenn die gekaufte Hardware die Möglichkeit bietet aufrüstbar zu sein um das NAS mit 20-50 Personen statt mit zwei zu nutzen.
Dann kann kann der i3 durch einen Xeon ausgetauscht werden und noch 3x 32GB RAM hinzugefügt werden. Für eine 2x 10GbE Karte gibts genug PCIe Plätze und auch die Lautstärke wäre kein Problem mehr (dann ergeben sich garantiert bessere Standorte außerhalb der Wohnräume) und man kann HDDs hinzufügen und die SSDs als Cache nutzen. Das Netzteil solle dafür auch genug Reserven haben und der Stromverbrauch teilt sich dann ja auf den Nutzen von wesentlich mehr Leute auf.

Raid:
Zuerst hatte ich an eine einzelne 8 / 7,68 TB Enterprise SSD statt ein Raid gedacht, da mir das Raid eh kein Backup ersetzt und Downtime im Falles des Rückspielens nicht das Problem ist. Alle unwiederbringlichen Daten sind über Nextcloud auf je zwei Rechnern und dem NAS stets synchron gehalten, alles andere ist unsere Medienbibliothek, die ich im schlimmsten Fall neu rippen und runterladen kann.
Nun bin ich drauf hingewiesen worden, dass ein RAID aber nicht nur im Fall des kompletten Ausfalls eines Laufwerks hilft, sondern generell die beim Scheiben und Lesen abgleicht um Bit Rot entgegenzuwirken.
Deshalb die Idee drei 4TB SSDs im RAID-Z1 zu verwenden.

SATA/NVMe:
Von der Geschwindigkeit würde mir mittelfristig SATA völlig ausreichen, erstmal ist der Betrieb mit 1GbE LAN geplant, jedoch scheinen NVMe SSDs nicht wirklich mehr zu kosten und für ein Potentielles Upgrade in der Zukunft mit einer 2x 10GbE Karte schade das ja auch nicht und in einigen Jahren sind SATA Enterprise SSDs ggf. auch schwer zu bekommen wenn man mal ersetzen muss/erweitern will.
Das Board bietet die Möglichkeit den x16 PCIe Slot auf x8/x4/x4 aufzuteilen und eine Asus Hyper M.2 Riserkarte (mit dickem Kühlkörper) habe ich noch, die lässt sich dann zwar nur mit drei SSDs nutzen, aber das soll mir ja reichen.

SSD Auswahl:
Zuerst hatte ich die Samsung PM9A3 SSDs im Auge, bis 4TB gibts die in M.2, die sind mit ca. 0,11€/GB auch echt bezahlbar, haben Power Loss Protection, 1DWPD für 5 Jahre (≈ 7.000 TBW), PCIe 4.0 (nicht das ich das mit dem Board nutzen könnte) und mit Samsung SSDs habe ich zumindest auch noch nie eine schlechte Erfahrung gemacht.
Allerdings scheinen diese SSDs kein Sleep zustand zu beherrschen! Laut Thomas Krenn Wikis smartctl Ausgabe unterstützen sie nur einen Power State nämlich P0 (https://www.thomas-krenn.com/de/wiki/Samsung_PM9A3_M.2_NVMe_SSDs). Samsung gibt für den Idle 2,5W und unter Last 8,2W an. Ich vermute Sleep das ist einfach keine Priorität für Datacenter SSDs, da sie eh die allermeiste Zeit aktiv genutzt werden?
Andere SSDs gehen bis zum P4 State runter mit 5mW, das sind bei drei SSDs 7,5W weniger Verbrauch und daraus resultierend knapp 50€ pro Jahr abgesehen davon, dass die SSDs auch kühler laufen bei passiver Kühlung.
Dann gibt es z.B. WD Red SN700 die diesen deep sleep beherrschen, aber keine Power Loss Protection haben, etwas weniger DWPD und auch noch teurer sind. Consumer SSDs wie z.B. Crucial P3 kommen grade mal auf 800 TBW, sowas ist auch keine Option.

Langer Rede kurzer Sinn, die eigentliche Frage:
Ich tue mich schwer eine passende 4TB SSDs zu finden die Features wie Power Loss Protection mit niedrigem Idle Verbrauch verbinden. Habt ihr da gute Vorschläge? Von dem was ich so gelesen habe, habe ich das Gefühl, das Power Loss Protection schon eine gute Sache ist wenn man es richtig machen will, liege ich damit richtig? Ich habe auch gegenteiliges gelesen und fühle mich nicht kompetent genug das für meine Anwendung wirklich zu beurteilen. Wenn ihr andere hilfreiche Anmerkungen zu meiner Idee habt, auch gerne her damit.

Bonusfrage 1:
Offiziell unterstützt das D3644-B Board max. 16GB RAM Riegel. Shops wie Speicher.de bieten aber 32GB Riegel an, mit „100% kompatibel Garantie“ (https://www.speicher.de/arbeitsspeicher-32gb-ddr4-fujitsu-d3644-b-ram-udimm-ecc-sp420331.html) und Leute schreiben auch das sie den i3-9100 mit 32GB riegeln nutzen. Kann das jemand so bestätigen/vermeinen?
Zum testen haben ich auch erstmal 2x4GB DDR4 hier, dann kann ich auch einen Rigel mit den selben Daten (EEC UDIMM, 2Rx8, 2666MHz, 19-19-19-14.25) wie bei Speicher.de kaufen (kostet woanders weniger als die Hälfte) wenns mit dem 32er nichts wir geht er im schlimmsten Fall halt einfach zurück.

Bonusfrage 2:
Geht die CPU im Idle eigentlich auch in Richtung Powerstate C8 runter meint einer SSD die nur P0 und keine Sleepstates unterstützt (wie die PM3A9) oder habe ich dann nicht nur den mehrverbrauch der SSDs sondern auch welchen da die CPU nichr ordentlich schlafen geht?

Ich freue mich auf eure Antworten.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Meine 2 Cent dazu:

Raid:
Zuerst hatte ich an eine einzelne 8 / 7,68 TB Enterprise SSD statt ein Raid gedacht, da mir das Raid eh kein Backup ersetzt und Downtime im Falles des Rückspielens nicht das Problem ist. Alle unwiederbringlichen Daten sind über Nextcloud auf je zwei Rechnern und dem NAS stets synchron gehalten, alles andere ist unsere Medienbibliothek, die ich im schlimmsten Fall neu rippen und runterladen kann.
Nun bin ich drauf hingewiesen worden, dass ein RAID aber nicht nur im Fall des kompletten Ausfalls eines Laufwerks hilft, sondern generell die beim Scheiben und Lesen abgleicht um Bit Rot entgegenzuwirken.
Deshalb die Idee drei 4TB SSDs im RAID-Z1 zu verwenden.

Dieser Hinweis ist richtig, mit nur einem Datenträger kann ZFS zwar Bitfehler erkennen, aber nicht reparieren. Dazu benötigst du mindestens zwei, oder wenn es doch nur einer sein soll müsstest du die Anzahl der gespeicherten Kopien auf 2 (besser 3) in den Pool Eigenschaften setzen.

Langer Rede kurzer Sinn, die eigentliche Frage:
Ich tue mich schwer eine passende 4TB SSDs zu finden die Features wie Power Loss Protection mit niedrigem Idle Verbrauch verbinden. Habt ihr da gute Vorschläge? Von dem was ich so gelesen habe, habe ich das Gefühl, das Power Loss Protection schon eine gute Sache ist wenn man es richtig machen will, liege ich damit richtig? Ich habe auch gegenteiliges gelesen und fühle mich nicht kompetent genug das für meine Anwendung wirklich zu beurteilen. Wenn ihr andere hilfreiche Anmerkungen zu meiner Idee habt, auch gerne her damit.

Du wirst keine Datacenter / Enterprise SSD finden, welche Idle states unterstützt. Da ist in deren Einsatzbereich einfach nicht vorgesehen. Die sind auf niedrige Latenz gebaut. Gilt auch für SATA wie PM/SM883, Micron 5100/5200/5300 und für die PCIE/NVME sowieso. Aber mit SATA kommst du bei gleichen TB natürlich deutlich "Stromgünstiger" als mit dem NVME-Pendant. Ich bin auch zurück zu SATA....
Zusätzlich sind auch professionelle NAS Systeme wie das von dir geplante TrueNAS nicht auf Stromsparen ausgelegt. Du wirst die SSDs mit diesem System eh nicht sauber in Idle bekommen, selbst wenn sie es können. Auch hier gilt: Latenz vor Stomsparen. Es gibt zwar Scripte, mit denen man selbst HDDs "schlafen" legen kann, aber dann führt man einige der integrierten Eigenschaften (wie regelmäßiges SMART Monitoring, Scrubs usw.) ja ad absurdum. TrueNAS ist für den kommerziellen Einsatz geschaffen, wir Homesuser können es kostenlos verwenden (und "zahlen" indirekt als Beta-Tester). Darf man nie vergessen.

Aber: Powerloss-Protection ist bei deinem geplanten Einsatzzweck nicht wirklich benötigt. Dies wird für SSDs benötigt, welche als SLOG für synchrone Schreibzugriffe dienen. SMB/CIFS "Datengrab" schreibt asynchron, da nützt ein PLP bei Stromausfall auch nichts.

Insgesamt neigen wir Homelabber (mich eingeschlossen) dazu, die durch unsere Systeme erzeugte Schreiblast deutlich zu überschätzen. Du wirst mit deinem "Datengrab" niemals auch nur ansatzweise eine Enterprise SSD "kaputt"schreiben, aber auch eine bessere Consumer-SSD hält viiieeeel mehr aus als man gemeinhin denkt. Habe hier im Testsystem zwei Samsung 840 Evo 500GB die haben ihre Schreiblast lt. Datenblatt vor über einem Jahr schon erreicht und haben aber immer noch über 60% "Gesundheit".

Bonusfrage 2:
Geht die CPU im Idle eigentlich auch in Richtung Powerstate C8 runter meint einer SSD die nur P0 und keine Sleepstates unterstützt (wie die PM3A9) oder habe ich dann nicht nur den mehrverbrauch der SSDs sondern auch welchen da die CPU nichr ordentlich schlafen geht?
Mit TrueNAS Core niemals, das zugrunde liegende BSD ist wieder ein Serversystem, nicht auf Stromsparen ausgelegt und darin daher auch echt schlecht. Bei Scale mit seinem Debilian Linux darunter könnte es etwas besser aussehen, aber auch hier wird von den Entwicklern kein Augenmerk auf stromsparen / deep sleep gelegt.
 
Insgesamt neigen wir Homelabber (mich eingeschlossen) dazu, die durch unsere Systeme erzeugte Schreiblast deutlich zu überschätzen. Du wirst mit deinem "Datengrab" niemals auch nur ansatzweise eine Enterprise SSD "kaputt"schreiben, aber auch eine bessere Consumer-SSD hält viiieeeel mehr aus als man gemeinhin denkt. Habe hier im Testsystem zwei Samsung 840 Evo 500GB die haben ihre Schreiblast lt. Datenblatt vor über einem Jahr schon erreicht und haben aber immer noch über 60% "Gesundheit".
Wir haben letztes Jahr nen 336TB Netto SSD Netapp abgerissen. Im HardcoreRZ-Einsatz wurden die in 5Jahren zu 10% oder sowas "kaputtgeschrieben". Also rein rechnerisch würde es 50 Jahre dauern die kaputtzumachen.
Und auf den Dingern wird halt rumgetrommelt wie sonst was.
Von den rund 100 SSD mussten 4 oder sowas im Laufe der Zeit getauscht werden.

Für nen Datengrab reicht daher allemal eine Consumer SSD aus. Ich würde mir da eher Gedanken um Performance (je nach Usecase) und Verfügbarkeit machen. Sprich also, lieber ein RAID Z2/3 mit Consumer SSDs als RAID Z1 oder Mirror. Das kann man ja mal durchrechnen, was das als TCO bedeutet. Auch wenn Consumer SSDs sleep besser könnten, macht in der Regel der Host nen Strich durch die Rechnung. Wenn ich überlege, wie oft mein NAS die Drives hochfährt... (daher nutze ich z.B. auch Zeitsteuerung für Dienstabschaltung, dass dann auch Ruhe ist, z.B. Nachts)
Aus dem Grund ist das im Enterpriseumfeld kein Thema und daher wird da auch nicht optimiert. Ein Grund, warum ESX ne Stromschleuder ist, weil das gesamte System gefühlt immer unter Volldampf fährt.

Weiterhin kann ich auch nur zu standardSATA wegen Stromsparen raten. NVMe Drive haben, auch M.2, Energieaufnahmen jenseits von Gut und Böse, so dass man die mitunter aktiv kühlen muss.
Normale SATA SSDs hingegen sind im IDLE gefühlt genauso warm, wie unter Volllast.

Ich persönlich setze dennoch auf Enterprise SSDs, zumindest für Boot, Arbeitslaufwerke und VM-Drives. Hier nutze ich gerne günstige Gebrauchtangebote bei ebay. Ne gebrauchte Enterprise SSD ist mir da lieber als ne ConsumerSSD mit QLC.
Datastore selber sind bei mir (noch?) keine SSD, sondern drehender Rost.

Ein User hier hat Micron IONs für sein TrueNAS als Datastore in Verwendung.
 
Zuletzt bearbeitet:
Danke für euren Input!!

Insgesamt neigen wir Homelabber (mich eingeschlossen) dazu, die durch unsere Systeme erzeugte Schreiblast deutlich zu überschätzen.
Ja das klingt nach mir^^ Ich bin aber auch beruflich rauere Arbeitsumfelder und höhre anforderungen gewohnt.
Meine schreiblast ist aber vermutlich ziemlich minimal, selbst wenn ich das System 10-20 Jahre nutze. Ich muss mal rausfinden ob die Diskstaion sowas protokoliert, das wäre ja ganz spannend.

Du wirst keine Datacenter / Enterprise SSD finden, welche Idle states unterstützt. Da ist in deren Einsatzbereich einfach nicht vorgesehen.
Aus dem Grund ist das im Enterpriseumfeld kein Thema und daher wird da auch nicht optimiert.
Ja je länger ich suche desto mehr komme ich auch empirisch zu dieser Erkenntniss und ihr bestätigt meine Spekulation.

Powerloss-Protection ist bei deinem geplanten Einsatzzweck nicht wirklich benötigt.
Für nen Datengrab reicht daher allemal eine Consumer SSD aus.
Okay, dann scheint mir SATA doch die sinvollere option zu sein. Wenn man auf PLP verzichtet gibts da ja doch ne ganze Menge.

Mit TrueNAS Core niemals, das zugrunde liegende BSD ist wieder ein Serversystem, nicht auf Stromsparen ausgelegt und darin daher auch echt schlecht
Ja da werde ich mal intensiv testen. Ich hatte mal testweise auf nem 2012 Mac mini fix TrueNAS core installiert und kam auf den selben Stormverbauch im Idle wie mit macOS (gemessen mit Gossen Metrahit Energy) und das ist ja für die Hardware recht gut optimiert ;-) Das hat mich erstmla optimistisch gestimmt. Aber mal sehen wie das denn mit der geplanten Hardware ist. (Der treppenwitz ist das der macOS Kernel am Ende auch von BSD abgeleitet ist :-D) TrueNAS Scale mit dem Linux Kernel gibt einem ja dann vermutlich auch eher die Möglichkeit mal Powertop und sowas auszuführen zum Testen. Und wenn ich PiHole ausführen will geht das eh nur auf Scale, da es bisher keine BSD Implementierung gibt.

Ich bin aber auch offen für andere Systeme als TrueNAS, wenn jemand da einen Vorschlag hat was energiesparender sein könnte.

Auch wenn Consumer SSDs sleep besser könnten, macht in der Regel der Host nen Strich durch die Rechnung. Wenn ich überlege, wie oft mein NAS die Drives hochfährt... (daher nutze ich z.B. auch Zeitsteuerung für Dienstabschaltung, dass dann auch Ruhe ist, z.B. Nachts)
Spannend, meine Diskstation soll aktuell die Platten eigentlich auch nach 10 Minuten Inaktivität schlafen schicken, aber von meinem Gefühl her schlafen sie eher nur wenn Weihnachten und Ostern mal auf einen Tag fallen. War aber bisher zu faul der Sache auf den Grund zu gehen wenn eh ein neues System ansteht.
Dann macht es vermutlich mehr Sinn, nach SATA SSDs zu suchen, die wenig verbauchen sowohl während sie aktiv geschrieben und gelesen werden als auch wenn sie in betrieb aber nicht im Sleep sind?

Es gibt zwar Scripte, mit denen man selbst HDDs "schlafen" legen kann, aber dann führt man einige der integrierten Eigenschaften (wie regelmäßiges SMART Monitoring, Scrubs usw.) ja ad absurdum.
Du würdes also ganz von Drivesleep abraten?
 
Aber: Powerloss-Protection ist bei deinem geplanten Einsatzzweck nicht wirklich benötigt. Dies wird für SSDs benötigt, welche als SLOG für synchrone Schreibzugriffe dienen. SMB/CIFS "Datengrab" schreibt asynchron, da nützt ein PLP bei Stromausfall auch nichts.

Man kann diskutieren wie groß das Risiko ist, aber selbst jenseits von Slog (wo powerloss protection in jedem Fall nötig ist) sehe ich Risiken

1. Es gibt einen Stromausfall beim Schreiben. Da stellt sich die Frage ob bestätigte atomare Schreibvorgänge (z.B. Datenblöcke schreiben und Metadaten aktualisieren) auf SSD sind oder im SSD Cache verloren sind. Es wäre zwar denkbar dass der Commit erst kommt wenn wie bei mechanischen Platten alle Daten tatsächlich auf SSD sind, sehe ich aber eher als unwahrscheinlich an. Nur mit Cache erreichen billige SSDs Performance und wenn ein Hersteller da teuren Aufwand betreibt, kann er gleich PLP garantieren. Da gilt dann gleiches wie beim Urlaub am Meer. Wenn da kein Meerblick beim Buchen angegeben ist, dann ist garantiert keiner dabei. Wenn es nur ein Teil der Daten auf SSD schafft, hat man ein korruptes Dateisystem.

2. Garbage Collection
Das ist ein Hintergrundprozess der SSD Firmware um die Schreibperformance hoch zu halten. Dabei werden Daten verschoben und Zellen gelöscht. Auch da kann ein Stromausfall zu korrupten Daten/ korrupten Dateisystemen führen.

3. Slog
Da werden alle Schreibvorgänge in den rambasierten Schreibcache sofort auf den Pool protokolliert. Bei einem Stromausfall/Crash werden fehlende bestätigte Schreibvorgänge beim nächsten Booten nachgeholt. Ohne PLP ist das sinnfrei und man kann sync gleich auslassen, Schreiben ist dann wenigstens schneller.

Selbst ZFS ist da teilweise machtlos. Wegen der Prüfsummen und mit Redundanz sind die Chancen für eine automatische Reparatur beim Lesen aber besser als ohne ZFS. PLP bei Flash ist daher eine gute Idee.
 
Zuletzt bearbeitet:
Okay, dann scheint mir SATA doch die sinvollere option zu sein. Wenn man auf PLP verzichtet gibts da ja doch ne ganze Menge.
Gibt auch Enterprise SATA SSDs mit PLP. Micron 5100/5200/5300, Samsung PM/SM8x3, Seagate Nytro 1351/1551, Toshiba und noch einige mehr.
Dann macht es vermutlich mehr Sinn, nach SATA SSDs zu suchen, die wenig verbauchen sowohl während sie aktiv geschrieben und gelesen werden als auch wenn sie in betrieb aber nicht im Sleep sind?
Aus meiner Sicht für deine Anforderung und dein Anwendungsprofil: Jepp
Du würdes also ganz von Drivesleep abraten?
Ja, sowohl bei HDD als auch bei SSD. NAS und Enterprise HDD sind für den Dauerbetrieb ausgelegt, die mögen das dauernde Motor an Motor aus Motor an gar nicht. Die Lager kühlen aus, der Verschleiß nimmt überproportional zu. Außerdem ist das System ja auch im iddle mit den Platten beschäftigt (SMART und anderes).
Bei SSD gibt es zwar keine mechanische Mehrbelastung, aber auch da ist die Firmware im Hintergrund immerzu am "machen", Garbage Collection z.B. Bei mir hatte das erzwungene Schlafen der SSDs in TrueNAS immer wieder zu "falschen" Alarmen geführt, eine SSD sei ausgefallen, einfach weil sie nicht fix genug wieder "aufgewacht" ist.

Man kann diskutieren wie groß das Risiko ist, aber selbst jenseits von Slog (wo powerloss protection in jedem Fall nötig ist) sehe ich Risiken

1. Es gibt einen Stromausfall beim Schreiben. Da stellt sich die Frage ob bestätigte atomare Schreibvorgänge (z.B. Datenblöcke schreiben und Metadaten aktualisieren) auf SSD sind oder im SSD Cache verloren sind. Es wäre zwar denkbar dass der Commit erst kommt wenn wie bei mechanischen Platten alle Daten tatsächlich auf SSD sind, sehe ich aber eher als unwahrscheinlich an. Nur mit Cache erreichen billige SSDs Performance und wenn ein Hersteller da teuren Aufwand betreibt, kann er gleich PLP garantieren. Da gilt dann gleiches wie beim Urlaub am Meer. Wenn da kein Meerblick beim Buchen angegeben ist, dann ist garantiert keiner dabei. Wenn es nur ein Teil der Daten auf SSD schafft, hat man ein korruptes Dateisystem.
Im beruflichen Umfeld / wo Geld verdient wird: *bedingungslos unterschreib*. Da ist aber (hoffentlich) die gesamte Kette gegen Powerloss gesichert, die beste PLP im NAS nützt wenig wenn der Verteilerswitch bei Stromausfall weg ist....
Daher ja auch meine Meinung: Im privaten Umfeld bzw. im konkret vom OP geschilderten Anwendungsfall wird PLP bei Stromausfall nicht arg viel nützen, die Daten gehen schon auf dem Weg im Netzwerk "kaputt".
 
Im beruflichen Umfeld / wo Geld verdient wird: *bedingungslos unterschreib*. Da ist aber (hoffentlich) die gesamte Kette gegen Powerloss gesichert, die beste PLP im NAS nützt wenig wenn der Verteilerswitch bei Stromausfall weg ist....
Daher ja auch meine Meinung: Im privaten Umfeld bzw. im konkret vom OP geschilderten Anwendungsfall wird PLP bei Stromausfall nicht arg viel nützen, die Daten gehen schon auf dem Weg im Netzwerk "kaputt".

Das Problem sind nicht Dateien. Wenn bei Schreiben z.B. eines Word Dokuments etwas passiert, ist die Datei immer kaputt. Da hilft auch das beste Dateisystem und viele UPSe nichts. Da helfen nur Backup Dateien die Word selber anlegt oder Snaps des vorherigen Datenstands z.B.. vor 15 Minuten damit nicht viel verloren geht.

Das Problem sind atomare abhängige Schreibvorgänge z.B. Metadaten. Eine komplette Schreib-Aktion bedeutet das Schreiben eines Datenblocks und das anschließende Aktualisieren der Metadaten. Ein anderes Beipiel wäre eine Buchhaltung mit Abbuchung von einem Konto und die verbundene Aufbuchung auf ein anderes oder das Schreiben eines Raid-5 Stripe nacheinander auf 3 Platten. Wird das nicht komplett durchgeführt ist das Dateisystem oder die Datenbank oder das Raid korrupt. ZFS unternimmt mit Copy on Write alles um das zu verhindern. Dann sollte das nicht auf den letzten 2cm Datenweg untergraben werden. Ein konsistentes Dateisystem ist auch das Einzige was sync write oder ein Hardwareraid mit BBU garantieren kann und soll und nicht die Unversehrtheit von Dateien beim Schreiben.

Das gilt bis auf den Sonderfall sehr kleine Datei die bereits komplett im RAM Schreibcache gelandet ist. Da garantiert sync write auch das korrekte Schreiben der Datei. Das ist auch der Grund warum manche auch bei einem SMB Filer sync write aktivieren, trotz Performanceverlusten und das obwohl ZFS da bei einem Crash immer unversehrt bleibt.
 
Zuletzt bearbeitet:
die beste PLP im NAS nützt wenig wenn der Verteilerswitch bei Stromausfall weg ist....
Meinst du hier den PCIe Switch der die Lanes zu den SSDs managed, dass wenn bei der stromlos wird, etweder da das NAS wie in meinem Fall keine USV hat oder wenn das Netzteil hinter der USV stirbt (weils webenfalls wie bei mir nicht redundant ist) und dann wenn das zu einer blöden Zeit passiert die RAID Integrietät dadurch kapput gehen kann trotz PLP auf den SSDs? Oder beziehst du die auf die Ethernet Switches und Daten die auf dem Weg zum NAS daruch verloren gehen?

Letzteres wäre für mich wie du schon sagst bei (Semi-)privater Nutzung absolut verschmerzbar, klar bei einigen Kunden von mir wäre auch das anders wo Downtime richtig Geld kostet, da ist der Kompromiss bezüglich Mehrverbrauch von redundaten Netzteilen, USVs, Link Aggregation, usw. natürlich ein anderer, aber bei mir zuhause.

Das Problem sind nicht Dateien. Wenn bei Schreiben z.B. eines Word Dokuments etwas passiert, ist die Datei immer kaputt. Da hilft auch das beste Dateisystem und viele UPSe nichts. Da helfen nur Backup Dateien die Word selber anlegt oder Snaps des vorherigen Datenstands z.B.. vor 15 Minuten damit nicht viel verloren geht.

Das Problem sind atomare abhängige Schreibvorgänge z.B. Metadaten.

Wovor ich Bammel habe ist dass ich mir ein Risiko einhole, dass z.B. ohne PLP die RAID Integrität gefärdet (wenn ich mal z.B. Sicherung oder FI kille mit meinem Elektronikarbeitsplatz der ja im selben Büro ist) ist und ob das nicht am Ende schlimmer ist als mein ursprünglicher Gedanke mit nur eine SSD ohne RAID (da kann zumindest keine RAID Integrität flöten gehen durch nur halb ausgeführte Schreibvorgänge)?

Gibt auch Enterprise SATA SSDs mit PLP. Micron 5100/5200/5300, Samsung PM/SM8x3, Seagate Nytro 1351/1551, Toshiba und noch einige mehr.
Die und andere werde ich mir dann morgen mal anschauen, ob es da welche gibt, die einen besseren Kompromiss aus PLP und Stromverbauch im Idle (nicht im Sleep) bieten. Denn die Leistung reicht ja immernoch dicke aus für mich auch in Zukunft.

ZFS unternimmt mit Copy on Write alles um das zu verhindern. Dann sollte das nicht auf den letzten 2cm Datenweg untergraben werden
Das ist auch der Grund warum manche auch bei einem SMB Filer sync write aktivieren, trotz Performanceverlusten und das obwohl ZFS da bei einem Crash immer unversehrt bleibt.
Lese ich daraus, dass du sync write UND power loss protection emfehlen würdest?
 
Lese ich daraus, dass du sync write UND power loss protection emfehlen würdest?

100% Sicherheit gibt es nicht und je näher man da dran will desto größer wird der Aufwand und die Kosten. Man sollte vermeidbare große technische Risiken und je nachdem kleinere Risiken vermeiden und grob fahrlässiges Verhalten (kein Disaster Backup, keine Snaps, unzureichendes/kein Raid) unterlassen.

Fehlendes PLP bei einer einzelnen SSD oder Slog ist ein Risiko das man vermeiden sollte. Im Raid ist das Risiko viel geringer da ZFS Fehler vermutlich erkennen und reparieren kann. Wenn man PLP oder ECC ohne allzugroße Kompromisse und Kosten haben kann, sollte man man das aber machen um vermeidbare Restrisiken zu vermeiden.

Sync write ist eine Notwendigkeit bei VM Storage und Datenbanken. Das da nicht zu nutzen ist fahrlässig. Bei einem SMB Filer verbessert es die Datensicherheit nur minimal (für kleine Dateien in einem kurzen Zeitfenster) mit den Kosten deutlich schlechtere Performance - eine Abwägung, sicher kein Muss.
 
100% Sicherheit gibt es nicht und je näher man da dran will desto größer wird der Aufwand und die Kosten. Man sollte vermeidbare große technische Risiken und je nachdem kleinere Risiken vermeiden und grob fahrlässiges Verhalten (kein Disaster Backup, keine Snaps, unzureichendes/kein Raid) unterlassen.
Ja genau das denke ich auch! Ich würde die Risiken die eingehe aus bewusster Abwägung gegen andere Aspekte wie Kosten/Stromverbrauch /Geschwindigkeit und so weiter machen und nicht möglich wenig aus Unwissenheit/Ignoranz.

Im Raid ist das Risiko viel geringer da ZFS Fehler vermutlich erkennen und reparieren kann
Spannend, da hat mich mein Buchgefühl schon getäucht! Ist eben nicht so viel wert wenn man wenig Ahnung von der Materie hat. Ich hatte ja verutet das die Gefahr ohne PLP mit RAID größer sein könnte als ohne
Wovor ich Bammel habe ist dass ich mir ein Risiko einhole, dass z.B. ohne PLP die RAID Integrität gefärdet ist und ob das nicht am Ende schlimmer ist als mein ursprünglicher Gedanke mit nur eine SSD ohne RAID
Aber das schon ja keineswegs der Fall zu sein, sehr gut zu wissen.

Wenn man PLP oder ECC ohne allzugroße Kompromisse und Kosten haben kann, sollte man man das aber machen um vermeidbare Restrisiken zu vermeiden.
Ich habe jetzt mal alle möglichen 3,84TB/4TB SATA SSDs mit und ohne PLP angeschaut bezüglich Stromverbauch, PLP, TBW und Preis wie WD RED SA500, WD Blue, Kingston DC450R, DC500R, DC500M, Micron 5300 Pro, 5300 Max, Samsung PM897, PM893, 870 EVO, Seageate Nytro 1351, 1551, Intel (Solidigm) D3-S4510, D3-S4520.

Da fällt zum ersten (mal wieder) auf, alle SSDs mit PLP verbauchen min 1,2W im Idle, die ohne unter 0,1W.

Zweites, bei den aktuellen Preisen ist unter TLC SSDs die Samsung PM893 für mich der klare Gewinner. Die bekommt man für knapp 400€ brutto, kommt mit PLP, 14.000TBW, 1,4W Idle, 3W Load. Verglichen damit bietet eine der "preiswerteren" Consumer TLC SSDs, die Samsung 870 EVO (alle SSDs mit unter 1.000TBW habe ich ignoriert) außer beim Stromverbauch keine nennenswerten Vorteile und die kosten nicht mal 20€ (!) weniger und biete dafür kein PLP und grade mal 2.800 statt 14.000TBW.
2.800TBW würden für meine Anwendung auch völlig, aber wenn ich für nicht mal 20€ mehr das fünfache haben kann brauche ich nicht groß zu überlegen. Einzig eben der Stromverbrauch bei 3 SSDs von 4W, der mit meinem Tarif aktuell 24€ in Jahr spart. Und im Winter hilt der Mehrverbauch ja sogar noch beim Heizen, stört also nur im Sommer so richtig 😅.

Nimmt man QLC SSDs dazu ist die Samsung 970 QVO ggf. noch interessant. Die gibts für 320€ mit 1.400TBW und 3 statt 5 Jahren Garantie. So richtig wohl ist mir dabei irgendwie trotzdem nicht.

Da würde ich dann vermutlich die 4W in kauf nehmen und dafür PLP, mehr TBW , mehr MTBF und vergleichn mit der QVO auch längere Garantie wählen.

Habe ich noch irgendweine Geheimtipp SSD übersehen? Oder würdet ihr zu QVO greifen?

Sync write ist eine Notwendigkeit bei VM Storage und Datenbanken.
Gut zu wissen, das habe ich ja schonmal nicht vor.

mit den Kosten deutlich schlechtere Performance - eine Abwägung, sicher kein Muss.
Das werde ich denke ich einfach testen wenn die Hardware da ist, ob im Verschüsselten Pool mit dem i3-9100 und eh nur einem 1GbE NIC überhaupt was zu spüren ist davon.

Hat jemand eigentlich eine Ahnung, mit soeiner SSD mit PLP und Mehrverbauch im Idle dazu führt, dass die CPU nicht in einen so niedirgen C Statze wechselt im Vergleich zu so einer Consumer SSD mit unter 0,1W?
 
Ich bin aber auch offen für andere Systeme als TrueNAS, wenn jemand da einen Vorschlag hat was energiesparender sein könnte.
Unraid ist bekannt dafür energiesparend sein zu können. Ist aber wie immer Boardabhängig oder besser HW abhängig.
Einer meiner Datengrabserver Asrock B560m mit Pentium Gold 6500 Prozessor (Corsair RM550x Netzteil) braucht mit einer Cache NVME und 6 HDDs (5xDaten und einmal Parity) gerade mal so 14W und geht in bis Package State C8 (iirc) wenn die Platten im Spindown sind.
Mein anderer Unraid Server, J4105 Board mit 4 SSDs (und PicoPSU) braucht zwischen 5,5 und 6W. //Alle Platten auf beiden Servern sind verschlüsselt btw.

Aber,
das kollidiert etwas mit deiner Anforderung das Teil später mit 50 Leuten nutzen zu wollen. Sobald die Cache SSD voll ist (wenn du Parity nutzen willst, ansonsten ist das irrelevant), brechen deine Schreibraten auf 60-80 MByte pro Sekunde ein. Wobei ich gar nicht sicher bin ob man Unraid Parity bei einem Full SSD System nutzen kann/sollte. Der von mir oben erwähnte J4105 SSD Server nutzt kein Parity, der macht Backups auf einen grossen Server.
Für 2 Leute sollte das aber kein Problem sein wenn die täglich geschriebenen Datenmengen kleiner als die Grösse der Cache SSD sind.

Gras,
Joerg
 
Zuletzt bearbeitet:
Spannend, da hat mich mein Buchgefühl schon getäucht! Ist eben nicht so viel wert wenn man wenig Ahnung von der Materie hat. Ich hatte ja verutet das die Gefahr ohne PLP mit RAID größer sein könnte als ohne

Aber das schon ja keineswegs der Fall zu sein, sehr gut zu wissen.

Der Schlüssel ist ZFS und nicht Raid im Allgemeinen denn bei ZFS werden alle Daten- und Metadatenblöcke z.B. 128k mit Prüfsummen versehen. ZFS kann damit Fehler sicher erkennen und mit Raid Redundanz automatisch beim Lesen reparieren. Ohne Redundanz ist bei ZFS auch nur die betroffene Datei kaputt. Bei einem degraded Raid-5 führt ein Lese-Fehler dagegen zu einem kompletten Verlust des Raid Arrays weil da nicht feststellbar ist was noch gut ist.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh