Ich bin in meiner Laufbahn schon mehrmals auf mdadm-RAID-Sets (RAID1+0, 5, 6 usw.) in verschiedenen Umgebungen (z. B. CentOS/Debian-Boxen, Synology/QNAP-NAS) gestoßen, die scheinbar einfach nicht in der Lage sind, mit fehlerhaften Festplatten umzugehen. Das ist eine Festplatte, die nicht völlig tot ist, aber Zehntausende fehlerhafter Sektoren hat und einfach nicht in der Lage ist, I/O zu verarbeiten. Aber sie ist nicht völlig tot, sie funktioniert noch irgendwie. Das Kernel-Protokoll ist normalerweise voller UNC-Fehler.
Manchmal erkennt SMART, dass die Festplatte fehlerhaft ist, manchmal gibt es außer langsamen E/A-Vorgängen keine weiteren Symptome.
Die langsame E/A führt tatsächlich dazu, dass das gesamte System einfriert. Die Verbindung über SSH dauert ewig, die Web-GUI (wenn es sich um ein NAS handelt) funktioniert normalerweise nicht mehr. Das Ausführen von Befehlen über SSH dauert ebenfalls ewig. Das ist so, bis ich die Festplatte aus dem Array trenne/absichtlich „ausfallen“ lasse, dann wird alles wieder „normal“ – das ist so normal, wie es mit einem degradierten Array sein kann.
Ich frage mich nur, wenn das Lesen/Schreiben einer Festplatte so lange dauert, warum man sie dann nicht einfach aus dem Array entfernt, eine Meldung im Protokoll hinterlässt und weitermacht? Es scheint, dass das ganze System zum Stillstand kommt, weil eine Festplatte irgendwie verrückt spielt, was einen der Hauptvorteile von RAID (Fehlertoleranz – die Fähigkeit, weiterzulaufen, wenn eine Festplatte ausfällt) völlig zunichte macht. Ich kann verstehen, dass dies in einem Szenario mit einer einzelnen Festplatte (z. B. wenn Ihr System eine einzelne SATA-Festplatte angeschlossen hat und diese Lese-/Schreibvorgänge nicht richtig ausführen kann) katastrophal ist, aber in einem RAID-Set (insbesondere den fehlertoleranten „Persönlichkeiten“) scheint es nicht nur ärgerlich, sondern auch unvereinbar mit dem gesunden Menschenverstand.
Gibt es einen sehr guten Grund, warum das Standardverhalten von mdadm darin besteht, die Box grundsätzlich lahmzulegen, bis sich jemand per Fernzugriff einloggt und das Problem manuell repariert?
Antwort1
Im Allgemeinen ist der Zweck einerÜBERFALL, je nach gewähltem Raid-Level, sorgt für eine unterschiedliche Balance zwischen den Hauptzielen Daten Redundanz, Verfügbarkeit, LeistungUndKapazität.
Basierend auf den spezifischen Anforderungen ist es dieVerantwortung des Speichereigentümerszu entscheiden, welches Gleichgewicht der verschiedenen Faktoren für den gegebenen Zweck das richtige ist, um einezuverlässigLösung.
Die Aufgabe der gewählten Raid-Lösung (in diesem Fall sprechen wir von der Software mdadm) besteht in erster Linie darin, den Datenschutz zu gewährleisten. Vor diesem Hintergrund wird klar, dass es nicht die Aufgabe der Raid-Lösung ist, der Geschäftskontinuität einen höheren Stellenwert einzuräumen als der Datenintegrität.
Mit anderen Worten: Die Aufgabe von mdadm besteht darin, einen fehlgeschlagenen Raid zu verhindern. Solange eine „seltsam wirkende Festplatte“ nicht völlig kaputt ist, trägt sie immer noch zum Raid bei.
Warum also nicht einfach eine sich seltsam verhaltende Festplatte aus dem Array entfernen, eine Meldung im Protokoll hinterlassen und weitermachen?Denn dadurch würde das Risiko eines Datenverlusts steigen.
Ich meine, Sie haben Recht, im Moment scheint es aus geschäftlicher Sicht die bessere Lösung zu sein, einfach weiterzumachen. In Wirklichkeit bleibt die Meldung, die ins Protokoll geschrieben wurde, jedoch möglicherweise unentdeckt, sodass der verschlechterte Zustand des Raids unentdeckt bleibt. Einige Zeit später fällt schließlich eine andere Festplatte im selben Raid aus, wodurch die gespeicherten Daten auf dem ausgefallenen Raid schließlich verloren gehen.
Darüber hinaus ist es schwierig, genau zu definieren, was eine „seltsam verhaltende Festplatte“ ist. Anders ausgedrückt: Was ist noch ein akzeptables Betriebsverhalten einer einzelnen Festplatte, die innerhalb eines Festplattenarrays betrieben wird?
Einige von uns antworten vielleicht: „Die Festplatte weist einige Fehler auf.“ Andere antworten vielleicht: „Solange die Fehler behoben werden können, ist alles in Ordnung.“ Andere antworten vielleicht: „Solange die Festplatte alle Befehle in einer bestimmten Zeit beantwortet, ist alles in Ordnung.“ Andere sagen: „Falls die Festplattentemperatur um mehr als 5 °C von der Durchschnittstemperatur aller Festplatten im selben Array abweicht.“ Eine andere Antwort könnte sein: „Solange ein Scrub keine Fehler aufdeckt“ oder „Solange SMART keine Fehler anzeigt.“
Das Geschriebene ist keine lange und auch keine vollständige Liste.
Der Punkt ist, dass die Definition des „akzeptablen Verhaltens einer Festplatte“ eine Frage der Interpretation ist und daher auch in der Verantwortung des Speicherbesitzers liegt und nicht etwas, worüber mdadm allein entscheiden soll.
Antwort2
Das Hauptproblem besteht darin, dass ein fehlerhaftes SATA-Laufwerk manchmal den gesamten Bus für die Dauer seines internen Fehlerbehebungsverfahrens einfrieren kann. Aus diesem Grund sollte manTLER-fähigLaufwerke nur in RAID-Arrays (und vorzugsweise ein Modell der Enterprise-Klasse).
Bei SAS-Laufwerken ist dieses Problem weniger ausgeprägt, aber auch sie sind nicht völlig frei davon.
Antwort3
Zusätzlich zu dem Gesagten möchte ich meinen Senf dazugeben, aber dies ist eine wichtige Überlegung.
Waseine Fahrtpassiert, wenn das Lesen des Sektors langsam ist?
Angeblich gehen Laufwerke, die für den alleinigen Betrieb konzipiert sind, z. B. typische „Desktop“-Laufwerke, davon aus, dass es keine andere Möglichkeit gibt, die in diesem fehlerhaften Sektor gespeicherten Daten abzurufen. Sie werden versuchen, die Daten um jeden Preis abzurufen, und dies über einen längeren Zeitraum immer wieder wiederholen. Natürlich werden sie diesen Sektor auch als fehlerhaft markieren, sodass sie ihn beim nächsten Schreiben neu zuordnen, aber dafür müssen Sie schreiben. Bis Sie ihn neu schreiben, werden sie bei jedem Lesen von diesem Ort abstürzen. In einer RAID-Einstellung bedeutet dies, dass das Laufwerk für das RAID noch funktioniert und es keinen Grund gibt, es rauszuwerfen, aber bei der Anwendung wird das Array bis zum Schneckentempo langsamer.
Auf der anderen Seite wird bei "Enterprise"-Laufwerken, insbesondere "Markenlaufwerken", oft angenommen, dass sie immer in RAID-Einstellungen verwendet werden. Ein "Marken"-Controller, der ein "Markenlaufwerk" erkennt, könnte sogarbenachrichtigenihre Firmware über das Vorhandensein von RAID. Das Laufwerk wird also frühzeitig abgeschaltet und meldet einen E/A-Fehler, selbst wenn mehrere weitere Versuche möglich waren, den Sektor zu lesen. Dann hat der Controller die Möglichkeit, schneller zu antworten, indem er den Lesebefehl an ein Schwesterlaufwerk spiegelt (und ein fehlerhaftes Laufwerk aus dem Array wirft). Wenn Sie das rausgeworfene Laufwerk herausziehen und gründlich untersuchen/testen, finden Sie keine offensichtlichen Probleme – es wurde nur für einen Moment verlangsamt und das war laut einer Controller-Logik genug, um es nicht mehr zu verwenden.
Ich vermute, das könnte seindie einzigeUnterschied zwischen „Desktop“-Laufwerken und „Marken-“/„Enterprise“-Laufwerken mit NL-SAS und SATA. Das ist wahrscheinlich der Grund, warum Sie dreimal mehr bezahlen, wenn Sie ein „HPE“-Laufwerk kaufen, das eigentlich von Toshiba hergestellt wurde, im Vergleich zum Kauf eines Laufwerks mit der Marke „Toshiba“.
Einige Laufwerke unterstützen jedoch einige generische Steuerungen hierfür. Diese werden SCT ERC genannt und dienenSMART Command Transport-Fehlerbehebungssteuerung. So sieht es aus in smartctl:
nicht unterstützt
# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities: (0x3037) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
unterstützt
=== START OF READ SMART DATA SECTION ===
...
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
Wenn Sie Glück haben, können Sie diese Funktion mit steuern smartctl. Sie können zwei Timeouts abrufen oder festlegen, wie lange versucht werden soll, erneut zu lesen und wie lange versucht werden soll, erneut zu schreiben:
# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command
smartctl -l scterc,120,60 /dev/sde
Das bedeutet: 120 Zehntelsekunden für erneuten Leseversuch; 60 Zehntelsekunden für erneuten Schreibversuch. Null bedeutet „Wiederholen, bis es nicht mehr geht“. Verschiedene Laufwerke haben hierfür unterschiedliche Standardeinstellungen.
Wenn Sie also nur ein Laufwerk der „RAID Edition“ verwenden, sollten Sie die ERC-Timeouts besser auf Null setzen, da Sie sonst möglicherweise Daten verlieren. Wenn Sie andererseits Laufwerke im RAID verwenden, sollten Sie einen vernünftigen niedrigen Wert ungleich Null festlegen.
Quelle von amarao @ Habrahabr, auf Russisch.
PS Und eine Anmerkung zu SAS. Verwenden Sie sdparm, es unterstützt weitere Steuerelemente hierfür.
Antwort4
Ich habe Situationen erlebt, in denen eine Festplatte nicht funktionierte, aber der Controller irgendwie ausgefallen war.
In der Vergangenheit war dies mit PATA möglich, wo Master- und Slave-Laufwerke am selben Kabel angeschlossen waren und ein defektes Laufwerk den Zugriff auf das andere, noch funktionierende Laufwerk beeinträchtigen konnte. Durch Entfernen des defekten Laufwerks konnte der Zugriff auf das verbleibende Laufwerk wieder aktiviert werden. Oder es war ein Neustart erforderlich, aber das RAID konnte beeinträchtigt werden und dann konnte die Wiederherstellung beginnen.
SATA ist dafür weniger anfällig, aber es ist trotzdem möglich, dass der Controller betroffen ist. Meiner Erfahrung mit Software-Raids zufolge sind dort mehr Innereien sichtbar, als von einem aufwendigeren dedizierten Raid-Controller verborgen werden könnten.
Bei SAS oder NVME ist mir dies nicht passiert, aber SAS steht oft für Hardware-RAID-Controller, die intern über mehr Intelligenz zur Festplattenverwaltung verfügen.