Der neue Switch ist ein 3com Baseline Switch 2924-SFP-Plus, wodurch wir nun Server mit 1 Gigabit anbinden können.

Housing-Kunden, denen die bisherige 100MBit-Verbindung nicht ausreicht, können uns gerne kontaktieren, Upgrades sind ohne Ausfall der Netzwerkkonnektivität möglich.

Die HTML-Version der Rundmail finden Sie unter folgender URL: http://www.aditsystems.de/nl/2009-07-17.html

1. Wartungsarbeiten

Wie Sie dem Betreff bereits entnehmen können, sind wir gezwungen, Wartungsarbeiten am Server venus.a1a-server.de, auf dem sich Ihre Webpräsenz befindet, durchzuführen.

Betroffen von den Wartungsarbeiten sind ausschließlich Kunden, deren Benutzername mit “web” beginnt.

Um den regulären Betrieb so wenig wie möglich zu stören, werden wir diese Arbeiten am Samstag, den 18.07.2009, zwischen 00:00 Uhr und 05:00 Uhr durchführen.

Während dieser Zeit kann es zu Störungen der Erreichbarkeit Ihrer Webseite und der weiteren Dienste kommen.

Grund für die Wartungsarbeiten ist der ausgeschöpfte Platz im angemieteten Rack im Rechenzentrum, weshalb wir die Serversysteme in ein neues, größeres Rack umziehen.

2. Serverstatus

Über den aktuellen Status unserer Server können Sie sich immer auf folgender Webseite informieren:

http://serverstatus.aditsystems.de/

Wir bitten um Verständnis für die Störung und verbleiben

Mit freundlichen Grüßen,
Ihr Team von ADIT Systems

leider müssen wir am Samstag, den 27.12.2008, im Zeitfenster zwischen 00:00 und 03:00 Uhr Wartungsarbeiten am Server Venus, auf dem auch Ihre Webseite sich befindet, durchführen.

Durch die Wartungsarbeiten kommt es zu kurzzeitigen Störungen der Erreichbarkeit.

Wir bitten um Verständnis für die Arbeiten und wünschen Ihnen ein erholsames Weihnachts-Wochenende.

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.

Grund war – wie vom Rechenzentrum mitgeteilt wurde – eine Störung in einem der Router, die alle daran angeschlossenen Racks betraf.