Anzeige:
Ergebnis 1 bis 6 von 6

Thema: Linux auf dem SW Raid

  1. #1
    Premium Mitglied Avatar von frankpr
    Registriert seit
    Feb 2002
    Ort
    Wo der Pfeffer wächst
    Beiträge
    3.124

    Linux auf dem SW Raid

    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
    Geändert von frankpr (07.11.04 um 21:55 Uhr)
    Dumme Fragen? ==> Dumme Antworten!
    Windows 7 x86_64 und Gentoo 2012.1 (x86_64) auf meinem Rechenknecht.
    Ein HTPC steht hier auch noch herum.

  2. #2
    Premium Mitglied Avatar von frankpr
    Registriert seit
    Feb 2002
    Ort
    Wo der Pfeffer wächst
    Beiträge
    3.124

    Nachtrag zu lilo

    Für alle, die den Aufwand, einen neuen lilo unter den Distributionen, die einen zu alten mitbringen (z.B. alle Fedora Core Releases), zu kompilieren, hier eine kleine Ergänzung.
    Unter Fedora habe ich mal das rpm vom SuSE FTP Server installiert (SuSE 9.0 unter Fedora Core 1 und SuSE 9.1 unter Fedora Core 2), unter beiden Releases gab es keinerlei Probleme, weder mit Abhängigkeiten, noch der rpm Datenbank, auch nicht mit dem Bootcode, da der sowieso in Assembler geschrieben, und somit von keiner Systembibliothek abhängig ist.

  3. #3
    Premium Mitglied Avatar von frankpr
    Registriert seit
    Feb 2002
    Ort
    Wo der Pfeffer wächst
    Beiträge
    3.124

    Fedora Core 2

    Da ich immer expreimentierfreudig bin, habe ich das Ganze mal unter Fedora Core 2 eingerichtet.
    Fazit: ständig bekam ich Fehlermeldungen, daß eine Disk fehlerhaft sei, mal hda, mal hdb, mal hdc. In allen Fällen waren die HDD's aber vollkommen in Ordnung. Betroffen waren immer nur einzelne Partitionen, nie eine komplette HDD.
    Das Problem trat mit Kernel 2.6.5, 2.6.6, 2.6.7 und 2.6.8-rc1 auf. Es waren sowohl die Fedora Kernel, als auch selbstkompilierte betroffen.
    Aus Zeitmangel konnte ich nicht ausgiebig nach dem Fehler suchen, es kommen 2 Möglichkeiten in Betracht:
    - der 2.6.x Kernel könnte ein Problem mit SW Raid haben, kann ich aber nicht so richtig glauben
    oder
    - die raidtools, die Fedora Core 2 mitliefert, haben ein Problem
    Aus diesem Grund kann ich derzeit SW Raid unter Fedora Core 2 nicht wirklich empfehlen.

  4. #4
    Premium Mitglied Avatar von frankpr
    Registriert seit
    Feb 2002
    Ort
    Wo der Pfeffer wächst
    Beiträge
    3.124

    Geplante Änderungen/Ergänzungen

    Nachdem ich es schon mehrfach gelesen habe und auch von einem Leser den Hinweis bekommen habe, daß grub mittlerweile ebenfalls von SW Raid Arrays booten kann, werde ich mich, sobald ich Zeit habe, mal damit beschäftigen und die Anleitung um den entsprechenden Abschnitt erweitern.

  5. #5
    Premium Mitglied Avatar von frankpr
    Registriert seit
    Feb 2002
    Ort
    Wo der Pfeffer wächst
    Beiträge
    3.124
    ... geändert ...
    Geändert von frankpr (24.10.08 um 16:19 Uhr)

  6. #6
    Premium Mitglied Avatar von frankpr
    Registriert seit
    Feb 2002
    Ort
    Wo der Pfeffer wächst
    Beiträge
    3.124

    Zum Thema grub

    Hier habe ich schon einen Beitrag zu diesem Thema geschrieben. grub an sich kann aktuell nach wie vor eigentlich nicht mit /boot auf einem SW Raid umgehen, es gibt nur einen Trick als Notbehelf.

Ähnliche Themen

  1. Desknote A 907 und SuSE Linux 8.2
    Von schuelsche im Forum System installieren und konfigurieren
    Antworten: 20
    Letzter Beitrag: 06.06.06, 21:47
  2. pdf writer für samba in suse 8.0
    Von cos im Forum Anwendungen Allgemein, Software
    Antworten: 16
    Letzter Beitrag: 14.10.05, 21:34
  3. Antworten: 2
    Letzter Beitrag: 27.05.04, 13:15
  4. Netzwerkkarte NETGEAR FA511 CardBus Mobile Adapter unter SuSE Linux
    Von DrainDZ im Forum Anbindung an die Aussenwelt
    Antworten: 5
    Letzter Beitrag: 07.03.03, 11:47
  5. USB-Scannerinstallation auch ohne hotplug möglich?
    Von Mr.Nobody im Forum System installieren und konfigurieren
    Antworten: 1
    Letzter Beitrag: 26.10.02, 08:53

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •