© Igor Groshev , 123RF

Wer sowieso viele Dienste in Containern konfektioniert von Server zu Server schiebt, fragt sich, warum nicht auch Datenbanken. Der Artikel schildert den Status quo für RDBMS-Container.

Software-Services verpackt als Container erreichen seit mindestens drei Jahren auch die letzten Ecken der IT. Dabei treffen Docker [1], Rkt [2], LXC [3] und Konsorten auf Technologien, die schon deutlich mehr Jahre auf dem Buckel haben als sie selbst – zum Teil 15 oder mehr. Dazu zählen mittlerweile auch relationale Datenbanken [4] mit ihren bekanntesten Vertretern Oracle [5], MySQL [6], Maria DB [7] und PostgreSQL [8].

Treffen Technologie-Hype und gestandene IT-Veteranen aufeinander, entflammt allerdings nicht in jedem Fall spontane Sympathie. Wer schon länger in der Szene unterwegs ist, kennt diese Situation. Sie ähnelt der, als die Virtualisierung die x86-Welt eroberte. Das Thema Datenbanken in Containern ist aber noch etwas komplexer.

Relationaler Einstieg

Die Internetrecherche nach dem Stichwort Datenbank fördert verschiedenste Techniken, Implementierungen, Ansätze und Softwarevarianten zutage. Der vorliegende Artikel konzentriert sich auf die relationalen Datenbankmanagement-Systeme (oder Relational Database Management Systems, kurz RDBMS) und schließt ein paar Technologien von seiner Betrachtung aus.

Außen vor bleiben Vertreter aus dem NoSQL-Bereich [9], insbesondere verteilte Speicher für Schlüssel-Wert-Paare. Analoges gilt für Datenbanken, die ihre Daten lediglich im Arbeitsspeicher ablegen [10]. Obwohl diese jüngeren Datenbank-Vertreter besser mit Containern kooperieren, bleibt die Popularität der relationalen Datenbanken im Markt ungebrochen [11].

Auch spezialisierte Container-Implementierungen wie Shifter [12] oder Singularity [13] lässt der Artikel links liegen, sie spielen im Kontext relationaler Datenbanken eine untergeordnete Rolle.

Bereits das Lager der Containernutzer ist heterogen genug und versammelt sowohl Freunde als auch Herausforderer von Docker [1], Rocket [2] oder LXC [3]. Offenbar tragen die Konvergenz-Bemühungen der Open Container Initiative (OCI, [14]) noch keine Früchte.

Der Artikel fokussiert auf Docker, da die meisten kommerziellen Produkte diese Container-Implementierung unterstützen. Das Internet ist voll von Anleitungen für den Docker-Einsatz, selbst Microsoft setzt mit der neusten Server-Version auf diese Container-Technologie (siehe Abbildung 1 sowie [15], [16]).

Abbildung 1: Docker-Technologie als Feature in Windows Server 2016.

Fragestunde

Relationale Datenbanken in Docker-Instanzen haben sich vor allem drei Herausforderungen zu stellen.

• Sie müssen die nicht-flüchtige Datenablage von Datenbanken mit zustandslosen Containern vereinbaren.
• Sie haben darauf zu achten, welche Datenbankhersteller eine kommerzielle Betriebsunterstützung leisten.
• Sie müssen prüfen, wie sich Container und Datenbanken mit traditionellen IT-Umgebungen vertragen.

Wer eine zufriedenstellende Antwort auf jede dieser Fragen kennt, hat ein Fundament für den erfolgreichen Einsatz klassischer Datenbanksysteme in Containerumgebungen.

Nachhaltigkeit ist Trumpf

Traditionelle RDBMS-Implementierungen sind nahezu wertlos, wenn sie ihre Daten bei jedem Neustart vergessen. Container wiederum sind allgemein als zustandslos bekannt, sie erreichen nach jedem Start denselben Ausgangszustand. Letzteres ist allerdings schon seit einer Weile nicht mehr ganz korrekt. Inzwischen gibt es eine Reihe von Möglichkeiten und Implementierungen, um Docker mit einem Gedächtnis auszustatten.

In der einfachsten Variante befindet sich der Datenspeicher außerhalb des Containers. In den Anfangszeiten von Docker war dies sogar die einzige Möglichkeit für eine nicht-flüchtige Datenablage. Dieser Ansatz hat durchaus seinen Reiz, setzt aber voraus, dass die jeweiligen Applikationen das entsprechende Protokoll des Massenspeichers außerhalb der Container beherrschen.

Für die klassischen Datenbanksysteme eignet sich diese Methode nicht, denn sie erwarten in der Regel ein Verzeichnis für die Datenablage (siehe Kasten “Blockdevices”). Der Trick ist nun, ein Container-internes Verzeichnis irgendwie außerhalb des Containers abzubilden. Hier kommen Data Volumes [17] und die Plugin-Infrastruktur [18] von Docker ins Spiel (Abbildung 2).

Abbildung 2: Die Plugin-Architektur für die Data Volumes von Docker.

Im einfachsten Fall spiegelt der Container-Admin ein Verzeichnis des Hosts in die Docker-Instanz. Das entkoppelt die Lebenszeit der dort abgelegen Daten von der Laufzeit der Container. Anders gesagt: Beendet der Admin eine Docker-Instanz, behält er dennoch die Daten in diesem Volume beziehungsweise Verzeichnis. Startet er einen neuen Container, hängt dieser das Verzeichnis des Hosts ein und greift so auf einen aktuellen Datenbestand zurück.

Verteilt speichern

Das hilft aber nur in Fällen, in denen alle Docker-Instanzen auf demselben Host beheimatet sind. Hat dieser jedoch ein Problem, sind Datenausfall oder gar ein kompletter Datenverlust programmiert. Abhilfe bieten verteilte Datenspeicher wie das Network File System (NFS, [19]), Gluster-FS [20] oder Ceph [21]. Prinzipiell eignen sich auch klassische Cluster-Dateisysteme wie GFS2 [22] oder OCFS2 [23] für diesen Zweck. Allerdings interessiert sich die Industrie immer weniger für diese, weshalb deren Zukunftssicherheit fraglich ist.

Zudem stellt sich die Frage, wer das Wissen über den verteilten Datenspeicher verwaltet: der Container oder der Host. Die ursprüngliche Implementierung der Data Volumes erlaubte keine Auswahl. Der Host musste den Zugriff auf die verteilte Datenablage im Auge behalten. Die Container-Instanz sah den tatsächlich verwendeten Speicher nicht.

Mit Einführung der Plugins [18] greift Docker direkt auf die verteilten Datenträger zu. Das verschlankt das Setup auf dem Host und legt die Verantwortung und Verwaltung auf die Container-Ebene. Tabelle 1 listet ein paar Plugins für Data Volumes von Docker auf.

Der Zugriff auf verteilten Datenspeicher über Plugins entkoppelt zudem implizit die (Hoch-)Verfügbarkeit der Daten und Container-Instanzen nahezu vollständig. Für Letztere muss der Admin lediglich sicherstellen, dass die entsprechenden Hosts Zugriff auf den entfernten Datenspeicher erhalten. Weitere Details zu den Plugins für Data Volumes in Docker liefert der Kasten “Datenträger zum Einstecken”.

Offiziell ja, aber …

Doch wie gut unterstützen Oracle, Maria DB oder PostgreSQL Docker? Die Antwort fällt zweiteilig aus. Der erste Teil der Antwort behandelt die Frage, ob die Software überhaupt läuft, wenn der Admin sie in einen Container zwängt. Tatsächlich ist Docker inzwischen ausgereift genug, dass hier im Alltagsbetrieb keine Probleme zu erwarten sind. Internetsuchen nach den Namen der Lieblings-RDMBS und dem Schlüsselwort »Docker« liefern zahlreiche Installationsanleitungen zurück.

Damit die Datenbank in Docker läuft, müssen beide Seiten dies unterstützen. Nach dem Stand Januar 2017 kann man dies als gegeben voraussetzen, wenn aktuelle Versionen von Docker und den Datenbanken zum Einsatz kommen. Für die ersten Schritte empfiehlt sich die Dokumentation für offizielle Docker-Abbilder [35] – mit einer Ausnahme: Oracle. Anhänger von Maria DB, MySQL und PostgreSQL finden dort gute Anleitungen für den Betrieb des entsprechenden Container-Abbildes und den Einsatz mit passenden Anwendungen.

Spannender ist allerdings der zweite Teil der Antwort. In ihm geht es darum, ob die Hersteller von Datenbanken die hippe junge Container-Technologie auch offiziell unterstützen. Zahlreiche Einträge inklusive einiger Docker-Images unter [35] lassen eine gewisse Betriebsunterstützung der Datenbankhersteller erahnen. Diese rangiert allerdings in einem Spektrum von “guter Wille und wenn Zeit ist” bis “rund um die Uhr mit garantierter Reaktionszeit”.

Eigentlich ist die Sache sogar noch etwas komplizierter, denn im Idealfall bräuchte die Gesamtheit der verwendeten Software den notwendigen Grad an Betriebsunterstützung. Dazu gehören zum Beispiel das Host-Betriebssystem, die Containertechnologie und dann natürlich die Datenbank selbst. Es ist daher ratsam, die Anzahl der beteiligten Parteien an einem Setup zu limitieren: Idealerweise bietet ein Dienstleister Support für alle Komponenten an.

Für die quelloffenen Vertreter unter den Datenbanken lohnt es sich, beim Betriebssystemhersteller nachzufragen. Bei Branchengrößen wie Red Hat, Suse oder Ubuntu sollte es mit dem Support klappen. Alternativ sucht der Admin Rat beim Datenbankhersteller oder beauftragt einen entsprechenden Dienstleister. Bei PostgreSQL bleibt in Sachen Enterprise-Support zum Beispiel nur der Weg über externe Firmen [36].

Es ist nicht möglich, eine prägnante Empfehlung bezüglich der besten Betriebsunterstützung auszusprechen. Fest steht, dass es hinreichend viele Anbieter gibt, die beim produktiven Einsatz klassischer Datenbanken in Containern helfen.

Oracle zurückhaltend

Das Unternehmen bietet im Sachen Container die kleineste Auswahl. Ursprünglich unterstützte der Softwaregigant nur die hauseigene Containertechnologie, die auf LXC beruhte. Seit Kurzem dürfen Datenbankbetreiber auch Docker nutzen, ein entsprechendes Supportdokument [37] erschien Mitte Dezember 2016.

Schlüsselfertige Docker-Abbilder stellt Oracle nicht bereit. Allerdings gibt es sehr gute Anleitungen zum Selberbauen ([38], [39]) – im einfachsten Fall genügt der Einsatz des Skripts »buildDockerImage.sh« (Listing 1).

Alles neu macht der Container

Im harten Produktionsalltag spielt häufig die hohe Verfügbarkeit eine gewichtige Rolle. Klassische Datenbanken setzen dafür entweder Cluster-, Multi-Master- oder Master-Slave-Konzepte um. Die notwendige Technologie liefert entweder eine externe Applikation oder sie ist Bestandteil der RDBMS-Software selbst.

01 $ ./buildDockerImage.sh -h
02
03 Usage: buildDockerImage.sh -v [version] [-e | -s | -x] [-i]
04 Builds a Docker Image for Oracle Database.
05
06 Parameters:
07    -v: version to build
08        Choose one of:
09    -e: creates image based on 'Enterprise Edition'
10    -s: creates image based on 'Standard Edition 2'
11    -x: creates image based on 'Express Edition'
12    -i: ignores the MD5 checksums
13
14 * select one edition only: -e, -s, or -x
15
16 LICENSE CDDL 1.0 + GPL 2.0
17 Copyright (c) 2014-2016 Oracle and/or its affiliates. All rights reserved.

Wer Container einführt, sollte am besten seine Hochverfügbarkeitskonzepte überdenken. Die drei genannten HA-Konzepte werfen dabei zwei Fragen auf. Die erste dreht sich darum, wer die gerade aktiven Instanzen verwaltet. Die zweite betrifft die Datensynchronisation zwischen den beteiligten Komponenten. Eine davon kann ein Datenspeicher sein, auf den alle aktiven Instanzen zugreifen, häufig kommen Storage Area Networks (SAN, [40]) oder Network Attached Storage (NAS, [41]) zur Anwendung. Eine alternative Methode ist die Datenreplikation der beteiligten Instanzen.

Weiter oben im Text war von einer ähnlichen Datenspeicher-Anforderung die Rede: Datensynchronisation erledigen die Data Volumes mit verteilter Datenablage im Hintergrund. Einzig der Fall des gleichzeitigen Schreibens eines Datums durch verschiedene Container-Instanzen erfordert ein nochmaliges und intensiveres Nachdenken.

Außenbordmotor

Analog verwaltet der Administrator die gerade aktiven Container-Instanzen auch einfach von außen. Das Stichwort lautet Container-Orchestrierung, und Google gehörte zu den ersten Nutzern. Mit Borg, dem Vorläufer des 2015 veröffentlichten Kubernetes [42], verwaltete das Unternehmen vor allen anderen Tausende von Containern. Docker Swarm [33] oder Apache Mesos [43] sind nur einige der weiteren Projekte, die ein genaueres Hinschauen verdienen und die auf Konferenzen um neue Kundschaft werben (Abbildung 3). Ursprünglich gehörte auch Fleet auf diese Liste [44], doch das hat Core OS kürzlich zugunsten von Kubernetes eingestampft.

Abbildung 3: Es gibt ausreichend Auswahl zum Thema Container-Orchestrierung.

Status quo

Der ernsthafte Betrieb klassischer Datenbanksysteme in Containern ist kein Technologieproblem (mehr). Die Herausforderungen liegen eher im Bereich der Prozesse und Mitarbeiter, die für Aufbau, Betrieb und Abbau zuständig sind. Docker & Co. verschieben den Fokus und die Verantwortung im Technologiepaket nach oben – in die Container. Die Infrastruktur darunter, insbesondere die Hardware, rückt in den Hintergrund. Themen wie Devops und Lean Management spielen eine tragende Rolle [45].

Weil die Forderung nach horizontaler Skalierbarkeit und hochgradiger Verteilung wächst, ist auch fraglich, wie lange die RDBMS-Vertreter noch den Markt anführen. “Containern” können die NoSQL-Kollegen deutlich besser.