-
Halte ich aber auch für problematisch..
Autor: Heribert 18.01.24 - 09:28
Schon jetzt, mit 20TB Platten in nem Raid-Verbund, wird ein Rebuild bei nem Ausfall zum Problem. Selbst sehr moderne Festplatten übertragen maximal mit 250Mb/s und schon bei einer 20TB Platte dauert es enorm lange, eine defekte in nem Raid zu ersetzen. Die Wahrscheinlichkeit, dass währenddessen eine weitere Platte ausfällt, ist den meisten Anwendern schon zu hoch. Bei 30 oder gar 50TB pro Festplatte dürfte das komplett unwirtschaftlich sein.
-
Re: Halte ich aber auch für problematisch..
Autor: _BJ_ 18.01.24 - 09:59
> Jetzt ist die Technik reif für große Rechenzentren und Cloud-Provider.
-
Re: Halte ich aber auch für problematisch..
Autor: Heribert 18.01.24 - 10:03
_BJ_ schrieb:
--------------------------------------------------------------------------------
> > Jetzt ist die Technik reif für große Rechenzentren und Cloud-Provider.
Die haben das gleiche Problem. Die Technik ist bloß zuerst dafür reif, weil sie für Privatanwender viel zu teuer sein wird. Außerdem kommt es bei Privatanwendern nicht so sehr auf die Packungsdichte (sprich TB Pro Höheneinheit im Rack) an. Da fährst du besser mit zwei 16TB Platten statt einer 30er. -
Re: Halte ich aber auch für problematisch..
Autor: _BJ_ 18.01.24 - 10:32
Rechenzentren interessieren sich zu aller erst für Speicherdichte und Energieverbrauch und dabei sind diese neuen Platten unschlagbar. Die Rebuild Zeit ist für Rechenzentren nicht so bedeutend da hier die Redundanzen anders ausgelegt sind das der unwahrscheinliche Fall eines 2. Ausfalls in Folge kompensiert werden kann.
Für Privatanwender gebe ich dir recht hier sollte man mindestens auf eine 2 Platten redundanz wechseln wenn man sich über diesen Fall sorgen macht.
1 mal bearbeitet, zuletzt am 18.01.24 10:32 durch _BJ_. -
wieso?
Autor: jo-1 18.01.24 - 10:44
Heribert schrieb:
--------------------------------------------------------------------------------
> Schon jetzt, mit 20TB Platten in nem Raid-Verbund, wird ein Rebuild bei nem
> Ausfall zum Problem. Selbst sehr moderne Festplatten übertragen maximal mit
> 250Mb/s und schon bei einer 20TB Platte dauert es enorm lange, eine defekte
> in nem Raid zu ersetzen. Die Wahrscheinlichkeit, dass währenddessen eine
> weitere Platte ausfällt, ist den meisten Anwendern schon zu hoch. Bei 30
> oder gar 50TB pro Festplatte dürfte das komplett unwirtschaftlich sein.
seit Jahren verwende ich nur Raid 6 genau aus diesem Grund - fällt eine Platte aus ( bin 10 Jahren ein mal passiert ) ist man mit Raid bis zu einer weitern Platte abgesichert für die Produktivdaten.
Selbstverständlich ersetzt ein Raid 6 trotzdem kein Backup.
Also für den extrem unwahrscheinlichen Fall, dass zu einem Ausfall einer Platte eine zweite und dritte ausfallen ist ein backup immer noch der Rettungsranker. Und auch dieser hat idealer Weise Raid 6 - also nochmals doppelte Redundanz.
Also es müssten insgesamt 6 Festplatten im selben Zeitraum ausfallen. Das ist sehr unwahrscheinlich und bei so wichtigen Daten würde ich immer ein zweites Backup vorhalten.
Dafür kann man locker alte Platten regelmässig als letzte Festung gegen Datenverlust nutzen. -
Re: Halte ich aber auch für problematisch..
Autor: Heribert 18.01.24 - 11:01
_BJ_ schrieb:
--------------------------------------------------------------------------------
> Rechenzentren interessieren sich zu aller erst für Speicherdichte und
> Energieverbrauch und dabei sind diese neuen Platten unschlagbar. Die
> Rebuild Zeit ist für Rechenzentren nicht so bedeutend da hier die
> Redundanzen anders ausgelegt sind das der unwahrscheinliche Fall eines 2.
> Ausfalls in Folge kompensiert werden kann.
>
> Für Privatanwender gebe ich dir recht hier sollte man mindestens auf eine 2
> Platten redundanz wechseln wenn man sich über diesen Fall sorgen macht.
Naja die interessieren sich auch für den Preis. Denn auf Speicherdichte und Energieverbrauch bezogen wären die Dinger sonst alle bis unters Dach voll mit sowas wie der Nimbusdata 3,5Zoll 100TB SSD. Die kostet allerdings auch Knappe 40.000 Euro -
Re: Halte ich aber auch für problematisch..
Autor: kieleich 18.01.24 - 18:33
Wenn ein Rebuild schief geht dann meistens weil eine weitere Platte bereits defekt war.
Bei unerkannten Defekten geht der Rebuild schief egal ob er 1 Minute oder 1 Woche dauert.
Festplatten haben ja selber eine Verzögerungstaktik und reallokieren erstmal intern selbst. Da weiss die Platte schon das sie ein Problem hat aber das RAID weis es nicht oder Die Platte Weiss es selbst nicht weil Defekte nun mal auch dort auftreten können wo ewig nicht mehr gelesen wurde. und erst im Rebuild treten die Fehler zutage.
Das kritische Zeitfenster sind die 2-3 Monate oder länger vorher die der Defekt schon vorhanden war aber schlicht weg nicht aufgefallen ist.
Regelmässige Oberflächen Tests sind notwendig. Nur dauern die auch ewig. SMART Selbsttests und mdadm RAID Checks unterstützen etappenweise tests, jeden Tag ein Stück vom Kuchen testen und gut -
Re: Halte ich aber auch für problematisch..
Autor: Heribert 18.01.24 - 19:32
kieleich schrieb:
--------------------------------------------------------------------------------
> Wenn ein Rebuild schief geht dann meistens weil eine weitere Platte bereits
> defekt war.
>
> Bei unerkannten Defekten geht der Rebuild schief egal ob er 1 Minute oder 1
> Woche dauert.
>
> Festplatten haben ja selber eine Verzögerungstaktik und reallokieren
> erstmal intern selbst. Da weiss die Platte schon das sie ein Problem hat
> aber das RAID weis es nicht oder Die Platte Weiss es selbst nicht weil
> Defekte nun mal auch dort auftreten können wo ewig nicht mehr gelesen
> wurde. und erst im Rebuild treten die Fehler zutage.
>
> Das kritische Zeitfenster sind die 2-3 Monate oder länger vorher die der
> Defekt schon vorhanden war aber schlicht weg nicht aufgefallen ist.
>
> Regelmässige Oberflächen Tests sind notwendig. Nur dauern die auch ewig.
> SMART Selbsttests und mdadm RAID Checks unterstützen etappenweise tests,
> jeden Tag ein Stück vom Kuchen testen und gut
Ja.. ich vermeide es auch Platte aus der selben Charge, bzw alle beim selben Händler zu kaufen, weil ich Serienfehler vermeiden möchte, die mir den ganzen Verbund auf einmal zerschießen würden. Selbst wenn backups vorhanden sind macht es nicht unbedingt Spaß, die zwei Wochen lang aus dem Internet wieder herunter zu laden. -
Re: Halte ich aber auch für problematisch..
Autor: oceansize 18.01.24 - 21:49
Ich arbeite mit ZFS, welches mit sogenanntem Scrub regelmäßig die komplette Platte/Pool scannt und die Checksumme abgleicht, bei genug Redundanz kann es die Daten wieder richten. Das zeigt auch an, ob es Fehler korrigieren musste. Hier zeigt sich auch, ob es eine Platte ggfs. nicht mehr so lange mache. Hatte ich schon mal, man konnte den Ausfall quasi kommen sehen.
Der Prozess dauert leider bei meinen 18TB-Platten auch jetzt schon extrem lang, macht die Platten heiß und macht auch ordentlichen Lärm. Die Lebensdauer wird es wohl auch nicht verbessern. Immerhin kann man sicher sein, dass die Daten konsistent bleiben und nicht durch Silent-Bit-Rot kaputt gehen. ZFS benötigt halt etwas mehr Speicherplatz für die Checksummen.
Trotzdem ist die Situation keine Gute. Für Rechenzentren wird das alles weniger ein Problem sein, wie schon einige geschrieben haben. Für privat wird es aber mit zunehmender Größe bei gleicher Lese-/Schreibrate immer schwieriger.
Wird Zeit für Tesa-Bänder ;-)
...
1 mal bearbeitet, zuletzt am 18.01.24 21:51 durch oceansize. -
Re: Halte ich aber auch für problematisch..
Autor: kieleich 19.01.24 - 09:22
oceansize schrieb:
--------------------------------------------------------------------------------
> Der Prozess dauert leider bei meinen 18TB-Platten auch jetzt schon extrem
> lang, macht die Platten heiß und macht auch ordentlichen Lärm.
ZFS wird als Dateisystem, viel mehr Seeks brauchen. Da ist ja jede Datei für sich selber gespiegelt und das auf verschiedenene Offsets auf verschiedenen Platten. Da muss der Lesekopf hüpfen.
Im RAID Check wird einfach linear durch gearbeitet - für die Platten weniger stressig. Hat eben alles Vor und Nach Teile.
Das RAID bietet von sich aus nur Paritätsprüfung. Keine Checksum aber eine schlechte Platte kann trotzdem auffallen. Checksums sind inzwischen auch per dm-integrity möglich aber nimmt keine Rücksicht auf RAID Besonderheiten (Write Hole udgl)
Das schöne an ZFS ist eigentlich das man sich um nichts mehr selbst kümmern muss. Kommt der "mach dir keinen Kopf es funktioniert einfach" Lösung insgesamt am nächsten. Aber wenn irgendwas schief geht kannst du da auch nichts mehr machen weil es undurchschaubar ist
Der Trend geht jedenfalls zu komplexen Multi Device Dateisystemen. bcachefs könnte ja auch noch interessant werden.



