Architettura di riferimento del database Oracle autogestito

Questa architettura di riferimento fornisce un framework concettuale per il deployment e il funzionamento di database Oracle autogestiti su Google Distributed Cloud (GDC) con air gap. Questa soluzione ti consente di gestire workload di database critici utilizzando l'Oracle Database Operator for Kubernetes ufficiale su cluster standard.

L'architettura si concentra sull'abilitazione di un modello Bring Your Own License (BYOL), che consente di eseguire il deployment di database standardizzati, sicuri e ad alta affidabilità all'interno di ambienti isolati. Copre l'intero ciclo di vita, dal provisioning e dal networking alle operazioni di livello di produzione come alta affidabilità, 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 Oracle Database Operator 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 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 degli avvisi utilizzando pattern sidecar.
  • Networking flessibile: supporto per i bilanciatori del carico L4 interni ed esterni per esporre gli endpoint del database in modo sicuro.

Principi di architettura

  • Approccio autogestito: fornisce il framework dell'architettura 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 ambienti diversi.
  • Resilienza basata sul database: dà 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.
  • Design incentrato sulla sicurezza: rispetta i requisiti di air gap utilizzando registry locali, scansione obbligatoria delle immagini e policy di rete esplicite per tutto il traffico del database.

Architettura

L'architettura illustra la relazione tra il cluster GDC standard, 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 GDC standard: l'ambiente di computing principale in cui risiedono l'operatore Oracle e i pod del database.
  • Harbor Registry: la fonte di riferimento locale e sicura per tutte le immagini container. Fornisce la scansione automatica 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 richiesta per i file di dati, i redo log e i file di controllo di Oracle utilizzando un PersistentVolumeClaim.

Servizi e logica

  • Oracle Database Operator: il controller responsabile del monitoraggio delle risorse personalizzate come SingleInstanceDatabase e DataguardBroker. Questi vengono riconciliati in oggetti Kubernetes standard, tra cui StatefulSet per i pod del database e servizi per il networking.
  • Database a istanza singola (SIDB): un deployment containerizzato che utilizza l'architettura multi-tenant di Oracle (CDB/PDB). Puoi eseguire il deployment di più istanze SIDB distinte o consolidare i workload creando più database collegabili (PDB) all'interno di un singolo SIDB.
  • Data Guard Broker: orchestra le transizioni dei ruoli tra le istanze primarie e in 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 degli avvisi: i log degli avvisi standard del database vengono inviati a stdout per la raccolta da parte dell'agente Logging di GDC.
  • Canali RMAN: utilizzati dalle risorse CronJob per trasmettere i backup in streaming allo spazio di archiviazione di oggetti compatibile con S3.

Considerazioni

  • Scalabilità e prestazioni:
    • I nodi worker devono essere dimensionati con un minimo di 8 vCPU e 32 GiB di RAM per i workload di produzione.
    • L'utilizzo di nodeSelector o di incompatibilità e tolleranze è una best practice per dedicare nodi specifici ai workload del database.
    • Le prestazioni dipendono in larga misura dallo spazio di 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.
    • L'edizione Oracle Database Free può essere utilizzata per lo sviluppo e il test.
  • 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 dall'esperienza di amministrazione del database.
    • L'utilizzo di un container sidecar è consigliato per l'inoltro di log di controllo e di traccia dettagliati che non vengono inviati a stdout.

Decisione di progettazione

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

Data Guard e replica a livello di spazio di archiviazione

Data Guard è il meccanismo di alta affidabilità perché è database-aware. Questo approccio protegge dalla corruzione logica e garantisce zero perdite di dati in modalità di disponibilità massima convalidando i 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 richiesta 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 bilanciatore del carico esterno. Per un bilanciatore del carico interno, è necessario creare manualmente una risorsa di servizio separata per includere l'annotazione networking.gke.io/load-balancer-type: "internal" necessaria. Questo approccio manuale fornisce un controllo dichiarativo su annotazioni ed etichette che il servizio predefinito gestito dall'operatore 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 un volume di logging elevato non influisca sulle prestazioni del database. Sebbene ciò aumenti l'impatto sulle risorse per pod di database, garantisce una raccolta affidabile della telemetria senza influire sulla stabilità del database.

Ipotesi e limitazioni

Ipotesi

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

Limitazioni

  • Alta affidabilità a zona singola: le configurazioni ad alta affidabilità 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 Single Instance e Data Guard.
  • Solo cluster standard: la soluzione è convalidata per i cluster standard GDC e non è supportata sui cluster utente condivisi.

Passaggi successivi