Optimasi Storage LVM AlmaLinux: Panduan Lengkap Step-by-Step untuk Production

Jadi gini, kemarin sore itu aku lagi santai bikin kopi, eh dapat notifikasi dari monitoring. Disk usage server production 94%. Padahal dua hari lalu masih 78%. Pikiran pertamaku sih santai aja, paling tinggal tambah disk, beres. Eh, ternyata gak segampang itu, lha.

Ini serunya ngurus storage LVM: masalahnya gak selalu diske-nya kurang. Kadang disk-nya cukup tapi alokasi-nya yang salah, kadang malah kebalikan – space nganggur banyak tapi gak kepake karena LV-nya pas-pasan. Nah, di artikel ini aku mau cerita sambil kasih langkah optimasi storage LVM di AlmaLinux yang tiap minggu aku pakai di kerjaan. Santai aja, gak usah buru-buru, biar paham sampai akar.

Kenapa Storage LVM Server Production Bisa “Panas”?

Masalah yang aku hadapi itu klasik banget, dan mungkin sampeyan juga pernah ngalamin: filesystem penuh padahal masih ada kapasitas yang kebuang. Ini ibarat rumah gede tapi semua barang numpuk di satu kamar – kamar lain kosong, tapi gak bisa dimasukin karena pintunya macet. Di LVM, “pintu yang macet” itu biasanya LV yang alokasi-nya kurang, snapshot yang lupa dihapus, atau log yang membengkak gak ketulungan. Yang paling sering bikin orang panik itu pas df -h udah 100% tapi lvs masih nunjukin free space di VG. Tenang, ini normal kok buat yang baru mulai serius ngerhatiin storage LVM.

Impact-nya gak main-main di production. Filesystem yang penuh bukan cuma bikin service nyangkut, tapi bisa bikin OOM killer mulai garuk-garuk process, web server balik ke error 500, sampe yang paling parah – database corrupt karena gak bisa nulis. Pernah ada satu kasus di client yang website-nya mati total jam 2 siang, pas lagi ramai pengunjung. Ternyata cuma gara-gara /var/log kebanjiran sampe 99% dan service gak bisa nulis apa-apa. Coba bayangin, segede itu dampaknya dari hal yang sebenarnya gampang dicegah. Ngenes, ya.

Common causes-nya biasanya begini, dan tolong dicatat baik-baik: (1) log file yang gak kena logrotate, (2) snapshot LVM yang ditinggal numpuk, (3) LV yang dialokasi pas-pasan tanpa headroom, (4) pattern penggunaan disk yang berubah tanpa diperhatiin, (5) lupa resize filesystem setelah extend disk di panel VPS. Lima hal ini, hampir semua kasus storage yang aku tangani selalu balik ke sini. Serius, gak nyangka kan kalau masalahnya sering keliatan sepele tapi dampaknya gede banget?

Audit Dulu: Kenali Kondisi Storage Sebelum Menyentuh Apa-apa

Sebelum utak-atik, aku selalu biasakan audit dulu. Jangan langsung extend atau hapus. Kenali kondisi fisik dan logik-nya, biar gak salah ambil keputusan. Lima perintah ini jadi rutinitasku:

df -hndf -inlsblknpvsnvgsnlvs

Nih, contoh output yang pernah aku temuin di server client (identitas-nya udah aku sensor ya, biar aman):

Filesystem      Size  Used Avail Use% Mounted onn/dev/mapper/vg01-root  98G   96G  1.4G  99% /n/dev/mapper/vg01-var   20G   19G  900M  96% /varnnVG   #PV #LV #SN Attr   VSize  VFreenvg01   1   2   0  wz--n- 119.24G 0

Nah, dari sini ketauan masalahnya. Filesystem / udah 99%, /var 96%. Tapi VG vg01 VFree-nya 0 – artinya gak ada sisa space sama sekali di volume group. Jadi mau extend juga gak bisa. Ini pola yang sama kayak kasus yang barusan aku ceritain. Root cause-nya bukan cuma “disk penuh”, tapi “volume group-nya juga habis”. Lain kali kalau liat output kayak gini, sampeyan udah bisa nebak langkah berikutnya.

Bandingin sama kasus lain yang pernah kejadian di server sendiri:

VG   #PV #LV #SN Attr   VSize   VFreenvg01   1   2   0  wz--n- 238.47G 137.12G

Nah ini kasus kebalikannya. VFree 137GB, tapi filesystem-nya tetep penuh. Kenapa? Karena LV root-nya cuma dialokasi 98G dari 238G. Jadi space-nya ada, tapi gak kepake. Ini yang paling bikin orang bingung – df penuh, tapi vgs masih nunjukin sisa banyak. Tenang, jawabannya satu: extend LV-nya, bukan beli disk baru. Ibaratnya rumah udah gede, tinggal buka pintu kamar yang kosong. Gak perlu bangun kamar baru.

Step 1: Rapikan Dulu yang Numpuk

Sebelum mutusin mau extend atau apa, bersihin dulu yang numpuk. Kadang setelah dibersihin, kebutuhan space-nya jadi gak segede itu. Yang paling sering bikin gendut di AlmaLinux itu journal journald. Cek dulu seberapa gede:

journalctl --disk-usagendu -sh /var/log/* | sort -rh | head -20

Kalau journald-nya udah ngilehin 2-3GB, vacuum aja:

journalctl --vacuum-size=500M

Ini aman dan gak ngerusak apa-apa – cuma nyisain log yang masih relevan. Habis itu cek juga logrotate-nya jalan apa ngga. Kadang log gede itu karena rotate-nya mati atau interval-nya kekecilan. Kalau mau lebih dalem soal logrotate, aku udah nulis di artikel cara optimasi logrotate biar log gak membengkak – bisa dibaca sambil santai.

Terus, snapshot. Nah ini yang sering dilupain. Snapshot LVM itu kayak safety net, tapi kalau dibiarin numpuk dia makin gede seiring perubahan data. Cek dulu:

lvs -a -o +lv_attr,lv_size,data_percent

Kalau ada snapshot lama yang udah gak kepake, remove aja. Tapi perhatiin dulu, jangan sampai masih ada yang butuh. Habis dihapus, space-nya balik ke VG. Kalau masih butuh snapshot, baca Step 5 di bawah, ada cara yang lebih bersih.

Step 2: Extend LV Kalau VG Masih Punya Sisa

Balik ke kasus kedua tadi: VFree 137GB tapi filesystem penuh. Solusinya extend LV root. Yang penting, ini bisa online, server gak perlu dimatiin. Kuncinya: LVM itu cuma ngatur block device, filesystem-nya perlu di-resize juga. Di AlmaLinux ada dua filesystem yang umum:

• ext4 – resize pake resize2fs, bisa naik dan turun
• xfs – resize pake xfs_growfs, cuman bisa naik

Perhatiin dulu filesystem-nya pake apa:

df -Th /

Kalau xfs:

lvextend -l +100%FREE /dev/vg01/rootnxfs_growfs /

Kalau ext4:

lvextend -l +100%FREE /dev/vg01/rootnresize2fs /dev/vg01/root

Nih, perhatiin output-nya harus mulus gak ada error. Habis itu verifikasi:

df -h /

Nah, ini momen yang enak. Filesystem yang tadi 99% jadi santai lagi. Aku suka liat angka ini kayak liat saldo malam sebelum gajian. Simple banget, tapi dulu pertama kali aku lakuin rasanya seru juga. Oh ya, extend LV yang lagi dipake live service itu memang didesain buat online operation, jadi gak usah khawatir. Tapi tetep, catat waktu maintenance-nya di log ya.

Step 3: VG Habis? Tambah PV Baru

Kalau kasusnya kayak yang pertama tadi (VFree 0), mau extend juga gak bisa. Solusinya: nambah kapasitas fisik dulu. Kalau sampeyan di VPS, resize disk dari panel provider. Kalau dedicated, attach harddisk baru atau expand RAID-nya. Habis itu, bikin PV dari disk yang baru muncul:

lsblk

Misal disk baru muncul sebagai /dev/vdb. Tambahin jadi PV:

pvcreate /dev/vdbnvgextend vg01 /dev/vdb

Cek lagi kondisi VG:

vgs

Nah, sekarang VFree-nya nambah. Lanjut extend LV sama kayak step sebelumnya:

lvextend -l +100%FREE /dev/vg01/rootnxfs_growfs /

Gampang kan? Kayak nambah lemari di rumah – habis lemari barunya masuk, barang yang numpuk bisa dipindahin. Yang penting cek dulu di panel provider-nya disk-nya beneran ke-resize, karena kadang perlu rescan biar kernel-nya liat ukuran baru. Kalau disk-nya gak muncul setelah resize di panel, cobain:

partprobenecho 1 > /sys/class/block/vdb/device/rescan

Itu buat kasus virtio/SCSI tertentu. Gak selalu perlu, tapi gak ada salahnya dicoba.

Step 4: Shrink LV? Hati-Hati Banget Ini

Jadi gini, shrink itu beda cerita sama extend. Kalau extend bisa online, shrink gak bisa main-main. Catatan penting: XFS gak bisa di-shrink sama sekali. Kalau filesystem-nya xfs, ya sudah, pindahin datanya atau bikin LV baru yang lebih kecil, jangan coba-coba. Buat ext4, langkahnya harus urut dan hati-hati. Konsepnya kayak mau ngecilin lemari: barangnya harus dikeluarin dulu semua, baru lemari-nya diukur ulang. Kalau barang masih di dalam, dipastiin bakal hancur.

Langkah amannya kira-kira begini. Pertama, unmount dulu LV-nya (butuh downtime sebentar, jadwalin pas maintenance):

umount /dev/vg01/data

Kedua, cek konsistensi filesystem dulu:

e2fsck -f /dev/vg01/data

Kalau ada error, perbaiki dulu. Jangan pernah shrink filesystem yang masih error. Ketiga, kecilkan filesystem-nya dulu ke ukuran target (misal 20G):

resize2fs /dev/vg01/data 20G

Baru setelah filesystem-nya kecil, LV-nya ikut dikecilkan. Kalau urutannya kebalik (LV dulu, FS belakangan), itu resep bencana. Filesystem bisa korup. Ini penting banget, jangan dilewatin:

lvreduce -L 20G /dev/vg01/data

Habis itu verifikasi, terus mount balik:

e2fsck -f /dev/vg01/datanmount /dev/vg01/data

Terus cek lagi:

df -h /datanvgs

Nah, VFree-nya nambah dan LV-nya sehat. Tapi jujur ya, aku jarang banget shrink di production. Kecuali emang bener-bener butuh, misal mau mindahin space antar filesystem. Kebanyakan kasus lebih gampang di-extend, atau dibersihin, atau di-reprovision. Kalau ada opsi yang lebih aman, ambil yang lebih aman. Itu prinsip yang bikin kerjaan NOC jarang darurat.

Step 5: Snapshot sebagai Safety Net

Snapshot LVM itu fitur yang menurutku underrated banget. Dia kayak time machine – bisa liat kondisi filesystem di titik tertentu tanpa bikin copy full. Cocok banget sebelum update besar atau migrasi, biar kalau ada apa-apa tinggal balik. Bikin snapshot gampang:

lvcreate -L 10G -s -n root-snap /dev/vg01/root

Yang penting diinget: snapshot LVM itu bukan backup. Dia sharing space sama LV aslinya. Kalau LV aslinya berubah banyak, snapshot-nya makin penuh. Kalau snapshot penuh, dia gak otomatis expand (kecuali kamu set threshold) dan bisa bikin LV aslinya error. Jadi disiplin: pake seperlunya, hapus pas selesai:

lvremove /dev/vg01/root-snap

Kalau mau nyegah storage penuh dari awal, pasang monitoring disk. Soal ini aku udah tulis di artikel cara monitoring disk penuh di Linux – dari cron sederhana sampai tool lengkap. Worth it banget dibaca.

Step 6: Verifikasi Akhir

Setelah semua beres, jangan langsung tutup ticket. Verifikasi dulu biar tenang. Ini checklist-ku:

df -hnvgsnlvsnlsblkndmesg | tail -20

Nah, yang terakhir itu jarang dicek orang. Padahal error di kernel (misal metadata LVM bermasalah atau device timeout) sering keliatan di situ. Lima menit cek di sini bisa nyimpen sampeyan dari masalah baru yang muncul besok pagi. Percaya aku, pengalaman ngajarin hal kayak gini. Kalau server-nya sekalian kerasa berat, mampir ke artikel troubleshoot server high load – biasanya satu masalah nyambung ke yang lain.

Tabel Troubleshooting Cepat

Symptom	Kemungkinan Penyebab	Solusi Cepat
df -h 100% tapi VG masih free	LV gak di-extend setelah disk nambah	lvextend lalu resize2fs / xfs_growfs
df -h 100% dan VFree 0	Kapasitas fisik abis	Tambah PV baru, lalu extend LV
Server pelan, I/O naik	Filesystem penuh atau snapshot penuh	Cek vgs/lvs, bersihin log & snapshot
“No space left on device” padahal masih ada free	Inode abis	df -i buat cek, lalu extend LV
Extend udah jalan tapi df tetep sama	Lupa grow filesystem-nya	Jalankan resize2fs / xfs_growfs

FAQ Seputar Optimasi Storage LVM AlmaLinux

Artikel Terkait

• Cara Monitoring Disk Penuh di Linux
• Optimasi Logrotate Biar Log Gak Membengkak
• Troubleshoot Server High Load
• Strategi Backup Pakai Rsync

Oke, kira-kira segitu dulu cerita dan langkah optimasi storage LVM di AlmaLinux dari aku. Kalau sampeyan pernah ngalamin kasus serupa tapi penyelesaiannya beda, mampir di kolom komentar ya – aku juga seneng denger cerita orang, sopo ngerti bisa bantu temen-temen lain. Bookmark juga artikel ini buat referensi nanti, dan jangan lupa artikel-artikel terkait di atas kalau mau lebih dalem. Sip, mugi bermanfaat. Santai aja, storage server kalian pasti aman kalau rutin dirawat. Sampai jumpa di artikel berikutnya!