Persistenz ohne Persistenz

NoSQL-Datenbanken laufen typischerweise auf virtuellen Maschinen in der Cloud. Aber wenn die Maschinen, auf denen sie laufen, virtuell sind, wie kann dann Persistenz gewährleistet werden?

Unternehmensweite Managementsysteme für relationale Datenbanken laufen in der Regel auf teurer robuster und sehr zuverlässiger Hardware. Oft werden große Summen investiert, um die Hardware so ausfallsicher wie möglich zu machen. Und der typische Datenbankadministrator würde auch auf solche Maßnahmen bestehen.

In der Cloud finden wir diese Situation fast nie. Cloud Computing findet statt dessen auf Standardhardware statt. Natürlich verwenden die Cloudbetreiber keine Billighardware vom Discounter, einfach weil deren Betrieb durch Ausfälle viel zu teuer wäre. Aber andererseits sind Server typischerweise nicht mit redundanten Netzteilen ausgestattet. Und Festplatten werden nicht zu RAID-Arrays oder anderen fehlertoleranten Systemen verbunden.

Entsprechend erklären Clouddienstleister ihren Kunden, dass sie sich nicht darauf verlassen können, dass virtuelle Knoten zuverlässig funktionieren. Tatsächlich sollte man davon ausgehen, dass Knoten ab und zu ausfallen. Dies hat interessante Konsequenzen. Wenn der Datenbankserver auf einer virtuellen Maschine läuft, ist auch die Platte, auf die der Server schreibt, nur virtuell. Natürlich muss da eine physische Platte hinter stehen. Aber diese ist nicht zugänglich. Wenn der Knoten, auf dem die virtuelle Maschine läuft, runter geht, dann natürlich auch die virtuelle Maschine. Was passiert mit den Daten auf der virtuellen Platte? Sie gehen verloren. Selbst wenn man eine dann neue virtuelle Maschine auf demselben Knoten wieder startet, gibt es keine Möglichkeit, an die Daten heranzukommen, die der Datenbankserver zuvor auf die virtuelle Platte geschrieben hat. Möchte man eine solche Situation vermeiden, müsste man regelmäßig von der virtuellen Maschine (einschließlich ihrer Platte) Bilder ziehen. Bei vielen schreibenden Zugriffen auf die Datenbank bedeutete dieses, dass kontinuierlich in kurzen Intervallen Bilder zu ziehen wären. Dies ist offensichtlich nicht praktikabel. Mit anderen Worten, es gibt keine Persistenz für Datenbankserver, die auf virtuellen Maschinen laufen.

Wenn also virtuelle Maschinen flüchtig sind, wie kann Persistenz dann erreicht werden? Die Antwort ist ziemlich ähnlich derjenigen, die auch im Falle von besonderer Datenbankhardware gegeben wird: Replikation der Daten. Jedes einzelne in der Datenbank abzulegende Datum sollte auf mehreren virtuellen Maschinen, die auf verschiedenen Knoten laufen, gespeichert werden. Dreifache Replikation hat sich als eine Art Standard etabliert. Die Idee dahinter ist folgende. Wir können uns zwar nicht auf die einzelnen Maschinen verlassen. Aber der gleichzeitige Ausfall von allen drei Maschinen, die ein Datum gespeichert haben, ist wenig wahrscheinlich. Wenn nur eine oder zwei Maschinen ausfallen, ist das Datum immer noch verfügbar. Und verschiedene NoSQL-Datenbankserver besitzen eingebaute Mechanismen, die Datenreplikation automatisch wieder herzustellen, wenn ein Knoten ausfällt. Bei anderen liegt diese Aufgabe in der Hand der Anwendungsentwickler.

Ist damit das Ende der Geschichte erreicht? Leider nicht wirklich. Im August letzten Jahres fiel Amazons europäisches Rechenzentrum in Irland komplett aus, nachdem ein Blitz in ein nahe gelegenes Transformatorenwerk einschlug (siehe z.B. hier oder hier). Da der Blitz auch die sekundäre Stromversorgung traf, erlitt das Rechenzentrum einen vollständigen Stromausfall. Dabei ist hier nicht wirklich relevant, ob das nun die richtige Erklärung für das speziellen Ereignis ist. Es genügt zu sehen, dass komplette Stromausfälle ganzer Rechenzentren tatsächlich vorkommen und nicht ins Reich des allzu Unwahrscheinlichen verbannt werden können.

Die offensichtliche Lösung besteht darin, rechenzentrumsübergreifende Datenreplikation einzuführen. Aber da fangen die Probleme erst an. Datenreplikation innerhalb eines Rechenzentrums ist relativ einfach, da alle Knoten mit hohen Bandbreiten miteinander verbunden sind. Daher ist hoher Datenverkehr zwischen den Knoten relativ unproblematisch. Solche Bandbreiten sind aber bei Datenverkehr zwischen Rechenzentren nicht mehr verfügbar, gerade auch wenn die Rechenzentren auf verschiedenen Kontinenten liegen. Bandbreiten über das Internet sind ganz klar der limitierende Faktor bei der Datenreplikation. Eine vollständige Replikation großer Datenmengen mit vielen schnellen Änderungen in Echtzeit ist schlicht unmöglich.

Dabei ist noch ein weiterer Effekt zu berücksichtigen. Wenn ein Rechenzentrum für längere Zeit ausfällt oder unerreichbar bleibt, fangen die Kunden des Rechenzentrums an, ihre Anwendungen auf andere Rechenzentren desselben Anbieters zu verschieben. Dies kann zur Folge habe, dass auch diese wegen Überlastung unerreichbar werden.

In so einer Situation gibt es keine uniforme Lösung für rechenzentrumsübergreifende Datenreplikation, die allen Anforderungen gerecht wird. Es sind viel mehr die individuellen Anforderungen der jeweiligen Anwendung, die die Lösung bestimmen. Im wesentlichen sind drei Typen von Daten zu unterscheiden:

1. Daten, bei denen eine rechenzentrumsübergreifende Replikation nicht erforderlich ist,
2. Daten, die irgendwann über Rechenzentrumsgrenzen hinweg repliziert werden sollten,
3. Daten die unmittelbare rechenzentrumsübergreifende Replikation erfordern.

Erklären wir dies anhand eines Beispiels. Betrachten wir einen Webshop und darin einen Neukunden, der eine Bestellung aufgeben möchte. Die Artikel im Einkaufswagen sind – vor Abgabe der Bestellung – ohnehin vorübergehende Daten. Daher gibt es keinen Grund, sie auf andere Rechenzentren zu kopieren. So lange die Bestellung durch den Kunden nicht abgeschlossen ist, ist der Datenverlust, der mit dem sehr unwahrscheinlichen Ausfall eines ganzen Rechenzentrums verbunden ist, ein ökonomisch verkraftbares Ereignis. Der Kunde muss schließlich nur die Bestellung neu eingeben. Und gegebenenfalls kann man noch versuchen, den Browser des Kunden als Backupsystem zu verwenden, in dem der Inhalt des Einkaufswagens in einem Cookie gespeichert wird.

Kundenadressen und Kreditkarten- und Bankdaten sind dagegen Daten, die in verschiedenen Rechenzentren repliziert werden sollten. Schließlich möchte man seine Kunden und deren Daten bei einem Rechenzentrumsausfall nicht verlieren. Aber es ist immer noch unwahrscheinlich, dass eine unmittelbare Replikation erfolgen muss. Statt dessen schlagen wir vor, die Replikation verzögert vorzunehmen. Wenn dann mal ein ganzes Rechenzentrum ausfällt, ist nur ein kleiner Teil der Kundenstammdaten wirklich betroffen, nämlich nur die, die seit der letzten Replikation geändert wurden.

Es ist schwierig, im vorliegenden Beispiel Daten zu finden, die ohne Zeitverzögerung repliziert werden müssten. Ein mögliches Beispiel sind Daten zur Kreditwürdigkeit von Kunden, etwa wenn ein Kunde seinen Status als zuverlässiger Zahler verliert und daher gar keine Bestellungen mehr aufgeben können darf, z.B. nach Entdeckung eines Betrugsversuches. In so einer Situation kann die Wichtigkeit dieser Information so groß sein, dass eine unmittelbare rechenzentrumsübergreifende Replikation die Aktion der Wahl ist.

Eine ähnlich geartete Analyse muss man für jede einzelne Applikation durchführen. Anwendungen, die verzögerte rechenzentrumsübergreifende Datenreplikation erfordern, sind durchaus noch handhabbar. Wenn aber das Ergebnis einer solchen Analyse die Anforderung der unmittelbaren Replikation großer Datenmengen ist, ist die Situation wirklich schwierig. Es gibt dann keine vorgefertigten Lösungen mehr. Aber solche Fälle muss man sich kritisch ansehen. Warum ist es der Fall, dass große Datenmengen unmittelbar repliziert werden müssen? Ist es wirklich erforderlich, solche Datenmengen zu replizieren? Antworten auf diese Fragen sind typischerweise nicht technischer Natur, sondern folgen aus Geschäftserfordernissen.

Zusammenfassend kann man sagen, wenn Persistenz ernst genommen werden soll, ist eine rechenzentrumsübergreifende Datenreplikation erforderlich. Aber Bandbreiten über das Internet, die bekanntlich Größenordnungen kleiner sind als die, die innerhalb von Rechenzentren zur Verfügung stehen, verhindern die unmittelbare Replikation großer Mengen an Daten. Daher ist es notwendig, die Datenmengen, die wirklich unmittelbare Replikation erfordern, zu identifizieren und klein zu halten. Für alle anderen Daten sollte eine Replikation über Rechenzentren, die verzögert stattfindet, ausreichen. Es ist außerdem ratsam, Mechanismen zur automatischen Erkennung des Ausfalls ganzer Rechenzentren aufzusetzen, um nutzlose Kommunikationsversuche zu verhindern.