12.07.2019

Ausfallsicherheit und Hochverfügbarkeit

Bei der Verwendung einer Alarmierungsplattform wird erwartet, dass sie im Krisenfall funktioniert. Da es jederzeit zu einem Krisenfall kommen kann, ist es für eine solche Plattform essentiell, dass sie durchgängig verfügbar ist. Schon ein Ausfall von wenigen Minuten, kann für den Nutzer und mögliche andere Betreffende verheerende Folgen haben.

Wir als Entwickler von GroupAlarm sehen uns in der Pflicht, Systemausfälle so gering wie möglich zu halten, um so die höchstmögliche Verfügbarkeit zu erreichen, damit unsere Kunden sich auf unser System blind verlassen können.

Dazu werden verschiedene aktuelle Technologien eingesetzt, die zum einen von global agierenden Unternehmen entwickelt, als auch schon jahrzehntelang dort eingesetzt werden und somit als Industriestandard gelten. In diesem Artikel möchten wir einen Einblick geben, welche Aufwendungen getroffen wurden, um GroupAlarm als hochverfügbares System aufzubauen. Außerdem möchten wir unsere Kunden und die, die es noch werden wollen, von der Ausfallsicherheit von GroupAlarm überzeugen.

Redundanz und Standortunabhängigkeit

Klassische Anwendungen arbeiten mit einem Server in einem beliebigen Rechenzentrum. Ein Server ist ein Computer, auf dem eine Anwendung wie GroupAlarm läuft. Sie als Kunde einer Anwendung mit einem einzelnen Server führen eine beliebige Anfrage an den immer gleichen Server aus, weil es keinen anderen gibt. Funktioniert dieser eine Server einmal nicht oder die Verbindung zu diesem ist gestört, kann Ihre Anfrage nicht verarbeitet werden. In einer hochverfügbaren Anwendung, wie GroupAlarm, kann ein solches Szenario nicht auftreten.

Ungeplante Ausfälle eines Servers lassen sich in den meisten Fällen auf äußere Einflüsse zurückführen. Dazu gehören zum Beispiel Festplatten-, Netzwerk- und Stromausfälle. Die logische Schlussfolgerung, um aus der oben beschriebenen Situation mehr Sicherheit vor Ausfällen zu erhalten, ist das Anlegen von mindestens einem weiteren Server. So kann, im Falle eines Ausfalls, der zweite Server die Arbeit des Ersten auffangen. Befinden sich beide Server im gleichen Rechenzentrum, so ist zum Beispiel der Festplattenausfall eines Servers abgesichert. Kommt es zu einem überregionalen Stromausfall, so sind aber wieder beide Server von der Störung betroffen und die Anwendung ist nicht erreichbar. Hier kommt die Verwendung von verschiedenen Standorten ins Spiel, sodass Server, die über mehrere Standorte hinweg verteilt sind, auch von einem regional beschränkten Ausfall abgesichert sind. Die Verbindung von mehreren Servern, auch wenn sie nicht direkt am selben Ort sind, nennt man Cluster.

Im konkreten Fall besteht GroupAlarm aus einem Cluster mit mindestens drei Servern, die über drei regional unabhängige Rechenzentren in Deutschland verteilt sind. Dazu nutzen wir die aktuellste Version der Orchestrierungssoftware Kubernetes1, die ursprünglich von Google entwickelt wurde und auch dort produktiv eingesetzt wird. Kubernetes verteilt die unabhängigen Komponenten von GroupAlarm über die verschiedenen Server und sorgt für die gleichmäßige Aufteilung Ihrer Anfragen. Wenn es nun zu einem überregionalen Stromausfall in einem der Rechenzentren kommen würde, besteht GroupAlarm immer noch aus mindestens zwei funktionierenden Server, die vom Stromausfall nicht betroffen wären. Damit wäre GroupAlarm selbst mit einem kaputten Server vollständig einsatzbereit und kann von Ihnen normal für die Alarmierung genutzt werden.

Viele Server – Ein Anführer

Da das GroupAlarm Cluster aus mehreren Servern an verschiedenen Standorten besteht, muss für einheitliche Datenhaltung gesorgt werden, denn jeder Server soll natürlich stets auf dem aktuellsten Datenstand sein. Neue Daten sollen automatisch an jeden Server weitergegeben und Aktualisierungen sollen an jeden Server übernommen werden, sodass auch nach oder während eines Ausfalls keine Daten verloren gehen. Dazu wird der Raft-Algorithmus2 genutzt. Grob gesagt legt Raft fest, welcher Server in einer Zeitspanne das Sagen hat und welche Server nur auf die Befehle des Anführers hören.

Dabei gehen alle Anfragen des Nutzers an den Anführer des Clusters. Der führende Server informiert regelmäßig die anderen Server im Cluster über seinen aktuellen Funktionsstatus mithilfe eines “Herzschlags”. Sollte dieser Herzschlag des Anführers ausbleiben, weil er zum Beispiel ausgefallen ist, können die verbleibenden Server einen neuen Anführer wählen und das Cluster bleibt funktionstüchtig. Die primäre Aufgabe des Anführers ist, neben der Annahme der Anfragen, auch die Speicherung der Daten. Alle vorgenommenen Veränderungen werden an die zuhörenden Server weitergegeben.

Diese grobe Beschreibung soll lediglich ein Überblick über die Arbeit von mehreren verteilten Servern in einem Cluster sein. Raft beschreibt viel detaillierter, wie die genaue Wahl zum Anführer funktionieren muss und wie die anderen Server neue Daten erhalten. Für interessierte Leser findet sich in englischer Sprache die Arbeit von Diego Ongaro und John Ousterhout, die dazu eine wissenschaftliche Ausarbeitung an der Stanford University verfasst haben3.

Weitere Vorteile von mehreren Servern

Dass für GroupAlarm mehrere standortunabhängige Server genutzt werden und wie diese ihre Daten replizieren, wurde nun beleuchtet. Es gibt aber auch noch weitere Vorteile für den Nutzer eines solchen Systems.

Im Themengebiet der High Availability, oder zu Deutsch Hochverfügbarkeit, wird der Begriff Downtime in zwei Arten unterteilt. Die Unscheduled Downtime beschreibt einen Ausfall des Systems, der nicht geplant und meist durch einen Fehler hervorgerufen wird. Einen Ausfall dieser Art haben wir schon beschrieben und wissen ihn zu verhindern. Eine weitere Art eines Ausfalls wird in der Scheduled Downtime beschrieben. Meistens kommt es zu solchen geplanten Ausfällen, wenn Wartungsarbeiten an einem Server getätigt werden. Wird der eine Server, auf dem eine Anwendung läuft, gewartet und muss zeitweise abgeschaltet werden, kann der Nutzer die darauf laufende Anwendung nicht nutzen. Wird mehr als nur ein Server eingesetzt und die Arbeiten werden nicht gleichzeitig ausgeführt, so können die noch laufenden Server die Arbeit auffangen.

Da GroupAlarm auf mehreren Servern läuft, werden mögliche Wartungsarbeiten immer fließend und nacheinander durchgeführt. Dadurch ist garantiert, dass stets zwei Server für Ihre Interaktionen verfügbar sind und es zu keiner Beeinträchtigung der Alarmierung kommen kann.

Referenzen

  1. Kubernetes
  2. Raft
  3. In Search of an Understandable Consensus Algorithm

Jetzt ausfallsicher alarmieren!