Ausfälle von Rechenzentren und Clouds voll abfangen

Katastrophen wie Erdbeben, Feuer, Stromausfall oder Hardware-Schäden können Services unterbrechen und Daten im Rechenzentrum korrumpieren. Diese möglichen Auswirkungen soll eine Lösung für Desaster-Toleranz auf ein Minimum begrenzen, indem sie Anwendungen und Daten innerhalb eines für das Geschäft angemessenen Zeitraums nach einem Desaster wiederherstellt. Doch wie lange sind wir bereit zu warten, bis die App wieder läuft? Länger als drei Sekunden? So viel nahmen 53 Prozent der mobilen Seitenbesucher nicht in Kauf. Sie erwarteten ein schnelleres Laden der Seite und brachen ab, fand DoubleClick von Google heraus. Das war 2016. Im heutigen Datenzeitalter, in dem bis 2025 laut IDC-Studie das weltweite Datenvolumen auf kaum vorstellbare 175 Zettabytes ansteigen und bis zu 49 Prozent in Clouds gespeichert wird, zählt jede Zehntelsekunde. Daten müssen stets verfügbar sein, ohne Verzögerungen.

Heute wollen international tätige Unternehmen auch schnell eine Instanz ihres Dienstes direkt in den USA oder beispielsweise in Australien starten. Dafür bietet eine Architektur, die auf relationalen Datenbanken basiert, zu wenig. Denn sie lässt Unternehmen nur die Wahl, ihre Daten an einem einzigen Ort vorzuhalten, was für ihre Kunden bedeutet: Sie müssen warten. Die zweite Variante wäre ein doppelter Datenbankenbetrieb, der sich irgendwann kaum noch managen ließe.

Mit NoSQL basierend auf Apache Cassandra zu global verfügbaren Daten und skalierbaren Apps
Die gesuchte Alternative liefert NoSQL. Solch ein Datenbanksystem macht die Daten global verfügbar, indem es sie auf Servern speichert und über verschiedene Regionen auf unterschiedliche Cloud-Anbieter verteilt. Zusätzliche Kosten entstehen nicht, es tritt höchstens eine gewisse Latenz auf. Apache Cassandra ist ein verteiltes Open-Source-Datenbankmanagementsystem, welches das NoSQL-Datenbankschema genau in diesem Sinne – also ohne relationales Beschreiben der Daten – für die Desaster-Toleranz umsetzt.

Bisher war Apache Cassandra als spaltenorientierte und auf Java basierende NoSQL-Datenbank für andere Szenarien bekannt. Sie kann riesige Datenmengen für Big-Data-Anwendungen verarbeiten und eignet sich als Echtzeit-Datenspeicher für Online-Anwendungen mit vielfältigen Transaktionen. Das schließt extrem skalierbare Echtzeitanwendungen ein, für die sich die Datenbankleistung einfach erhöhen lässt. Für das Verdoppeln fügt man zum Beispiel im laufenden Betrieb einfach so viele Knoten hinzu, wie der Cluster bereits hatte.

Regeln für verteilte Daten

Warum die NoSQL-Datenbank nun einen neuen Standard für Ausfalltoleranz etablieren kann, liegt vor allem daran, dass sie das CAP- oder Brewer’s Theorem umsetzt. Dieses beschreibt die Beziehung von Consistency (C), Availability (A) und Partition-Tolerance (P) und geht auf Eric Allen Brewer, Informatikprofessor und Vizepräsident für Infrastruktur bei Google, zurück. Es regelt alle Fragen für verteilte Daten und geht davon aus, dass sich nur zwei der drei Anforderungen (C, A, P) gut aufeinander abstimmen lassen. Praktische Relevanz besitzen CP- und AP-Systeme, da diese nicht anfällig gegenüber unvermeidlichen Netzwerkausfällen sind. In der CP-Optimierung ist eine Datenbank konsistent und partitionstolerant, aber weniger belastbar. Hochverfügbar und partitionstolerant wird es in der AP-Konfiguration, die aber nur möglicherweise konsistent ist.

Das bekannteste AP-System ist das globale Domain Name System (DNS): Es ist unglaublich ausfallsicher und überlebt die Netzwerkpartitionierung problemlos. In diesem Einsatzszenario bleibt Apache Cassandra flexibel, kann die Abfrageposition definieren und das Abfrageverhalten von CP bis AP konfigurieren.

Gleichgestellte Knoten replizieren Daten präventiv

Laut CAP-Theorem müssen alle Single Points of Failure (SPoF) beseitigt werden. Fallen diese aus, geht auch im System nichts mehr. Jeder Masterknoten einer relationalen Datenbank ist ein SpoF. Mit Apache Cassandra baut man jedoch eine masterlose Architektur auf, in der die Knoten gleichgestellt sind. So kann jeder Knoten bei Apache Cassandra eine Anfrage verarbeiten, egal ob er lesen oder schreiben soll.
Fällt einer dieser Knoten aus, müssen die Daten von ihm an einem anderen Ort verfügbar sein – ohne Backup, weil das zu lange dauern würde. Die Lösung: Die Daten werden stattdessen vorläufig repliziert, bevor sie jemand benötigt. Mit Cassandra erstellt man dazu eine Art SQL-Datenbank, die den Replikationsfaktor definiert, um jedes Datenelement in der gewünschten Anzahl von Knoten zu replizieren. Dafür ist zusätzlicher Speicherplatz nötig. Dieser kostet allerdings wenig im Vergleich zu einem möglichen Reputationsverlust, Auftragsausfällen und einem langfristigen wirtschaftlichen Schaden. Zur Ausfalltoleranz trägt zudem wesentlich bei, dass sich ein Apache Cassandra Cluster selbst wiederherstellen kann.

Desaster-tolerante Datenbank kommt an

Das Aufsetzen und Warten eines Apache Cassandra Clusters verlangt Fachkenntnisse und ist aufwändig. Dies wird sich jedoch für Unternehmen rechnen, die ihre Daten nicht auf einem einzigen Server halten, sondern geografisch verteilen wollen. Die Nachteile, weder das Datenmodell einschränken noch Kaskadenoperationen durchführen zu können, kompensiert ihre schnell lesende und schreibende NoSQL-Datenbank. Administratoren können den gesamten Cluster so konfigurieren, dass ein schnell verteiltes, Desaster-tolerantes System entsteht, welches genau auf ihre Situation zugeschnitten ist.

Mittlerweile haben deshalb viele bekannte Top-Unternehmen Apache Cassandra oder seine kommerzielle Version, DataStax Enterprise, implementiert. Unter anderen vertrauen Apple, Netflix, Twitter, Sony, eBay, Walmart, FedEx und viele andere dem Flaggschiff unter den Cloud-Datenbanken. Es zeigt sich: Eine ausfallsichere Datenbank, die nicht „vollläuft“, ist für viele Unternehmen unterschiedlicher Branchen relevant.