Belajar MicroCloud - Performance & Capacity Planning

#Pendahuluan

Episode 17 menegaskan pilihan jalur rilis. Tapi versi tidak menentukan kecepatan — hardware dan konfigurasi yang melakukannya. Di episode 18 kalian belajar dua hal yang sering tertukar: tuning (membuat yang sudah ada seoptimal mungkin) dan capacity planning (menghitung kebutuhan sebelum membeli). Cloud yang cepat dimulai dari lembar perhitungan, bukan dari keberuntungan.

Analogi: membeli mobil sport tidak membuat kalian pemenang balapan. Pilihan ban, bahan bakar, dan jalur — ditambah perhitungan berapa liter yang dibutuhkan untuk 500 km — itulah yang menentukan. MicroCloud kalian adalah mobil sport itu; episode ini adalah pit-stop engineer-nya.

#Tuning Hardware

#Disk: NVMe untuk OSD

Storage adalah jantung MicroCloud. Semua I/O instance — volume, snapshot, replikasi Ceph — melewati OSD. Rekomendasinya tegas:

• NVMe untuk OSD adalah pilihan terbaik untuk performa. Latensi sub-milidetik dan IOPS tinggi membuat replikasi Ceph (3 salinan) terasa ringan.
• SSD SATA/SAS masih layak untuk workload menengah.
• HDD hanya untuk arsip/kapasitas murni — siapkan penurunan latensi dan throughput.

lsblk -d -o NAME,ROTA,SIZE,TRAN,MODEL

Baris dengan ROTA=0 dan TRAN=nvme adalah target OSD yang ideal.

#Jaringan: 10GbE

Jaringan underlay menentukan seberapa cepat data replikasi dan trafik instance bergerak antar node:

• Minimum serius: 1GbE untuk lab kecil, dengan penurunan throughput.
• Rekomendasi produksi: 10GbE antar node — replikasi Ceph dan live migration berjalan lancar tanpa menjadi bottleneck.
• Latensi rendah: pastikan switch tidak overload; jangan biarkan trafik storage bercampur dengan trafik publik tanpa perencanaan segmen (episode 14).

#Tuning Ceph

#Pool Size dan Replikasi

Ceph pool punya parameter yang menentukan keseimbangan antara ketersediaan dan kapasitas:

• Size (faktor replikasi): berapa salinan data. MicroCloud default 3 — tahan kehilangan 2 OSD/node. size=2 menghemat ruang tapi hanya tahan 1 kegagalan.
• Min_size: salinan minimum agar pool tetap menerima tulis. Default umum 2 untuk size=3 — cluster masih menulis walau satu salinan down.

Cek konfigurasi pool:

ceph osd pool ls detail

#Placement Groups (PG)

PG membagi data menjadi unit yang didistribusikan ke OSD. Jumlah PG yang tepat membuat data tersebar merata tanpa memboroskan resource:

• Terlalu sedikit PG: distribusi tidak merata, OSD kelebihan beban.
• Terlalu banyak PG: overhead memory dan recovery naik.

Panduan umum: ±100 PG per OSD adalah titik yang wajar. Rumus praktis per pool:

PG = (jumlah OSD × 100) / jumlah pool

MicroCeph biasanya menetapkan default yang masuk akal saat init. Intervensi manual hanya saat skala berubah signifikan (episode 11).

ceph osd pool get rbd pg_num
ceph osd pool get rbd pgp_num

#Capacity Planning

#Menghitung Kapasitas dengan Replika 3

Kapasitas usable tidak sama dengan kapasitas mentah. Dengan replikasi 3, tiap byte data disimpan 3 kali:

usable = total raw disk / size
 
contoh: 3 node × 1TB NVMe = 3TB raw
        size=3 → usable = 3TB / 3 = 1TB
        size=2 → usable = 3TB / 2 = 1.5TB

Tambahkan overhead lain:

• Bluestore/Ceph overhead: sekitar 2-3% ruang per OSD.
• Headroom operasional: jaga penggunaan pool di bawah ±80% agar rebalance dan recovery punya ruang bernapas.

#Sizing Node: 3-50 Node

MicroCloud dirancang untuk 3-50 node — fleksibel dari homelab hingga edge fleet menengah:

• 3 node (minimum produksi): HA penuh — replikasi 3, kehilangan 1 node tidak mematikan layanan. Kandidat sempurna untuk percontohan HA (episode 9).
• 3-9 node: skala kecil-menengah; tambah OSD dan node seiring kebutuhan (episode 11).
• 10-50 node: edge fleet / multi-site; pertimbangkan MicroCloud Cluster Manager untuk observability lintas cluster (episode 12) dan perencanaan jaringan yang matang (episode 14).

Node A ─┐
Node B ─┼─► 3× 2TB NVMe OSD ─► 6TB raw ─► ±2TB usable (size 3)
Node C ─┘

#Workload sebagai Masukan Utama

Jangan mulai dari hardware, mulai dari workload:

1. Berapa instance dan berapa vCPU/RAM rata-rata per instance?
2. Berapa storage per instance plus snapshot?
3. Berapa throughput jaringan yang dibutuhkan?

Dari sana tentukan jumlah node, tipe disk, dan link jaringan. Kalkulasi ini menjadi dasar checklist produksi di episode 22.

#Pitfall Umum

• HDD untuk OSD produksi: latensi tinggi menghambat replikasi 3 — gunakan NVMe/SSD.
• NVMe tanpa 10GbE: bottleneck pindah ke jaringan.
• Menambah PG tanpa maintenance: rebalance besar mengguncang cluster — rencanakan jendela.
• Menghitung kapasitas tanpa replika: 3TB raw tidak sama dengan 3TB usable bila size=3.
• Fill ratio mendekati 100%: Ceph akan menolak tulis sebelum penuh — sisakan headroom minimal 20%.
• Size 2 untuk menghemat: hemat ruang, tapi kehilangan satu node bisa menghentikan tulis — ketahui konsekuensinya.

#Penutup

Inti yang harus dibawa pulang:

• NVMe untuk OSD + 10GbE underlay adalah kombinasi produksi yang disarankan.
• Tuning Ceph: size=3, min_size=2, PG ±100/OSD — ukur sebelum mengubah.
• Kapasitas usable = raw ÷ size; sisakan overhead Bluestore dan headroom minimal 20%.
• 3 node minimum untuk HA; MicroCloud mendukung hingga 50 node.
• Mulai dari workload, bukan hardware — hitung dulu, beli kemudian.

Di episode 19 selanjutnya kita membahas ekosistem: Ubuntu Pro & LXD — dukungan komersial Ubuntu Pro (LTS eligibility, LXD 5.21/6.x, auto-attach guest) serta integrasi tooling: Ansible inventory dan connection plugin LXD, Terraform provider, dan Packer builder. Kalian akan melihat MicroCloud sebagai bagian dari ekosistem automation yang lebih luas!