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


Leave a Reply

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>