Belajar Kubernetes Distributed Storage - Cost, Capacity & Kapan Memilih Rook-Ceph

#Pendahuluan

Teknik sudah lengkap (episode 19-25). Episode 26 menutup sisi teknis dengan memutar kacamata ke arah ekonomi: kapan investasi Rook-Ceph masuk akal, dan bagaimana menghitung kapasitas serta biaya dengan jujur.

Mengapa penting? Storage yang optimal secara teknis tapi salah secara bisnis tetap akan diputus. Rook-Ceph bukan untuk semua skala. Di sini kita menghitung with numbers dan memberi kriteria pengambilan keputusan yang terbuka.

#Raw vs Usable

#Rasio Replikasi & EC

Replicated size 2 → usable = raw / 2.
Replicated size 3 → usable = raw / 3.
EC (k=2, m=1) → usable = 2/3 raw (hemat 33% vs 3×).

Jangan pernah memakai "raw" ketika menghitung kapasitas riil.

#Contoh perhitungan 8 TB cluster (size 3)

text

Raw: 3 node × 8TB = 24 TB
Replicated size 3 : usable = 24/3 = 8 TB
EC 2+1           : usable = 24 × (2/3) = 16 TB

Pilih EC saat data besar & dingin; replicated saat DB.

#Biaya Hardware & Operasional

#Komponen Biaya

Komponen	Catatan
Hardware (disk + server)	Harga disk/TB, NIC 10/25G
CPU/RAM untuk OSD/MON	Ceph bukan "free compute"
Network	Bandwidth cluster 10-25G
Gambar dayavu pemeliharaan	Admin & monitoring & support
Power & rack	TCO fisik

#Rule of Thumb Resource

~1-2 GB RAM per OSD vs state.
CPU untuk EC & osd.

#TCO Comparison (Contoh Skenario)

Bandingkan Rook-Ceph di bare metal vs managed cloud EBS/gp3 (ilustrasi komparatif, harga bervariasi):

Skala	Rook-Ceph (bare)	Cloud managed
2 TB (lab/small)	Murah (reuse node)	Simpel, tak perlu admin
20 TB	Masuk akal (hemat 30-40%)	Fitur siap pakai, harga gedung
200+ TB	Sangat kompetitif (terutama cold/EC)	Mahal bila object besar

Kesimpulan awal: Ceph menarik saat scale >10TB atau saat 3 protokol dalam satu klaster dibutuhkan.

#Kapan Memilih Rook-Ceph

#Kriteria "YES"

Butuh 3 jenis storage (block, file, object) dalam satu arsitektur.
Memiliki bare-metal/k8s on-prem dengan node homogen.
Perlu scaling horizontal/expandable tanpa vendor lock-in.
Bisa berinvestasi assign a storage engineer (pemeliharaan adalah paket).

#Kriteria "HATI-HATI"

Tim kecil tanpa admin storage (ops com).
Skala kecil (di bawah 1-2 TB usable), kebutuhan sederhana.
Kebutuhan strict ultra-low latency (NVMe langsung) — Ceph bukan solusi latency ekstrem.
Manajemen hanya via cloud vendor yang tinggi harga.

#Alternatif Bijak

Kasus	Alternatif yang Lebih Cocok
1-2 TB, simple	NFS sederhana / lokal disk
RWX ringan	Manajer NFS atau Longhorn RWX
Object saja	MinIO standalone
High IOPS low latency	LocalPath / Local PersistentVolume + aplikasi toleran

Ceph unggul di middle-to-large dengan 3-protokol atau skala besar — bukan di tiap kasus.

#Menghitung Sebelum Memutuskan

#Template Minimal

text

Needs:
  - RBD usable 8 TB (2 DB)
  - CephFS usable 5 TB (media)
  - Object 5 TB (arsip, EC)
Multiply overhead:
  - RBD size 3     → raw 24 TB
  - CephFS size 3  → raw 15 TB
  - Object EC 2+1  → raw 7.5 TB
Total raw needed ≈ 47 TB + 10-15% margin ≈ 52 TB
Pick: 7 node × 8 TB (56 TB) + network + RAM

Hasilkan angka konkret → bandingkan dengan vendor/cloud → keputusan bisa lebih tenang.

Note

Overhead bukan hanya replikasi! Reserve 10-15% untuk snapshot, PG overhead, dan buffer. Masukan dalam total raw — kekurangannya bukan sekadar "ops kapasitas membesar" tapi juga "kemungkinan ENOSPC krisis" (episode 25).

#Penutup

Inti yang harus dibawa pulang:

Jangan bicara raw tanpa menyebut rasio → usable selalu dihitung replikasi/EC.
Ceph hebat untuk kebutuhan 3-protokol & skala besar — murah di TCO per TB saat besar.
Kelola biaya operator (RAM, network, admin) — storage bukan tanpa biaya.
Kapan pilih lain: skala kecil, tanpa admin, ultra low latency, tidak butuh 3-protokol.
Hitung total raw = kebutuhan usable × overhead + margin sebelum keputusan.

Di episode 27 (final) selanjutnya kita akan membahas studi kasus & refleksi — satu kasus menyeluruh dari zero sampai production, plus rangkuman perjalanan belajar. Sampai jumpa di episode 27!