Rafi Harlianto

Informatics Engineering

Category: IT

  • Memahami dan Memaksimalkan Claude Code

    Memahami dan Memaksimalkan Claude Code

    Saya pakai beberapa AI code assistant, Claude Code, Antigravity, dan sejenisnya, tapi tulisan ini fokus ke Claude Code dan jadi bahan pembelajaran untuk saya yang masih pemula dalam penggunaannya. Prinsip di bawah ini sebagian besar berlaku juga untuk tool lain, cuma cara implementasinya beda-beda.

    Dua masalah paling sering muncul waktu kerja pakai AI code agent:

    1. Token cepat habis, usage limit kena padahal kerjaan belum kelar.
    2. Hasil kerja melenceng dari rencana, jadi harus dikoreksi berkali-kali.

    Catatan ini disusun dari dokumentasi resmi Claude Code (code.claude.com/docs).

    1. Hemat Token dan Usage Limit

    Akar masalahnya satu: context window. Makin penuh context, makin banyak token diproses ulang tiap pesan, dan performa ikut turun karena instruksi lama mulai “terlupakan”. Jadi strategi hemat token intinya jaga context tetap kecil dan relevan.

    StrategiKenapa penting
    Rapikan CLAUDE.mdFile ini kebaca tiap sesi, jadi ikut nambah token di tiap request. Isi cuma hal yang Claude tidak bisa tebak sendiri: perintah build khusus, konvensi kode beda dari default, gotcha project. Kalau satu baris dihapus dan Claude tetap benar, hapus saja
    /clear antar taskPindah task tapi context lama masih menumpuk itu boros. /clear reset total
    /compact <instruksi>Kasih arahan spesifik, misal /compact fokus ke perubahan API dan hasil test, biar ringkasan yang tersimpan relevan
    Reference file pakai @Sebut file spesifik, misal @src/auth/session.ts, daripada suruh Claude eksplorasi satu folder penuh
    Delegasikan riset ke subagentSubagent jalan di context terpisah, yang balik ke context utama cuma rangkumannya
    Pilih model sesuai beban kerjaSonnet cukup untuk kerjaan harian dan lebih murah. Simpan Opus untuk keputusan arsitektur atau analisis kompleks. Ganti lewat /model
    Pantau lewat /context dan /usage/context kasih breakdown token per komponen. /usage kasih estimasi biaya sesi berjalan

    2. Supaya Claude Code Jalan Sesuai Rencana

    Bagian ini paling sering diabaikan. Langsung suruh coding tanpa eksplorasi dan rencana biasanya menghasilkan kode yang terlihat benar tapi menjawab masalah yang salah.

    Alur resmi yang direkomendasikan ada empat tahap:

    1. Explore: masuk plan mode, suruh Claude baca dan pahami kode relevan dulu tanpa mengubah apa pun.
    2. Plan: minta Claude buat rencana implementasi detail. Bisa diedit manual dulu sebelum lanjut.
    3. Implement: keluar plan mode, biarkan Claude coding sambil verifikasi ke rencana yang disepakati.
    4. Commit: minta Claude commit dengan pesan jelas.

    Plan mode ada overhead-nya, jadi skip saja untuk perubahan kecil yang sudah jelas seperti perbaiki typo atau rename variabel. Pakai kalau perubahan menyentuh banyak file, atau kalian sendiri belum yakin pendekatan yang tepat.

    Dua kebiasaan lain yang paling berpengaruh ke akurasi hasil:

    Kasih konteks spesifik, bukan instruksi umum.

    Kurang spesifikLebih spesifik
    “tambahin test buat foo.py”“tulis test untuk foo.py, cover kasus user sudah logout, jangan pakai mock”
    “perbaiki bug login”“login gagal setelah session timeout, cek flow auth di src/auth/ terutama token refresh, buat failing test dulu baru diperbaiki”

    Kasih Claude cara verifikasi sendiri, entah test suite, build, atau screenshot dibanding desain awal. Tanpa itu, satu-satunya sinyal “kelar” cuma kode yang terlihat masuk akal, belum tentu benar.

    Untuk fitur besar, minta Claude interview kalian dulu soal implementasi teknis, UX, dan edge case, sebelum nulis spek ke file terpisah. Sesi implementasi baru dimulai setelah spek matang, jadi context-nya bersih dan fokus.

    Kalau sudah dikoreksi dua kali untuk masalah yang sama, jangan koreksi ketiga kalinya di sesi yang sama. /clear saja dan tulis ulang prompt yang lebih spesifik.

    Untuk kerjaan tanpa pengawasan, tambahkan satu langkah review dari subagent terpisah yang mengecek diff terhadap rencana awal, bukan sekadar gaya penulisan kode.

    3. Lain-lain

    • Hooks: aturan yang wajib jalan tanpa kecuali, misal lint otomatis tiap habis edit file. Deterministik, beda dari CLAUDE.md yang sifatnya cuma anjuran.
    • Skills: workflow berulang, bikin SKILL.md di .claude/skills/ daripada jelasin ulang tiap sesi.
    • Rename dan resume session: kasih nama sesi jelas pakai /rename per workstream, lanjut pakai --resume atau --continue.
    • Non-interactive mode: untuk kerjaan berulang atau otomasi, pakai claude -p "prompt" di script, pre-commit hook, atau CI.
    • Checkpoint dan rewind: tiap prompt otomatis bikin checkpoint. Kalau salah arah, tekan Esc dua kali atau jalankan /rewind.

    Pola gagal yang paling sering terjadi:

    Pola gagalCara mengatasi
    Satu sesi dipakai banyak task tidak nyambung/clear tiap ganti task
    Koreksi berulang tanpa hasil membaik/clear setelah dua kali gagal, tulis ulang prompt
    CLAUDE.md kepanjangan sampai instruksi penting ketutup noisePangkas ruthless
    Percaya hasil tanpa verifikasiSelalu sediakan cara ngecek
    Eksplorasi tanpa scope jelasBatasi cakupan riset atau delegasikan ke subagent

    Penutup

    Intinya satu: context adalah resource terbatas, perlakukan seperti resource, bukan tempat sampah. Makin bersih dan terarah context yang dikasih ke Claude Code, makin hemat token, dan makin kecil kemungkinan hasilnya melenceng dari rencana.

    Referensi:

    • Best practices for Claude Code, Anthropic. https://code.claude.com/docs/en/best-practices
    • Manage costs effectively, Anthropic. https://code.claude.com/docs/en/costs
  • Merancang Instalasi Otomatis Zimbra dengan Ansible

    Merancang Instalasi Otomatis Zimbra dengan Ansible

    Hari ini saya memulai untuk membangun project saya, yaitu project instalasi zimbra secara otomatis, dan disini saya menggunakan Ansible sebagai mesin otomasi nya. Instalasi Zimbra secara manual itu melelahkan. Kalian harus SSH ke server, menyiapkan hostname dan DNS, menjalankan install.sh, lalu menjawab puluhan pertanyaan interaktif di zmsetup.pl satu per satu. Ulangi proses ini untuk setiap server, dan satu salah ketik bisa membuat Anda mengulang dari awal.

    Di artikel ini saya akan menceritakan rancangan saya, bagaimana saya membangun sebuah dashboard yang menginstalasi Zimbra secara otomatis ke server target, cukup dengan mengisi parameter wajib lewat form. Mesin di belakangnya adalah Ansible. Dashboard mendukung dua edisi: Zimbra OSE (Open Source Edition) dan Zimbra NE (Network Edition).

    Kenapa Ansible?

    Ansible cocok untuk kasus ini karena beberapa alasan:

    • Agentless. Tidak perlu memasang apa pun di server target; cukup akses SSH dan Python (sudah ada di hampir semua distro Linux).
    • Idempotent. Menjalankan ulang playbook tidak merusak yang sudah benar — sangat penting untuk instalasi yang panjang.
    • Deklaratif. Anda mendeskripsikan kondisi akhir yang diinginkan, bukan urutan perintah manual.
    • Mudah dipasangkan dengan dashboard. Dashboard cukup men-generate file variabel dan inventory, lalu memanggil ansible-playbook.

    Arsitektur Solusi

    Alur kerjanya sederhana:

    [ Dashboard (form) ]
        │  generate
        ▼
group_vars/all.yml  +  inventory/hosts.ini
        │  trigger
        ▼
ansible-playbook site.yml
        │  SSH
        ▼
[ Server target: Zimbra terpasang ]

    Dashboard hanya bertugas mengumpulkan parameter dari user, menuliskannya ke dua file, lalu menjalankan playbook. Seluruh logika instalasi hidup di dalam Ansible.

    Metode Instalasi Unattended

    Kunci otomasi Zimbra adalah membuat installer yang biasanya interaktif menjadi unattended. Saya mengikuti pendekatan resmi dari repo Zimbra (zinstaller), yang terbagi dua fase:

    Fase 1 — Install software saja. Jalankan installer dengan flag software-only dan suplai jawaban lewat answer file:

    ./install.sh -s < keystroke_answers

    Fase 2 — Konfigurasi unattended. Setelah paket terpasang, jalankan setup dengan file konfigurasi, bukan wizard interaktif:

    /opt/zimbra/libexec/zmsetup.pl -c /tmp/zim-install-config

    File zim-install-config berisi key konfigurasi resmi Zimbra (hostname, domain, password admin, komponen yang diaktifkan, dan seterusnya). Template inilah yang diisi dari parameter dashboard.

    Perbedaan OSE vs NE

    Bedanya terutama pada lisensi:

    • OSE — tidak butuh lisensi sama sekali.
    • NE 10.1.x — aktivasi memakai license KEY via zmlicense -a <key>.
    • NE ≤ 10.0 — memakai file lisensi (license.xml) yang ditunjuk lewat variabel LICENSEFILE.

    Dashboard cukup menampilkan field lisensi secara kondisional ketika user memilih edisi NE.

    Struktur Project Ansible

    instaru/
├── site.yml
├── inventory/
│   └── hosts.ini
├── group_vars/
│   └── all.yml          # semua parameter wajib di sini
├── roles/
│   ├── preflight/       # cek hostname, DNS, resource, swap
│   ├── zimbra_install/  # download, install.sh -s
│   └── zimbra_config/   # render config, zmsetup.pl -c
└── templates/
    └── zim-install-config.j2

    Parameter wajib (group_vars/all.yml)

    Inilah variabel yang dikumpulkan dashboard dari user:

    # Identitas
zimbra_edition: "ose"          # ose | ne
zimbra_version: "10.1.0"
zimbra_hostname: "mail.example.com"
zimbra_domain: "example.com"

# Kredensial
admin_password: "{{ vault_admin_password }}"
ldap_password: "{{ vault_ldap_password }}"

# Lisensi (hanya untuk NE)
zimbra_license_key: ""         # NE 10.1.x
zimbra_license_file: ""        # NE <=10.0

# Komponen
enable_proxy: true
enable_spell: true
timezone: "Asia/Jakarta"

    Simpan semua password di Ansible Vault, jangan plaintext. Dashboard bisa mengenkripsi nilai sensitif sebelum menulisnya ke file.

    Inventory & topologi

    Topologi dipilih lewat grup inventory. Untuk single-server semua peran di satu host; untuk multi-server, peran dipecah dan LDAP harus diinstall pertama.

    # Single server

    [zimbra_single]
mail.example.com

    atau

    # Multi-server

    [zimbra_ldap]
ldap.example.com

[zimbra_store] (mailbox/mbox)
store.example.com

[zimbra_mta]
mta.example.com

[zimbra_proxy]
proxy.example.com

    Playbook Utama

    # site.yml
- name: Validasi & persiapan server
  hosts: all
  become: true
  roles:
    - preflight

- name: Install & konfigurasi Zimbra
  hosts: all
  become: true
  roles:
    - zimbra_install
    - zimbra_config

    Role preflight penting: ia memvalidasi bahwa hostname FQDN sudah benar, DNS A dan MX sudah resolve, RAM mencukupi, dan swap tersedia — kesalahan paling umum pada instalasi Zimbra ada di tahap ini, jadi lebih baik gagal cepat sebelum installer berjalan.

    Catatan dependensi: playbook ini membutuhkan koleksi community.general dan ansible.posix. Pasang dengan:

    ansible-galaxy collection install community.general ansible.posix

    Menjalankannya

    Dari dashboard, eksekusi akhirnya sesederhana ini:

    ansible-playbook -i inventory/hosts.ini site.yml --ask-vault-pass

    Dashboard menjalankan perintah ini sebagai background job, lalu menampilkan progres dengan men-stream output Ansible kembali ke UI. User cukup menunggu sampai status berubah menjadi selesai.

    Penutup

    Jika ini berhasil, maka saya tinggal membuat dashboard terintegrasi yang dapat melakukan instalasi zimbra hanya dengan beberapa input saja (ip, hostname, dll) dan akses ssh ke server target.

    Langkah pengembangan berikutnya yang saya rencanakan: validasi parameter real-time di sisi dashboard, dukungan rollback otomatis bila instalasi gagal di tengah jalan, dan template multi-server siap pakai.

  • Integrasi Proxmox Datacenter Manager (PDM) dengan Cluster PVE

    Integrasi Proxmox Datacenter Manager (PDM) dengan Cluster PVE

    Ini catatan percobaan instalasi saya dengan Proxmox Datacenter Manager (PDM). Instalasinya sendiri sudah saya lakukan cepat lewat ISO PDM, jadi di sini saya fokus ke bagian integrasinya dengan cluster PVE saya. PDM ini lapisan manajemen terpusat di atas beberapa node atau cluster Proxmox, jadi saya bisa pantau semua dari satu antarmuka tanpa buka banyak tab.

    Catatan sebelum integrasi

    • PDM harus bisa terhubung langsung ke remote PVE lewat API (port 8006). Remote sendiri tidak perlu bisa menghubungi PDM.
    • Reverse proxy antara PDM dan remote tidak didukung. Untuk remote lewat internet, pakai tunnel seperti WireGuard atau OpenVPN.
    • Versi minimum: Proxmox VE 8.4 dan Proxmox Backup Server 3.4.

    Akses web UI

    Setelah instalasi ISO selesai, akses lewat browser pakai HTTPS di port 8443.

    https://<ip-atau-dns-pdm>:8443

    Login pakai user root@pam dengan password yang diset saat instalasi.

    Menambahkan cluster PVE sebagai remote

    Di PDM, satu cluster atau node PVE disebut remote. Untuk cluster, cukup tambah satu node saja, PDM otomatis menemukan node lain di cluster yang sama.

    1. Buka menu Remotes lalu Add, pilih tipe Proxmox VE.
    2. Masukkan alamat salah satu node cluster, misalnya https://192.168.14.11:8006 untuk node rafi1.
    3. Login dengan user PVE (root@pam) beserta passwordnya. Wizard membuat API token otomatis sesuai izin user, jadi PDM tidak menyimpan password.
    4. Wizard akan probe sertifikat. Karena sertifikat Proxmox default itu self-signed, kalian diminta menerima fingerprint-nya (Trust On First Use). Pastikan fingerprint cocok sebelum menerima.
    5. Setelah ditambahkan, PDM menampilkan seluruh hierarki cluster, VM, container, dan storage.

    Yang bisa dilakukan setelah tersambung

    • Metrik terpusat (CPU, RAM, storage) dari semua remote dalam satu dashboard.
    • Start, stop, reboot guest tanpa login ke node satu per satu.
    • Live migration guest, bahkan antar cluster berbeda tanpa syarat jaringan cluster.
    • Update management terpusat untuk melihat dan menjalankan patch.
    • Overview Ceph, berguna untuk cluster yang pakai Ceph.

    Menemukan Fingerprint Node Proxmox

    Kasus yang sering muncul: sertifikat self-signed di node di-renew atau dirotasi, sehingga fingerprint yang dipin di PDM tidak cocok lagi. Koneksi ke remote itu akan gagal dengan error certificate verify failed.

    pvenode cert info --output-format json-pretty

    Cari fingerprint: diantara hasilnya.

    Penutup

    Sejauh percobaan ini, PDM mengisi celah yang selama ini merepotkan saat punya lebih dari satu node atau cluster. Integrasinya cukup mulus, dan satu remote sudah otomatis menarik seluruh node cluster.

    Referensi

    • Dokumentasi resmi PDM, Remotes: https://pdm.proxmox.com/docs/remotes.html
    • Dokumentasi resmi PDM, Installation: https://pdm.proxmox.com/docs/installation.html
    • Halaman produk PDM: https://www.proxmox.com/en/products/proxmox-datacenter-manager/overview
  • Perbedaan Repository Proxmox VE: Enterprise vs No-Subscription

    Perbedaan Repository Proxmox VE: Enterprise vs No-Subscription

    Waktu pertama install Proxmox VE, repository yang aktif secara default adalah Enterprise. Kalau kalian tidak punya subscription, apt update bakal error 401 Unauthorized dan tidak ada paket yang bisa di-update. Di sini saya jelaskan singkat bedanya repository Enterprise dan No-Subscription, plus kapan sebaiknya pakai yang mana.

    Sebenarnya Proxmox VE menyediakan tiga repository (di luar repo dasar Debian):

    • pve-enterprise: paling stabil, untuk produksi, butuh subscription.
    • pve-no-subscription: gratis, tanpa key, cocok untuk testing dan non-produksi.
    • pve-test: untuk developer yang mau coba fitur baru, jangan dipakai di produksi.

    Yang paling sering dibandingkan adalah dua yang pertama.

    Enterprise

    • Repo default dan direkomendasikan Proxmox untuk produksi.
    • Berisi paket paling stabil karena melewati testing dan validasi lebih ketat.
    • Butuh subscription aktif (level berapa pun).
    • URL: https://enterprise.proxmox.com/debian/pve

    No-Subscription

    • Gratis, tidak butuh subscription key.
    • Cocok untuk testing dan non-produksi seperti homelab atau lab belajar.
    • Paketnya tidak melalui testing seketat repo Enterprise, jadi update datang lebih cepat tapi risiko sedikit lebih tinggi.
    • Setelah beberapa waktu, versi paketnya juga masuk ke repo Enterprise.
    • URL: http://download.proxmox.com/debian/pve

    Tabel Perbandingan

    AspekEnterpriseNo-Subscription
    BiayaButuh subscription berbayarGratis
    KestabilanPaling stabil, validasi ketatKurang teruji, update lebih cepat
    RekomendasiProduksiTesting / non-produksi
    Subscription keyWajibTidak perlu
    Notifikasi “no valid subscription”Tidak munculMuncul di web UI
    Status defaultAktifPerlu diaktifkan manual

    Kapan Pakai yang Mana

    • Server produksi yang butuh stabilitas dan support resmi: pakai Enterprise (beli subscription).
    • Homelab, lab testing, belajar, atau budget terbatas: pakai No-Subscription.
    • Jangan aktifkan keduanya bersamaan. Pilih salah satu dan disable yang lain lewat web UI di Node > Updates > Repositories.
    • Repo Debian (base OS) jangan di-disable. Itu tetap diperlukan untuk paket di luar Proxmox.

    Catatan untuk Proxmox VE 9

    Mulai Proxmox VE 9 (basis Debian 13 Trixie), format repository pindah ke deb822 (.sources), bukan lagi one-line sources.list seperti di PVE 8 (Debian 12 Bookworm). Contoh stanza No-Subscription di file /etc/apt/sources.list.d/pve-no-subscription.sources:

    Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

    Soal notifikasi “You do not have a valid subscription”: ini wajar muncul kalau pakai No-Subscription dan aman diabaikan di node lab. Saya tidak menyarankan mengedit file JavaScript bawaan untuk menghilangkannya, karena perubahan itu bisa hilang atau rusak saat update dan bukan praktik resmi.

    Sumber

  • Mengatur Proxmox dari Handphone

    Mengatur Proxmox dari Handphone

    Selama ini saya mendalami dan mempelajari Proxmox, saya kira hanya dapat akses lewat web UI, di hp pun sudah pas sih untuk tampilan UI nya. Tapi, pas iseng baca-baca artikel, ternyata Proxmox bisa dipantau dan dikontrol langsung dengan menggunakan aplikasi berbasis android/ios. Berikut rangkuman yang saya pelajari, plus sedikit pendapat saya sebagai orang yang kadang sehari-hari pakai Proxmox.

    Sumber: How I Manage My Proxmox Cluster From My Phone (4 Mobile Tools I Use) – Virtualizationhowto

    Apa yang bisa dan tidak bisa dari HP

    Web UI desktop tetap tempat utama buat ngatur semua aspek cluster. HP cocoknya buat monitoring dan operasi cepat.

    Bisa dari HP:

    • Cek status node dan resource cluster
    • Start, stop, restart VM dan container
    • Pantau CPU dan memori
    • Lihat utilisasi storage
    • Baca system log

    Sebaiknya tetap dari desktop:

    • Konfigurasi jaringan
    • Manajemen storage
    • Konfigurasi level cluster
    • Perubahan infrastruktur kompleks

    4 tool yang dibahas

    1. Web UI mobile bawaan Proxmox

    Sejak Proxmox 9, web UI bawaan sudah ramah layar HP. Tinggal buka URL server di browser, tampilannya menyesuaikan.

    Kelebihan:

    • Tanpa instal aplikasi, cukup browser
    • Selalu kompatibel dengan rilis terbaru
    • Fitur admin cukup lengkap

    Kekurangan:

    • Masih ada yang belum bisa, contohnya snapshot

    2. Aplikasi resmi Proxmox

    Konek langsung ke API Proxmox. Lebih praktis dari browser karena ingat koneksi dan dukung login biometrik.

    Kelebihan:

    • Mudah dipakai
    • Info resource lengkap
    • Operasi power VM seperti start, stop, dan reboot
    • Login biometrik

    Kekurangan:

    • Tidak ada manajemen detail
    • Tidak ada manajemen snapshot
    • Tidak bisa kelola PBS

    3. Proxmobo

    Aplikasi pihak ketiga dengan dashboard rapi. Menurut penulis, grafik resource-nya paling bagus di antara semua aplikasi.

    Kelebihan:

    • UI termasuk terbaik menurut penulis
    • Info resource detail
    • Operasi power VM
    • Bisa tambah instance PBS secara native

    Kekurangan:

    • Sebagian fitur terkunci di premium
    • Tidak ada manajemen snapshot

    4. Proxmate

    Favorit penulis belakangan. Bersih, intuitif, fokus ke monitoring dan operasi cepat. Yang menonjol: bisa lihat kesehatan Ceph langsung dari aplikasi (katanya tidak ada di aplikasi lain), kelola snapshot di versi berbayar, dan SSH quick commands.

    Kelebihan:

    • Mudah dipakai
    • Info paling lengkap di antara semua aplikasi
    • Status kesehatan Ceph native
    • Bisa kelola snapshot
    • Info resource sangat detail
    • Bisa lihat suhu hardware
    • SSH quick commands yang bisa dikustomisasi
    • Operasi power VM
    • Versi premium lisensi seumur hidup, sekitar 9,99 dolar

    Kekurangan:

    • Sebagian fitur perlu versi berbayar

    Jangan lupa, butuh tunnel atau VPN untuk akses dari luar

    Kalau di luar jaringan homelab, jangan pernah ekspos web UI cluster ke internet. Pakai VPN atau tunnel modern seperti Pangolin, Cloudflare Tunnel, atau Twingate. Tidak perlu buka port masuk, cukup izinkan koneksi keluar lewat HTTPS. Alurnya: konek VPN dulu, baru buka aplikasi mobile.

    Tabel perbandingan

    ToolPlatformCocok untukKelebihan utamaKeterbatasan
    Web UI mobile bawaanBrowser (iOS/Android)Akses cluster penuhBawaan Proxmox, fitur cukup, selalu update, tanpa instal aplikasiAda batasan di mobile, tidak semua fitur tersedia
    Aplikasi resmi ProxmoxiOS/AndroidKontrol VM dan node cepatTampilan simpel, operasi power gampangKonfigurasi lanjutan terbatas
    ProxmoboiOS/AndroidDashboard visual yang cantikUI bagus, grafik resource, overview cluster okePihak ketiga, ada batasan fitur
    ProxmateiOS/AndroidMonitoring termasuk CephMonitoring kuat, snapshot, SSH quick action, monitoring hardwareSebagian fitur perlu versi berbayar

    Penutup

    Buat saya ini penemuan yang menyenangkan. Beberapa pendapat saya:

    • HP bukan pengganti web UI desktop, posisinya pelengkap buat monitoring dan tindakan cepat.
    • Mulai dari yang gratis dulu, baru naik ke berbayar kalau butuh fitur seperti snapshot atau monitoring Ceph.
    • Fitur Ceph di Proxmate menarik buat saya yang kebetulan pakai Ceph di cluster sendiri.
    • Sebagus apa pun aplikasinya, keamanan tetap nomor satu. Jangan tergoda kemudahan sampai lupa pakai VPN atau tunnel.

    Referensi

  • Thin Provision di ZFS Proxmox: Kelalaian Kecil yang Bikin I/O Error

    Thin Provision di ZFS Proxmox: Kelalaian Kecil yang Bikin I/O Error

    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:

    ModeUkuran disk virtualRuang yang langsung dikunci di pool
    Thin (sparse)100 GBSesuai data terpakai, misal 10 GB
    Thick (non sparse)100 GB100 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

    1. Buka Datacenter > Storage > Add > ZFS.
    2. Isi ID dan pilih ZFS Pool yang dipakai.
    3. Centang opsi Thin provision.
    4. 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:

    1. Datacenter > Storage > pilih storage ZFS yang dimaksud > Edit.
    2. Centang Thin provision.
    3. Klik OK.

    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/
  • Checklist Keamanan Proxmox VE: 2FA, RBAC, Firewall, Update, dan Remote Access

    Checklist Keamanan Proxmox VE: 2FA, RBAC, Firewall, Update, dan Remote Access

    Sebagian besar insiden di lingkungan virtualisasi itu bukan karena teknik hacking canggih. Biasanya pemicunya sederhana: password dipakai ulang, web UI bisa diakses dari internet, atau patch ditunda terus karena dianggap merepotkan.

    Yang bikin Proxmox beda dari server biasa, dia itu management plane. Anggap saja Proxmox sebagai panel kendali untuk seluruh VM dan container kalian. Jadi kalau penyerang berhasil masuk ke Proxmox, dia tidak cuma menguasai satu VM. Dia bisa mount disk VM lain, menyalin datanya, membaca output console (yang sering memuat password), sampai mengubah jaringan. Singkatnya, “admin di UI Proxmox” itu hampir sama bahayanya dengan “root di servernya langsung”.

    Tulisan ini rangkuman dari checklist keamanan Proxmox di cr0x.net, saya tulis ulang biar lebih mudah dipahami.

    Lima prioritas

    Kalau bingung mau mulai dari mana, kerjakan lima hal ini dulu sesuai urutan:

    1. Buat panel Proxmox tidak bisa diakses dari jaringan sembarangan. Idealnya cuma lewat VPN atau jaringan admin khusus.
    2. Wajibkan 2FA untuk semua akun manusia. Proses otomatis (script, automation) cukup pakai API token.
    3. Atur hak akses (RBAC) seperlunya saja. Pisahkan yang cuma “menjalankan VM” dari yang boleh “mengubah cluster”.
    4. Nyalakan firewall dengan prinsip tutup dulu lalu buka seperlunya, dan pastikan benar-benar jalan.
    5. Rutin patch secara bertahap, dan jangan takut reboot kalau memang perlu.

    Lima ini saya jabarkan satu per satu di bawah.

    2FA

    2FA (two-factor authentication) itu lapisan kedua selain password. Jadi walaupun password kalian bocor, penyerang tetap butuh kode dari HP kalian untuk bisa masuk. Anggap saja seperti sabuk pengaman, dia tidak mencegah semua masalah, tapi mencegah masalah kecil jadi fatal.

    Di Proxmox kalian bisa pakai TOTP (kode 6 digit dari aplikasi seperti Google Authenticator, ini paling gampang) atau WebAuthn (security key fisik).

    • Wajibkan untuk semua akun yang bisa login ke UI atau shell.
    • Jangan ada akun yang dipakai ramai-ramai. Kalau satu akun dipakai banyak orang, kalian tidak akan tahu siapa melakukan apa.
    • Untuk automation, pakai API token. Token bisa dibatasi haknya dan dirotasi tanpa mengganggu akun manusia.
    • Siapkan jalur darurat (break-glass) kalau HP 2FA hilang: kredensial disimpan offline, dengan prosedur dan catatan yang jelas.

    Satu hal yang sering bikin pusing: TOTP bergantung pada jam yang akurat. Kalau jam server melenceng karena NTP mati, kodenya bakal gagal terus untuk banyak orang sekaligus. Solusinya perbaiki NTP, bukan malah mematikan 2FA.

    RBAC

    RBAC itu sistem hak akses berbasis peran. Intinya kalian menentukan siapa boleh melakukan apa, dan di bagian mana.

    Yang perlu diingat, hak akses di Proxmox itu menurun dari atas ke bawah, mengikuti struktur datacenter ke node ke VM. Jadi kalau kalian kasih seseorang hak di level paling atas (/), otomatis dia punya hak itu di semua node dan semua VM. Ini sumber masalah yang paling sering: niatnya cuma kasih akses sementara, ujungnya orang itu bisa mengutak-atik seluruh infrastruktur.

    • Berikan peran ke group, bukan ke orang per orang. Orang bisa keluar masuk, group lebih mudah dikelola.
    • Pakai cakupan yang sempit. Misal operator VM cukup diberi akses di /vms atau pool tertentu, bukan di /.
    • Pisahkan “menjalankan” (start/stop VM) dari “mengubah infrastruktur” (menambah storage, gabung cluster).
    • Peran PVEAdmin di / itu praktis kekuasaan penuh. Simpan hanya untuk segelintir admin inti.

    Firewall

    Firewall bawaan Proxmox sebenarnya bagus, tapi banyak orang mengira cukup mencentang satu kotak di GUI lalu merasa aman. Padahal keamanan tidak boleh bergantung pada satu centang. Kalian perlu yakin rule-nya benar-benar diterapkan.

    Beberapa aturan yang sebaiknya tidak dilanggar:

    • Web UI (port 8006) dan SSH (port 22): hanya boleh diakses dari jaringan admin atau VPN.
    • Trafik cluster (Corosync, untuk komunikasi antar node): hanya antar node di jaringan cluster, dan jangan di-NAT.
    • Storage (NFS, iSCSI, Ceph): hanya antar pihak yang memang perlu, jangan dibuka ke semua.

    Prinsipnya tutup semua inbound dulu di interface management, baru buka yang benar-benar dibutuhkan. Setelah itu cek di dua tempat, level datacenter dan level node, lalu pastikan rule-nya benar-benar aktif di server, bukan cuma kelihatan aktif di UI. Dan ingat, server yang “bisa di-ping” itu belum tentu aman, karena penyerang tidak butuh ping, dia butuh port yang terbuka.

    Update

    Soal update ini lebih ke disiplin daripada teknis. Kuncinya jangan menunda, tapi juga jangan gegabah.

    • Update bertahap, satu node dulu. Kalau aman, baru lanjut ke node berikutnya. Tujuannya supaya kalau ada masalah, tidak semua node ikut tumbang.
    • Sediakan jadwal maintenance rutin, walau cuma sejam seminggu. Downtime yang terencana jauh lebih murah daripada downtime mendadak.
    • Update kernel artinya harus reboot. Boleh ditunda sebentar, tapi jangan dibiarkan berbulan-bulan.
    • Sesudah update, cek hal penting: quorum cluster, storage ke-mount, VM bisa start, backup jalan, dan firewall masih benar.

    Pisahkan juga di kepala kalian, security update itu mendesak, sedangkan feature update bisa diteliti dulu sebelum diterapkan.

    Remote access

    Cara paling aman mengelola Proxmox dari jarak jauh bukan dengan memperkuat pintu yang terbuka, tapi dengan mengurangi jumlah pintunya. “Boleh diakses dari internet asal pakai password kuat” itu bukan strategi yang aman.

    Pilih salah satu pola, jangan dicampur asal-asalan:

    1. VPN ke jaringan admin. Paling sederhana. Admin masuk VPN dulu, baru bisa mengakses Proxmox.
    2. Bastion atau jump host. Login dulu ke satu server perantara, baru lompat ke node Proxmox.
    3. Jaringan management khusus yang hanya bisa diakses dari kantor atau VPN.

    Untuk SSH-nya sendiri:

    • Pakai key, matikan login pakai password.
    • Matikan login root langsung. Pakai user biasa lalu sudo, supaya jejaknya tercatat.
    • Batasi IP yang boleh masuk ke subnet admin saja.

    Catatan penting: sebelum mengutak-atik konfigurasi SSH, pastikan kalian masih punya akses console (lewat IPMI, iLO, atau KVM). Buka juga sesi kedua saat menguji perubahannya. Ini biar kalau salah konfigurasi, kalian tidak terkunci dari server sendiri.

    Audit cepat

    Beberapa perintah ini bisa kalian jalankan di tiap node untuk mengecek kondisi saat ini:

    PerintahUntuk mengecek
    pvecm statusStatus quorum cluster. Kalau tidak quorate, jangan dulu ubah konfigurasi
    timedatectlApakah jam server sinkron (penting buat 2FA)
    pveum acl listDaftar siapa punya hak apa, di path mana
    pveum user token list <user>API token yang ada beserta masa berlakunya
    ss -lntpService apa saja yang listen dan di alamat mana
    sshd -TKonfigurasi SSH yang benar-benar berlaku
    journalctl -u pveproxyPercobaan login. Kalau ada IP asing, berarti panel kalian terekspos

    Langkah minggu ini

    Kalau mau langsung action, ini yang bisa dikerjakan minggu ini:

    1. Pastikan port 8006 dan 22 tidak bisa diakses dari jaringan luar.
    2. Aktifkan 2FA untuk semua orang (perbaiki NTP dulu).
    3. Bersih-bersih RBAC, terutama hapus PVEAdmin yang menempel di /.
    4. Cek firewall benar-benar aktif di datacenter dan node.
    5. Mulai biasakan patch bertahap.

    Tujuannya bukan bikin benteng yang mustahil ditembus. Tujuannya membuat akses ke Proxmox itu sengaja dibatasi, hak akses sengaja dipersempit, dan perubahan dilakukan secara rutin dan terkontrol.

    Referensi

  • Pemilihan OSD untuk Proxmox VE Ceph dan Alasannya

    Pemilihan OSD untuk Proxmox VE Ceph dan Alasannya

    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

    KondisiOSDKeterangan
    Tingkat lab atau uji coba1 OSDBisa jalan, misalnya di laptop pakai VirtualBox atau di Raspberry Pi. Bukan untuk produksi.
    Best Practice Proxmox VE Ceph12 OSDMinimal 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.

    Referensi

  • Memahami PVE Electrified: Mod UI di Proxmox

    Memahami PVE Electrified: Mod UI di Proxmox

    Saat saya baca-baca artikel tentang Proxmox di virtualizationhowto, saya menemukan satu proyek menarik bernama PVE Electrified. Ini bukan UI Proxmox resmi, tapi sebuah modifikasi tampilan web Proxmox VE yang menambahkan fitur-fitur yang menurut saya sudah seharusnya ada sejak awal, khususnya untuk homelab. Di tulisan ini saya tidak membahas cara instalasi nya, cuma sedikit rangkuman saja tentang apa isinya.

    Apa itu PVE Electrified

    • Modifikasi antarmuka web Proxmox VE, dibuat oleh developer independen (bukan dari perusahaan Proxmox).
    • Sasaran utamanya pengguna homelab, developer, dan kalian yang suka oprek.
    • Bukan add-on resmi dan tidak didukung Proxmox, jadi tidak disarankan dipasang di server produksi.
    • Membutuhkan Proxmox VE versi 9.x atau lebih baru.

    Fitur yang sudah tersedia

    • CPU usage bars di tree. Penggunaan CPU tiap guest tampil langsung di panel kiri secara realtime (interval sekitar 1 detik), jadi tidak perlu buka tab Summary dulu.
    • Tombol power management di tree. Start, stop, dan reset VM maupun LXC bisa langsung dari pohon objek, dengan feedback status yang lebih cepat. Praktis buat kalian yang sering cycling mesin lab.
    • Instant cloning guest. Ini fitur favorit saya. Memanfaatkan mekanisme copy-on-write ZFS, jadi clone terjadi instan dan tidak memakan disk tambahan. Bisa clone langsung dari snapshot untuk mengintip kondisi VM yang lama, bisa clone beserta RAM, dan dialognya dirancang lebih cepat. Catatan: fitur clone ini hanya jalan di ZFS.
    • Dialog konflik hardware. Saat menyalakan guest yang memakai resource eksklusif seperti USB atau GPU, akan muncul peringatan konflik. Berguna kalau kalian gantian pakai satu GPU passthrough antar VM.
    • Sistem plugin. Ada mekanisme untuk membuat dan mempublikasikan plugin UI sendiri. Ini poin penting karena selama ini UI Proxmox sulit dimodifikasi, sehingga ekosistem mod komunitas hampir tidak ada.

    Fitur yang masih direncanakan

    • Menampilkan thin disk usage sebenarnya di tree.
    • Dukungan Docker.
    • Asisten untuk optimasi homelab, antara lain GPU passthrough, dynamic IP, mencegah SSD cepat aus, update microcode, perbaikan setting memory ZFS, dan penanganan disk stalling.

    Sedikit soal arsitektur

    Yang membuat proyek ini menarik secara teknis adalah perubahan tech stack-nya. UI asli Proxmox ditulis dengan Perl dan ExtJS dalam satu file JavaScript besar yang susah di-debug. PVE Electrified memindahkannya ke tumpukan yang lebih modern: Node.js dan TypeScript di backend, serta React dan Vite di frontend. Komponen React dipakai berdampingan dengan komponen ExtJS lama. Webserver Node.js berjalan di port 8006 dan mem-proxy sebagian path ke pveproxy asli yang dipindah ke port internal 8005. Pendekatan inilah yang membuka pintu untuk sistem plugin tadi.

    Penutup

    Buat saya, PVE Electrified adalah contoh bagus bagaimana komunitas homelab sering jadi tempat lahirnya fitur yang belum ada di produk resmi. Sifatnya quality-of-life: tidak mengubah arsitektur secara besar, tapi memperbaiki workflow yang sehari-hari terasa kurang. Selama kalian paham ini mod tidak resmi dan menjauhkannya dari server produksi, proyek ini layak dicoba di lab pribadi.

    Sumber:

    https://www.virtualizationhowto.com/2026/06/i-found-a-proxmox-mod-that-adds-features-i-wish-were-built-in

    https://github.com/bogeeee/pve-manager-electrified

    https://www.pve-electrified.net

  • Ceph Full Mesh Network di Proxmox VE

    Ceph Full Mesh Network di Proxmox VE

    Kalau kalian membangun cluster Proxmox 3 node dengan Ceph, salah satu kendala yang sering muncul adalah switch. Ceph butuh jaringan storage cepat (minimal 10 Gbit), sedangkan switch 10/25/40/100 Gbit harganya mahal. Solusinya adalah full mesh network. Di tulisan ini saya jelaskan dari pengertian sampai cara konfigurasinya di Proxmox VE, termasuk cara terbaru lewat SDN Fabrics di PVE 9.

    Apa itu full mesh network

    Full mesh adalah topologi di mana setiap node terhubung langsung ke node lain lewat kabel point-to-point, tanpa melewati switch. Untuk cluster 3 node, artinya tiap node punya koneksi langsung ke dua node sisanya. Pada Ceph, jaringan inilah yang dipakai untuk lalu lintas storage (public dan cluster network) berkecepatan tinggi.

    Topologinya seperti ini:

             ┌───────┐
    ┌────┤ Node1 ├────┐
    │    └───────┘    │
┌───┴───┐         ┌───┴───┐
│ Node2 ├─────────┤ Node3 │
└───────┘         └───────┘

    Kenapa pakai full mesh

    Alasan utamanya hemat. Kalian bisa dapat koneksi antar node yang sangat cepat tanpa beli switch mahal. Selain itu bandwidth antar node penuh dan latency rendah, jadi cocok untuk cluster kecil termasuk homelab.

    Catatan: Proxmox merekomendasikan full mesh maksimal untuk 3 node. Kalau cluster kalian berencana lebih dari 3 node atau mau diekspansi ke depan, lebih baik langsung investasi switch sejak awal.

    Syarat

    Tiap node butuh minimal 2 NIC kosong (di luar NIC management/WAN), masing-masing terhubung ke salah satu node lain.

    Sebagai contoh, saya pakai penamaan dari dokumentasi resmi. Sesuaikan dengan punya kalian:

    • 3 node dengan IP storage .50, .51, .52 di subnet 10.15.15.0/24
    • ens18 dan ens19: untuk mesh, direct ke dua node lain
    • ens20: ke WAN/management lewat vmbr0
    • ens21 (opsional): LAN untuk corosync/cluster

    Koneksi fisiknya:

    • Node1/ens18 ke Node2/ens19
    • Node2/ens18 ke Node3/ens19
    • Node3/ens18 ke Node1/ens19

    Pilihan metode

    Ada 4 cara setup mesh di Proxmox. Singkatnya:

    MetodeKelebihanKekurangan
    Routed (simple)Performa terbaik, tanpa software tambahanKalau 1 link putus, antar node bisa kehilangan komunikasi
    Routed with fallback (OpenFabric/FRR)Performa mirip, tetap jalan kalau 1 link putus (dirouting lewat node tengah)Sedikit lebih kompleks
    RSTPTahan 1 link putus, recovery beberapa detikButuh Open vSwitch
    BroadcastPaling gampang di-setupBoros bandwidth (kirim ke 2 node sekaligus)

    Rekomendasi: routed with fallback pakai OpenFabric. Performanya bagus dan cluster tetap jalan kalau salah satu kabel atau NIC bermasalah. Mulai PVE 9, cara ini bisa dilakukan lewat GUI dengan fitur SDN Fabrics, jadi jauh lebih gampang dari sebelumnya.

    Cara 1: SDN Fabrics (PVE 9, direkomendasikan)

    Ini cara paling baru dan paling rapi karena semuanya lewat GUI.

    1. Buka Datacenter > SDN > Fabrics.
    2. Klik Add Fabric, lalu pilih protokol OpenFabric. Proxmox mendukung OSPF dan OpenFabric, tapi untuk setup sederhana seperti ini OpenFabric lebih gampang.
    3. Isi nama fabric, misalnya ceph. Lalu isi IPv4 prefix, misalnya 10.15.15.0/24. Prefix ini menentukan subnet untuk semua IP node di dalam fabric.
    4. Opsional, ubah Hello-Interval jadi 1 dan CSNP-Interval jadi 2. Angka lebih kecil bikin failover lebih cepat saat link putus, tapi traffic keep-alive jadi lebih banyak.
    5. Tambahkan node. Klik tombol + di baris fabric, pilih node, isi IPv4-nya (sekaligus jadi router-id), misalnya 10.15.15.50. Lalu pilih interface yang dipakai, di contoh ini ens18 dan ens19. Field lain biarkan kosong. Kalau interface tidak diberi IP, dia jalan di mode unnumbered, yaitu mewarisi IP dari node.
    6. Ulangi untuk semua node, .51 dan .52.
    7. Terakhir, buka Datacenter > SDN lalu klik Apply Configuration. Ini akan generate dan apply konfigurasi FRR di tiap node secara otomatis.

    Cek apakah fabric sudah converge lewat shell FRR:

    vtysh
show openfabric neighbor
show openfabric route

    Pasang Ceph di atas mesh

    Kalau pakai SDN Fabrics, instalasi Ceph normal saja. Pas langkah konfigurasi network awal, pilih fabric tadi dari dropdown jaringan yang tersedia. Selesai.

    Catatan untuk yang setup FRR manual: kalau IP dikonfigurasi di FRR dan bukan di /etc/network/interfaces, GUI Ceph tidak akan menampilkannya. Jadi inisialisasi Ceph lewat CLI:

    pveceph init --network 10.15.15.50/24
pveceph mon create

    Tambahkan opsi –cluster-network kalau cluster network mau dipisah ke subnet lain.

    Cara 2: Broadcast (paling simpel, via CLI)

    Kalau kalian mau yang paling cepat atau masih pakai versi PVE lama, broadcast bonding bisa jadi pilihan. Tinggal buat bond mode broadcast di tiap node. Contoh untuk Node1, edit /etc/network/interfaces:

    iface ens18 inet manual

iface ens19 inet manual

auto bond0
iface bond0 inet static
        address 10.15.15.50
        netmask 255.255.255.0
        slaves ens18 ens19
        bond_miimon 100
        bond_mode broadcast

    Lalu jalankan ifup bond0 atau reboot. Bisa juga lewat GUI: pilih node > System > Network > Create > Linux Bond, mode broadcast, tanpa gateway.

    Di konfigurasi Ceph, set Public Network dan Cluster Network ke subnet 10.15.15.0/24.

    Kekurangannya, broadcast mengirim semua data ke dua node sekaligus jadi boros bandwidth, dan kalau satu link putus node bisa kehilangan komunikasi. Untuk menambah toleransi, broadcast atau routed simple bisa dikombinasikan dengan bond, konsekuensinya butuh lebih banyak NIC dan kabel.

    Catatan untuk PVE 9

    Kalau kalian setup FRR manual (bukan lewat SDN Fabrics), mulai PVE 9 ada satu hal penting. Tambahkan cek kecil di post-up vmbr0 supaya tidak terjadi deadlock saat urutan start service. Contohnya:

    post-up /usr/bin/systemctl is-active --quiet frr.service && /usr/bin/systemctl restart frr.service || true

    Penutup

    Full mesh adalah cara paling hemat untuk dapat jaringan Ceph cepat di cluster 3 node tanpa beli switch mahal. Untuk pemakaian sekarang, saya sarankan langsung pakai SDN Fabrics dengan OpenFabric di PVE 9 karena paling rapi, tahan terhadap link putus, dan semuanya bisa dari GUI. Tapi sekali lagi, kalau cluster kalian berencana lebih dari 3 node, lebih baik pakai switch sejak awal.

    Referensi:

    dokumentasi resmi Proxmox VE, “Full Mesh Network for Ceph Server” (pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server).