Ungeplant geplante Nachtschichten

Eigentlich lief heute Nacht alles planmäßig: Upgrade eines Kundenservers mit mehr RAM, größere Festplatte und einer neuen CPU.

Die Backups waren um 00:00 Uhr angelegt, der Support bestätigte den Upgradetermin von 01:00 Uhr. Damit sich keine Daten ändern, die dann im Backup nicht mehr sind, wurden gegen 00:45 Uhr alle Dienste beendet, und ein letztes Backup gemacht.

Das war aber schon der letzte Punkt, der planmäßig ablief …

Erst gegen 01:50 Uhr wurde der Server aus der Colo zum Upgrade gebracht, und war dann erst gegen 04:30 Uhr wieder online – muss wohl ziemlich stressig gewesen sein, die Nachtschicht.

Anschließend, später als geplant, die Daten aus dem Backup zurückgesichert – da das bei einigen Gigabyte etwas dauert, kann man sich hier eine Mütze Schlaf gönnen, bis 07:00 Uhr. Da war der Restore-Vorgang fertig, fehlt nur noch das Booten des Systems.

Kein Problem: Grub installiert, Kernel überprüft, reboot – und ab hier liefs schlecht: Der Server war nicht erreichbar, es gab auch keinerlei Log-Einträge des Bootvorgangs, der Server crasht also schon, bevor überhaupt Festplatten gemountet werden können. Nur: Remote, ohne Zugriff auf die lokale Konsole, ist die Diagnose ziemlich schwer.

Keiner der bisherigen „Tricks“ brachte Erfolg, bis das Rechenzentrum gegen 09:30 Uhr einen Blick auf den Server warf: Der RAID-Controller wurde nicht erkannt.

Laut Upgrade sollten nur Festplatten, CPU und RAM getauscht werden, der Rest sollte Orginal bleiben … nach einer Kontrolle war das aber hinfällig: das Board wurde ebenfalls ausgetauscht (geänderte MAC-Adresse), und aus dem 3ware-RAID-Controller wurde ein HighPoint RocketRaid 3120-Controller, der bisher noch nie verbaut wurde.

Google offenbarte dann noch, dass der 2.6.18-Kernel (Default von Debian Etch) nichts mit dem Controller anfangen konnte … also noch den Kernel aus dem Rescue-System „geklaut“, gebootet – und wieder nix.

Hier Dank an den Mitarbeiter im Rechenzentrum, der sich das System angeschaut hat, und letztendlich um 10:15 Uhr dafür sorgte, dass der Server wieder online war. Er bestätigte auch das getauschte Board/Controller, da es wohl Probleme mit der neuen CPU gab. Eine Information direkt in der „Up-Mail“, dass mehr Teile getauscht wurden, als ursprünglich geplant, wäre jedoch eher von Vorteil gewesen.

Als der Server online war, gabs dann auch den restlichen Schlaf …

Was lernen wir daraus?

Erstens kommt es anders, und zweitens als man denkt …

Und: bei weiteren Upgrades immer überprüfen, welche Hardware nun genau verbaut ist, erspart aufwändige Fehlersuche in Dateien, die sowieso nichts mit dem Problem zu tun hatten …

Für unsere eigenen Server wurde der Punkt der lokalen Konsole behoben: Wir haben einen KVM over IP-Switch angeschafft, der noch vor Weihnachten zusammen mit einem Remote Power-Control an den Servern angebracht wird. Somit kann über das Internet Zugriff auf den Server genommen werden, als ob man direkt vor dem Server mit Tastatur/Maus/Monitor sitzt. Fehlermeldungen, die während dem Bootvorgang auftreten, können so von überall eingesehen werden, ohne im Rechenzentrum vor Ort zu sein.

Post navigation


Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>