Belajar Kubernetes Distributed Storage - Stretch Cluster & Multi-DC / Disaster Recovery

#Pendahuluan

Kapasitas & performa sudah matang (episode 19-20). Episode 21 membahas dinding terakhir: resiliensi lintas data center — apa yang terjadi jika satu DC mati total?

Mengapa penting? Kegagalan DC lebih langka daripada kegagalan host, tetapi dampaknya jauh lebih besar. Ceph menawarkan dua mekanisme: stretch cluster (mirip aktif-aktif, quorum tersebar) dan RBD mirroring (replikasi async ke klaster sekunder). Memilih dan menyusun keduanya dengan benar adalah spesialisasi admin storage production.

#Stretch Cluster

#Konsep: DC sebagai Failure Domain

Stretch cluster membuat MON & data tersebar di 2 DC + 1 arbiter:

yaml

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephConfig:
    global:
      mon_host: ...
  mon:
    count: 5   # 2 di DC1, 2 di DC2, 1 arbiter

Bakar atau kuorum hotlist MON DC3 tipis.

Prinsipnya:

2 data centers menyimpan replika (data tetap hidup saat satu DC mati).
Site ketiga (arbiter) menyediakan quorum MON — mencegah split-brain.
Latency DC1↔DC2 harus rendah (ideal di bawah 50 ms) untuk data replikasi sinkron.

#Batasan

Stretch memerlukan setidaknya 5 MON & koneksi reliable antar-DC.
Replikasi sinkron antar-DC → transaction commit tergantung round-trip → latency database naik.
Bukan solusi untuk semua — hanya untuk yang benar-benar membutuhkan.

#RBD Mirroring (Async) — DR Terpisah

#Alur Async

Kembali ke konsep episode 14: RBD mirroring async mereplikasi image ke klaster sekunder dengan lag beberapa detik/menit.

yaml

apiVersion: ceph.rook.io/v1
kind: CephRBDMirror
metadata:
  name: rbd-mirror
  namespace: rook-ceph
spec:
  count: 2

Promosi manual: pada DR, klaster sekunder di-promote.
RPO = waktu lag mirror (beberapa detik). RTO = waktu manual restore aplikasi.

#Kapan Pakai

Klasik untuk workload yang boleh kehilangan beberapa detik data:

Media gallery / arsip file.
Data analitik yang tidak bersifat transaksional.
DR RPO 15 detik-1 menit.

Tapi bukan untuk database transaksi yang wajib RPO 0 — itu tugas stretch/kuorum sinkron.

#Failover & Failback

#Skenario Failover

DC1 offline → promote sekunder.
Aplikasi di failover klaster memakai image miror.
Data dari mirror (beberapa detik hanya hilang).

Promosi sekunder (di klaster DR)

rbd mirror image promote replicapool/csi-vol-xxx

#Skenario Failback

DC1 pulih → re-sync (mirror kembali) dari sekunder ke primer.
Demote sekunder, promote primer.
Redirect aplikasi.

Peringatan penting: jangan pernah membuka kedua sisi sekaligus (split-brain). Satu arah aktif di satu waktu.

#Quorum MON & Split-Brain

#Mengapa Arbiter Penting

Split-brain terjadi bila 2 DC bertengkar "siapa yang benar". Arbiter ketiga & quorum (majority) memutuskan.

MON harus majority (mis. 3 dari 5) untuk menulis — DC biasa memerlukan partisipasi arbiter.
Pastikan MON tidak mulai di DC yang "separated" sendiri tanpa quorum.

#Rule of Thumb

Untuk klaster 2 DC selalu tambahkan arbiter (site ketiga) bila kritis.
RBD mirroring tidak memiliki quorum lintas klaster — konsistensi dijaga manual (failover satu arah).

Warning

Dokumenkan perintah failover dalam runbook. Saat DC1 benar-benar mati, tim tidak boleh mencoba "mempromosi semua" secara tebak-tebakan. Tetapkan: siapa yang boleh promote, langkah apa, siapa yang mengubah DNS/DNS routing aplikasi.

#Network & Latency Budget

#Persyaratan Jaringan

Stretch: RTT antar-DC di bawah 50 ms (idealnya di bawah 10 ms), bandwidth memadai (replikasi sinkron + client).
Mirroring async: lebih toleran (lag menyesuaikan), tapi tebal saat initial sync/re-sync besar.

#Mengukur

bash

ping -c 5 <ip-dc2-mon>
iperf3 -c <ip-dc2>   # bandwidth

Gunakan hasil ini untuk menentukan mode mana yang layak.

#Penutup

Inti yang harus dibawa pulang:

Stretch cluster: sinkron lintas 2 DC + arbiter (quorum) — RPO 0, butuh latency rendah.
RBD mirroring async: DR terpisah, RPO detik-menit, aktif failover manual.
Failover/failback: satu arah aktif; anti split-brain (jangan 2 sisi).
Arbiter & quorum MON menentukan konsistensi lintas DC.
Ukur latency & bandwidth sebelum memilih mode; tulis runbook DR.

Di episode 22 selanjutnya kita akan membahas node maintenance & drain yang Ceph-safe — menjaga daemon Ceph saat maintenance, drain OS node, dan waktu yang pas untuk OS maintenance. Sampai jumpa di episode 22!