Belajar MicroCloud - Troubleshooting

#Pendahuluan

Setelah enkripsi dan data protection di episode 15, kalian punya cloud yang aman. Tapi keamanan tidak berarti bebas masalah — node bisa gagal join, OSD bisa drop, dan cluster bisa degraded. Di episode 16 kita membangun toolkit troubleshooting: cara membaca status, menggali log, memecahkan kasus umum, dan memulihkan cluster saat sesuatu rusak.

Analogi yang pas: pilot tidak menunggu pesawat jatuh untuk belajar emergency checklist. Mereka menghafal prosedur sebelum masalah muncul, sehingga saat indikator merah menyala, tangannya sudah tahu apa yang harus dilakukan. Episode ini adalah emergency checklist kalian untuk MicroCloud — simpan, pahami, dan pakai saat cluster bertingkah aneh.

#Toolkit Debug: Status dan Log

#microcloud status

Perintah pertama yang harus kalian ingat adalah microcloud status — ia merangkum kesehatan seluruh tumpukan (LXD, Ceph, OVN) dalam satu layar:

Status keseluruhan MicroCloud

sudo microcloud status

Contoh output microcloud status

Clustering                   |  enabled
                           ...
MicroCloud services          |  MicroCloud, MicroCeph, MicroOVN, LXD
                            |  all running
LXD cluster                  |  3 members, all online
Ceph cluster                 |  HEALTH_OK
OVN cluster                  |  all online

Jika salah satu lapisan bermasalah, microcloud status biasanya menunjukkannya di sini — inilah titik awal selalu sebelum menyelam ke log.

#snap logs microcloud

microcloud status memberi tahu apa yang salah; log memberi tahu mengapa. Semua snap menyimpan log yang bisa dibaca dengan snap logs:

Log orkestrator microcloud

sudo snap logs microcloud -n 200

#microceph status dan microovn status

Untuk masalah storage, gali lebih dalam ke MicroCeph; untuk jaringan, ke MicroOVN:

Cek kesehatan Ceph

sudo microceph status
ceph -s

Cek status OVN

sudo microovn status
sudo snap logs microovn -n 200

#Log LXD dan Instance

LXD mencatat aktivitas cluster dan instance. Jika instance gagal start atau cluster "aneh", periksa log LXD:

Log daemon LXD

sudo snap logs lxd -n 200

Tip

Bangun urutan debug yang konsisten: microcloud status → log snap yang relevan → ceph -s/microovn status → log LXD. Jangan langsung menebak-nebak di tengah — data dulu, lalu diagnosis, baru aksi. Urutan ini menyelamatkan kalian dari perbaikan yang salah sasaran.

#Kasus Umum dan Solusinya

#Join Gagal

Join gagal adalah keluhan paling umum. Gejala: microcloud join di node baru berhenti dengan pesan token atau timeout. Penyebab yang paling sering:

Token kedaluwarsa: sejak 2.1.3, join token dibuat dengan masa berlaku default 1 jam (sebelumnya 5 menit). Jika join lama, buat token baru dari node pertama.
Hostname duplikat: node dengan hostname yang sudah dipakai akan ditolak — pastikan hostname unik (hostnamectl hostname).
Node tidak bisa saling menjangkau: verifikasi konektivitas dan port yang dibuka.

Diagnosis join gagal

hostnamectl hostname
ping -c 3 node-b
sudo microcloud status

#Disk Kecil

Gejala: OSD aktif tapi cluster HEALTH_WARN dengan near full atau data tidak bisa menyebar merata. Cek penggunaan dan lihat apakah ada OSD yang jauh lebih kecil dari saudaranya:

Cek ukuran dan penggunaan OSD

lsblk -d -o NAME,SIZE,TYPE
ceph osd df
ceph osd tree

Jika satu OSD FULL sementara yang lain lega, data tidak seimbang. Solusi jangka pendek adalah membiarkan rebalancing Ceph selesai; jangka panjang, tambahkan disk (episode 11) atau kurangi replikasi jika kapasitas memang terbatas.

#Network Underlay

Gejala: cluster sehat sebentar lalu member "hilang", atau trafik storage lambat. Masalah underlay — jaringan fisik tempat LXD/Ceph/OVN berkomunikasi — sering jadi biang keladi:

Cek latensi dan packet loss antar node

ping -c 5 node-a
mtr -n node-b

Periksa juga bahwa port antar node tidak diblokir firewall (episode 14 membahas segmen dan port kunci: 8443 LXD, 6789/6800-7300 Ceph, 6081 OVN tunnel).

Warning

Jangan pernah menutup port cluster antar sesama node dengan firewall. Node yang "hilang lalu muncul" berulang adalah gejala klasik packet loss atau latency tinggi di underlay — bukan masalah perangkat lunak MicroCloud. Verifikasi jaringan fisik dulu sebelum menyalahkan service.

#Clock Skew

LXD dan Ceph sangat sensitif terhadap selisih waktu antar node. Jika member tiba-tiba ditandai offline padahal jaringan sehat, curigai clock:

Cek sinkronisasi waktu

timedatectl status
chronyc sources -v

Semua node harus memakai sumber waktu yang sama (misal chrony) — selisih yang besar akan membuat certificate dan heartbeat LXD tidak valid.

#Recovery Member

#Keluarkan Member dengan Benar

Jika sebuah node rusak permanen dan harus keluar dari cluster, jangan menghapusnya hanya dari LXD — MicroCloud 2.x menyediakan perintah khusus yang membersihkan dari semua layanan sekaligus:

Keluarkan member dari seluruh layanan

sudo microcloud remove node-b

Jalankan dari node lain yang sehat, lalu verifikasi:

Verifikasi member terhapus

sudo microcloud status
lxc cluster list

#Maintenance Tanpa Menghapus

Untuk maintenance terencana — reboot, ganti hardware — kalian tidak perlu menghapus member. Gunakan evacuate untuk memindahkan semua instance dulu, lalu restore saat node kembali:

Evakuasi node untuk maintenance

lxc cluster evacuate node-b
# ... maintenance ...
lxc cluster restore node-b

#Re-init Service

Jika state sebuah snap korup dan tidak bisa dipulihkan, opsi terakhir adalah re-init: bersihkan semua snap lalu pasang ulang. Ini langkah nuklir — lakukan hanya saat benar-benar buntu:

Bersihkan instalasi MicroCloud di satu node

sudo snap remove microcloud --purge
sudo snap remove microovn --purge
sudo snap remove microceph --purge
sudo snap remove lxd --purge

Setelah bersih, install ulang (episode 3) lalu microcloud join kembali ke cluster. Proactive trust (episode 15) membantu node yang di-reinit ini join kembali tanpa gesekan.

#Pitfall Umum

Menghapus member dari satu layanan saja: meninggalkan sisa state di LXD/Ceph/OVN — selalu pakai microcloud remove.
Reboot tanpa evacuate: instance di storage local bisa hilang; instance Ceph di-reschedule tapi dengan downtime — evacuate dulu.
Mengabaikan log: microcloud status sehat tidak menjamin log bersih — baca log untuk masalah intermiten.
Re-init terlalu cepat: re-init menghapus data config node; pastikan backup (episode 10) tersedia sebelum langkah nuklir.
Menebak tanpa data: diagnosis berbasis data (status + log + cek jaringan) selalu lebih cepat daripada menebak.

#Penutup

Inti yang harus dibawa pulang:

Mulai debugging dari microcloud status, lalu gali log snap yang relevan.
Join gagal: cek token, hostname unik, dan konektivitas antar node.
Disk kecil dan data tidak seimbang: pantau ceph osd df dan biarkan rebalancing selesai.
Node "hilang" intermiten: curigai network underlay dan clock skew sebelum menebak software.
Recovery member pakai sudo microcloud remove <node>; maintenance pakai lxc cluster evacuate/restore.
Re-init service hanya sebagai jalan terakhir, dan hanya dengan backup yang sudah aman.

Di episode 17 selanjutnya kita akan membahas MicroCloud 3.2 & fitur terbaru — kompatibilitas LXD 6.8, perbaikan dan fitur di rilis feature 3.2 (April 2026), alasan 3.x belum direkomendasikan untuk upgrade dari 2 LTS, serta rilis 2.1.3 LTS untuk produksi dengan upgrade path resmi. Version matters!