Architettura di riferimento del database Oracle autogestito

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

L'architettura si concentra sull'attivazione di un modello Bring Your Own License (BYOL), che consente di implementare database standardizzati, sicuri e ad alta disponibilità in 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 del 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 singola istanza (SIDB).
  • Alta affidabilità: supporto integrato per Oracle Data Guard per fornire replica sincrona o asincrona e funzionalità 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 la scansione delle vulnerabilità integrata.
  • Osservabilità unificata: meccanismi integrati per esportare le metriche del database in Prometheus e inoltrare i log di avviso utilizzando pattern sidecar.
  • Networking flessibile: supporto per i bilanciatori del carico L4 interni ed esterni per esporre in modo sicuro gli endpoint del database.

Principi architettonici

  • 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 carichi di lavoro stateful, garantendo la coerenza tra i diversi ambienti.
  • Resilienza basata sul 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 di isolamento fisico utilizzando registri 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 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 sicura e locale di riferimento per tutte le immagini dei container. Fornisce la scansione automatica per garantire che le immagini siano prive di vulnerabilità note.
  • Archiviazione permanente: le classi di archiviazione standard-rwo di GDC forniscono l'archiviazione a blocchi sottostante necessaria per i file di dati, i log di ripristino e i file di controllo di Oracle utilizzando un PersistentVolumeClaim.

Servizi e logica

  • Operatore Oracle Database: il controller responsabile del monitoraggio delle risorse personalizzate come SingleInstanceDatabase e DataguardBroker. Li riconcilia in oggetti Kubernetes standard, inclusi StatefulSet per i pod di database e i servizi per il networking.
  • Database a singola istanza (SIDB): un deployment in container che utilizza l'architettura multi-tenant 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: coordina le transizioni di ruolo tra le istanze primaria 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 degli avvisi: i log degli avvisi del database standard vengono inviati a stdout per la raccolta da parte dell'agente di logging GDC.
  • Canali RMAN: utilizzati dalle risorse CronJob per trasmettere in streaming i backup all'archiviazione di oggetti compatibile con S3.

Considerazioni

  • Scalabilità e prestazioni:
    • I nodi worker devono avere una dimensione minima di 8 vCPU e 32 GiB di RAM per i carichi di lavoro di produzione.
    • L'utilizzo di nodeSelector o di taint e tolleranze è una best practice per dedicare nodi specifici ai workload del database.
    • Le prestazioni dipendono molto dall'archiviazione sottostante; è consigliabile utilizzare standard-rwo con IOPS elevati.
  • Gestione delle risorse e licenze:
    • Questa soluzione segue un modello Bring Your Own License (BYOL).
    • 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 utilizzato 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 di 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 problemi 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 nell'amministrazione dei database.
    • L'utilizzo di un container sidecar è consigliato per l'inoltro di log di controllo e tracce 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-gap.

Data Guard e 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 zero dati 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 richiesta per i carichi di lavoro critici.

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 il 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 separata dal processo del database principale, garantendo che il volume elevato di logging non influisca sulle prestazioni del database. Sebbene ciò aumenti l'utilizzo delle risorse per pod di database, garantisce una raccolta affidabile della telemetria senza influire sulla stabilità del database.

Presupposti 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

  • HA 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 nei cluster utente condivisi.

Passaggi successivi