invis_server_wiki:troubleshoooting

Dies ist eine alte Version des Dokuments!


Troubleshooting

Diese Seite widmet sich der Beseitigung von Problemen aller Art am Server oder im Netzwerk. Dabei geht es nicht alleine um den invis-Server. Die hier beschriebenen Mittel und Wege dürfte auch für andere Linux-Admins von Interesse sein.

Der Ausfall einer Festplatte ist dank RAID-Systemen in aller Regel zu verschmerzen. Das Handling von Linux Software-RAID Verbünden ist meist nicht weiter kompliziert. Trotzdem kann es zu Zuständen kommen, die einem schon mal den Angstschweiss auf die Stirn treiben können. Eine entsprechende Situation durfte ich bereits Live erleben. Vorausgegangen war ein Versehen. Aus einem RAID5-Verbund mit insgesamt 6 Festplatten wurde versehentlich eine vollkommen intakte Platte im Betrieb herausgezogen. Eigentlich kein Problem. Platte wieder einstecken und die RAID-Partition dem Verbund wieder hinzufügen:

invis:~ # mdadm /dev/md1 -a /dev/sdc1

(Die Festplatten, RAID und Partitionsbezeichnungen müssen natürlich an die eigenen Gegebenheiten angepasst werden.)

Danach kontrollieren, ob ein RAID-Resync läuft:

invis:~ # cat /proc/mdstat

In der Ausgabe sollte der Fortschritt der Synchronisation angezeigt werden. Im besonderen Fall hier war der Rebuild allerdings schon nach wenigen Sekunden scheinbar erfolgreich abgeschlossen (Bei 4TB Platten dauert ein vollständiger Resync normalerweise Stunden.). Zunächst habe ich dem wenig Bedeutung beigemessen, da erstens die Platte nur wenige Sekunden aus dem RAID entfernt war und der Server wegen Wartungsarbeiten gerade nichts zu tun hatte. Es also wenig Zugriffe auf den RAID-Verbund gab.

Die böse Überraschung folgte dann etwa 1 bis 2 Stunden später. Auf dem RAID Verbund liefen einige virtuelle Maschinen, die sich zunehmend sonderbar verhielten. Es war auch nicht mehr möglich diese geordnet herunterzufahren. Nach kurzer Zeit hatte der Linux-Kernel (glücklicherweise) auf Read-Only umgeschaltet. Der erste Reflex war ein Reboot des Servers, der allerdings mitten drin stecken blieb. Der betroffene RAID-Verbund stand nicht mehr zur Verfügung (inactive).

Der erste Versuch den Verbund wieder zum Leben zu erwecken endete damit das plötzlich der Ausfall zweier Platten gemeldet wurde, was bei einem RAID5 natürlich der Supergau wäre. Totalverlust!

In der Verzweiflung versucht man natürlich nach jedem Strohalm zu greifen. Ich habe das System über eine Rescue-Disk gebootet und dann einen zweiten Versuch unternommen den Verbund zu reaktivieren. Wichtig ist, dass er trotz Inaktivität zunächst gestoppt werden:

invis:~ # mdadm --stop /dev/md1

Ein automatisches Reassemblieren mit:

invis:~ # mdadm --assemble --scan

führte nicht zum Erfolg. Wer das testet, muss vor dem nächsten Schritt den Verbund wieder wie zuvor gezeigt stoppen.

Erst mit Gewalt unter Angabe aller beteiligten Platten klappte es:

invis:~ # mdadm --assemble --force /dev/md1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1

Wieder war zu beobachten, dass des der Resync nach nur wenigen Sekunden abgeschlossen war. Misstrauen war angesagt. Zur endgültigen Beseitigung des Problems habe ich die betroffene Platte wieder aus dem laufenden Verbund entfernt und vollständig neu partitioniert. Erst danach wurde sie dem dem Verbund wieder hinzugefügt. Danach lief die Resynchronisation erwartungsgemäß einige Stunden.

Achtung: Sie müssen sich für diesen Schritt absolut sicher sein welche Platte das Problem verursacht hat. Ich kann mir vorstellen, dass es das finale Ende des RAID5 Verbundes wäre jetzt die falsche Platte aus dem RAID zu nehmen.

Entfernen der Platte (Partition) aus dem Verbund:

invis:~ # mdadm /dev/md1 -f /dev/sdc1
invis:~ # mdadm /dev/md1 -r /dev/sdc1

Zur Sicherheit ein paar Nuller auf den Anfang schreiben:

invis:~ # dd if=/dev/zero of=/dev/sdc

Dann mit fdisk neu partitionieren, am besten damit beginnen eine neue Partitionstabelle auf die Platte zu schreiben (fdisk Kommando „g“ für eine GPT-Tabelle).

Beim neuen Anlegen einer Partition (fdisk Kommando „n“) auf der Platte erkennen neuere fdisk-Versionen ggf. noch alte Strukturen wie etwa die RAID-Signatur und fragen, ob diese überschrieben werden können. Unbedingt bejahen! Nicht vergessen den Partitionstyp auf Linux-RAID zu setzen (fdisk-Kommando „t“ / Typ „29“ oder „fd“ - je nach fdisk Version).

Danach kann die Platte (Partition) wieder in den RAID-Verbund aufgenommen werden:

invis:~ # mdadm /dev/md1 -a /dev/sdc1

Kontrolle wieder mit:

invis:~ # cat /proc/mdstat

Jetzt sollte der Resync je nach Plattengröße einige Stunden dauern.

  • invis_server_wiki/troubleshoooting.1621234565.txt.gz
  • Zuletzt geändert: 2021/05/17 06:56
  • von flacco