Evaluation des operativen Einsatzes von containerisierten relationalen Datenbankmanagementsystemen

Dieser Blogbeitrag umfasst einen Überblick mit den Ergebnissen meiner Bachelorarbeit. Ich habe untersucht, ob relationale Datenbankmanagementsysteme (RDBMS) operativ in containerisierten Umgebungen betrieben werden können. Für meine Untersuchung habe ich eine Methodik entwickelt, die eine Menge von Faktoren analysiert und testet.

Warum ist es interessant Datenbanken in Containern zu betreiben?

Container bieten die Möglichkeit Anwendungen dynamisch und effizient bereitzustellen. Große Container Landschaften können mit Softwarelösungen wie zum Beispiel Kubernetes oder OpenShift orchestriert werden. Im Vergleich zu virtuellen Maschinen benötigen Container weniger Ressourcen und bieten eine bessere Portabilität, da sie weniger Abhängigkeiten zum Host-System haben. Container bieten durch ihre einfache Skalierbarkeit zudem die Möglichkeit aufkommende Lastspitzen dynamisch abzufangen.

Skepsis auf Basis der Designprinzipien von Containern

Container sind ohne eine zusätzliche Konfiguration zustandslose Prozesse. Nach dem Neustart eines Containers verliert dieser sein Gedächtnis und kehrt in seinen Ausgangszustand zurück. Dies widerspricht natürlich der Hauptaufgabe eines DBMS, welches Daten dauerhaft persistieren soll. Im Vergleich zu virtuellen Maschinen teilen sich alle Container die Ressourcen des Host-Systems. Es muss sichergestellt werden, dass eine containerisierte Anwendung eine Mindestmenge an Ressourcen zusteht, aber auch nur ein Maximum an Ressourcen für sich beanspruchen kann. Dies weckt eine Skepsis gegenüber RDBMS in Containern zu betreiben.

Technologien der Testinfrastruktur

Die in meiner Methodik untersuchten Faktoren sind in einer Testinfrastruktur ausgeführt worden. Meine Testinfrastruktur ist ein hochverfügbares PostgreSQL Cluster (Master-Slave Architektur). Dieses wird in einem hochverfügbaren Kubernetes Cluster (drei Master-, und drei Arbeitsknoten) betriebenund basiert auf den folgenden Technologien:

PostgreSQL & Patroni

Ich habe mich für PostgreSQL als RDBMS entschieden, da ich in der Arbeit meinen Fokus auf Open Source Software gelegt habe. PostgreSQL ist zudem das einzige Open Source RDBMS, welches in den letzten Jahren kontinuierlich an Popularität gewonnen hat (db-engines ranking). Patroni ist eine von Zalando entwickelte Software, um hochverfügbare PostgreSQL Cluster zu realisieren. In einem Vergleich mit anderen PostgreSQL-HA (Vergleich bei scalegrid) konnte Patroni in den meisten Anforderungen überzeugen.

Postgres Operator

Der von Zalando entwickelte Postgres Operator überwacht die einzelnen PostgreSQL-Instanzen (Pods). Zusätzlich stellt dieser einen Load Balancer für den Zugriff auf die Master bzw. Standby-Instanzen bereit (externe IP-Adresse).

Entwickelte Methodik

In meiner entwickelten Methodik habe ich die Faktoren: Hochverfügbarkeit, Datenpersistenz, CPU- und RAM-Systemressourcen, Skalierbarkeit, Netzwerk und Sicherheit im Detail betrachtet. Ich gehe hier nur kurz auf ein paar Aspekte ein, die für einen Faktor näher betrachtet wurden. Im Detail kann dies in der Arbeit nachgelesen werden.

Hochverfügbarkeit

Was bedeutet Hochverfügbarkeit und welche Komponenten der Infrastruktur müssen hochverfügbar eingerichtet sein?

• PostgreSQL Cluster
• Kubernetes

Datenpersistenz

Ein Designprinzip von Containern ist deren Zustandslosigkeit. Wie können Container zustandsbehaftet eingerichtet werden?

• Volumes
• Externe Speicheranbindung

CPU- und RAM-Systemressourcen

Container konkurrieren mit anderen Containern auf dem gleichen Host-System mit den verfügbaren Ressourcen. Wie kann sichergestellt werden, dass einem Container eine Mindestmenge an Ressourcen zusteht und dass er auch nur ein definiertes Maximum verwenden darf.

• Systemressourcen Reservieren und Limitieren
• Ressourcen Monitoring

Skalierbarkeit

Container sind auf Basis ihrer wenigen Abhängigkeiten zum Host-System und zur Portabilität einfacher zu skalieren als virtuelle Maschinen. Wie werden Pods in Kubernetes skaliert und welche Unterschiede bzw. Schwierigkeiten gibt es bei der Skalierung von NoSQL und RDBMS?

• Pods skalieren
• Datenbankmanagementsysteme skalieren

Netzwerk

• Kommunikation zwischen Master- und Arbeitsknoten
• Kommunikation zwischen Pods

Sicherheit

• Zugriffsberechtigung
• Protokollierung – Logging

Testfälle & Dokumentation

Für jeden Faktor wurde eine Teilmenge an Testfällen durchgeführt. Jeder Testfall wurde dabei unter denselben Bedingungen ausgeführt und aufgebaut.

Aufbau eines Testfalles

• Testname: Was wird in diesem Test überprüft und aus welchem Abschnitt der Methodik leitet sich dieser ab?
• Durchführung: Schrittweise Durchführung des Testfalles. Codeausschnitte ermöglichen die Wiederholbarkeit.
• Erwartung: Welches Ergebnis wurde auf Basis der Methodik und der verwendeten Testinfrastruktur erwartet.
• Ergebnis: Das tatsächliche Ergebnis des Testfalles. Dieses wurde mit der Erwartung gegenübergestellt, um den Testfall als Bestanden oder nicht Bestanden zu kennzeichnen.

Testreihe (Menge an Testfällen für einen Faktor)

Für jeden Faktor wurden die Testergebnisse zusammengefasst. Auf Basis dieser Zusammenfassung wurde definiert, ob ein Faktor erfolgreich oder nicht erfolgreich abgebildet werden kann (auch hier auf Basis der verwendeten Testinfrastruktur).

Fazit

Aus der Arbeit ergibt sich, dass auf Basis der Methodik und der daraus resultierenden Maßnahmen (diese können Sie in der Arbeit nachlesen), RDBMS hochverfügbar und konsistent in containerisierten Umgebungen betrieben werden können. Das Unternehmen 2ndQuadrant hat die Bedeutung von Kubernetes für PostgreSQL bereits erkannt und ist dessen erster Zertifizierter Kubernetes Service Provider.

Downloadlink zu meiner Arbeit