25. Mai 2003 05:59h: je nach Dienst 3 bis insgesamt 19 Minuten Ausfall durch Wartungsarbeiten
Liebe Mitglieder und sonstige Hostsharing-Nutzer,Auswirkung
Von 5:59h bis 5:11h waren die mySQL-Server nicht erreichbar. Um 5:16h startete ein Reboot des Servers, so dass bis SMTP und SSH bis 5:18h, FTP und POP3 bis 5:20h und HTTP sowie die Datenbanken bis 5:24h nicht zur Verfügung standen.
Ursache
Bedingt durch den Umzug in der Nacht zum Freitag haben wir sicherheitshalber einer offline Prüfung/Reparatur der mySQL-Datenbanken durchgeführt. Außerdem wurde der mySQL-Betriebsmodus geändert, u.a. um für einen zentralen phpmyadmin für mehrere Server gerüstet zu sein.
Der Reboot war notwendig, um /tmp neu, ohne ext3 zu mounten. ext3 im Zusammenhang mit Quota führt unter Last leider zu Deadlocks, und damit zu dem Problem, welches vermutlich in der Nacht zum Freitag den Ausfall verursachte. Die Änderung wäre auch ohne Reboot möglich gewesen, doch ist ein Reboot vorhersagbarer, was die Länge des Ausfalls betrifft. Ohne Reboot hätten wir dafür sorgen müssen, dass kein Prozess mehr auf /tmp zugreift, was sich selbst bei Abschaltung aller zentralen Dienste als schwierig herausgestellt hat. Die Dienste wären in jedem Fall für ein paar Minuten ausgefallen.
Details
Der zentrale Webserver für DW und der zentrale Webserver für DS Pakete startete leider durch den Runlevel nicht. Die Ursache ist nicht bekannt, eingetragen sind beide für den Runlevel 4 (Production).
Es dauert relativ lange bis alle Webserver nacheinander gestartet sind. Daher werden die httpd-* Skripte in Zukunft im Hintergrund gestartet (ist bereits geändert).
Maßnahmen
Die Wartungsarbeiten selbst sind optimal verlaufen. Dass diese überhaupt notwendig waren, sollte in Zukunft vermieden werden:
- Der Plan für einen offline-Umzug steht noch aus. (TODO)
Dies hätte die nachträgliche mySQL-Prüfung erspart, andererseits aber auch den Ausfall von der Nacht zum Freitag um 12 Minuten verlängert. Ideal wäre eine online Prüfung der mySQL-Datenbanken, praktisch ist es möglich, es ist aber noch zu prüfen, ob das auch sauber ist. - Ein Kernel-Fix für das Deadlock-Problem im ext3 Modul wäre sehr wichtig. (TODO)
- Vorerst sollten wir wenigstens prüfen, ob wir versehentlich wieder ein Device mit ext3 und Quota mounten. (DONE)
Für den Ausfall bitte ich im Namen der Hostmaster um Verständnis.
- Michael Hönnig
Hostmaster Hostsharing eG
