© 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?

Artikelserie

Teil 1: Motivation, Fehler und Beefy Server

Teil 2: Speicheroptionen und Back-ups

Teil 3: CPU, Multiplexing, N etzwerk, Service Discovery und mehr

Teil 4: Deep-dive in die Containerorchestrierung und Kubernetes

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

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