Beim neu Aufsetzen eines LtspServers muss mdadm.conf aktualisiert werden

[Rüdiger Kupper]

In /etc/mdadm/mdadm.conf steht die UUID der RAID-Platten. Wird ein Server neu aufgesetzt, oder werden die Platten ausgetauscht, so muss diese Datei neu erzeugt werden. Das geht mit

sudo /usr/share/mdadm/mkconf generate

Siehe: ​launchpad:652327

-> ins Ltsp-Setup-Skript aufnehmen!

[Rüdiger Kupper]

Ich habe die starke Vermutung, dass die mdadm.conf gar nicht benötigt wird: GRUB2 scheint die RAIDs zusammenzusetzen. Das würde erklären, wieso unsere Server problemlos gebootet haben, als komplett falsche UUIDs in der mdadm.conf standen.

Es kann aber wohl nicht schaden, die mdadm.conf korrekt zu generieren, ich nehme es also in das Skript auf.

[Rüdiger Kupper]

Erledigt per changeset:489/keplertools.

=> Skript auf USB-Sticks vor nächstem Gebrauch updaten.

[bau]

Erkennt Grub2 die Raids automatisch oder kann man dem irgendwo mitgeben, was der das zusammenbauen soll.

Zu Testen bleibt:

• Ein Laufwerk (sdY) aus dem Array aushängen und den Server neu booten.

    mdadm --manage /dev/md127 --fail /dev/sdY
    mdadm --manage /dev/md127 --remove /dev/sdY
  

• Das Laufwerk (sdY) platt machen oder neue Platte rein

  dd if=/dev/zero of=/dev/sdY bs=512 count=1
  

• Neu partitionieren

    sfdisk -d /dev/sdX > sdb-partition.txt
    sfdisk /dev/sdY < sdb-partition.txt
  

• Die neue Platte ins Array einhängen

    mdadm --manage /dev/md127 --add /dev/sdY1
  

das Raid wird sich nun automatisch syncen (im laufenden Betrieb!). Das kann mit

  cat /proc/mdstat 

verfolgt werden. Nähere Infos unter ​http://en.wikipedia.org/wiki/Mdadm

[bau]

Beim Starten des defekten Raid war gestern einmal ein Start des Systems aus der initramfs-Umgebung möglich. Laut ​http://en.wikipedia.org/wiki/Mdadm#Booting ist ein Booten nur von einer Platte oder von einem Raid1 möglich, dabei wird zunächst die Spiegelung außen vor gelassen und der Boot-Teil erledigt. Ich vermute, kup hatte nicht nur /root eingehängt sondern auch /boot, und konnte dann per <strg>-D die initramfs verlassen.

Testumgebung: VirtualBox mit Ubuntu 12.04 Server aufsetzen auf ein Raid1 über zwei virtuelle Platten und von dort aus testen.

Anscheinend ist es vollkommen unerheblich, ob man die Platten als sda oder sdb einsetzt oder vertauschtm da die Platten im MBR ihre Verwendung im Raid (Device) abgespeichert haben. cat /proc/mdstat zeigt diese bei jeder Partition auch an. Es ist für uns jedoch sehr wichtig zu wissen, wo welche Platte sich befindet, damit wir im Ernstfall die richtige rausziehen.

[bau]

Was wir auch hätten probieren können ist ebenfalls beschrieben in: ​http://en.wikipedia.org/wiki/Mdadm#Recovering_from_a_loss_of_raid_superblock:

• Raiddaten anzeigen

     mdadm --detail /dev/md127
     mdadm --examine /dev/sda1 | egrep 'dev|Update|Role|State|Chunk Size'
     mdadm --examine /dev/sdb1 | egrep 'dev|Update|Role|State|Chunk Size'
  

• Raid stoppen, entfernen, superblocks löschen und wieder erstellen

    mdadm --stop /dev/md127    # to halt the array
    mdadm --remove /dev/md127  # to remove the array
    mdadm --zero-superblock /dev/sda1
    mdadm --zero-superblock /dev/sdb1
  
    mdadm --create /dev/md127 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1 # oder nur mit einem Device:
    mdadm --create /dev/md127 --level=1 --raid-devices=2 /dev/sda1 missing
  
    mdadm -D /dev/md127                       # UUID auslesen und in /etc/mdadm.conf anpassen
    mdadm --assemble /dev/md1 --update=resync # syncen
  

[Rüdiger Kupper]

Replying to kup:

Erledigt per changeset:489/keplertools.

=> Skript auf USB-Sticks vor nächstem Gebrauch updaten.

Skript ist gestern durchgelaufen, mdadm.conf wird nun also richtig erstellt. Beim nachfolgenden Installieren des Boot-Loaders müsste diese mdadm.conf dann auch in die initrd übernommen werden, so dass man in der Recovery-Konsole die korrekte mdadm.conf vorfindet.

[Rüdiger Kupper]

Replying to bau:

Erkennt Grub2 die Raids automatisch oder kann man dem irgendwo mitgeben, was der das zusammenbauen soll.

GRUB2 lädt vor dem Boot die Module für RAID und LVM: Aus /boot/grub/grub.cfg:

insmod raid
insmod mdraid1x
insmod lvm

Soweit ich weiß, arbeiten diese Module ganz autark, d.h., sie lesen den RAID-Superblock (wenn vorhanden) aus allen dem BIOS bekannten Platten aus und bauen das RAID passend zusammen. Dann passiert das gleiche mit dem LVM-Superblock, der wiederum in dem RAID gespeichert ist. Danach kann GRUB vom LVM booten.

Es ist sehr komfortabel, dass GRUB2 das alles selbst macht, und eigentlich müsste damit ein Recovery nach einem Plattenausfall problemlos laufen.

Die mdadm.conf-Datei wird allerdings beim Aufsetzen der initrd mit übernommen. Landet man also in der initrd-Recovery-Konsole, hat man die korrekt mdadm.conf verfügbar.
Ich nehme an, was dem ltsp3-RAID das Genick gebrochen hatte war, dass Du die letzte aktive Platte gezogen und durch eine ausgetauscht hast, auf der auch ein RAID-Superblock war, der aber nicht zu "unserem" RAID gehörte. Ich denke, das hat das System irgendwie ausgehebelt.

[Rüdiger Kupper]

Replying to bau:

Beim Starten des defekten Raid war gestern einmal ein Start des Systems aus der initramfs-Umgebung möglich. Laut ​http://en.wikipedia.org/wiki/Mdadm#Booting ist ein Booten nur von einer Platte oder von einem Raid1 möglich, dabei wird zunächst die Spiegelung außen vor gelassen und der Boot-Teil erledigt. Ich vermute, kup hatte nicht nur /root eingehängt sondern auch /boot, und konnte dann per <strg>-D die initramfs verlassen.

Es gibt bei uns keine eigene Partition für /boot mehr. /boot ist ein gewöhnliches Unterverzeichnis der Root-Partition. Die /boot-Partition habe ich abgeschafft, als GRUB2 so weit entwickelt war, dass es selbsttätig von RAID/LVM booten konnte.

Ich installiere den Bootloader übrigens stets in die MBR beider Platten, so dass GRUB von jeder der beiden Platten gsetartet werden kann. Damit sollte man ein RAID1 eigentlich immer booten können, egal, welche Platte fehlt.

Testumgebung: VirtualBox mit Ubuntu 12.04 Server aufsetzen auf ein Raid1 über zwei virtuelle Platten und von dort aus testen.

Genau, dann können wir damit einfach mal ein wenig gefahrlos herumexperimentieren.

Anscheinend ist es vollkommen unerheblich, ob man die Platten als sda oder sdb einsetzt oder vertauschtm da die Platten im MBR ihre Verwendung im Raid (Device) abgespeichert haben. cat /proc/mdstat zeigt diese bei jeder Partition auch an. Es ist für uns jedoch sehr wichtig zu wissen, wo welche Platte sich befindet, damit wir im Ernstfall die richtige rausziehen.

Exakt :-).

[Rüdiger Kupper]

Replying to bau:

Was wir auch hätten probieren können ist ebenfalls beschrieben in: ​http://en.wikipedia.org/wiki/Mdadm#Recovering_from_a_loss_of_raid_superblock:

Ja, klingt einleuchtend. Vielleicht hätte es schon gereicht, die richtige UUID in die mdadm.conf der initrd einzutragen(?).

[bau]

OK, du hattest gestern recht: die Platte aus dem ltsp6 hat einen Knacks und hat das RAID wieder im Zustand [U_] hinterlassen, degraded ließ es sich nicht booten. ich werde also nachher mal den Test ausprobieren. Mal sehen, was das Teil dazu sagt.

Kann ich ansonsten vom Stick booten und das Raid mit einer 500GB Platte neu aufsetzen?
Wie geht das dann - außer Fragen richtig beantworten?

[Rüdiger Kupper]

Ach, deshalb hat das gestern auch so ewig gedauert.

Am elegantesten wär's natürlich, vom degradierten RAID zu booten und einfach die neue Platte reinzustecken. Die Daten müssten ja komplett auf der ersten Platte vorliegen!

Wenn das nicht klappt:

1. Beim Booten F8 drücken und als Bootmedium den USB-Stick (nicht UEFI) auswählen.
2. Nach dem Hochfahren Terminal öffnen
3. (Dann wär's geschickt, Du startest erstmal eine "screen"-Session:

   screen -R setup
   

   dann kann man sich nämlich von außen in die Sitzung einklinken mit

   screen -x setup
   

   Dann kann ich mitlesen und Du muss nicht die ganze Zeit davorhocken.)
4. Skript starten

   LTSP-setup/LTSP-setup
   

   und als Option "add" wählen. Du kannst generell alle Fragen mit "y" oder "yes" beantworten, dann werden die Platten formatiert, das RAID neu aufgesetzt und das System vom ltsp7 rübergezogen. Die Tools beschweren sich über dies und das, das ist aber alles unkritisch. Vorm Kopieren des Systems wirst Du zweimal nach dem Passwort von linadmin gefragt.
5. Es gibt eine Stelle, an der das Skript stehen bleibt, ist aber auch unkritisch: Nachdem das rsync fertig ist, spuckt es eine Zusammenfassung aus (Wie viele Bytes übertragen wurden, Geschwindigkeit, etc.). Damit ist das rsync fertig, das Skript hängt aber, weil die X-Verbindung zum ltsp7 nicht endet. Wenn Du die Zusammenfassung des rsync siehst, musst Du also einmal "CTRL-C"-drücken (aber nur einmal ;-), dann läuft das Skript weiter.

Das war's.

Wenn Du experimentierfreudig bist, kannst Du stattdessen in der Live-Session natürlich nochmal versuchen, das RAID neu zusammenzusetzen und zu booten.

Du kannst mich auch gern anrufen, wenn Du vor'm Rechner sitzt: 4010532.