RAID: Festplatte(n) vor produktivem Einsatz prüfen
Dieser Artikel ist der Erste in einer Serie von Kurzartikeln über das Einrichten und die Verwaltung von Linux Software-RAID.
Vor der Inbetriebnahme des RAID-Verbunds sind einige Schritte notwendig, um die Qualität und Leistung der Festplatten festzustellen. Dadurch sind später Richtwerte vorhanden, um die Geschwindigkeit des Verbunds einordnen und optimieren zu können.
Gerade bei Festplatten aus dem Desktop-Bereich, die sich aufgrund ihres niedrigen Preises für RAID-Verbünde eignen, kann es je nach Hersteller Qualitätsunterschiede geben, die festzustellen sind. Wichtig ist, dass bei den folgenden Abläufen, alle bisher gespeicherten Daten der Festplatten verloren gehen.
Für den selbst gemachten Qualitätstest werden die dafür üblichen Verdächtigen benötigt:
# apt-get install spew stress
Defekte Blöcke
Blöcke sind die kleinste Einheit auf einer Spur auf einem Platter der Festplatte. Ziel ist es hier zu prüfen, ob und wieviele Blöcke endgültig defekt sind, bevor die wichtigen Urlaubsfilme oder Unternehmensdaten gerade in einem dieser Blöcke gespeichert werden. Einige defekte Blöcke kann eine Festplatte durch Reserve-Blöcke ersetzen. Die folgende Kommandozeile prüft jeden Block auf Funktion, indem die größten und kleinsten speicherbaren Informationen (0x00, 0xff und Wiederholungen davon) in jeden Block geschrieben und wieder gelesen werden.
# badblocks -v -s -w /dev/sdX | tee sdX_badblocks.txt
Nach einigen Stunden ist der Test beendet. Sollte die Textdatei eine Liste von natürlichen Zahlen enthalten, wurden die Blöcke mit den angegebenen Nummern als endgültig defekt erkannt. Die Textdatei beschleunigt die Garantieabwicklung. Wurden keine defekten Blöcke gefunden, ist die Datei leer.
Stresstest
Um nicht nur die Qualität der Blöcke, sondern auch das Verhalten der Festplatten unter Last zu prüfen und Fehler im Gehäuse-Luftstrom, Stromzufuhr und andere Einschränkungen für den Dauerbetrieb zu finden, ist ein Stresstest notwendig. Vor dem Stresstest wird die zu prüfende Festplatte mit dem Dateisystem formatiert, mit dem auch der RAID-Verbund betrieben werden soll. Für diese Artikel-Serie wird das (ich möchte nicht zu weit vorgreifen) XFS sein. Die dafür notwendigen Programme müssen installiert werden.
# apt-get install xfsprogs
Jetzt die entsprechende Festplatte mit den Voreinstellungen formatieren und einbinden.
mkfs.xfs /dev/sdX mount /dev/sdX /mnt cd /mnt
Um einen aussagekräftigen Stresstest durchzuführen, ist es das zum vorgesehen Einsatzgebiet des RAID-Verbunds passende Testmuster zu wählen. Hier einige Beispiele, nach Erfahrungswert.
# stress -t 21600 --hdd 3 --hdd-bytes 64k
Ein sechsstündiger Arbeitstag einer durchschnittlichen System-Festplatte.
# stress -t 86400 --hdd 30 --hdd-bytes 4k
Ein rund um die Uhr betriebener Usenet-Server mit ungefähr 30 aktiven Nutzern.
# stress -t 14400 --hdd 3 --hdd-bytes 700m
Ein vierstündiger Abend eines privaten Fileservers für Videos in einer kleinen Familie.
Der Test sollte keine Fehler produzieren und erfolgreich terminieren. Ist das nicht der Fall, lohnt es sich den Test auf defekte Blöcke erneut durchzuführen, um durch den Zugriff möglicherweise als endgültig defekt erkannte Blöcke zu finden und die Festplatte zu tauschen.
Benchmark
Hat die Festplatte bisher durchgehalten, stehen die Chancen gut, dass sie im RAID-Verbund lange Freude bereiten wird. Bleibt nur noch, die Leistungswerte unter realen Bedingungen zu erfassen. Die können später herangezogen werden, um die Geschwindigkeit des Software RAID-Verbunds zu optimieren. Dabei hat es sich als praktisch erwiesen, für verschiedene Dateigrößen den Festplattendurchsatz und die dabei möglichen I/O-Operationen pro Sekunde (IOPS) zu erfassen. Es ist schwierig unter Debian GNU/Linux, das über sehr gute Caching-Mechanismen verfügt, gerade bei kleinen Dateien nicht die Geschwindigkeit des Arbeitsspeichers, sondern die der Festplatte zu messen. Darum sollte vor jedem Testlauf der Cache des I/O-Subsystems gelöscht werden.
Gemessen wird die Leistung der Festplatte bei einer Dateigröße von 4kB, 1MB und 1GB. Der Test wird fünf mal wiederholt.
sync && echo 3 > /proc/sys/vm/drop_caches spew -d -i 5 --read-after-write -b 1k 4k test4k | tee sdX_4kBench.txt
sync && echo 3 > /proc/sys/vm/drop_caches spew -d -i 5 --read-after-write -b 1k 1m test1m | tee sdX_1MBench.txt
sync && echo 3 > /proc/sys/vm/drop_caches spew -d -i 5 --read-after-write -b 8m 1g test1g | tee sdX_1GBench.txt
(Wobei jeweils gilt: WTR - Durchsatz schreibend, RTR - Durchsatz lesend)
Die Ergebnisse des letzten Tests sollten bis auf kleine Unterschiede ähnliche IOPS-Werte liefern. Ansonsten ist ein weiterer Test auf defekte Blöcke oder die Wiederholung des Benchmarks ratsam, um sicher zu gehen, dass die Ursache nicht ein Defekt der Festplatte ist.
Prüfung abschließen
Wenn die Festplatte alle drei Tests fehlerfrei überstanden hat: Glückwunsch! Dem Einsatz in einem RAID-Verbund steht nichts im Weg, außer dem noch notwendigen Aufwand, die Testergebnisse an einem sicheren Ort aufzubewahren.
Ergänzend macht es noch Sinn, die S.M.A.R.T-Werte der Festplatte vor Inbetriebnahme zu erfassen. Wie das geht, hat Marco in seinem Artikel beschrieben.