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 02.08.2019 Soft-/Hardware: Wie Daten richtig verschlüsseln?

Eine Software-Verschlüsselung soll weniger Probleme verursachen, als eine Hardware-Verschlüsselung. Stimmt das? Was passiert, wenn der gewählte Verschlüsselungsanbieter nicht mehr verfügbar ist, wie kommt man dann an seine Daten?


12.07.2019 Analysten-Prognosen sind verschwendete Lebenszeit

Diesmal nimmt sich Doc Storage die Trendvorhersagen von Marktforschern vor. Seiner Ansicht nach ist vieles nur ein Blick in die Glaskugel, anderes dagegen so offensichtlich, dass es keine weitere Betrachtung benötige. Er hält diese Art von Info für verschwendete Lebenszeit.


28.06.2019 DSGVO bleibt aus DV-Sicht ein unsägliches Thema

Kolumne: Unser Doc Storage ist kein Freund der DSGVO. Dies hat er in mehreren Kolumnen klar formuliert. In seinem zweiten Teil zu »Ein Jahr DSGVO« fasst er nochmal zusammen, warum die Thematik aus seiner DV-Sicht für Firmen unsäglich ist.


14.06.2019 Ein Jahr DSGVO: Aufwand unerträglich hoch

Kolumne: Zur Einführung der DSGVO hat Doc Storage mächtig Dampf abgelassen. Ein Jahr später lässt kaum ein Verband ein gutes Haar an der Datenschutz-Grundverordnung. Der Aufwand für Firmen und IT-Abteilungen sei unerträglich hoch.


07.06.2019 Welchen Flash für welche Anwendung?

Vor rund sechs Jahren schickten sich Flash-Speicher an, sich in Computern und Storage-Systemen zu etablieren. Damals galten die Lösungen aber noch als proprietär. Wo steht die Technik heute und welcher Flash eignet sich für welchen Einsatzzweck?


17.05.2019 NAS-Caching oder Tiering für VMs multiple Zugriffe?

In einer Lehrumgebung werden virtuellen Maschinen auf einem NAS mit 10GbE-Anbindung gespeichert. Nachdem eine Erweiterung mit NVMe-Flash ansteht, stellt sich die Frage, ob eine Caching- oder eine Tiering-Konfiguration die sinnvollere Wahl ist?

powered by
Boston Server & Storage Solutions Itiso GmbH
Fujitsu Technology Solutions GmbH Infortrend
N-TEC GmbH FAST LTA AG
Datacore Software Seagate Technology
Folgen Sie speicherguide.de auch auf unseren Social-Media-Kanälen
Folgen Sie und auf Facebook Folgen Sie und auf YouTube Folgen Sie und auf Twitter