Membangun Centralized Storage Proxmox Menggunakan ZFS dan NFS

Memanfaatkan HDD Lama untuk Storage Bersama di Homelab

Dalam membangun homelab, menurut saya tidak semua kebutuhan harus diselesaikan dengan membeli perangkat baru. Terkadang, perangkat lama yang masih berfungsi dengan baik bisa dimanfaatkan kembali untuk membangun infrastruktur yang lebih berguna.

Kali ini saya mencoba memanfaatkan sebuah HDD Toshiba berkapasitas 500 GB (465,8 GB terbaca) yang sebelumnya belum digunakan secara maksimal.

Ide awalnya cukup sederhana: saya ingin memiliki satu tempat penyimpanan terpusat yang bisa digunakan oleh beberapa node Proxmox dalam jaringan homelab saya.

Kebetulan saya memiliki dua node Proxmox dengan arsitektur berbeda, yaitu server x86 dan OrangePi3B berbasis ARM64.

Dari situ saya mulai bereksperimen menggunakan ZFS sebagai sistem penyimpanan utama dan NFS sebagai media berbagi storage melalui jaringan.

Target akhirnya adalah agar kedua node Proxmox dapat menggunakan HDD yang sama untuk menyimpan backup, dan sekaligus mencoba menjalankan virtual machine langsung dari NFS.

1. Mengenal Infrastruktur yang Digunakan

Sebelum memulai konfigurasi, berikut perangkat yang saya gunakan dalam eksperimen ini.

Saya menggunakan HDD Toshiba sebagai media penyimpanan utama. Sementara itu, server x86 bertugas mengelola ZFS dan menyediakan storage melalui NFS.

Secara sederhana, arsitekturnya seperti ini:

           Proxmox x86
           20.20.20.25
                |
           Toshiba HDD
             465.8 GB
                |
             ZFS Pool
              backup
                |
          backup/vzdump
                |
         /backup/vzdump
                |
          NFS Server
                |
         Network 20.20.20.0/24
                |
           OrangePi3B
           20.20.20.21
                |
           NFS Client
                |
           backup-nfs
                |
           VM / Backup

2. Membuat ZFS Pool pada HDD

Langkah pertama adalah mempersiapkan HDD pada server x86.

Saya melakukan pengecekan perangkat penyimpanan terlebih dahulu menggunakan perintah:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL

Dari hasil pengecekan, HDD yang akan digunakan terdeteksi sebagai:

/dev/sdd
TOSHIBA MQ01ACF050
465.8 GB

Setelah memastikan bahwa /dev/sdd merupakan HDD yang benar dan tidak ada data penting di dalamnya, saya membersihkan signature filesystem lama:

wipefs -a /dev/sdd

Perhatian: Perintah ini bersifat destruktif. Pastikan perangkat yang dipilih benar karena data dan signature filesystem lama dapat hilang.

Selanjutnya saya membuat ZFS pool dengan nama backup.

zpool create -f -o ashift=12 backup /dev/sdd

Saya menggunakan ashift=12 untuk menyesuaikan alignment dengan sektor 4K.

Setelah pool berhasil dibuat, saya mengaktifkan kompresi LZ4:

zfs set compression=lz4 backup

Kemudian membuat dataset khusus untuk menyimpan file backup Proxmox:

zfs create backup/vzdump

Saya juga mengatur kompresi pada dataset tersebut:

zfs set compression=lz4 backup/vzdump

Untuk memastikan semuanya berjalan dengan baik, saya melakukan pengecekan:

zpool status backup
zfs list

Dataset yang dibuat otomatis tersedia pada direktori:

/backup/vzdump

Dengan demikian, HDD sudah siap digunakan sebagai storage berbasis ZFS.

3. Mengintegrasikan ZFS ke Proxmox

Setelah ZFS pool berhasil dibuat, saya mengintegrasikannya ke Proxmox.

Ada satu hal yang perlu diperhatikan di sini. Karena dataset backup/vzdump akan digunakan untuk menyimpan file backup VZDUMP, saya memilih backend Directory, bukan ZFS.

Alasannya, Directory storage dapat menyimpan file backup seperti .vma.zst dan .tar.zst, sedangkan ZFS storage backend Proxmox digunakan untuk menyediakan volume disk VM dan container.

Konfigurasinya melalui:

Datacenter → Storage → Add → Directory

Pengaturan yang saya gunakan:

Setelah ditambahkan, storage sudah muncul di Proxmox dan dapat digunakan sebagai tujuan backup VM maupun container.

4. Mengaktifkan NFS Server pada Proxmox x86

Selanjutnya saya ingin agar storage tersebut bisa diakses oleh OrangePi3B melalui jaringan.

Untuk itu saya menggunakan NFS (Network File System).

NFS memungkinkan sebuah direktori pada server Linux diakses oleh komputer lain melalui jaringan, seolah-olah direktori tersebut merupakan storage yang tersedia secara lokal.

Pada server x86, saya menginstal paket NFS Server:

apt update
apt install nfs-kernel-server -y

Setelah instalasi selesai, saya membuka konfigurasi export NFS:

nano /etc/exports

Kemudian menambahkan konfigurasi berikut:

/backup/vzdump 20.20.20.0/24(rw,sync,no_subtree_check,no_root_squash)

Berikut penjelasan beberapa parameter yang digunakan:

Saya menggunakan no_root_squash karena Proxmox membutuhkan akses root ketika melakukan operasi tertentu pada storage.

Namun, konfigurasi ini harus digunakan dengan hati-hati karena memberikan hak akses yang cukup besar kepada root dari client. Karena itu, saya membatasi akses export pada jaringan homelab yang dipercaya.

Setelah konfigurasi selesai, saya menerapkannya:

exportfs -ra

Untuk memastikan direktori sudah berhasil diekspor:

exportfs -v

5. Menghubungkan OrangePi3B ke NFS Server

Setelah NFS Server berjalan pada x86, sekarang giliran OrangePi3B sebagai client.

Pertama, saya menginstal paket NFS client:

apt update
apt install nfs-common -y

Kemudian memeriksa daftar direktori yang tersedia pada NFS Server:

showmount -e 20.20.20.25

Hasil yang saya dapatkan:

Export list for 20.20.20.25:
/backup/vzdump 20.20.20.0/24

Artinya, direktori /backup/vzdump sudah berhasil diekspor dan dapat ditemukan oleh OrangePi3B.

Saya kemudian melakukan pengujian mount secara manual:

mkdir -p /mnt/test-nfs

mount -t nfs 20.20.20.25:/backup/vzdump /mnt/test-nfs

Untuk memastikan storage berhasil terhubung:

df -hT /mnt/test-nfs

Saya juga melakukan pengujian tulis:

touch /mnt/test-nfs/nfs-test.txt
ls -l /mnt/test-nfs/nfs-test.txt
rm /mnt/test-nfs/nfs-test.txt

Pada awalnya saya sempat menemukan kendala permission ketika mencoba menulis menggunakan user root. Setelah mengevaluasi konfigurasi export dan menerapkan no_root_squash, pengujian tulis berhasil dilakukan.

Setelah selesai, saya melepas mount sementara:

umount /mnt/test-nfs

6. Menambahkan NFS sebagai Storage Proxmox

Pengujian manual berhasil. Selanjutnya saya ingin agar NFS dapat dikelola langsung oleh Proxmox.

Saya tidak menggunakan /etc/fstab untuk melakukan mount permanen secara manual. Sebagai gantinya, saya memanfaatkan fitur NFS Storage bawaan Proxmox.

Pada OrangePi3B, saya membuka:

Datacenter → Storage → Add → NFS

Kemudian mengisi konfigurasi:

Proxmox akan mengelola mount NFS secara otomatis.

Lokasi mount yang digunakan:

/mnt/pve/backup-nfs

Untuk memastikan storage sudah aktif, saya menjalankan:

pvesm status

Dengan demikian, OrangePi3B sudah dapat mengakses storage yang secara fisik berada pada server x86.

7. Menggunakan Storage NFS untuk Virtual Machine

Awalnya saya hanya berencana menggunakan NFS sebagai tempat penyimpanan backup.

Namun, setelah konfigurasi berhasil, saya tertarik mencoba hal lain: apakah NFS juga dapat digunakan untuk menyimpan virtual disk dan menjalankan VM secara langsung?

Saya kemudian membuat VM Debian ARM64 dengan konfigurasi berikut:

Setelah VM dibuat, saya memeriksa konfigurasi menggunakan:

qm config 405

Bagian yang paling penting adalah:

virtio0: backup-nfs:405/vm-405-disk-0.qcow2,discard=on,iothread=1,size=32G

Dari konfigurasi tersebut, saya memastikan bahwa virtual disk VM memang berada pada storage backup-nfs, bukan pada storage lokal OrangePi3B.

Artinya, ketika VM melakukan aktivitas baca dan tulis, data akan melewati jaringan menuju server x86 dan kemudian disimpan pada HDD yang menggunakan ZFS.

Menarik juga, karena dengan cara ini OrangePi3B dapat menggunakan storage yang kapasitasnya lebih besar tanpa harus menyediakan HDD tambahan secara langsung.

8. Menguji Performa Storage Menggunakan FIO

Setelah VM berhasil berjalan menggunakan NFS, saya mulai penasaran dengan performanya.

Apakah storage melalui jaringan cukup cepat untuk menjalankan VM? Bagaimana performa baca dan tulisnya dibandingkan dengan storage lokal?

Untuk menjawab pertanyaan tersebut, saya menggunakan fio (Flexible I/O Tester).

Saya menginstalnya di dalam Debian VM:

apt update
apt install fio -y

Versi yang digunakan:

fio-3.33

Saya melakukan empat jenis pengujian:

• Sequential Write
• Sequential Read
• Random 4K Read
• Random 4K Write

Semua pengujian menggunakan file sebesar 4 GB, direct I/O, dan durasi 60 detik.

Pengujian Sequential Write

fio --name=seq-write \
    --filename=/root/fio-test.img \
    --size=4G \
    --rw=write \
    --bs=1M \
    --direct=1 \
    --ioengine=libaio \
    --iodepth=16 \
    --runtime=60 \
    --time_based \
    --group_reporting

Pengujian Sequential Read

fio --name=seq-read \
    --filename=/root/fio-test.img \
    --size=4G \
    --rw=read \
    --bs=1M \
    --direct=1 \
    --ioengine=libaio \
    --iodepth=16 \
    --runtime=60 \
    --time_based \
    --group_reporting

Pengujian Random 4K Read

fio --name=rand-read \
    --filename=/root/fio-test.img \
    --size=4G \
    --rw=randread \
    --bs=4k \
    --direct=1 \
    --ioengine=libaio \
    --iodepth=16 \
    --runtime=60 \
    --time_based \
    --group_reporting

Pengujian Random 4K Write

fio --name=rand-write \
    --filename=/root/fio-test.img \
    --size=4G \
    --rw=randwrite \
    --bs=4k \
    --direct=1 \
    --ioengine=libaio \
    --iodepth=16 \
    --runtime=60 \
    --time_based \
    --group_reporting

Setelah seluruh pengujian selesai, saya menghapus file pengujian:

rm -f /root/fio-test.img
sync

9. Hasil Pengujian Storage NFS

Berikut hasil yang saya dapatkan dari Debian VM yang menggunakan virtual disk pada NFS.

Dari hasil tersebut, saya melihat perbedaan yang cukup besar antara performa baca dan tulis.

Sequential Read masih cukup baik untuk konfigurasi ini. Random Read bahkan menghasilkan sekitar 10.800 IOPS.

Namun, Sequential Write hanya mendapatkan sekitar 9,65 MiB/s, sedangkan Random Write jauh lebih rendah, yaitu sekitar 66 IOPS.

Hasil ini membuat saya penasaran. Apakah masalahnya memang berasal dari NFS, atau justru dari HDD dan ZFS yang digunakan sebagai storage utama?

10. Membandingkan Performa NFS dengan ZFS Langsung

Untuk mencari tahu sumber permasalahannya, saya mencoba melakukan pengujian tambahan langsung pada server x86.

Kali ini saya tidak menggunakan VM maupun NFS. Saya menjalankan FIO langsung pada direktori ZFS:

/backup/vzdump

Perintah yang digunakan:

fio --name=seq-write \
    --filename=/backup/vzdump/fio-test.img \
    --size=4G \
    --rw=write \
    --bs=1M \
    --direct=1 \
    --ioengine=libaio \
    --iodepth=16 \
    --runtime=60 \
    --time_based \
    --group_reporting

Hasilnya cukup menarik.

Hasil pengujian langsung pada ZFS mencapai 36,9 MiB/s, sedangkan pengujian melalui VM di NFS hanya mencapai 9,65 MiB/s.

Dengan kata lain, throughput pengujian langsung sekitar 3,8 kali lebih tinggi dibandingkan pengujian melalui NFS.

Namun, ada hal lain yang cukup mengejutkan.

Pada pengujian langsung tersebut, rata-rata latency tercatat sekitar 433 ms. Bahkan persentil ke-99 mencapai sekitar 1.070 ms.

Menurut saya, angka latency ini cukup tinggi dan perlu diselidiki lebih lanjut.

Jadi, saya belum bisa menyimpulkan bahwa NFS merupakan satu-satunya penyebab rendahnya performa write. Bisa saja terdapat keterbatasan pada HDD, perilaku synchronous write ZFS, overhead QCOW2, maupun kombinasi beberapa faktor tersebut.

11. Apa yang Perlu Diperiksa Selanjutnya?

Dari eksperimen ini, saya mendapatkan beberapa hal yang menarik untuk dipelajari lebih lanjut.

Pertama, saya ingin mengetahui bagaimana kondisi fisik HDD ketika menerima aktivitas write.

Kedua, saya ingin memahami pengaruh konfigurasi synchronous write pada NFS dan ZFS.

Ketiga, saya ingin membandingkan performa virtual disk QCOW2 dengan RAW pada storage yang sama.

Untuk tahap investigasi berikutnya, beberapa perintah yang akan saya gunakan adalah:

Memeriksa kondisi pool:

zpool status backup

Memeriksa properti sync:

zpool get sync backup

Memeriksa properti dataset:

zfs get sync,compression,recordsize backup/vzdump

Memantau aktivitas disk:

zpool iostat -v backup 1 5

Saya belum berencana mengubah konfigurasi sync atau menonaktifkan mekanisme keamanan penulisan data hanya untuk mendapatkan angka benchmark yang lebih tinggi.

Bagi saya, performa memang penting, tetapi keamanan data dan kestabilan storage jauh lebih penting.

12. Kesimpulan

Dari seluruh proses ini, saya berhasil membangun centralized storage menggunakan ZFS dan NFS dengan memanfaatkan perangkat yang sudah tersedia di homelab.

HDD Toshiba yang sebelumnya belum digunakan secara maksimal kini dapat dimanfaatkan sebagai storage bersama untuk dua node Proxmox dengan arsitektur berbeda.

Beberapa hal yang berhasil saya implementasikan:

• Membuat ZFS pool dan dataset.
• Mengaktifkan kompresi LZ4.
• Mengintegrasikan ZFS ke Proxmox.
• Mengonfigurasi NFS Server pada x86 Proxmox.
• Menghubungkan OrangePi3B sebagai NFS Client.
• Menambahkan NFS sebagai storage Proxmox.
• Menyimpan virtual disk VM ARM64 pada NFS.
• Melakukan benchmark storage menggunakan FIO.

Eksperimen ini juga mengajarkan saya bahwa memiliki storage yang bisa diakses melalui jaringan belum tentu berarti performanya akan sama dengan storage lokal.

Ada banyak lapisan yang perlu diperhatikan, mulai dari virtual disk, protokol NFS, ZFS, hingga perangkat HDD itu sendiri.

Dan sepertinya perjalanan eksperimen storage ini belum selesai. Masih ada beberapa hal yang ingin saya uji dan optimalkan.

Bagi saya, membangun homelab bukan hanya tentang membuat layanan berjalan, tetapi juga memahami bagaimana setiap komponen bekerja dan bagaimana mengatasi masalah yang muncul di dalamnya.

Sedikit demi sedikit, pengalaman seperti ini menjadi pengetahuan yang bisa digunakan kembali ketika membangun infrastruktur yang lebih besar.

Catatan pribadi

Artikel ini saya tulis berdasarkan pengalaman konfigurasi dan pengujian langsung pada homelab saya. Hasil benchmark merupakan hasil pengujian pada perangkat dan konfigurasi yang digunakan, sehingga belum tentu sama pada perangkat lain.