Belajar Kubernetes Block Storage RWO - Cost, Sizing & Trade-Off
Menghitung biaya nyata Longhorn: lisensi gratis tapi butuh disk dedicated, overhead CPU/memori dan network untuk replikasi, rasio 3 replica terhadap kapasitas usable, serta panduan kapan menggunakan Longhorn dan kapan memilih alternatif seperti Rook-Ceph atau managed block storage.
#Pendahuluan
Setelah 25 episode membangun, mengamankan, dan mem-backup Longhorn, episode 26 bertanya hal yang sering dihindari: berapa biaya sebenarnya, dan kapan Longhorn bukan jawaban? Keputusan arsitektur storage adalah keputusan anggaran jangka panjang.
Mengapa penting? "Gratis" (open source) tidak berarti "tanpa biaya". Ada biaya hardware, overhead resources, dan biaya operasional. Memahami trade-off membuat kalian memilih storage yang tepat — bukan sekadar yang populer.
#Biaya Longhorn
#Gratis (Open Source)
- Lisensi Apache 2.0 — tidak ada biaya lisensi.
- Berjalan di atas Kubernetes yang sudah ada.
#Biaya Tidak Langsung yang Nyata
| Item | Keterangan |
|---|---|
| Disks dedicated | Setiap node butuh disk untuk replica — tidak bisa berbagi rootfs |
| CPU/Memori | Engine + replica consumption; 3 replica = 3 proses engine aktif |
| Network | Replikasi sinkron mengonsumsi bandwidth antar node |
| Monitoring | Server Prometheus/Grafana/Loki tambahan |
| Operasional | Upgrade, backup, DR test, on-call |
Perkiraan kasar resource di lab: tiap volume aktif memakai ~0.5–1 vCPU + ratusan MB RAM untuk engine/replica. Untuk 10 volume database, itu signifikan.
#Replikasi & Kapasitas
#Rasio 3 Replica = 3× Ruang Disk
Ini persamaan mental yang harus selalu diingat:
usable = raw / number_of_replicas- 1 TB data + 3 replica → 3 TB disk fisik terpakai.
- 2 replica → 2×.
- Dengan dataLocality
best-effort, sedikit penghematan, tapi prinsipnya sama.
Dengan begitu, sizing disk harus menghitung pertumbuhan: 500 GB data aktual → harus menyediakan 1.5 TB disk (3 replica).
#Data Locality & Bandwidth
best-effort: mencopot replika lokal saat read — mengurangi penggunaan bandwidth jaringan.strict-local: tidak ada replikasi cross-node → hemat bandwidth, tapi HA hilang.disabled: Longhorn bebas menempatkan — paling efisien scheduling, tapi latency bisa bervariasi.
Pilihan ini adalah trade-off tidak bisa 3-in-1: HA, latency rendah, dan disk hemat. Pilih prioritas.
#Kapan Pakai Longhorn, Kapan Tidak
#Ideal untuk Longhorn
- Database standalone (PostgreSQL/MySQL) yang butuh RWO + replikasi.
- Self-hosted cluster di bare-metal/VM — kalian juga mengelola Kubernetes.
- RWO workload dengan budget disk 3×.
- Butuh backup bawaan terintegrasi (S3/NFS).
#Pertimbangkan Alternatif
| Situasi | Alternatif |
|---|---|
| Perlu block + file + object satu kesatuan | Rook-Ceph |
| Perlu object/file multitenancy & scale besar | Rook-Ceph |
| Kinerja ekstrem (high IOPS/latency 0) | Managed block (EBS/PD), atau Longhorn V2 NVMe |
| RWX sederhana | NFS / CephFS / OpenEBS-NFS |
| Lab hemat resource, single-node | OpenEBS Local / hostPath |
| RWO butuh managed expertise | Cloud-managed block |
#Ringkasan Keputusan
Rebutan keputusan cepat:
- RWO DB → Longhorn (dengan asumsi Kubernetes self-managed dan butuh replikasi).
- RWX files → NFS / CephFS untuk berbagi file (media, session).
- Mega workload agnostic → Rook-Ceph (block+file+object, scale besar).
Note
Jangan memilih storage hanya dari nama besar. Hitung tiga angka: biaya disk per ream, biaya resources, dan biaya operasional upkeep. Longhorn menang di dua pertama; Rook-Ceph menang jika memang butuh banyak protokol tapi dengan biaya resource yang lebih tinggi.
#Penutup
Inti yang harus dibawa pulang:
- Longhorn gratis lisensi tapi mahal disk (3×) + resource engine/replica + bandwidth replikasi.
- Usable = raw / replica; selalu hitung growth sejak awal.
- Longhorn ideal untuk DB RWO; pertimbangkan Ceph untuk multi-protokol, managed block untuk kinerja ekstrem.
- Gunakan kerangka keputusan: RWO → Longhorn; RWX → NFS/CephFS; mega-agnostic → Rook-Ceph.
Di episode 27 (final) selanjutnya kita akan merangkum seluruh series dalam studi kasus & refleksi — recap arsitektur 5-node, simulasi crash node, ekspansi disk, backup & restore penuh, sesi problem solving, serta langkah lanjutan setelah series ini. Sampai jumpa di episode final!