Eine hundertprozentige Verfügbarkeit ist etwas, was es in der Informatik nicht gibt. Ein Umstand der in 99.9% der Zeit, in der alles gut läuft, gerne in Vergessenheit gerät.
Ein Problem auf Server 35 hat uns und unsere Kunden, welche auf diesem System zu Hause sind, schmerzlich daran erinnert. An zwei Tagen im Dezember und drei Tagen im Januar war der Server während insgesamt knapp 3 Stunden nicht erreichbar. Einzelne Dienste wie Web oder E-Mail waren sogar noch etwas länger nicht verfügbar.
Das Beste aber gleich zu Beginn: Der Fehler ist inzwischen gelöst. Doch der Reihe nach:
Rien ne va plus
Am 12.12.2011 gab es einen Ruck auf unserem Server 35. Nichts ging mehr und die einzige Möglichkeit den Server wieder zum Laufen zu bewegen war es, diesen neu zu starten.
Wie bei uns üblich, wurde nach dem Vorfall sofort geprüft, was denn die Ursache für das Problem gewesen sein könnte. Nach einigem Nachforschen schien klar: Die Ursache war ein Fehler in der Hardware, genauer im sog. Disk Controller Cache. Oder doch nicht?
Neue Hardware im Eiltempo
Das Problem trat am nächsten Tag erneut auf. Zeit für unseren Notfallplan, das komplette System auf einen Standby-Server zu migrieren. Dank Bladeservern geht dies innert Minuten, es müssen lediglich die lokalen Disks in das neue System umgezogen werden.
Geht mal ein Lämpchen aus, steht ein Ersatzserver bereit.
Doch auch auf dem neuen System währte die Ruhe nur kurz: Das neue System zeigte das gleiche Verhalten. Lag das Problem also doch an einer Softwarekomponente? Unsere Nachforschungen gingen nun in die verschiedensten Richtungen.
Entlasten
Die üblichen Massnahmen zur Problemfindung waren fürs erste ausgeschöpft und so begannen wir, Kunden von Server 35 weg zu transferieren. Dies gab uns die Möglichkeit, Server 35 zu entlasten und so möglicherweise dem Problem auf die Schliche zu kommen.
Und siehe da, das Problem trat nicht mehr auf. Zumindest vorerst. Der Fehlerteufel machte wohl Weihnachtsferien.
Externe Expertise
Im neuen Jahr zeigte sich das Problem dann plötzlich wieder: Der Server blieb stehen und liess sich nur durch einen Neustart wieder zur Arbeit zu bewegen. Unsere Köpfe rauchten, denn die Ursache war unklarer denn je.
Bei einer Störung holen wir uns sehr rasch auch externe Hilfe hinzu. Der Serverhersteller lieferte uns weitere Diagnosetools um die Hardware nochmals zu prüfen – doch hier war alles im grünen Bereich.
Ab und zu trägt auch ein frisches Paar Augen zur Lösungsfindung bei. Wir greifen deshalb gerne auf befreundete Experten zurück, um eine Zweitmeinung einzuholen. Doch leider beschränkte sich die Ausbeute auch hier auf ratloses Schulterzucken.
Als dritte Partie im Bunde belieferten wir den Hersteller unseres Betriebssystems mit Logdaten und Kerneldumps. Dieser versorgte uns wiederum mit modifizierten Kerneln, die wir auf unserem Testsystem ausprobierten. Doch eine schnelle Lösung lag nicht in Griffnähe.
Phantasie ist gefragt
Während der Problemsuche ist es stets oberste Priorität, die Systeme so verfügbar wie möglich zu halten. Und dabei ist manchmal auch ein Griff in die Trickkiste erforderlich.
In diesem Fall zeigte sich zum Beispiel, dass bei den ersten Anzeichen des Problems (was in diesem Fall ein erhöhter I/O Wait war) ein rechtzeitiger Neustart des Webservers den Totalabsturz des Servers verhindern konnte. Ein kleines Script übernahm diese Aufgabe und konnte das System so weitgehend stabil halten.
Endlich: Land in Sicht
Wir hatten wieder damit begonnen, Kunden vom Server weg zu transferieren. Und endlich kamen wir so auf die richtige Fährte. Denn plötzlich trat das Problem auf dem neuen Server auf, auf welchen diese Kunden transferiert wurden. Nun war klar: die Ursache musste durch einen bereits transferierten Kunden verursacht worden sein. So konnten wir nach Prüfung sämtlicher in Frage kommenden Kundenscripts den Fehler ausfindig machen.
Übeltäter mod_rewrite
Schuld am Ganzen waren am Ende eine dreizeilige, jedoch komplexe, Rewrite-Anweisung. Diese führte dazu, dass der gesamte Zwischenspeicher des Servers (immerhin 48 GB plus 10 GB Swap) durch eine Endlosschlaufe innert Sekunden gefüllt wurde und das System zum Erliegen brachte. Die eingebaute Loop-Protection des Webservers konnte diese Schlaufe nicht abfangen, da sich der entsprechende Wert bei jedem Schlaufendurchgang veränderte.
Eigentlich darf so etwas nicht passieren. Wir betrachten dieses Verhalten daher als Bug des Webservers. Da es sich um eine Anweisung handelt, die auch bei anderen Anbietern zu Problemen führen kann, möchten wir die genaue Anweisung hier nicht publizieren.
Fazit
Auch wenn wir ein Betriebssystem einsetzen, welches den grössten Teil aller Prozesse einkapseln und unter Kontrolle halten kann, gibt es Konstellationen, die Fehler auslösen. Wir arbeiten zusammen mit dem Hersteller unseres Betriebssystems daran, auch solche speziellen Konstellationen in Zukunft automatisch abfangen zu können. Das System wird also ständig verbessert und wir gehen davon aus, dass ein vergleichbares Problem in Zukunft nicht mehr auftaucht.
Bei allen betroffenen Kunden möchten wir uns noch einmal in aller Form für die Unannehmlichkeiten entschuldigen.
Bei Fragen steht Ihnen unser Support gerne via support@cyon.ch oder unter der kostenlosen Telefonnummer 0800 840 840 zur Verfügung.