Ich verwende Ubuntu 12.04 LTS. Gestern fand ich in meiner Mailbox eine Nachricht, dass mein Server heruntergefahren wurde. Ich versuchte, das System neu zu starten, aber es sprang nach vielen Minuten nicht an und ich hatte kein Hardware-KVM-System, um zu sehen, was der Kernel auf dem Terminal ausgab. Also startete ich das System mit einem Linux-Rettungsimage neu und sah, dass das Software-RAID-1-Array nicht mehr synchron war. Das Rettungssystem begann auch mit der Rekonstruktion des RAID-Arrays.
Bisher gibt es keine Hinweise darauf, dass eine der Festplatten Hardwarefehler aufweist. Die SMART-Status sehen bisher gut aus.
Ich habe nie eine E-Mail-Benachrichtigung von mdadm erhalten, obwohl die E-Mail-Benachrichtigung in /etc/mdadm/mdadm.conf aktiviert war.
Dieser Server war auch so konfiguriert, dass alle Syslog-Meldungen an einen Log-Host weitergeleitet wurden, also habe ich meinen Log-Host überprüft. Die relevanten Teile sind:
20. Mai 15:38:40 Kernel: [1.869825] md0: Kapazitätsänderung von 0 auf 536858624 erkannt 20. Mai 15:38:40 Kernel: [1.870687] md0: unbekannte Partitionstabelle 20. Mai 15:38:40 Kernel: [1.877412] md: binden 20. Mai 15:38:40 Kernel: [1.878337] md/raid1:md1: nicht sauber – Rekonstruktion im Hintergrund wird gestartet 20. Mai 15:38:40 Kernel: [1.878376] md/raid1:md1: aktiv mit 2 von 2 Spiegeln 20. Mai 15:38:40 Kernel: [1.878418] md1: Kapazitätsänderung von 0 auf 3000052808704 erkannt 20. Mai 15:38:40 Kernel: [1.878575] md: Resynchronisierung des RAID-Arrays md1 [Ausschnitt] 20. Mai 15:52:33 Kernel: Kernel-Protokollierung (proc) gestoppt. 20. Mai 15:52:33 rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="845" x-info="http://www.rsyslog.com"] wird bei Signal 15 beendet.
Wie Sie sehen, hat das System (das normale, nicht das Rettungssystem) bereits beim Systemstart erkannt, dass etwas mit dem RAID-Array nicht stimmte. Dann, kurz darauf, hat etwas (nicht ich) das System angehalten.
Meine Fragen sind also:
- Was könnte dazu führen, dass die Festplatten plötzlich nicht mehr synchron sind?
- Warum wurde ich nicht per E-Mail benachrichtigt?
- Warum wurde der Fehler vor dem Anhalten des Systems nicht ordnungsgemäß ins Syslog protokolliert? Könnte es sein, dass das System versucht hat, sich ins Syslog zu protokollieren, dies aber nach dem Anhalten des Syslog-Daemons getan hat? Wenn ja, was kann ich tun, um dies zu verhindern?
- Was kann ich tun, um herauszufinden, was passiert ist? Oder, wenn es für mich jetzt keine Möglichkeit gibt, herauszufinden, was passiert ist: Wie kann ich die Protokollierung und Benachrichtigungen verbessern, damit ich das nächste Mal eine bessere Nachbetrachtung durchführen kann?
Meine Frage istnichtüber die richtige Vorgehensweise beim Sichern. Ich weiß bereits, dass RAID kein Backup usw. ist. Meine Frage bezieht sich ausschließlich auf Benachrichtigungen und Diagnose.
Antwort1
Was könnte dazu führen, dass die Festplatten plötzlich nicht mehr synchron sind?
Es könnte sich um einen Hardware- oder Softwarefehler im Pfad zwischen den Laufwerksplatten und den Daten im Speicher handeln. Das kann (ist aber nicht darauf beschränkt) bedeuten: Laufwerkskopf, Laufwerkscontroller, Anschlusskopf am Kabel, das Kabel selbst (interner Kabelbruch), der Anschluss, an den das Kabel am Laufwerk angeschlossen wird, der Anschluss auf der Hauptplatine oder Tochterkarte, der Controllerchip auf der Hauptplatine oder Tochterkarte oder sogar ein Softwarefehler (irgendwo).
Wahre Geschichte: Ich hatte einmal einen RAID-Spiegel, der unzuverlässig war und ein Laufwerk ohne Grund ausließ. Die Laufwerke waren einwandfrei, die Platten waren sauber (wiederholte SMART-Durchläufe ergaben nichts) und alles funktionierte gut – bis es wieder und wieder ausfiel. Ich ersetzte das 3-Dollar-SATA-Kabel und die Problemesofortging weg. Die Moral der Geschichte: Es kann eine MENGE schiefgehen, und Sie können nicht immer davon ausgehen, dass „alles in Ordnung ist“, wenn Sie nicht jede Komponente im Datenpfad überprüfen.
Warum wurde ich nicht per E-Mail benachrichtigt?
Eine E-Mail-Benachrichtigung erfolgt nur, wenn (a) das Array aktiv überwacht wird oder (b) wenn das Array abgefragt wird.
Mein Ratschlag lautet: Sie müssen mdadm aktiv das Laufwerk-Array als Prozess überwachen lassen. Dies kann mit etwas Ähnlichem (aber nicht genau so) erreicht werden:
mdadm --monitor --scan --syslog
Sie müssen die obige Zeile an Ihre spezifische Installation anpassen.
Warum wurde der Fehler vor dem Anhalten des Systems nicht ordnungsgemäß ins Syslog protokolliert? Könnte es sein, dass das System versucht hat, sich ins Syslog zu protokollieren, dies aber nach dem Anhalten des Syslog-Daemons getan hat? Wenn ja, was kann ich tun, um dies zu verhindern?
Der Verlust der Protokollierung kann auf verschiedene Probleme zurückzuführen sein.
Zunächst einmal ist da die Frage, wie Syslog im Allgemeinen funktioniert. Obwohl viele Jahre darauf verwendet wurden, es robust und zuverlässig zu machen, gibt es bestimmte Randfälle, in denen Daten möglicherweise nicht auf die Festplatte gelangen. Dies ist ein bekanntes Designproblem, das aktiv mit einem Service-Management im Supervision-Stil (auch bekannt als Daemontools und dergleichen) angegangen wurde. Die Lösung bestand darin, Syslog vollständig zu umgehen und die Ausgabe in einen Logger zu schreiben, der jederzeit einen offenen Dateideskriptor hatte, sodass nichts verloren ging und der Logger die Ausgabe so schnell wie möglich auf die Festplatte schrieb. Dies ist zwar keine 100 % effektive Lösung, verbessert aber die Wahrscheinlichkeit erheblich, dass Ereignisse auf das Laufwerk geschrieben werden, bevor ein Kernel in Panik gerät oder herunterfährt.
Zweitens besteht die Möglichkeit, dass der Kernel in Panik geraten ist oder ein anderes Ereignis aufgetreten ist, das die Maschine in die Enge getrieben hat. Sogar fehlerhafte Hardware kann ein Problem verursachen - ich habe Maschinen mit unterdimensionierten Netzteilen gesehen, die unter Windows 8 spontane Abschaltungen verursachten. Ein Austausch des Netzteils hat das Abschaltproblem dauerhaft behoben. OffensichtlichNichtsWas der Kernel tun kann, schützt vor einer Maschine, die einfach entscheidet: „Ich habe genug davon“ und ins Neustart-Land davontapst.
Was kann ich tun, um herauszufinden, was passiert ist? Oder, wenn es für mich jetzt keine Möglichkeit gibt, herauszufinden, was passiert ist: Wie kann ich die Protokollierung und Benachrichtigungen verbessern, damit ich das nächste Mal eine bessere Nachbetrachtung durchführen kann?
Es gibt mehrere Ansätze:
Platzieren Sie die Protokollierung auf einer separaten Partition. Dies ist zwar keine Garantie dafür, dass Sie intakte Protokolle erhalten, es hilft jedoch dabei, Dateisystemprobleme zu isolieren, z. B. „Festplatte voll, kann nicht geschrieben werden“, „Beschädigung“, die eine erneute Bereitstellung in den schreibgeschützten Zustand verursacht usw. In diesen speziellen Fällen ist es sicherlich hilfreich.
Sehen Sie sich die Remote-Protokollierung wichtiger Systeminformationen an. Auch dies ist keine Garantie, aber es ist hilfreich, wenn das letzte Paket es „aus der Tür schafft“, bevor ein Neustart erfolgt, und dieses Paket wichtige Hinweise darauf enthält, warum der Neustart erfolgt ist.
Bei bestimmten, kritischen Diensten sollten Sie die Ausgabe an Syslog durch etwas anderes ersetzen, beispielsweise durch eine Protokollierung im Überwachungsstil, bei der ein dedizierter Logger die Ausgabe abfängt und so schnell wie möglich auf die Festplatte schreibt. Dadurch wird die Zuverlässigkeit der Ausgabe erhöht, die den Speicher erreicht. Mit ein wenig Arbeit kann dies parallel zu anderen Service-Management-Vorkehrungen erfolgen.
Antwort2
Was könnte dazu führen, dass die Festplatten plötzlich nicht mehr synchron sind?
Laufwerksfehler, Controllerfehler, ein anderer Hardwarefehler. Irgendein obskures Softwareproblem.
Warum wurde ich nicht per E-Mail benachrichtigt?
Ubuntu verfügt über einen Cronjob /etc/cron.d/mdadm, der dazu führt, dass die RAID-Volumes einmal täglich um 00:57 Uhr überprüft werden. Wenn Ihr System zu diesem Zeitpunkt keine Probleme hatte oder zu diesem Zeitpunkt bereits ausgefallen war, gab es keine Möglichkeit, eine Nachricht zu senden.
Warum wurde der Fehler vor dem Anhalten des Systems nicht ordnungsgemäß im Syslog protokolliert?
Nun, wenn Laufwerke ausfallen, ist es nicht wirklich sinnvoll, zu versuchen, darauf zu schreiben, da jedes weitere Schreiben alles zerstören könnte, was noch übrig ist. Da ich die genaue Ursache Ihres Fehlers nicht kenne, könnte es sein, dass Ihr Volume oder Dateisystem schreibgeschützt wurde. Standardmäßig ist Ubuntu so eingerichtet, dass es zu einem schreibgeschützten Dateisystem wechselt, wenn Fehler auf dem Stammvolume auftreten.
Wie kann ich die Protokollierung und Benachrichtigungen verbessern, damit ich beim nächsten Mal eine bessere Obduktion durchführen kann?
Richten Sie die Protokollierung auf einem Remote-Syslog-Host ein. Auf diese Weise bedeutet ein Speicherfehler nicht, dass nichts protokolliert werden kann.