Bagi banyak pemilik usaha kecil-menengah, satu server fisik yang menjalankan semua virtual machine terdengar praktis — sampai server itu mati mendadak dan seluruh operasional bisnis ikut berhenti. Di sinilah cluster Proxmox VE tiga node menjadi solusi yang masuk akal: cukup terjangkau untuk anggaran UKM, tapi tetap memberikan fondasi high availability (HA) yang selama ini hanya dianggap “mainan” perusahaan besar.

Proxmox VE adalah platform virtualisasi open source berbasis Debian yang menggabungkan KVM untuk virtual machine dan LXC untuk container, lengkap dengan web interface untuk manajemen terpusat. Ketika beberapa node Proxmox digabung menjadi satu cluster, admin bisa melakukan live migration, mengaktifkan HA agar VM otomatis pindah saat sebuah node mati, dan mengelola semuanya dari satu dashboard.

Pertanyaannya: kenapa harus tiga node, bukan dua saja yang lebih murah? Artikel ini akan membahas tuntas alasan teknisnya, kebutuhan hardware minimum, pilihan shared storage yang realistis untuk anggaran terbatas, sampai langkah-langkah praktis membangunnya.

Kenapa Minimal 3 Node, Bukan 2?

Ini bukan sekadar rekomendasi marketing — ini soal matematika quorum. Proxmox VE menggunakan Corosync sebagai lapisan komunikasi cluster, dan cluster ini bekerja berdasarkan sistem voting: setiap node punya satu suara, dan cluster hanya bisa beroperasi normal jika mayoritas suara (quorum) terpenuhi, dengan rumus (N/2) + 1.

Coba hitung sendiri:

• 2 node → quorum butuh 2 suara. Kalau satu node mati, sisa satu node otomatis kehilangan quorum dan cluster berhenti berfungsi normal (masuk mode read-only). Ini masalah klasik “split-brain” yang justru membatalkan tujuan HA itu sendiri.
• 3 node → quorum butuh 2 dari 3 suara. Kalau satu node mati, dua node yang tersisa masih mayoritas dan cluster tetap berjalan normal.

Dokumentasi resmi Proxmox VE menegaskan hal ini secara eksplisit: untuk kebutuhan High Availability, minimal tiga node diperlukan agar quorum bisa diandalkan. Analoginya sederhana — bayangkan rapat pengambilan keputusan dengan dua orang yang berseberangan pendapat, tidak akan pernah ada keputusan sah tanpa pihak ketiga sebagai penengah. Node ketiga berperan seperti “penengah” itu.

Memang ada workaround untuk cluster dua node menggunakan QDevice (perangkat vote eksternal ringan yang berjalan di luar cluster, biasanya di VM atau Raspberry Pi kecil), tapi untuk kebutuhan produksi small business, tiga node fisik penuh tetap jauh lebih andal dan lebih sederhana untuk dikelola dibanding menambal kekurangan cluster dua node.

Arsitektur Cluster 3 Node untuk Small Business

Cluster tiga node yang ideal untuk UKM biasanya terdiri dari:

1. Tiga unit server fisik (bisa server rack, tower, atau bahkan mini PC kelas industri untuk skala sangat kecil) yang menjalankan Proxmox VE dengan versi yang sama persis di semua node.
2. Jaringan cluster (corosync) yang terpisah dari jaringan VM dan storage, idealnya lewat NIC fisik khusus.
3. Shared storage atau storage terreplikasi agar VM bisa berpindah node tanpa kehilangan data.

Latensi jaringan antar-node menjadi faktor kritis yang sering diabaikan pemula. Corosync membutuhkan latensi stabil di bawah 5 milidetik (setara performa LAN) agar cluster tetap sehat; di atas itu, risiko node “fencing” diri sendiri (mematikan diri karena dianggap terputus dari cluster) meningkat signifikan, apalagi jika HA aktif.

Kebutuhan Hardware Minimum yang Realistis

Untuk skala small business (misalnya 15-40 VM/container ringan-menengah, bukan beban kerja enterprise berat), berikut kebutuhan hardware minimum yang masuk akal per node:

• CPU: minimal 6-8 core modern (Intel Xeon E-series atau AMD EPYC entry-level cukup memadai), sebaiknya vendor CPU yang sama di semua node agar live migration online berjalan mulus.
• RAM: minimal 32 GB per node, idealnya 64 GB jika beban VM cukup padat — ingat, saat HA memindahkan VM dari node yang mati, dua node sisanya harus sanggup menampung beban tambahan.
• Storage lokal: minimal SSD/NVMe enterprise-grade (bukan consumer SSD) karena ketahanan tulis (endurance) jauh lebih penting dibanding kapasitas mentah, terutama jika memakai Ceph atau ZFS.
• Network Interface Card (NIC): minimal 2 port fisik per node — satu untuk manajemen/VM, satu khusus untuk trafik cluster/storage. Idealnya 3 NIC (manajemen, corosync, storage) atau gunakan NIC 10GbE untuk menyederhanakan topologi.
• Power Supply redundan jika anggaran memungkinkan, karena kegagalan PSU adalah salah satu penyebab downtime paling umum di lingkungan UKM.

Pilihan Shared Storage: Mana yang Cocok untuk Anggaran Terbatas?

Ini bagian yang paling sering bikin bingung, karena setiap opsi punya trade-off berbeda antara biaya, kompleksitas, dan performa.

1. Ceph (hyper-converged) Ceph terintegrasi langsung di Proxmox VE dan menjadikan storage lokal tiap node sebagai satu pool storage terdistribusi. Kelebihannya: tidak perlu perangkat storage eksternal terpisah, self-healing otomatis, cocok untuk cluster tiga node. Kekurangannya: butuh minimal tiga node dengan disk khusus untuk OSD (idealnya bukan disk sistem), performa sangat bergantung pada kualitas NIC dan latensi jaringan, serta konsumsi resource CPU/RAM lebih tinggi dibanding opsi lain. Untuk UKM dengan anggaran terbatas tapi ingin arsitektur “all-in-one” tanpa NAS eksternal, Ceph adalah pilihan paling populer di cluster tiga node.

2. ZFS dengan replikasi (bukan shared storage sejati) Proxmox mendukung replikasi ZFS antar-node secara terjadwal (misalnya setiap 5-15 menit). Ini bukan storage yang benar-benar “shared” real-time, tapi cukup untuk skenario HA sederhana dengan sedikit potensi kehilangan data (RPO beberapa menit). Kelebihannya: jauh lebih ringan resource-nya dibanding Ceph, tidak butuh jaringan storage khusus berkecepatan sangat tinggi. Cocok untuk UKM yang prioritasnya “cukup bisa recovery cepat”, bukan zero-downtime murni.

3. NFS atau iSCSI dari NAS eksternal Jika anggaran memungkinkan membeli satu unit NAS (misalnya berbasis TrueNAS atau Synology dengan iSCSI), semua node bisa mount storage yang sama secara terpusat. Kelebihannya: setup lebih sederhana dibanding Ceph, performa storage bisa dioptimalkan terpisah dari compute. Kekurangannya: NAS menjadi single point of failure baru kecuali dibuat redundan, yang berarti biaya tambahan.

Rekomendasi praktis untuk small business: jika anggaran hanya cukup untuk tiga server tanpa perangkat tambahan, Ceph atau replikasi ZFS adalah pilihan paling masuk akal. Jika masih ada sisa anggaran untuk satu unit NAS terpisah, kombinasi NFS/iSCSI memberi kesederhanaan manajemen yang lebih baik untuk tim IT kecil yang belum familiar dengan Ceph.

Pertimbangan Jaringan

Disarankan memisahkan minimal tiga jenis trafik secara logis (VLAN) atau fisik jika NIC mencukupi:

• Trafik manajemen/VM (akses pengguna ke aplikasi)
• Trafik corosync (komunikasi quorum antar-node, sangat sensitif latensi)
• Trafik storage (Ceph/iSCSI/NFS, butuh bandwidth besar)

Menjalankan semuanya di satu NIC yang sama berisiko tinggi menyebabkan cluster kehilangan quorum saat trafik storage sedang padat, sehingga node bisa fencing diri sendiri secara tidak terduga.

Materi Praktis: Studi Kasus Sederhana

Bayangkan sebuah UKM dengan 20 karyawan yang menjalankan file server, aplikasi akuntansi berbasis web, dan mail server internal — total sekitar 10 VM. Dengan tiga node Proxmox (masing-masing 8 core, 64 GB RAM, 2x NVMe enterprise 1TB) yang dihubungkan lewat switch managed 10GbE dan menjalankan Ceph sebagai storage, bisnis ini bisa kehilangan satu node fisik (misalnya karena kerusakan motherboard) tanpa layanan internal terhenti — VM otomatis dipindahkan HA ke dua node yang tersisa dalam hitungan menit.

Tutorial Step-by-Step Membangun Cluster

1. Instal Proxmox VE di ketiga node dengan versi identik, hostname final, dan IP statis (hostname dan IP tidak bisa diubah setelah cluster dibuat).
2. Siapkan jaringan corosync terpisah terlebih dahulu sebelum membuat cluster, idealnya lewat NIC/VLAN khusus.
3. Buat cluster di node pertama lewat menu Datacenter > Cluster > Create Cluster, atau via command line dengan pvecm create nama-cluster.
4. Gabungkan node kedua dan ketiga ke cluster lewat menu Join Information, atau pvecm add <ip-node-pertama>.
5. Verifikasi status quorum dengan pvecm status — pastikan “Quorate: Yes” dan jumlah votes sesuai jumlah node.
6. Konfigurasi shared storage (Ceph, ZFS replication, atau NFS/iSCSI) sesuai kebutuhan.
7. Aktifkan HA group dan tentukan VM/container mana yang perlu failover otomatis.
8. Uji failover dengan mematikan satu node secara terkontrol untuk memastikan VM benar-benar berpindah otomatis.

Kesalahan yang Sering Terjadi

• Membangun cluster dua node tanpa QDevice, lalu berharap HA berjalan mulus. Penyebabnya kurang paham konsep quorum; dampaknya cluster kehilangan fungsi normal saat satu node down; solusinya tambah node ketiga atau minimal QDevice.
• Menyatukan trafik corosync dengan trafik storage di satu NIC. Penyebabnya ingin hemat biaya NIC; dampaknya node bisa fencing diri sendiri saat storage sibuk; solusinya pisahkan minimal secara VLAN.
• Memakai consumer SSD untuk Ceph OSD. Penyebabnya ingin menekan biaya; dampaknya performa dan umur disk jauh di bawah ekspektasi; solusinya gunakan SSD/NVMe enterprise dengan endurance tinggi.
• Lupa menyamakan versi Proxmox di semua node. Penyebabnya update tidak serentak; dampaknya potensi masalah kompatibilitas cluster; solusinya jadwalkan update bersamaan.

Tips dan Rekomendasi

• Gunakan CPU dari vendor yang sama di semua node agar live migration online tidak terhambat.
• Sisihkan anggaran untuk NIC redundan meski hanya cluster kecil — downtime jaringan jauh lebih mahal dibanding harga NIC tambahan.
• Uji skenario failover secara rutin, bukan hanya sekali saat instalasi awal.
• Untuk UKM yang benar-benar baru mengenal clustering, mulai dengan replikasi ZFS lebih dulu sebelum melangkah ke Ceph yang lebih kompleks.

Kesimpulan

Cluster Proxmox tiga node bukan sekadar soal menambah satu server ekstra — ini soal memenuhi kebutuhan matematis quorum agar high availability benar-benar berfungsi saat dibutuhkan. Dengan hardware yang tepat, pemisahan jaringan yang disiplin, dan pilihan storage yang sesuai anggaran, small business bisa mendapatkan tingkat keandalan infrastruktur yang dulunya hanya terjangkau oleh perusahaan besar.

Poin penting yang perlu diingat: minimal tiga node untuk quorum yang stabil, pisahkan trafik corosync dari trafik lain, dan pilih shared storage sesuai kombinasi anggaran dan tingkat kenyamanan tim IT Anda.

---

Frequently Asked Questions (FAQ)

Pertanyaan: Apakah cluster Proxmox bisa dibangun hanya dengan dua node? Jawaban: Bisa secara teknis, tapi tidak direkomendasikan untuk HA produksi karena masalah quorum. Dua node butuh QDevice tambahan sebagai penengah suara agar cluster tetap berfungsi saat satu node mati.

Pertanyaan: Apa storage terbaik untuk cluster tiga node dengan anggaran terbatas? Jawaban: Ceph atau replikasi ZFS umumnya paling praktis karena tidak memerlukan perangkat storage eksternal tambahan, cukup memanfaatkan disk lokal tiap node.

Pertanyaan: Berapa spesifikasi minimum server untuk cluster Proxmox small business? Jawaban: Idealnya minimal 6-8 core CPU, 32-64 GB RAM, dan SSD/NVMe enterprise per node, disesuaikan dengan jumlah dan beban VM yang akan dijalankan.

Pertanyaan: Apakah semua node harus punya spesifikasi hardware yang identik? Jawaban: Tidak wajib identik, tapi sangat disarankan menyamakan vendor CPU dan kapasitas resource agar live migration dan failover HA berjalan mulus tanpa hambatan kompatibilitas.

Pertanyaan: Apa yang terjadi jika satu node mati di cluster tiga node? Jawaban: Dua node yang tersisa masih memenuhi syarat quorum (mayoritas suara), sehingga cluster tetap berjalan normal dan VM dengan HA aktif otomatis dipindahkan ke node yang masih hidup.

---

Punya pengalaman membangun cluster Proxmox sendiri, atau justru masih ragu antara Ceph dan ZFS replication untuk bisnis Anda?

Tulis pertanyaan atau pengalaman Anda di kolom komentar — mari berdiskusi! Jangan lupa bagikan artikel ini ke rekan IT atau komunitas sysadmin Anda, dan jelajahi artikel terkait lainnya seputar Linux, networking, dan cybersecurity di blog ini agar tidak ketinggalan update terbaru seputar infrastruktur IT.