© Leo_Traveling/Shutterstock.com
Teil 1: Motivation, Fehler und Beefy Server

Container als Datenbankhabitat


In den vergangenen Jahren haben wir unsere Anwendungen in Container verpackt, um sie zu isolieren und einfach auslieferbar zu machen. Nun kämpfen wir damit, Anwendungen mit persistenten Daten in Containern zu betreiben, um sie fehlertoleranter und skalierbarer zu machen. Daher betreiben wir Datenbanken meist in separaten Clustern, weil es noch relativ schwer ist, sie sinnvoll in Containern zu orchestrieren. Das bedeutet allerdings, dass wir unsere gesamte Infrastruktur nicht optimal ausnutzen und Skalierungseffekte zwischen zustandslosen und zustandsbehafteten Anwendungen verschenken. Aber was bedeutet es eigentlich, eine Datenbank in einen Container zu stecken?

In dieser Artikelreihe werden wir analysieren, welche Auswirkungen Container unter anderem auf Festplattenzugriffe, auf Netzwerke oder die CPU-Nutzung haben. Weiterhin werden wir Persistenz, Replikation, Back-ups und Integration in moderne Orchestrierungs-Frameworks wie zum Beispiel Kubernetes oder DC/OS diskutieren. Verschiedene Lösungsansätze und Strategien für die aufgezählten Herausforderungen sollen im Lauf der Serie vorgestellt werden. Wichtig hierbei ist zu beachten, dass sich Datenbanken sehr stark in ihren Anforderungen unterscheiden und sehr unterschiedlich auf Randbedingungen wie Speichermedium oder Netzwerk reagieren. Daher muss man für jede Datenbank einzeln und gezielt Architekturentscheidungen treffen.

Abschließend werden wir die Architekturentscheidungen diskutieren, die wir getroffen haben, um Neo4j Cloud [1] zu implementieren. Dabei handelt es sich um eine vollständige gehostete und betriebene Graphdatenbank (Neo4j).

Warum das ganze Theater mit Containern?

Wenn man sich die Produktionslandschaften von großen Unternehmen vor einigen Jahren angeschaut hat, hat man größtenteils relativ ähnliche Installationen vorgefunden. Da Deployments aufwendiger und statischer waren als heute, wurde meist bei der Abschätzung der benötigten Hardware ein sehr hoher Wert für zu erwartende CPU- und Speicheranforderungen angegeben. Das ist auch sinnvoll, da diese Installationen alle Lastspitzen überleben mussten und sogar Hardwarefehler tolerieren sollten. Eine Sonderrolle bei diesen Abschätzungen hat immer die Datenbank gespielt.

In der Datenbank liegt üblicherweise der größte Wert eines Unternehmens, daher wurde bzw. wird dort auch sehr gerne zu der besten Hardware mit der geringsten zu erwartenden Fehlerquote und dem teuersten und vermeintlich besten Supportvertrag gegriffen. Das ist sinnvoll, da in der Vergangenheit Datenbanken oft ohne Cluster oder Replikation betrieben wurden. Das Problem bei einer Datenbank ohne Replikation und ohne Cluster ist jedoch, dass Daten verloren gehen, sollte die Hardware des Datenbankservers komplett ausfallen. Komplett verloren wären die Daten wahrscheinlich nicht, da mit Sicherheit ein halbwegs aktuelles Back-up verfügbar wäre oder jemand die Festplatte bergen und in einen neuen Server transferieren könnte. Aber das wäre ein enormer manueller Aufwand, und die Datenbank wäre in diesem Zeitraum ebenfalls nicht verfügbar. Zusätzlich wären wahrscheinlich alle Anwendungen, die auf den Daten dieser Datenbank aufbauen, ebenfalls nicht verfügbar.

Ein weiter wichtiger Aspekt, der sich ebenfalls negativ auf die Verfügbarkeit auswirkt, ist der Faktor Mensch: Alle Prozesse, die nicht automatisiert sind und sich nicht selbst heilen können, benötigen Zeit. Zeit, die bei einem Produktionsausfall sehr teuer werden kann. Zudem sind manuelle Eingriffe in eine Produktionsumgebung, zum Beispiel an einem Sonntag um acht Uhr morgens, mit enormem Stress verbunden und daher auch sehr fehleranfällig.

Automatisierung

Lasst uns noch einmal kurz in der Zeit etwas zurückgehen und uns den Installationsprozess einer Datenbank vor Augen führen. Am Anfang stand meist ein Bestellformular für einen oder mehrere Server mit der besten Hardware, der geringsten zu erwartenden Fehlerquote sowie dem teuersten und vermeint...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang