Johannes Unterstein Neo4j

„Wenn in einem Datenbankcluster von drei Containern ein Container ausfällt, kann der Cluster als solches aus zwei Containern weiterbestehen. In den meisten Fällen können sogar weiterhin schreibende Anfragen verarbeiten werden, man kann also einfach einen neuen Container starten und dem Cluster zuteilen.“

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 Orchestrierungsframeworks 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 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 Installation 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.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Entwickler Magazin 2.19 - "WebAssembly"

Alle Infos zum Heft
579881940Container als Datenbankhabitat
X
- Gib Deinen Standort ein -
- or -