Belajar Kubernetes Block Storage RWO - Performance Tuning & Volume Expansion

#Pendahuluan

Kita telah membangun, menyimpan, membackup, dan memonitor Longhorn. Episod 18 memasuki ranah yang disukai banyak orang: kecepatan. Storage yang lambat akan menyeret seluruh database. Kita pelajari cara mengukur, men-tune, dan memperbesar kapasitas volume tanpa downtime.

Mengapa penting? Beban database vs storage menyesuaikan seiring waktu — dan tanpa tuning, perangkat bekerja suboptimal tanpa kalian tahu. Benchmark yang rutin memberi angka yang bisa dipertandingkan ketika memakai perubahan parameter.

#Expand Volume

#Dari Kubectl

Volume bisa di-resize secara online (tanpa melepas Pod). Ubah requests.storage di PVC:

yaml

kubectl edit pvc data-postgres-0

Ubah:

yaml

spec:
  resources:
    requests:
      storage: 20Gi  # dari 10Gi

Longhorn controller mendeteksi perubahan dan otomatis melakukan resize (filesystem ext4/xfs didukung online resize). Tidak perlu unmount; Pod tetap jalan.

#Verifikasi

Cek PVC & filesystem di pod

kubectl get pvc data-postgres-0
kubectl exec -it postgres-0 -- df -h /var/lib/postgresql/data

Pastikan kapasitas baru muncul di df -h. Untuk parameter allowVolumeExpansion, wajib diaktifkan di StorageClass (episode 20). Tanpa itu, resize PVC akan tertahan FilesystemResizePending.

#Tuning Engine/Replica

#QoS dan Queue Depth per Volume

Longhorn memungkinkan kontrol per volume lewat label longhorn.io/volume-* — misalnya membatasi IOPS/throughput (QoS) agar satu volume tidak memonopoli disk. Di UI, setting Volume memberi pilihan:

IOPS limit (read/write).
Bandwidth limit (MB/s).
Queue depth engine (block device) untuk mengatur seberapa dalam permintaan I/O dikirim.

Untuk database, cukup beri QoS yang tegas agar volume DB mendapat slot performa yang stabil.

#V2 Engine (SPDK/NVMe-oF)

Jika memakai V2 Data Engine (SPDK):

Butuh hugepages 2 MB yang dialokasi di node.
Meng-attach volume lewat nvmeof (NVMe-oF) — latency lebih rendah, butuh tuning kernel.

Pertimbangkan V2 ketika database butuh low-latency ekstrem (high IOPS) dan node mendukung hugepages. Di deployment rumahan, V1 dengan setting queue depth cukup biasanya sudah memadai.

#Filesystem & Mount Options

#ext4 vs xfs

Aspek	ext4	xfs
Default Longhorn	Ya	Opsional
Online resize	Ya	Ya
File besar	Baik	Unggul
Recover cepat	Ya	Ada `xfs_repair`

Keduanya aman untuk PostgreSQL. Pilih xfs jika workload menekankan fleksibilitas file besar.

#Mount Options

Tambahkan di StorageClass (parameter mountOptions):

yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-db
provisioner: driver.longhorn.io
allowVolumeExpansion: true
mountOptions:
  - noatime
  - nodiratime
parameters:
  numberOfReplicas: "3"
  fsType: "xfs"

noatime / nodiratime menghindari update akses-timestamp — menekan write overhead — aman untuk database. Jangan gunakan sync naif (semua write jadi barang mahal).

#Tuning Database (Opsional)

Di PostgreSQL, fsync=on (default). Storage modernLonghorn yang sudah fsync-friendly mengizinkan synchronous_commit diatur per-transaksi. Pada MySQL, pertimbangkan innodb_flush_method=O_DIRECT bila dropdown FX diperparah. Ingat: jangan pernah mematikan durabilitas database demi kecepatan.

#Benchmark

#fio di Pod

Siapkan Pod benchmark dengan Pod yang punya volume mount sementara. Jalankan fio dari dalam container:

fio sequential & random

fio --name=seqwrite \
    --rw=write \
    --bs=1M \
    --size=2G \
    --filename=/data/fio \
    --numjobs=1 \
    --direct=1
 
fio --name=randrw \
    --rw=randrw \
    --bs=4k \
    --size=2G \
    --filename=/data/fio \
    --numjobs=4 \
    --iodepth=16 \
    --direct=1

Catat ISOPS, latency, throughput. Jalankan di DB dengan V1 dan V2, bandingkan.

#Mengamati Dampak

Benchmark rutin (mis. bulanan) dan simpan angka baseline:

Sebelum/standar setelah mengubah parameter.
Melacak degradasi saat disk penuh/penuh.

Kalau database terasa lambat di produksi — cek dulu benchmark ini, bukan ganti storage.

Tip

Saat benchmark, pastikan tidak ada workload database nyata berjalan di volume yang sama — fio akan mendominasi I/O. Jalankan di luar jam puncak atau gunakan pod terpisah.

#Penutup

Inti yang harus dibawa pulang:

Expand volume online: edit requests.storage PVC → Longhorn resize otomatis.
Tuning engine/replica pakai QoS (IOPS/bandwidth) + opsi queue depth; V2 butuh hugepages.
noatime/nodiratime mount options menekan overhead write pada DB.
Benchmark fio untuk mengukur dan membandingkan V1 vs V2.

Di episode 19 selanjutnya kita akan membahas scaling database & aplikasi pakai RWO — scaling Laravel replica sambil menjaga satu primary DB, read-replica PostgreSQL dengan volume RWO, peran HPA & cache/Redis, dan kapan harus memperbesar disk. Sampai jumpa di episode 19!