16.02.2018 (Doc Storage)
3.7 von 5, (7 Bewertungen)

HDD-Fehlerraten schlecht in RAID-5-Arrays?

Leserfrage: In diesem Video »Why You Should NOT Use RAID 5 Storage (But Use RAID 6!)« (ab ca. 3:40), wird argumentiert, dass HDDs gewisse Fehlerraten haben, im Schnitt alle 10^14 Bit, das sind rund zwölf TByte. Und wenn das Array mehr als zwölf TByte ausmacht, sei es gut möglich, dass es einen Lesefehler gibt. In diesem Falle würde sich das RAID nicht mehr wiederherstellen lassen, wenn eine Platte ausfällt. Was halten Sie von dieser Aussage?

Antwort Doc Storage:

Wie immer in der EDV, es kommt drauf an: Erstens auf die Platte und ihren Hersteller, zweitens auf das Alter der Medien, drittens auf deren Nutzungs- und Abnutzungsgrad, viertens auf die Umgebungsbedingungen und vieles mehr. Natürlich gibt es diesen theoretischen Wert von zwölf TByte, der bereits seit ich-weiß-nicht-wann in den Medien herumschwirrt. Es kommt auch darauf an, wie wir mit diesem Wert umgehen – bezieht er sich auf einzelne Medien oder auch einen Verbund derselben?

Nehmen wir einmal an, dass er sich auf den Verbund derselben, also eine RAID-Gruppe bezieht. Auch hier gibt es wieder Unterscheidungsmerkmale, wie unter anderem die Platten und Controller. Sollte es in einem RAID 5 zu einem Medienfehler kommen, und sollte dieser nicht schon beim Schreiben aufgefallen und der entsprechende Zylinder ausgeschlossen worden sein (was in den meisten Fällen passiert, so dass Medienfehler überhaupt nicht auffallen), kommt es auf die »Intelligenz« des Controllers an. Moderne Controller und Speichersysteme werden nur den beschädigten Zylinder und die dort gespeicherten Daten nicht mehr lesen können. Dies bedeutet eine beschädigte Datei, vielleicht mehrere, wenn diese klein genug sind, sich den Zylinder zu teilen.

Der Controller wird einen entsprechenden Hinweis geben, und die Aufforderung die Platte zu ersetzen gleich dazu. Und jetzt kommt das berühmte »aber«: Erstens sind alle Platten mit Ersatzzylindern ausgerüstet und verlagern möglicherweise dort gespeicherte Daten frühgenug auf einen »frischen« (also bevor ein Lesefehler passiert). Zweitens warnen alle vernünftigen Controller und Speichersysteme frühzeitig vor einer »ausgelatschten« Platte und verlagern die Daten auf ein mitlaufendes Ersatzmedium. Drittens verwendet niemand, der seine Daten liebt, bei einem zwölf oder mehr TByte großen Array allen Ernstes noch RAID 5.

Wenn das Geld da nicht mehr für RAID 6 reicht, sollte man es gleich lassen. Ach ja - und viertens hat jeder, der seine Daten liebt, jeden Tag oder in kürzeren Abständen ein Backup gezogen. Damit sollten alle Schrecken, die der junge Kollege hier zu verbreiten versucht, vermieden bzw. statistisch ins Reich des annähernd unmöglichen verwiesen sein.

Und um die Frage zu beantworten, was ich von dem Video halte: mathematisch absolut korrekt, in der praktischen DV allerdings (mal wieder) völlig bedeutungslos.

Gruß
Doc Storage

Stellen Sie Ihre Frage
Doc. tec. Storage beantwortet alle Ihre technischen Fragen zu Storage, Backup & Co.

Stellen Sie Ihre Frage an: DocStorage@speicherguide.de
Kommentare (3)
22.02.2018 - bernd.schaub

@LHL, Begriffe wie "ziemlich effektiv" und "dummes Speichersystem" klingen natürlich nicht 100% vertrauenswürdig. Ich denke Sie kennen "An Analysis of Data Corruption in the Storage Stack", weil Sie WAFL erwähnten. Mir ist schon bekannt, dass Objektspeicher in vielen Dingen anders arbeiten. Mir ist bisher kein Objektspeicher bekannt, der Platten als RAW Device anspricht. Letztlich landen die Objekte und Metadaten wieder in einem Dateisystem auf einzelnen Platten, wo über Replikation oder Erasure Coding mehrerer Platten für Schutz gesorgt wird.

22.02.2018 - LHL

Der Artikel vom Cern aus dem Jahr 2007 hat natürlich nicht unrecht. Aber auch dort wurde schon zwischen unterschiedlichen Fehlern differenziert. "Normale" Medienfehler, die zu "File not found" führen, werden heutzutage durch die ganzen vorsorglichen Maßnahmen intelligenter Speichersysteme - wie sie der Doc in seinem Artikel beschrieben hat - ziemlich effektiv abgefangen. Ich selbst habe solche Fehler bestimmt schon seit mindestens 10 Jahren nicht mehr gesehen. Wenn es zu einem "File not found" kommen sollte, dann wird dieser Fehler auch nicht unbemerkt lange Zeit mitgesichert, sondern müsste eigentlich sofort im Backup auffallen.
Etwas anderes sind Verletzungen der Datenintegrität durch "spontane Bitkipper" - rotten Bits. Die kann eine "dummes" Speichersystem nicht erkennen, weil sie zu keinem Lese- oder Schreibfehler führen. Dort braucht man die Intelligenz z.B. eines ZFS- oder WAFL-Filesystems, die mit Hash-Werten die Integrität der Daten überwachen.
Objektspeicher mit RAID6 zu vergleichen macht keinen Sinn - das sind unterschiedliche Ebenen. Objektspeicher sind alternative Arten der Datenverwaltung - alternativ z.B. zu Filesystemen oder Datenbanken. Ähnlich wie bei diesen hängt es von der Intelligenz der Objektspeicherverwaltung ab, ob diese z.B. über regelmäßige Hash-Wert-Prüfung in der Lage sind, die Integrität der Daten zu überprüfen und ggf. auch automatisch zu korrigieren. Eine simple Georedundanz - wie bei vielen Cloudspeichern angeboten - hilft da z.B. nicht unbedingt, weil da solche Fehler einfach georedundant mitrepliziert werden.

16.02.2018 - bernd.schaub

Hat Cern mit der Studie der stillen Datenkorruption nach unrecht?
storagemojo.com/2007/09/19/cerns-data-corruption-research/

Machen Firmen wie Google, Amazon oder Microsoft mit Objektspeichern etwas falsch und sollten bei Petabytes lieber auf RAID6 setzen?

"Die Intelligenz eines Controllers" ... toll, Exklusive Oder und etwas Mathematik. Fehlt hier nicht der 100% Nachweis einer korrekten Übertragung Platte von und nach CPU?

Der Controller meldet einen Fehler und was kommt dann? Backup zurückspielen, wo der Fehler ggf. schon lange Zeit mit gesichert wurde?

Wozu bringt man Dateisysteme und Objektspeicher mit Hashcodes, wenn die Hardware fehlerfrei arbeitet?

Selbst einer der ganz großen Hersteller in dem Bereich gibt zu, dass sie bei der Fehlererkennung in letzter Instanz nur zu ca. 82% erkennen können. Sprich mit 18% der Fehler wird weiter gearbeitet. Finde hierzu leider den Link nicht mehr.


Mehr von Doc. tec. Storage 15.02.2019 Was sagt DWPD über SSDs aus?

Im Zusammenhang mit (Enterprise-)SSDs wird oft die Qualitätsgröße DWPD (Drive Writes Per Day) genutzt. Meist wird die Angabe auch für einen Zeitraum von fünf Jahren spezifiziert. Was sagt DWPD genau aus und mit welcher Standard-Lebensdauer darf man rechnen?


08.02.2019 Unterschiede der Performance-States von SSDs

Gängige Meinung: SSDs sind schnell. In der Praxis gibt es aber dann doch einige Unterschiede, so sind vielen die verschiedenen Performance-States von SSDs und Flash-Speichern nicht bekannt: FOB, steady, burst and transition. Was steckt genau dahinter?


01.02.2019 BSI empfiehlt 200-km-Distanz – 200 km ERNSTHAFT!?

Kurz vor Weihnachten veröffentlichte das BSI neue Kriterien für georedundante RZs. Darin wird der bisher empfohlene Mindestabstand von fünf auf 200 Kilometer hochgesetzt. Aus Praxissicht laut Doc Storage »vollkommener Blödsinn«.


31.01.2019 Nervfaktor digitale Transformation – ein Rant

Die digitale Transformation bzw. Digitalisierung verfolgt uns nun schon geraume Zeit. Mit dem Faktor Mensch kommt nun nochmal ein neues Trendthema hinzu. Doc Storage hat hier eine klare Meinung: »alles Blödsinn – es nervt«. Nichts von dem, was heute diskutiert wird, ist neu und Menschen waren schon immer der Kern eines jeden Geschäftsbetriebs – selbst in der IT.


25.01.2019 SSDs: Was ist mit den Schreibzyklen, wenn SSDs fast voll sind?

Moderne SSDs sorgen mit der Wear-Leveling-Funktion automatisch dafür, dass möglichst gleichmäßig über alle Sektoren geschrieben wird. Wie verhält es sich mit den spezifizierten Schreibzyklen, wenn die SSD nahezu voll ist?


18.01.2019 Wie sinnvoll sind Benchmarks und Performance-Tests?

Welchen Stellenwert haben Benchmarks und Performance-Tests (z.B. SPC-1 und SPC-2) bei der Anschaffung von Storage-Systemen? Man hört ja, dass sich Firmen die Anforderungen nur noch vertraglich garantieren lassen. Ist das wirklich ein gangbarer Weg?

powered by
Boston Server & Storage Solutions Datacore Software
Fujitsu Technology Solutions GmbH Unitrends
N-TEC GmbH FAST LTA AG