Referenzarchitektur für selbstverwaltete Oracle-Datenbank

Diese Referenzarchitektur bietet ein konzeptionelles Framework für die Bereitstellung und den Betrieb selbstverwalteter Oracle-Datenbanken in Google Distributed Cloud (GDC) mit Air Gap. Mit dieser Lösung können Sie kritische Datenbank arbeitslasten mithilfe des offiziellen Oracle Database Operator für Kubernetes in Standardclustern verwalten.

Die Architektur konzentriert sich auf die Aktivierung eines BYOL-Modells (Bring Your Own License), mit dem Sie standardisierte, sichere und hochverfügbare Datenbanken in isolierten Umgebungen bereitstellen können. Sie deckt den gesamten Lebenszyklus ab, von der Bereitstellung und Vernetzung bis hin zu Produktionsvorgängen wie Hochverfügbarkeit, Sicherung, Wiederherstellung und Beobachtbarkeit.

Funktionen

Die Lösung bietet mehrere funktionale Kernkomponenten für die Datenbankverwaltung:

  • Automatisierte Lebenszyklusverwaltung: Mit dem Oracle Database Operator können Sie die Bereitstellung, das Klonen, das Patchen und die Konfiguration von Single Instance Databases (SIDB) automatisieren.
  • Hochverfügbarkeit: Integrierte Unterstützung für Oracle Data Guard für synchrone oder asynchrone Replikation und automatisierte Failover-Funktionen. Hochverfügbarkeit wird innerhalb einer einzelnen Zone unterstützt.
  • Integration von persistentem Speicher: GDC-Standard-RWO-Speicherklassen für Datenbankdateien nahtlos nutzen, um die Datenbeständigkeit zu gewährleisten.
  • Sichere Imageverwaltung: Unterstützung für das Spiegeln von Oracle-Container-Images aus der Oracle Container Registry in lokale Harbor-Registries, einschließlich integrierter Scans auf Sicherheitslücken.
  • Einheitliche Beobachtbarkeit: Integrierte Mechanismen zum Exportieren von Datenbankmesswerten nach Prometheus und zum Weiterleiten von Benachrichtigungslogs mithilfe von Sidecar-Mustern.
  • Flexible Netzwerke: Unterstützung für interne und externe L4-Load-Balancer, um Datenbankendpunkte sicher verfügbar zu machen.

Architekturprinzipien

  • Selbstverwalteter Ansatz: Bietet den architektonischen Rahmen für die Bereitstellung und Verwaltung von Oracle-Arbeitslasten.
  • Cloud-native Vorgänge: Verwendet das Operator-Muster, um zustandsorientierte Arbeitslasten zu verwalten und die Konsistenz in verschiedenen Umgebungen zu gewährleisten.
  • Datenbankbezogene Resilienz: Priorisiert die Replikation auf Datenbankebene (Data Guard) gegenüber der Replikation auf Infrastrukturebene, um logische Konsistenz und eine schnellere Wiederherstellung zu gewährleisten.
  • Sicherheitsorientiertes Design: Entspricht den Anforderungen für Air Gap-Umgebungen durch die Verwendung lokaler Registries, obligatorischer Image-Scans und expliziter Netzwerkrichtlinien für den gesamten Datenbanktraffic.

Architektur

Die Architektur veranschaulicht die Beziehung zwischen dem GDC-Standardcluster, dem Oracle Database Operator, den SIDB-Ressourcen und der unterstützenden Infrastruktur wie Harbor.

Architekturdiagramm einer selbstverwalteten Oracle-Datenbank.

Konzepte und Technologien

In diesem Abschnitt werden die funktionalen Komponenten, ihre Verantwortlichkeiten und die Art und Weise beschrieben, wie sie innerhalb des Systems kommunizieren.

Infrastruktur und Plattform

  • GDC-Standardcluster: Die primäre Compute Umgebung, in der sich der Oracle Operator und die Datenbank-Pods befinden.
  • Harbor Registry: Die sichere, lokale „Source of Truth“ für alle Container Images. Sie bietet automatisierte Scans, um sicherzustellen, dass Images keine bekannten Sicherheitslücken enthalten.
  • Nichtflüchtiger Speicher: GDC-Standard-RWO-Speicherklassen bieten den zugrunde liegenden Blockspeicher, der für Oracle-Datendateien, Redo-Logs und Steuerdateien erforderlich ist, und verwenden dazu einen PersistentVolumeClaim.

Dienste und Logik

  • Oracle Database Operator: Der Controller, der benutzerdefinierte Ressourcen wie SingleInstanceDatabase und DataguardBroker überwacht. Er gleicht diese mit Standard-Kubernetes-Objekten ab, einschließlich StatefulSets für Datenbank-Pods und Diensten für die Vernetzung.
  • Single Instance Database (SIDB): Eine containerisierte Bereitstellung mit der mandantenfähigen Oracle-Architektur (CDB/PDB). Sie können mehrere separate SIDB-Instanzen bereitstellen oder Arbeitslasten konsolidieren, indem Sie mehrere Pluggable Databases (PDBs) in einer einzelnen SIDB erstellen.
  • Data Guard Broker: Orchestriert Rollenübergänge zwischen primären und Standby-Instanzen. Er verwaltet die Datenbankrollenlabels, z. B. database.oracle.com/role: primary, die von Kubernetes-Diensten verwendet werden, um den Traffic nach einem Failover korrekt weiterzuleiten.
  • L4-Load-Balancer: Bietet stabile IP-Adressen für die Datenbankverbindung.

Datenfluss und Schnittstellen

  • SQL*Net (Port 1521): Das primäre Protokoll für die Anwendungsverbindung.
  • Exporter für Beobachtbarkeit: Macht einen /metrics Endpunkt für Prometheus verfügbar.
  • Benachrichtigungslogs: Standardmäßige Datenbankbenachrichtigungslogs werden an stdout gesendet, damit sie vom GDC-Logging-Agent erfasst werden können.
  • RMAN-Kanäle: Werden von CronJob Ressourcen verwendet, um Sicherungen in S3-kompatiblen Objektspeicher zu streamen.

Hinweise

  • Skalierbarkeit und Leistung:
    • Worker-Knoten müssen für Produktionsarbeitslasten mit mindestens 8 vCPUs und 32 GB RAM dimensioniert sein.
    • Die Verwendung von nodeSelector oder Taints und Toleranzen ist eine Best Practice, um bestimmte Knoten für Datenbankarbeitslasten zu reservieren.
    • Die Leistung hängt stark vom zugrunde liegenden Speicher ab. Es wird empfohlen, standard-rwo mit hohen IOPS zu verwenden.
  • Ressourcenverwaltung und Lizenzierung:
    • Für diese Lösung wird ein BYOL-Modell (Bring Your Own License) verwendet.
    • Für erweiterte Funktionen wie transparente Datenverschlüsselung (Transparent Data Encryption, TDE), erweiterte Komprimierung und Active Data Guard (schreibgeschützter Standby) sind bestimmte Enterprise Edition-Lizenzen erforderlich.
    • Die Oracle Database Free Edition kann für Entwicklung und Tests verwendet werden.
  • Verfügbarkeit und Zuverlässigkeit:
    • Hochverfügbarkeit wird durch Data Guard-Konfigurationen mit einer einzelnen Zone erreicht, bei denen sich primäre und Standby-Instanzen im selben Namespace befinden.
    • Wenn Sie einen Dienst mit einem Selektor für das Label primary verwenden, wird eine nahtlose Client-Umleitung während des Failovers ohne clientseitige Änderungen gewährleistet.
    • Zum Datenschutz verwendet die Lösung RMAN für Sicherungen in einem S3-kompatiblen Bucket.
  • Betriebsmanagement:
    • Der Operator vereinfacht zwar die Bereitstellung, aber für den täglichen Betrieb wie Optimierung und komplexe Wiederherstellungen ist weiterhin Fachwissen in der Datenbankverwaltung erforderlich.
    • Die Verwendung eines Sidecar-Containers wird empfohlen, um detaillierte Trace- und Audit-Logs weiterzuleiten, die nicht an stdout gesendet werden.

Designentscheidung

Die primären architektonischen Entscheidungen für diese Lösung konzentrieren sich darauf, die Automatisierung mit den Einschränkungen einer Air Gap-Umgebung in Einklang zu bringen.

Data Guard im Vergleich zur Replikation auf Speicherebene

Data Guard ist der Mechanismus für Hochverfügbarkeit, da er datenbankbezogen ist. Dieser Ansatz schützt vor logischen Beschädigungen und sorgt im Modus für maximale Verfügbarkeit für keinen Datenverlust, indem Blöcke validiert werden, bevor sie in den Standby geschrieben werden. Dies erfordert zwar zusätzliche Lizenzen für die Enterprise Edition und mehr Einrichtungsaufwand als Volumes-Snapshots, bietet aber die erforderliche Konsistenz für Verfeinerungsarbeitslasten.

Dienstverwaltung für Load-Balancer

Wenn Sie den Parameter loadBalancer: true in der Spezifikation SingleInstanceDatabase festlegen, wird standardmäßig automatisch ein externer Load-Balancer-Dienst erstellt. Für einen internen Load-Balancer muss manuell eine separate Dienstressource erstellt werden, um die erforderliche networking.gke.io/load-balancer-type: "Internal" Annotation einzufügen. Dieser manuelle Ansatz bietet deklarative Kontrolle über Annotationen und Labels, die der standardmäßige vom Operator verwaltete Dienst möglicherweise nicht verfügbar macht.

Strategie für die Beobachtbarkeit von Sidecars für Logs

Die Lösung empfiehlt die Verwendung von Sidecar-Containern für die Logweiterleitung. Dadurch wird die Logerfassung vom Hauptdatenbankprozess entkoppelt, sodass ein hohes Logvolumen die Datenbankleistung nicht beeinträchtigt. Dadurch erhöht sich zwar der Ressourcenbedarf pro Datenbank-Pod, aber es wird eine zuverlässige Telemetrieerfassung gewährleistet, ohne die Datenbankstabilität zu beeinträchtigen.

Annahmen und Einschränkungen

Annahmen

  • Die Umgebung verfügt über eine vorkonfigurierte und zugängliche Harbor-Instanz für das Image-Hosting.
  • Cert-Manager ist im Standardcluster vorinstalliert, um die Webhook-Zertifikate des Operators zu verarbeiten.
  • Für RMAN-Sicherungsziele ist ein S3-kompatibler Objektspeicher verfügbar.

Einschränkungen

  • Hochverfügbarkeit in einer einzelnen Zone: Hochverfügbarkeitskonfigurationen werden innerhalb einer einzelnen Zone unterstützt.
  • Kein Oracle RAC: Die Unterstützung für Real Application Clusters (RAC) ist nicht enthalten. Die Lösung konzentriert sich auf Single Instance und Data Guard.
  • Nur Standardcluster: Die Lösung wurde für GDC-Standardcluster validiert und wird in freigegebenen Nutzerclustern nicht unterstützt.

Nächste Schritte