Es muss nicht immer Hardware sein: Wenn ausreichend Rechenleistung zur Verfügung steht und Hot Swap nicht erforderlich ist, tut ein Software-Raid gute Dienste. Aber wie migriert man eine vorhandene Installation?

Sinn und Unsinn von Software-Raids sind in Fachkreisen durchaus umstritten, Phrasen wie “Software-Raid? Hat das Geld nicht für eine Hardwarelösung gereicht?” bekommt man immer wieder zu hören. Software-Raids sind sicherlich keine High-End-Lösung, aber im unteren und mittleren Leistungssegment eine erwägenswerte Alternative zu Festplattencontrollern mit Raid-Funktion, bei denen der Treiber und somit wieder der Prozessor des Rechners die Hauptarbeit leistet. Warum dann nicht gleich zum Software-Raid greifen?

Auf Basis des Multiple-Device-Treibers stellt der Kernel völlig unabhängig von der Hardware bis zu 256 Multiple Devices (»/dev/md X«) zur Verfügung. Ein Multiple Device ist ein virtuelles Block Device bestehend aus zwei oder mehr Partitionen, die als ein Array angesprochen werden. Die Leistung eines solchen Array hängt von der Taktfrequenz und Auslastung des Prozessors sowie der Datenrate der einzelnen Festplatten ab.

Wie viel Raid darf’s sein?

Das Raid-Prinzip ha-ben Katz, Gibson und Patterson in ihrem Papier “A Case for Redundant Arrays of Inexpen-sive Disks (RAID)” an der Universität Berkeley 1988 beschrieben[1]. Die Daten werden auf mehrere (redundant angelegte) Festplatten geschrieben. Je nach Art und Weise der logischen Verknüpfung der Festplatten wird hierdurch die Transferrate oder die Ausfallsicherheit erhöht.

Seither hat sich gut ein Dutzend Raid-Level entwickelt. Der Multiple-Device-Treiber von Linux unterstützt in der Version 0.90 fünf verschiedene Raid-Level (siehe Kasten “Raid-Level”).

Fliegender Umbau

Der folgender Workshop zeigt beispielhaft, wie aus einem bestehenden Linux- System in Handarbeit ein Raid-5-System mit drei Festplatten entsteht. Dieser Weg hat den Vorteil, dass die Daten der vorhandenen Festplatte zunächst nicht auf ein viertes Laufwerk umkopiert werden müssen. Dennoch sollten Sie die Daten in jedem Fall sichern, eine kleine Namensverwechslung reicht, um die Systemplatte versehentlich zu überschreiben. Die verwendeten Raid-Tools sowie das Programm »mdadm« sind in SuSE Linux und Red Hat 9.0 enthalten.

Ausgangspunkt für den Umbau ist ein System mit drei IDE-Festplatten. Die Platten müssen für ein Software-Raid nicht alle baugleich sein, sollten aber in diesem Fall ungefähr die gleiche Größe haben und möglichst auch die gleiche Übertragungsrate haben.

Auf dem Beispielsystem ist auf »hdc« bereits ein lauffähiges Linux-System mit folgenden Partitionen installiert: »hdc1« (später »md0«) mit 200 MByte als »/boot« mit Ext 3, »hdc2« (später »md1«) mit 1 GByte als Swap sowie »hdc3« (später »md3«) mit 5 GByte als »/root« (»/«) mit Ext 3. Um das System in möglichst jeder (Fehler-)Situation sicher booten zu können, wird die »/boot«-Partition als Raid 1 ausgelegt.

Lilo statt Grub

Als Bootloader dient Lilo, da er ab der Version 22.0 einen Notfall-Bootcode in den Master Boot Record der anderen Raid-Laufwerke schreiben kann. Somit ist bei einem Ausfall von »hda« gewährleistet, dass das System von »hdb« oder »hdc« booten kann. Grub besitzt diese Fähigkeit nicht.

Lilo wird für den Umbau mit der Option »boot = /dev/hda« eingerichtet. Die Swap-Partition wird als Raid 5 ausgelegt. Denkbar wäre es auch, drei einzelne Swap-Partitionen zu nutzen. Wer sehr großen Wert auf die Stabilität des Systems bei einem Plattenausfall legt, sollte Swap auf einen Raid-5-Verbund legen. Selbst wenn bei Benutzung des Swap eine Platte ausfällt, kommt der Kernel damit gut zurecht.

Während des Umbaus wird dem Kernel die aktuelle Systemplatte »hdc« als defekte dritte Platte im Raid-Array vorgetäuscht. Dieses Verfahren funktioniert auch mit zwei Festplatten beim Aufbau eines Raid 1.

Kernel-Optionen

Im Kernel 2.4 muss die Unterstützung für Multiple Devices aktiviert sein, wie in Abbildung 1 zu sehen. Zudem sollte das Root-Dateisystem fest in den Kernel eingebunden sein. Für die alten Kernel 2.0 und 2.2 gibt es unter[2] entsprechende Patches. Ist der Kernel fertig kompiliert und installiert, geht es an die Einrichtung und Verwaltung des Raid. Zur Auswahl stehen das Raid-Tools-Paket (Version 1.0,[4]) und das Programm »mdadm«[5]. Im folgenden Beispiel kommen die Raid-Tools zum Einsatz.

Abbildung 1: Im Kernel muss die Unterstützung für Multiple Devices aktiviert sein, das ist bei den meisten aktuellen Distributionen Standard.

Zum Abschluss der Vorarbeiten müssen Sie noch den Swap-Bereich per »swapoff -a« abschalten und danach den Eintrag in der Datei »/etc/fstab« auskommentieren. Auf den beiden Festplatten »hda« und »hdb« legen Sie mittels »fdisk« jeweils drei Partitionen mit dem Typ »0xfd Linux raid auto« an (Kasten “Partitionierung der Raid-Festplatten”). Am Partitionstyp erkennt der Kernel beim Booten, dass es sich um ein Software-Raid handelt.

Schritt für Schritt zum Raid 5

Die meisten Distributionen legen schon in der Grundinstallation die Gerätedateien »md0« bis »md255« an. Fehlen diese Einträge in »/dev«, müssen Sie die Gerätedateien entsprechend mit »mknod -m 0660 /dev/md X b 9 X« einrichten, Eigentümer ist »root«, die Gruppe »disk«. Nun legen Sie die Datei »/etc /raidtab« an, ein Beispiel dafür ist in Listing 1 zu finden.

01 #/etc/raidtab
02 # /boot md0 als RAID 5
03 
04 raiddev         /dev/md0  # Unter diesem Namen wird das Device angesprochen
05 raid-level             1  # Der eingesetzte RAID Level
06 nr-raid-disks          3  # Anzahl der im RAID Verbund enthaltenen Laufwerke
07 chunk-size            64  # Hat für RAID1 keine Bedeutung, muss aber vorh. sein
08 persistent-superblock  1  #Wird beim Booten der Platten benötigt
09 nr-spare-disks         0  #Hier kann eine Erstzplatte definiert werden
10 
11 device         /dev/hda1
12 raid-disk              0
13 
14 device         /dev/hdb1
15 raid-disk              1
16 
17 device         /dev/hdc1
18 #raid-disk             2  # wird nach dem Umbau benötigt
19 failed-disk            2  # Da hdc derzeit noch Systemplatte ist
20 
21 #-----------------------------------
22 # swap md1 als RAID 5
23 
24 raiddev         /dev/md1
25 raid-level             5
26 nr-raid-disks          3
27 chunk-size            64
28 parity-algorithm left-symmetric
29 persistent-superblock  1
30 nr-spare-disks         0
31 
32 device         /dev/hda2
33 raid-disk              0
34 
35 device         /dev/hdb2
36 raid-disk              1
37 
38 device         /dev/hdc2
39 #raid-disk             2
40 failed-disk            2
41 
42 #-----------------------------------
43 # /root md2 als RAID 5
44 
45 raiddev         /dev/md2
46 raid-level             5
47 nr-raid-disks          3
48 chunk-size            64
49 parity-algorithm left-symmetric
50 persistent-superblock  1
51 nr-spare-disks         0
52 
53 device         /dev/hda3
54 raid-disk              0
55 
56 device         /dev/hdb3
57 raid-disk              1
58 
59 device         /dev/hdc3
60 #raid-disk             2
61 failed-disk            2

Multiple Devices bilden

Mit dem Befehl »mkraid /dev/md0« entsteht aus dem ersten Teil der »/etc/ raidtab« das neue Raid 1 als »md0«, aber ohne die Partition »hdc1«, da sie in der Datei »/etc/raidtab« als permanent fehlerhaft markiert ist. In der Ausgabe erscheinen unter anderem die Größen der Partitionen »hda1«, »hdb1« und die Lage des Raid-Superblocks ab 200704 KByte. Der aktuelle Status eines Multiple Device kann jederzeit mit »cat /proc /mdstat« abgefragt werden und sollte zum jetzigen Zeitpunkt so wie in Listing 2 aussehen.

Die Multiple Devices »md1« und »md2« entstehen auf gleiche Weise. Anschließend formatieren Sie die Multiple Devices entsprechend, auf »md1« erzeugen Sie eine Swap-Partition und auf »md1« und »md2« je ein Ext 3. Damit Lilo das neue Root-System findet, wird das Root-Dateisystem in »/etc/lilo.conf« auf das Multiple Device »/dev/md2« gelegt (»root=/dev/md2«). Zu diesem Zeitpunkt darf der Eintrag »boot=/dev /md1« noch nicht verändert werden.

Daten auf das Raid kopieren

Fahren Sie das Linux-System in den Singleuser-Modus und mounten »md2« unter »/mnt/system« und »md0« unter »/mnt/boot«. Danach werden die Daten von der Systemplatte »hdc3« nach »/mnt /system« kopiert, beispielsweise mit dem Befehl »find. -xdev | cpio -pm /mnt /system«.

Löschen Sie den Inhalt des Verzeichnisses »/mnt/system/boot«, es dient später als Mountpoint, und kopieren Sie danach alle Einträge, inklusive der symbolischen Links, aus »/boot« nach »/mnt /boot«. Anschließend tauschen Sie in der Datei »/mnt/system/etc/fstab« die Einträge für »/dev/hdc1« gegen »/dev /md0«, »/dev/hda3« gegen »/dev/md2« sowie bei »swap« (immer noch auskommentiert) den Eintrag »/dev/hdc2« gegen »/dev/md1« aus.

Rufen Sie »lilo« auf, um die neue Konfiguration zu übernehmen, und fahren nach einem Neustart das System wieder im Singleuser-Modus hoch. Kontrollieren Sie, ob »md0« und »md2« korrekt gemountet wurden.

Reboot ins Raid

Zum Schluss ist noch »hdc« in das Raid einzubinden. Dazu partitionieren Sie »hdc« wie im Kasten “Partitionierung der Raid-Festplatten” beschrieben. In der Datei »/etc/raidtab« werden die »failed disk«-Einträge auskommentiert und die »raid-disk«-Einträge aktiviert. Die folgenden Kommandos

raidhotadd /dev/md0 /dev/hdc1
raidhotadd /dev/md1 /dev/hdc2
raidhotadd /dev/md2 /dev/hdc3

fügen die drei Partitionen in das Raid ein. Die nächsten Schritte sollten erst folgen, wenn die Platten mit dem Wiederherstellungsprozess fertig sind. Über den Fortgang gibt wieder »cat /proc/mdstat« Auskunft.

Als vorletzten Schritt ändern Sie den Boot-Eintrag in »/etc/lilo.conf« auf »boot=/dev/md0« und fügen die folgende Zeile ein:

raid-boot-extra=/dev/hda,/dev/hdb,/dev/hdc

Mit »lilo« werden die Änderungen übernommen. Anschließend können Sie Swap in »/etc/fstab« wieder aktivieren. Ein spannender Augenblick ist der nächste Reboot – damit sollten Sie aber in jedem Fall warten, bis der Rebuild des Raid abgeschlossen ist.

Mdadm oder Raid-Tools?

Bisher kamen immer nur die Raid-Tools zum Einsatz. Im Gegensatz zu diesem Paket, das aus mehren Programmen besteht, beherrscht das einzelne Programm »mdadm« alle nötigen Funktionen und kann notfalls auch ohne Konfigurationsdatei Raids anlegen. Welches der beiden das geeignetere Werkzeug ist, hängt vom Einsatzfall ab.

Die wohl interessantesten Features von »mdadm« sind: mit dem Parameter »–monitor« Multiple Devices überwachen und im Fehlerfall eine Mail an den Administrator schicken. Auch lässt sich automatisch ein Programm starten. Zudem liest »mdadm –examine /dev/md X« den Superblock des Raid aus.

Mysterium Raid-Superblock

Der Raid-Superblock wird beim Anlegen eines Multiple Device aus den Informationen der Datei »/etc/raidtab« erzeugt, wenn die Option »persistent-superblock« in dieser Datei auf »1« gesetzt ist. Während des Bootvorgangs sucht der Kernel auf allen angeschlossenen Platten nach diesen Raid-Superblöcken.

Mit den darin enthaltenen Informationen und dem Partitionstyp »0xfd – Linux raid autodetect« kann das System die entsprechenden Multiple Devices anschließend automatisch mounten. Der 4 KByte große Datenblock liegt am Beginn des letzten geraden 64-KByte-Blocks jeder Multiple-Device-Partition, es gehen also maximal 128 KByte der gesamten Kapazität einer Partition für den Superblock verloren.

Listing 3 zeigt den Inhalt des Superblocks, wie ihn der Befehl »mdadm –examine /dev/hda1« ausgibt. In Zeile 13 ist der Gesundheitszustand des Array abzulesen. Mit »no-errors« wird signalisiert, das alles in Ordnung ist. Der Eintrag »dirty« ist kein Grund nervös zu werden – es sind Daten vorhanden, die nur noch nicht geschrieben wurden. Wird das System sauber heruntergefahren, wird daraus »clean«.

Device    Boot    Start       End    Blocks   Id  System
/dev/hda1             1        25    200781   fd  Linux raid autodetect
/dev/hda2            26       148    987997+  fd  Linux raid autodetect
/dev/hda3           149       757    4891792+  fd  Linux raid autodetect

Festplatten-Recycling und Systemüberwachung

Wie werden Sie den Superblock wieder los? Diese Frage stellt sich, wenn Sie eine Festplatte aus einem Multiple- Device-Array ausbauen und danach erneut verwenden wollen. Mit dem Befehl »mdadm –zero-superblock /dev/hda1« entledigt man sich des Super-Kollegen. Alternativ tut es auch »dd if=/dev/zero of=/dev/hda1 bs=1 seek=200704 count=4«.

Mit dem letzten Befehl schreibt »dd« ab Position 200704 KByte auf »/dev/hda1« vier 1 KByte große Blöcke mit Nullen. Die genaue Position, in unserem Fall 200704 KByte, wird unter anderem beim Booten ausgegeben oder ist über den Raid-Superblock selbst zu ermitteln.

Wer ein Raid-System einsetzt, möchte natürlich im Fehlerfall durch eine Warnmeldung informiert werden. Das geht zum Beispiel per »mdadm« im Monitor-Modus, wie bereits erwähnt. Auch ein Blick in die Datei »/proc/mdstat«, ob nun per Skript oder von Hand, zeigt den Ausfall eines Multiple Device oder einer ganzen Platte an.

Eine weitere Möglichkeit ist es, das Syslog zu überwachen und beim Auftreten bestimmter Schlüsselwörter wie “Raid”, “md”, “superblock”, “resyncing” oder “recovery” den Administrator zu informieren. Benutzer des Monitoring-Tools Big Brother[6] können das Skript »bb-mdstat.sh« von[7] zum Überwachen eines Software-Raid nutzen.

Ausfall einer Platte

Beim Ausfall einer Festplatte ist natürlich ein selbstheilendes Raid wünschenswert. Wie auch die meisten Raid- Controller bietet das Software-Raid die Möglichkeit, eine Spare Disk (Hot Spare) einzusetzen. Mit der Spare Disk stellt der Kernel beim Ausfall einer Raid-Platte automatisch auf das freie Laufwerk um. Dazu müssen Sie bei den Raid-Tools die Datei »/etc/raidtab« anpassen.

Steht keine Spare Disk zur Verfügung, ist Handarbeit gefragt. Im oben eingerichteten Raid 5 wird dazu das System heruntergefahren und die defekte Festplatte gegen eine neue mit gleicher Partitionierung ausgetauscht. Nach dem Neustart des Systems ordnet »raidhotadd /dev /md X /dev/hd Y« die neue Festplatte dem Raid zu und nach einigen Minuten wird der Rebuild gestartet. Zum Schluss sei noch auf das Software-Raid-Howto[8] verwiesen. (mdö)

01 Personalities : [linear] [raid0] [raid1] [raid5] [multipath]
02 read_ahead 1024 sectors
03 md0 : active raid1 hdb1[1] hda1[0]
04       200704 blocks [3/2] [UU_]
05 
06 unused devices: <none>
07 handling MD device /dev/md1
08 analyzing super-block
09 disk 0: /dev/hda2, 987997kB, raid superblock at 987904kB
10 disk 1: /dev/hdb2, 987997kB, raid superblock at 987904kB
11 disk 2: /dev/hdc2, failed

01  /dev/hda1:
02            Magic : a92b4efc
03          Version : 00.90.00
04             UUID : 243e03bb:e3a486c3:ebf23ec9:fc518e36
05    Creation Time : Fri May  9 17:17:28 2003
06       Raid Level : raid1
07      Device Size : 200704 (196.00 MiB 205.52 MB)
08     Raid Devices : 3
09    Total Devices : 4
10  Preferred Minor : 0
11
12      Update Time : Fri May  9 21:57:15 2003
13            State : dirty, no-errors
14   Active Devices : 3
15  Working Devices : 3
16   Failed Devices : 1
17    Spare Devices : 0
18         Checksum : 16cd8686 - correct
19           Events : 0.25
20
21        Number   Major   Minor   RaidDevice State
22  this     0       3        1        0      active sync   /dev/hda1
23     0     0       3        1        0      active sync   /dev/hda1
24     1     1       3       65        1      active sync   /dev/hdb1
25     2     2      22        1        2      active sync   /dev/hdc1