Nachdem wir im letzten Blogbeitrag unserer Serie “Managed Kubernetes 101” auf das Thema “Message Streaming” aus dem Layer “App Definition and Development” der CNCF-Landscape angegangen sind, stehen heute die allseits beliebten Datenbanken auf dem Plan.
Kurzlebigkeit vs. Langzeitspeicherung
Management-Systeme für Datenbanken erfreuen sich einer großen Beliebtheit. Durch die hohe Effizienz in der Speicherung, der Zugriffssteuerung als auch in der logischen Sortierung bilden sie den Status Quo im Bereich der Datenspeicherung. Dabei ist es irrelevant, ob es sich um relationale oder nicht-relationale Datenbanken handelt.
Das Hauptziel ist die Sicherung der Daten für einen längeren Zeitraum. Ein Verlust der Daten wäre eine finanzielle Einbuße für Unternehmen. Aber auch der zeitlich befristete Ausfall von Datenbanken ist bereits ein Szenario, was zu vermeiden ist. Für ein Kubernetes-Setup, das mit flüchtigen Zuständen arbeitet, eine eher schlechte Ausgangsposition.
Durch die Nutzung wächst auch die Datenmenge. Daher sind Optimierungen im Bereich der Abfragezeiten und -menge wichtig. Nähern wir uns der Lösung einmal vom letzten Punkt aus.
Datenbanken und Microservices
Neben den typischen Vertretern wie MySQL, PostgreSQL oder MongoDB sind auch Datenbanken wie Redis oder Memcached interessant. Der Hintergrund ist denkbar einfach: Redis und Memcached gehören zu den sogenannten In-Memory-Datenbanken. Obwohl Redis auch Daten persistieren kann, liegt der Hauptvorteil der beiden darin, die Daten im RAM vorzuhalten, sogenanntes Caching. Es bietet damit eine deutlich höhere Geschwindigkeit bei Abfragen. Das bedeutet am Ende aber auch, dass sie bei einem Neustart keine Daten mehr enthalten und neu geladen werden müssen.
In-Memory-Datenbanken lösen damit die erste Problematik der Abfrageoptimierung.
Die Verteilung der Daten auf mehrere In-Memory-Datenbanken fördert außerdem die Skalierbarkeit.
Speziell bei Kubernetes-Clustern wird meist sogenannter Distributed Storage genutzt. Dieser bietet eine hohe Bandbreite und ist für parallele Zugriffe gedacht. Persistente Datenbanken, also MySQL oder PostgreSQL benötigen für eine intensive Nutzung jedoch eher geringe Latenzen mit sequentiellen Zugriffen. Dafür sind wiederum andere Storage-Typen geeignet.
Wenn man In-Memory-Datenbanken in einer Systemarchitektur als Microservice wahrnimmt, fehlen damit einige Features wie die persistente Speicherung, die man sonst bei klassischen Datenbanksystemen ganz natürlich so vorfinden möchte. Wir haben also immer noch die Herausforderung der Datenspeicherung im persistenten Umfeld.
Alles ist ein Cluster
Wenn nun der Neustart von Containern auf der Tagesordnung steht, benötigt man Anwendungen, die ebenjenes unterstützen. Dabei hilft generell ein Cluster-Setup, also ein redundantes Setup mit mehreren unabhängigen Instanzen. Die meisten Datenbanksysteme unterstützen diesen Ansatz bereits in einem Primary-Secondary-Prinzip, wo lediglich die Primary-Instanz Schreibrechte erhält. Bei einem Ausfall der Primary-Instanz wird automatisch eine Secondary-Instanz befördert und übernimmt die Schreibrechte. So wird sichergestellt, dass die Applikation trotz des Ausfalls einzelner Instanzen innerhalb kürzester Zeit wieder zur Verfügung steht.
Ein Ansatz mit mehreren Primary-Instanzen ist ebenfalls möglich. Dabei ist zu beachten, dass das ACID-Prinzip (Atomicity, Consistency, Isolation, Durability) möglicherweise verletzt wird und ganz explizit beachtet werden muss.
Der Clusterbetrieb wird übrigens auf Kubernetes von einigen Herstellern bereits mit sogenannten Operators unterstützt. Diese managen anhand der Konfigurationseinstellungen den Datenbank-Cluster und erleichtern den Betrieb mit Dingen wie Leader-Election, Lifecycle Management oder Skalierung.
Das Ops in DevOps
Der letzte und wichtigste Punkt ist die Aufgabe der Langzeitspeicherung und des damit einhergehenden Betriebs. Darunter fallen auch Backup-Mechanismen. Das sind Tätigkeiten, die regelmäßig geprüft und nicht vernachlässigt werden dürfen. Sei es nun Velero als eigenständige Backup-Komponente oder ein Kubernetes-Job zur Erzeugung eines Datenbank-Dumps – auch für diesen Bereich gibt es Methoden, die abseits des restlichen Systems die Arbeit vereinfachen.
Damit werden die Daten auch außerhalb eures Kubernetes-Clusters gesichert. Diese Automatisierungen ermöglichen es euch, die Langzeitspeicherung da zu betreiben, wo es für euch am günstigsten ist. Ein Datenbank-Dump kann verschlüsselt auch gut in einem S3-kompatiblen Speicher abgelegt werden.
Mit der verteilten Herangehensweise – In-Memory-Datenbanken, persistente Datenbanken als Cluster und zusätzliche Tools für Langzeitspeicherung – kreieren wir aus einem Datenbank-Layer drei neue. Ausfallzeiten werden dadurch weiter reduziert. Die Komplexität im Umfeld der Containerisierung steigt aber weiterhin.
Der Blog-Beitrag “Service Mesh” gibt bereits eine Möglichkeit des Managements an die Hand. Darüber hinaus werden wir im nächsten Artikel mit “Continuous Integration & Delivery” erklären, wie diese Art von Einstellungen auf Kubernetes zu standardisierten Prozessen für beliebig viele Setups führen kann.
Egal, wie Du Dich entscheidest: Wir helfen Dir bei jeder Art von Setup.
