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:57] flacco [RAID5, die Zweite] |
invis_server_wiki:troubleshoooting [2024/05/30 20:28] (aktuell) flacco [RAID5, die Zweite] |
||
---|---|---|---|
Zeile 136: | Zeile 136: | ||
<code> | <code> | ||
- | 0:rescue:~ # mdadm | + | 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 ===== |