Foto: Tee11 - shutterstock.com
Autonome Datenbanken sind ein kleiner, aber wichtiger Teil des Megatrends zur immer stärkeren Automatisierung vieler Aufgaben, Workflows und Prozesse. Die Gründe dafür sind vielfältig: So entlastet die Automatisierung von Routineaufgaben bei der Bearbeitung typischer wiederkehrender Vorgänge und ist meist kosteneffizienter. Gleichzeitig gilt sie als probates Mittel gegen den aktuell so häufig kolportierten Fachkräftemangel. Und nicht zuletzt ist ihr prädestiniertes Einsatzfeld dort, wo wachsende Aufgaben nicht mehr mit der bestehenden Manpower bewältigt werden können.
Alle diese Punkte treffen in unterschiedlicher Ausprägung und Mischung auch auf die IT-Abteilungen vieler Unternehmen zu: Die Infrastruktur wird immer komplexer, das Digitalisierungstempo schneller und die sogenannte "time-to-market" fordert von den IT- Experten Agilität und Business Know-how. Sie werden folgerichtig dringend gesucht - und oft genug nicht gefunden.
Viele IT-Abteilungen arbeiten daher an der Belastungsgrenze. Sie sollen für den stabilen, problemlos laufenden Alltagsbetrieb sorgen und gleichzeitig die digitale Modernisierung ihrer Unternehmen unterstützen. Und das, ohne die Budgets zu sprengen. Da ist jede Unterstützung willkommen, die zusätzliche IT-Ressourcen freimacht.
Automatisierung hat viele Facetten
Es klingt ja zugegebenermaßen fast zu schön um wahr zu sein: Automatisierung als Modernisierungs-, Effizienz- und Kostenoptimierungs-Tool in einem. Wenn wir diesen Euphemismus herunterbrechen auf das Spezialgebiet professioneller Datenbanken, dann können Autonomous Databases bei entsprechender Implementierung einige dieser versprochenen Vorteile einlösen.
So zeigt eine eigene interne Erhebung, die natürlich keinen Anspruch auf Repräsentativität erhebt, dass die operativen Kosten für die Datenbank-Administration um bis zu 80 Prozent gesenkt werden können. Mindestens ebenso wichtig sind aber auch die positiven Auswirkungen auf die sinnvolle Auslastung der IT-Ressourcen, die Stabilität, die Verfügbarkeit, die Performance und die Ausfallsicherheit der Datenbank.
Aus technischer Sicht lässt sich das Self-Management der Datenbank auf verschiedenen Wegen umsetzen: mithilfe eigener proprietärer Entwicklungen, unter Zuhilfenahme allgemein verfügbarer Tools oder in Verbindung mit einem Kubernetes-Framework. Oft ist eine Mischung dieser Ansätze die präferierte Lösung. In jedem Fall muss sie drei Aufgaben erfüllen und miteinander verzahnen:
Das Monitoring der laufenden Datenbank-Prozesse und ihrer Umgebung. Dabei muss das System beispielsweise automatisch erfassen, wenn ein Node nicht mehr verfügbar ist.
Die Entscheidung der jeweils zu treffenden Aktion oder Aktionen: Beispielsweise dann, wenn eine virtuelle Maschine (VM) ausgefallen ist.
Die autonome Ausführung dieser Aktion(en) zur Behebung der festgestellten Funktionsstörung.
Kubernetes und alternative Tools
Nicht zuletzt durch die Aktivitäten der Hyperscaler wie AWS, Azure oder Google Cloud ist Kubernetes gerade dabei, sich als "Quasi-Standard" für die Cloud-Orchestrierung zu etablieren. Deshalb wird es von einer Reihe von Anbietern genutzt, ist aber nicht alternativlos. Wer es, aus welchen Gründen auch immer, jedoch nicht einsetzen will, kann für alle drei beschriebenen Teilfunktionen auf entsprechende Werkzeuge zurückgreifen, die meist auf Open Source-Entwicklungen basieren.
Für das Monitoring der Datenbank-Prozesse sind Prometheus oder Nagios die bekanntesten und am häufigsten eingesetzten Werkzeuge. Prometheus besitzt zudem eine Rules Engine zur Entscheidungsfindung, die für den nächsten Schritt zur Einleitung entsprechender Reaktionen und Aktivitäten genutzt werden kann. Mit Grafana können Entwickler und Entwicklerinnen dazu übersichtliche Graphen und Dashboards erstellen. Für die "action", wie etwa die Provisionierung einer virtuellen Maschine, stehen wiederum Tools wie Ansible oder Puppet zur Verfügung.
Autonomous Database und Kubernetes
In den meisten Fällen wird jedoch Kubernetes für den Orchestrierungs-Layer eingesetzt werden. Sei es aus "Mainstream"-Gründen, sei es, weil es die am besten passende technische Lösung ist. Auf der Datenbank-Seite wird ein entsprechendes Pendant gebraucht. Also eine Erweiterung, die die Lifecycle-Management- und Deployment-Aufgaben eines Datenbank-Clusters wie Konfiguration, Skalierung, Backup oder Recovery automatisch provisioniert, steuert und kontrolliert.
Als erklärendes Beispiel für die Funktionsweise mag der Couchbase Autonomous Operator (CAO) dienen, alternativ bietet etwa auch Oracle autonome Datenbanken an. Die aktuelle CAO-Version 2.2 von Couchbase unterstützt unter anderem die folgenden Datenbank-Funktionen: Cluster Provisioning, Auto-Scaling, Rolling-Upgrade und Cluster Auto-Recovery.
Der Operator arbeitet als Steuerungs-Layer zwischen dem Kubernetes-Framework und dem Datenbank-Server, beziehungsweise einem Datenbank-Cluster. Er erweitert die Kubernetes-API durch eine Custom Ressource Definition (CRD), übernimmt das Management des Clusters und definiert die spezifischen Dienste wie Data Service, Search Service, Analytics Service, Eventing Service sowie Query und Index Services. Per YAML-File lässt sich vorab definieren, wie ein bestimmter Cluster beschaffen sein soll.
Eine typische Cluster-Konfiguration könnte beispielsweise folgendermaßen aussehen: drei Nodes respektive Pods, ein Bucket und 8 GByte Memory für die Data Services. Sobald der Cluster in Kubernetes geladen ist, übernimmt der Operator die entsprechende Konfiguration und kümmert sich um die spezifische Provisionierung.
Diese Aufgaben erfüllt er nicht nur einmalig, sondern er übernimmt das Management für alle Datenbank-Cluster. Die Steuerungseinheit basiert auf einem im Operator hinterlegten Regelwerk, das sukzessive abgearbeitet wird. Der Datenbank-Administrator kann dem Autonomous Operator wahlweise das Management der kompletten Datenbank zuweisen oder ihm nur die Steuerung bestimmter Services gestatten. Der Grad der Automatisierung lässt sich also nach eigenen Vorstellungen oder Notwendigkeiten definieren.
Die fünf Ebenen der "Automatisierungs-Kompetenz"
Nimmt man Kubernetes als Maßstab, so lässt sich die Automatisierungs-Kompetenz einer Datenbank an der Erfüllung von fünf vordefinierten Automatisierungs-Ebenen ablesen und vergleichen. Zuständig für die Festlegung der Reifegrade, der sogenannten Maturity-Levels, ist die Cloud Native Computing Foundation (CNCF).
Basis-Level 1 umfasst lediglich Funktionen wie das automatisierte Konfigurationsmanagement oder das App-Provisioning. Auf dem Top-Level 5 (Full Automation) dagegen gehören zu den automatisierten Funktionen unter anderem Automated Availability, Automated Provisioning, Automated Update, Auto Failover, Auto Scheduling, Centralized Management, On-demand Dynamic Scaling, Failure Recovery, Cross Datacenter Replication (XDCR) und automatisches Vertikal- und Horizontal-Scaling.
Voraussetzung für einen hohen Automatisierungsgrad ist im Kubernetes-Umfeld daher das entsprechende CNFC-Ranking einer Datenbank. Je höher sie eingestuft ist, desto mehr Funktionen kann die autonome Steuerungseinheit übernehmen.
Ein Operator lohnt sich nur dann, wenn die Autonomous Database mindestens Level 4 unterstützt. Anderenfalls hätten beide ja praktisch keine Funktionen, die sie übernehmen könnten. Dabei gilt es im Blick zu behalten, dass die Erfüllung dieser Level nicht für einzelne Dienste, sondern immer nur für die gesamte Datenbank gilt.
Es reicht also nicht, beispielsweise mit Level 3 für einen bestimmten Service punkten zu wollen, wenn die restlichen Services der Datenbank noch auf Level 2 verharren. Jedes Unternehmen muss daher im Vorfeld selbst entscheiden, welche autonomen Datenbank-Services für die eigenen Anforderungen sinnvoll oder unverzichtbar sind. (mb)