Wie gehen wir damit um, wenn etwas schief geht? Fehlersuche, Fehlerbehebung, Problemanalyse und Transparenz.
Zunächst die Kurzfassung: wir haben einen Konfigurationsfehler gemacht, der viele Monate ohne Nebenwirkungen und unentdeckt geblieben ist. Zufall und Last haben den Fehler aufgedeckt: Lemniscus war einige Male für ein paar Minuten nicht erreichbar. Die Fehlermeldungen, die wir bekommen haben, waren insofern kontraproduktiv, da sie uns in die falsche Richtung haben suchen lassen.
Wir haben den Fehler gefunden, behoben und im Nachgang Teile der Infrastruktur überarbeitet.
Fangen wir mit dem Thema Transparenz an.
Es sind nur sehr wenige Kunden von dem Ausfall betroffen gewesen, dennoch ist es uns sehr wichtig, eine Stellungnahme zu dem Vorfall zu veröffentlichen.
Wir sind so organisiert, dass wir gleich mehrere Überwachungssysteme haben. Wir haben sogar eine öffentliche Verfügbarkeits-Seite, die für jeden erreichbar ist:
Neben einem internem Monitoring haben wir noch unsere Anwender, die uns schneller als jedes Überwachungstool mitteilen können, wenn irgendwas schief geht - was prinzipiell eine tolle Sache ist.
Wir nutzen auch Twitter als Status-Seite - also für wichtige Meldungen wie
- Ankündigung von Wartungsarbeiten
- Ankündigung von Updates/ Hotfixes
- Statusmeldungen in Krisensituationen
Gerade die Statusmeldungen in Krisensituationen sind der effizienteste Weg, mit einer großen Anzahl Betroffener so zu kommunizieren, dass wir trotzdem noch Fehlersuche und Fehlerbehebung betreiben können:
Zunächst eine kurze Erklärung, wie Lemniscus aufgesetzt ist.
Wir betreiben Lemniscus verteilt, inzwischen teilweise auf drei physisch getrennten Rechenzentren. In jedem Rechenzentrum haben wir eigene virtuelle Netzwerke, Firewalls, Routing- und Sicherheitskonfigurationen. Wir betreiben die Datenbank gespiegelt auf zwei Datenbank-Server auf zwei Rechenzentren: die Last-Verteilung wird so durchgeführt, dass lesende Zugriffe auf dem sogenannten Spiegel stattfinden, schreibende Zugriffe auf der “Master-Datenbank”. Bei höherer Last wird im dritten Rechenzentrum ein weiterer Spiegel vollkommen automatisch hochgefahren (und wieder runtergefahren, wenn die Last geringer wird). Zusätzlich betreiben wir zwei verteilte Cache-Server, die Suchergebnisse und Berechnungen für kurze Zeit zwischenspeichern. Und dann natürlich die eigentlichen Anwendungs-Server, die die eigentliche Lemniscus-Anwendung betreiben. Das Ganze ist von außen nicht erreichbar, so dass wir einen VPN Server bei bedarf starten, um uns in das System einwählen zu können. Das Ganze betreiben wir noch ein zweites Mal als Test-Umgebung und zusätzlich halten wir noch einen Anwendungs-Server “bereit”, der aber nicht in der Infrastruktur eingebunden ist, damit wir Hotfixes erst dort ausrollen können.
Netzwerktechnisch geht jeder Aufruf zunächst an einen Last-Verteiler (Load-Balancer), der dann den Aufruf an einen Proxy auf einem der verfügbaren, eingebunden Anwendungs-Server weiterleitet. Der Proxy wird dann den Aufruf an die eigentliche Lemniscus-Anwendung intern auf dem Rechner weiterleiten. Die Lemniscus Anwendung wird dann mit Cache- und Datenbankservern kommunizieren. Deswegen ist das Routing so wichtig: über Netzwerkregeln wird von uns festgelegt, welche Systemkomponente mit wem wann und wie kommunizieren darf.
Kommen wir zum Fehler…
Die Einbindung des dritten Rechenzentrums vor einigen Monaten hatte ein Konfigurationsfehler im Netzwerkrouting, diese wurden von uns zu restriktiv eingestellt, so dass Anwendungs-Server aus dem dritten Rechenzentrum keine Verbindung zu einem der verteilten Cache-Server zu einem bestimmten anderem Rechenzentrum aufbauen konnte. Klingt kompliziert, ist es aber eigentlich nicht. Wir haben eine Strasse blockiert und in Folge hatten wir einen kolossalen Stau. Kennt jeder.
Damit wir die Elastizität des Gesamtsystems sicherstellen können, müssen die Server je nach Bedarf auch mit Servern auf anderen Rechenzentren kommunizieren können. Elastizität? Anwendungs-Server werden bei uns je nach Bedarf hinzugefügt und entfernt - und zwar täglich. Sobald die CPU-Last eines Anwendungs-Servers die 40% übersteigt, wird ein weiterer Server hochgefahren. Fällt die CPU-Last pro Server unter 15%, dann wird ein Server aus der Farm entfernt und gelöscht. Bei CPU Lasten über 50% bei den Datenbank-Servern wir ein weiterer Datenbank-Spiegel automatisch hochgefahren.
So kommt es, dass Anwendungs-Server bei uns unter der Woche selten länger als einen Tag in Betrieb sind, da wir bei einem Abbau der Rechenkapazität immer die am längsten laufenden Server zuerst entfernen. In welchem der drei Rechenzentren der nächste Server hochgefahren wird, ist von uns nicht vorgegeben. In den letzten Monaten haben wir nie die Situation gehabt, einen dritten Anwendungs-Server zu benötigen, und die Server, die neu hinzugekommen sind, wurden immer in den anderen zwei Rechenzentren angelegt. Dieses Verhalten hat sich offensichtlich letzte Woche geändert, und es wurde oft ein Anwendungs-Server im dritten Rechenzentrum hochgefahren.
Als der Fehler identifiziert wurde, war die Fehlerbehebung sehr einfach, was uns gleichermassen gefreut und geärgert hat.
Als Folge zu den Ausfällen haben wir die Infrastruktur der Anwendungs-Server modernisiert.
