|
Eine existierende HOWTO beschäftigt sich bereits mit dem Thema,
allerdings ist Sie erstens auf Englisch und zweitens geht es durch
neue Kerneloptionen auch eleganter als dort beschrieben.
Bitte erleichtern Sie sich Ihre Arbeit und senken Sie das
Frustniveau, indem Sie vorab noch drei Tipps beherzigen:
-
Erstellen Sie ein Backup Ihrer Daten.
-
Erstellen Sie sowohl eine funktionierende und getestete DOS als
auch Linux Bootdiskette.
-
Lesen Sie diese Ausführungen erst mal komplett durch, bevor Sie
mittendrin feststellen müssen, etwas wichtiges vergessen zu haben,
das Sie zu so spätem Zeitpunkt nicht mehr nachholen können.
Für dieses Verfahren wird noch eine DOS oder Win95 Partition in
Verbindung mit dem Loadlin benötigt. Loadlin befindet sich - so das
Programm nicht schon eingesetzt wird - auf der ersten DLD CD unter
/delix/RPMS/i386/loadlin-1.6.2.i386.rpm. Alternativ kann man sich
auch eine Bootdiskette anfertigen.
Der Hintergrund ist ganz einfach der, dass LILO mit dem RAID-Device
nicht zurechtkommt und man somit nicht explizit von diesem RAID-Device
booten kann. Daher behilft man sich hier entweder mit Loadlin, oder
aber mit einem Mini Linux auf einer kleinen Extra-Partition. Weitere
Möglichkeiten zum Booten von Linux auch von RAID-Verbunden wurden
bereits im Abschnitt Möglichkeiten des Bootens von Linux
behandelt.
Nichts desto trotz bleiben wir bei dem Verfahren mit Loadlin. Das
Programm befindet sich nach erfolgreicher Installation des
RPMS-Paketes unter /dos/loadlin/. Auf der oben genannten nötigen DOS
Partition richtet man sich nun ein Verzeichnis wie z.B. Linux ein und
kopiert die Dateien loadlin.bat und loadlin.exe zusammen mit dem
frischen Kernel, in den die RAID-Parameter einkompiliert wurden,
hinein.
Um sicherzugehen, dass auch wirklich nichts passiert, sollte man
entweder die nötigen Treiber für den (E)IDE Kontroller oder des
passenden SCSI Kontroller auch mit in den Kernel einkompiliert
haben.
Die Batchdatei loadlin.bat wird nun dahingehend angepasst, dass wir die
Parameter für das zu bootende RAID-Device gleich mit angeben:
linux.bat
|
md=<md device no.>,<raid level>,<chunk
size>,dev0,...,devn
|
md device no
Die Nummer des RAID (md) Devices: 1 steht für /dev/md1, 2
für /dev/md2 usw.
raid level
Welches RAID Level wird verwendet: -1 für Linear Modus, 0
für RAID-0 (Striping).
chunk size
Legt die Chunk Size fest bei RAID-0 und
RAID-1 fest.
dev0-devn
Eine durch Kommata getrennte Liste von Devices, aus denen das md
Device gebildet wird, z.B.
/dev/hda1,/dev/hdc1,/dev/sda1.
Andere RAID-Modi außer Linear und RAID-0 werden im Moment nicht
unterstützt. Gemäß der vorher beschriebenen Anleitung würde die Zeile
in der linux.bat dann so aussehen:
linux.bat
|
c:\linux\loadlin c:\linux\zimage root=/dev/md0
md=0,0,0,0,/dev/sda6,/dev/sdb6 ro
|
Dies soll nur eine einzige Zeile sein; außerdem ist auch hier wieder
auf die richtige Reihenfolge der Partitionen zu achten. Weiterhin
müssen natürlich zwei oder mehrere Partitionen - zu entweder einem
RAID-0 oder einem Linear Device zusammengefasst - bereits vorliegen.
Der Kernel muss die o.a. Bootoption und die nötigen RAID oder Linear
Parameter in den Kernel einkompiliert haben; man beachte: Nicht als
Module. Dann mountet man das RAID-Device, welches später die
Root-Partition werden soll, nach z.B. /mnt, kopiert mittels einer der
im Abschnitt
Möglichkeiten zum Kopieren von Daten beschriebenen
Methoden die benötigten Verzeichnisse auf das RAID-Device.
Speziell für die DLD 6.0, aber auch für alle anderen Distributionen
sei hier gesagt, dass beim Booten von einem RAID-Device der oben
beschriebene Befehl mdadd -ar vor dem ersten mount Befehl auszuführen
ist. Für die DLD 6.0 heißt das konkret, dass der Befehl bereits in das
Skript /etc/init.d/bc.mount_root eingetragen werden muss, da dort der
erste mount Befehl ausgeführt wird. Benutzer anderer Distributionen
sind hier auf sich gestellt oder schauen sich zur Not die Methode mit
den neuen RAID-Tools Version 0.9x an; siehe Abschnitt
RAID-Verbunde mit den RAID-Tools Version 0.9x erstellen.
Jetzt fehlen nur noch die passenden Einträge in /etc/fstab und
/etc/lilo.conf, in denen man auf dem neuen RAID-Device die
ursprüngliche Root-Partition in /dev/md0 umändert - im Moment liegen
diese Dateien natürlich noch unter /mnt.
An dieser Stelle sollte man die obige Liste noch einmal in Ruhe
durchsehen, sich vergewissern, dass alles stimmt, und dann die DOS oder
Win95 Partition booten. Dort führt man nun die Batchdatei
linux.bat aus.
|
Im Abschnitt RAID-Verbunde mit den RAID-Tools Version
0.9x erstellen wurde bereits auf die vorzügliche Eigenschaft des
automatischen Erkennens von RAID-Devices durch den Kernel-Patch beim
Startup des Linuxsystems hingewiesen. Dieser Umstand legt die
Vermutung nahe, dass es mit dieser Hilfe noch einfacher ist, die
Root-Partition als RAID-Device laufen zu lassen. Das ist auch wirklich so,
allerdings gibt es auch hierbei immer noch einige Kleinigkeiten zu
beachten. Generell kann man Linux entweder mittels Loadlin oder mit
Hilfe von LILO booten. Je nach Bootart ist die Vorgehensweise
unterschiedlich aufwendig.
Für beide Fälle braucht man jedoch erst mal ein RAID-Device. Um bei dem
Beispiel des RAID-0 Devices mit den Partitionen /dev/sda6 und
/dev/sdb6 zu bleiben, nehmen wir dieses Device und mounten es in
unseren Verzeichnisbaum.
Hier muss allerdings noch einmal darauf hingewiesen werden, dass ein
RAID-0 Device als Root-Partition ein denkbar schlechtes Beispiel ist.
RAID-0 besitzt keinerlei Redundanz; fällt eine Festplatte aus, ist das
Ganze RAID im Eimer. Für eine Root-Partition sollte man deshalb auf
jeden Fall ein RAID-1 oder RAID-5 Device vorziehen. Auch das
funktioniert Dank der neuen Autodetect Funktion und wird analog dem
beschriebenen RAID-0 Verbund eingerichtet.
Auf das gemountete RAID-Device /dev/md0 kopiert man nun ganz simpel
mittels einer der im Abschnitt Möglichkeiten zum Kopieren von Daten
beschriebenen Methoden das komplette Root-Verzeichnis.
Danach muss auf dem RAID-Device noch die Datei /etc/fstab so angepasst
werden, das als Root-Partition /dev/md0 benutzt wird und nicht mehr
die originale Root-Partition.
Erstellen Sie sich eine DOS-Bootdiskette - das pure DOS von Win95 tut
es auch - und auf dieser ein Verzeichnis Linux. Hierher kopieren Sie
nun aus dem passenden RPM-Paket Ihrer Distribution das DOS-Tool
loadlin und Ihren aktuellen Kernel. Manchmal befindet sich loadlin
auch unkomprimiert im Hauptverzeichnis der Distributions-CD. Der
Kernel sollte natürlich die RAID-Unterstützung bereits implementiert
haben. Nun erstellen Sie mit Ihrem Lieblingseditor in dem neuen Linux
Verzeichnis eine loadlin.bat. Haben Sie Ihren Kernel z.B. vmlinuz
genannt, sollte in der Datei loadlin.bat etwas in dieser Art stehen:
loadlin.bat
|
a:\linux\loadlin a:\linux\vmlinuz root=/dev/md0 ro vga=normal
|
Die Pfade müssen natürlich angepasst werden. Ein Reboot und das Starten
von der Diskette mit der zusätzlichen Ausführung der linux.bat sollte
Ihnen ein vom RAID-Device gebootetes Linux bescheren. Booten Sie
generell nur über Loadlin, so endet für Sie hier
die Beschreibung.
Möchten Sie allerdings Ihr neues Root-RAID mittels LILO booten, finden
Sie im Abschnitt Möglichkeiten des Bootens von Linux diverse
Methoden aufgelistet und teilweise sehr genau beschrieben, mit denen
Sie sich noch bis zum endgültigen Erfolg beschäftigen müssten.
|
Hat man sich bei einer anderen Distribution als SuSE 6.2 für einen
Root-RAID Verbund entschieden, der im Fehlerfall auch von der zweiten
Festplatte booten soll, muss man noch folgendes beachten: Da auch auf
der zweiten Festplatte eine Boot-Partition benötigt wird, die zwar
ebenso in der /etc/fstab aufgenommen wurde, aber im Fehlerfall nicht
mehr vorhanden ist, fällt die SuSE 6.2 Distribution in einen
Notfall-Modus, in dem das root-Paßwort eingegeben werden muss und
das fragliche Dateisystem repariert werden soll. Dies kann Ihnen auch
bei anderen Distributionen passieren.
Es wird also ein Weg benötigt, die beiden Boot-Partitionen /boot und
/boot2 nur dann zu mounten, wenn sie tatsächlich körperlich im Rechner
vorhanden sind. Hierbei hilft ihnen das Skript mntboot:
mntboot
|
#!/bin/sh
MNTBOOTTAB=/etc/mntboottab
case "$1" in
start)
[ -f $MNTBOOTTAB ] || {
echo "$0: *** $MNTBOOTTAB: not found" >&2
break
}
PARTS=`cat $MNTBOOTTAB`
for part in $PARTS ; do
[ "`awk '{print $2}' /etc/fstab | grep "^$part$"`" == "" ] && {
echo "$0: *** Partition $part: not in /etc/fstab" >&2
continue
}
[ "`awk '{print $2}' </proc/mounts | grep "^$part$"`" != "" ] && {
echo "$0: *** Partition $part: already mounted" >&2
continue
}
fsck -a $part
[ $? -le 1 ] || {
echo "$0: *** Partition $part: Defect? Unavailable?" >&2
continue
}
mount $part || {
echo "$0: *** Partition $part: cannot mount" >&2
continue
}
done
exit 0
;;
*)
echo "usage: $0 start" >&2
exit 1
;;
esac
|
Das Skript gehört bei SuSE Distributionen nach /sbin/init.d, bei
vermutlich allen anderen Linux Distributionen nach /etc/rc.d/init.d.
Auf das Skript sollte ein symbolischer Link
/sbin/init.d/rc2.d/S02mntboot zeigen. Für alle anderen gilt es hier
einen Link nach /etc/rc.d/rc3.d/S02mntboot zu setzen, da außer den
SuSE Distributionen wohl alle im Runlevel 3 starten und Ihre Links
dafür in diesem Verzeichnis haben. Das Skript prüft ein paar
Nebenbedingungen für diejenigen Partitionen, die in /etc/mntboottab
eingetragen sind (darin sollten /boot und /boot2 stehen) und ruft
jeweils fsck und mount für diese Partitionen auf. Da es bei allen
anderen Distributionen keine /etc/mntboottab gibt, gilt es hier diese
zu erstellen oder anzupassen.
In der /etc/fstab sollten diese Partitionen mit noauto statt
defaults eingetragen werden. Außerdem muss im sechsten Feld der Wert
0 stehen, da die Distribution im Backup-Fall sonst in den
Notfall-Modus fällt.
|
|
Sie überlegen sich, RAID auch für Swap Partitionen einzurichten? Diese
Mühe können Sie sich sparen, denn der Linux-Kernel unterstützt ein
RAID-Verhalten auf Swap-Partitionen ähnlich dem RAID-0 Modus quasi
von Haus aus. Legen Sie einfach auf verschiedenen Festplatten ein
paar Partitionen an, ändern Sie den Partitionstyp mittels
root@linux ~#
fdisk /dev/Ihre-Partition
|
und der Option t auf 82 und erstellen Sie das Swap Dateisystem:
root@linux ~#
mkswap /dev/Ihre-neue-Swap-Partition
|
Nun fügen Sie diese in die /etc/fstab ein und geben allen
Swap-Partitionen dieselbe Priorität.
fstab
|
/dev/hda3 swap swap defaults,pri=1 0 0
/dev/hdb3 swap swap defaults,pri=1 0 0
/dev/sda4 swap swap defaults,pri=1 0 0
|
Vom nächsten Startup an werden die Swap Partitionen wie ein RAID-0
Device behandelt, da die Lese- und Schreibzugriffe ab jetzt
gleichmäßig über die Swap-Partitionen verteilt werden.
Will man aus irgendwelchen Gründen zwei Swap-Partitionen höher
priorisieren als eine Dritte, so kann man das auch über den Parameter
pri= ändern, wobei die Priorität einen Wert zwischen 0 und 32767
annehmen kann. Ein höherer Wert entspricht einer höheren Priorität. Je
höher die Priorität desto eher wird die Swap-Partition beschrieben.
Bei der folgenden Konfiguration würde also /dev/hda3 wesentlich
stärker als Swap-Partition genutzt werden als /dev/hdb3.
fstab
|
/dev/hda3 swap swap defaults,pri=5 0 0
/dev/hdb3 swap swap defaults,pri=1 0 0
|
|
Erstellt man die Swap-Partition auf einem vorhandenen RAID-1 Verbund,
formatiert sie dann mittels mkswap /dev/mdx und trägt sie als
Swap-Partition in die /etc/fstab ein, so hat man zwar keinen, oder nur
einen kleinen lesenden Geschwindigkeitsvorteil, jedoch den großen,
nicht zu unterschätzenden Vorteil, dass man bei einem Festplattendefekt
nach dem Ausschalten des Rechners und dem Austausch der defekten
Festplatte, ohne weitere manuelle Eingriffe wieder ein vollständig
funktionierendes System hat. Der einzige Wermutstropfen betrifft
hierbei die Freunde des Hot Plugging. Erfahrungsgemäß verkraftet
Linux das Hot Plugging eines dermaßen gestalteten RAID-1 Verbundes
nur, wenn vorher die Swap-Partitionen mittels swapoff -a abgeschaltet
wurden.
Als Warnung seien hier aber noch zwei der schlimmsten Fälle genannt,
über die man sich Gedanken machen sollte und die noch dazu voneinander
abhängig sind:
Der erste Fall beschreibt die Situation, Swap auf einem RAID-1 Verbund
mit den alten RAID-Tools und damit den sowohl in den 2.0.xer als auch
in den 2.2.xer original im Kernel vorhandenen RAID Treibern zu
benutzen. Hierbei können nach einer gewissen Laufzeit des
Linuxsystems unweigerliche Abstürze auftreten. Der Grund dafür liegt in der
Problematik der unterschiedlichen Cachestrategie von Software-RAID
einerseits und Swap-Partitionen andererseits. Erst mit den aktuellen
RAID-Treibern ist der Betrieb einer Swap-Partition auf einem
RAID-Verbund stabil geworden. Wollen Sie also einen sicheren RAID-Verbund
erstellen, der nachher aus Gründen der Ausfallsicherheit auch die
Swap-Partition beinhalten soll, benutzen Sie bitte immer die aktuellen
RAID-Treiber in Form des aktuellen RAID-Patches. Dies entspricht dann
der Einrichtfunktionalität der RAID-Tools Version 0.9x.
Der zweite Fall beschreibt die generelle Problematik, mit der Sie sich
bei der Einrichtung von Swap-Partitionen in Bezug auf Software-RAID
auseinandersetzen müssen:
Hat man die Swap-Partition auf einen RAID-1 Verbund gelegt und
zusätzlich dafür eine Spare-Disk reserviert, würde diese Spare-Disk
natürlich bei einem Festplattendefekt sofort eingearbeitet werden. Das
ist zwar erwünscht und auch so gedacht, jedoch funktioniert das
Resynchronisieren dieses RAID-1 Verbundes mit einer aktiven
Swap-Partition nicht. Die Software-RAID Treiber nutzen beim
Resynchronisieren den Puffer-Cache, die Swap-Partition aber nicht. Das
Ergebnis ist eine defekte Swap-Partition.
Als Lösung bleibt nur die Möglichkeit, keine Spare-Disks zu benutzen
und nach einem Festplattenausfall swapoff -a per Hand auszuführen, die
defekte Festplatte auszutauschen und nach dem Erstellen der
Partitionen und des Swap-Dateisystems mit swapon -a wieder zu
aktivieren.
Ein Problem bleibt dennoch: Gesetzt den Fall der Linux-Rechner würde
aufgrund eines Stromausfalls nicht sauber heruntergefahren worden
sein, so werden die RAID-Verbunde beim nächsten Startup automatisch
resynchronisiert. Dies erfolgt mit einem automatischen ge-nice-ten
Aufruf des entsprechenden RAID-Daemons im Hintergrund bereits zu
Anfang der Bootprozedur. Im weiteren Bootverlauf werden aber
irgendwann die Swap-Partitionen aktiviert und treffen auf ein nicht
synchronisiertes RAID. Das Aktivieren der Swap-Partitionen muss also
verzögert werden, bis die Resynchronisation abgeschlossen ist.
Wie unter Linux üblich lässt sich auch dieses Problem mit einem Skript
lösen. Der Gedanke dabei ist, den Befehl swapon -a durch ein Skript
zu ersetzen, welches die Pseudodatei /proc/mdstat nach der
Zeichenfolge resync= durchsucht und im Falle des Verschwindens dieser
Zeichenfolge die Swap-Partitionen aktiviert. Im folgenden finden Sie
ein Beispiel dazu abgedruckt:
swapon -a
|
#!/bin/sh
#
RAIDDEVS=`grep swap /etc/fstab | grep /dev/md|cut -f1|cut -d/ -f3`
for raiddev in $RAIDDEVS
do
# echo "testing $raiddev"
while grep $raiddev /proc/mdstat | grep -q "resync="
do
# echo "`date`: $raiddev resyncing" >> /var/log/raidswap-status
sleep 20
done
/sbin/swapon /dev/$raiddev
done
exit 0
|
|
|
|
|