Ich habe ein RAID5-Setup mit 4 Festplatten und 5 TB, bei dem eine Festplatte Anzeichen zeigt, dass sie den Geist aufgibt. Sie meldet Medienfehler und in dmesg kann ich sehen, dass mehrere Lesefehler behoben wurden. smartctl meldet zwar „Benachrichtigungen“, aber bisher kein Grund zur Panik. Da neue Festplatten im Moment ziemlich teuer sind, fange ich an, darüber nachzudenken, wie robust die Linux-MD-Schicht eigentlich ist.
Ich wäre dankbar, wenn jemand etwas Licht ins Dunkel bringen könnte, wie md eigentlich mit Festplattenfehlern umgeht. Wie geht md beispielsweise mit Schreib- und Lesefehlern um – was muss (wirklich) passieren, damit eine Festplatte aus einem Array abgelehnt wird? Ich habe auch gelesen, dass md seit Kurzem Unterstützung für die Zuordnung fehlerhafter Blöcke hat. Bedeutet das, dass die Lesefehler, die ich hatte, zugeordnet worden wären, wenn ich einen Kernel >3.1 verwendet hätte, oder würde md trotzdem versuchen, „an ihnen zu arbeiten“, um sie nutzbar zu machen?
Antwort1
Wenn Ihnen Ihre Daten wichtig sind, wechseln Sie jetzt die Festplatte. Jedes Subsystem tut alles, um Datenverlust zu verhindern, aber es kann nur so viel tun. Sogar es kann fehlerhafte Blöcke umgehen: Wenn es einen gibt, gibt es weitere
Sie haben massive Warnungen vor drohenden Problemen erhalten: Diese zu ignorieren ist gegenüber den Daten Ihrer Kunden schlicht unverantwortlich.
Bearbeiten, da dies für einen Kommentar zu lang ist:
Ich weiß nicht, was deine Frage eigentlich ist. Willst du wissen, ob die Warnungen ernst gemeint sind? Ja, das sind sie. Willst du etwas dagegen tun? Ja, und zwar sofort.
Wenn ein Subsystem Lesefehler meldet, sind diese vorhanden und wichtig. Auch wenn das System noch in der Lage ist, sie zu beheben, besteht eine gute Chance, dass dies in zwei Minuten nicht mehr der Fall ist und die Festplatte als fehlerhaft markiert und offline genommen wird.
Linux MD RAID ist mindestens so vertrauenswürdig wie jede Hardware-RAID-Implementierung, aber ich würde RAID5 im besten Fall als gefährliche Wahl betrachten. Das Problem dabei ist, dass Sie während einer Wiederherstellung ungeschützt sind, was für RAID5 eine sehr anstrengende Situation ist. Ich halte es für vertrauenswürdiger als einige Hardware-RAID-Systeme, da Sie frühzeitig gewarnt werden, wenn eine Festplatte kurz vor dem Ausfall steht, während ein Hardware-RAID Sie möglicherweise erst im Nachhinein informiert. Ein Software-RAID hat einige Nachteile, die hauptsächlich mit Leistungsproblemen zusammenhängen, aber Zuverlässigkeit gehört nicht dazu.
Unabhängig davon besteht die professionelle Vorgehensweise in einer Situation wie der Ihren darin, die Festplatte sofort auszutauschen. Und das wäre auch meine Reaktion bei meinem privaten Festplatten-Array (für solche Situationen habe ich immer ein Ersatzlaufwerk herumliegen).
Antwort2
Dies beruht auf einer etwa 6 Jahre alten Erfahrung mit einem unserer Dell-Server: Damals haben wir kein Hardware-RAID verwendet, da es keine Möglichkeit gab, Festplattenausfälle aus der Ferne zu erkennen.
Also haben wir Software-RAID 1 (md) verwendet. Kurze Zeit später wurde das RAID degradiert. Als ich mir /var/log/messages ansah, sah ich, dass es eine Liste von IO-Fehlern im Zusammenhang mit einer bestimmten Partition gab.
Ich habe die Partition erneut zum Raid hinzugefügt und kurze Zeit später wurde sie wieder rausgeworfen.
Ich habe dem Dell-Support die Ausgabe /var/log/messages geschickt und sofort eine neue Festplatte erhalten. Diese war auf einer nicht unterstützten Linux-Variante und hatte nur die grundlegendste Supportstufe.
Wir hatten ein paar andere Maschinen damit eingerichtet und hatten nie wieder diese Probleme (d. h. die Festplatten sind nie ausgefallen). Für mich ist das ein Beweis dafür, dass man sich auf md verlassen kann.
Ich glaube, das gilt immer noch für den 3.1-Kernel (ich habe noch keinen davon).
Antwort3
Soweit ich weiß, ist mdadm eine robuste Software-RAID-Implementierung, die bei Festplatten in gutem Zustand selten Fehler jeglicher Art generiert. Ich habe mehrere Server mit konfiguriertem mdadm und habe nie Lesefehler in den Protokolldateien erhalten.
Überprüfen Sie den Status Ihres Arrays mit:
mdadm --detail /dev/mdX
Ich empfehle Ihnen jedoch dringend, das für die Fehler verantwortliche Laufwerk auszutauschen ...