Server 35: ein Rückblick auf die Geschehnisse
Philipp Zeder
Kategorie:in
Über cyon
Veröffentlicht am 10. Jan. 2012
Aktualisiert am 29. Apr. 2024
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.
Beteilige dich an der Diskussion
19 Kommentare
@Philippe Der betroffene Kunde ist natürlich informiert.
Vielen Dank noch einmal an alle für die vielen positiven Feedbacks.
Ein Webprojekt von mir war davon auch betroffen und ich gehe mal nicht davon aus, das ich’s war. Zumindest änderte ich seit über einem Jahr nichts an meiner htaccess Datei.
Vielen Dank für eure offene Kommunikation – ich schätze das sehr!
Sehr interessant. Und schön, dass Ihr das publiziert. Danke. Bin immer wieder sehr zufrieden, dass ich zu Euch geweschselt habe.
@Zeni Merci für Dein Feedback. Ja dieser Test im K-Tipp beachtet wirklich fast nur den Preis, obwohl im Text sehr viele Variablen angegeben sind. Dass diese auch wirklich überprüft worden sind, bezweifle ich aber.
Wiedermal eine super Kommunikation! Bravo! DAS ist es, was für mich ein gutes, innovatives Unternehmen ausmacht.
Nur leider wollen das DAU-Tester wie die vom K-Tipp nicht einsehen und bewerten nur den Preis (mal abgesehen davon, dass es noch 30 weitere technische Variabeln gäbe). :/
@Anonymous Ich geb’s gern an unsere Techniker weiter :)
@all Wir suchen übrigens einen Linux System Engineer. Alle Infos dazu gibt es unter https://www.cyon.ch/ueber-cyon/jobs. Und nein, das hat nichts mit diesem Vorfall zu tun.
Ich finde es toll, wie transparent und ehrlich ihr kommuniziert. Weiter so!
Spannend!
Danke für die offene Kommunikation.
Glaubt mir, bei 48 GB Speicher braucht kein Webserver irgendwelchen Swap. Einfach ein “swapoff -a” ausführen :-)
Damit bei solchen Monster-Prozessen das System doch noch auf eure Anliegen reagiert, empfehle ich euch verschiedene Prozesse zu priorisieren. Ein “renice -20” auf “getty” und “sshd” erhöht die Chance erheblich, dass ihr bei solchen Vorkommnissen wenigstens eine Shell zu Gesicht bekommt. Hintergrundprozesse (z. B. ein MTA) sollten mit tiefer Priorität arbeiten.
Mit dem schnell in Vergessenheit geratene Shell Befehl “ulimit” könnt ihr solche Ereignisse komplett eliminieren.
@Silas Ich verstehe Deinen Ansatz. Es ist auch nicht so, dass wir nur böses vermuten. Unsere Erfahrung hat aber gezeigt, dass solche Sachen gerne ausprobiert werden, nachdem sie veröffentlicht werden. Das möchten wir zumindest vorerst nicht noch fördern.
@Marcel Danke. Die bereits transferierten Kunden werden nicht zurücktransferiert und verbleiben auf Server 41.
Sehr offen kommunizert, bravo!
Eine Frage bleibt: werden die betroffenen Seiten wieder zuürck auf Server35 geschoben oder bleiben die jetzt auf Server41?
@Philipp & Remo: Klar soll das nicht die bösen Geister auf den Plan rufen. Aber es wäre vielleicht hilfreich für die Zukunft, dass solche Sachen nicht mehr passieren. Immer gleich das böse im Menschen vermuten find ich den verkehrten Ansatz.
Cheers
@Silas Wie von Remo korrekt erkannt, möchten wir den Code nicht veröffentlichen und so böse Geister auf den Plan rufen.
@Anonymous Das Problem war eben, dass der Prozess nicht gekillt wurde. Wir stehen mit den Herren von CloudLinux, unserem Betriebssystem, in engem Kontakt und werden auch prüfen ob Swap auf unseren Servern Sinn macht bzw. ob die Server auch ohne Swap problemlos funktionieren.
Merci auf jeden Fall für den Hinweis.
Was? 10 GB Swap auf einem Webserver? Swap gehört auf den Desktop und nicht auf einen Webserver mit 48 GB RAM. Bitte dieses Relikt der Vergangenheit auf 0 GB verkleinern – ansonsten werdet ihr weiterhin solche Probleme haben.
Meine Vermutung: httpd Prozess füllt den Speicher + kopiert 10 GB Daten auf die Platten -> Kernel killt diesen Prozess -> Festplatten I/O Spiel geht von vorne los.
So was nenne ich absolute Firmen-Transparent.
Gutes Wording, auf den Punkt gebracht und ehrlich… Chapeau!
(Kompliment an den Writer)
@Silas:
“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.”
Die einigen Zeilen des mod_rewrite-Codes könnten Missbraucht werden – das will doch niemand oder etwa doch? :o
War ich das etwa ??
Hallo Cyon-Team
Ich kenne solche Situationen nur zu gut! Gibt es eine Möglichkeit für Server35 Kunden diese 3 mod_rewrite Zeilen einzusehen?
cheers
s
meine 0.3 euro (vor allen dingen an die anonymous-trolls):
wieso sollte der kern denn nen prozess killen, nur weil der mal eben 10 GiBiBytes irgendwo hinkopiert? das läuft ja über config und ist meines wissens nicht built-in. und kopieren macht man noch oft!
und bezüglich !swappen: klar, bei 48G-servers kommt man wohl nicht so schnell an die grenze, wo geswappt wird. doch wir reden hier ja von v-web-servers mit allenfalls vielen kunden und requests und allem.
meine empfehlung: swap anlassen, aber so konfigurieren, dass erst im letzten moment rausgepaged wird.
und nen kleinen monitor einschalten, der das noch dem techie mailt… dann kann sich der ne schöne metrik zurechtbasteln und weiss genau, wann seine servies zu rauchnen anfangen bzw. dass sein pikett stressig wird, weil die mühlen zu weihnachten immer rumzikken (hat ja vielleicht ne kleine weihnachts-grüsse-verschick-app auf system 35, womit alle grossmütter ihren verzogenen grosskindern digitale postkarten schicken. natürlich alle gleichzeitig um 7 uhr am morgen).
aber wenn der speicher verbraucht ist, dann pummeln wenigstens keine prozesse ab, wenn geswappt werden kann. wird halt langsamer, aber der techie kann dann gemütlich seinen kater pflegen, bevor er via ssh mal die lage beurteilt!