Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
invis_server_wiki:troubleshoooting [2024/05/30 19:34] flacco [RAID5, die Zweite] |
invis_server_wiki:troubleshoooting [2024/05/30 20:28] (aktuell) flacco [RAID5, die Zweite] |
||
|---|---|---|---|
| Zeile 116: | Zeile 116: | ||
| 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. | 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) Reschusystem ins Netz zu bringen: | + | Auch wenn es nicht direkt zum Thema passt hier die erforderlichen Befehle um ein (openSUSE) Rescue-System ins Netz zu bringen: |
| <code> | <code> | ||
| Zeile 129: | Zeile 129: | ||
| 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. | 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> | ||
| + | 0:rescue:~ # mdadm --stop /dev/md0 | ||
| + | </code> | ||
| + | |||
| + | Das Problem war, dass ich zunächst versucht hatte, denn Verbund ohne brachiale Gewalt wieder zu aktivieren: | ||
| + | |||
| + | <code> | ||
| + | 0: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> | ||
| + | 0:rescue:~ # mdadm --stop /dev/md0 | ||
| + | 0: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> | ||
| + | 0: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> | ||
| + | 0: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 ===== | ===== Netzwerkprobleme ===== | ||
| ===== Server-Dienste ===== | ===== Server-Dienste ===== | ||