© Wang An Qi/Shutterstock.com
Entwickler Magazin
Teil 2: Speicheroptionen und Back-ups

Ab in den Container!

In den vergangenen Jahren haben wir unsere Anwendungen in Container verpackt, um diese 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 meistens in separaten Clustern, weil es noch relativ schwer ist, diese 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, Netzwerk, Service Discovery und mehrTeil 4: Deep-dive in die Containerorchestrierung und Kubernetes

Im vorherigen Teil haben wir versucht, die Problematik von Datenbanken in Containern darzustellen und gezeigt, warum es in vielen Installationen heutzutage Sinn ergeben würde, unsere Datenbank zusammen mit der restlichen Anwendung in unserer Containerinfrastruktur zu betreiben. Der wichtigste Unterschied von Datenbanken im Vergleich zu den restlichen Anwendungen ist allerdings die Tatsache, dass eine Datenbank zustandsbehaftet ist. Wir können eine Datenbank nach einem Fehler oder Update nicht einfach auf einem wahlfreien Server in einem frischen Speicher neu starten, da wir sonst unter Umständen unternehmenskritische Daten verlieren oder korrumpieren würden. In diesem Teil der Serie wollen wir uns mit dem Thema Speicher beschäftigen. Wir werden verschiedene Arten von Speichern diskutieren, angefangen bei lokalen Speichern über lokal persistente Speicher und entfernte Speicher. Darüber hinaus werden wir das Zusammenspiel von Clustern und Speicherlösungen betrachten, und wie Back-ups mit diesen Ansätzen effizient kombiniert werden können.

Kennt eure Datenbank!

Bevor wir jedoch anfangen und verschiedene Technologien betrachten, möchte ich gerne wieder einen Schritt zurückgehen und eine Diskussion aufgreifen, die wir bereits am Anfang des letzten Teils begonnen haben. Es gibt keine allgemeingültige Antwort auf die Frage „Welche Speichertechnologie soll ich für meine Datenbank am besten benutzen?“ Es gibt sicherlich Leute, die auf diese Frage eine allgemeingültige Antwort bereithalten; aber ich denke, dass wir immer skeptisch bleiben sollten, wenn uns eine solche Silberkugel präsentiert wird.

Im ersten Teil haben wir diskutiert, dass wir die Datenbankart vielleicht nach der Form unserer Daten wählen sollten. Für vernetzte Daten nehmen wir vielleicht im Idealfall einen Graphen, für tabellenartige Daten ergibt eine relationale Datenbank Sinn und so weiter. Genau die gleiche Diskussion möchte ich auch hier anstoßen, ohne dass ich eine abschließende, allgemeingültige Antwort bereithalte.

Datenbanken sind sehr verschieden in der Art und Weise, wie sie ihre Daten halten und wie ihre Nutzung aussieht. Die Nutzungsart einer Datenbank kann sogar von Installation zu Installation drastisch unterschiedlich sein. So gibt es Installationen von relationalen Daten...

Entwickler Magazin
Teil 2: Speicheroptionen und Back-ups

Ab in den Container!

In den vergangenen Jahren haben wir unsere Anwendungen in Container verpackt, um diese 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 meistens in separaten Clustern, weil es noch relativ schwer ist, diese 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, Netzwerk, Service Discovery und mehrTeil 4: Deep-dive in die Containerorchestrierung und Kubernetes

Im vorherigen Teil haben wir versucht, die Problematik von Datenbanken in Containern darzustellen und gezeigt, warum es in vielen Installationen heutzutage Sinn ergeben würde, unsere Datenbank zusammen mit der restlichen Anwendung in unserer Containerinfrastruktur zu betreiben. Der wichtigste Unterschied von Datenbanken im Vergleich zu den restlichen Anwendungen ist allerdings die Tatsache, dass eine Datenbank zustandsbehaftet ist. Wir können eine Datenbank nach einem Fehler oder Update nicht einfach auf einem wahlfreien Server in einem frischen Speicher neu starten, da wir sonst unter Umständen unternehmenskritische Daten verlieren oder korrumpieren würden. In diesem Teil der Serie wollen wir uns mit dem Thema Speicher beschäftigen. Wir werden verschiedene Arten von Speichern diskutieren, angefangen bei lokalen Speichern über lokal persistente Speicher und entfernte Speicher. Darüber hinaus werden wir das Zusammenspiel von Clustern und Speicherlösungen betrachten, und wie Back-ups mit diesen Ansätzen effizient kombiniert werden können.

Kennt eure Datenbank!

Bevor wir jedoch anfangen und verschiedene Technologien betrachten, möchte ich gerne wieder einen Schritt zurückgehen und eine Diskussion aufgreifen, die wir bereits am Anfang des letzten Teils begonnen haben. Es gibt keine allgemeingültige Antwort auf die Frage „Welche Speichertechnologie soll ich für meine Datenbank am besten benutzen?“ Es gibt sicherlich Leute, die auf diese Frage eine allgemeingültige Antwort bereithalten; aber ich denke, dass wir immer skeptisch bleiben sollten, wenn uns eine solche Silberkugel präsentiert wird.

Im ersten Teil haben wir diskutiert, dass wir die Datenbankart vielleicht nach der Form unserer Daten wählen sollten. Für vernetzte Daten nehmen wir vielleicht im Idealfall einen Graphen, für tabellenartige Daten ergibt eine relationale Datenbank Sinn und so weiter. Genau die gleiche Diskussion möchte ich auch hier anstoßen, ohne dass ich eine abschließende, allgemeingültige Antwort bereithalte.

Datenbanken sind sehr verschieden in der Art und Weise, wie sie ihre Daten halten und wie ihre Nutzung aussieht. Die Nutzungsart einer Datenbank kann sogar von Installation zu Installation drastisch unterschiedlich sein. So gibt es Installationen von relationalen Daten...

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