|
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
ausgiebiger 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 muss 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, dass
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 muss gesagt werden, dass Hot Plugging unter Linux auch vom
SCSI-Treiber unterstützt werden muss, 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 muss 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:
root@linux ~#
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 level5, 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 1024sectors
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):
root@linux ~#
raidhotremove /dev/md0 /dev/sdd1
|
Ein cat /proc/mdstat hat sich nun dahingehend verändert, dass 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 1024sectors
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:
root@linux ~#
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 1024sectors
md0 : active raid5 sdd1[4] sdc6[2] sdb6[1] sda5[0] 633984 blockslevel5, 32k chunk, algorithm 2 [4/3] [UUU_] recovery=7% finish=4.3min
unused devices: <none>
|
Der Abschluss 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 1024sectors
md0 : active raid5 sdd1[3] sdc6[2] sdb6[1] sda5[0] 633984 blocks level5, 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:
root@linux ~#
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 level5, 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 1024sectors
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, dass Ihr
RAID-Verbund läuft. Ist das nicht bereits während des Bootvorganges
erfolgt, müssen Sie selbiges jetzt nachholen:
root@linux ~#
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 noch mal. Ansonsten:
root@linux ~#
raidhotadd /dev/md0 /dev/sdd1
|
Dieser Befehl suggeriert zwar, dass hier eine Art Hot Plugging
stattfindet, heißt in diesem Zusammenhang aber nichts anderes, als dass
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 1024sectors
md0 : active raid5 sdd1[3] sdc6[2] sdb6[1] sda5[0] 633984 blocks level5, 32k chunk, algorithm 2 [4/4] [UUUU] resync=57% finish=1.7min
unused devices: <none>
|
Der Abschluss 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 1024sectors
md0 : active raid5 sdd1[3] sdc6[2] sdb6[1] sda5[0] 633984 blocks level5, 32k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
|
Das RAID-5 Array muss nun lediglich wieder in den Verzeichnisbaum
gemountet werden, falls Ihr RAID-Array nicht bereits innerhalb der
/etc/fstab während des Bootvorganges gemountet wurde:
root@linux ~#
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, dass 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 muss.
Auch an dieser Stelle muss 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 level5, 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-Prozess ü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
root@linux ~#
umount /dev/md0
|
ausführen. Mit
root@linux ~#
raidstop /dev/md0
|
wird der aktuelle Zustand auf die RAID-Partitionen geschrieben. Ein
root@linux ~#
raidstart -a
root@linux ~#
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 erst mal der
/etc/raidtab Datei den neuen Zustand beibringen:
root@linux #
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
root@linux ~#
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 noch mal 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:
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 level5, 32k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
|
Nun ruft man
root@linux ~#
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
root@linux ~#
mount /dev/md0 /mount-point
|
den RAID-Verbund wieder in das Dateisystem einhängen. Ansonsten ist
vorher noch folgender Befehl notwendig:
root@linux ~#
raidstart /dev/md0
|
Hiermit haben Sie wieder ein vollständiges laufendes RAID-5 Array
hergestellt.
|
|
|
SelfLinux 
