Hari ini saya sedang oprek tentang lvm thin dan menempatkan /opt pada disk terpisah sebelum instalasi Carbonio. Untuk itu, disk tambahan 30 GB (/dev/xvdb) saya gunakan sebagai LVM thin pool, lalu saya buat thin volume bernama opt. Volume tersebut diformat dengan ext4 dan di-mount ke /opt. Jadi, filesystem dibuat di atas thin volume. Disk OS tetap berada di /dev/xvda.
Sebelum mulai, pastikan /dev/xvdb benar-benar disk kosong dan /opt belum berisi aplikasi. Perintah pvcreate dapat merusak data jika dijalankan pada disk atau volume yang tidak sesuai.
1. Periksa disk dan direktori /opt
lsblk -f
findmnt --mountpoint /opt
ls -la /opt
Pastikan /dev/xvdb adalah disk tambahan yang kosong dan /opt belum berisi aplikasi. Jangan lanjut jika ada data yang perlu dipertahankan.
Disk 30 GB tersebut sekarang memiliki volume group vgthin dengan thin pool 24 GB.
3. Buat thin volume untuk /opt
lvcreate -V 24G -T vgthin/pool -n opt
Ukuran virtual volume opt adalah 24 GB, sama dengan ukuran pool. Jadi, contoh ini memakai LVM thin, tetapi belum mengalokasikan ukuran virtual melebihi pool.
Sebelumnya saya pernah mencoba overprovisioning vCPU dan memori pada Apache CloudStack. Kali ini saya mencoba pengaturan serupa namun untuk storage, dengan mengubah storage.overprovisioning.factor pada halaman setting di Primary Storage.
Apa itu storage overprovisioning?
Saat membuat VM, kita bisa menentukan virtual disk sebesar 50 GB, sementara data yang benar-benar ditulis ke disk tersebut baru 5 GB. Storage overprovisioning memanfaatkan selisih antara ukuran disk yang dialokasikan dan ruang fisik yang terpakai.
Pada storage yang mendukung fitur ini, CloudStack memakai faktor overprovisioning untuk menghitung kapasitas alokasi. Misalnya, pool fisik 100 GB dengan faktor 10 dapat dihitung memiliki kapasitas alokasi sekitar 1.000 GB. Disk fisiknya tetap 100 GB.docs.cloudstack.apache.org
Yang dilihat
Contoh dengan faktor 10
Kapasitas fisik
100 GB
Kapasitas dalam perhitungan alokasi
Sekitar 1.000 GB
Cara mengubah melalui GUI
Pada percobaan ini, saya membuka pool Filesystem / KVM / Host:
Login sebagai administrator CloudStack.
Buka Infrastructure → Primary Storage, lalu pilih pool.
Masuk ke tab Settings dan cari overprovision.
Ubah Storage overprovisioning factor menjadi 10 (sesuaikan dengan kebutuhan).
Klik centang hijau, lalu refresh untuk memastikan nilainya tersimpan.
Dampak dan Perubahan
Jika jenis storage mendukung, perubahan ini menaikkan batas kapasitas yang dipakai CloudStack untuk menghitung alokasi virtual disk. Ukuran disk VM yang sudah ada tidak otomatis bertambah. Kapasitas fisik host juga tidak berubah.
Untuk mengeceknya, bandingkan angka Allocated dan Used pada Primary Storage.
Sebelum
Sesudah
Catatan: dokumentasi CloudStack 4.23 mencantumkan storage overprovisioning KVM untuk NFS saja, sedangkan pool pada untuk local Filesystem perlu dibandingkan sebelum dan sesudah perubahan, lalu diuji dengan deployment VM. docs.cloudstack.apache.org
Saat mencari bahan bacaan seputar Proxmox, saya menemukan halaman Mr.PlanB yang membahas berbagai teknologi storage. Dari sana, saya menyadari bahwa memilih storage sebaiknya tidak dimulai dari pertanyaan “Teknologi mana yang paling bagus?”, tetapi dari “Storage ini akan digunakan untuk kebutuhan apa?”
Proxmox VE mendukung storage lokal maupun shared storage. VM dan container dapat ditempatkan pada directory, LVM-thin, ZFS, NFS, iSCSI, hingga Ceph. Banyaknya pilihan tersebut bukan berarti kita harus menggunakan semuanya. Kita cukup memilih arsitektur yang sesuai dengan jumlah node, workload, performa, dan kebutuhan ketersediaan layanan.
Mulai dari kebutuhan
Pada fitur storage picker milik Mr.PlanB, pemilihan storage dimulai dari tiga pertanyaan:
Berapa jumlah node yang digunakan?
Apa platform utamanya?
Apa prioritas utama storage tersebut?
Prioritasnya dibagi menjadi integritas data, kemudahan penggunaan, scalability dan high availability, serta backup dan archive. Kebutuhan performa, kapasitas, dan redundancy juga tetap menjadi pertimbangan.
Untuk lingkungan Proxmox, variabel tersebut dapat disederhanakan menjadi:
Pertimbangan
Variabel
Jumlah node
Single node, cluster kecil, atau cluster besar.
Jenis workload
VM pengujian, file server, database, atau layanan production.
Availability
Layanan harus tetap berjalan saat node gagal.
Performa
Apakah workload membutuhkan IOPS atau throughput tinggi.
Pengelolaan
Seberapa kompleks storage yang mampu kita rawat.
Backup
Bagaimana data dipulihkan ketika VM terhapus atau rusak.
1. Storage lokal untuk single node
Untuk Proxmox single node, storage lokal biasanya sudah mencukupi.
Pilihan yang dapat digunakan antara lain:
Directory untuk ISO, template, backup, dan disk VM
LVM-thin untuk disk VM dan container
ZFS untuk snapshot, compression, checksum, dan integritas data
Directory dan LVM-thin cocok untuk memulai homelab karena konfigurasinya sederhana. Sementara itu, ZFS menarik ketika kita ingin mempelajari pengelolaan pool, snapshot, compression, serta perlindungan data berbasis checksum.
Mr.PlanB menempatkan ZFS sebagai pilihan yang kuat untuk integritas data dan menyebutnya sebagai fondasi yang banyak digunakan pada homelab Proxmox maupun TrueNAS.
Contoh penggunaan:
Satu server Proxmox untuk belajar
Beberapa VM dan container internal
Media server atau server pengujian
Workload yang tidak membutuhkan failover otomatis
2. Cluster kecil: storage lokal atau shared NAS
Ketika menggunakan dua atau tiga node Proxmox, kita memiliki beberapa pilihan.
ZFS Replication
Setiap node menggunakan storage ZFS lokal, kemudian disk VM direplikasi ke node lain berdasarkan jadwal.
Kelebihannya:
Arsitektur lebih sederhana
Tidak membutuhkan shared storage
Cocok untuk cluster kecil
Mengurangi waktu migrasi karena salinan disk sudah tersedia pada node tujuan
Namun, replication berjalan secara asynchronous. Jika node gagal sebelum proses replication berikutnya selesai, perubahan terbaru masih mungkin hilang.
NFS atau iSCSI
Kita juga dapat menggunakan NAS atau SAN sebagai shared storage:
NFS menyediakan file storage melalui jaringan dan relatif mudah dikelola.
iSCSI menyediakan block storage melalui jaringan dan umum digunakan untuk virtualisasi.
Shared storage memungkinkan beberapa node mengakses storage yang sama. Namun, server NAS, SAN, dan jaringan storage harus dirancang dengan baik agar tidak menjadi titik kegagalan tunggal. Proxmox secara resmi mendukung VM pada shared storage seperti NFS dan iSCSI.
Contoh penggunaan:
Homelab tiga node dengan NAS terpisah
Cluster kantor kecil
Infrastruktur yang sudah memiliki NAS atau SAN
3. Scale dan High Availability dengan Ceph
Untuk cluster production dengan beberapa node, kebutuhan storage biasanya tidak lagi hanya soal kapasitas. Storage juga harus tetap tersedia ketika disk atau node mengalami kegagalan.
Di sinilah Ceph dapat dipertimbangkan.
Ceph merupakan distributed storage yang menyediakan block, object, dan file storage. Data didistribusikan ke beberapa node sehingga storage dapat berkembang secara horizontal dan melakukan pemulihan ketika terjadi kegagalan.
Pada Proxmox, Ceph cocok ketika kita membutuhkan:
Shared storage terdistribusi
High availability
Live migration yang cepat
Penambahan kapasitas melalui node baru
Tidak bergantung pada satu server NAS
Namun, Ceph membutuhkan lebih banyak node, disk, jaringan cepat, monitoring, dan kemampuan troubleshooting. Untuk homelab kecil, ZFS Replication sering lebih mudah dirawat. Artikel komunitas Mr.PlanB menggambarkan ZFS sebagai pilihan praktis untuk cluster kecil, sedangkan Ceph lebih sesuai ketika kebutuhan scale dan HA memang sebanding dengan kompleksitasnya.
4. Backup tetap menggunakan PBS
Apa pun storage utama yang dipilih, kita tetap membutuhkan backup.
Untuk Proxmox, pilihan yang paling sesuai adalah Proxmox Backup Server karena terintegrasi langsung dengan Proxmox VE dan mendukung backup VM, container, serta physical host.
PBS menyediakan:
Incremental backup
Deduplication
Compression
Verifikasi integritas
Client-side encryption
Sinkronisasi datastore ke lokasi lain
Backup dikirim secara incremental dan dideduplicasi pada server sehingga penggunaan storage dan jaringan dapat ditekan.
Replication, RAID, ZFS, dan Ceph tidak menggantikan backup. Data yang terhapus, rusak, atau terkena kesalahan konfigurasi tetap memerlukan recovery point yang terpisah.
Rangkuman pilihan untuk Proxmox
Skenario
Pilihan awal
Homelab single node
Directory, LVM-thin, atau ZFS
Homelab dengan fokus integritas data
ZFS
Cluster kecil 2–3 node
ZFS Replication atau shared NFS
Sudah memiliki NAS/SAN
NFS atau iSCSI
Production multi-node dengan HA
Ceph
Backup VM dan container
Proxmox Backup Server
Backup di lokasi lain
PBS Remote dan Sync Job
Platform lain tentu memiliki pendekatan berbeda. Kubernetes, misalnya, dapat menggunakan Longhorn atau Rook-Ceph, sedangkan bare metal dan NAS dapat menggunakan ZFS, Unraid, NFS, atau iSCSI. Namun, untuk lingkungan Proxmox, pilihan umumnya tetap berputar pada storage lokal, shared storage, distributed storage, dan backup terpisah.
Kesimpulan
Tidak ada satu storage yang terbaik untuk semua kondisi.
Untuk homelab, pilihan sederhana seperti LVM-thin, ZFS, NFS, atau ZFS Replication sering sudah mencukupi. Pada skala production, kebutuhan shared storage, high availability, performa, redundancy, dan kemampuan recovery menjadi lebih penting sehingga NFS, iSCSI, atau Ceph dapat dipertimbangkan.
Menurut saya, storage terbaik bukan storage dengan teknologi paling rumit, tetapi storage yang sesuai dengan workload dan masih dapat kita kelola dengan baik.
Mulailah dari kebutuhan, ukur kemampuan hardware dan jaringan, kemudian pastikan seluruh VM dan container tetap memiliki backup terpisah di Proxmox Backup Server.
Minggu lalu saya ikut training Proxmox yang berlangsung Sabtu dan Minggu. Salah satu materinya membahas storage tipe ZFS. Di sela sesi saya lupa mencentang opsi Thin Provision saat membuat storage ZFS. Hasilnya, penggunaan disk cepat mencapai 100 persen dan VM langsung kena I/O error. Tulisan ini saya buat supaya kejadian ini tidak terulang, sekaligus jadi catatan untuk kalian yang baru belajar Proxmox.
Apa itu Thin Provision
Thin provision adalah metode alokasi storage di mana ruang disk hanya dipakai sesuai data yang benar benar ditulis, bukan sesuai ukuran disk yang didefinisikan di awal.
Di ZFS, istilah resminya adalah sparse volume. Menurut dokumentasi resmi Proxmox, sparse volume adalah volume yang reservation nya tidak sama dengan ukuran volume itu sendiri.
Gambarannya seperti ini:
Mode
Ukuran disk virtual
Ruang yang langsung dikunci di pool
Thin (sparse)
100 GB
Sesuai data terpakai, misal 10 GB
Thick (non sparse)
100 GB
100 GB langsung dikunci dari pool
Kenapa Lupa Centang Bikin I/O Error
Kalau opsi Thin Provision tidak dicentang, Proxmox membuat zvol dengan refreservation penuh. Artinya seluruh ukuran disk yang didefinisikan langsung dikunci dari pool ZFS sejak awal, walau isinya masih kosong.
Kejadian saya waktu training kira kira begini:
Storage ZFS dibuat dengan ukuran pool yang terbatas.
Beberapa disk VM dibuat dengan ukuran cukup besar.
Karena Thin Provision tidak aktif, seluruh ukuran disk langsung teralokasi penuh di pool.
Pool ZFS cepat penuh walau data yang benar benar ditulis jauh lebih kecil.
Begitu pool mencapai 100 persen, VM langsung I/O error karena tidak ada ruang kosong untuk menulis data baru.
Hal ini juga dikonfirmasi di forum resmi Proxmox. Salah satu pengguna menjelaskan kalau opsi thin dicentang saat membuat storage, virtual disk akan benar benar thin provisioned dan ruang yang belum terpakai tidak akan memakan kapasitas pool.
Cara Mengaktifkan Thin Provision
Saat membuat storage baru
Buka Datacenter > Storage > Add > ZFS.
Isi ID dan pilih ZFS Pool yang dipakai.
Centang opsi Thin provision.
Klik OK.
Posisinya seperti di gambar yang saya lampirkan, opsi Thin provision ada di kolom kanan, sejajar dengan Enable dan Block Size.
Mengaktifkan di storage yang sudah ada
Kalau storage sudah dibuat seperti kasus saya, caranya:
Catatan penting, perubahan ini hanya berlaku untuk disk VM yang dibuat setelah opsi diaktifkan. Disk yang sudah ada sebelumnya tetap thick provision. Kalau mau disk lama jadi thin juga, ada dua cara:
Pindahkan disk ke storage lain lalu kembalikan lagi ke storage ZFS yang sama, proses ini akan membuat ulang zvol.
Set manual lewat CLI dengan zfs set refreservation=none nama-pool/nama-zvol.
Lewat file konfigurasi
Opsi ini juga bisa diatur langsung di /etc/pve/storage.cfg dengan menambahkan baris sparse:
zfspool: nama-storage
pool nama-pool
content images,rootdir
sparse
Yang Perlu Diperhatikan
Thin provision butuh dukungan discard atau TRIM yang jalan penuh, dari sistem di dalam VM, lewat virtio, sampai ke pool ZFS. Kalau salah satu putus, ruang yang sudah dihapus di VM tidak akan balik kosong di pool.
Pakai controller Virtio SCSI single dan aktifkan opsi Discard di hardware disk VM.
Pantau penggunaan pool secara rutin dengan zfs list atau dari menu Datacenter > Storage, supaya tidak kejadian pool penuh tanpa disadari, sekalipun sudah thin provision.
Penutup
Satu centang kecil ternyata berdampak besar ke operasional. Sejak kejadian ini saya selalu cek ulang opsi Thin provision setiap kali membuat storage ZFS baru, baik di homelab maupun di environment client.
Referensi
Dokumentasi resmi Proxmox, Storage ZFS: https://pve.proxmox.com/wiki/Storage:_ZFS
Forum Proxmox, How to enable thin provisioning on ZFS: https://forum.proxmox.com/threads/how-to-enable-thin-provisioning-on-zfs.92801/
Forum Proxmox, Thin Provision after the fact: https://forum.proxmox.com/threads/thin-provision-after-the-fact.132568/
Pertanyaan ini sering muncul dari teman-teman yang baru mulai dan mendalami Ceph. Jawabannya ada dua tingkatan: minimal supaya bisa jalan untuk uji coba, dan minimal yang dianjurkan untuk cluster yang benar-benar dipakai.
OSD (Object Storage Daemon) adalah proses yang menyimpan objek data Ceph lewat jaringan. Aturan dasarnya, satu OSD untuk satu disk.
Jawaban singkat
Kondisi
OSD
Keterangan
Tingkat lab atau uji coba
1 OSD
Bisa jalan, misalnya di laptop pakai VirtualBox atau di Raspberry Pi. Bukan untuk produksi.
Best Practice Proxmox VE Ceph
12 OSD
Minimal 3 node, masing-masing minimal 4 OSD (3 x 4 = 12 disk).
Jadi untuk cluster production, patokannya 3 node dengan total 12 OSD. Angka 1 OSD hanya untuk lab.
Kenapa minimal 3 node/cluster
Default replikasi pool Ceph di Proxmox VE adalah 3, artinya setiap objek disimpan tiga kali dengan satu salinan per host. Supaya tiga salinan itu bisa diletakkan di host yang berbeda, jumlah node minimalnya tiga.
Dokumentasi Ceph juga menyarankan node yang lebih banyak dan lebih kecil supaya blast radius atau cakupan dampak kegagalan lebih kecil. Alasannya, kalau satu node memegang porsi kapasitas yang besar lalu mati, proses recovery bisa mendorong OSD lain melewati batas penuh (full ratio), dan Ceph akan berhenti menulis untuk mencegah kehilangan data.
Kenapa minimal 4 OSD per node
Paralelisme. Makin banyak OSD, makin tinggi pemrosesan paralel dan distribusi beban. Operasi baca tulis tersebar ke banyak disk.
Hindari bottleneck. Kalau OSD terlalu sedikit, beban menumpuk di sedikit disk dan jadi titik macet sehingga performanya jelek.
Jangan berlebihan juga. Terlalu banyak OSD menaikkan kebutuhan bandwidth jaringan dan resource CPU/RAM. Intinya cari keseimbangan.
Aturan dasar tiap OSD
Satu OSD untuk satu disk. Menaruh banyak OSD di satu HDD SATA/SAS bukan ide bagus. Satu disk satu OSD, kecuali mungkin SSD berkapasitas di atas 30 TB.
Minimal ukuran disk 1 TiB. Disk yang jauh lebih kecil habis sebagian besar kapasitasnya untuk metadata, dan disk di bawah 100 GiB praktis tidak berguna.
Pisahkan dari OS dan layanan lain. Jangan satukan disk OS dengan disk OSD, dan jangan gabungkan data OSD dengan data MON, MGR, atau MDS di disk yang sama.
Hitung resource per OSD. Tiap OSD butuh minimal 4 GB RAM (lebih banyak lebih baik, di bawah 2 GB tidak dianjurkan) ditambah jatah CPU thread. Makin banyak OSD, makin besar kebutuhan CPU dan RAM tiap node.
Soal jaringan
Karena replikasi antar-OSD jalan lewat jaringan, faktor ini ikut menentukan. Sediakan minimal 10 Gbit/s kalau pakai HDD, dan minimal 25 Gbit/s kalau pakai NVMe SSD.
Ringkasnya
Uji coba: cukup 1 OSD.
Cluster nyata di Proxmox VE: minimal 3 node, 4 OSD per node, total 12 OSD.
Alasannya: replikasi default 3 butuh minimal 3 host, dan jumlah OSD yang cukup supaya beban tersebar, tidak jadi bottleneck, dan blast radius tetap kecil.
Patuhi aturan dasar: satu OSD satu disk, minimal 1 TiB, pisah dari OS, dan siapkan RAM serta CPU yang cukup per OSD.
Saya sedang merancang skenario implementasi Proxmox 3 node, dan tulisan ini saya jadikan dasar buat memutuskan mau pakai storage mana. Pemilihan antara Ceph atau ZFS itu bukan tentang fiturnya lebih banyak, tapi soal mode failure mana yang sanggup ditangani waktu ada node yang mati/error.
Skenario
Cluster Proxmox VE 3 node. Proxmox dengan 3 node ini jumlah minimum yang sehat buat quorum sekaligus titik masuk paling pas buat Ceph.
Targetnya storage yang andal buat disk VM, dengan jalur naik ke HA kalau nanti dibutuhkan.
Tiga hal yang harus saya tentukan sendiri sebelum memutuskan: butuh HA atau nggak, network-nya seberapa kencang, dan workload-nya seperti apa.
Pertanyaan kunci
Biasanya cukup jawab satu pertanyaan ini:
Apakah dibutuhkan HA? Maksudnya node mati tapi VM tetap jalan tanpa ada yang sadar.
Kalau ya dan network mendukung: ambil Ceph (RBD).
Kalau failover beberapa menit masih oke dan tinggal restore dari backup: ZFS lokal + replikasi jadi jawaban.
Dua opsi di 3 node
Opsi A: Ceph (RBD)
Cocok jika membutuhkan shared storage dan HA langsung dari Proxmox.
Kelebihan: node mati, disk VM tetap kebaca; cluster nyembuhin diri sendiri; live migration mulus tanpa pindah-pindah disk.
Kekurangan: operasionalnya lebih rumit, dan berkaitan sama network.
Cocok kalau network terbatas, tim kecil, atau memakai model restore-based.
Kelebihan: simpel, latency rendah (apalagi pakai mirror), hardware lebih murah, integritas data juara.
Kelemahan: nggak ada shared storage bawaan; ada jeda data karena replikasi sifatnya async; failover-nya hitungan menit.
Kebutuhan: mirror buat disk VM, replikasi (zfs send/receive) ke node lain, plus Proxmox Backup Server.
Perbandingan cepat
Aspek
Ceph (RBD)
ZFS lokal + replikasi
HA / shared storage bawaan
Ya
Tidak
Saat node mati
VM tetap jalan
Failover atau restore beberapa menit
Network
25GbE ideal, minimal 10GbE terpisah
10GbE cukup, 1GbE pun bisa
Kompleksitas operasional
Tinggi
Rendah
Disk
OSD seragam SSD/NVMe
Mirror SSD/NVMe
Risiko data saat node mati
Minim (size 3)
Ada jeda replikasi
Paling cocok
True HA, banyak VM
Simpel, network terbatas
Keputusan
Buat skenario 3 node ini, kalau memang tujuannya High Availability dan syarat network terpenuhi, saya pilih Ceph (RBD) dengan size 3 dan failure domain per host. Tiga node itu pas banget buat Ceph: tiga MON buat quorum, dan persis satu salinan data per host.
Perintah buat ngecek kondisi
pvesm status: lihat storage apa aja yang kebaca Proxmox dan udah kepakai berapa persen. Jaga Ceph tetap di bawah 75 sampai 80 persen.
zpool status -x: cek kesehatan ZFS. Kalau jawabannya bukan “all pools are healthy”, beresin dulu sebelum lanjut.
ceph -s: lihat health cluster sekilas. HEALTH_WARN dengan slow ops yang nggak ilang-ilang itu udah masuk kategori insiden produksi.
ceph osd perf: cari OSD yang lambat sendirian, soalnya satu OSD aja bisa narik turun latency seluruh cluster.
ceph osd pool ls detail: pastiin size-nya 3, bukan 2.
Beberapa waktu terakhir saya sedang mendalami implementasi storage terdistribusi menggunakan LINSTOR di cluster Proxmox VE. Tujuannya sederhana: membuat storage yang bisa direplikasi antar node (HA) sehingga VM tetap aman walaupun salah satu node mati. Semua setup awal terlihat normal—node sudah terdaftar, storage pool sudah dibuat, dan integrasi ke Proxmox juga sudah masuk.
Namun saat mencoba clone VM ke storage LINSTOR, muncul error autoplace yang cukup membingungkan. Setelah ditelusuri, ternyata akar masalahnya bukan di konfigurasi storage pool atau resource group, melainkan di layer yang lebih dalam: versi DRBD yang tidak selaras antara kernel dan userspace. Di sinilah perjalanan troubleshooting dimulai.
Mengenal DRBD dan LINSTOR
Sebelum masuk ke teknis, kita pahami dulu perannya:
DRBD adalah teknologi replikasi block storage (mirip RAID 1 tapi via network).
LINSTOR adalah orchestrator yang mengatur DRBD secara otomatis di banyak node.
Secara sederhana:
DRBD = mesin replikasi
LINSTOR = otaknya
LINSTOR tidak menyimpan data sendiri, tapi memanfaatkan DRBD untuk membuat disk yang direplikasi antar node.
Masalah yang Terjadi
Saat melakukan pengecekan:
linstor node info
Hasilnya:
Padahal:
drbdadm ada
modprobe drbd berhasil
service linstor jalan normal
Pas dicek lebih dalam:
cat /proc/drbd
Output:
version: 8.4.11 ()
Sementara:
dkms status
Output:
drbd/9.3.2-1, 7.0.0-3-pve, x86_64: installed ()
Intinya
Terjadi mismatch versi DRBD:
Komponen
Versi
Kernel module
DRBD 8 ❌
Userspace
DRBD 9 ✔️
Masalahnya:
LINSTOR hanya support DRBD 9
DRBD 8 dianggap tidak ada
Kenapa Bisa Terjadi?
Kernel Proxmox secara default masih membawa DRBD 8. Saat menjalankan:
modprobe drbd
Yang ter-load bukan DRBD 9 dari DKMS, tapi DRBD 8 bawaan kernel
Akibatnya:
DRBD terlihat “aktif”
tapi tidak usable oleh LINSTOR
Solusi: Selaraskan Versi DRBD
Berikut langkah yang saya lakukan untuk memperbaiki mismatch ini.
Beberapa hal penting yang saya pelajari dari kasus ini:
DRBD harus versi yang sama untuk LINSTOR
modprobe drbd tidak menjamin versi yang digunakan benar
Selalu cek versi dari drbd di /proc/drbd
Kernel module bisa override DKMS jika tidak di-blacklist
LINSTOR sangat bergantung pada layer DRBD yang valid
Kesimpulan
Masalah yang terlihat seperti error konfigurasi LINSTOR ternyata berasal dari layer paling bawah: kernel module DRBD. Ini menunjukkan bahwa dalam implementasi storage terdistribusi, setiap layer harus selaras—mulai dari kernel, userspace, hingga orchestration.
Dengan memastikan DRBD versi 9 aktif di semua node, LINSTOR dapat bekerja optimal dan seluruh fitur seperti replication, HA, dan cloning bisa berjalan dengan lancar.
