Arsitektur referensi database Oracle yang dikelola sendiri

Arsitektur referensi ini menyediakan framework konseptual untuk men-deploy dan mengoperasikan database Oracle yang dikelola sendiri di Google Distributed Cloud (GDC) yang terisolasi. Solusi ini memungkinkan Anda mempertahankan workload database penting dengan menggunakan Oracle Database Operator resmi untuk Kubernetes dicluster standar.

Arsitektur ini berfokus pada pengaktifan model Bring-Your-Own-License (BYOL), yang memungkinkan Anda men-deploy database standar, aman, dan sangat tersedia dalam lingkungan yang terisolasi. Solusi ini mencakup siklus proses lengkap mulai dari penyediaan dan jaringan hingga operasi tingkat produksi seperti ketersediaan tinggi, pencadangan, pemulihan, dan kemampuan observasi.

Fitur dan kemampuan

Solusi ini menyediakan beberapa komponen fungsional inti untuk pengelolaan database:

  • Pengelolaan siklus proses otomatis: Gunakan Oracle Database Operator untuk mengotomatiskan penyediaan, kloning, patching, dan konfigurasi Database Instance Tunggal (SIDB).
  • Ketersediaan tinggi: Dukungan terintegrasi untuk Oracle Data Guard guna menyediakan replikasi sinkron atau asinkron dan kemampuan failover otomatis. Ketersediaan tinggi didukung dalam satu zona.
  • Integrasi penyimpanan persisten: Manfaatkan class penyimpanan standar-rwo GDC yang ada untuk file database secara lancar guna memastikan ketahanan data.
  • Pengelolaan image yang aman: Dukungan untuk melakukan mirroring image container Oracle dari Oracle Container Registry ke registry Harbor lokal, termasuk pemindaian kerentanan terintegrasi.
  • Kemampuan observasi terpadu: Mekanisme bawaan untuk mengekspor metrik database ke Prometheus dan meneruskan log pemberitahuan menggunakan pola sidecar.
  • Jaringan yang fleksibel: Dukungan untuk Load Balancer L4 internal dan eksternal guna mengekspos endpoint database dengan aman.

Prinsip arsitektur

  • Pendekatan yang dikelola sendiri: Menyediakan framework arsitektur untuk men-deploy dan mengelola workload Oracle.
  • Operasi cloud-native: Menggunakan pola operator untuk mengelola workload stateful, sehingga memastikan konsistensi di berbagai lingkungan.
  • Ketahanan yang mendukung database: Memprioritaskan replikasi tingkat database (Data Guard) daripada replikasi tingkat infrastruktur untuk memastikan konsistensi logis dan pemulihan yang lebih cepat.
  • Desain yang berfokus pada keamanan: Mematuhi persyaratan terisolasi dengan menggunakan registry lokal, pemindaian image wajib, dan kebijakan jaringan eksplisit untuk semua traffic database.

Arsitektur

Arsitektur ini menggambarkan hubungan antara cluster standar GDC, Oracle Database Operator, resource SIDB, dan infrastruktur pendukung seperti Harbor.

Diagram arsitektur database Oracle yang dikelola sendiri.

Konsep dan teknologi

Bagian ini menjelaskan komponen fungsional, tanggung jawabnya, dan cara berkomunikasi dalam sistem.

Infrastruktur dan platform

  • Cluster standar GDC: Lingkungan komputasi utama tempat Oracle Operator dan pod database berada.
  • Harbor Registry: Sumber kebenaran lokal yang aman untuk semua image container. Registry ini menyediakan pemindaian otomatis untuk memastikan image bebas dari kerentanan yang diketahui.
  • Penyimpanan persisten: Class penyimpanan standar-rwo GDC menyediakan penyimpanan blok yang mendasarinya dan diperlukan untuk file data Oracle, log redo, dan file kontrol menggunakan PersistentVolumeClaim.

Layanan dan logika

  • Oracle Database Operator: Pengontrol yang bertanggung jawab untuk memantau resource kustom seperti SingleInstanceDatabase dan DataguardBroker. Pengontrol ini merekonsiliasi resource tersebut ke dalam objek Kubernetes standar, termasuk StatefulSets untuk pod dan layanan database untuk jaringan.
  • Database Instance Tunggal (SIDB): Deployment dalam container menggunakan arsitektur multi-tenant Oracle (CDB/PDB). Anda dapat men-deploy beberapa instance SIDB yang berbeda atau menggabungkan workload dengan membuat beberapa Pluggable Database (PDB) dalam satu SIDB.
  • Data Guard Broker: Mengatur transisi peran antara instance utama dan standby. Broker ini mengelola label peran database, misalnya database.oracle.com/role: primary, yang digunakan oleh layanan Kubernetes untuk merutekan traffic dengan benar setelah failover.
  • Load Balancer L4: Menyediakan alamat IP yang stabil untuk konektivitas database.

Alur dan antarmuka data

  • SQL*Net (Port 1521): Protokol utama untuk konektivitas aplikasi.
  • Pengekspor kemampuan observasi: Mengekspos endpoint /metrics untuk Prometheus.
  • Log pemberitahuan: Log pemberitahuan database standar dikirim ke stdout untuk dikumpulkan oleh agen logging GDC.
  • Channel RMAN: Digunakan oleh resource CronJob untuk melakukan streaming cadangan ke penyimpanan objek yang kompatibel dengan S3.

Pertimbangan

  • Skalabilitas dan performa:
    • Node pekerja harus berukuran minimal 8 vCPU dan RAM 32 GiB untuk workload produksi.
    • Menggunakan nodeSelector atau taints dan tolerations adalah praktik terbaik untuk mendedikasikan node tertentu ke workload database.
    • Performa sangat bergantung pada penyimpanan yang mendasarinya; sebaiknya gunakan standard-rwo dengan IOPS tinggi.
  • Pengelolaan resource dan lisensi:
    • Solusi ini mengikuti model Bring-Your-Own-License (BYOL).
    • Fitur lanjutan seperti Transparent Data Encryption (TDE), Advanced Compression, dan Active Data Guard (standby hanya baca) memerlukan lisensi Enterprise Edition tertentu.
    • Oracle Database Free Edition dapat digunakan untuk pengembangan dan pengujian.
  • Ketersediaan dan keandalan:
    • Ketersediaan tinggi dicapai melalui konfigurasi Data Guard satu zona tempat instance utama dan standby berada di namespace yang sama.
    • Menggunakan Layanan dengan pemilih untuk label peran primary memastikan pengalihan klien yang lancar selama failover tanpa perubahan sisi klien.
    • Untuk perlindungan data, solusi ini menggunakan RMAN untuk pencadangan ke bucket yang kompatibel dengan S3.
  • Pengelolaan operasional:
    • Meskipun operator menyederhanakan deployment, operasi sehari-hari seperti penyesuaian dan pemulihan yang kompleks tetap memerlukan keahlian administrasi database.
    • Penggunaan container sidecar direkomendasikan untuk meneruskan log audit dan pelacakan mendetail yang tidak dikirim ke stdout.

Keputusan desain

Pilihan arsitektur utama untuk solusi ini berfokus pada penyeimbangan otomatisasi dengan batasan lingkungan yang terisolasi.

Data Guard versus replikasi tingkat penyimpanan

Data Guard adalah mekanisme ketersediaan tinggi karena mendukung database. Pendekatan ini melindungi dari kerusakan logis dan memastikan tidak ada data yang hilang dalam mode ketersediaan maksimum dengan memvalidasi blok sebelum ditulis ke standby. Meskipun memerlukan lisensi tambahan untuk Enterprise Edition dan overhead penyiapan yang lebih banyak daripada snapshot volume, pendekatan ini memberikan konsistensi yang diperlukan untuk workload penyempurnaan.

Pengelolaan layanan untuk load balancer

Secara default, menetapkan parameter loadBalancer: true dalam spesifikasi SingleInstanceDatabase akan otomatis membuat layanan load balancer eksternal. Untuk load balancer internal, resource layanan terpisah harus dibuat secara manual untuk menyertakan anotasi yang diperlukan networking.gke.io/load-balancer-type: "Internal". Pendekatan manual ini memberikan kontrol deklaratif atas anotasi dan label yang mungkin tidak diekspos oleh layanan yang dikelola operator default.

Strategi kemampuan observasi sidecar untuk log

Solusi ini merekomendasikan penggunaan container sidecar untuk penerusan log. Hal ini memisahkan pengumpulan log dari proses database utama, sehingga memastikan volume logging yang besar tidak memengaruhi performa database. Meskipun meningkatkan jejak resource per pod database, hal ini memastikan pengumpulan telemetri yang andal tanpa memengaruhi stabilitas database.

Asumsi dan batasan

Asumsi

  • Lingkungan memiliki instance Harbor yang telah dikonfigurasi sebelumnya dan dapat diakses untuk hosting image.
  • Cert-manager sudah terinstal di cluster standar untuk menangani sertifikat webhook operator.
  • Penyimpanan objek yang kompatibel dengan S3 tersedia untuk target pencadangan RMAN.

Batasan

  • HA satu zona: Konfigurasi ketersediaan tinggi didukung dalam satu zona.
  • Tidak ada Oracle RAC: Dukungan untuk Real Application Clusters (RAC) tidak disertakan; solusi ini berfokus pada Instance Tunggal dan Data Guard.
  • Hanya cluster standar: Solusi ini divalidasi untuk cluster standar GDC dan tidak didukung di cluster pengguna bersama.

Langkah berikutnya