 |
|
zeropage is © by the L13-Crew, all part of TUI-NET
|
|
 |
 |
|
RAID unter Linux - aber welches?
Siehe auch: RAID - Grundlagen
Eine der häufigsten Ursachen für Systemausfälle ist eine defekte Festplatte. An sich kein Wunder, so sind Festplatten neben den Lüftern ja die am meisten beanspruchten mechanischen Komponenten.
Als alleroberste Regel gegen Datenverlust gilt: BACKUPs! Diese müssen natürlich aktuell genug sein ...
Trotz Backups möchte man natürlich die Downtime möglichst gering halten. Dazu bieten sich redundante Systeme an. Je nach Skalierung kann dies z.B. ein identisches System sein (vgl. Novell NetWare SFT-III) oder aber ein RAID (Redundant Array of Inexpensive Disks). Und darum soll es hier gehen :)
Ausserdem natürlich: Einbauanleitung beachten (z.B. Platte moeglichst gerade einbauen usw.) und gut belüften! Die Installation der entsprechenden Sensoren (lmsensors, gkrellm) sowie ggf. S.M.A.R.T. (bei IDE) kann das unterstützen - auch wenn ich bisher mit S.M.A.R.T. sehr unzufrieden bin, weil dessen Statusanzeige bisher selten mit der Realität übereingestimmt hat (was aber nicht an der Linux-Implementation der Tools liegt, sondern an der auf den Platten selber, wie mir die vom Hersteller der Platten bereitgestellten Tools bestätigt haben).
RAID
Grundlegendes Wissen bzgl. der verschiedenen RAID-Level, Einsatz, Verwendungsmöglichkeiten usw. ist auf jeden Fall sinnvoll vor Planung und Einsatz. Man kann sich dabei auch durchaus einfach der entsprechenden SCSI-Literatur bedienen; das meiste lässt sich für IDE übertragen.
Bei IDE sollte man jedoch beachten, dass das Master/Slave-Konzept seine Tücken hat - ich empfehle also dringend, pro Strang nur eine HDD (Master bzw. stand-alone) anzuschliessen. Es ist sonst sehr wahrscheinlich, dass eine defekte Platte am Strang dazu führt, dass die andere - wahrscheinlich noch intakte - Platte auch nicht mehr ansprechbar ist.
Eine Bemerkung sei mir jedoch gestattet: auch wenn viele Leute immer gerne davon reden, dass sie sich jetzt "ein RAID zugelegt haben", so meint der Privatmensch damit meistens linear mode/RAID-0, welches einfach nur zum Erhöhen von Speicherplatz oder Geschwindigkeit eingesetzt wird. Ein RAID-0 ist jedoch nur ein AID (also KEINE Redundanz)! RAID-10 - eine Kombination aus RAID-0 und RAID-1 - bietet diese dann wieder, benötigt aber dafür auch mindestens vier Laufwerke. Betrachtungen bzgl. der Geschwindigkeit habe ich ansonsten hier völlig aussen vor gelassen, da Sicherheit vorgeht (vielleicht habe ich ja irgendwann noch mal die Zeit/Muse dafür ...)
Hardware-RAID
Diese sind zumeist bei SCSI anzutreffen.
Nachteile:
- Falls der Controller keinen Standard-Chipsatz emuliert (was wg. UDMA usw. heutzutage ggf. eh nicht mehr sinnvoll ist), ist ein spezieller Treiber nur für den Controller notwendig.
- Die Kosten für den Controller übersteigen oft den einer Festplatte.
Vorteile:
- IdR kann man im Falle des Falles die RAID1-Platten auch an einem normalen Controller betreiben.
- Der Rechner muss die Daten nur ein Mal über den Bus zum Controller schaufeln; dieser übernimmt selbstätig Replikation, Fehlererkennung und ggf. ~korrektur.
- arbeitet gegenüber dem Betriebssytem völlig transparent; die Konsistenz des RAIDs kann durch einen Absturz des OS nicht beeinträchtigt werden.
- Daher kann man auch mehrere Betriebssysteme (Treiber vorausgesetzt) problemlos parallel installieren.
- Man kann hiermit gleich die Geschwindigkeit des Interfaces steigern (z.B. wenn der onBoard-IDE-Controller nur UDMA/33 kann, weil das Motherboard schon etwas in die Tage gekommen ist). Genau so kann evtl. eine HotSwap-Möglichkeit hinzugefügt werden.
Pseudo-Hardware-RAID
Hierzu zählen z.B. die FastTrak-Reihe von Promise und einige HighPoint (HPT).
Die Promise-Teile lassen sich sogar teilweise umbauen (siehe z.B. http://www.tweakhardware.com/forum oder in japanisch, direkt von der Quelle: http://www.be.wakwak.com/~pierrot/pub/factory/pierrots.htm) - danke an Barney für die Links!.
Nachteile:
- Das Chipsatz-/Treiber-Problem exisitiert hier genau so wie bei richtigen Hardware-RAID-Lösungen.
- Ist der Treiber nicht openSource, ist unklar, in wie weit der Treiber oder wirklich der Controller das RAID'en übernehmen - mit den jeweils entsprechenden Vor- und Nachteilen.
- Der Support an Treibern für Linux ist zur Zeit für manche Controller mangelhaft oder komplett fehlend.
- Es ist idR notwendig, mit einer initrd zu booten.
Vorteile:
- IdR kann man im Falle des Falles die Platten auch an einem normalen Controller betreiben.
- Controller sind bereits für ca. 100 € erhältlich.
- Man kann hiermit gleich die Geschwindigkeit des Interfaces steigern (z.B. wenn der onBoard-IDE-Controller nur UDMA/33 kann, weil das Motherboard schon etwas in die Tage gekommen ist). Genau so kann evtl. eine HotSwap-Möglichkeit hinzugefügt werden.
- Entsprechende Treiber vorausgesetzt kann man auch hier verschiedene OS parallel installieren.
Linux ATARAID
Zur Zeit (seit Linux-2.5.32) gibt es keinen Support für ATARAID im 2.6er Kernel!
Siehe dazu auch http://bugme.osdl.org/show_bug.cgi?id=496. Offensichtlich wurde beim Löschen des 2.5er IDE-cores und Übernahme des cores aus 2.4.19-pre-acX der Baum "raid" (bewusst, wegen redesign?) nicht mit übernommen.
update 2003-12-18:Im 2.6er Kernel musste der alte LVM "dem leistungsfähigeren Device-Mapper weichen, der die kernelseitige Grundlage des neuen LVM2 darstellt. Mit ihm lassen sich Block Devices - auch in Teilen - viel flexibler als bisher zu Logical Volumes zusammenfassen. Sistina liefert neue LVM2-User-Space-Tools [ftp.sistina.com/pub/LVM2/tools]. Mittelfristig soll der Device-Mapper das derzeit nicht funktionierende ataraid-Modul ersetzen." [Quelle: iX 1/2004, S.50]
ATARAID kann sowohl mit Unterstützung eines Controllers als auch ohne erfolgen. Im Gegensatz zum Linux Software-RAID ist hier eine 1:1-Spiegelung der Platten möglich und die Daten lassen sich auch normal ohne ATARAID lesen und schreiben (dann natürlich nur einzeln pro Platte, aber wenigstens überhaupt).
update: mittlerweile kann der Kernel 2.6 wieder mit ATARAID umgehen; wie bereits in der iX angekündigt wird dies nun über den device-mapper abgebildet. Eine saubere Lösung, finde ich.
Linux-Software-RAID (md)
Für die Einrichtung von RAID unter Linux gibt es - wie so meist :) - ein entsprechendes HOWTO. Die Implementierungen vor Kernel 2.4 unterscheiden sich zu diesem; das steht aber alles mit im HOWTO.
(Stichwörter: /proc/mdstat, mdadm, raidtools2, /etc/raidtab, /etc/mdadm/mdadm.conf, fdisk: Typ 0xFD, mkraid, /etc/fstab, /etc/lilo.conf, /dev/md? b 9 x)
Alles neu macht der Mai - aus raidtools2 wird mdadm - nur ein paar quick notes:
mdadm --create /dev/mdX --level=raid1 --raid-devices=2 /dev/sd[ab]Xmdadm --create --verbose /dev/md1 --level=1 --auto=md --raid-devices=2 /dev/sdb /dev/sdc- "alte" RAIDs wie ATARAID lassen sich nun via
dmraid über den device-mapper einbinden
- To migrate from the configuration file /etc/raidtab (raidtools2) to /etc/mdadm/mdadm.conf (mdadm), please execute:
# echo 'DEVICE /dev/hd*[0-9] /dev/sd*[0-9]' > /etc/mdadm/mdadm.conf
# mdadm --examine --scan >> /etc/mdadm/mdadm.conf
Nachteile:
- Es scheint nicht möglich zu sein, im Falle des Falles eine der Platten einzeln mit einem normalen Linux zu nutzen!
- Im Falle eines Crashs oder Fehlers des OS ist es möglich, dass auch das RAID davon betroffen ist (da ja Bestandteil des OS) und danach in einem undefinierten oder zerstörten Zustand vorliegt. Passieren kann das deswegen, weil das OS alle beteiligten Laufwerke eben auch einzeln sieht (im Layer unterhalb von md) und daher dort - ohne Wissen des RAID-Treibers - "Mist" schreiben kann.
- bei /dev/mdX lassen sich - im Gegensatz zu /dev/hdX - nicht die Geometriedaten verändern, was aber notwendig ist, da manche Softwareversionen (z.B. von fdisk) nur mit bis zu 1xxxxx Zylindern sauber arbeiten
- In wie weit man diese md's überhaupt partitionieren darf, muss ich noch etwas rumprobieren. "out-of-the-box" hat es jedenfalls erst mal nicht funktioniert. Das ist irgendwie inkonsequent. "mdpart" soll da evtl. weiterhelfen, weil ja für /dev/md0p1 usw. keine major/minor's mehr verfügbar sind. Es existiert zwar ein Patch für den 2.4er Kernel (nach mdpart suchen), aber es ist im Moment unklar, ob der a) auch mit der aktuellen Kernelversion sauber funktioniert und b) für zukünftige Kerlenversionen zur Verfügung steht bzw. offiziell aufgenommen wird. Vielleicht wird auch das mit devfs besser ;-)
- offensichtlich lassen sich sowieso keine ganzen HDDs einfach spiegeln (1:1-Kopie), so man diese auch noch partitionieren möchte - das geht nur über den Umweg der Einteilung in mehrere Laufwerke und/oder deren Zusammenfügen mittels LVM
- Durch Ändern der Partitionskennung in 0xFD für RAID-autodetect geht die ursprüngliche Information verloren. Allerdings ist das eh zumeist 0x83 (Linux), und bei 0x82 (Linux Swap) wird auf der Linux-Software-RAID-Mailingliste sowieso von der Nutzung eines RAID-1 für Swap abgeraten. update: neuere Dokumente sagen aus, dass das mit den aktuellen md-Implementationen stabil und performant laufen soll. Mein Testsystem (Debian 3.0 stable ["Woody"], Kernel 2.4.22-xfs) läuft bisher auch stabil damit (as of September 2003).
Vorteile:
- Ganz klar - das Linux-Software-RAID baut auf dem Unix-Konzept "alles ist eine Datei" auf, so dass man Laufwerke auch nur teilweise für RAID und teilweise für normale Daten nutzen bzw. das nahezu beliebig mischen kann. Flexibler dürfte es kaum gehen.
- Wohl die am besten dokumentierteste Variante der vier hier vorgestellten.
