Belajar Kubernetes Block Storage RWO - Replikasi Data & High Availability

#Pendahuluan

Di episode 8 kita menata data lifecycle dan backup. Episode 9 menjawab pertanyaan yang selalu muncul saat node mati: kenapa volume saya masih jalan / stuck / offline? Ini adalah jantung high availability Longhorn — memahami kuorum, rebuild, dan status volume.

Mengapa penting? Sebagai operator, kalian harus tahu kapan cluster aman dan kapan berbahaya. Menjalankan volume dengan 2 dari 3 replika sehat adalah normal; menjalankan dengan 1 replika sehat adalah alarm. Di episode ini kalian juga akan mempraktikkan simulasi kegagalan tanpa merusak data.

#Memahami Perilaku Replica

#Kuorum dan Status Volume

Volume dengan numberOfReplicas: 3 membutuhkan kuorum 2 untuk bertulis (write). Artinya:

Replica Sehat	Status Volume	Kapabilitas
3/3	Healthy	Write + Read normal
2/3	Degraded	Write + Read tetap jalan (kuorum terpenuhi)
1/3	Offline (no healthy replica)	Tidak bisa attach — data tidak boleh ditulis

Ketika dua node mati bersamaan dari volume 3-replica, sisa satu tidak cukup membentuk kuorum → volume offline untuk keamanan (mencegah data korupsi).

#Demostrasi: Degraded & Rebuild

Buat volume 3-replica (StorageClass longhorn-ha).
kubectl drain worker-2 --ignore-daemonsets --delete-emptydir-data.
Lihat status volume: Degraded 2/3 — masih jalan.
Buka UI → pilih Replica rebuild → Longhorn membuat replika baru di node tersedia.
Setelah sinkronisasi selesai, status kembali Healthy 3/3.

Cek status volume via kubectl

kubectl -n longhorn-system get volumes
kubectl -n longhorn-system get replicas.longhorn.io

#Rebuild Replica

Rebuild terjadi otomatis maupun manual. Langkah manual di UI:

Buka Volume → pilih volume → Replicas → pilih replika yang ERR/terjoin → Rebuild.
Longhorn menciptakan replika baru di node dengan ruang cukup, lalu menyalin data dari replika sehat.

Perubahan numberOfReplicas juga memicu auto reconciliation:

yaml

# set StorageClass baru atau edit volume
numberOfReplicas: "2"

Longhorn otomatis menyesuaikan jumlah replika seluruh volume yang memakai StorageClass tersebut. Ini rekonsiliasi desired state — bukan operasi manual per volume.

#Biaya Rebuild

Rebuild = transfer semua data volume ke node baru. Untuk volume 100 GB, rebuild menghabiskan bandwidth dan I/O. Bijaklah: jangan melakukan rebuild banyak volume bersamaan di saat window peak.

#Data Locality dan Performa

#strict-local

Semua replika berada di node yang sama dengan volume aktif. Latency I/O paling rendah (tidak ada jaringan antar replika), tetapi tidak ada replikasi cross-node — kalau node mati, volume mati. Cocok untuk beban I/O yang sangat sensitif dan sudah menerima single-node risk.

#best-effort

Mencoba menaruh replika di node yang memakai volume (lokal), tapi tetap bisa menyebar bila node penuh. Ini default yang seimbang: read datang dari replika lokal, dan masih ada replika di node lain.

#disabled

Longhorn bebas menempatkan replika di mana pun — performa paling bervariasi.

Untuk database 2-node: gunakan best-effort untuk keseimbangan latency + HA.

#Simulasi Failure

#Skenario Nyata

Simulasikan node worker-1 mati

kubectl cordon worker-1
kubectl drain worker-1 --delete-emptydir-data --ignore-daemonsets --force

Drain akan memindahkan Pod. Longhorn mendeteksi node tidak terjadwal; replika yang di sana menandai diri Failed; Kubernetes tidak bisa memakai volume dari node tersebut hingga replika rebuild di node sehat.

Setelah perawatan selesai, kembalikan node:

Kembalikan node

kubectl uncordon worker-1

Longhorn perlahan me-rebuild replika yang hilang setelah node kembali — status volume kembali Healthy tanpa downtime data.

Caution

Drain node storage akan memicu rebuild — perhatikan disk dan bandwidth. Pastikan ada node lain dengan ruang cukup sebelum menjalankan drain. Jika tidak, replika tidak bisa dijadwalkan dan volume akan stuck degraded selamanya.

#Latihan Cordon/Uncordon

Cordon dan drain worker-1.
Amati kubectl -n longhorn-system get volumes → Degraded.
Uncordon; amati proses rebuild hingga Healthy.
Ulangi untuk worker-2.

Praktik ini membangun reflek: sebelum maintenance node apa pun, pastikan Longhorn punya ruang untuk rebuild.

#Penutup

Inti yang harus dibawa pulang:

3 replika = kuorum 2: tahan 1 node gagal; degraded ≠ bahaya, offline = aman karena quorum gagal.
Rebuild otomatis saat replika hilang; perubahan numberOfReplicas → auto reconciliation.
strict-local = latency terbaik tapi tanpa HA; best-effort = keseimbangan.
Latihan cordon/drain/uncordon wajib dilakukan di lab sebelum menyentuh production.

Di episode 10 selanjutnya kita akan membahas management node & disk Longhorn — menambah/mengurangi disk, menandai node non-schedulable untuk maintenance, disk eviction saat mengganti SSD, dan membuat StorageClass multi-tier (SSD vs HDD). Sampai jumpa di episode 10!