Belajar MicroCloud - High Availability & Failover

#Pendahuluan

Di episode 8 kita deploy instance dan VM. Tapi cloud yang andal bukan sekadar mampu menjalankan workload — ia harus bertahan ketika ada node yang mati. Di episode 9 kita menguji high availability: bagaimana LXD cluster menjadwalkan ulang instance, bagaimana Ceph menjaga data, dan bagaimana kalian memverifikasi recovery otomatis lewat simulasi node down.

Analogi yang pas: HA adalah regenerasi koloni semut. Jika satu semut (node) mati, koloni (cluster) tidak panik — pekerja (instance) yang kehilangan sarangnya dipindahkan, cadangan makanan (replikasi Ceph) tetap tersimpan di sarang lain, dan ratu (quorum) memastikan keputusan tetap valid. Yang kalian pelajari hari ini adalah cara kerja "naluri" koloni ini secara teknis.

#Mekanisme HA di MicroCloud

#Dua Lapisan Perlindungan

HA MicroCloud bekerja di dua lapisan yang saling melengkapi:

1. LXD cluster — instance yang scheduled bisa dipindahkan ke node lain saat node asalnya mati.
2. MicroCeph — data instance direplikasi ke node lain, sehingga begitu instance dipindahkan, disk-nya sudah tersedia di node tujuan.

node-a down ──► LXD: mark offline, reschedule instance
                Ceph: salinan data tetap ada di node-b/c
                OVN: IP instance tetap valid via overlay

Tanpa salah satu lapisan, HA tidak lengkap: LXD bisa memindahkan instance tapi tidak ada data di tujuan (storage local), atau Ceph aman tapi instance tidak otomatis dijadwalkan ulang.

#Mengapa 3 Node?

LXD cluster memakai quorum untuk mengambil keputusan. Dengan 3 node:

• 1 node mati → masih ada quorum (2/3) → cluster tetap berjalan dan memutuskan failover.
• 2 node mati → tidak ada quorum → cluster berhenti mengambil keputusan untuk menghindari split-brain.

Angka ganjil (3, 5) dipilih agar toleransi kegagalan maksimal: 3 node toleran 1 kegagalan, 5 node toleran 2 kegagalan. Inilah mengapa "cloud di dalam 3 node" adalah angka ajaib MicroCloud.

#Simulasi Node Down

#Menyiapkan Instance yang Tahan Failover

Sebelum men-simulasikan kegagalan, pastikan instance memakai storage Ceph (pool remote) dan network OVN:

lxc list
lxc config show c1 | grep -E "pool|network"

Semua instance yang ingin kita uji harus berbasis Ceph. Instance di storage local akan ikut mati bersama node-nya — ini perilaku yang disengaja.

#Menjatuhkan Node

Simulasikan kegagalan dengan mematikan salah satu node tempat instance berjalan. Dari node lain atau host fisik:

sudo poweroff

Atau untuk simulasi yang lebih halus, hanya hentikan daemon LXD-nya:

sudo snap stop lxd

#Mengamati Recovery

Dari node-a, amati bagaimana cluster merespons:

lxc cluster list

+--------+---------+----------------------+--------+-----------+---------+
|  NAME  |  STATUS |        ADDRESS       | ROLES  | MESSAGE   | ...
+--------+---------+----------------------+--------+-----------+---------+
| node-a | ONLINE  | 192.168.1.10:8443    | leader |           |
| node-b | OFFLINE | 192.168.1.11:8443    |        | Unavailable |
| node-c | ONLINE  | 192.168.1.12:8443    |        |           |
+--------+---------+----------------------+--------+-----------+---------+

LXD menandai node-b sebagai OFFLINE dan mulai menjadwalkan ulang instance yang bisa dipindahkan:

lxc list

Instance yang tadinya LOCATION: node-b akan muncul dengan status STOPPED lalu dijadwalkan ke node-c atau node-a (untuk container system; VM dengan config tertentu bisa di-migrate stateful). Data tetap utuh karena tersimpan di Ceph.

#Memulihkan Node

#Node Kembali Online

Saat node-b hidup kembali, LXD cluster mendeteksinya dan menandainya ONLINE lagi:

lxc cluster list

Ceph juga menyembuhkan dirinya sendiri — OSD node-b yang kembali akan ikut mereplikasi ulang data yang hilang (recovery). Selama proses ini, ceph -s menampilkan recovery dan HEALTH_WARN sementara.

ceph -s

#Verifikasi Data Tidak Hilang

lxc list
lxc exec c1 -- df -h /

Seluruh instance harus tetap hidup dengan data utuh — bukti bahwa replikasi Ceph bekerja.

#Latihan HA yang Disarankan

Rangkaian latihan yang sebaiknya kalian lakukan di lab:

1. Container di storage Ceph → matikan node-nya → amati reschedule otomatis.
2. VM → matikan node-nya → amati restart VM di node lain.
3. VM live migration → lxc move --target saat node masih hidup → amati zero-downtime.
4. Dua node mati sekaligus → amati bahwa cluster tidak mengambil keputusan (tidak ada quorum) → nyalakan satu node → cluster pulih.

Latihan nomor 4 paling penting dipahami: kehilangan quorum menghentikan keputusan, bukan menghancurkan data. Setelah node kembali, cluster memulihkan diri.

#Pitfall Umum

• Instance di storage local ikut mati: itu wajar — untuk HA gunakan pool Ceph.
• Cluster "stuck" saat node mati: jika dua dari tiga node mati, tunggu salah satu kembali; jangan inisialisasi ulang di tengah jalan.
• Migrasi VM gagal karena resources: node tujuan harus punya cukup CPU/RAM; periksa lxc info --resources per node.
• Menganggap recovery instan: reschedule dan recovery Ceph butuh waktu (menit, tergantung ukuran data) — bukan detik.

#Penutup

Inti yang harus dibawa pulang:

• HA = LXD reschedule instance + Ceph replikasi data + OVN menjaga IP.
• 3 node memberi toleransi 1 kegagalan; quorum menjaga keputusan tetap valid.
• Instance berbasis Ceph otomatis dijadwalkan ulang saat node-nya down.
• Ceph menyembuhkan dirinya sendiri saat node kembali (recovery).
• Selalu latih skenario node down sebelum membawa cloud ke production.

Di episode 10 selanjutnya kita akan membahas snapshot, backup & restore — lxc snapshot c1 snap1, snapshot storage pool, snapshot RBD di Ceph, lxc export/import, serta integrasi backup seperti restic dan Proxmox Backup Server di dalam VM. Data kalian akan punya jaring pengaman!