Am vergangenen Samstag kam es in unserer Cloud zu einem Failover Fall. Eine seit Jahren problemlos funktionierende, überwachte Komponente hat plötzlich den Dienst verweigert und somit Fehlalarme ausgelöst.

Bevor ich auf die genauen Umstände und unsere, teilweise automatischen, Reaktionen dazu eingehe, möchte ich die Gelegenheit nutzen und kurz den Aufbau unserer Cloud erklären.

Der Weg eines Alarms

Der Weg eines Alarms vom Kundensystem durch unsere Cloud und eventuell wieder zu Ihnen per Email zurück ist ein langer Weg durch etwa 15 eigenständige Komponenten.

Aufbau Cloud

In dieser vereinfachten Ansicht sehen wir, dass die Daten Ihrer Kundensysteme und Ihrer eigenen bei uns im Rechenzentrum von einer Firewall angenommen werden. Die Verbindung wird danach direkt von einem Reverse Proxy übernommen, welcher das SSL terminiert und anhand verschiedener Kriterien die nächste Komponente für diese Daten festlegt.

Im Fall einer Alarmierung werden die Daten erst von einer Komponenten aus der Verbindung gelesen und zwischengespeichert. Die nächste Komponente greift dann ein, wertet die Daten aus und speichert sie in der Datenbank. Außerdem legt sie fest, ob ein Benutzer alarmiert werden muss, wie er alarmiert wird und auch wann. Auch das wird in der Datenbank eingetragen und abschließend von einer letzten Komponente ausgeführt.

Fällt eine dieser Komponenten aus steht der komplette Prozess. Um dies zu verhindern haben wir alle Prozesse von Server-Eye redundant ausgelegt. In der Vergangenheit hatten wir alle unsere Komponenten in einem großen virtuellen Cluster mit mehreren Hosts. Komponenten konnten von einem Host auf den anderen geschoben werden, der Storage war ein Cluster Storage, etc. Mit der Zeit haben wir festgestellt, dass durch die komplette Virtualisierungsstruktur weitere Fallstricke und neue Probleme entstehen. Komponenten, die anderen Komponenten CPU Zeit stehlen, Performance Probleme des Netzwerkstorage und den Cluster Storage Services, etc. Unser Szenario mit mehreren 100 Maschinen, die permanent die gleiche Last tragen und kaum Spitzen in der Ressourcenauslastung haben, war einfach nicht ideal für diese Art von Virtualisierung.

Der jetzige Aufbau

Unser Anspruch war es daher das oben gezeigte simple Schaubild mit möglichst hoher Redundanz, Skalierbarkeit und einfacher Verwaltung umzusetzen. Dieses System verwenden wir nun seit etwas mehr als einem Jahr.Aufbaut Cloud mit Pods

Ein Pod ist ein Virtualisierungshost und stellt alle Komponenten bereit, die Server-Eye benötigt. Er enthält das OCC, API, Verarbeitung der Alarme, etc. Ein Pod bildet somit ein autark funktionierendes Server-Eye ab. Wird ein Pod abgeschaltet oder funktioniert nicht beeinträchtigt dies nicht die anderen Pods. Komponenten müssen und können im Fehlerfall nicht auf einen anderen Pod umziehen. Es gibt keinen Netzwerkstorage mehr. Dies spart uns viel Overhead und Ressourcen ein, die vorher in Cloud Services und ähnliche verschwunden sind.

Die Firewall und der Reverse Proxy sind redundant vor die Pods geschaltet. Durch ein Source Balancing landet Ihr Kunde immer auf dem gleichen Pod. Dies erleichtert uns die Arbeit bei Support Fällen enorm, da zum Beispiel im Hilfebereich des OCC für Sie ersichtlich ist welchen Pod sie nutzen. Mit dieser Information können wir Problemen schneller auf die Spur kommen.

Müssen Wartungsarbeiten oder Updates durchgeführt werden lässt sich im Reverse Proxy einfach der entsprechende Pod abschalten. Die Verbindungen verteilen sich dadurch auf die anderen Pods um und es gibt nur noch sehr wenige Wartungsfenster, die tatsächlich die Funktionalität von Server-Eye beeinträchtigen.

Zusätzlich lassen sich neue Technologien, Komponenten und Verbesserungen nun sehr leicht mit einem kleinen Kundenkreis temporär testen, bevor Sie auf den anderen Pods für alle ausgerollt werden.

Der Failover Fall

Es kann immer passieren, dass eine Komponente ausfällt, zu langsam arbeitet oder etwas unerwartetes passiert. Aus diesem Grund läuft auf jedem Pod ein eigenes Monitoring. Dieses Monitoring ist eine Eigenentwicklung speziell auf unsere Struktur angepasst. Es prüft verschiedene Szenarien, die auf einem Pod zu Problemen führen können und alarmiert immer die Server-Eye falls eines der Szenarien eintritt. Der Reverse Proxy vor den Pods fragt regelmäßig die einzelnen Monitoring Systeme nach Ihrem Status und schaltet den Pod ab, falls der Status nicht zufriedenstellend ist.

Die alarmierten Techniker prüfen die involvierten Komponenten, beheben das Problem und schalten den Pod wieder aktiv. Der Failover Fall wird also voll automatisiert eingeleitet, immer die Server-Eye Techniker informiert und manuell behoben.

Failover Szenarien und dieser Samstag

Wie erwähnt kam es diesen Samstag zu Fehlalarmen. Eine extrem zuverlässig arbeitende Komponente wird bereits seit langem überwacht und wird automatisiert gestartet, falls sie abstürzen sollte. In diesem Fall hat aber das Startscript, welches auch beim Serverstart ausgeführt wird, um die Komponenten zu starten, nicht mehr funktioniert. Dieses Szenario ist nicht über ein weiteres Monitoring abgedeckt. Dadurch griff das Monitoring mit dem Einleiten des Failover Falls erst nach wenigen Minuten, anstatt wie üblich nach ein paar Sekunden, ein. Durch den schnellen manuellen Eingriff konnte der Grund des Ausfalls schnell behoben und die Funktionalität nach kurzer Zeit wieder hergestellt werden.

Ergebnis

Die genauen Details, wieso die Komponente ausgefallen ist, befinden sich noch in der Analyse. Für uns ergibt sich aber vor allem die Erkenntnis, die man im Tagesgeschäft nicht immer wahrhaben möchte. Selbst die sicherste und zuverlässigste Komponente wird irgendwann ausfallen. Auch darauf sollte man vorbereitet sein und es im Idealfall vorher erkennen. Wir werden uns deshalb nochmals unsere Failover Szenarien ansehen und das Monitoring der einzelnen Komponente erweitern. Hätte das Monitoring diesen Fall sofort erkannt, hätten wir eher eingreifen können.

Bei Fragen zu unserer Cloud können Sie sich gerne jederzeit an uns wenden und eventuell hat der Artikel auch Ihnen ein paar Denkanstöße geliefert.