Belajar Kubernetes Distributed Storage - Performance & Failure Domain

#Pendahuluan

Ceph sudah dimonitor (episode 18). Episode 19 menjawab pertanyaan yang selalu muncul saat storage produktif digunakan: "seberapa kencang? dan bagaimana memastikan data aman saat satu host/rack mati?" Dua konsep: performance dan failure domain.

Mengapa penting? Sebuah storage yang lambat atau yang silaht donasi data saat rack mati adalah kewajiban yang gagal. Memahami domain kegagalan menentukan redundancy menyeluruh; memahami pola I/O menentukan optimasi. Keduanya menciptakan storage yang benar-benar "tinggal pakai".

#Benchmark Block (fio)

#Pasang fio di Client

Jalankan fio di Pod client

kubectl exec -it deploy/bench -- fio --name=test \
  --filename=/mnt/bench/testfile \
  --rw=randwrite --bs=4k --numjobs=4 --iodepth=32 \
  --runtime=30 --time_based --group_reporting

#Perbedaannya: replicated vs erasure coding

Mode	Read	Write	Keterangan
Replicated (RBD)	Tinggi	Tinggi	Contoh PV production
EC (RBD pool EC)	Bisa lebih lambat (CPU paritas)	Menurun saat write	Hemat disk, kost CPU

Untuk workload database (PostgreSQL, episode 10), replicated RBD biasanya pilihan tepat.

#Baca Hasil

fio menampilkan IOPS & bandwidth (4k randwrite, sequential read, dll). Simpan baseline untuk dibandingkan setelah tuning.

#Benchmark Object (s3cmd / aws cli)

#Upload/Download Batch

Benchmark object upload

aws --endpoint-url http://rook-ceph-rgw-my-store:8080 \
  s3 cp --recursive /tmp/big-files s3://bench-bucket/

Atau dengan presigned URL (repo benchmark) untuk download parallel.

#Yang Diukur

Throughput upload (Mbps).
Latency per request (head/stat).
Concurrent object limit — RGW instances.

#Failure Domain

#`failureDomain: host | rack | region`

Pool menentukan di mana data boleh "jangan bersama". Contoh:

yaml

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicated-pool
  namespace: rook-ceph
spec:
  failureDomain: host
  replicated:
    size: 3

host — replika minimal di host yang berbeda (bila ada banyak OSD per node).
rack / failure domain rack — replika antar rack berbeda.
region (data center) — replika lintas DC.

#Pilih Sesuai SLOD&C

Kompromi:

failureDomain	Tahan pada	Kerugian
host	1 host mati	Bandwidth intra-node tinggi
rack	1 rack mati	Jadi terbentang antar-node → latency lebih
region	1 DC mati	Latency lintas DC; butuh bandwidth ekstra

Untuk DB production, pilih setidaknya host (dan bila menekan rack bila punya 3+ rack).

#Mode RBD Data Pool (optimasi latensi)

#`dataPool` terpisah untuk WAL/DB

Untuk beban sync-heavy (DB), pisahkan journal/data:

yaml

spec:
  blockSize: 4m
  replicated:
    size: 3
  dataPool:
    replicated:
      size: 3

Ini membuat RBD memisahkan data segar (memakai recovery pool terpisah) & memungkinkan melakukan fragmen. Tidak wajib untuk semua workload — tetapi penting untuk latency rendah DB.

#NVMe-oF (Ceph v20 / RBD)

#Latency Rendah via NVMe-oF

Sejak Ceph v20 (didukung Rook v1.20), RBD bisa diekspos sebagai NVMe-oF — client attach volume sebagai NVMe drive lewat TCP. Keuntungan:

Latency lebih rendah (queueing NVMe, tidak lewat emulasi SCSI).
Lebih cocok database berbasis NVMe.

Setup: CephBlockPool ekspos dengan endpoint NVMe-oF (lihat dokumentasi Rook) dan driver client. Untuk lab, benchmarking dengan replicated RBD biasa sudah cukup — NVMe-oF adalah optimasi lanjutan.

Warning

fio di cluster tanpa beban ≠ fio di cluster production. Untuk nilai yang dapat dipercaya, jalankan benchmark saat ada workload riil (atau di maintenance window), dan gunakan baseline berkala untuk melihat degradasi OSD/net.

#Penutup

Inti yang harus dibawa pulang:

Benchmark block fio (4k randwrite, sequential) untuk baseline; bandingkan replicated vs EC.
Object storage diukur dengan throughput & latency (upload/download RGW).
failureDomain: host/rack/region menentukan toleransi kehilangan rack/DC sempurna.
dataPool terpisah dapat membantu latency DB; NVMe-oF (Ceph v20) untuk jalur low-latency.

Di episode 20 selanjutnya kita akan membahas volume expansion & allowVolumeExpansion — memperbesar PVC PostgreSQL tanpa downtime saat database membesar, dan bagaimana Ceph menangani penambahan kapasitas secara live. Sampai jumpa di episode 20!