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.
