Belajar Kubernetes Simple Shared Storage - Performance & Tuning Lab

#Pendahuluan

Mitos "NFS = lambat" tidak selalu benar — dan tidak selalu salah. Episode 19 menghentikan debat dengan data: kita mengukur performa Local PV dan NFS di lab yang sama, memahami di mana latensi muncul, lalu meramu tuning yang masuk akal untuk beban web files.

Alasan episode ini penting: keputusan "storage mana untuk beban mana" akan jauh lebih baik bila disertai angka, bukan perasaan.

#Benchmark Simple

#dd (throughput kasar)

Benchmark dd di volume NFS

kubectl exec deploy/rwx-writer -- sh -c \
  'dd if=/dev/zero of=/shared/test.bin bs=1M count=1024 oflag=direct status=progress'

Ulangi di Local PV hostpath (mount folder node) dengan Pod yang memakai openebs-hostpath. Bandingkan hasil MB/s.

#fio (lebih presisi)

Gunakan image openebs/fio dalam Pod untuk benchmark read/write acak:

Benchmark fio di NFS RWX

kubectl exec deploy/rwx-writer -- sh -c \
  'fio --name=test --rw=randrw --rwmixread=80 --bs=4k \
      --numjobs=4 --iodepth=16 --size=512M --direct=1 \
      --time_based --runtime=30 --directory=/shared'

Untuk episode ini cukup catat tiga metrik: read IOPS, write IOPS, latency (clat) dari proses NFS vs hostpath.

#Latensi Network

NFS menempuh jalan lebih jauh: Pod → CNI → pod-network → NFS Server Pod → backing hostpath → disk. Setiap hop menambah delay:

Hostpath:   Pod → disk node           (lokal, ~0.1-1 ms)
NFS RWX:    Pod → NFS Server → disk   (lewat network, +RTT node)

Untuk file besar yang dibaca berurutan, overhead-nya kecil. Untuk ribuan file kecil / stat calls, latensi per-operasi menjadi nyata — inilah mengapa media & upload cocok di NFS, tetapi database & cache tidak.

#Tuning

#Mount Options di PVC

Opsi mount NFS dapat diatur di StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-nfs-rwx
provisioner: openebs.io/nfs
parameters:
  backendStorageClass: openebs-hostpath
  nfsServerType: kernel-nfs
mountOptions:
  - hard
  - intr
  - noatime

Penjelasan:

• hard — retry tanpa batas saat server bermasalah (data aman; lihat episode 25).
• intr — operasi bisa diinterupsi sinyal (mengurangi "hang" tak terkendali).
• noatime — tidak menulis access time; mengurangi penulisan metadata yang tidak perlu.

#Local PV: Node Affinity

Untuk Local PV, sedekat mungkin dengan aplikasi:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: storage-node
              operator: In
              values: ["true"]

Scheduler menempatkan Pod database di node penyimpan datanya — menghindari data dan compute di node berbeda (meski Local PV memang otomatis terikat node saat Pod pertama berjalan).

#Trade-off

Keputusan akhir selalu kompromi:

NFS RWX lebih fleksibel, tetapi harganya latency sedikit lebih tinggi — dan itu tidak masalah untuk beban web files. Kalian tidak mengukur supaya semua cepat; kalian mengukur supaya tahu mana yang pantas di mana.

#Penutup

Pada episode 19 ini, keputusan storage bersandar pada angka:

Inti yang harus dibawa pulang:

• Benchmark: dd dan fio untuk throughput & IOPS; bandingkan NFS vs hostpath.
• Latensi NFS berasal dari hop jaringan: Pod → NFS server → disk.
• Mount options: hard,intr,noatime untuk keseimbangan keamanan & kecepatan.
• Local PV: node affinity menjaga data dekat aplikasi.
• Trade-off: NFS RWX fleksibel, hostpath cepat — tempatkan berdasarkan beban.

Di episode 20 selanjutnya kita akan melindungi data lab: pg_dump berjadwal, rsync media, instalasi Velero, backup resources + PVC, dan uji restore yang rutin. Sampai jumpa di episode 20!