Belajar Kubernetes Block Storage RWO - Arsitektur Longhorn & Konsep Replikasi Block
Memahami arsitektur Longhorn: Engine controller, Replica tersebar, Share Manager untuk RWX, dan perbedaan V1 (iSCSI) vs V2 (SPDK/NVMe). Kalian juga akan melihat cara kerja replikasi sinkron yang membuat Longhorn bebas dari single point of failure.
#Pendahuluan
Di episode 1 kita memahami mengapa database butuh block storage. Sekarang saatnya membedah bagaimana Longhorn mewujudkannya — arsitektur internal yang mengubah disk beberapa node menjadi satu pool block volume yang direplikasi.
Pemahaman arsitektur ini penting karena menentukan cara kalian troubleshoot, mengkonfigurasi replica, dan menakar performa. Kalian tidak perlu menghafal setiap komponen, tetapi harus paham aliran data: dari Pod → Engine → Replica, dan apa yang terjadi saat salah satu Replica mati.
#Apa Itu Longhorn
Longhorn adalah cloud-native distributed block storage untuk Kubernetes — proyek CNCF yang awalnya dikembangkan Rancher/SUSE. Intinya: Longhorn memanfaatkan disk pada node kubernetes sebagai pool, lalu menyediakan volume block yang direplikasi secara sinkron ke beberapa node.
Model pengoperasiannya software-defined: semua komponen berjalan sebagai container di dalam cluster. Tidak ada storage appliance fisik.
Setiap volume Longhorn punya satu Engine dan beberapa Replica (biasanya 3).
#Komponen Utama Longhorn
#Engine Controller
Engine adalah proses yang men-decode I/O dari node tempat workload berjalan. Ini "otak" per volume: setiap read/write yang datang dari Pod diproses Engine, lalu diteruskan ke semua Replica secara sinkron. Engine berjalan di node yang sama dengan Pod yang memakai volume.
Perhatikan: Engine tidak menyimpan data — ia hanya router I/O. Jika node tersebut mati, Engine dipindah ke node lain dan diskoneksi dari Replica yang tersisa.
#Replica
Replica adalah salinan penuh block data yang disimpan di node lain, disinkronisasi secara sinkron (synchronous mirror). Konfigurasi umum:
- 3 Replica → tahan 1 node gagal.
- 2 Replica → tahan 1 node gagal (kuorum 2).
- 1 Replica → tidak ada HA (cocok hanya untuk dev).
Replica disebar ke node yang berbeda (anti-affinity) secara default.
#Share Manager
Longhorn menyediakan access mode RWX lewat Share Manager — sebuah Pod yang mem-export volume Longhorn via NFSv4 ke beberapa Pod sekaligus. Meski seri ini fokus RWO, memahami Share Manager penting karena menu RWX di Longhorn sering memakai kolom feature ini.
#longhorn-ui dan Operator
- longhorn-manager (operator): mengelola CRD
Volume,Engine,Replica,Node, dll. - longhorn-driver-deployer: mengelola CSI driver.
- longhorn-ui: dashboard web untuk administrasi volume, node, disk, backup.
#V1 vs V2 Data Engine
Longhorn menawarkan dua data engine yang berbeda secara fundamental:
| Aspek | V1 Data Engine | V2 Data Engine |
|---|---|---|
| Transport | iSCSI (memerlukan open-iscsi) | SPDK / NVMe-oF |
| Performa | Baik | Tinggi, latency rendah |
| Stabilitas | Stable, default | Stabil sejak v1.8+, direkomendasikan untuk produksi tertentu di v1.12 |
| Fitur | Mature, semua fitur | Linked-clone & sharding (experimental) |
| Prasyarat | open-iscsi | Hugepages 2 MB, node dengan kernel modul NVMe |
Pada v1.12, Longhorn mendukung fast clone dan sharding untuk V2 — namun masih experimental. Untuk series ini kita memfokuskan diri pada V1 Data Engine karena paling stabil dan default.
Note
Kapan memilih V2? Jika kalian butuh performa database ekstrem (low-latency, high IOPS) dan node punya hugepages siap. Untuk lab dan produksi umum, V1 jauh lebih simpel karena hanya butuh open-iscsi.
#Cara Kerja Replikasi
#Write Path: Sinkron ke Semua Replica
Ketika PostgreSQL menulis blok:
- Write dikirim ke Engine di node yang sama.
- Engine meneruskan write ke semua Replica sehat secara paralel.
- Setiap Replica melakukan
fsyncdan membalasack. - Engine mengembalikan sukses ke aplikasi setelah quorum tercapai.
Proses ini sinkron: aplikasi tidak dianggap sukses sampai data benar-benar ditulis di cukup banyak Replica. Ini menjamin tidak ada kehilangan data meski satu node mati seketika.
#Rebuild: Self-Healing Tanpa Downtime
Jika satu Replica down atau node mati:
- Longhorn mendeteksi Replica tidak sehat.
- Volume tidak kehilangan data — Replica lain masih punya salinan penuh.
- Longhorn membuat Replica pengganti (di node baru) dan rebuild dengan menyalin delta dari Replica sehat.
- Setelah rebuild selesai, kuorum dan daya tahan kembali normal.
Proses rebuild memakan bandwidth dan CPU, tapi berjalan di background tanpa memutus Pod.
#Tidak Ada Single Point of Failure
Karena Engine bisa dipindah ke node lain dan Replica tersebar, tidak ada satu pun komponen yang jika mati menghilangkan data. Bahkan controller manager Longhorn sendiri bisa restart tanpa mempengaruhi volume yang sudah aktif — ini karena volume path dikendalikan CRD, bukan proses tunggal.
#Ringkasan Praktis untuk Praktisi
- 1 volume = 1 Engine + N Replica. Jumlah Replica menentukan daya tahan dan pemakaian disk (3 Replica = 3× ruang).
- Replica tersebar otomatis via anti-affinity; jangan paksa menaruh semuanya di satu node.
- V1 = iSCSI (sederhana); V2 = SPDK/NVMe (performa; butuh hugepages).
- Write waktu nyata sinkron; read biasanya dari Replica lokal untuk efisiensi.
#Penutup
Inti yang harus dibawa pulang:
- Longhorn = distributed block storage CNCF: disk node diubah jadi pool volume.
- Engine memproses I/O; Replica menyimpan salinan; Share Manager menyediakan RWX via NFSv4.
- Replikasi sinkron dengan quorum — data aman walau satu node mati.
- V1 (iSCSI) stabil & default; V2 (SPDK/NVMe) untuk performa tinggi.
- Tidak ada SPOF: Engine bisa pindah, Replica auto-rebuild.
Di episode 3 selanjutnya kita akan menyiapkan node & prasyarat Longhorn — persyaratan node, instalasi open-iscsi di Debian/Ubuntu dan RHEL, setup disk untuk longhorn, serta verifikasi modul kernel. Siapkan worker node kalian, dan sampai jumpa di episode 3!