Users Guide

RAID-Funktion für defekte Datenblöcke
Die RAID-Funktion für defekte Datenblöcke ist eine Funktion des Dell PowerEdge RAID Controllers (PERC) und ermöglicht es dem
Controller, eine Redundanz des Arrays trotz Datenverlust durch einen zweifachen Fehler wiederherzustellen. Eine andere Bezeichnung für
die RAID-Funktion für defekte Datenblöcke ist Neuerstellung mit Fehlern. Wenn der RAID-Controller einen zweifachen Fehler und
unzureichende Redundanz für die Wiederherstellung der Daten im betroffenen Block feststellt, erstellt der Controller eine „Punktionsstelle“
in diesem Datenblock und ermöglicht die Fortsetzung der Neuerstellung.
● Bei jeder Bedingung, die dazu führt, dass kein Zugriff auf Daten in dem gleichen Datenblock auf mehr als einem Laufwerk möglich ist,
handelt es sich um einen zweifachen Fehler.
● Zweifache Fehler führen zum Verlust aller Daten in dem betroffenen Datenblock.
● Alle RAID-Punktionsstellen sind zweifache Fehler, nicht alle zweifachen Fehler sind jedoch RAID-Punktionsstellen.
Ursachen für RAID-Löcher
Ohne die Funktion „RAID Puncture“ (RAID-Loch) würden Array-Rebuilds fehlschlagen und das Array würde heruntergestuft. In manchen
Fällen könnte ein solches Fehlschlagen dazu führen, dass weitere Laufwerke ausfallen und das Array funktionsunfähig wird (Status
„Offline“). RAID-Löcher auf Arrays haben keine Auswirkungen auf den Array-Start. Auch der Zugriff auf die auf dem Array gespeicherten
Daten ist weiterhin möglich.
RAID-Löcher können in zwei Situationen gesetzt werden:
● Es wurde ein doppelter Ausfall erkannt (d. h., es sind bereits Daten verloren gegangen).
Ein Datenfehler auf einem online geschalteten Laufwerk wird auf ein Laufwerk kopiert, auf dem gerade ein Rebuild durchgeführt wird.
● Es wurde kein doppelter Ausfall erkannt (d. h., es kommt erst beim zweiten Fehler zu Datenverlust).
Wenn auf einem online geschalteten Laufwerk im Status „Degraded“ (Heruntergestuft) ein fehlerhafter Block erkannt wird, wird an
der betreffenden LBA ein RAID-Loch gesetzt.
Der Vorteil eines Array-Lochs besteht darin, dass das System für die Produktion verfügbar bleibt, bis die Redundanz des Arrays
wiederhergestellt werden kann. Die Daten im betroffenen Stripe gehen immer verloren, gleich ob ein RAID-Loch gesetzt wird oder nicht.
Der Hauptnachteil dieser Methode: Solange auf einem Array ein RAID-Loch gesetzt ist, werden weiterhin nicht korrigierbare Fehler
auftreten, wann immer auf gegebenenfalls vorhandene betroffene Daten zugegriffen wird.
RAID-Löcher können an den folgenden drei Stellen auftreten:
● In leerem Speicherplatz, der keine Daten enthält. Auf den betreffenden Stripe kann dann zwar nicht mehr zugegriffen werden, dies hat
aber keine größeren Auswirkungen, da an dieser Speicheradresse keine Daten abgelegt sind. Alle Versuche des Betriebssystems, in
einen Stripe mit RAID-Loch zu schreiben, schlagen fehl und die Daten werden an eine andere Speicheradresse geschrieben.
● In Stripes, die unkritische Daten wie Dateien des Typs „README.TXT“ enthalten. Solange auf die betroffenen Daten nicht zugegriffen
wird, werden während normaler E/A-Vorgänge keine Fehler erzeugt. Bei Versuchen, ein Dateisystembackup durchzuführen, werden
alle von einem RAID-Loch betroffenen Dateien nicht gesichert. Werden Konsistenzprüfungen oder Patrol Reads durchgeführt, wird für
die betreffende LBA und/oder die betreffenden Stripes der Sense-Code „3/11/00“ erzeugt.
● In Datenbereichen, auf die zugegriffen wird. In einem solchen Fall kann der Datenverlust zu einer ganzen Reihe von Fehlern führen.
Dabei kann es sich um geringfügige Fehler handeln, die keine negativen Auswirkungen auf die Produktionsumgebung haben. Die Fehler
können aber auch schwerwiegender sein und dazu führen, dass das System kein Betriebssystem starten kann oder dass Anwendungen
fehlschlagen.
Ein Array mit RAID-Loch muss irgendwann gelöscht und neu erstellt werden, um das RAID-Loch zu beseitigen. Bei diesem Vorgang
werden alle Daten gelöscht. Die Daten müssen dann neu erstellt oder aus einem Backup wiederhergestellt werden, sobald das RAID-Loch
behoben wurde. Die Behebung eines RAID-Lochs kann für einen Zeitpunkt geplant werden, der für den Unternehmensbetrieb vorteilhafter
ist.
Wann immer auf die Daten in einem Stripe mit RAID-Loch zugegriffen wird, werden nicht korrigierbare Fehler an den betroffenen defekten
LBAs gemeldet. Nach einer gewissen Zeit (Minuten, Tage, Wochen, Monate usw.) läuft die Tabelle zur Verwaltung defekter Blöcke (Bad
Block Management, BBM) voll und für ein oder mehrere Laufwerke wird gemeldet, dass ein Ausfall wahrscheinlich ist. Wie in der Abbildung
ersichtlich, wird in der Regel für Laufwerk 0 Ausfallwahrscheinlichkeit gemeldet, weil Fehler auf Laufwerk 1 und Laufwerk 2 auf es kopiert
werden. Tatsächlich kann es sein, dass Laufwerk 0 normal arbeitet. Wenn Sie es austauschen, führt das lediglich dazu, dass nach einer
gewissen Zeit auch für das neue Laufwerk Ausfallwahrscheinlichkeit gemeldet wird.
Auch die Durchführung einer Konsistenzprüfung nach der Setzung eines RAID-Lochs behebt dieses Problem nicht. Deshalb ist es sehr
wichtig, regelmäßig Konsistenzprüfungen durchzuführen. Insbesondere vor dem Austausch von Laufwerken sollte wenn möglich eine
Konsistenzprüfung durchgeführt werden. Das Array muss in optimalem Zustand sein, damit eine Konsistenzprüfung durchgeführt werden
kann.
98
Beheben von Hardwareproblemen