03. Mai 2003 07:41h: 2 Stunden, teilweise bis zu 4,5 Stunden Total-Ausfall
Liebe Mitglieder und sonstige Hostsharing-Nutzer,Auswirkung
Am Samstag, den 3. Mai 2003 gab es von 7:41h bis ca. 9:20h einen Totalausfall. Danach, bis maximal ca. 12:15h waren noch einzelne Dienste bzw. die in den letzten Wochen neu aufgeschalteten Domains nicht erreichbar.
Ursache
Der Hauptserver (Pomo), der wegen der Umbauten an den anderen Servern (RAM, RAID etc.) zur Zeit sämtliche Pakete beheimatet, hat um 7:41h aufgehört auf höhere Dienste zu antworten. Nur Ping funktionierte noch. Die Ursache dafür ist noch nicht bekannt.
Details
Unglücklicherweise wurde KEIN SMS Alarm ausgelöst. Auch hierfür ist die Ursache noch nicht bekannt. Der Ausfall wurde daher erst zufällig um 8:00h von einem Hostmaster entdeckt. Auch gab es zu dem Zeitpunt noch keine Meldung per Telefon oder SMS von Nutzern.
Ein Reboot des Hauptservers Pomo scheiterte, er antwortet nach wie vor nicht. Im Laufe des Tages wird ein Hostmaster ins Rechenzentrum fahren und sich des Problems annehmen. Unglücklicherweise habe ich um ca. 8:05h den falschen Server, nämlich den Standby-Server Pima statt des Produktiv-Servers Pomo, neu gebootet. Daduch verzögerte sich die Startzeit der Aktivierung um ca. 30 Minuten (nötiges fsck).
Die Aktivierung des Standby-Servers verzögerte sich aufgrund folgender Umstände:
- Die /etc/passwd und /etc/shadow sowie /etc/group und /etc/gshadow werden nicht gespiegelt (geht auch aus Sicherheitsgründen nicht).
- Einige weitere Dateien mussten manuell zusammengeführt werden.
- Es lief ein Prozess auf dem Standby-Server Pima, der auf allen IP#n auf Port 443 gebunden hatte, so dass die HTTP-SSL Webserver nicht starten konnten.
- Wir haben noch keine Runlevel für Standby- und Produktiv-Modus, so dass einige Dienste (z.B. named) erst verzögert gestartet wurden.
Desweiteren sind folgende Fehler gemacht worden:
- Die Postfix Config-Datei enthielt als eigenen Host, den Hostnamen Pomo statt Pima. Dadurch wurden einkommende Mails für ca. eineinhalb Stunden abgewiesen (bounced).
- /home/doms ist nicht in der Spiegelung enthalten, so dass ca. 140 Domain-Links erst nachgezogen werden mussten.
- /etc/httpd*/httpd.conf und ip.conf sind ebenfalls nicht in der Spiegelung enthalten, so dass neue Pakete auch erst manuell nachgezogen werden mussten, leider hatten wir das nicht bemerkt und erst durch eine SMS von einem Mitglied um 14:45h erfahren.
- /etc/postfix/virtusertables.pacs fehlte ebenfalls in der Spiegelung, dadurch funktionierten die Adressen wie xyz00@hostsharing.net nicht mehr, jedenfalls nicht bei neuen Paketen.
- Die Newsserver haben offenbar wieder nicht dieselben Artikelnummern, so dass die falschen Artikel als gelesen/ungelesen gekennzeichnet sind.
Insgesamt haben wir unser Ziel, selbst bei einem Totalausfall der Hardware (und ein solcher liegt vor) spätestens nach 4 Stunden wieder vollständig online zu sein, um ca. 30 Minuten verfehlt. Die meisten Websites, wenn auch ohne SSL, waren jedoch nach weniger als 2 Stunden wieder online. Der Stand der Daten entspricht dem Zeitraum von ca. 5:30h bis 7:41h. Morgens läuft die rsync-Spiegelung leider immer sehr langsam und braucht ca. 2h für eine Durchlauf.
Maßnahmen
Um einen solchen Ausfall in Zukunft besser handzuhaben, schlage ich folgende Maßnamen vor:
- Ein Skript zum automatischen Zusammenstellen der passwd+shadow sowie group+gshadow Dateien. (DONE)
Das Skript heisst /usr/local/sbin/mk-passwd. - Standby-, Produktiv- und Wartungs-Modus müssen per Runlevel definiert sein. Sieh auch ToDo #148 in http://todo.hostsharing.net. (DONE)
- /home/doms muss in die Spiegelung aufgenommen werden. Temporär habe ich dort ein Skript .fix angelegt, welches fehlende Domains verlinkt. (DONE)
- /etc/httpd*/httpd.conf muss in die Spiegelung aufgenommen werden, die Includes per mk-httpd-conf erstellt werden. (DONE)
- /etc/postfix/virtusertables.pacs muss beim Aktivieren auch neu erstellt oder ins rsync aufgenommen werden. (DONE)
Ist nun im rsync. - Für die Spiegelung sollte in den Morgenstunden nach dem Backup mehr Bandbreite bereitgestellt werden, (DONE)
oder sogar die erste Spiegelung nach den Backups evtl. gar ohne Bandbreitenbegrenzung laufen. - Langfristig sollten wir eine 1:1 Spiegelung ermöglichen (sieh Hive-Vorschlag von mir, einige Wochen her). (TODO#255) Eine 1:1 Spiegelung würde die Aktivierung deutlich beschleuningen und Fehlerquellen beseitigen. Z.B. wäre damit auch das SSH-Host-Key und das Postfix-Problem gelöst.
Keine Lösung habe ich für folgende Probleme:
- Auswahl des falschen Servers für reboot im PDU Frontend. (Evtl. deutlicher verschiedene Hostnamen?)
- Verschiedene Artikelnummern in den Newsservern.
Für den Ausfall, insbesondere die durch meinen Fehler verursachte Verzögerung bei der Re-Aktivierung, bitte ich im Namen der Hostmaster um Verzeihung.
- Michael Hönnig
Hostmaster Hostsharing eG

