Interview mit Timo Lackmann

Datenbanken & Kubernetes: „Flexible Skalierung und signifikant vereinfachte Bereitstellung“
Keine Kommentare

In Zeiten von Cloud Computing und der immer weiter zunehmenden Containerisierung von Anwendungen fragt man sich, was eigentlich mit Datenbanken passiert. Können diese in Container ausgelagert werden? Welche Vorteile hat das? Diese und weitere Fragen haben wir Timo Lackmann, Solution Architect bei MongoDB, gestellt.

JAXenter: Kubernetes hat sich in der Welt der Softwareentwicklung zu einem Standard entwickelt; fast jedes Unternehmen setzt es heute ein. Aber ganz ehrlich: Muss es immer Kubernetes sein?

Timo Lackmann: Grundsätzlich muss natürlich nicht immer Kubernetes zur Container-Orchestrierung genutzt werden. Kubernetes ist eine besonders leistungsstarke Lösung und bietet umfangreiche Funktionen rund um Management und Monitoring, die im Enterprise-Umfeld benötigt werden. Allerdings ist sie auch komplexer als Alternativen wie beispielsweise Docker Swarm und erfordert mehr Kenntnisse. Auch sehe ich bei meinen Kunden vor allem im Bereich von Private Clouds eine steigende Beliebtheit von OpenShift, da OpenShift vor allem die Anforderungen an Security und Netzwerkmanagement umfangreicher bedient.

Am Ende sollte es immer das Ziel sein, die Lösung einzusetzen, die die gegebenen Anforderungen am besten erfüllt.

Trotzdem zeigt die Entwickler-Umfrage von StackOverflow aus dem Jahr 2020, dass Kubernetes nach Linux und Docker zu den „most loved platforms“ gehört, und auch der Umfragebericht von CNCF von jetztem Jahr zeigt einen klaren Trend auf. Hier haben 83% der Teilnehmer angegeben, dass sie Kubernetes bereits produktiv einsetzen. 2018 waren es noch 58%, das ist also ein deutlicher Anstieg.

Ich denke, der Grund für die große Beliebtheit und dafür, dass viele Kubernetes als de-facto-Standard sehen, ist nicht zuletzt die große und äußerst aktive Community. Bis dato gibt es bereits über 99.445 Commits auf dem GitHub-Repository von Kubernetes. Neue Releases, die auf Basis der Nutzer-Anforderungen neue Funktionen mit sich bringen, folgen jeweils quartalsweise. Neben freien Entwicklern beteiligen sich auch Unternehmen wie Microsoft, IBM, Red Hat, VMware und viele weitere, wodurch sich um Kubernetes herum inzwischen ein starkes und umfangreiches Ökosystem entwickelt hat. Zudem haben neben Google auch Cloud-Anbieter wie Amazon und Microsoft ihre gemanagten Kubernetes-Services weiter ausgebaut, wodurch Unternehmen nun eine größere Auswahl an Deployment-Modellen haben. Die Bandbreite reich dabei vom selbstverwalteten Deployment im eigenen Rechenzentrum über IaaS-Angebote in der Cloud bis hin zum vollständigen Cloud-Deployment basierend auf den Services der Cloud-Anbieter.

JAXenter: Auch Datenbanken sind nicht von der Containerisierung ausgeschlossen. Welche Vorteile bringt es, eine Datenbank im Container (oder mehreren) zu betreiben?

Timo Lackmann: Die Vorteile einer Datenbank in Containern sind ähnlich zu denen der Applikationsschicht. Die Bereitstellung der Datenbank wird signifikant vereinfacht, kann somit in wenigen Minuten erfolgen und ist zudem hochverfügbar. Außerdem können so Applikations- und Datenschicht gleichzeitig und mit den gleichen Tools in unterschiedlichen Umgebungen eingerichtet und somit der Prozess des Testens und der Migration vereinfacht werden.

Des Weiteren erlaubt die Containerisierung der Datenbank eine flexible Skalierung, die dynamisch an die entsprechende Auslastung angepasst werden kann. Dabei kann die Skalierung nicht nur vertikal erfolgen, indem den Containern mehr Ressourcen zugewiesen werden, sondern auch horizontal, wobei Lese- und Schreibzugriffe durch weitere Container parallelisiert werden. Das setzt allerdings voraus, dass die eingesetzte Datenbank diese Form der Skalierung unterstützen kann, ohne dass sich das negativ auf Aspekte wie Datenkonsistenz, Transaktionsfähigkeit und Verfügbarkeit auswirkt.

JAXenter: Wie funktioniert die Verknüpfung der Datenbank mit der Anwendung, wenn alles in einzelnen Containern gelagert wird?

Timo Lackmann: Hierzu müssen wir zunächst darauf eingehen, wie Container und die dazugehörigen Computer-Ressourcen in Kubernetes verwaltet werden. Für die Zuordnung von Speicher und Netzwerk werden in Kubernetes sogenannte Pods verwendet, die in der Regel nur einen Container enthalten. Jedem Pod wird innerhalb des Kubernetes-Clusters eine IP-Adresse zugeordnet, wodurch eine Kommunikation zwischen Containern ermöglicht wird. Allerdings ist die IP-Adresse an die jeweilige Instanz des Pods gebunden und ändert sich, sobald ein Pod aus unterschiedlichen Gründen neu aufgesetzt wird. Daher werden die Pods der Datenbank einem Service zugeordnet, wodurch sie einen DNS-Namen erhalten, der über die Lebensdauer eines Pods hinaus erhalten bleibt. Wird beispielsweise die Datenbank aktualisiert, so wird ein neuer Container mit der aktuellen Version in einem neuen Pod erstellt und der Pod mit der älteren Version terminiert. Somit erhält der neue Pod zwar eine neue IP Adresse, ist aber nach wie vor noch unter dem alten DNS-Namen auffindbar. Im Fall von MongoDB wird zudem für die Ausführung von Datenbankoperationen ein Driver genutzt, welcher die entsprechende Programmiersprache unterstützt. Dieser vereinfacht einerseits das Mapping der Objektattribute zu den Feldern in der Datenbank, ohne dass ein weiteres ORM-Layer benötigt wird. Zum anderen verwaltet der Driver auch die Verbindung zu allen datenbankbezogenen Pods mit Hilfe eines Connection Strings, wodurch der Aufwand in der Entwicklung reduziert wird.

JAXenter: Welche Vorteile bietet es, MongoDB für den Einsatz in Verbindung mit Kubernetes einzusetzen?

Timo Lackmann: Traditionelle SQL-Datenbanken sind historisch bedingt als Monolithen entwickelt worden, woraus sich im Kubernetes-Umfeld einige Limitierungen und Herausforderungen in Bezug auf Hochverfügbarkeit und horizontale Skalierung ergeben.

MongoDB hingegen ist von Anfang an als verteiltes Datenbanksystem für moderne Applikationen entwickelt worden und beinhaltet daher zahlreiche Funktionalitäten, welche im Kubernetes-Umfeld zum Tragen kommen.

Ein wichtiger Bestandteil ist hierbei das Replica-Set, in dem eine Gruppe von MongoDB-Knoten zusammengefasst werden, die den gleichen Datensatz verwalten. Die Knoten entsprechen dabei Containern, die in voneinander unabhängigen Pods betrieben werden. Somit teilen sie keine Storage oder Netzwerkressourcen und können über mehrere Kubernetes-Worker verteilt werden. Innerhalb des Replica-Sets wird ein Knoten zum sogenannten Primary bestimmt, während die verbleibenden Knoten als Secondaries bezeichnet werden. Der Primary empfängt alle Schreib- und meist auch Leseoperationen und repliziert diese an alle weiteren Secondaries, wodurch die Konsistenz der Daten sichergestellt wird. Hierbei ist zu beachten, dass es sich bei Primary und Secondaries lediglich um Rollen handelt, diese sich aber in ihren Binaries nicht unterscheiden. Daher kann jeder Secondary nach Bedarf zum neuen Primary ernannt werden und umgekehrt. Somit bietet die Architektur des Replica Sets eine hohe Verfügbarkeit mit Hilfe von Redundanz. Kommt es zum Ausfall des primären Pods, so findet automatisch ein Votum innerhalb der verbleibenden Knoten statt, um schnellstmöglich einen neuen Primary zu bestimmen. Für die Applikation ist dieser Prozess transparent, da der MongoDB-Driver eigenständig den jeweiligen primären Pod mit Hilfe des Connection Strings identifiziert. Außerdem werden fehlgeschlagene Operationen durch sogenannte Retryable Reads and Writes ohne eine Exception Handling in der Applikation wiederholt, wodurch ein kontinuierlicher Betrieb sichergestellt werden kann.

Weiterhin können die Daten mit Hilfe des Shardings auf mehrere Replica-Sets aufgeteilt und somit die Anfragen über mehrere Pods parallelisiert werden. Damit bietet MongoDB eine native Lösung zur horizontalen Skalierung, ohne dabei die Datenkonsistenz zu kompromittieren. Aufgrund der Architektur von MongoDB bleibt auch hierbei der Datenzugriff für die Applikation transparent, so dass kein zusätzlicher Entwicklungsaufwand entsteht.

JAXenter: Wie funktioniert das Ganze auf technischer Ebene? Wie kann man MongoDB und K8s zusammenführen?

Timo Lackmann: MongoDB kann entweder innerhalb des eigenen Kubernetes-Clusters aufgesetzt werden oder als Managed Service in der Cloud auf GCP, AWS und Azure. Für den Betrieb innerhalb von Kubernetes bietet MongoDB einen eigenen Operator an, welcher auch für OpenShift-Umgebungen genutzt werden kann. Der Operator automatisiert sowohl die Kubernetes-spezifischen Konfigurationen wie Speicher, Netzwerk und Rechenleistung als auch die Konfiguration des MongoDB-Clusters und das Verwalten von Datenbanknutzern. Außerdem können vorhandene MongoDB-Instanzen einfach verändert und skaliert werden. Im Zusammenspiel mit dem MongoDB Ops Manager können außerdem Themen wie zentrales Monitoring und Backup-Management schnell und einfach umgesetzt werden.

Alternativ kann auch der gemanagte Cloud Service MongoDB Atlas mit Kubernetes zusammengeführt werden. Mit Hilfe des MongoDB Atlas Operators kann ein MongoDB-Cluster auf einen der drei Cloud-Anbieter oder mehreren gleichzeitig als Multi Cloud-Cluster aufgesetzt werden. Dazu gehört auch das Erstellen des notwendigen Netzwerk-Peerings oder eines Private Links.

Das Besondere ist, dass MongoDB sowohl auf Kubernetes als auch auf Atlas dieselbe Datenbank ist und somit nahtlos migriert oder parallel betrieben werden kann.

JAXenter: Was kommt deiner Meinung nach als nächstes? Ist Kubernetes „der Weisheit letzter Schluss“? Was ist mit Serverless?

Timo Lackmann: Auch, wenn eine Aussage über zukünftige Trends und Technologien immer etwas riskant ist, so bin ich doch sicher, dass Kubernetes nicht das Ende sein wird. Generell wird von Seiten unserer Kunden vermehrt das Ziel einer ereignisgetriebenen Architektur formuliert. Dazu gehört neben der zunehmenden Nutzung von Message-Brokern und Kubernetes sicherlich auch verstärkt die Nutzung von Serverless, welches auch teilweise als Function-as-a-Service (FaaS) bezeichnet wird. Allerdings hat Serverless nach wie vor zwei signifikante Nachteile. Zum einen sind die Angebote in der Cloud stets stark an den jeweiligen Anbieter gebunden und erzeugen damit einen starken Vendor Lock-in, und zum anderen werden nach wie vor nur eine begrenzte Anzahl an Programmiersprachen und Versionen unterstützt. Hier scheint noch ein Lösungsansatz zu fehlen, wie Serverless-Applikationen anbieterübergreifend verwaltet werden können.

Ein erster Schritt in diese Richtung könnte von Google in Form eines neuen Dienstes namens Anthos kommen. Anthos verspricht nicht nur eine anbieterübergreifende Plattform zu werden, auf der heute schon Kubernetes-Clusters im eigenen Rechenzentrum, auf AWS und GCP zentral verwaltet werden können, sondern auch ein zentrales Management von Policies und Security-Mechanismen für die entsprechenden Umgebungen zu ermöglichen. Außerdem ermöglicht es bereits Serverless-Dienste im eigenen Rechenzentrum zu betreiben anstatt ausschließlich in der Cloud. Es bleibt abzuwarten, ob Anthos zukünftig auch Azure ins Boot holen kann und tatsächlich ein einheitliches Deployment auf allen drei Cloud Anbietern zuzüglich dem eigenen Rechenzentrum anbieten wird.

JAXenter: Danke, Timo, für dieses Interview!

Timo Lackmann ist Solution Architect bei MongoDB.
 
 
 
 
Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -