Belajar Kubernetes Shared Filesystem RWX - High Availability NFS Server

#Pendahuluan

Sejauh ini, semua Pod aplikasi berputar di satu NFS server (single PVC). Nyaman untuk lab — tetapi satu kejadian kecil (kabel jaringan, disk penuh, node reboot) menghentikan mount semua worker. Episode 20 membahas high availability NFS server dengan jujur: kapan perlu, opsi apa yang bisa dipilih, dan kapan solusi "lebih besar" sebenarnya lebih salah daripada benar.

#SPOF NFS Server

Arsitektur kita saat ini:

text

Worker 1 ──┐
Worker 2 ──┼──► NFS SERVER (satu Pod/Service) ──► PersistentVolume ──► Disk Node
Worker 3 ──┘         (single point of failure)

Jika NFS server mati:

Semua hard mount (episode 19) menggantung — proses aplikasi tidak kemana-mana.
Aplikasi tidak bisa menulis media; upload gagal; replika tidak sinkron.
Restore hanya terjadi setelah NFS server kembali — bukan otomatis.

Ini tidak berarti arsitektur one-server salah untuk lab — tetapi keputusan ini harus sadar: kalian menukar kesederhanaan dengan toleransi.

Note

Test yang tegas: kubectl scale deploy nfs-server --replicas=0 lalu lihat dampaknya. Jika aplikasi berhenti berfungsi dan tidak ada rencana pemulihan dalam 5 menit, SPOF nyata — dan kalian memutuskan bahwa risiko itu tidak melebihi nilai kesederhanaan.

#Opsi HA

#DRBD + Pacemaker/Corosync

Pendekatan klasik di bare-metal: mereplikasi block secara sinkron antara dua node, dengan VIP dan failover otomatis:

text

Dua node NFS
   ├── DRBD (replikasi block sinkron)
   ├── Pacemaker/Corosync (manajemen resource & split-brain prevention)
   ├── Virtual IP (VIP): klien mount ke VIP, bukan ke IP node
   └── STONITH (fencing): mematikan node yang membingungkan

Kelebihan: failover dalam hitungan detik, tanpa mengubah alamat mount (VIP).

Kekurangan di Kubernetes: menjalankan Pacemaker/DRBD di dalam cluster berarti menggandakan kompleksitas sistem sendiri (fencing, quorum, kernel module) — biasanya di luar scope "simple shared storage".

#GlusterFS — berat

Gluster menawarkan HA terdistribusi, tetapi dalam praktik di stack ini: penyesuaian cache yang serius, kontrol peledakan saat terganggu, dan overhead operasi jauh melebihi manfaat untuk jumlah file media yang kita kelola. Untuk kepentingan ini, lewati Gluster dan lihat Rook-Ceph bila benar-benar butuh distributed storage.

#Cloud-Native: NFS-as-a-Service

Di managed Kubernetes, biasanya ada tawaran native:

StorageClass managed NFS (ilustrasi)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs
provisioner: kubernetes.io/<cloud-nfs>
parameters:
  server: nfs.gcp.internal   # contoh
  export: /share/laravel

Tidak ada yang perlu di-HA-kan — penyedia mengelolanya. Kapan pilihan ini unggul: tim kecil, menginginkan guarantee SLA dan tidak ingin memakai waktu untuk runbook NFS (lihat perbandingan biaya di episode 26).

Tip

Urutan keputusan HA yang masuk akal: (1) pastikan operasi NFS ditangani dengan jelas (satu halaman runbook); (2) bila ada kebutuhan SLA — utamakan data penting: backup berlapis (ep 21) dan NFS server yang sehat; (3) terakhir baru pertimbangkan DRBD/Rook — karena kompleksitas justru paling tinggi dan berisiko merusak yang sudah berjalan baik.

#Failover & Fencing

Jika kalian memilih jalur DRBD/Pacemaker, tiga prinsip wajib:

Hanya satu node aktif menulis — resource terbatas ke primary; secondary read-only.
Virtual IP — klien mount ke VIP; failover tidak mengubah mount point.
STONITH wajib — mencegah split-brain (dua primary sekaligus = data rusak).

Verifikasi dari sisi klien:

Cek failover terdeteksi klien

mount | grep nfs
df -h /shared
pwd && touch /shared/sekali-tulis.txt && cat /shared/sekali-tulis.txt

Dengan mount hard, operasi yang menggantung saat failover akan melanjutkan otomatis setelah VIP pindah — itulah nilai hard + intr (episode 19, 25).

#Kapan Upgrade ke Distributed Storage

Ada batas ketika NFS dengan HA klasik bukan jawaban yang tepat lagi. Pindah ke Rook-Ceph (atau setara) ketika:

Storage > ekspor tunggal — kapasitas satu NFS/export tidak cukup.
Replikasi otomatis multi-node — data harus ada di 3 replica tanpa skrip DRBD manual.
Persyaratan RTO/RPO rendah — pemulihan dalam menit, bukan rencana pemulihan manual.
Multi-tenant skala menengah — N namespace dengan SLA berbeda.

Ceph memberi: replication factor, self-healing, erasure coding, tiering. Biayanya: opers yang jauh lebih besar (lebih banyak komponen bergerak) dan tim harus mampu menyerapnya.

Lihat series belajar Rook-Ceph untuk jalan setapak menuju distributed storage bila kebutuhan kalian sudah di sana.

Warning

Kutukan medium: Jangan membangun DRBD/Ceph yang kompleks hanya karena NFS server kadang turun — solusi itu sering menjadi sumber downtime baru yang lebih parah. Evaluasi: apakah masalah yang kalian hadapi benar-benar HA, atau hanya butuh backup yang cepat (ep 21) dan NFS server yang lebih kuat saja.

#Penutup

Pada episode 20 ini, kalian memahami titik gagal dan jalur HA dengan kepala dingin:

Inti yang harus dibawa pulang:

Satu NFS server = SPOF nyata; mount hard menggantung saat server mati.
Opsi HA: DRBD+Pacemaker (block sinkron + VIP + STONITH), NFSaaS, atau Rook.
Gluster berat & tidak sepadan di sini.
Failover: satu primary, VIP, STONITH; klien auto-recover dengan hard.
Ke distributed storage: hanya saat butuh replikasi otomatis dan scale > ekspor tunggal.

Di episode 21 selanjutnya kita akan melindungi data yang tersimpan di NFS ini: instalasi Velero, backup namespace + volume, restore yang teruji, dan strategi RPO/RTO yang dapat dijalankan tim kecil. Sampai jumpa di episode 21!