Architettura di riferimento del database Oracle autogestito

Questa architettura di riferimento fornisce un framework concettuale per il deployment e l'operatività dei database Oracle autogestiti su Google Distributed Cloud (GDC) air-gapped. Questa soluzione ti consente di gestire i workload di database critici utilizzando l'operatore Oracle Database ufficiale per Kubernetes su cluster standard.

L'architettura si concentra sull'abilitazione di un modello Bring-Your-Own-License (BYOL), che ti consente di eseguire il deployment di database standardizzati, sicuri e ad alta disponibilità all'interno di ambienti isolati. Copre l'intero ciclo di vita, dal provisioning e dal networking alle operazioni di livello di produzione come alta disponibilità, backup, ripristino e osservabilità.

Caratteristiche e funzionalità

La soluzione fornisce diversi componenti funzionali di base per la gestione dei database:

  • Gestione automatizzata del ciclo di vita: utilizza l'operatore Oracle Database per automatizzare il provisioning, la clonazione, l'applicazione di patch e la configurazione dei database a istanza singola (SIDB).
  • Alta affidabilità: supporto integrato per Oracle Data Guard per fornire funzionalità di replica sincrona o asincrona e di failover automatico. L'alta affidabilità è supportata all'interno di una singola zona.
  • Integrazione dell'archiviazione permanente: utilizza senza problemi le classi di archiviazione standard-rwo esistenti di GDC per i file di database per garantire la durabilità dei dati.
  • Gestione sicura delle immagini: supporto per il mirroring delle immagini container Oracle da Oracle Container Registry ai registri Harbor locali, inclusa l'analisi delle vulnerabilità integrata.
  • Osservabilità unificata: meccanismi integrati per l'esportazione delle metriche del database in Prometheus e l'inoltro dei log di avviso utilizzando i pattern sidecar.
  • Networking flessibile: supporto per i bilanciatori del carico L4 interni ed esterni per esporre in modo sicuro gli endpoint del database.

Principi dell'architettura

  • Approccio autogestito: fornisce il framework architetturale per il deployment e la gestione dei workload Oracle.
  • Operazioni cloud-native: utilizza il pattern dell'operatore per gestire i workload stateful, garantendo la coerenza tra i diversi ambienti.
  • Resilienza consapevole del database: assegna la priorità alla replica a livello di database (Data Guard) rispetto alla replica a livello di infrastruttura per garantire la coerenza logica e un ripristino più rapido.
  • Progettazione incentrata sulla sicurezza: rispetta i requisiti air-gapped utilizzando registri locali , analisi obbligatoria delle immagini e policy di rete esplicite per tutto il traffico del database.

Architettura

L'architettura illustra la relazione tra il cluster standard GDC, l'operatore Oracle Database, le risorse SIDB e l'infrastruttura di supporto come Harbor.

Diagramma dell'architettura del database Oracle autogestito.

Concetti e tecnologie

Questa sezione descrive in dettaglio i componenti funzionali, le loro responsabilità e il modo in cui comunicano all'interno del sistema.

Infrastruttura e piattaforma

  • Cluster standard GDC: l'ambiente di calcolo principale in cui risiedono l'operatore Oracle e i pod del database.
  • Registro Harbor: l'origine attendibile locale e sicura per tutte le immagini container. Fornisce l'analisi automatizzata per garantire che le immagini non contengano vulnerabilità note.
  • Archiviazione permanente: le classi di archiviazione standard-rwo di GDC forniscono l'archiviazione a blocchi sottostante necessaria per i file di dati Oracle, i redo log e i file di controllo utilizzando un PersistentVolumeClaim.

Servizi e logica

  • Operatore Oracle Database: il controller responsabile del monitoraggio delle risorse personalizzate come SingleInstanceDatabase e DataguardBroker. Le riconcilia in oggetti Kubernetes standard, inclusi StatefulSet per i pod del database e servizi per il networking.
  • Database a istanza singola (SIDB): un deployment containerizzato che utilizza l'architettura multitenant Oracle (CDB/PDB). Puoi eseguire il deployment di più istanze SIDB distinte o consolidare i workload creando più database modulari (PDB) all'interno di un singolo SIDB.
  • Data Guard Broker: orchestra le transizioni di ruolo tra le istanze principali e di standby. Gestisce le etichette dei ruoli del database, ad esempio database.oracle.com/role: primary, utilizzate dai servizi Kubernetes per instradare correttamente il traffico dopo un failover.
  • Bilanciatore del carico L4: fornisce indirizzi IP stabili per la connettività del database.

Flusso di dati e interfacce

  • SQL*Net (porta 1521): il protocollo principale per la connettività delle applicazioni.
  • Esportatore di osservabilità: espone un endpoint /metrics per Prometheus.
  • Log di avviso: i log di avviso del database standard vengono inviati a stdout per la raccolta da parte dell'agente di logging GDC.
  • Canali RMAN: utilizzati dalle risorse CronJob per eseguire lo streaming dei backup nell'archiviazione di oggetti compatibile con S3.

Considerazioni

  • Scalabilità e prestazioni:
    • Le dimensioni dei nodi worker devono essere almeno 8 vCPU e 32 GiB di RAM per i workload di produzione.
    • L'utilizzo di nodeSelector o di taints e tolleranze è una best practice per dedicare nodi specifici ai workload di database.
    • Le prestazioni dipendono in gran parte dall'archiviazione sottostante; è consigliabile utilizzare standard-rwo con IOPS elevate.
  • Gestione delle risorse e licenze:
    • Questa soluzione segue un modello Bring-Your-Own-License (BYOL).
    • Le funzionalità avanzate come Transparent Data Encryption (TDE), Advanced Compression e Active Data Guard (standby di sola lettura) richiedono licenze Enterprise Edition specifiche.
    • Oracle Database Free Edition può essere utilizzata per lo sviluppo e il testing.
  • Disponibilità e affidabilità:
    • L'alta affidabilità viene ottenuta tramite configurazioni Data Guard a zona singola in cui le istanze principali e in standby risiedono nello stesso spazio dei nomi.
    • L'utilizzo di un servizio con un selettore per l'etichetta del ruolo primary garantisce un reindirizzamento del client senza interruzioni durante il failover senza modifiche lato client.
    • Per la protezione dei dati, la soluzione utilizza RMAN per i backup in un bucket compatibile con S3.
  • Gestione operativa:
    • Sebbene l'operatore semplifichi il deployment, le operazioni quotidiane come l'ottimizzazione e i ripristini complessi traggono comunque vantaggio dalle competenze di amministrazione del database.
    • È consigliabile utilizzare un container sidecar per l'inoltro dei log di traccia e di audit dettagliati che non vengono inviati a stdout.

Decisione di progettazione

Le scelte architetturali principali per questa soluzione si concentrano sul bilanciamento dell'automazione con i vincoli di un ambiente air-gapped.

Data Guard rispetto alla replica a livello di archiviazione

Data Guard è il meccanismo di alta disponibilità perché è consapevole del database. Questo approccio protegge dalla corruzione logica e garantisce la perdita di dati zero in modalità di massima disponibilità con la convalida dei blocchi prima che vengano scritti nello standby. Sebbene ciò richieda licenze aggiuntive per Enterprise Edition e un overhead di configurazione maggiore rispetto agli snapshot dei volumi, fornisce la coerenza necessaria per i workload di perfezionamento.

Gestione dei servizi per i bilanciatori del carico

Per impostazione predefinita, l'impostazione del parametro loadBalancer: true nella specifica SingleInstanceDatabase crea automaticamente un servizio di bilanciamento del carico esterno. Per un bilanciatore del carico interno, è necessario creare manualmente una risorsa di servizio separata per includere l'annotazione necessaria networking.gke.io/load-balancer-type: "Internal". Questo approccio manuale fornisce un controllo dichiarativo su annotazioni ed etichette che il servizio gestito dall'operatore predefinito potrebbe non esporre.

Strategia di osservabilità dei sidecar per i log

La soluzione consiglia di utilizzare i container sidecar per l'inoltro dei log. In questo modo, la raccolta dei log viene disaccoppiata dal processo del database principale, garantendo che il volume elevato di logging non influisca sulle prestazioni del database. Sebbene ciò aumenti l'impronta delle risorse per pod del database, garantisce una raccolta affidabile della telemetria senza influire sulla stabilità del database.

Ipotesi e limitazioni

Ipotesi

  • L'ambiente dispone di un'istanza Harbor preconfigurata e accessibile per l'hosting delle immagini.
  • Cert-manager è preinstallato nel cluster standard per gestire i certificati webhook dell'operatore.
  • È disponibile un archivio di oggetti compatibile con S3 per le destinazioni di backup RMAN.

Limitazioni

  • HA a zona singola: le configurazioni ad alta disponibilità sono supportate all'interno di una singola zona.
  • Nessun Oracle RAC: il supporto per Real Application Clusters (RAC) non è incluso; la soluzione si concentra su istanza singola e Data Guard.
  • Solo cluster standard: la soluzione è convalidata per i cluster standard GDC e non è supportata nei cluster utente condivisi.

Passaggi successivi