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 Datenbankarbeitslasten verwalten, indem Sie den offiziellen Oracle Database Operator for Kubernetes auf Standardclustern verwenden.

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

Funktionen

Die Lösung bietet mehrere zentrale Funktionskomponenten für die Datenbankverwaltung:

  • Automatisiertes Lebenszyklusmanagement: 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, um synchrone oder asynchrone Replikation und automatisierte Failover-Funktionen bereitzustellen. Hochverfügbarkeit wird innerhalb einer einzelnen Zone unterstützt.
  • Integration von nichtflüchtigem Speicher: Nutzen Sie die vorhandenen standard-rwo-Speicherklassen von GDC für Datenbankdateien, um die Datenbeständigkeit zu gewährleisten.
  • Sichere Image-Verwaltung: Unterstützung für das Spiegeln von Oracle-Container-Images aus der Oracle Container Registry in lokale Harbor-Registries, einschließlich integriertem Scannen 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 bereitzustellen.

Architekturprinzipien

  • Selbstverwalteter Ansatz: Bietet das Architektur-Framework für die Bereitstellung und Verwaltung von Oracle-Arbeitslasten.
  • Cloudnative Vorgänge: Verwendet das Operator-Muster, um zustandsorientierte Arbeitslasten zu verwalten und so für Konsistenz in verschiedenen Umgebungen zu sorgen.
  • Datenbankbasierte Ausfallsicherheit: 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: Erfüllt die Anforderungen für Air-Gap-Umgebungen durch die Verwendung lokaler Registries, obligatorischer Image-Scans und expliziter Netzwerkrichtlinien für den gesamten Datenbank-Traffic.

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 für eine selbstverwaltete Oracle-Datenbank.

Konzepte und Technologien

In diesem Abschnitt werden die funktionalen Komponenten, ihre Aufgaben und die Kommunikation innerhalb des Systems beschrieben.

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 Quelle für alle Container-Images. Es bietet automatisierte Scans, um sicherzustellen, dass Images keine bekannten Sicherheitslücken aufweisen.
  • Nichtflüchtiger Speicher: GDC-Standard-RWO-Speicherklassen stellen den zugrunde liegenden Blockspeicher bereit, der für Oracle-Datendateien, Redo-Logs und Steuerdateien mit einem PersistentVolumeClaim erforderlich ist.

Dienste und Logik

  • Oracle Database Operator: Der Controller, der für die Überwachung benutzerdefinierter Ressourcen wie SingleInstanceDatabase und DataguardBroker verantwortlich ist. Diese werden in Standard-Kubernetes-Objekte abgeglichen, einschließlich StatefulSets für Datenbank-Pods und Dienste für Netzwerke.
  • Single Instance Database (SIDB): Eine containerisierte Bereitstellung mit der mandantenfähigen Oracle-Architektur (CDB/PDB). Sie können mehrere unterschiedliche 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 Stand-by-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: Stellt stabile IP-Adressen für die Datenbankverbindung bereit.

Datenfluss und Schnittstellen

  • SQL*Net (Port 1521): Das primäre Protokoll für die Anwendungsverbindung.
  • Beobachtbarkeits-Exporter: Stellt einen /metrics-Endpunkt für Prometheus bereit.
  • 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 mindestens 8 vCPUs und 32 GiB RAM haben.
    • Die Verwendung von nodeSelector oder Markierungen 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:
    • Diese Lösung folgt einem BYOL-Modell (Bring Your Own License).
    • Für erweiterte Funktionen wie Transparent Data Encryption (TDE), Advanced Compression und Active Data Guard (Standby mit Lesezugriff) 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 Stand-by-Instanzen im selben Namespace befinden.
    • Wenn Sie einen Dienst mit einem Selektor für das Rollenlabel primary verwenden, wird der Client während des Failovers nahtlos umgeleitet, ohne dass clientseitige Änderungen erforderlich sind.
    • 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 alltägliche Aufgaben wie die Feinabstimmung und komplexe Wiederherstellungen ist weiterhin Fachwissen im Bereich 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 Architekturentscheidungen 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 Hochverfügbarkeitsmechanismus, da er datenbankfähig ist. Dieser Ansatz schützt vor logischer Beschädigung und sorgt im Modus für maximale Verfügbarkeit dafür, dass keine Daten verloren gehen, da Blöcke vor dem Schreiben in die Standby-Datenbank validiert werden. Dies erfordert zwar eine zusätzliche Lizenzierung für die Enterprise Edition und mehr Einrichtungsaufwand als Volume-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, die die erforderliche Annotation networking.gke.io/load-balancer-type: "internal" enthält. Dieser manuelle Ansatz bietet deklarative Kontrolle über Annotationen und Labels, die der standardmäßige vom Operator verwaltete Dienst möglicherweise nicht bereitstellt.

Beobachtbarkeitsstrategie 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. Dies erhöht zwar den Ressourcenbedarf pro Datenbank-Pod, sorgt aber für eine zuverlässige Telemetrieerfassung, ohne die Datenbankstabilität zu beeinträchtigen.

Annahmen und Einschränkungen

Annahmen

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

Beschrä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 auf freigegebenen Nutzerclustern nicht unterstützt.

Nächste Schritte