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) dengan air gap. Solusi ini memungkinkan Anda mempertahankan workload database penting dengan menggunakan Oracle Database Operator for Kubernetes resmi di cluster standar.

Arsitektur ini berfokus untuk mengaktifkan model Bring-Your-Own-License (BYOL), yang memungkinkan Anda men-deploy database standar, aman, dan sangat tersedia dalam lingkungan yang terisolasi. Layanan ini mencakup siklus proses penuh 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 Operator Database Oracle untuk mengotomatiskan penyediaan, pengkloningan, penerapan patch, 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 kelas penyimpanan standard-rwo GDC yang ada dengan lancar untuk file database guna memastikan ketahanan data.
  • Pengelolaan image yang aman: Dukungan untuk mencerminkan image container Oracle dari Oracle Container Registry ke registry Harbor lokal, termasuk pemindaian kerentanan terintegrasi.
  • Observabilitas 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 untuk mengekspos endpoint database secara 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 beban kerja stateful, sehingga memastikan konsistensi di berbagai lingkungan.
  • Ketahanan yang kompatibel dengan 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 air gap dengan menggunakan registry lokal, pemindaian gambar 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 pod database dan Operator Oracle berada.
  • Harbor Registry: Sumber tepercaya lokal yang aman untuk semua image penampung. Layanan ini menyediakan pemindaian otomatis untuk memastikan image bebas dari kerentanan yang diketahui.
  • Penyimpanan persisten: Class penyimpanan GDC standard-rwo menyediakan penyimpanan blok dasar yang diperlukan untuk file data Oracle, log redo, dan file kontrol menggunakan PersistentVolumeClaim.

Layanan dan logika

  • Operator Database Oracle: Pengontrol yang bertanggung jawab untuk memantau resource kustom seperti SingleInstanceDatabase dan DataguardBroker. Operator ini menyelaraskan objek ini ke dalam objek Kubernetes standar, termasuk StatefulSets untuk pod database dan layanan untuk jaringan.
  • Single Instance Database (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. Operator 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.

Aliran dan antarmuka data

  • SQL*Net (Port 1521): Protokol utama untuk konektivitas aplikasi.
  • Pengekspor kemampuan pengamatan: 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 taint dan toleransi adalah praktik terbaik untuk mendedikasikan node tertentu untuk workload database.
    • Performa sangat bergantung pada penyimpanan yang mendasarinya; sebaiknya gunakan standard-rwo dengan IOPS tinggi.
  • Pengelolaan resource dan pemberian lisensi:
    • Solusi ini mengikuti model Bring-Your-Own-License (BYOL).
    • Fitur lanjutan seperti Transparent Data Encryption (TDE), Kompresi Lanjutan, 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 zona tunggal dengan 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 di 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 masih memerlukan keahlian administrasi database.
    • Penggunaan container sidecar direkomendasikan untuk meneruskan log audit dan trace mendetail yang tidak dikirim ke stdout.

Keputusan desain

Pilihan arsitektur utama untuk solusi ini berfokus pada menyeimbangkan otomatisasi dengan batasan lingkungan yang terisolasi dari internet.

Data Guard versus replikasi tingkat penyimpanan

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

Pengelolaan layanan untuk load balancer

Secara default, menyetel 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 networking.gke.io/load-balancer-type: "Internal" yang diperlukan. Pendekatan manual ini memberikan kontrol deklaratif atas anotasi dan label yang mungkin tidak diekspos oleh layanan yang dikelola operator secara default.

Strategi kemampuan observasi sidecar untuk log

Solusi ini merekomendasikan penggunaan penampung sidecar untuk penerusan log. Hal ini memisahkan pengumpulan log dari proses database utama, sehingga memastikan bahwa volume logging yang besar tidak memengaruhi performa database. Meskipun hal ini 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 gambar.
  • Cert-manager sudah diinstal sebelumnya di cluster standar untuk menangani sertifikat webhook operator.
  • Penyimpanan objek yang kompatibel dengan S3 tersedia untuk target pencadangan RMAN.

Batasan

  • HA zona tunggal: Konfigurasi ketersediaan tinggi didukung dalam satu zona.
  • Tanpa Oracle RAC: Dukungan untuk Real Application Clusters (RAC) tidak disertakan; solusi ini berfokus pada Single Instance dan Data Guard.
  • Khusus kluster standar: Solusi ini divalidasi untuk kluster standar GDC dan tidak didukung di kluster pengguna bersama.

Langkah berikutnya