Rechtzeitig zur KubeCon in London erschien noch im März 2025 das OraOperator-Update 1.2 für nahezu beliebige Kubernetes Distributionen. Auf die mir augenfälligsten weil lang ersehnten Neuerungen und Änderungen möchte ich kurz hinweisen.
Nach wie vor vereinfacht der Oracle Database Operator for Kubernetes, kurz OraOperator genannt, die Einbindung und Verwaltung externer Oracle Datenbanken in verschiedenen Kubernetes Umgebungen u.a. für besseres DevOps. Er ist auch sehr lange schon in der Lage gewesen, verschiedene Ausprägungen von Oracle Datenbanken und ihre umgebenden Komponenten wie ORDS, Data Guard und Monitoring-Metriken direkt im Kubernetes Cluster vereinfacht zu betreiben. In der neuen Version 1.2 sind einige Preview-Features der Vorgänger-Version vertieft und verbessert worden, aber auch neue Features sind hinzugekommen.
Eine vollständige Liste aller unterstützter Datenbank-Features und -Varianten steht auf der Dokumentationsseite des OraOperator auf github. Im gleichen Dokument steht auch eine ansehnliche Liste der Neuerungen im Datenbank Lifecycle Management der Version 1.2
Als von Oracle entwickelte und gepflegte Komponente hat OraOperator inzwischen eine eigene ID (14423 “onprem”) auf den Seiten des Oracle Support erhalten, aber auch auf github issues wird natürlich reagiert. Die github issues-Seiten spiegeln jedoch nicht alle Themen und Anregungen wider, die im Oracle Support zu finden sind.
OraOperator ist mittlerweile (wenn auch noch in Version 1.1) auf den Seiten von Operatorhub.io eingetragen mit einer Liste aller verwalteten Ressourcen und mit einer einfachen Installationsanleitung. Der für die Verwaltung der inzwischen zahlreichen Kubernetes Operatoren zuständige Operator Lifecycle Manager (OLM) beherrscht nun auch die Einrichtung und automatische Updates des OraOperator. In Kombination mit Funktionstests auf dem freien Openshift-Pendant OKD wird eine noch umfassendere Unterstützung für Kubernetes Distributionen in verschiedenen Clouds wie Google, Azure, OCI und selbstverständlich On-Premises gewährleistet.
Pluggable Databases (PDBs) durften und dürfen sowohl extern referenziert werden (z.B. auf separaten Datenbank Servern wie Exadata und Database Appliance) als auch direkt im Kubernetes Cluster mitbetrieben sein. OraOperator kümmert sich um das Lifecycle Management von PDBs und kann sie aus einem Guß gemeinsam mit einem Anwendungsdeployment erzeugen, clonen, umkonfigurieren, hoch und herunterfahren, und natürlich auch wieder löschen. In der neuen Version 1.2 des OraOperator muß die Verwaltung von PDBs nicht länger über die REST Services eines automatisiert bereitgestellten ORDS Containers erfolgen. Die herkömmlichen Kubernetes Ressourcen CDB und PDB können nun ersetzt werden durch LREST und LRPDB Ressourcen. LREST ist ein separater, besonders schlanker Container der sich ausschließlich um das Lifecycle Management von PDBs kümmert und sich mit einer Container Database (CDB) verbindet. Dadurch verschwindet die Abhängigkeit zu bestimmten, meist älteren und selbstgebauten ORDS Containern, und es entstehen auch keine Konflikte mit ORDS-spezifischen Datenbank-Schemas unterschiedlicher Versionen in einer CDB zu denen in einzelnen PDBs. Auch unter die Haube geschaut verschwindet manch anderes Manageability-Problem, auf das Sie vielleicht bereits gestoßen sind. Weiterhin sind neue Features nun möglich wie das Binden(bind) an bereits bestehende PDBs und ein zukünftig geplantes auto-bind bzw. auto-discovery aller PDBs einer CDB. Eine Anleitung zur Einrichtung von LREST und LRPDB Ressourcen finden Sie ebenfalls auf github.com im Bereich Multitenant Unterstützung.
Die bislang als Developer Preview markierte Unterstützung für Data Guard in Datenbanken innerhalb des Kubernetes Cluster (die SingleInstanceDatabase Kubernetes Ressource) hat mit Version 1.2 nun Production Status erreicht. Den Unterschied macht ein eingebauter Observer, der das Fast Start Failover-Feature (FSFO) gespiegelter Oracle Datenbanken unterstützt. Vor Version 1.2 des OraOperator waren nur manuelle Switchover auf gespiegelte Datenbanken möglich, um beispielsweise zero-downtime Patching ganzer Datenbanken zu ermöglichen. Nun werden auch ungeplante Ausfälle dank FSFO unterstützt. Und es lassen sich Spiegeldatenbanken in den Snapshot Standby Modus versetzen, damit Entwickler auf einer Spiegeldatenbank vorübergehend Tests durchführen können.
pre-started containers für schnelleren Failover oder Data Guard mit gespiegelten Dateien,
jetzt auch mit fast-start failover (FSFO) und snapshot standby Modus.
Doch es hat sich im Bereich High Availability für in-cluster Datenbanken noch mehr getan. OraOperator kann Sie massiv dabei unterstützen, eine Globally Distributed Database (einst auch Sharded Database genannt) aufzusetzen. Bei einer Globally Distributed Database werden Teile der Datenbestände auf separate Datenbanken ausgelagert. Diese Datenbanken werden durch einen Koordinator vereint, so daß Operationen auf die Daten automatisch verteilt werden und die sonst autarken Oracle Datenbanken (in der Rolle von Shards) wie eine einzige Datenbank wirken. Diese ist aber stark verteilt auf verschiedene Knoten und vielleicht auch auf unterschiedliche Netzwerke. Mit Oracle 23ai kam ein weiteres Feature hinzu, die Raft Replikation. Sie wird nun auch von OraOperator unterstützt und ermöglicht einen Daten-Sync zwischen einzelnen Shards untereinander. Dieser Sync führt prinzipiell zu einer ähnlichen Datenverteilung wie bei einem RAID 1+0 Festplattensystem, aber läuft über das Raft Konsens-Protokoll über ein Netzwerk hinweg. Der Raft Sync kommt ohne Data Guard aus und auch ohne GoldenGate und er verspricht Datenbank (bzw. Shard) Failover Zeiten von weniger als 3 Sekunden. Bei Systemen mit mehr als 3 Shards benötigen Sie zwar Active Data Guard- oder GoldenGate-Lizenzen, aber nicht die Technologie dahinter. Versuchen Sie doch einmal ein solches Setup in Ihrem Kubernetes Cluster! Eine Beschreibung am Beispiel der Oracle23ai free Datenbank finden Sie ebenfalls auf github. Generelle Infos zur Raft Replikation gibt es als Blog-Eintrag und auch als Youtube Video
Die Unterstützung des True Cache Mechanismus auf Basis von Oracle Dataguard wurde ebenfalls neu hinzugefügt, wenn auch vorerst nur als Developer Preview Feature für 23ai FREE Datenbanken zum Test. Weitere Neuerungen in bestehenden Features entnehmen Sie bitte bei Bedarf der mittlerweile umfassenden Dokumentation auf github, oder einigen Blogs zum OraOperator um beispielsweise ORDS Container und Grafana-Metriken zu unterstützen.
Auch an dieser Stelle wie immer – viel Spaß beim Testen und Ausprobieren!
Einige der Links in diesem Blog:
Die Quellseite des OraOperator auf github mit Liste aller Features und unterstützter Cloud- und OnPrem-Varianten
OraOperator auf Operatorhub.io und Artifacthub.io
Betrieb einer in-cluster Oracle Database mit Grafana Monitoring
OraOperator und die neue LREST Multitenant Unterstützung auf github
OraOperator und TrueCache Unterstützung auf github
Globally Distributed Database und Raft Replication mit Oracle Database 23ai