NonRaid zu (software)Raid1 SuSE 10 1: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
(Sonderfall "appears to be part of a raid array")
K (intern verlinkt)
 
(31 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Oftmals entscheidet man sich nicht schon bei der Installation dazu, auf ein Software-RAID zu installieren, um z.B. erst ein neues System zu testen bevor das alte entfernet wird. Eine Neuinstallation ist auch nicht immer wünschenswert, wenn bereits Arbeit in das neue System geflossen ist.
+
Oftmals entscheidet man sich nicht schon bei der Installation dazu, auf ein [[RAID allgemein#Softwareraid|Software-RAID]] zu installieren, um z.B. erst ein neues System zu testen bevor das alte entfernet wird. Eine Neuinstallation ist auch nicht immer wünschenswert, wenn bereits Arbeit in das neue System geflossen ist.
  
 
Ein schon laufendes System später auf RAID-1 umzustellen ist duchaus möglich, benötigt aber eine Menge Handarbeit. Eine andere Möglichkeit ist, über ein komplettes System-Backup zu gehen, man läuft aber dennoch Gefahr, in die Konfigurationsfallen zu tappen.
 
Ein schon laufendes System später auf RAID-1 umzustellen ist duchaus möglich, benötigt aber eine Menge Handarbeit. Eine andere Möglichkeit ist, über ein komplettes System-Backup zu gehen, man läuft aber dennoch Gefahr, in die Konfigurationsfallen zu tappen.
Zeile 6: Zeile 6:
  
  
'''Warnung:''' Jedes Linuxsystem ist anders konfiguriert, es müssen also evtl. einige Optionen innerhalb der Befehle an jedes System angepasst werden statt dass sie direkt abgetippt werden können.
+
{{Box Test||
Es ist erforderlich, einige Erfahrungen im Umgang als root auf einer Shell unter Linux allgemein zu haben, sowie mit <code>fstab</code> und GRUBs <code>menu.lst</code>. Erfahrungen mit mdadm können keinesfalls schaden.
+
* SUSE Linux 10.1 Ausgiebige Tests mit den ersten Versionen dieses Howtos<br>
 +
* open SUSE  10.2 Prinzipielles Funktionieren des Howto<br>
 +
* open SUSE  10.3 Änderungen und Ergänzungen führten zur aktuellen Version<br>
 +
* open SUSE  11.0 Prinzipielles Funktionieren des Howto<br>
 +
* open SUSE  11.1 Kurztest
 +
* open SUSE  11.2 Test und ein paar kleinere Updates
 +
* open SUSE  11.3 Kurztest
 +
* open SUSE  11.4 Kurztest
 +
Für OpenSuse > 11.4 ist dieses Howto nicht getestet und Vorgehensweise müsste wegen [[systemd]] und [[GRUB_2]] massiv geändert werden.
 +
}}
  
Die bestehende Konfiguration:
+
 
 +
{{ Box Hinweis||Jedes Linuxsystem ist anders konfiguriert, es müssen also evtl. einige Optionen innerhalb der Befehle an jedes System speziell angepasst werden statt dass sie direkt kopiert oder abgetippt werden können.
 +
Es ist erforderlich, einige Erfahrungen im Umgang als root auf einer Shell unter Linux allgemein zu haben, sowie grundlegende Kenntnisse über die '''fstab''' und GRUBs '''menu.lst'''. Erfahrungen mit '''mdadm''' können keinesfalls schaden sind jedoch nicht zwingend erforderlich. Fundamentale Hinweise, wie etwa, das man vor manuellen Änderungen an Konfigurationsdateien eine Sicherheitskopie anlegen könnte, wird man hier vergeblich suchen. Kurzum: '''dieses Howto richtet sich an User die schon etwas Erfahrung mit LINUX und SUSE gesammelt haben''' }}
 +
 
 +
 
 +
 
 +
 
 +
 
 +
== Konfiguration des Ausgangssystems ==
 +
 
 +
Die bestehende Konfiguration wie sie sich vor dem Anlegen des Raids auf dem Rechner darstellt, mit dem hier im Howto die Ausgaben und Befehle enthalten sind :
 
  automat:/proc # fdisk -l
 
  automat:/proc # fdisk -l
 
   
 
   
Zeile 16: Zeile 35:
 
  Units = cylinders of 2048 * 512 = 1048576 bytes
 
  Units = cylinders of 2048 * 512 = 1048576 bytes
 
   
 
   
     Device Boot     Start         End     Blocks   Id  System
+
     Device Boot Start   End   Blocks Id  System
  /dev/sda1  *           1         65       66544   83  Linux
+
  /dev/sda1  *       1     65     66544 83  Linux
  /dev/sda2             66       5186     5243904   83  Linux
+
  /dev/sda2         66   5186   5243904 83  Linux
  /dev/sda3           5187       25667   20972544   83  Linux
+
  /dev/sda3       5187 25667 20972544 83  Linux
  /dev/sda4           25668       35003     9560064   f  W95 Ext'd (LBA)
+
  /dev/sda4       25668 35003   9560064   f  W95 Ext'd (LBA)
  /dev/sda5           25668       27716     2098160   82  Linux swap / Solaris
+
  /dev/sda5       25668 27716   2098160 82  Linux swap / Solaris
  /dev/sda6           27717       35003     7461872   83  Linux  
+
  /dev/sda6       27717 35003   7461872 83  Linux  
 
   
 
   
 
  Disk /dev/sdb: 36.7 GB, 36703932928 bytes
 
  Disk /dev/sdb: 36.7 GB, 36703932928 bytes
Zeile 28: Zeile 47:
 
  Units = cylinders of 2048 * 512 = 1048576 bytes
 
  Units = cylinders of 2048 * 512 = 1048576 bytes
 
   
 
   
     Device Boot     Start         End     Blocks   Id  System
+
     Device Boot Start   End   Blocks Id  System
  /dev/sdb1               1       35003   35843056   83  Linux  
+
  /dev/sdb1           1 35003 35843056 83  Linux  
 
   
 
   
 
   
 
   
 
  automat:/proc # cat /etc/fstab
 
  automat:/proc # cat /etc/fstab
  /dev/sda2           /                   ext3       acl,user_xattr       1 1
+
  /dev/sda2 /             ext3   acl,user_xattr   1 1
  /dev/sda5           swap                 swap       pri=42               0 0
+
  /dev/sda5 swap           swap   pri=42           0 0
  /dev/sda1           /boot               ext2       acl,user_xattr       1 2
+
  /dev/sda1 /boot         ext2   acl,user_xattr   1 2
  /dev/sda3           /home               ext3       acl,user_xattr       1 2
+
  /dev/sda3 /home         ext3   acl,user_xattr   1 2
  /dev/sda6           /data               ext2       auto,ro               1 2
+
  /dev/sda6 /data         ext2   auto,ro           1 2
  devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
+
  devpts     /dev/pts       devpts mode=0620,gid=5   0 0
  proc                 /proc               proc       defaults             0 0
+
  proc       /proc         proc   defaults         0 0
  usbfs               /proc/bus/usb       usbfs     noauto               0 0
+
  usbfs     /proc/bus/usb usbfs   noauto           0 0
  sysfs               /sys                 sysfs     noauto               0 0
+
  sysfs     /sys           sysfs   noauto           0 0
  /dev/fd0             /media/floppy       auto       noauto,user,sync     0 0
+
  /dev/fd0   /media/floppy auto   noauto,user,sync 0 0
 +
 
 +
 
 +
Es gibt also zwei gleiche Platten, wovon '''sdb''' derzeit nicht in Benutzung ist. Vorhanden sind auch mehrere Linux-Filesysteme ( '''/home''' , ''' /data''' ), auch ''' /boot ''' ist ein separates Filesystem.
 +
 
 +
{{Box Hinweis||Das Howto ist so geschrieben, dass es egal ist, ob das '''/boot-Verzeichnis''' auf einer separaten Partition (wie hier im Beispiel), oder mit auf der Rootpartition ist, es ist beides getestet. Die Hinweise bei der Konfiguration vor allem bei Grub sollte man aber beachten, hier ergebem sich kleine Unterschiede zwischen diesen beiden Konfigurationen}}
 +
 
 +
 
  
 +
== Anlegen einer identischen Partitionstabelle ==
  
Es gibt also zwei gleiche Platten, wovon sdb derzeit nicht in Benutzung ist. Vorhanden sind auch mehrere Linux-Filesysteme (<code>/home</code>, <code>/data</code>), auch <code>/boot</code> ist ein separates Filesystem. Das Howto ist so geschrieben, dass es egal ist, ob die Daten separat (wie hier) oder alles auf einer (Root)partition ist.
+
Zuerst klonen wir die gesamte Partionstabelle von sda nach sdb:
+
Zuerst klonen wir die gesamte Partionstabelle von '''sda''' nach '''sdb''':
  
 
  automat:/proc # sfdisk -d /dev/sda  > /tmp/sda.txt
 
  automat:/proc # sfdisk -d /dev/sda  > /tmp/sda.txt
Zeile 57: Zeile 84:
 
  Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0
 
  Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0
 
   
 
   
     Device Boot Start    End   #cyls    #blocks   Id  System
+
     Device Boot Start    End #cyls    #blocks Id  System
  /dev/sdb1          0+  35002   35003-  35843056   83  Linux
+
  /dev/sdb1          0+  35002 35003-  35843056 83  Linux
  /dev/sdb2          0      -       0          0   0  Empty
+
  /dev/sdb2          0      -     0          0   0  Empty
  /dev/sdb3          0      -       0          0   0  Empty
+
  /dev/sdb3          0      -     0          0   0  Empty
  /dev/sdb4          0      -       0          0   0  Empty
+
  /dev/sdb4          0      -     0          0   0  Empty
 
  New situation:
 
  New situation:
 
  Units = sectors of 512 bytes, counting from 0
 
  Units = sectors of 512 bytes, counting from 0
 
   
 
   
     Device Boot    Start      End   #sectors  Id  System
+
     Device Boot    Start      End #sectors  Id  System
  /dev/sdb1  *        32    133119     133088  83  Linux
+
  /dev/sdb1  *        32    133119   133088  83  Linux
  /dev/sdb2        133120  10620927   10487808  83  Linux
+
  /dev/sdb2        133120  10620927 10487808  83  Linux
  /dev/sdb3      10620928  52566015   41945088  83  Linux
+
  /dev/sdb3      10620928  52566015 41945088  83  Linux
  /dev/sdb4      52566016  71686143   19120128  f  W95 Ext'd (LBA)
+
  /dev/sdb4      52566016  71686143 19120128  f  W95 Ext'd (LBA)
 
  /dev/sdb5      52566048  56762367    4196320  82  Linux swap / Solaris
 
  /dev/sdb5      52566048  56762367    4196320  82  Linux swap / Solaris
 
  /dev/sdb6      56762400  71686143  14923744  83  Linux
 
  /dev/sdb6      56762400  71686143  14923744  83  Linux
Zeile 81: Zeile 108:
  
 
Wer KDE offen hat: dort gehen eventuell ein paar Fenster auf, dass neue Devices gefunden wurden. Diese sind mit "Abbrechen" zu schließen.
 
Wer KDE offen hat: dort gehen eventuell ein paar Fenster auf, dass neue Devices gefunden wurden. Diese sind mit "Abbrechen" zu schließen.
<code>fdisk -l</code> zeigt nun, dass alle Partitionen auf sda und sdb gleich sind. Da sdb z.Zt. nicht in Benutzung ist, wird kein Neustart benötigt.
+
'''fdisk -l''' zeigt nun, dass alle Partitionen auf '''sda''' und '''sdb''' gleich sind. Da '''sdb''' z.Zt. nicht in Benutzung ist, wird kein Neustart benötigt. Eventuell (insbesondere nachdem die Platte vorher mit Nullen überschrieben worden ist) könnte hier eine Fehlermeldung in der Art "DOS Kompatibilitäsproblem" kommen.<br>
 +
In diesem Fall die Option '''--force''' probieren, weitere Infos gibt es auch in einem [[Partitionstabelle sichern und wiederherstellen|eigenem Howto]] zu diesem Thema. Wenn wir die komplette Platte spiegeln sollte jedenfalls unser Ziel auch eine identische Partitionstabelle auf beiden Platten sein. Sollten hier Probleme auftauchen, dass die Partitionstabellen nicht gleich aussehen dann bitte [[Partitionstabelle sichern und wiederherstellen|hier]] nachlesen.
 +
 
 +
 
 +
== Raid für das zukünftige Rootfilesystem erstellen ==
 +
 
 +
 
Wir beginnen zunächst damit das Root-Filesystem auf einem RAID-Device aufzubauen und dieses zum Laufen zu bekommen.
 
Wir beginnen zunächst damit das Root-Filesystem auf einem RAID-Device aufzubauen und dieses zum Laufen zu bekommen.
sda wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootbar.
+
'''sda''' wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootfähig.  
Wir erstellen ein RAID-1-Device mit einer fehlenden Komponente mit sdb2 als einziger aktive Komponente.
+
{{OpenSUSE|10.3|
Zunächst wird die Partitions-ID von sdb2 geändert:
+
bei openSuse 10.3 sollten wir an dieser Stelle unbedingt einmal überprüfen ob das Initscript '''boot.md''' beim Booten gestartet wird, ansonsten sollten wir das jetzt hier entsprechend einrichten, bevor uns der Rechner bei einem Reboot ohne konfigurierte Raid-Device hängen bleibt.
 +
 
 +
 
 +
Zum Testen ob das Script '''boot.md''' beim Start ausgeführt wird, reicht folgender Befehl
 +
ls /etc/init.d/boot.d/*boot.md
 +
kommt hier als Antwort
 +
ls: cannot access /etc/init.d/boot.d/*boot.md: No such file or directory
 +
dann ist folgender Befehl auszuführen damit das Script dann in Zukunft wirklich beim Booten nach Raiddevices sucht und diese startet.
 +
insserv /etc/init.d/boot.md
 +
}}
 +
 
 +
 
 +
So jetzt wird es ernst und zuerst erstellen wir ein RAID-1-Device für unser zukünftig gespiegeltes Rootfilesystem mit einer fehlenden Komponente mit '''sdb2''' als einziger aktive Komponente.
 +
Zunächst wird die Partitions-ID von '''sdb2''' geändert: ''(das ist zwar nicht zwingend erforderlich, da es unter Linux von keinerlei Programm wirklich ausgewertet wird, einzig ein im Kernel fest eingebundenes Raidmodul würde dieses Flag nutzen, und wer hat das schon,  aber diese Kennzeichnung erleichtert uns später den Überblick zu bewaren, was schon konfiguriert ist und was noch nicht)''
  
 
  automat:/proc # sfdisk --change-id /dev/sdb 2 fd
 
  automat:/proc # sfdisk --change-id /dev/sdb 2 fd
Zeile 91: Zeile 137:
 
  automat:/proc # sfdisk -R /dev/sdb
 
  automat:/proc # sfdisk -R /dev/sdb
  
Eventuell tauchen unter KDE wieder Fenster auf, die mit Abbruch zu schließen sind.
+
 
 +
Eventuell tauchen unter KDE jetzt wieder Fenster auf, die mit Abbruch zu schließen sind.
 
Ein Blick auf <code>fdisk -l</code> zeigt nun, dass bei sdb2 wirklich <code>fd</code> als ID eingetragen ist.
 
Ein Blick auf <code>fdisk -l</code> zeigt nun, dass bei sdb2 wirklich <code>fd</code> als ID eingetragen ist.
 
Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird:
 
Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird:
 +
Das wird unser zukünftiges Rootfilesystem aufnehmen.
  
  automat:/ # mdadm -C /dev/md0 -e 1.0 -l1 -n2 missing /dev/sdb2
+
  automat:/ # mdadm -C /dev/md0 -b internal -e 1.0 -l1 -n2 missing /dev/sdb2
 
  mdadm: /dev/sdb2 appears to be part of a raid array:
 
  mdadm: /dev/sdb2 appears to be part of a raid array:
 
     level=raid1 devices=2 ctime=Sat Aug 19 21:27:47 2006
 
     level=raid1 devices=2 ctime=Sat Aug 19 21:27:47 2006
 
  Continue creating array? y
 
  Continue creating array? y
  mdadm: array /dev/md0 started.-------------------
+
  mdadm: array /dev/md0 started.
  
 
Die Nachfrage nach "appears to be part of a raid array" kann daraus resultieren, wenn die Partition bereits einen MDRAID-Superblock enthielt (z.B. von vorhergehenden Tests mit mdadm). Den Erfolg können wir wie folgt überprüfen:
 
Die Nachfrage nach "appears to be part of a raid array" kann daraus resultieren, wenn die Partition bereits einen MDRAID-Superblock enthielt (z.B. von vorhergehenden Tests mit mdadm). Den Erfolg können wir wie folgt überprüfen:
Zeile 110: Zeile 158:
 
  unused devices: <none>
 
  unused devices: <none>
  
 
+
und/oder
und oder
 
  
 
  automat:/proc # mdadm -D /dev/md0
 
  automat:/proc # mdadm -D /dev/md0
Zeile 135: Zeile 182:
 
           Events : 0.1
 
           Events : 0.1
 
   
 
   
    Number   Major   Minor   RaidDevice State
+
Number Major Minor RaidDevice State
        0      0       0        0      removed
+
    0      0      0       0      removed
        1       8      18        1      active sync   /dev/sdb2  
+
    1     8     18       1      active sync /dev/sdb2  
  
Wir tragen jetzt unser konfiguriertes Raiddevice in die mdadm.conf ein. Dabei hat es sich zumindestens bei meinen SCSI-Laufwerken für erforderlich herausgestellt die DEVICES bekannt zu geben, auf denen die RAID-Superblöcke zu suchen sind, da sie sonst beim booten nicht gefunden werden.
+
Wir tragen jetzt unser konfiguriertes RAID-Device in die '''mdadm.conf''' ein. Es ist erforderlich, eine DEVICES-Zeile in '''mdadm.conf''' einzufügen (sofern dies noch nicht geschehen ist), damit [http://linux.die.net/man/8/mdadm mdadm] beim Booten die dort gelisteten Blockgeräte überhaupt für das aktivieren von Arrays in Betracht zieht. Sollte es also diese Datei nicht geben oder noch keinen passenden DEVICES-Eintrag geben, ist dieser hinzuzufügen:
  
 
  automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
 
  automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
 +
 +
Der folgende Befehl scannt nun die /dev/md*-Geräte durch und trägt ihre Eigenschaften in '''mdadm.conf''' ein:
 +
 
  automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
 
  automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
 
  automat:/ # cat /etc/mdadm.conf
 
  automat:/ # cat /etc/mdadm.conf
Zeile 147: Zeile 197:
 
  ARRAY /dev/md0 level=raid1 num-devices=2 UUID=edf2a03f:8371ba02:b75cfbef:b1415c61
 
  ARRAY /dev/md0 level=raid1 num-devices=2 UUID=edf2a03f:8371ba02:b75cfbef:b1415c61
  
Nächster Punkt: das Filesystem auf /dev/md0 anlegen und das Filesystem temporär mounten und die orginalen Files dort hinein kopieren.
+
Nächster Punkt ist, das Filesystem auf '''/dev/md0''' anzulegen, temporär zu mounten und die originalen Dateien unseres Rootfilesystems dorthin zu kopieren.
  
  automat:/proc # mkfs.ext3 -j /dev/md0
+
  automat:/ # mkfs.ext3 -j /dev/md0
 
  ...
 
  ...
 
  ...
 
  ...
  automat:/proc # mount /dev/md0 /mnt
+
  automat:/ # mount /dev/md0 /mnt
  automat:/proc # cd /
+
  automat:/ # rsync -AHPSXavx / /mnt/
automat:/ # find . -mount | cpio  -pdumC65536 /mnt
+
 
64239 blocks
+
Der abschließende Slash bei '''/mnt/''' ist für das gewünschten Ziel-Layout unbedingt erforderlich.
 +
 
 +
Vorteil von [http://linux.die.net/man/1/rsync rsync] gegenüber anderen Programmen ist ACLs (''' -A ''') und Xattrs (''' -X ''') übertragen werden -- dies ist insbesondere bei Samba-Systemen wichtig. (Die Option ''' -A ''' ist vor SUSE Linux 10.1 nicht vorhanden; die Option ''' -X ''' nicht vor openSUSE 10.2.) rsync bietet darüber hinaus eine Statusanzeige und kann abgebrochene Transfers wieder aufnehmen. Sollte der Transfer allgemein länger dauern, so empfiehlt es sich nach Abschluss nochmals rsync laufen zu lassen, um Dateien, die während des 1. Versuchs geändert wurden, auch noch zu übertragen. Man ruft hierzu rsync mit gleichen Parametern und zusätzlich ''' --delete-during ''' (sollte die Option nicht bekannt sein, ist auf ''' --delete ''' auszuweichen) aufzurufen.
 +
 
  
jetzt ändern wir auf dem "neuem" Rootfilesystem die fstab  
+
 
 +
Jetzt ändern wir auf dem "neuem" Rootfilesystem die '''etc/fstab'''
  
 
  automat:/ # cd /mnt/etc
 
  automat:/ # cd /mnt/etc
 
  automat:/mnt/etc # vi fstab
 
  automat:/mnt/etc # vi fstab
  /dev/sda2           /                   ext3       acl,user_xattr       1 1 (dieses ist der alte Zeile)
+
  /dev/sda2 / ext3 acl,user_xattr 1 1 (dieses ist der alte Zeile)
  /dev/md0             /                   ext3       acl,user_xattr       1 1 (das ist geänderte Zeile)  
+
  /dev/md0   / ext3 acl,user_xattr 1 1 (das ist geänderte Zeile)  
 +
 
 +
{{OpenSUSE|10.3|
 +
bei openSuse 10.3 und wahrscheinlich nachfolgenden Versionen wird per default in der fstab nicht über den Deviceknoten direkt, sondern über die Disk-by-Id angesprochen. Dieser Link verweist dann seinerseits auf den Geräteknoten. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen könnte.
 +
 
 +
erste Zeile auskommentiert ist das Orginal und 2 Zeile der neue Eintrag für das Raid
 +
<pre>
 +
#/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 /    ext3      acl,user_xattr    1 1
 +
/dev/md0 /                    ext3      acl,user_xattr        1 1
 +
</pre>
 +
}}
  
Sodann können wir das Filesystem wieder aushängen, wir ändern als nächstes die /boot/grub/menu.lst  
+
 
 +
Das Filesystem wird dann wieder umount'ed  und die '''/boot/grub/menu.lst''' angepasst:
  
 
  automat:/mnt/etc # cd /
 
  automat:/mnt/etc # cd /
Zeile 171: Zeile 236:
 
  automat:/boot/grub # vi menu.lst
 
  automat:/boot/grub # vi menu.lst
  
 
+
Ein neuer Eintrag auf Basis des alten wird eingefügt, wir ändern aber das '''root=''' Argument so, dass nun '''md0''' als neues Root-Filesystem dienen soll. Der normale Booteintrag bleibt zunächst als default bestehen und über ihn kann vorläufig noch das alte System gebootet werden:
den normalen Booteintrag nehmen wir als Vorbild und wir fügen einen neuen Eintrag dazu der uns das neue Rootfilesystem als Raid1 starten soll.  
 
  
 
  #(normaler Booteintrag bleibt stehen)
 
  #(normaler Booteintrag bleibt stehen)
Zeile 187: Zeile 251:
 
     initrd /initrd  
 
     initrd /initrd  
  
Zum Schluss müssen wir noch eine neue initrd erstellen mit den Informationen von von mdadm.conf und mit Raidunterstützung, wir geben das neue Rootdevice mit an, wenn er noch Informationen benötigt soll er sie sich von dort holen.  
+
{{OpenSUSE|10.3|
 +
bei openSuse 10.3 hier ebenfals das Problem mit der Disk-by-ID. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen müsste.
 +
 
 +
<pre>
 +
###Don't change this comment - YaST2 identifier: Original name: linux###
 +
title openSUSE 10.3 - 2.6.22.17-0.1
 +
    root (hd0,1)
 +
    kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 \
 +
acpi=off  resume=/dev/sda1 splash=silent showopts
 +
    initrd /boot/initrd-2.6.22.17-0.1-default
 +
 
 +
###Don't change this comment - YaST2 identifier: Original name: RAID###
 +
title RAID 10.3 - 2.6.22.17-0.1
 +
    root (hd0,1)
 +
    kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x317 acpi=off resume=/dev/sda1 splash=silent showopts
 +
    initrd /boot/initrd-2.6.22.17-0.1-default
 +
</pre>
 +
}}
 +
 
 +
 
 +
Zum Schluss muss noch eine neue '''initrd''' mit den Informationen aus '''mdadm.conf''' und RAID-Unterstützung erstellt werden. Werden hierzu intern weiter Infos über das System benötigt, werden sie von den Scripten von '''mkinitrd''' automatisch selbst gesucht. Es reichen hier die Optionen Modul md und Rootfilesystem /dev/md0
  
 
  automat:/ # mkinitrd -f md -d /dev/md0  
 
  automat:/ # mkinitrd -f md -d /dev/md0  
  
'''1. Teil fertig.''' wir können rebooten und testen ob der neu angelegte Menüeintrag im Grub funktioniert und unser Raid1 Rootdevice sauber bootet
+
Bei Erfolg sollte am Ende irgend etwas von einer Blockanzahl stehen. Eine Warnung unter 10.3
Sollte das nicht funktionieren dann vom orginalen Booteintrag ohne Raid das alte System booten.
+
WARNING: GRUB::GrubPath2UnixPath: Path /boot/grub/menu.lst in UNIX form, not modifying it
 +
kann erst einmal ignoriert werden, sie kommt scheinbar durch das kopieren und teilweisen Veränderung eines automatisch erstellten Eintrags und wegen der bevorzugten DISK-by-ID Einstellung von 10.3 die wir hier nicht strikt befolgt haben.
 +
 
 +
 
 +
'''1. Teil fertig.''' wir können rebooten und testen, ob der neu angelegte Menüeintrag in GRUB funktioniert und das RAID1-Rootdevice sauber bootet.
 +
Sollte das nicht funktionieren, so kann man mittels originalem Booteintrag ohne RAID das alte System booten. Wir booten also nach wie vor jetzt noch von der orginalen Platte und aus dem darauf befindlichen /boot-Verzeichnis. Die einzige Änderung, wir binden als Rootdevice unser eben erstelltes (halbes) Raid1 ein.
 +
 
 +
 
 +
 
 +
== Anlegen der restlichen Raiddevices ==
 +
 
  
System ist wieder oben, prüfen ob das alles so funktioniert hat.  
+
Ist das System wieder oben, prüfen wir ob alles entsprechend funktioniert hat.
  
 
  automat:~ # mount
 
  automat:~ # mount
Zeile 213: Zeile 307:
 
       5243840 blocks [2/1] [_U]
 
       5243840 blocks [2/1] [_U]
 
        
 
        
  unused devices: <none  
+
  unused devices: <none>
 +
 
 +
Das war der schwierige Teil der Arbeit, ab hier wird es etwas einfacher.
 +
Nach gleicher Prozedur werden jetzt die restlichen RAID1-Devices angelegt, ohne '''sda''' zu verändern.
  
Das war der schwierige Teil der Arbeit, ab hier wirds einfacher
+
{{Kasten rot|Hier müssen wir jetzt allerdings besonders gut aufpassen, dass wir nichts durcheinander bringen, am besten man schreibt sich vorher auf, welches alte Device mit welchem Filesystemtype auf welchem Mountpoint welche Raid-Nummer bekommen soll. Entsprechend der unterschiedlichen Voraussetzungen vor dem Spiegeln können hier die Befehle dazu von den hier angegebenen Beispiel durchaus etwas stärker abweichen.}}
Wir gehen in der selben Weise weiter, und legen die restlichen Raid1 Devices an, ohne die sda kaput zu machen.
+
 
Wir ändern als nächstes alle anderen System-ID auf der sdb  
+
Wir ändern als nächstes alle anderen Partitions-IDs auf sdb:
  
 
  sfdisk --change-id /dev/sdb 1 fd
 
  sfdisk --change-id /dev/sdb 1 fd
Zeile 224: Zeile 321:
 
  sfdisk --change-id /dev/sdb 6 fd
 
  sfdisk --change-id /dev/sdb 6 fd
  
Als nächstes legen wir die restlichen neuen Raiddevice mit jeweils einer "missing" an
+
Als nächstes legen wir die restlichen neuen RAID-Device mit auch jeweils einer fehlenden Komponente an:
  
  mdadm -C /dev/md1 -e1.0 -l1 -n2  missing /dev/sdb1
+
  mdadm -C /dev/md1 -b internal -e1.0 -l1 -n2  missing /dev/sdb1
  mdadm -C /dev/md2 -e1.0 -l1 -n2  missing /dev/sdb5
+
  mdadm -C /dev/md2 -b internal -e1.0 -l1 -n2  missing /dev/sdb5
  mdadm -C /dev/md3 -e1.0 -l1 -n2  missing /dev/sdb3
+
  mdadm -C /dev/md3 -b internal -e1.0 -l1 -n2  missing /dev/sdb3
  mdadm -C /dev/md4 -e1.0 -l1 -n2  missing /dev/sdb6
+
  mdadm -C /dev/md4 -b internal -e1.0 -l1 -n2  missing /dev/sdb6
 
   
 
   
 
  automat:~ # cat /proc/mdstat
 
  automat:~ # cat /proc/mdstat
Zeile 250: Zeile 347:
 
  unused devices: <none>
 
  unused devices: <none>
  
Danach die mdadm.conf wieder anpassen.
+
Danach müssen die neuen RAID-Devices in der '''mdadm.conf''' eingetragen werden. Am einfachsten, indem wir diese noch einmal ganz neu erstellen lassen (DEVICE-Zeile vorher wieder einfügen):
  
 
  automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
 
  automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
 
  automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
 
  automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
  
jetzt können wir die Filesysteme auf den neuen Raiddevices anlegen und die Daten dorthin kopieren  
+
jetzt können wir die Filesysteme auf den neuen Devices anlegen und die Daten dorthin kopieren, ''der Notiz-Zettel hilft hier sicher ;-)''
 +
 
 +
'''Zwischenbemerkung:''' Wir spiegeln hier auch unseren Swap, (auch wenn sich da die Geister wieder streiten und es dazu durchaus geteilte Meinung gibt), aber nur mit einem gespiegeltem Swap kann man auch in einem laufenden Betrieb einen total-Plattenausfall überleben, deshalb müssen wir natürlich auch das "Swapfilesystem"  neu anlegen.
  
 
  mkswap /dev/md2
 
  mkswap /dev/md2
Zeile 261: Zeile 360:
 
  mkfs.ext3 -j /dev/md3
 
  mkfs.ext3 -j /dev/md3
 
  mkfs.ext2 /dev/md4
 
  mkfs.ext2 /dev/md4
+
 
 +
Nach dem Anlegen der Filesysteme wird jedes neue Filesystem temporär gemountet und die entsprechenden Daten dorthinein kopiert. Zum Kopieren gibt es die verschiedensten Möglichkeiten angefangen von [http://linux.die.net/man/1/cp cp], über eine ganze Anzahl von Backup- und Archivierungstools ist hier vieles möglich, es sind jedoch durchweg alles Befehle die eine ganzen Reihe von Optionen benötigen, damit auch alle Dateien wirklich mit den richtigen Eigenschaften kopiert werden. In diesem Beispiel benutzen wird [http://www.bellevuelinux.org/man/cpio.1.html cpio] dazu. Das kopiert allerdings so hier nur die Standard Zugriffrechte, was für Otto den Normallinuxer und das normale Linux Betriebssystem auch ausreicht, in einigen speziellen Fällen und Datenfilesystemen wird es jedoch nicht ganz ausreichend sein.<br>
 +
{{blau|; Man kann sich etwa an folgendem orientieren:
 +
wenn man für ein Backup ein spezielles Programm mit speziellen Optionen benötigt, dann ist es auch wahrscheinlich, das man auch hier etwas anderes als '''cpio''' nehmen sollte. Dann könnte man hier zB mit [http://linux.die.net/man/1/rsync rsync] ( schon oben beim kopieren der Rootpartition beschrieben) oder mit [http://linux.die.net/man/1/star star] und entsprechenden Optionen kopieren, um spezielle Eigenschaften von Dateien beim Kopieren mit zu übertragen. Solange jedoch ein '''tar''' als Backupprogramm reicht oder reichen würde, dann kann man getrost auch mit dem cpio-Befehl hier arbeiten.}}
 +
 
 
  automat:/ # mount /dev/md1 /mnt
 
  automat:/ # mount /dev/md1 /mnt
 
  automat:/ # cd /boot
 
  automat:/ # cd /boot
Zeile 277: Zeile 380:
 
  52731 blocks   
 
  52731 blocks   
  
natürlich jetzt noch die /etc/fstab anpassen
+
Natürlich ist jetzt noch die '''/etc/fstab''' anzupassen:
 +
''bei openSUSE 10.3 sind dann erst einmal alle Einträge mit DISK-by-ID unserer Rootplatte auskommentiert oder gelöscht''
  
 
  automat:/data # cat /etc/fstab
 
  automat:/data # cat /etc/fstab
  /dev/md0             /                   ext3       acl,user_xattr       1 1
+
  /dev/md0 /     ext3 acl,user_xattr 1 1
  /dev/md2             swap                 swap       pri=42               0 0
+
  /dev/md2 swap   swap pri=42         0 0
  /dev/md1             /boot               ext2       acl,user_xattr       1 2
+
  /dev/md1 /boot ext2 acl,user_xattr 1 2
  /dev/md3             /home               ext3       acl,user_xattr       1 2
+
  /dev/md3 /home ext3 acl,user_xattr 1 2
  /dev/md4             /data               ext2       auto,ro               1 2
+
  /dev/md4 /data ext2 auto,ro         1 2
 
  .....
 
  .....
  
'''2. Teil fertig:''' Hier kommt der ganz große reboot, wir wollen jetzt mit dem vorhin angelegten Menueintrag in der menu.lst auf die komplette Raidkonfiguration umstellen.
+
'''2. Teil fertig:''' An dieser Stelle rebootet man, um auch die restlichen RAID-Devices ins System zu integrieren. Wir booten nach wie vor noch von der alten Platte und aus dem darauf befindlichem '''/boot'''. Nur verwenden wir jetzt beim Starten alle neue Raiddevices.
 +
 
 +
 
 +
== Prüfen des Systems vor dem entgültigen Spiegeln ==
 +
 
  
Wieder da? Aber gleich Erfolg prüfen mit
+
Ist der Reboot sauber durchgelaufen, prüfen wir nochmals:
  
 
  automat:~ # swapon -s
 
  automat:~ # swapon -s
  Filename                               Type           Size    Used   Priority
+
  Filename Type       Size    Used Priority
  /dev/md2                               partition       2098040 0       42
+
  /dev/md2 partition 2098040 0   42
 
  automat:~ # mount
 
  automat:~ # mount
 
  /dev/md0 on / type ext3 (rw,acl,user_xattr)
 
  /dev/md0 on / type ext3 (rw,acl,user_xattr)
Zeile 306: Zeile 414:
 
  securityfs on /sys/kernel/security type securityfs (rw)  
 
  securityfs on /sys/kernel/security type securityfs (rw)  
  
soweit ok? Das System können wir hier ausgiebig auf saubere Funktion prüfen, bis jetzt ist das alte System noch voll einsatzfähig, und wir können immernoch zurück. Wenn ok<br>
+
Das System können wir hier ausgiebig auf saubere Funktion testen; bis jetzt ist das alte System immer noch voll einsatzfähig und wir können immer noch zurück. Sowohl in der Ausgabe von [http://linux.die.net/man/8/swapon swapon] als  auch von [http://linux.die.net/man/8/mount mount] sollte jetzt die orginale Platte nicht mehr erscheinen und dafür die Raiddevices. Auch das System sollte einwandfrei funktionieren,
Dann können wir die fehlenden Spiegelslices jetzt dazufügen.<br><br>
+
 
'''Achtung: Ab hier ist wird das alte System nicht mehr bootbar.'''
+
{{Box Achtung||'''wenn jetzt irgend etwas nicht richtig funktioniert hier besser die weitere Abarbeitung dieses Howtos abbrechen und auf Fehlersuche gehen''', ansonsten riskiert ihr die Gefahr einer eventuellen Neuinstallation.}}
 +
 
 +
Bisher sind am altem System nur folgende Dinge geändert worden, wenn man sich hier ans Howto gehalten hat:
 +
* bei einem 10.3 wurde das initscript /etc/init.d/boot.md aktiviert
 +
* ein Eintrag in die /boot/grub/menu.lst ist zusätzlich hinzugekommen
 +
* die initrd wurde neu erstellt und hat jetzt Raidsupport
 +
alle diese Einträge sind notfalls auch schnell wieder rückgängig zu machen.
 +
 
 +
 
 +
== Herstellung der Spiegelung ==
 +
 
 +
 
 +
Wenn alles in Ordnung ist, dann können die fehlenden Spiegelkomponenten nun hinzugefügt werden.
 +
 
 +
{{Box Achtung||'''Ab hier wird das alte System nicht mehr bootfähig.'''}}
  
 
  sfdisk --change-id /dev/sda 1 fd
 
  sfdisk --change-id /dev/sda 1 fd
Zeile 322: Zeile 444:
 
  mdadm /dev/md0 -a /dev/sda2
 
  mdadm /dev/md0 -a /dev/sda2
  
beobachten und verfolgen können wir das mit
+
Den Spiegelungsverlauf kann man wie folgt beobachten und verfolgen:
  
  automat:/proc # cat mdstat
+
  automat:/proc # cat /proc/mdstat
 
  Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
 
  Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
 
  md1 : active raid1 sda1[0] sdb1[1]
 
  md1 : active raid1 sda1[0] sdb1[1]
Zeile 346: Zeile 468:
 
  unused devices: <none>  
 
  unused devices: <none>  
  
Wir warten am besten bis alle Devices sauber online sind.<br>
+
{{Box Achtung||
Dann kommen wir zur neu Konfiguration des Grub.<br>
+
Man wartet ab, bis alle Devices synchronisiert sind. Ein Neustart ist hier überhaupt nicht empfehlenswert, da jetzt durch das recover die GRUB-Daten  nicht mehr passen. Also erst nach der kompletten Grub-Konfiguration und der nochmaligen Erzeugung einer initrd wieder rebooten oder ausschalten}}
Wir löschen jetzt den alten, jetzt überflüssigen Menüeintrag und ändern unseren ersten Eintrag von vorhin und legen noch einen zweiten an. Auch einen fallback-Eintrag legen wir an. Es sollten jetzt für jede Platte ein Menüeintrag vorhanden sein
+
 
 +
 
 +
 
 +
== Konfiguration von Grub ==
 +
 
 +
=== Konfiguration von /boot/grub/menu.lst ===
 +
 
 +
Jetzt wird es noch einmal etwas komplizierter, wir müssen Grub anpassen, zuerst die '''/boot/grub/menu.lst'''.
 +
Sie sollte im Moment noch den Orginalzustand des früheren Systems haben. Die Einträge unseres Linuxsystems müssen wir in folgenden Punkten änderen.
 +
root=
 +
resume=
 +
dort sollte überall jetzt ein /dev/md? stehen.
 +
 
 +
Desweiteren haben wir 2 Platten, und wir müssen von jeder Platte das System starten können, also brauchen wir jeden Eintrag doppelt, also jeweils für jede Platte einen eigenen. Die beiden Einträge unterscheiden sich dann jeweils in allen '''(hd?,?)''' Einträgen. Zur Sicherheit geben wir die '''Kernel''' und die '''initrd''' mit ihrem kompletten Path, also einschließlich ihrem Device mit an. Wir verwenden für '''Kernel''' und '''initrd''' nur die Softlinks und wir ändern die Kommentarzeile von Yast. Nur so können wir wirklich sicher sein, das YaST unsere Einträge nicht verändert, und damit auch noch nach dem nächsten Update sauber funktionieren.
 +
 
 +
{{blau|man merke sich: bis der Kernel fertig geladen ist, gibt es das Konzept von RAID nicht, d.h. GRUB
 +
kann die Platten nur einzeln sehen.}}
 +
 
 +
Es ist durchaus (besonders unter openSUSE 10.3) ein schönes Stück Konfigurationsänderungen hier notwendig und man sollte vorher unbedingt mal etwas über [[Grub]] gelesen haben. Bei Tests unter 10.3 haben sich massive Probleme mit der Kombination von "gespiegeltem Swap" und "Suspend to Disk" ergeben. Auch Krückenlösungen brachten hier nicht den richtigen gewünschten Erfolg. Meine Empfehlung deshalb, man überlege sich, ob man wirklich beide Funktionen in einem Rechner benötigt, oder ob man auf einem Rechner mit gespiegeltem Swap auf "Suspend to Disk" ganz verzichten kann, in diesem Fall diese Funktion hier deaktivieren. In allen anderen Fällen (auch bei Versionen vor 10.3) sollte man abschließend die beiden Funktionen genau testen inwieweit sie wirklich sauber zusammen funktionieren oder nicht. 
 +
 
 +
 
 +
So hier sollten diese Booteinträge nach der Änderung dann aussehen: (''' man beachte hier auch, dass beim Kernel und der initrd es hier einen Unterschied im Path gibt, je nach dem ob /boot eine eigene Partition ist, oder mit auf dem Rootdevice liegt''' <br>
 +
(''ich habe [http://wiki.linux-club.de/opensuse/Diskussion:NonRaid_zu_%28software%29Raid1_SuSE_10_1#Beispiel_einer_menu.lst_bei_openSUSE_10.3 hier] auf die Diskussionseite noch einmal eine komplette Datei eines 10.3 vor und nach dieser Änderung gegenüber gestellt.'')
  
 
  automat:/boot/grub # vi menu.lst
 
  automat:/boot/grub # vi menu.lst
Zeile 370: Zeile 514:
 
     initrd (hd1,0)/initrd  
 
     initrd (hd1,0)/initrd  
  
Als nächstes erzeugen wir noch einmal ein neues initrd, damit jetzt auch die restlichen Raiddevices beim booten erkannt werden können.
 
  
automat:/boot/grub # mkinitrd -f md
 
  
Jetzt müssen wir nur noch auf beide Platten einen neuen MBR schreiben, der die Grub Dateien auf den jeweiligen Devices findet.
+
=== Erzeugen der Bootloader im MBR auf beiden Spiegelplatten ===
dazu starten wir die grub-Shell
+
 
 +
 
 +
Jetzt muss nur noch auf beiden Platten ein neuer MBR geschreiben werden, der jeweils Bezug auf die  Grubkonfiguration seiner eigenen Platte enthält. Dazu starten wir die GRUB-Shell. Auch das ist noch einmal ein bisschen eine haarige Angelegenheit, aber halb so schlimm, wenn man wirklich weiß, was man hier macht. Deshalb einmal zur Erklärung, was mit den Befehlen hier genau angesprochen und gemacht wird, damit sollte es dann möglich sein, sich das gegebenenfalls für seinen Rechner richtig anzupassen. Im Zweifelsfall noch mal bei [[Grub]] vorbeischauen.
 +
; root (hd1,0) : bedeutet die Konfiguration von Grub (Dateien von grub unterhalb von /boot) befinden sich auf der '''Partition 1''' der Platte die in '''/boot/grub/device.map''' als '''hd1''' geführt wird
 +
; setup (hd1)  : und werden konfiguriert für den MBR eben dieser Platte '''hd1'''.
 +
und das Ganze konfigurieren wir für beide Platten.
 +
 
  
 
  automat:/boot/grub # grub
 
  automat:/boot/grub # grub
Zeile 405: Zeile 553:
 
  Done.  
 
  Done.  
  
noch ein kleiner Zusatz damit wir auch eine Mail bekommen, wenn einem unserer Raids irgenwas böses widerfährt.<br>
 
Wir schreiben an das Ende der mdadm.conf unsere Mailaddresse und starten im Yast den mdadmd Dienst.
 
  
  echo "MAIADDR root@localhost" >> /etc/mdadm.conf
+
== Aufnahme der neuen Platte in die /boot/grub/device.map ==
 +
 
 +
Bislang steht in der Datei nur
 +
 
 +
(fd0)  /dev/fd0
 +
(hd0)  /dev/sda
 +
 
 +
Die folgenden Zeile muss noch zugefügt werden.
 +
 
 +
(hd1)  /dev/sdb
 +
 
 +
 
 +
== Abschließende Konfiguration ==
 +
 
 +
 
 +
Nochmal muss eine initrd erstellt werden, damit auch hier die Raidunterstützung in dem neuen /boot Verzeichnis aktiviert wird, und damit auch noch die restlichen Raid-IDs innerhalb der '''initrd''' bekannt sind.
 +
 
 +
automat:/boot/grub # mkinitrd -f md
 +
 
 +
 
 +
 
 +
Ein kleiner Zusatz noch, damit wir auch eine Mail bekommen, wenn eine Komponente in den RAID-Arrays auf fehlerhaft ('''faulty''') geht: an das Ende der '''mdadm.conf''' fügen wir unsere Mailaddresse ein.
 +
  echo "MAILADDR root@localhost" >> /etc/mdadm.conf
 +
 
 +
 
 +
Damit die Devices überwacht werden und wir eine Mail bekommen können, müssen wir jedoch noch den '''mdadmd-Deamon''' starten, entweder über YaST oder mittels '''insserv'''
 +
insserv /etc/init.d/mdadmd
 +
 
  
 
'''Fertig:''' Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen.
 
'''Fertig:''' Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen.
Dann kann das Raidsystem ausgiebig getest werden.
+
Dann kann das RAID-System ausgiebig getest werden, und nicht vergessen, im [[BIOS|BIOS Menü]] auch die 2. Platte als bootfähig einzustellen, damit wenn die erste Platte fehlt oder ausfällt, die 2. Platte automatisch booten kann.
 +
 
 +
 
 +
 
 +
 
 +
== weitere Optionale Konfigurationen ==
 +
 
 +
 
 +
{{openSUSE|10.3|Wenn man openSUSE 10.3 hat, das Raid jetzt sauber von beiden Platten bootet und auch sonst alles funktioniert (einschließlich der nächste boot nach einem Kernelupdate) und man zusätzlich noch ein Freund von DISK-by-ID ist, dann kann man in der '''/etc/fstab''' und in der '''/boot/grub/menu.lst''' die Einträge manuell wieder auf DISK-BY-ID umstellen,
 +
die genauen Werte die zu benutzen sind kann man zB mit:
 +
  ls -l /dev/disk/by-id/md-uuid*
 +
abfragen. ''( Ob das bei Softwareraid irgendwo Vorteile bringen könnte, wage ich im Moment (noch) nicht einzuschätzen.)'' }}
  
  
robi
+
Wer ganz sicher gehen will trägt noch das Raidmodul in die '''/etc/sysconfig/kernel''' in die Zeile  '''INITRD_MODULES=''' ein. Erforderlich ist das nicht zwingend, denn solange beim ausführen von '''mkinitrd''' das Rootdevice ein Raid ist, wird [http://linux.die.net/man/8/mkinitrd mkinitrd] das Modul automatisch einbinden, aber man weiß ja nie auf welchen administratorischen Schwachsinn man mal in Zukunft kommt.
  
  

Aktuelle Version vom 5. September 2015, 20:08 Uhr

Oftmals entscheidet man sich nicht schon bei der Installation dazu, auf ein Software-RAID zu installieren, um z.B. erst ein neues System zu testen bevor das alte entfernet wird. Eine Neuinstallation ist auch nicht immer wünschenswert, wenn bereits Arbeit in das neue System geflossen ist.

Ein schon laufendes System später auf RAID-1 umzustellen ist duchaus möglich, benötigt aber eine Menge Handarbeit. Eine andere Möglichkeit ist, über ein komplettes System-Backup zu gehen, man läuft aber dennoch Gefahr, in die Konfigurationsfallen zu tappen.

Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 und SCSI-Devices funktionieren, desshalb habe ich mal meine Erfahrungen zu einem HOWTO zusammengestellt.


Diese Beschreibung wurde mit folgenden Distributionen getestet:
  • SUSE Linux 10.1 Ausgiebige Tests mit den ersten Versionen dieses Howtos
  • open SUSE 10.2 Prinzipielles Funktionieren des Howto
  • open SUSE 10.3 Änderungen und Ergänzungen führten zur aktuellen Version
  • open SUSE 11.0 Prinzipielles Funktionieren des Howto
  • open SUSE 11.1 Kurztest
  • open SUSE 11.2 Test und ein paar kleinere Updates
  • open SUSE 11.3 Kurztest
  • open SUSE 11.4 Kurztest

Für OpenSuse > 11.4 ist dieses Howto nicht getestet und Vorgehensweise müsste wegen systemd und GRUB_2 massiv geändert werden.


Hinweis:

Jedes Linuxsystem ist anders konfiguriert, es müssen also evtl. einige Optionen innerhalb der Befehle an jedes System speziell angepasst werden statt dass sie direkt kopiert oder abgetippt werden können. Es ist erforderlich, einige Erfahrungen im Umgang als root auf einer Shell unter Linux allgemein zu haben, sowie grundlegende Kenntnisse über die fstab und GRUBs menu.lst. Erfahrungen mit mdadm können keinesfalls schaden sind jedoch nicht zwingend erforderlich. Fundamentale Hinweise, wie etwa, das man vor manuellen Änderungen an Konfigurationsdateien eine Sicherheitskopie anlegen könnte, wird man hier vergeblich suchen. Kurzum: dieses Howto richtet sich an User die schon etwas Erfahrung mit LINUX und SUSE gesammelt haben




Konfiguration des Ausgangssystems

Die bestehende Konfiguration wie sie sich vor dem Anlegen des Raids auf dem Rechner darstellt, mit dem hier im Howto die Ausgaben und Befehle enthalten sind :

automat:/proc # fdisk -l

Disk /dev/sda: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

   Device Boot  Start    End    Blocks  Id  System
/dev/sda1   *       1     65     66544  83  Linux
/dev/sda2          66   5186   5243904  83  Linux
/dev/sda3        5187  25667  20972544  83  Linux
/dev/sda4       25668  35003   9560064   f  W95 Ext'd (LBA)
/dev/sda5       25668  27716   2098160  82  Linux swap / Solaris
/dev/sda6       27717  35003   7461872  83  Linux 

Disk /dev/sdb: 36.7 GB, 36703932928 bytes
64 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

   Device Boot  Start    End    Blocks  Id  System
/dev/sdb1           1  35003  35843056  83  Linux 


automat:/proc # cat /etc/fstab
/dev/sda2  /              ext3    acl,user_xattr    1 1
/dev/sda5  swap           swap    pri=42            0 0
/dev/sda1  /boot          ext2    acl,user_xattr    1 2
/dev/sda3  /home          ext3    acl,user_xattr    1 2
/dev/sda6  /data          ext2    auto,ro           1 2
devpts     /dev/pts       devpts  mode=0620,gid=5   0 0
proc       /proc          proc    defaults          0 0
usbfs      /proc/bus/usb  usbfs   noauto            0 0
sysfs      /sys           sysfs   noauto            0 0
/dev/fd0   /media/floppy  auto    noauto,user,sync  0 0


Es gibt also zwei gleiche Platten, wovon sdb derzeit nicht in Benutzung ist. Vorhanden sind auch mehrere Linux-Filesysteme ( /home , /data ), auch /boot ist ein separates Filesystem.

Hinweis:

Das Howto ist so geschrieben, dass es egal ist, ob das /boot-Verzeichnis auf einer separaten Partition (wie hier im Beispiel), oder mit auf der Rootpartition ist, es ist beides getestet. Die Hinweise bei der Konfiguration vor allem bei Grub sollte man aber beachten, hier ergebem sich kleine Unterschiede zwischen diesen beiden Konfigurationen



Anlegen einer identischen Partitionstabelle

Zuerst klonen wir die gesamte Partionstabelle von sda nach sdb:

automat:/proc # sfdisk -d /dev/sda  > /tmp/sda.txt
automat:/proc # sfdisk /dev/sdb < /tmp/sda.txt
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 35003 cylinders, 64 heads, 32 sectors/track
Old situation:
Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End  #cyls    #blocks  Id  System
/dev/sdb1          0+  35002  35003-  35843056  83  Linux
/dev/sdb2          0       -      0          0   0  Empty
/dev/sdb3          0       -      0          0   0  Empty
/dev/sdb4          0       -      0          0   0  Empty
New situation:
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End  #sectors  Id  System
/dev/sdb1   *        32    133119    133088  83  Linux
/dev/sdb2        133120  10620927  10487808  83  Linux
/dev/sdb3      10620928  52566015  41945088  83  Linux
/dev/sdb4      52566016  71686143  19120128   f  W95 Ext'd (LBA)
/dev/sdb5      52566048  56762367    4196320  82  Linux swap / Solaris
/dev/sdb6      56762400  71686143   14923744  83  Linux
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Wer KDE offen hat: dort gehen eventuell ein paar Fenster auf, dass neue Devices gefunden wurden. Diese sind mit "Abbrechen" zu schließen. fdisk -l zeigt nun, dass alle Partitionen auf sda und sdb gleich sind. Da sdb z.Zt. nicht in Benutzung ist, wird kein Neustart benötigt. Eventuell (insbesondere nachdem die Platte vorher mit Nullen überschrieben worden ist) könnte hier eine Fehlermeldung in der Art "DOS Kompatibilitäsproblem" kommen.
In diesem Fall die Option --force probieren, weitere Infos gibt es auch in einem eigenem Howto zu diesem Thema. Wenn wir die komplette Platte spiegeln sollte jedenfalls unser Ziel auch eine identische Partitionstabelle auf beiden Platten sein. Sollten hier Probleme auftauchen, dass die Partitionstabellen nicht gleich aussehen dann bitte hier nachlesen.


Raid für das zukünftige Rootfilesystem erstellen

Wir beginnen zunächst damit das Root-Filesystem auf einem RAID-Device aufzubauen und dieses zum Laufen zu bekommen. sda wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootfähig.

openSUSE:
10.3

bei openSuse 10.3 sollten wir an dieser Stelle unbedingt einmal überprüfen ob das Initscript boot.md beim Booten gestartet wird, ansonsten sollten wir das jetzt hier entsprechend einrichten, bevor uns der Rechner bei einem Reboot ohne konfigurierte Raid-Device hängen bleibt.


Zum Testen ob das Script boot.md beim Start ausgeführt wird, reicht folgender Befehl

ls /etc/init.d/boot.d/*boot.md 

kommt hier als Antwort

ls: cannot access /etc/init.d/boot.d/*boot.md: No such file or directory

dann ist folgender Befehl auszuführen damit das Script dann in Zukunft wirklich beim Booten nach Raiddevices sucht und diese startet.

insserv /etc/init.d/boot.md


So jetzt wird es ernst und zuerst erstellen wir ein RAID-1-Device für unser zukünftig gespiegeltes Rootfilesystem mit einer fehlenden Komponente mit sdb2 als einziger aktive Komponente. Zunächst wird die Partitions-ID von sdb2 geändert: (das ist zwar nicht zwingend erforderlich, da es unter Linux von keinerlei Programm wirklich ausgewertet wird, einzig ein im Kernel fest eingebundenes Raidmodul würde dieses Flag nutzen, und wer hat das schon, aber diese Kennzeichnung erleichtert uns später den Überblick zu bewaren, was schon konfiguriert ist und was noch nicht)

automat:/proc # sfdisk --change-id /dev/sdb 2 fd
Done
automat:/proc # sfdisk -R /dev/sdb


Eventuell tauchen unter KDE jetzt wieder Fenster auf, die mit Abbruch zu schließen sind. Ein Blick auf fdisk -l zeigt nun, dass bei sdb2 wirklich fd als ID eingetragen ist. Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird: Das wird unser zukünftiges Rootfilesystem aufnehmen.

automat:/ # mdadm -C /dev/md0 -b internal -e 1.0 -l1 -n2 missing /dev/sdb2
mdadm: /dev/sdb2 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Sat Aug 19 21:27:47 2006
Continue creating array? y
mdadm: array /dev/md0 started.

Die Nachfrage nach "appears to be part of a raid array" kann daraus resultieren, wenn die Partition bereits einen MDRAID-Superblock enthielt (z.B. von vorhergehenden Tests mit mdadm). Den Erfolg können wir wie folgt überprüfen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[1]
      5243840 blocks [2/1] [_U]
     
unused devices: <none>

und/oder

automat:/proc # mdadm -D /dev/md0
/dev/md0:
        Version : 01.00.03
  Creation Time : Sat Aug 19 21:27:47 2006
     Raid Level : raid1
     Array Size : 5243840 (5.00 GiB 5.37 GB)
    Device Size : 5243840 (5.00 GiB 5.37 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Aug 19 21:27:47 2006
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : edf2a03f:8371ba02:b75cfbef:b1415c61
         Events : 0.1

Number  Major  Minor  RaidDevice State
   0      0       0       0      removed
   1      8      18       1      active sync  /dev/sdb2 

Wir tragen jetzt unser konfiguriertes RAID-Device in die mdadm.conf ein. Es ist erforderlich, eine DEVICES-Zeile in mdadm.conf einzufügen (sofern dies noch nicht geschehen ist), damit mdadm beim Booten die dort gelisteten Blockgeräte überhaupt für das aktivieren von Arrays in Betracht zieht. Sollte es also diese Datei nicht geben oder noch keinen passenden DEVICES-Eintrag geben, ist dieser hinzuzufügen:

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf

Der folgende Befehl scannt nun die /dev/md*-Geräte durch und trägt ihre Eigenschaften in mdadm.conf ein:

automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
automat:/ # cat /etc/mdadm.conf
DEVICE /dev/sd[a-z][0-9]
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=edf2a03f:8371ba02:b75cfbef:b1415c61

Nächster Punkt ist, das Filesystem auf /dev/md0 anzulegen, temporär zu mounten und die originalen Dateien unseres Rootfilesystems dorthin zu kopieren.

automat:/ # mkfs.ext3 -j /dev/md0
...
...
automat:/ # mount /dev/md0 /mnt
automat:/ # rsync -AHPSXavx / /mnt/

Der abschließende Slash bei /mnt/ ist für das gewünschten Ziel-Layout unbedingt erforderlich.

Vorteil von rsync gegenüber anderen Programmen ist ACLs ( -A ) und Xattrs ( -X ) übertragen werden -- dies ist insbesondere bei Samba-Systemen wichtig. (Die Option -A ist vor SUSE Linux 10.1 nicht vorhanden; die Option -X nicht vor openSUSE 10.2.) rsync bietet darüber hinaus eine Statusanzeige und kann abgebrochene Transfers wieder aufnehmen. Sollte der Transfer allgemein länger dauern, so empfiehlt es sich nach Abschluss nochmals rsync laufen zu lassen, um Dateien, die während des 1. Versuchs geändert wurden, auch noch zu übertragen. Man ruft hierzu rsync mit gleichen Parametern und zusätzlich --delete-during (sollte die Option nicht bekannt sein, ist auf --delete auszuweichen) aufzurufen.


Jetzt ändern wir auf dem "neuem" Rootfilesystem die etc/fstab

automat:/ # cd /mnt/etc
automat:/mnt/etc # vi fstab
/dev/sda2  /  ext3  acl,user_xattr  1 1  (dieses ist der alte Zeile)
/dev/md0   /  ext3  acl,user_xattr  1 1  (das ist geänderte Zeile) 
openSUSE:
10.3

bei openSuse 10.3 und wahrscheinlich nachfolgenden Versionen wird per default in der fstab nicht über den Deviceknoten direkt, sondern über die Disk-by-Id angesprochen. Dieser Link verweist dann seinerseits auf den Geräteknoten. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen könnte.

erste Zeile auskommentiert ist das Orginal und 2 Zeile der neue Eintrag für das Raid

#/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 /    ext3      acl,user_xattr     1 1
/dev/md0 /                    ext3       acl,user_xattr        1 1


Das Filesystem wird dann wieder umount'ed und die /boot/grub/menu.lst angepasst:

automat:/mnt/etc # cd /
automat:/ # umount /mnt
automat:/ # cd /boot/grub
automat:/boot/grub # vi menu.lst

Ein neuer Eintrag auf Basis des alten wird eingefügt, wir ändern aber das root= Argument so, dass nun md0 als neues Root-Filesystem dienen soll. Der normale Booteintrag bleibt zunächst als default bestehen und über ihn kann vorläufig noch das alte System gebootet werden:

#(normaler Booteintrag bleibt stehen)
###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux 10.1
    root (hd0,0)
    kernel /vmlinuz root=/dev/sda2 vga=0x314 acpi=off resume=/dev/sda5 splash=silent  showopts
    initrd /initrd
#(nachfolgender Booteintrag kommt neu hinzu)
#--------- RAID----------#
title SUSE RAID 10.1
    root (hd0,0)
    kernel /vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/sda5 splash=silent  showopts
    initrd /initrd 
openSUSE:
10.3

bei openSuse 10.3 hier ebenfals das Problem mit der Disk-by-ID. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen müsste.

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 \
acpi=off   resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: RAID###
title RAID 10.3 - 2.6.22.17-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x317 acpi=off resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.17-0.1-default


Zum Schluss muss noch eine neue initrd mit den Informationen aus mdadm.conf und RAID-Unterstützung erstellt werden. Werden hierzu intern weiter Infos über das System benötigt, werden sie von den Scripten von mkinitrd automatisch selbst gesucht. Es reichen hier die Optionen Modul md und Rootfilesystem /dev/md0

automat:/ # mkinitrd -f md -d /dev/md0 

Bei Erfolg sollte am Ende irgend etwas von einer Blockanzahl stehen. Eine Warnung unter 10.3

WARNING: GRUB::GrubPath2UnixPath: Path /boot/grub/menu.lst in UNIX form, not modifying it

kann erst einmal ignoriert werden, sie kommt scheinbar durch das kopieren und teilweisen Veränderung eines automatisch erstellten Eintrags und wegen der bevorzugten DISK-by-ID Einstellung von 10.3 die wir hier nicht strikt befolgt haben.


1. Teil fertig. wir können rebooten und testen, ob der neu angelegte Menüeintrag in GRUB funktioniert und das RAID1-Rootdevice sauber bootet. Sollte das nicht funktionieren, so kann man mittels originalem Booteintrag ohne RAID das alte System booten. Wir booten also nach wie vor jetzt noch von der orginalen Platte und aus dem darauf befindlichen /boot-Verzeichnis. Die einzige Änderung, wir binden als Rootdevice unser eben erstelltes (halbes) Raid1 ein.


Anlegen der restlichen Raiddevices

Ist das System wieder oben, prüfen wir ob alles entsprechend funktioniert hat.

automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext2 (rw,acl,user_xattr)
/dev/sda3 on /home type ext3 (rw,acl,user_xattr)
/dev/sda6 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw)

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md0 : active raid1 sdb2[1]
      5243840 blocks [2/1] [_U]
     
unused devices: <none>

Das war der schwierige Teil der Arbeit, ab hier wird es etwas einfacher. Nach gleicher Prozedur werden jetzt die restlichen RAID1-Devices angelegt, ohne sda zu verändern.


Hier müssen wir jetzt allerdings besonders gut aufpassen, dass wir nichts durcheinander bringen, am besten man schreibt sich vorher auf, welches alte Device mit welchem Filesystemtype auf welchem Mountpoint welche Raid-Nummer bekommen soll. Entsprechend der unterschiedlichen Voraussetzungen vor dem Spiegeln können hier die Befehle dazu von den hier angegebenen Beispiel durchaus etwas stärker abweichen.

Wir ändern als nächstes alle anderen Partitions-IDs auf sdb:

sfdisk --change-id /dev/sdb 1 fd
sfdisk --change-id /dev/sdb 3 fd
sfdisk --change-id /dev/sdb 5 fd
sfdisk --change-id /dev/sdb 6 fd

Als nächstes legen wir die restlichen neuen RAID-Device mit auch jeweils einer fehlenden Komponente an:

mdadm -C /dev/md1 -b internal -e1.0 -l1 -n2  missing /dev/sdb1
mdadm -C /dev/md2 -b internal -e1.0 -l1 -n2  missing /dev/sdb5
mdadm -C /dev/md3 -b internal -e1.0 -l1 -n2  missing /dev/sdb3
mdadm -C /dev/md4 -b internal -e1.0 -l1 -n2  missing /dev/sdb6

automat:~ # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md4 : active raid1 sdb6[1]
      7461760 blocks [2/1] [_U]
     
md3 : active raid1 sdb3[1]
      20972480 blocks [2/1] [_U]
     
md2 : active raid1 sdb5[1]
      2098048 blocks [2/1] [_U]
     
md1 : active raid1 sdb1[1]
      66432 blocks [2/1] [_U]
     
md0 : active raid1 sdb2[1]
      5243840 blocks [2/1] [_U]
     
unused devices: <none>

Danach müssen die neuen RAID-Devices in der mdadm.conf eingetragen werden. Am einfachsten, indem wir diese noch einmal ganz neu erstellen lassen (DEVICE-Zeile vorher wieder einfügen):

automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
automat:/ # mdadm --detail --scan >> /etc/mdadm.conf

jetzt können wir die Filesysteme auf den neuen Devices anlegen und die Daten dorthin kopieren, der Notiz-Zettel hilft hier sicher ;-)

Zwischenbemerkung: Wir spiegeln hier auch unseren Swap, (auch wenn sich da die Geister wieder streiten und es dazu durchaus geteilte Meinung gibt), aber nur mit einem gespiegeltem Swap kann man auch in einem laufenden Betrieb einen total-Plattenausfall überleben, deshalb müssen wir natürlich auch das "Swapfilesystem" neu anlegen.

mkswap /dev/md2
mkfs.ext2 /dev/md1
mkfs.ext3 -j /dev/md3
mkfs.ext2 /dev/md4

Nach dem Anlegen der Filesysteme wird jedes neue Filesystem temporär gemountet und die entsprechenden Daten dorthinein kopiert. Zum Kopieren gibt es die verschiedensten Möglichkeiten angefangen von cp, über eine ganze Anzahl von Backup- und Archivierungstools ist hier vieles möglich, es sind jedoch durchweg alles Befehle die eine ganzen Reihe von Optionen benötigen, damit auch alle Dateien wirklich mit den richtigen Eigenschaften kopiert werden. In diesem Beispiel benutzen wird cpio dazu. Das kopiert allerdings so hier nur die Standard Zugriffrechte, was für Otto den Normallinuxer und das normale Linux Betriebssystem auch ausreicht, in einigen speziellen Fällen und Datenfilesystemen wird es jedoch nicht ganz ausreichend sein.

Man kann sich etwa an folgendem orientieren

wenn man für ein Backup ein spezielles Programm mit speziellen Optionen benötigt, dann ist es auch wahrscheinlich, das man auch hier etwas anderes als cpio nehmen sollte. Dann könnte man hier zB mit rsync ( schon oben beim kopieren der Rootpartition beschrieben) oder mit star und entsprechenden Optionen kopieren, um spezielle Eigenschaften von Dateien beim Kopieren mit zu übertragen. Solange jedoch ein tar als Backupprogramm reicht oder reichen würde, dann kann man getrost auch mit dem cpio-Befehl hier arbeiten.

automat:/ # mount /dev/md1 /mnt
automat:/ # cd /boot
automat:/boot # find . -mount | cpio -pdumC65536 /mnt
349 blocks
automat:/boot # umount /mnt
automat:/boot # mount /dev/md3 /mnt
automat:/boot # cd /home
automat:/home # find . -mount | cpio -pdumC65536 /mnt
53011 blocks
automat:/home # umount /mnt
automat:/home # mount /dev/md4 /mnt
automat:/home # cd /data
automat:/data # find . -mount | cpio -pdumC65536 /mnt
52731 blocks  

Natürlich ist jetzt noch die /etc/fstab anzupassen: bei openSUSE 10.3 sind dann erst einmal alle Einträge mit DISK-by-ID unserer Rootplatte auskommentiert oder gelöscht

automat:/data # cat /etc/fstab
/dev/md0  /      ext3  acl,user_xattr  1 1
/dev/md2  swap   swap  pri=42          0 0
/dev/md1  /boot  ext2  acl,user_xattr  1 2
/dev/md3  /home  ext3  acl,user_xattr  1 2
/dev/md4  /data  ext2  auto,ro         1 2
.....

2. Teil fertig: An dieser Stelle rebootet man, um auch die restlichen RAID-Devices ins System zu integrieren. Wir booten nach wie vor noch von der alten Platte und aus dem darauf befindlichem /boot. Nur verwenden wir jetzt beim Starten alle neue Raiddevices.


Prüfen des Systems vor dem entgültigen Spiegeln

Ist der Reboot sauber durchgelaufen, prüfen wir nochmals:

automat:~ # swapon -s
Filename  Type       Size    Used Priority
/dev/md2  partition  2098040 0    42
automat:~ # mount
/dev/md0 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/md1 on /boot type ext2 (rw,acl,user_xattr)
/dev/md3 on /home type ext3 (rw,acl,user_xattr)
/dev/md4 on /data type ext2 (ro)
securityfs on /sys/kernel/security type securityfs (rw) 

Das System können wir hier ausgiebig auf saubere Funktion testen; bis jetzt ist das alte System immer noch voll einsatzfähig und wir können immer noch zurück. Sowohl in der Ausgabe von swapon als auch von mount sollte jetzt die orginale Platte nicht mehr erscheinen und dafür die Raiddevices. Auch das System sollte einwandfrei funktionieren,

Achtung:

wenn jetzt irgend etwas nicht richtig funktioniert hier besser die weitere Abarbeitung dieses Howtos abbrechen und auf Fehlersuche gehen, ansonsten riskiert ihr die Gefahr einer eventuellen Neuinstallation.


Bisher sind am altem System nur folgende Dinge geändert worden, wenn man sich hier ans Howto gehalten hat:

  • bei einem 10.3 wurde das initscript /etc/init.d/boot.md aktiviert
  • ein Eintrag in die /boot/grub/menu.lst ist zusätzlich hinzugekommen
  • die initrd wurde neu erstellt und hat jetzt Raidsupport

alle diese Einträge sind notfalls auch schnell wieder rückgängig zu machen.


Herstellung der Spiegelung

Wenn alles in Ordnung ist, dann können die fehlenden Spiegelkomponenten nun hinzugefügt werden.

Achtung:

Ab hier wird das alte System nicht mehr bootfähig.


sfdisk --change-id /dev/sda 1 fd
sfdisk --change-id /dev/sda 2 fd
sfdisk --change-id /dev/sda 3 fd
sfdisk --change-id /dev/sda 5 fd
sfdisk --change-id /dev/sda 6 fd

mdadm /dev/md4 -a /dev/sda6
mdadm /dev/md3 -a /dev/sda3
mdadm /dev/md2 -a /dev/sda5
mdadm /dev/md1 -a /dev/sda1
mdadm /dev/md0 -a /dev/sda2

Den Spiegelungsverlauf kann man wie folgt beobachten und verfolgen:

automat:/proc # cat /proc/mdstat
Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
md1 : active raid1 sda1[0] sdb1[1]
      66432 blocks [2/2] [UU]
     
md3 : active raid1 sda3[0] sdb3[1]
      20972480 blocks [2/1] [_U]
      [==>..................]  recovery = 11.4% (2395776/20972480) finish=8.6min speed=35734K/sec
     
md4 : active raid1 sda6[0] sdb6[1]
      7461760 blocks [2/2] [UU]
     
md2 : active raid1 sda5[0] sdb5[1]
      2098048 blocks [2/1] [_U]
        resync=DELAYED
     
md0 : active raid1 sda2[2] sdb2[1]
      5243840 blocks [2/1] [_U]
        resync=DELAYED
     
unused devices: <none> 
Achtung:

Man wartet ab, bis alle Devices synchronisiert sind. Ein Neustart ist hier überhaupt nicht empfehlenswert, da jetzt durch das recover die GRUB-Daten nicht mehr passen. Also erst nach der kompletten Grub-Konfiguration und der nochmaligen Erzeugung einer initrd wieder rebooten oder ausschalten



Konfiguration von Grub

Konfiguration von /boot/grub/menu.lst

Jetzt wird es noch einmal etwas komplizierter, wir müssen Grub anpassen, zuerst die /boot/grub/menu.lst. Sie sollte im Moment noch den Orginalzustand des früheren Systems haben. Die Einträge unseres Linuxsystems müssen wir in folgenden Punkten änderen.

root=
resume=

dort sollte überall jetzt ein /dev/md? stehen.

Desweiteren haben wir 2 Platten, und wir müssen von jeder Platte das System starten können, also brauchen wir jeden Eintrag doppelt, also jeweils für jede Platte einen eigenen. Die beiden Einträge unterscheiden sich dann jeweils in allen (hd?,?) Einträgen. Zur Sicherheit geben wir die Kernel und die initrd mit ihrem kompletten Path, also einschließlich ihrem Device mit an. Wir verwenden für Kernel und initrd nur die Softlinks und wir ändern die Kommentarzeile von Yast. Nur so können wir wirklich sicher sein, das YaST unsere Einträge nicht verändert, und damit auch noch nach dem nächsten Update sauber funktionieren.


man merke sich: bis der Kernel fertig geladen ist, gibt es das Konzept von RAID nicht, d.h. GRUB kann die Platten nur einzeln sehen.

Es ist durchaus (besonders unter openSUSE 10.3) ein schönes Stück Konfigurationsänderungen hier notwendig und man sollte vorher unbedingt mal etwas über Grub gelesen haben. Bei Tests unter 10.3 haben sich massive Probleme mit der Kombination von "gespiegeltem Swap" und "Suspend to Disk" ergeben. Auch Krückenlösungen brachten hier nicht den richtigen gewünschten Erfolg. Meine Empfehlung deshalb, man überlege sich, ob man wirklich beide Funktionen in einem Rechner benötigt, oder ob man auf einem Rechner mit gespiegeltem Swap auf "Suspend to Disk" ganz verzichten kann, in diesem Fall diese Funktion hier deaktivieren. In allen anderen Fällen (auch bei Versionen vor 10.3) sollte man abschließend die beiden Funktionen genau testen inwieweit sie wirklich sauber zusammen funktionieren oder nicht.


So hier sollten diese Booteinträge nach der Änderung dann aussehen: ( man beachte hier auch, dass beim Kernel und der initrd es hier einen Unterschied im Path gibt, je nach dem ob /boot eine eigene Partition ist, oder mit auf dem Rootdevice liegt
(ich habe hier auf die Diskussionseite noch einmal eine komplette Datei eines 10.3 vor und nach dieser Änderung gegenüber gestellt.)

automat:/boot/grub # vi menu.lst
# Modified by YaST2. Last modification on Sun Aug 13 16:40:57 CEST 2006
color white/blue black/light-gray
default 0
fallback 1
timeout 8
gfxmenu (hd0,0)/message

#--------- RAID----------#
title SUSE RAID 10.1 1-Platte
    root (hd0,0)
    kernel (hd0,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent  showopts
    initrd (hd0,0)/initrd

#--------- RAID----------#
title SUSE RAID 10.1 2-Platte
    root (hd1,0)
    kernel (hd1,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent  showopts
    initrd (hd1,0)/initrd 


Erzeugen der Bootloader im MBR auf beiden Spiegelplatten

Jetzt muss nur noch auf beiden Platten ein neuer MBR geschreiben werden, der jeweils Bezug auf die Grubkonfiguration seiner eigenen Platte enthält. Dazu starten wir die GRUB-Shell. Auch das ist noch einmal ein bisschen eine haarige Angelegenheit, aber halb so schlimm, wenn man wirklich weiß, was man hier macht. Deshalb einmal zur Erklärung, was mit den Befehlen hier genau angesprochen und gemacht wird, damit sollte es dann möglich sein, sich das gegebenenfalls für seinen Rechner richtig anzupassen. Im Zweifelsfall noch mal bei Grub vorbeischauen.

root (hd1,0) 
bedeutet die Konfiguration von Grub (Dateien von grub unterhalb von /boot) befinden sich auf der Partition 1 der Platte die in /boot/grub/device.map als hd1 geführt wird
setup (hd1)  
und werden konfiguriert für den MBR eben dieser Platte hd1.

und das Ganze konfigurieren wir für beide Platten.


automat:/boot/grub # grub

grub> root (hd1,0)
 Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd1)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd1)"...  15 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done. 


Aufnahme der neuen Platte in die /boot/grub/device.map

Bislang steht in der Datei nur

(fd0)   /dev/fd0
(hd0)   /dev/sda

Die folgenden Zeile muss noch zugefügt werden.

(hd1)   /dev/sdb


Abschließende Konfiguration

Nochmal muss eine initrd erstellt werden, damit auch hier die Raidunterstützung in dem neuen /boot Verzeichnis aktiviert wird, und damit auch noch die restlichen Raid-IDs innerhalb der initrd bekannt sind.

automat:/boot/grub # mkinitrd -f md


Ein kleiner Zusatz noch, damit wir auch eine Mail bekommen, wenn eine Komponente in den RAID-Arrays auf fehlerhaft (faulty) geht: an das Ende der mdadm.conf fügen wir unsere Mailaddresse ein.

echo "MAILADDR root@localhost" >> /etc/mdadm.conf


Damit die Devices überwacht werden und wir eine Mail bekommen können, müssen wir jedoch noch den mdadmd-Deamon starten, entweder über YaST oder mittels insserv

insserv /etc/init.d/mdadmd


Fertig: Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen. Dann kann das RAID-System ausgiebig getest werden, und nicht vergessen, im BIOS Menü auch die 2. Platte als bootfähig einzustellen, damit wenn die erste Platte fehlt oder ausfällt, die 2. Platte automatisch booten kann.



weitere Optionale Konfigurationen

openSUSE:
10.3
Wenn man openSUSE 10.3 hat, das Raid jetzt sauber von beiden Platten bootet und auch sonst alles funktioniert (einschließlich der nächste boot nach einem Kernelupdate) und man zusätzlich noch ein Freund von DISK-by-ID ist, dann kann man in der /etc/fstab und in der /boot/grub/menu.lst die Einträge manuell wieder auf DISK-BY-ID umstellen,

die genauen Werte die zu benutzen sind kann man zB mit:

 ls -l /dev/disk/by-id/md-uuid* 
abfragen. ( Ob das bei Softwareraid irgendwo Vorteile bringen könnte, wage ich im Moment (noch) nicht einzuschätzen.)


Wer ganz sicher gehen will trägt noch das Raidmodul in die /etc/sysconfig/kernel in die Zeile INITRD_MODULES= ein. Erforderlich ist das nicht zwingend, denn solange beim ausführen von mkinitrd das Rootdevice ein Raid ist, wird mkinitrd das Modul automatisch einbinden, aber man weiß ja nie auf welchen administratorischen Schwachsinn man mal in Zukunft kommt.