Normalerweise sind Sonntage eher ruhig – bis auf Ausnahmen. So eine gab es auch heute wieder.

Bereits gestern meldete das Monitoring bei einem unserer Server Fehler im RAID-Verbund. Wäre normalerweise eine Sache von 5 Minuten, das RZ zu informieren und den HDD-Tausch zu veranlassen – bei diesem Server allerdings nicht.

Aus diversen Gründen, u.a. wegen der erhöhten (geographischen) Redundanz sowie des sehr günstigen Datentransfers, steht dieser Server als Backup-Storage und Nameserver bei Hetzner – daher allerdings nur mit Software-RAID1 und ohne Hardware-RAID-Controller. Der Austausch ist also weder im laufenden Betrieb noch ohne Handarbeit möglich.

Der Austausch kann bei Hetzner allerdings äußerst unkompliziert beauftragt werden.

Nach dem Login im Hetzner-Robot wird bei den Support-Anfragen der betroffene Server sowie als Problemkategorie “Festplatte ist defekt” bietet Hetzner nun ein vorbereites Formular an. Folgende Angaben werden benötigt:

  • Spezifizierung der Seriennummer der defekten oder der intakten Festplatte (mit Auswahl), um die defekte HDD identifizieren zu können
  • Logfile-Auszüge, die auf den Grund des Defektes hindeuten
  • Auswahl der Ersatzfestplatte: kostenfreier Tausch gegen eine neuwertige oder “getestete Gebrauchte” je nach Verfügbarkeit oder gegen 49€ Gebühr eine garantiert neuwertige HDD
  • sowie die Angabe des Terminvorschlages (“sofort, sobald Techniker verfügbar” oder Angabe eines Wunschtermines)

Der Tausch selbst wurde dann binnen 40 Minuten abgeschlossen – für Sonntag Nachmittag äußerst angenehm schnell!

Leider bootete der Server nicht von der verbliebenen intakten Festplatte, so dass der Server nach dem Tausch im Rescue übergeben wurde.

Dort meldete MDAdm leider Probleme. Das RAID wurde zweigeteilt aufgebaut, ein RAID1-Device für das Betriebssystem inkl. Boot-Daten sowie ein weiteres RAID1-Device, auf dem sich die LVM-Volumes mit den virtuellen Maschinen befinden.

Das kleine Boot-RAID1 war nach dem Kopieren der Partitionierung (“sgdisk -R /dev/sda /dev/sdb”, um die Partitionierung von /dev/sdb auf /dev/sda zu übertragen) und dem Hinzufügen (“mdadm /dev/md0 –add /dev/sda2”) schnell behoben. Um das Booten von der Festplatte sicherzustellen, musste nach dem Hinzufügen der neuen Partition zum bestehenden Boot-RAID1 noch GRUB aktualisiert werden:

root@uranus:~# grub-install --recheck /dev/sda
Installation finished. No error reported.
root@uranus:~# grub-install --recheck /dev/sdb
Installation finished. No error reported.
root@uranus:~#

Zusammen mit einem “update-grub” war der darauffolgende Bootvorgang wieder erfolgreich.

Das große Daten-RAID1 hingegen zeigte sich unkooperativ:

root@uranus:~# cat /proc/mdstat
Personalities : [raid1]
md1 : inactive sdb4[1](S)
      2901944320 blocks super 1.2

md0 : active raid1 sda2[2] sdb2[1]
      24314808 blocks super 1.2 [2/2] [UU]

unused devices:

Entfernen von “md1” und erneutes Assemblieren brachte nichts, da die “gute” Festplatte offenbar während des Rebuild-Vorganges behindert wurde und der Kernel sich deshalb nicht auf diese Daten verlassen wollte:

root@uranus:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@uranus:~# mdadm --assemble --force /dev/md1 /dev/sdb4
mdadm: /dev/md1 assembled from 0 drives and  1 rebuilding - not enough to start the array.
root@uranus:~#

Die Lösung fand sich dann bei StackExchange: das RAID1 wurde entfernt und mit neuem Superblock neu aufgebaut. Danach die getauschte, nun leere, Festplatte zum RAID1-Verbund hinzufügen:

root@uranus:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@uranus:~# mdadm --create /dev/md1 --assume-clean /dev/sdb4  -l1 -n2 missing
mdadm: /dev/sdb4 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Sat Mar  3 14:03:09 2012
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@uranus:~# 2013 Mar 17 16:48:42 uranus DegradedArray event detected on md device /dev/md1

root@uranus:~# cat /proc/mdstat
Personalities : [raid1]
md1 : active (auto-read-only) raid1 sdb4[0]
      2901944184 blocks super 1.2 [2/1] [U_]

md0 : active raid1 sda2[2] sdb2[1]
      24314808 blocks super 1.2 [2/2] [UU]

unused devices:
root@uranus:~# mdadm /dev/md1 --add /dev/sda4

Seit dem werden die Daten kopiert – bei 1,5TB dauert das leider etwas länger als früher. Der Rebuild läuft seit ca. 17:00 Uhr und wird voraussichtlich noch 2 Stunden dauern.

Was lernen wir daraus?

  • Software-RAID ist zwar preisgünstig, allerdings mit deutlich mehr Handarbeit/Aufwand sowie einer größeren Fehleranfälligkeit verbunden
  • das Neu-Aufbauen eines RAID1 klappte hingegen (in diesem speziellen Fall) doch recht gut.
  • Backups schaden nie 🙂

Next Post Previous Post