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 12.04.2019 Dateisysteme für den PByte-Bereich

Datenberge jenseits des PByte-Bereichs, Cloud-Anbindungen und Analytics-Szenarien stellen Dateiysteme vor neue Herausforderungen. Der Markt bietet einige Optionen wie GPFS, Gluster FS, OneFS oder QF2. Worauf gilt es zu achten?


05.04.2019 Neuordnung des Storage-Tiering

Nachdem sich Flash und SSDs mittlerweile auch in mehrere Leistungsklassen unterteilen, steht die Technik nicht mehr nur für Tier 0. 15k-HDDs scheinen vor dem Aus zu stehen. Gilt dies auch für alle SAS-Platten? Wie sieht die Neuordnung des Storage-Tiering aktuell aus?


15.03.2019 30 Jahre World Wide Web: Was gibt es zu feiern?

Das World Wide Web feiert seinen 30. Geburtstag. Ohne dem Internet ist unser heutiges Leben nicht mehr vorstellbar. Für Doc Storage hat das Netz aber auch genug Schattenseiten. An Regulierungen bzw. an das vom Erfinder erhoffte bessere Internet, glaubt er nicht.


08.03.2019 Datenanordnung im RAID 10 mit 8 Platten

In einem Server wird ein RAID 10 mit acht Festplatten unter Windows 2008 R2 betrieben. Nun ist ein Laufwerk ausgefallen. Da sich nur wenige Daten auf den HDDs befinden, besteht die Möglichkeit, dass die defekte Platte eventuell gar keine Daten enthält?


22.02.2019 Welcher RAID-Level für welche Anwendung?

Gibt es eigentliche eine Faustregel, welches RAID-Level für welche Anwendung am besten geeignet ist? Ich denke da zum Beispiel an Datenbanken mit sehr vielen Zugriffen bei relativ kleinen Datenmengen oder an Webserver und als Extrem auf der anderen Seite Bild-Datenbanken, Audio-Server beim Rundfunk, Video-Archive mit sehr hohen Datenvolumen.


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?

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