© Leo_Traveling/Shutterstock.com
Entwickler Magazin
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?

Johannes Unterstein


ArtikelserieTeil 1: Motivation, Fehler und Beefy ServerTeil 2: Speicheroptionen und Back-upsTeil 3: CPU, Multiplexing, N etzwerk, Service Discovery und mehrTeil 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 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. A...

Entwickler Magazin
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?

Johannes Unterstein


ArtikelserieTeil 1: Motivation, Fehler und Beefy ServerTeil 2: Speicheroptionen und Back-upsTeil 3: CPU, Multiplexing, N etzwerk, Service Discovery und mehrTeil 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 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. A...

Neugierig geworden?


   
Loading...

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