Linux Installation auf einem SW Raid
Einleitung
Mit dieser kleinen Anleitung möchte ich es interessierten Usern etwas erleichtern, ihr System auf einem SW Raid zu installieren.
Ausgeführt habe ich die Installation bislang mehrfach unter SuSE 8.2 und 9.0, RedHat 9 und Fedora Core 1. Es sollte also unter jeder Distribution problemlos klappen.
Das Wissen über Bootloader, partitionieren von Festplatten, usw., setze ich hier mal voraus, es gibt dafür hier im Forum und auch im Web ausreichend Hilfe, Anleitungen und Dokumentationen. Ich will ja schließlich eine Anleitung und keinen Roman schreiben
Warum SW Raid?
1. Keine Mehrkosten für einen Raidcontroller. Da Linux von Hause aus alle nötigen Mittel für den Betrieb der Festplatten als Raid Array mitbringt, kann man sich in den meisten Fällen die Anschaffung des selbigen sparen.
2. Auf allen halbwegs modernen Mainboards für Standard PC's kann es durchaus, vor allem bei Raid 0 mit mehr als 2 Platten, dazu kommen, daß die Performance gegenüber einem PCI 32 Controller steigt, da moderne Festplatten mittlerweise so hohe Übertragungsraten erreichen, daß der PCI Bus schnell ausgereizt oder gar überfordert ist. Dazu kommen noch Leistungsbremsen wie IRQ-Sharing und ungünstiges IRQ Routing durch ein schlecht designetes Mainboard. Die P-ATA Anschlüsse moderner Chipsätze sind dagegen über deutlich schnellere Bussysteme (Hypertransport, Infiniband, ...) an Prozessor und Speicher angebunden.
3. Es können auf einem Festplattenverbund GLEICHZEITIG mehrere Arrays mit VERSCHIEDENEN Raid Leveln angelegt werden.
4. Die Festplatten erscheinen gegenüber dem Kernel im Gegensatz zu Arrays an einem Raid Kontroller nach wie vor als einzelne Platten, können also mit Tools wie smartd und hddtemp weiter überwacht werden.
Kleine Einschränkungen
1. Linux läßt sich derzeit nicht komplett direkt auf einen SW Raid installieren. Die Installer aller mir bekannten Distributionen verweigern vor allem das Anlegen von /boot auf einem SW Raid.
2. Als Bootloader ist derzeit nur der relativ veraltete lilo einsetzbar, grub kann mit SW Raid Bootpartitionen nicht umgehen.
Das Beispielsystem
Als Grundlage dient beispielhaft RedHat 9. Die Hardware:
- 3 festplatten Seagate Barracuda ATA V mit jeweils 60GB als hda, hdb und hdc
- hdd ist das DVD Rom
Die Partitionen:
- 1. Array Raid Level 1 mit 100MB als /boot
- 2. Array Raid Level 5 mit insgesamt 2GB als swap
- 3. Array Raid Level 5 mit insgesamt 8GB als /
- 4. Array Raid Level 5 mit dem Rest, als LVM
* LVM 1. Volume 15GB als /var
* LVM 2. Volume 15GB als /home
* LVM 3. Volume 35GB als /fileserver
* LVM Rest bleibt für die eventuelle Vergrößerung der Volumes bei Bedarf frei.
Die Partitionierung ist natürlich nur beispielhaft und auf die Bedürfnisse meines Servers ausgerichtet. Da muß jeder das für sich passende finden.
/boot habe ich deshalb mit 100MB angelegt, da ich ReiserFS verwende und RedHat basierte Distributionen als Mindestgröße für /boot bei der Installation auf ReiserFS eben diese 100MB verlangt, ist die Partition kleiner, verweigert Anaconda die Installation mit einer Fehlermeldung. Bei SuSE liegt die Mindestgröße, wenn ich mich richtig erinnere, bei etwa 75MB. Ursache für dieses Verhalten ist die Tatsache, daß ReiserFS mehr Platz für das Journal beansprucht, als es bei anderen Filesystemen der Fall ist, so ist jedenfalls mein Kenntnisstand.
/var hat 15GB, da bei RedHat basierten Distributionen hier u.a. die Daten des Apache und des FTP Servers abgelegt sind (/var/www und /var/ftp).
Zu beachten sind dabei die Unterschiede zwischen den einzelnen Raid Leveln.
Bei Raid Level 1 ist die Gesamtgröße des Arrays genau so groß, wie die Größe einer Partition im Array, in meinem Fall bleibt sie also bei 100MB, auch wenn ich noch 2 Platten dazunehmen würde.
Bei Raid Level 5 ist die Gesamtgröße wie die Summe aller Partitionen MINUS der Größe einer Partition. Das heißt, habe ich eine Partitionsgröße von 5GB, so beträgt die Gesamtgröße bei 3 Platten 10GB, bei 4 Platten 15GB, ...
Los geht's
Wie in Einschränkung 1 geschrieben, läßt sich Linux nicht komplett direkt auf ein SW Raid installieren. Man könnte nun alles außer /boot auf das Raid Array packen, ich mache es aber immer so, daß ich alles komplett auf eine einzelne Platte installiere und danach auf das Raid verlege.
Die Installation erfolgt auf Laufwerk hdc mit den Partitionen:
- hdc1 als /boot
- hdc2 als swap
- hdc3 als /
Die Größe spielt dabei keine Rolle (groß genug eben), ebenso wenig das Dateisystem. Als Bootloader wählen wir, wie schon gesagt, lilo. Dieser wird in den MBR von /dev/hda installiert, auch wenn die Platte leer ist.
Achtung!
Bei Fedora Core kann lilo nicht mehr bei der Installation ausgewählt werden, er muß nachinstalliert (per apt oder yum) und manuell konfiguriert werden. Hier mal eine /etc/lilo.conf, wie sie nach der Grundinstallation aussehen könnte:
Code:
change-rules
reset
prompt
read-only
timeout=50
default=Server
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
lba32
menu-title = "Frank's Server"
menu-scheme = "wk:Wg:wk:Gk"
image=/boot/vmlinuz-2.4.26
label=Server
append="enableapic acpi=on apm=off"
root=/dev/hdc3
vga=791
image = /boot/memtest.bin
label = Speichertest
Wichtig ist der Eintrag LBA32, da es sonst passieren kann, daß die Festplatte(n) evtl. im älteren CHS Modus betrieben werden. Hierbei würde zwar die gleiche Gesamtkapazität zur Verfügung stehen, aber man würde nicht gleichgroße Partitionen hinbekommen, da im LBA (Large Block Access) Modus die Plattengeometrie anders als die physikalische Geometrie im CHS (Cylinder Head Sektor) Modus interpretiert wird, die logischen Sektoren sind deutlich größer.
Ich selbst bevorzuge es, wie schon aus der lilo.conf ersichtlich ist, ohne initrd zu booten und alle dafür notwendigen Treiber fest in den Kernel zu kompilieren. Als da für diesen Fall wären:
- Dateisystem natürlich, ich bevorzuge seit Jahren ReiserFS
- LVM
- Raid 1
- Raid 5
Läuft die Grundinstallation, kann jetzt das Raid angelegt werden und das System umziehen.
Raid anlegen
Als erstes müssen wir die Datei /etc/raidtab anlegen und editieren, ich habe hier mal meine:
Code:
# /etc/raidtab by frankpr
# Array 1 - RAID1
# boot
raiddev /dev/md0
raid-level 1
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
chunk-size 4
device /dev/hda1
raid-disk 0
device /dev/hdb1
raid-disk 1
device /dev/hdc1
failed-disk 2
##########################
# Array 2 - RAID5
# swap
raiddev /dev/md1
raid-level 5
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 128
device /dev/hda2
raid-disk 0
device /dev/hdb2
raid-disk 1
device /dev/hdc2
failed-disk 2
##########################
# Array 3 - RAID5
# root
raiddev /dev/md2
raid-level 5
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 128
device /dev/hda3
raid-disk 0
device /dev/hdb3
raid-disk 1
device /dev/hdc3
failed-disk 2
##########################
# Array 4 - RAID5
# LVM
raiddev /dev/md3
raid-level 5
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 128
device /dev/hda4
raid-disk 0
device /dev/hdb4
raid-disk 1
device /dev/hdc4
failed-disk 2
##########################
Wichtig sind hier die Einträge failed-disk 2. Wir machen uns hier ganz einfach eine Eigenheit des SW Raid zu Nutze und legen die Arrays gleich mit einer defekten Festplatte an, da ja auf /dev/hdc die Grundinstallation ist.
Das erste Array für /boot ist als Raid 1 anzulegen, da lilo nur diesen Raid Level unterstützt.
Jetzt können /dev/hda und /dev/hdc partitioniert werden, wie weiter oben beschrieben, sollten sich die Platten im LBA Modus befinden. Ist die nicht der Fall, kann dies mit fdisk geändert werden (korrekte Werte für LBA Modus unter Anzahl Köpfe, Zylinder und Sektoren/Spur eintragen und Partitionstabelle neu schreiben). Die nötigen Angaben findet man je nach Produkt entweder auf der Platte aufgedruckt, auf der Webseite des Herstellers, die Angaben im BIOS des Rechners differenzieren je nach Mainboard, selbst auf modernen Mainboards habe ich schon die Werte für den CHS Modus gesehen, obwohl die Platte eindeutig im LBA Modus lief. Das ist dann auf deutsch gesagt Inkonsquenz des Mainboardherstellers.
Als Partitionstyp muß der Hexwert FD angegeben werden (Linux Raid).
Die Arrays werden nun mit
mkraid --really-force /dev/md0
mkraid --really-force /dev/md1
mkraid --really-force /dev/md2
mkraid --really-force /dev/md3
angelegt.
LVM anlegen
Als erstes muß ein Physical Volume (PV) angelegt werden
pvcreate /dev/md3.
Kommt es hier zu einer Fehlermeldung, so fehlt die Datei /etc/lvmtab. Ein vgscan left diese Datei an. Danach pvcreate einfach noch einmal wiederholen.
Jetzt wird die Volumegroup (VG) angelegt
vgcreate LVMroot /dev/md3.
Der Name ist frei wählbar, ich habe mich wegen der Eindeutigkeit für den Namen entschieden, den auch SuSE Linux in YaST vorschlägt.
Nun können die einzelnen Volumes angelegt werden
lvcreate -L 15G -n var LVMroot
lvcreate -L 15G -n home LVMroot
lvcreate -L 35G -n fileserver LVMroot.
Ein vgdisplay LVMroot zeigt den Zustand der Volumegroup an
Code:
vgdisplay LVMroot
--- Volume group ---
VG Name LVMroot
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 3
Open LV 3
MAX LV Size 255.99 GB
Max PV 256
Cur PV 1
Act PV 1
VG Size 101.59 GB
PE Size 4 MB
Total PE 26006
Alloc PE / Size 16640 / 65 GB
Free PE / Size 9366 / 36.59 GB
VG UUID 6B6T7s-ZW83-TCfx-mx6r-AU8I-qXSq-RuHBdR
Nun können die Dateisysteme formatiert werden, wie gesagt, ich persönlich bevorzuge ReiserFS.
mkreiserfs /dev/md0
mkreiserfs /dev/md2
mkreiserfs /dev/LVMroot/var
mkreiserfs /dev/LVMroot/home
mkreiserfs /dev/LVMroot/fileserver
mkswap -c /dev/md1
System kopieren
Nun werden die neuen Arrays gemountet, das im Beispiel gewählte Verzeichnis sollte leer sein: mount /dev/md2 /mnt mountet zuerst die neue Rootpartition.
Jetzt die nötigen Verzeichnisse anlegen:
mkdir /mnt/boot
mkdir /mnt/var
mkdir /mnt/home
mkdir /mnt/fileserver
mkdir /mnt/proc
und alles mounten
mount /dev/md0 /mnt/boot
mount /dev/LVMroot/var /mnt/var
mount /dev/LVMroot/home /mnt/home
mount /dev/LVMroot/fileserver /mnt/fileserver
Ein rsync -av / /mnt --exclude /mnt --exclude /proc kopiert das gesamte System auf die Raid Arrays. Die --exclude Optionen bedeuten:
--exclude /mntverhindert, daß der Kopiervorgang in eine Endlosschleife gerät
--exclude /procschließt /proc aus, da dessen Inhalt zur Laufzeit von System angelegt wird und teilweise auch kein Zugriff darauf besteht, der Kopiervorgang würde dann mit einer Fehlermeldung abbrechen.
So, jetzt die Datei /mnt/etc/fstab an die neuen Gegebenheiten anpassen:
Code:
/dev/md2 / reiserfs defaults 1 1
/dev/md0 /boot reiserfs defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/md1 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/LVMroot/var /var reiserfs defaults 1 2
/dev/LVMroot/home /home reiserfs defaults 1 2
/dev/LVMroot/fileserver /fileserver reiserfs defaults 1 2
usbdevfs /proc/bus/usb usbdevfs noauto 0 0
Als nächstes die Dateien /etc/lilo.conf und /mnt/etc/lilo.conf anpassen, dabei beachten, daß als Speicherort weiterhin noch /dev/hda angegeben ist:
Code:
change-rules
reset
prompt
read-only
timeout=50
default=Server
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
lba32
menu-title = "Frank's Server"
menu-scheme = "wk:Wg:wk:Gk"
image=/boot/vmlinuz-2.4.26
label=Server
append="enableapic acpi=on apm=off"
root=/dev/md2
vga=791
image = /boot/memtest.bin
label = Speichertest
und die neue /boot Partition mounten und lilo neu installieren:
umount /boot
mount /dev/md0 /boot
lilo
Jetzt ist es so weit, es kann das erste Mal vom Raid gebootet werden, das sollte auch problemlos funktionieren.
Der Abschluß
Wurde das System auf Herz und Nieren geprüft und alles läuft, kann die 3 festplatte eingebunden werden.
Dazu wird sie zuerst neu partitioniert, ein fdisk -l verschafft noch einmal einen Überblick über die beiden anderen Platten:
Code:
fdisk -l
Platte /dev/hdc: 60.0 GByte, 60022480896 Byte
255 Köpfe, 63 Sektoren/Spuren, 7297 Zylinder
Einheiten = Zylinder von 16065 * 512 = 8225280 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp
/dev/hdc1 1 13 104391 fd Linux raid autodetect
/dev/hdc2 14 144 1052257+ fd Linux raid autodetect
/dev/hdc3 145 666 4192965 fd Linux raid autodetect
/dev/hdc4 667 7297 53263507+ fd Linux raid autodetect
Platte /dev/hda: 60.0 GByte, 60022480896 Byte
255 Köpfe, 63 Sektoren/Spuren, 7297 Zylinder
Einheiten = Zylinder von 16065 * 512 = 8225280 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp
/dev/hda1 * 1 13 104391 fd Linux raid autodetect
/dev/hda2 14 144 1052257+ fd Linux raid autodetect
/dev/hda3 145 666 4192965 fd Linux raid autodetect
/dev/hda4 667 7297 53263507+ fd Linux raid autodetect
Platte /dev/hdb: 60.0 GByte, 60022480896 Byte
255 Köpfe, 63 Sektoren/Spuren, 7297 Zylinder
Einheiten = Zylinder von 16065 * 512 = 8225280 Bytes
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp
/dev/hdb1 * 1 13 104391 fd Linux raid autodetect
/dev/hdb2 14 144 1052257+ fd Linux raid autodetect
/dev/hdb3 145 666 4192965 fd Linux raid autodetect
/dev/hdb4 667 7297 53263507+ fd Linux raid autodetect
Anschließend wird die Datei /etc/raidtab in die endgültige Form gebracht, d.h., die failed-disk Einträge werden ersetzt:
Code:
# /etc/raidtab by frankpr
# Array 1 - RAID1
# boot
raiddev /dev/md0
raid-level 1
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
chunk-size 4
device /dev/hda1
raid-disk 0
device /dev/hdb1
raid-disk 1
device /dev/hdc1
raid-disk 2
##########################
# Array 2 - RAID5
# swap
raiddev /dev/md1
raid-level 5
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 128
device /dev/hda2
raid-disk 0
device /dev/hdb2
raid-disk 1
device /dev/hdc2
raid-disk 2
##########################
# Array 3 - RAID5
# root
raiddev /dev/md2
raid-level 5
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 128
device /dev/hda3
raid-disk 0
device /dev/hdb3
raid-disk 1
device /dev/hdc3
raid-disk 2
##########################
# Array 4 - RAID5
# LVM
raiddev /dev/md3
raid-level 5
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 128
device /dev/hda4
raid-disk 0
device /dev/hdb4
raid-disk 1
device /dev/hdc4
raid-disk 2
##########################
Nun können die Partitionen der 3. Platte in die Arrays eingebunden werden:
raidhotadd /dev/md0 /dev/hdc1
raidhotadd /dev/md1 /dev/hdc2
raidhotadd /dev/md2 /dev/hdc3
raidhotadd /dev/md3 /dev/hdc4
Die Arrays werden nun synchronisiert, der Vorgang kann bei großen Partitionen bis zu einer Stunde dauern und mit cat /proc/mdstat verfolgt werden. Das System ist in dieser Zeit übrigens voll verfügbar, Arbeiten daran verlängern allerdings die Zeit für das Synchronisieren.
Ist das erledigt, wird /etc/lilo.conf in die endgültige Form gebracht
Code:
change-rules
reset
prompt
read-only
timeout=50
default=Server
boot=/dev/md0
map=/boot/map
install=/boot/boot.b
lba32
menu-title = "Frank's Server"
menu-scheme = "wk:Wg:wk:Gk"
raid-extra-boot = /dev/hda,/dev/hdb,/dev/hdc
image=/boot/vmlinuz-2.4.26
label=Server
append="enableapic acpi=on apm=off"
root=/dev/md2
vga=791
image = /boot/memtest.bin
label = Speichertest
und lilo neu installiert. Die Option raid-extra-boot dient dazu, den Bootloader in den MBR aller 3 Platten zu schreiben, denn was nützt ein Raid, wenn /dev/hda ausfällt und das System nicht mehr booten kann.
Damit ist die gesamte Aktion beendet.
lilo Besonderheiten
Die lilo Versionen, die mit RedHat Linux bzw. Fedora Core ausgeliefert werden, kennen die Option raid-extra-boot nicht, sie sind entweder kastriert oder zu alt. Ich habe deshalb das src.rpm für lilo von SuSE 9.0 (z.B. auf den SuSE FTP Servern zu finden) genommen und lilo neu kompiliert. Dieser Version kennt die Option.
Dabei ist es wichtig zu wissen, daß zum Kompilieren ein Assembler installiert sein muß (Paket dev86-version.rpm), der bei Fedora Core 1 fehlt. Das nötige Paket läßt sich aber über www.rpmfind.net beschaffen, gleich der erste Treffer in der Ergebnisliste war der richtige.
Änderung am System durchgeführt und vergessen, lilo neu zu installieren, was tun?
-das Rescue System der entsprechenden Distribution oder Knoppix von CD/DVD booten
-mount /dev/md2 /mnt
-umount /boot
-mount /dev/md0 /boot
-cp /mnt/etc/lilo.conf /etc
-lilo
installiert lilo neu.
Hilfsmittel
mdadmd
Mit diesem Programm kann der Zustand der Arrays überwacht werden und eine Benachrichtigung per Mail konfiguriert werden. Die Syntax der Konfigurationsdatei /etc/mdadmd.conf ist in dieser selbst erklärt, hier ist meine:
Code:
# mdadm configuration file
DEVICE /dev/hda* /dev/hdb* /dev/hdc*
ARRAY /dev/md0 UUID=355f1416:4f961c68:cc01bcbe:7b2ae7a1
ARRAY /dev/md1 UUID=7ad24eef:bfb49b58:4361f7cc:85d911c9
ARRAY /dev/md2 UUID=dd6f6030:6ca256d0:58830428:ac4bb140
ARRAY /dev/md3 UUID=aced93f3:9813480a:728d14da:7178e7f6
MAILADDR root@localhost
#PROGRAM /usr/sbin/handle-mdadm-events
Die benötigten UUID's der Arrays können mit mdadm -D device ermittelt werden, ein Beispiel:
Code:
mdadm -D /dev/md0
/dev/md0:
Version : 00.90.00
Creation Time : Fri May 21 21:26:11 2004
Raid Level : raid1
Array Size : 104320 (101.88 MiB 106.82 MB)
Device Size : 104320 (101.88 MiB 106.82 MB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Sun May 23 17:33:28 2004
State : dirty, no-errors
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Number Major Minor RaidDevice State
0 3 1 0 active sync /dev/hda1
1 3 65 1 active sync /dev/hdb1
2 22 1 2 active sync /dev/hdc1
UUID : 355f1416:4f961c68:cc01bcbe:7b2ae7a1
Events : 0.25
smartd
S.M.A.R.T überwacht den Zustand der festplatten und meldet jeden Fehler (defekte Blöcke, dramatische Temperaturanstiege, ...) an das System. Voraussetzung:
-die Festplatten müssen S.M.A.R.T interstützen
-smartd muß installiert und konfiguriert werden
Die Syntax der Konfigurationsdatei erfährt man per man smartd.conf, hier ist meine Datei:
Code:
# configuration file for smartd. See man smartd.conf.
# Home page is: http://smartmontools.sourceforge.net
/dev/hda -a -m root@localhost
/dev/hdb -a -m root@localhost
/dev/hdc -a -m root@localhost
/proc
Ein cat /proc/mdstat zeigt den aktuellen Zustand der Raid Arrays an:
Code:
cat /proc/mdstat
Personalities : [raid1] [raid5]
read_ahead 1024 sectors
md0 : active raid1 hdc1[2] hdb1[1] hda1[0]
104320 blocks [3/3] [UUU]
md1 : active raid5 hdc2[2] hdb2[1] hda2[0]
2104320 blocks level 5, 128k chunk, algorithm 2 [3/3] [UUU]
md2 : active raid5 hdc3[2] hdb3[1] hda3[0]
8385792 blocks level 5, 128k chunk, algorithm 2 [3/3] [UUU]
md3 : active raid5 hdc4[2] hdb4[1] hda4[0]
106526720 blocks level 5, 128k chunk, algorithm 2 [3/3] [UUU]
unused devices:
Hier zu sehen ist der Idealzustand, alles ist in Ordnung. Im Fehlerfall wird dieser normalerweise recht verständlich angezeigt, wichtig ist das Zeilenende:
[UUU] steht für die 3 Festplatten, wäre z.B. hdb defekt, stünde dort [U_U].
So, das wäre es mit der kleinen Anleitung, ich hoffe, sie hilft jemanden.
Vieles, was ich hier beschrieben habe, läßt sich unter SuSE Linux natürlich auch per YaST erledigen, aber:
1. lernt man da nicht viel
2. wäre den Nutzern anderer Distributionen mit einer YaST- basierten Anleitung nicht geholfen.
Viel Spaß
MfG
Lesezeichen