Belajar Kubernetes Distributed Storage - Mengapa Distributed Storage untuk Serious Infrastructure

#Pendahuluan

Di episode 0 kita menyiapkan cluster dan disk mentah. Episode 1 menjawab pertanyaan fundamental: kenapa harus distributed storage? Kalau Longhorn RWO (seri sebelumnya) sudah bagus untuk database, mengapa kita membutuhkan sesuatu yang lebih besar?

Mengapa penting? Karena perbedaan antara "aplikasi jalan" dan "infrastruktur serius" adalah keputusan arsitektur storage. Distributed storage menentukan bagaimana data disimpan, direplikasi, digagalkan, dan di-scale ketika organisasi tumbuh. Memahami alasannya membantu kalian memilih solusi yang tepat — bukan sekadar yang populer.

#Masalah Storage Tradisional di Kubernetes

#NFS Single-Server: SPOF & Tidak Self-Healing

NFS klasik (single server) sederhana dan familiar, tetapi:

Single point of failure: server NFS mati = semua volume hilang.
Tidak self-healing: butuh intervensi manual untuk mengganti server.
Skalabilitas terbatas: satu server ≠ kapasitas petabyte.
Latency dan lock management menjadi bottleneck pada banyak client.

#Local Disk (hostPath): Terbatas Satu Node, Tidak HA

Me-mount direktori node langsung (hostPath) memberi performa penuh, tetapi:

Data terkunci pada satu node.
Pod yang pindah node kehilangan data.
Tidak ada replikasi, tidak ada migrasi.

#Cloud-Managed: Mahal dan Terikat Vendor

Managed block/object dari cloud (EBS, EFS, S3) nyaman, tapi:

Biaya per-GiB + IOPS bisa meledak.
Terikat vendor: tidak portabel.
Tidak bisa diperluas di luar zona cloud.

#Apa yang Dibutuhkan "Big/Serious Infrastructure"

Ketika organisasi menjalankan beban kritis — mikroservices, database reproduksi, data pipelines, media streaming — storage harus:

#Self-Healing dan Automatic Replication

Sebuah node mati tidak menjatuhkan data — salinan otomatis diambil.
Recovery dan rebalance berjalan tanpa human operator.

#Multi-Protocol dalam Satu Platform

Infrastruktur besar butuh tiga tipe storage sekaligus:

Kebutuhan	Protokol
Database	Block (RBD)
File berbagi antar Pod	File (CephFS)
Media besar / S3 client	Object (RGW/S3)

Memiliki semuanya dalam satu cluster menyederhanakan operasional, versioning, dan DR — satu kendali.

#Skalabilitas Hingga Petabyte

Menambah kapasitas = menambah OSD/node.
Tanpa batas arsitektur kaku seperti satu NFS server.

#Monitoring Penuh dan DR

Metrik, alerting, dan dashboard bawaan.
Replikasi dan mirroring lintas cluster untuk disaster recovery.

#Mengapa Ceph + Rook

#Ceph Matang dan Terdistribusi

Ceph adalah proyek open-source dengan lebih dari 10 tahun track record produksi. Ia dirancang sebagai distributed system sejati:

RADOS menyimpan semua data sebagai object di pool.
CRUSH menempatkan data secara deterministik — tanpa metadata terpusat.
Self-healing: recovery otomatis saat OSD hilang.

#Rook Mengorkestrasi Ceph di Kubernetes

Rook adalah operator Kubernetes yang mengelola Ceph:

Membuat dan mengelola MON/OSD/MDS/RGW sebagai CRDs.
Merekonngurasi daemon sesuai desired state.
Menyediakan driver CSI (RBD & CephFS) ke Kubernetes.

Ini berarti kalian tidak mengelola Ceph manual — Rook yang menangani penyebaran, upgrade, dan health.

#Satu CephCluster = Tiga Access Mode

Dengan satu deployment, Ceph menyediakan:

text

Block  → CephBlockPool (RBD)       → RWO untuk database
File   → CephFilesystem (CephFS)   → RWX untuk berbagi file
Object → CephObjectStore (RGW)     → S3-compatible untuk bucket

Ini berbeda dengan Longhorn yang fokus block, atau NFS murni file.

#Posisi Rook-Ceph vs Lainnya

Solusi	Fitur	Resource	Best For
Rook-Ceph	Block + File + Object, paling lengkap	Resource-hungry	"Serious infra", multi-protocol, petabyte
Longhorn	Simple replicated block	Ringan	RWO database di cluster self-hosted
OpenEBS	Local + replicated block	Lab-friendly	Lab murah, workload ringan

#Kapan Memilih

Butuh "agnostic storage output" (semua protokol) → Rook-Ceph.
Hanya perlu RWO database sederhana → Longhorn.
Lab murah / POC cepat → OpenEBS.

Note

Rook-Ceph bukan "Longhorn yang lebih besar". Ia adalah platform storage mandiri dengan cost operasional tinggi — cocok ketika organisasi memang membutuhkan tiga protokol dalam satu kesatuan. Jangan memilihnya hanya karena ingin "efek mewah".

#Penutup

Inti yang harus dibawa pulang:

NFS single-server, hostPath, dan cloud-managed punya batas arsitektur untuk infrastruktur serius.
Serious infra butuh self-healing, multi-protocol, skala petabyte, monitoring, dan DR.
Ceph matang & terdistribusi; Rook mengorkestrasinya di Kubernetes.
Satu CephCluster menyediakan RBD (block), CephFS (file), dan RGW (object).
Rook-Ceph = terlengkap tapi resource-hungry; Longhorn/OpenEBS untuk kasus lebih ringan.

Di episode 2 selanjutnya kita akan membedah arsitektur Ceph & Rook operator — komponen MON/OSD/MGR/MDS/RGW, fondasi RADOS, algoritma CRUSH, dan cara kerja operator lewat CRDs. Sampai jumpa di episode 2!