Penambahan Kapasitas Storage — Disk image_hdd untuk File Upload User¶

1. Latar Belakang¶

Kapasitas Longhorn di 3 storage node (10.0.0.7–10.0.0.9, disk vdb 120GB/node) sudah cukup terpakai oleh PVC Galera + Postgres (lihat Instalasi Monitoring §3 — sempat harus menurunkan threshold storage-minimal-available-percentage dari 25%→10% karena hal ini). Untuk kebutuhan penyimpanan file yang diupload user lewat aplikasi di oneKE, dibutuhkan kapasitas terpisah agar tidak ikut menekan disk yang sudah padat tersebut.

Keputusan: tambah disk baru per storage node dari datastore OpenNebula image_hdd (ID 101), lalu daftarkan ke Longhorn sebagai disk terpisah dengan tag khusus — supaya StorageClass baru untuk upload file bisa memilih hanya disk ini, tidak berebut I/O/kapasitas dengan disk database.

2. Sisi OpenNebula (dilakukan Admin via Sunstone)¶

Image DATABLOCK baru dibuat dari datastore image_hdd (101), ukuran 512GB, di-attach ke ketiga VM storage node oneKE. Setelah attach, disk baru langsung terlihat di guest OS tanpa reboot (hot-attach, virtio-blk) sebagai /dev/vdc di masing-masing node:

NAME    SIZE  TYPE MOUNTPOINTS
vda     50G   disk
vdb     120G  disk /var/lib/longhorn
vdc     512G  disk                     ← disk baru dari image_hdd (101)

3. Format & Mount (Guest OS)¶

Diverifikasi dulu bahwa vdc benar-benar kosong (blkid exit code 2 = tidak ada filesystem/ signature) sebelum diformat — mencegah menimpa data yang tidak sengaja masih ada:

mkfs.ext4 -L longhorn-uploads /dev/vdc
mkdir -p /var/lib/longhorn-uploads
echo "UUID=<uuid> /var/lib/longhorn-uploads ext4 defaults,nofail 0 2" >> /etc/fstab
mount /var/lib/longhorn-uploads

Dilakukan di ketiga node (10.0.0.7, 10.0.0.8, 10.0.0.9) — hasil masing-masing 503GB tersedia (~478GB free setelah overhead filesystem). Entry /etc/fstab memastikan mount tetap ada setelah reboot (opsi nofail supaya boot tidak gagal bila suatu saat disk tidak terdeteksi).

4. Daftarkan sebagai Disk Baru di Longhorn¶

kubectl patch nodes.longhorn.io <node-name> -n longhorn-system --type=merge -p '
spec:
  disks:
    uploads-disk:
      path: /var/lib/longhorn-uploads/
      allowScheduling: true
      storageReserved: 0
      tags: [uploads]
      diskType: filesystem
'

Hasil: disk uploads-disk di ketiga node berstatus Ready dan Schedulable, dengan tag uploads yang jadi kunci pemisah dari disk database.

5. StorageClass Baru — longhorn-uploads¶

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-uploads
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "30"
  diskSelector: uploads     # kunci isolasi: hanya disk bertag "uploads" yang dipakai
  fsType: ext4

Item	Keputusan	Alasan
Replika	3×	Beda dari Galera/Postgres (yang sudah replikasi sendiri di level aplikasi), file upload user tidak punya redundansi lain — replikasi penuh di level Longhorn perlu
reclaimPolicy	Retain	File user tidak boleh hilang otomatis walau PVC/Deployment aplikasi terhapus tidak sengaja
diskSelector: uploads	—	Memaksa scheduler Longhorn memilih hanya disk yang ditag uploads, tidak menyentuh disk default (dipakai Galera/Postgres)

6. Uji Isolasi Disk ✅¶

PVC uji coba dibuat dengan storageClassName: longhorn-uploads, lalu diperiksa lokasi fisik replikanya:

kubectl get replicas.longhorn.io -n longhorn-system -l longhornvolume=<vol> \
  -o custom-columns='NAME:.metadata.name,NODE:.spec.nodeID,DISKPATH:.spec.diskPath'

Hasil: ketiga replika (satu per node) benar-benar terjadwal ke /var/lib/longhorn-uploads/ — bukan /var/lib/longhorn/ (disk lama) — mengonfirmasi diskSelector bekerja sesuai rencana. PVC uji dihapus setelah verifikasi.

7. Cara Pakai untuk Aplikasi¶

Aplikasi yang menangani upload file user tinggal membuat PVC dengan StorageClass ini:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-uploads
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: longhorn-uploads
  resources:
    requests:
      storage: 20Gi   # sesuaikan kebutuhan

lalu di-mount ke direktori upload di pod aplikasi seperti PVC biasa.

Ringkasan Eksekusi¶

Langkah	Status
Disk image_hdd (101) 512GB di-attach ke 3 storage node (OpenNebula)	✅ (dilakukan Admin)
Format ext4 + mount /var/lib/longhorn-uploads/ + entry fstab	✅ 3/3 node
Registrasi disk baru ke Longhorn dengan tag uploads	✅ 3/3 node, Ready & Schedulable
StorageClass longhorn-uploads (diskSelector, replika 3×, Retain)	✅
Uji isolasi disk (replika benar-benar di disk baru, bukan disk DB)	✅ Lulus

Update 17 Juli 2026 — Node ke-4 (storage_3)¶

Langkah yang dijalankan di 10.0.0.17, identik dengan §3–§4 di atas:

mkfs.ext4 -L longhorn-uploads /dev/vdc
mkdir -p /var/lib/longhorn-uploads
echo "UUID=<uuid> /var/lib/longhorn-uploads ext4 defaults,nofail 0 2" >> /etc/fstab
mount /var/lib/longhorn-uploads

kubectl patch nodes.longhorn.io oneke-ip-10-0-0-17 -n longhorn-system --type=merge -p '
spec:
  disks:
    uploads-disk:
      path: /var/lib/longhorn-uploads/
      allowScheduling: true
      storageReserved: 0
      tags: [uploads]
      diskType: filesystem
'

Hasil: 503GB tersedia, status Ready dan Schedulable, otomatis tercakup StorageClass longhorn-uploads yang sudah ada (diskSelector: uploads) — tidak perlu StorageClass baru maupun perubahan pada aplikasi yang sudah memakainya.

Langkah	Status
Format ext4 + mount /var/lib/longhorn-uploads/ + entry fstab (node ke-4)	✅
Registrasi disk baru ke Longhorn dengan tag uploads (node ke-4)	✅ Ready & Schedulable
StorageClass longhorn-uploads	✅ Tidak berubah, otomatis mencakup node baru

---

Diimplementasikan 9 Juli 2026, diperluas ke node ke-4 pada 17 Juli 2026. Lihat Instalasi Monitoring untuk konteks tekanan kapasitas Longhorn yang mendorong penambahan disk ini.