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)