Rencana Arsitektur Implementasi Database Cluster¶

Kondisi Kapasitas Cluster Saat Ini¶

Topologi Node¶

Node Role	Node	Spek/node	Taint	Fungsi
Master	10.0.0.2	2 vCPU / 8GB RAM	CriticalAddonsOnly (NoExecute)	Control-plane RKE2 — tidak menjalankan workload aplikasi
Compute Worker	10.0.0.3–6 (4 node)	2 vCPU / 7.6GB RAM /node	Tidak ada	Tempat pod aplikasi (termasuk database cluster) dijadwalkan
Storage Node	10.0.0.7–9 (3 node)	2 vCPU / 2.9GB RAM /node	node.longhorn.io/create-default-disk (NoSchedule)	Dedicated untuk replika data Longhorn

Total pool compute relevan: 8 vCPU / ~30GB RAM, sebagian besar masih bebas untuk workload baru.

Kapasitas Storage (Longhorn)¶

Item	Nilai
Kapasitas per storage node	~120GB (3 node dedicated)
Replikasi default StorageClass	3× (numberOfReplicas: 3)
Kapasitas usable efektif	~120GB

Rencana Arsitektur¶

1. Strategi Storage — Hindari Double-Replication¶

Karena Galera sudah melakukan replikasi data sendiri (3 node), replikasi Longhorn default (3×) akan menyebabkan duplikasi 9× (3 node DB × 3 replika Longhorn) jika tidak diatur ulang.

Rencana: Buat StorageClass khusus untuk PVC database dengan numberOfReplicas: 1, konsisten dengan pendekatan longhorn-ssd/longhorn-hdd pada SEKSI-02 namun disesuaikan replika untuk menghindari duplikasi berlebih:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-db-single
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "1"
  staleReplicaTimeout: "30"
allowVolumeExpansion: true

2. Strategi Penjadwalan Pod (Anti-Affinity)¶

Agar HA benar-benar efektif, 3 pod Galera wajib tersebar ke node fisik berbeda di antara 4 compute node (10.0.0.3–6) — bukan menumpuk di satu node.

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: mysql-galera
      topologyKey: kubernetes.io/hostname

3. Operator Kubernetes¶

Teknologi	Operator	Keterangan
MariaDB Galera	mariadb-operator	CRD-native khusus MariaDB (bukan Percona XtraDB — itu fork MySQL), mendukung Galera, backup otomatis, dan manajemen User/Database/Grant deklaratif

4. Estimasi Resource (Sesuai Sizing SEKSI-01)¶

Komponen	Replica	Request	Limit	StorageClass / PVC
HAProxy / Ingress	1	0,5 vCPU / 512 MB	1 vCPU / 1 GB	— (stateless)
Redis (Cache)	1	0,5 vCPU / 1 GB	1 vCPU / 2 GB	longhorn-db-single, ~10–20 GB (opsional)
ProxySQL	1	0,5 vCPU / 512 MB	1 vCPU / 1 GB	— (stateless)
MariaDB Galera	3	0,5 vCPU / 1 GB per node	1 vCPU / 2 GB per node	longhorn-db-single, ~50 GB/node

Total request: ~2,5 vCPU / ~5,5GB — nyaman dibandingkan headroom pool compute (~6,5 vCPU bebas dari total 8 vCPU).

5. Namespace¶

Rencana namespace: galera-system (mengikuti pola stack aplikasi pada SEKSI-01), terpisah dari longhorn-system, traefik-system, dll.

Tahapan Implementasi¶

1. Buat StorageClass khusus (longhorn-db-single)
2. Buat namespace galera-system
3. Install mariadb-operator via Helm (lihat Instalasi MariaDB Galera)
4. Deploy custom resource Galera (3 node) dengan pod anti-affinity dan StorageClass khusus
5. Deploy HAProxy/Ingress, Redis, ProxySQL sesuai SEKSI-02
6. Verifikasi cluster sehat: quorum/replikasi jalan, failover test
7. Setup backup terjadwal ke object storage S3-compatible
8. Dokumentasi kredensial & connection string untuk tim aplikasi (disimpan aman, terpisah)

Risiko & Mitigasi¶

Risiko	Mitigasi
Double-replication storage (9×) menghabiskan kapasitas Longhorn	StorageClass khusus numberOfReplicas: 1
3 pod Galera menumpuk di 1 node fisik (HA semu)	Pod anti-affinity wajib
Beban tambahan pada pool compute yang hanya 4 node	Mulai dengan sizing SEKSI-01 (ringan), monitor kubectl top nodes
Resource contention dengan komponen platform lain	Set resource requests & limits eksplisit

Keputusan yang Masih Diperlukan¶

• [ ] Konfirmasi jadwal mulai migrasi rolling (lihat Rencana Migrasi)
• [ ] Estimasi ukuran data & beban query aktual dari layanan (Hosting-Farmasi, Hosting-FEB, dll.) yang akan dimigrasikan
• [ ] Konfirmasi kebutuhan backup otomatis ke storage eksternal (S3-compatible) dan kredensialnya
• [ ] Konfirmasi skema database, user aplikasi, dan kebijakan akses per layanan

Langkah Selanjutnya¶

Setelah poin-poin di atas dikonfirmasi, implementasi dapat dimulai mengikuti tahapan pada bagian Tahapan Implementasi. Estimasi waktu eksekusi: 1–2 jam kerja interaktif, di luar waktu tunggu image pull & inisialisasi cluster.

---

Direncanakan 8 Juli 2026. Belum ada perubahan yang dieksekusi ke cluster oneKE terkait rencana ini.