An dieser Stelle wird auf das Verhalten der unterschiedlichen RAID-Verbunde im Fehlerfall eingegangen. Die Szenarien zum Restaurieren defekter RAID-Verbunde reichen von den verschiedenen RAID-Modi bis hin zu Hot Plugging und Spare-Disks.
Die folgenden Beschreibungen stützen sich alle auf den Kernel 2.2.10 mit den passenden RAID-Tools und Kernel-Patches, entsprechen also der Einrichtfunktionalität des Abschnittes über die neuen RAID-Tools Version 0.9x. Die RAID-Verbunde, welche mit den MD-Tools unter der DLD 6.0 und DLD 6.01 eingerichtet und damit quasi auf die alte Art mit den RAID-Tools Version 0.4x erstellt wurden, werden mangels ausgiebieger Tests nicht berücksichtigt.
Da sich viele Möglichkeiten der Synchronisation und der Überwachung von RAID-Verbunden auf spezielle Funktionen und Optionen der neuen RAID-Tools beziehen, kann man die im folgenden geschilderten Prozeduren nicht mal näherungsweise auf RAID-Verbunde, die mit den alten RAID-Tools Version 0.4x eingerichtet wurden, beziehen. Solange das noch nicht getestet wurde, sind Sie hier auf sich gestellt.
Hier ist die Möglichkeit der Rekonstruktion von Daten schnell erklärt. Da diese RAID-Modi keine Redundanz ermöglichen, sind beim Ausfall einer Festplatte alle Daten verloren. Definitiv gilt das für RAID-0; beim Linear Modus können Sie eventuell mit viel Glück noch einige Daten einer RAID-Partition sichern, so es denn die erste Partition ist und Sie irgendwie in der Lage sind, die Partition einzeln zu Mounten. Da RAID-0 die Daten parallel schreibt, erhalten Sie - auch wenn Sie eine Partition des RAID-0 Verbundes gemountet bekommen - niemals mehr als einen zusammenhängenden Block. Meiner Meinung nach ist an dieser Stelle eine Datenrettung von einem RAID-0 Verbund sehr sehr schwierig.
Alle drei RAID-Modi versprechen Redundanz. Doch was muß gezielt getan werden, wenn hier eine Festplatte oder eine RAID-Partition ausfällt? Generell bieten sich einem zwei Wege, um die defekte Festplatte durch eine neue zu ersetzen. Bedenken Sie bei dieser Beschreibung, daß RAID-Partition und Festplatte synonym verwendet wird. Ich gehe von einer Partition je Festplatte aus. Die eine Methode beschreibt den »heißen« Weg. Hierbei wird die Festplatte im laufenden Betrieb ausgetauscht. Die andere Methode beschreibt entsprechend den sicheren Weg. Beide Möglichkeiten haben für die RAID-Modi 1, 4 und 5 funktioniert. Seien Sie insbesondere mit dem »heißen« Weg trotzdem sehr vorsichtig, da die Benutzung dieser Befehle nicht Hot Plugging fähige Hardware zerstören könnte.
Vorab muß gesagt werden, daß Hot Plugging unter Linux auch vom SCSI-Treiber unterstützt werden muß, versuchen Sie Hot Plugging aber niemals mit (E)IDE Laufwerken. Zwar sollen alle Linux SCSI-Treiber des hier verwendeten 2.2.10er Kernels Hot Plugging unterstützen, jedoch ist dies nur bei dem Adaptec und Symbios Treiber sicher der Fall. Auch sollte Ihre Hardware und damit Ihr SCSI Kontroller und Ihre SCSI-Festplatten Hot Plugging unterstützen. Wie man das herausbekommt, ist schwer zu sagen, allerdings hat es auch mit einem fünf Jahre alten Symbios Kontroller und mehreren IBM-DCAS-UW Festplatten funktioniert. Generell ist die meiste im Consumer Bereich verfügbare Hardware nicht Hot Plugging fähig. Die zu Testzwecken eingesetzten UW-Wechselrahmen kosten etwa 125,- EUR und haben alle Hot Plugging Tests klaglos verkraftet.
Haben Sie irgendwelche Zweifel und sind nicht gezwungen, Hot Plugging zu nutzen, dann lesen Sie hier gar nicht erst weiter, sondern springen Sie sofort zu der »sicheren« Beschreibung. Auch ergeben sich aus meinen erfolgreichen Tests keine Garantien für irgendeinen Erfolg. Mit allem Nachdruck muß daher an dieser Stelle auf die Möglichkeit der Zerstörung Ihrer Hardware durch die Benutzung von Hot Plugging mit ungeeigneter Hardware hingewiesen werden.
Ihr RAID-1, 4 oder 5 ist gemäß einer der vorherigen Anleitungen erstellt
worden und betriebsbereit. Um den ganzen Ablauf zu vereinfachen, wird ab jetzt
nur noch von einem RAID-5 ausgegangen und auch die Beispielauszüge mittels
cat /proc/mdstat beschreiben ein RAID-5; RAID-1 und RAID-4 Benutzer
können analog verfahren, richten aber bitte eine erhöhte Aufmerksamkeit auf
die Unterscheidung und Abstraktion der Meldungsparameter.
Das Beispiel-RAID-5 ist in der /etc/raidtab so eingetragen:
raiddev /dev/md0
raid-level 5
nr-raid-disks 4
nr-spare-disks 0
parity-algorithm left-symmetric
persistent-superblock 1
chunk-size 32
device /dev/sda5
raid-disk 0
device /dev/sdb6
raid-disk 1
device /dev/sdc6
raid-disk 2
device /dev/sdd1
raid-disk 3
cat /proc/mdstat meldet einen ordentlich laufenden RAID-5-Verbund:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdd1[3] sdc6[2] sdb6[1] sda5[0] 633984 blocks
level 5, 32k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
Jetzt fällt die Festplatte /dev/sdd komplett aus. Beim nächsten
Zugriff auf das RAID-5 wird der Mangel erkannt, der SCSI-Bus wird resetet und
das RAID-5 läuft relativ unbeeindruckt weiter. Die defekte RAID-Partition wird
lediglich mit »(F)« gekennzeichnet und fehlt in den durch ein »U« markierten
gestarteten RAID-Partitionen:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdd1[3](F) sdc6[2] sdb6[1] sda5[0] 633984 blocks
level 5, 32k chunk, algorithm 2 [4/3] [UUU_]
unused devices: <none>
Jetzt möchten Sie wieder ein redundantes System bekommen, ohne den Rechner neu
booten zu müssen und ohne Ihr gemountetes RAID-5 stoppen zu müssen. Entfernen
Sie dafür die defekte RAID-Partition (/dev/sdd1) mittels des bei den
RAID-Tools beiliegenden Hilfsprogramms raidhotremove aus dem aktiven
RAID-Verbund (/dev/md0):
raidhotremove /dev/md0 /dev/sdd1
Ein cat /proc/mdstat hat sich nun dahingehend verändert, daß die
defekte Partition komplett rausgenommen wurde und Ihnen eine fehlende
Partition, um Redundanz zu gewährleisten, mit »[UUU_]« angezeigt wird:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdc6[2] sdb6[1] sda5[0] 633984 blocks level 5,
32k chunk, algorithm 2 [4/3] [UUU_]
unused devices: <none>
Tauschen Sie jetzt Ihre hoffentlich in einem guten Wechselrahmen befindliche defekte Festplatte gegen eine neue aus und erstellen Sie eine Partition darauf. Anschließend geben Sie den Befehl, diese neue RAID-Partition wieder in das laufende Array einzubinden:
raidhotadd /dev/md0 /dev/sdd1
Der Daemon raid5d macht sich nun daran, die neue RAID-Partition mit
den anderen zu synchronisieren:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdd1[4] sdc6[2] sdb6[1] sda5[0] 633984 blocks
level 5, 32k chunk, algorithm 2 [4/3] [UUU_] recovery=7%
finish=4.3min
unused devices: <none>
Der Abschluß dieses Vorganges wird mit einem ebenso lapidaren wie beruhigendem »resync finished« quittiert. Eine Kontrolle ergibt tatsächlich ein wieder vollständig redundantes und funktionstüchtiges RAID-5:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdd1[3] sdc6[2] sdb6[1] sda5[0] 633984 blocks
level 5, 32k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
Als ob nicht gewesen wäre.
Diese Methode sieht einen Wechsel einer defekten Festplatte in einem System vor, das ruhig für einige Zeit heruntergefahren werden kann.
Ihr RAID-1, 4 oder 5 ist gemäß einer der vorherigen Anleitungen erstellt
worden und betriebsbereit. Um den ganzen Ablauf zu vereinfachen, wird ab jetzt
nur noch von einem RAID-5 ausgegangen und auch die Beispielauszüge mittels
cat /proc/mdstat beschreiben ein RAID-5; RAID-1 und RAID-4 Benutzer
können analog verfahren, richten aber bitte eine erhöhte Aufmerksamkeit auf
die Unterscheidung und Abstraktion der Meldungsparameter.
Das Beispiel RAID-5 ist in der /etc/raidtab so eingetragen:
raiddev /dev/md0
raid-level 5
nr-raid-disks 4
nr-spare-disks 0
parity-algorithm left-symmetric
persistent-superblock 1
chunk-size 32
device /dev/sda5
raid-disk 0
device /dev/sdb6
raid-disk 1
device /dev/sdc6
raid-disk 2
device /dev/sdd1
raid-disk 3
cat /proc/mdstat meldet einen ordentlich laufenden RAID-5-Verbund:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdd1[3] sdc6[2] sdb6[1] sda5[0] 633984 blocks
level 5, 32k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
Jetzt fällt die Festplatte /dev/sdd komplett aus. Beim nächsten
Zugriff auf das RAID-5 wird der Mangel erkannt, der SCSI-Bus wird resetet und
das RAID-5 läuft relativ unbeeindruckt weiter. Die defekte RAID-Partition wird
lediglich mit »(F)« gekennzeichnet:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdd1[3](F) sdc6[2] sdb6[1] sda5[0] 633984 blocks
level 5, 32k chunk, algorithm 2 [4/3] [UUU_]
unused devices: <none>
Jetzt möchten Sie wieder ein redundantes System bekommen. Fahren Sie dazu
Ihren Rechner herunter und tauschen Sie die defekte Festplatte gegen eine neue
aus. Nach dem Startup müssen Sie auf der neuen Festplatte eine entsprechende
Partition möglichst auch mit der RAID-Autostart Option durch das
»fd« Flag einrichten. Ist die neue Partitionsangabe identisch mit der
auf der defekten Festplatte, brauchen Sie nichts weiter zu machen, ansonsten
müssen Sie noch Ihre /etc/raidtab anpassen. Weiterhin ist es
erforderlich, daß Ihr RAID-Verbund läuft. Ist das nicht bereits während des
Bootvorganges erfolgt, müssen Sie selbiges jetzt nachhlen:
raidstart /dev/md0
Jetzt fehlt noch der Befehl, um die neue RAID-Partition wieder in das RAID-5
einzuarbeiten und die »persistent-superblocks« neu zu schreiben. Hierbei
werden keine vorhandenen Daten auf dem bestehenden RAID-5 Verbund zerstört, es
sei denn, Sie haben sich bei der eventuell nötigen Aktualisierung der
/etc/raidtab vertan. Prüfen Sie alles dringend nochmal. Ansonsten:
raidhotadd /dev/md0 /dev/sdd1
Dieser Befehl suggeriert zwar, daß hier eine Art Hot Plugging stattfindet,
heißt in diesem Zusammenhang aber nichts anderes, als daß eine RAID-Partition
in ein vorhandenes RAID-Array eingearbeitet wird. Würden Sie stattdessen den Befehl
mkraid mit seinen Parametern aufrufen, würde dies zwar auch zu dem
Erfolg führen, ein neues RAID-Array zu erstellen, jedoch dummerweise ohne Daten und
damit natürlich auch und vor allem ohne die bisher vorhandenen Daten.
Inspizieren Sie anschließend den Verlauf wieder mittels cat /proc/mdstat:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdd1[3] sdc6[2] sdb6[1] sda5[0] 633984 blocks
level 5, 32k chunk, algorithm 2 [4/4] [UUUU] resync=57%
finish=1.7min
unused devices: <none>
Der Abschluß dieses Vorganges wird mit einem ebenso lapidaren wie beruhigendem »resync finished« quittiert. Eine Kontrolle ergibt tatsächlich ein wieder vollständig redundantes und funktionstüchtiges RAID-5:
Personalities : [linear] [raid0] [raid1] [raid5] [hsm]
read_ahead 1024 sectors
md0 : active raid5 sdd1[3] sdc6[2] sdb6[1] sda5[0] 633984 blocks
level 5, 32k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
Das RAID-5 Array muß nun lediglich wieder in den Verzeichnisbaum gemountet
werden, falls Ihr RAID-Array nicht bereits innerhalb der /etc/fstab
während des Bootvorganges gemountet wurde:
mount /dev/md0 /mount-point
Hiermit haben Sie wieder ein vollständig redundantes und lauffähiges RAID-5 Array hergestellt.
Um bei einem RAID-1, 4 oder 5 Verbund mit einer Spare-Disk per Hot Plugging,
also ohne den RAID-Verbund auch nur herunterzufahren, eine RAID-Partition per
raidhotremove aus dem laufenden Verbund zu entfernen und durch eine
neue RAID-Partition zu ersetzen, sind die aktuellsten RAID-Tools erforderlich.
Erst diese haben durch das neue Programm raidsetfaulty die
Möglichkeit, die ausgefallene RAID-Partition als defekt zu markieren und so
den Befehl raidhotremove zu ermöglichen. Zu beachten ist hier, daß
bei einem Festplattenausfall die Spare-Disk sofort eingearbeitet und das System
anschließend auch wieder Redundant ist und somit natürlich nicht die
Spare-Disk, sondern die ausgefallene RAID-Partition als defekt markiert,
ausgetauscht und als neue Spare-Disk wieder eingesetzt werden muß.
Auch an dieser Stelle muß auf die Gefahr der teilweisen oder vollständigen Zerstörung Ihrer Hardware hingewiesen werden, sollte diese nicht Hot Plugging fähig sein. Haben Sie die Möglichkeit zu wählen, benutzen Sie immer die sichere Methode.
Ein normal laufender RAID-5 Verbund mit Spare-Disk sollte bei einem
RAID-Verbund /dev/md0 mit den RAID-Partitionen /dev/sdb1,
/dev/sdc1 und /dev/sdd1 plus der Spare-Disk
/dev/sde1 unter /proc/mdstat folgendes zeigen:
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 sde1[3] sdd1[2] sdc1[1] sdb1[0] 782080 blocks
level 5, 32k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Durch das Entriegeln des Wechselrahmens wird ein Defekt der Partition
/dev/sdc1 simuliert. Sobald wieder auf den RAID-5 Verbund zugegriffen
wird, wird der Defekt bemerkt, der SCSI-Bus resetet und der Recovery-Prozeß
über den raid5d Daemon beginnt. Ein cat /proc/mdstat zeigt jetzt
folgendes:
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 sde1[3] sdd1[2] sdc1[1](F) sdb1[0] 782080 blocks
level 5, 32k chunk, algorithm 2 [3/2] [U_U] recovery=4%
finish=15.4min
unused devices: <none>
Nach dem erfolgreichen Ende des Recovery-Prozesses liefert cat /proc/mdstat folgendes:
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 sde1[3] sdd1[2] sdc1[1](F) sdb1[0] 782080 blocks
level 5, 32k chunk, algorithm 2 [3/2] [U_U]
unused devices: <none>
Den neuen Zustand sollten Sie nun sichern, indem Sie
umount /dev/md0
ausführen. Mit
raidstop /dev/md0
wird der aktuelle Zustand auf die RAID-Partitionen geschrieben. Ein
raidstart -a
cat /proc/mdstat
zeigt dann:
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 sdd1[2] sde1[1] sdb1[0] 782080 blocks level 5,
32k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Wie Sie erkennen können, fehlt die defekte Partition /dev/sdc1[1](F),
dafür hat die Spare-Disk /dev/sde1[1] deren Funktion übernommen.
Das ist jetzt der aktuelle Zustand des RAID-5. Nun wird die defekte
Festplatte ersetzt, indem Sie den Rechner herunterfahren und den
Festplattenaustausch durchführt. Wenn Sie neu booten, geht zunächst
nichts mehr. Nun bloß keine Panik kriegen, sondern erstmal der
/etc/raidtab Datei den neuen Zustand beibringen:
raiddev /dev/md0
raid-level 5
nr-raid-disks 3
nr-spare-disks 1
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 32
device /dev/sdb1
raid-disk 0
device /dev/sde1
raid-disk 1
device /dev/sdd1
raid-disk 2
device /dev/sdc1
spare-disk 0
Anschließend bringt ein
raidhotadd /dev/md0 /dev/sdc1
dem RAID-Verbund die neue Konstellation bei, ohne dabei die Daten
auf dem RAID-5 Verbund zu beschädigen, solange Sie sich in der
Datei /etc/raidtab nicht vertan haben. Schauen Sie sich die
Einträge in Ihrem eigenen Interesse bitte nochmal genau an. Ein
cat /proc/mdstat zeigt jetzt die Resynchronisation. Man sieht
jetzt die neue Zuordnung der RAID-Partitionen im RAID-Verbund, die exakt den
neuen Stand der Zuordnung darstellen sollte.
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 sdc1[3] sdd1[2] sde1[19] sdb1[0] 782080 blocks
level 5, 32k chunk, algorithm 2 [3/3] [UUU] resync=36%
finish=6.7min
unused devices: <none>
Am Ende erscheint:
raid5: resync finished
Ein cat /proc/mdstat sieht nun so aus:
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 sdc1[3] sdd1[2] sde1[1] sdb1[0] 782080 blocks
level 5, 32k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Nun ruft man
raidstop /dev/md0
auf, um alles auf die Platten zu schreiben. Hat der Kernel das RAID-Array bereits gestartet (persistent-superblock 1), kann man mit einem
mount /dev/md0 /mount-point
den RAID-Verbund wieder in das Dateisystem einhängen. Ansonsten ist vorher noch folgender Befehl notwendig:
raidstart /dev/md0
Hiermit haben Sie wieder ein vollständiges laufendes RAID-5 Array hergestellt.