Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:troubleshoooting [2024/05/30 18:44]
flacco [RAID5, die Zweite]
+++ invis_server_wiki:troubleshoooting [2024/05/30 20:28] (aktuell)
flacco [RAID5, die Zweite]
@@ Zeile 86: / Zeile 86: @@
 Auch dies ist ein realer Fall aus der Praxis. Vorausgegangen ist ein schweres Unwetter. Getroffen hat es Augsburg Ende Mai 2024, wenn ich richtig informiert bin, kam es  durch Blitzschlag sogar zu schweren Schäden in einem Umspannwerk. Neben dem darauf folgenden Stromausfall, kann es im Netz sogar zu Spannungsspitzen kommen, die auch vom Überspannungsschutz einer USV nicht vollständig kompensiert werden können.
-Das Resultat beim Kunden war eine regelrecht aus einem RAID5-Verbung heraus gedroschene Festplatte. Physisch zerstört. Zwar ließ sich die Platte irgend wie noch ansprechen, //"fdisk -l /dev/sda"// beispielsweise zeigte, ohne Zeitverzögerung, noch die Partitionstabelle an. Allerdings resultiere Jeder Versuch mit der Platte zu kommunizieren massive I/O-Fehler im System-Journal. Ein merkwürdiger Zustand irgendwo zwischen intakt und defekt, wobei letzteres eindeutig der Realität entsprach.
+Das Resultat beim Kunden war eine regelrecht aus einem RAID5-Verbung heraus gedroschene Festplatte. Physisch zerstört. Zwar ließ sich die Platte irgend wie noch ansprechen, //"fdisk -l /dev/sda"// beispielsweise zeigte, ohne Zeitverzögerung, noch die Partitionstabelle an. Allerdings resultiere jeder Versuch mit der Platte zu kommunizieren massive I/O-Fehler im System-Journal. Ein merkwürdiger Zustand irgendwo zwischen intakt und defekt, wobei letzteres eindeutig der Realität entsprach.
+Bedingt durch den anschließenden Stromausfall, war der Server irgendwann aus. Nach dem Neustart, reagierte der RAID5-Verbund nicht mehr:
+<code>
+:rescue:~ # cat /proc/mdstat
+Personalities :
+md0 : inactive sdb1[1](S) sdd1[4](S) sdc1[2](S)
+      11721050052 blocks super 1.0
+unused devices: <none>
+</code>
+In der Liste der beteiligten RAID-Devices fehlt //"/dev/sda1"// und der Status steht auf "inactive". Nicht unbedingt das, was man erwartet. Schließlich soll ein RAID ja genau davor schützen, also "degraded", also beim Wegfall eines beteiligten Devices einfach wieder starten. Leider nicht in diesem Fall. Das fehlende Device, wurde irgendwie immer noch als beteiligt erkannt, aber wegen physischer Fehler auch nicht eingebunden. Henne und Ei Problem. Das RAID5 lies sich nicht "degradiert" aktivieren, da auf "/dev/sda1" keine Superblock gefunden werden konnte. Allerdings konnte "/dev/sda1/" auch nicht mittels:
+<code>
+:rescue:~ # mdadm /dev/md0 -f /dev/sda1
+:rescue:~ # mdadm /dev/md0 -r /dev/sda1
+</code>
+als fehlerhaft gekennzeichnet und entfernt werden, da es ja ohnehin nicht mehr da war. Beängstigender Zustand, wirkte so, als müsste der Verbund unter Verlust aller Daten aufgegeben werden, obwohl ja noch 3 von 4 Devices intakt und vorhanden waren -- also eigentlich kein Problem für einen RAID5-Verbund.
+Ich spare mir hier jetzt die Beschreibung einiger Stunden hilflosen Herumgestochers im Internet.
+Erwartet hätte ich. dass der Verbund degradiert einfach wieder startet. Es gibt allerdings eine Kernel-Bootoption, die dem Kernel untersagt einen RAID-Verbund in solchen Fällen einfach wieder zu starten. Statt dessen bleibt der Verbund inaktiv, was vermutlich sogar dem Schutz der darauf liegenden Daten dient. Dem Admin treibt es allerdings in solchen Momenten den kalten Schweiß auf die Stirn. Im hier beschriebenen Fall war es sogar so, dass ich für eine Schulung in Lübeck engagiert und vertraglich gebunden und der Kunde, eine Anwaltskanzlei in Augsburg, handlungsunfähig war. Satte 800km Entfernung, kein Remote-Zugriff und vor Ort niemand mit adäquaten Kenntnissen. (Ist nicht böse gemeint!)
+Beim Versuch irgendwie zu einem Remote-Zugriff zu kommen, gab es einige Hürden aus dem Weg zu räumen. Zwar startete das System aus eigener Kraft noch bis zu einem "emergency mode" hoch, auch eine Anmeldung als Benutzer "root" war möglich. Allerdings endeten alle Versuche auf dem System temporär eine Netzwerkschnittstelle zum Leben zu erwecken in unverständlichem Durcheinander. Also musste das System über einen USB-Stick in ein echtes Rescue-System gestaret werden. Den Server aber über einen USB-Stick zu starten erforderte gelinde gesagt ein paar Überredungskünste.
+Gelingt das, muss im System eine Netzwerkschnittstelle etabliert, ein Default-Gateway definiert, ein root-Passwort gesetzt, der SSH-Daemon gestartet, und im Router eine Portweiterleitung eingerichtet werden. Alles mit Personen Vor Ort, die in solchen Dingen irgendwo zwischen "nicht trittsicher" oder "ohne Fachkenntnisse" sind.
+Auch wenn es nicht direkt zum Thema passt hier die erforderlichen Befehle um ein (openSUSE) Rescue-System ins Netz zu bringen:
+<code>
+:rescue:~ # ip addr add 192.168.178.99/24 dev eth0
+:rescue:~ # ip link set dev eth0 up
+:rescue:~ # ip route add default via 192.168.178.1 dev eth0
+:rescue:~ # systemctl start sshd.service
+...
+:rescue:~ # passwd
+</code>
+Das Beispiel bezieht sich auf das traditionelle IP-Netz hinter einer Fritz-Box. Wie gesagt, es muss dann noch im Router ein Portforwarding des Ports 22/TCP auf die in der ersten Zeile gesetzten IP-Adresse eingerichtet (und, wenn der Schlamassel behoben ist, wieder entfernt) werden.
+Zurück zum Thema. Die Lösung des Problems war überraschend einfach.
+Wird Google bemüht, liefert das viele gute Tipps und Kommandos zu Tage mit denen das Problem beseitigt werden kann. Leider fehlt oft der Zusammenhang, oder zumindest die richtige Reihenfolge der einzugebenden Kommandos.
+Der "degradierte" Verbund lies sich wie folgt wieder zum Leben erwecken. Schritt 1 war das "Stoppen" des ohnehin inaktiven RAID-Vebundes:
+<code>
+:rescue:~ # mdadm --stop /dev/md0
+</code>
+Das Problem war, dass ich zunächst versucht hatte, denn Verbund ohne brachiale Gewalt wieder zu aktivieren:
+<code>
+:rescue:~ # mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
+mdadm: /dev/sdb1 is identified as a member of /dev/md/0, slot 1.
+mdadm: /dev/sdc1 is identified as a member of /dev/md/0, slot 2.
+mdadm: /dev/sdd1 is identified as a member of /dev/md/0, slot 3.
+mdadm: no uptodate device for slot 0 of /dev/md/0
+mdadm: added /dev/sdc1 to /dev/md/0 as 2
+mdadm: added /dev/sdd1 to /dev/md/0 as 3
+mdadm: added /dev/sdb1 to /dev/md/0 as 1
+mdadm: failed to RUN_ARRAY /dev/md/0: Input/output error
+mdadm: Not enough devices to start the array while not clean - consider --force.
+</code>
+Wird das Kommando, wie empfohlen mit der Option "--force" wiederholt, führt das zu nichts. Aus den Rückmeldungen geht einfach nicht hervor, dass der Verbund zunächst erneut gestoppt werden muss... Das hat ein bisschen Zeit gekostet.
+Zum Ziel führt also:
+<code>
+:rescue:~ # mdadm --stop /dev/md0
+:rescue:~ # mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
+</code>
+Die beiden Befehle also in unmittelbarer Abfolge. Danach startete der Verbund, wenn auch degradiert. Bleibt also die defekte Platte zu tauschen.
+Auch wenn es merkwürdig klingt ist auf invis-Servern daran, dass der Raidverbund (md0) als physical-Volume für LVM dient und so gestartet auch einen Neustart des Systems überlebt. Das wiederum macht es schwierig (wenn nicht dokumentiert) die defekte Platte zu erkennen. Zu wissen, dass es "sda" ist, genügt nicht, wenn die Verkabelung nicht klar ist und entsprechend nicht gesagt werden kann in welchem Schacht die Platte steckt. Grund dafür ist, dass sich, sowie LVM aktiv ist, sich der zugrunde liegende RAID-Verbund nicht mehr stoppen lässt.
+Im gestoppten Zustand, kann man zur Not einfach die Platten im laufenden Betrieb ziehen und mit:
+<code>
+:rescue:~ # udevmadm monitor
+</code>
+beobachten kann wann die defekte Platte verschwindet. Versucht man das bei aktivem RAID-Verbund, ist dieser zerstört, wenn versehentlich die falsche Platte entfernt wird.
+Wir haben im aktuellen Fall, also bei aktivem RAID, beobachtet, dass die jeweilige HDD-LED kurz aufblitzt, wenn:
+<code>
+:rescue:~ # fdisk /dev/sdX
+</code>
+eingegeben wird. Das große X ist der Reihe nach durch die echten Buchstaben der Platten zu ersetzen.
+Ist die Platte eindeutig identifiziert, Server herunter fahren, Platte tauschen. Server neu starten, neue Platte partitionieren und in den Verbund aufnehmen. Danach sollte der Rebuild des Verbundes starten. Wie das geht steht auch hier im Wiki.
 ===== Netzwerkprobleme =====
 ===== Server-Dienste =====