Nichtverfügbarkeit von Cluster Systemen

So lernt man das ja an der Uni: jeder Server hat eine gewisse Ausfallwahrscheinlichkeit. Nimmt man einen zweiten dazu, ist die Wahrscheinlichkeit, dass beide zum selben Zeitpunkt ausfallen um Größenordnungen geringer. Man braucht "nur" noch ein wenig Intelligenz, die mitbekommt, dass der eine nicht mehr da ist und die Kontrolle an den anderen übergibt. Dummerweise ist diese Umschaltung nicht ganz trivial:

• mindestens mal hat man eine neue Komponente eingeführt, die sich um die Überwachung der beiden Clusterknoten kümmert und die Servicerolle umschalten muss. Diese Komponente kann aber selbst - wie alles - kaputt gehen oder sich irren
• dann muss man noch dafür sorgen, dass alle Clusterkoten dieselben Daten haben, was unter Umständen auch nochmal zusätzliche Komplexität bedeutet
• und man hat viel mehr Zustände, die ein solch komplexes System annehmen kann und einen vielfach höheren Aufwand das einzurichten und zu testen.
• Einen Aspekt hatte ich ja schon beim "platten Reservereifen" beschrieben: man muss sich auch darum kümmern, dass der alternative Clusterknoten startklar ist, also den regelmäßig testen und überwachen.

In der Praxis musste ich leider die Erfahrung machen, dass Clustersysteme manchmal eben viel öfter ausfallen, als die darunter liegenden Server (das kam mir in all den Jahren übrigens nie vor). Ein Beispiel war die zentrale Newsroom Applikation in einem Nachrichtensender. Was da so alles passierte:

• der Clustermanager war sehr oft (etwa einmal im Monat) der Meinung, der aktive Knoten funktionierte nicht mehr und fing an den runter zu fahren, um dann die Datenbank zu schwenken und den anderen Knoten hochzufahren, was schon ein paar Minuten dauerte (wesentlich mehr Minuten, als der Chefredakteur brauchte, seine Lieblingsnummern abzutelefonieren).
• Es gab natürlich auch ein Test- und Spielsystem, nur hatte man da die kostspielige Clusterlösung weggelassen. So gab es inhouse kein tiefes Knowhow, wie man denn mit der Clustersoftware  umgeht, denn die lief nur auf dem Produktivsystem, von dem man schön die Finger ließ. Und "bei anderen Kunden ist so etwas noch nnnniehh aufgetreten", deshalb wusste man beim Lieferanten auch nicht so genau, wie man dem überdrehten Umschalter etwas mehr Geduld beibringt, falls ein gestresster Clusterknoten mal nicht sofort und priorisiert antwortet.
• zunächst war auch gar keine Datenbankreplikation eingerichtet sondern nur eine nächtliche Backup-Kopie die auf dem Backup Knoten wartete. Die Diskussion, was für eine RPO ( Recovery Point Objective - wieviel Sekunden Datenverlust maximal erträglich sind) man haben möchte, führt man besser in Ruhe vorher und nicht wenn man feststellt, dass nichts wichtiger ist, als die Daten der letzten Stunde.

Was ich daraus gelernt habe:

• schon in der Planung Klarheit schaffen, welche Anforderungen an Business Continuity bestehen bzw. wieviel man dafür bereit ist auszugeben.
• die Clusterlösung muss auch gewartet und konfiguriert werden. Es muss klar sein, wer sich darum kümmern soll und auch sichergestellt werden, dass die nötigen Ressourcen da sind, diese Personen zu trainieren bzw. Konfigurationen zu testen.
• testen, testen und nochmal testen - alle möglichen Fehlerszenarien und die Rückkehr zum Normalbetrieb müssen vollständig getestet werden und eben auch die Fähigkeit aller damit betrauten Personen, das System durch so eine Havarie zu steuern (gerne mal den Chef fragen, ob die Lufthansa nicht viel Geld sparen würde, wenn sie nicht andauernd die Piloten in den Simulator schickte)
• das alles kostet viel Zeit und Geld, man muss sich aber frühzeitig einig werden, wo man hin will