Episode ini membahas kesiapan menghadapi bencana: mencadangkan konfigurasi dan memulihkan state, menyusun kebijakan failback yang terkontrol, serta mengenali dan menangani split-brain dan jaringan yang terbelah.

High availability bukan hanya soal mencegah kegagalan, tapi juga soal bangkit setelah kegagalan. Episode 18 menyiapkan kalian untuk hari terburuk: mencadangkan konfigurasi, memulihkan node dengan cepat, memutuskan kapan mengembalikan VIP ke node asli, dan menghadapi skenario paling berbahaya — split-brain.
Split-brain terjadi saat dua node sama-sama menganggap dirinya MASTER. Tidak ada teknologi HA yang terbebas darinya sepenuhnya, tapi dengan desain yang benar, dampaknya bisa dibatasi. Episode ini memberi kalian strategi untuk mencegah, mendeteksi, dan memulihkan diri dari situasi tersebut.
keepalived.conf adalah aset paling berharga. Cadangkan secara berkala:
sudo tar czf /var/backups/keepalived-$(date +%F).tar.gz \
/etc/keepalived \
/etc/sysconfig/keepalivedPerintah tar czf /var/backups/keepalived-$(date +%F).tar.gz mengemas direktori konfigurasi beserta file environment service. Simpan arsip di luar node — ke object storage atau server backup — agar selamat saat node mati total.
Untuk pemulihan, cukup kembalikan arsip dan restart:
sudo tar xzf /var/backups/keepalived-2026-08-10.tar.gz -C /
sudo keepalived -t -f /etc/keepalived/keepalived.conf
sudo systemctl restart keepalivedUrutan keepalived -t lalu restart memastikan konfigurasi yang dipulihkan valid sebelum diaktifkan. Prosedur ini harus teruji, bukan hanya ditulis di dokumentasi.
Tabel IPVS hilang saat node mati. Jika perlu memulihkan struktur tanpa menunggu health check, cadangkan dengan ipvsadm:
sudo ipvsadm -S > /var/backups/ipvs-rules.txtOutput ipvsadm -S menghasilkan aturan yang bisa dimuat ulang dengan ipvsadm -R. Ini berguna untuk merekonstruksi tabel IPVS pada node pengganti.
Secara default, node MASTER asli yang kembali dengan priority lebih tinggi akan merebut VIP setelah preempt_delay. Failback otomatis ini nyaman tapi bisa berisiko jika layanan di node asli belum siap.
Jika kalian lebih suka failback manual dan terkontrol, gunakan nopreempt dan promosikan node dengan intervensi:
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 90
nopreempt
virtual_ipaddress {
192.168.1.100/24 dev eth0
}
}nopreempt membuat node asli tidak merebut VIP selama MASTER saat ini masih sehat. Failback dilakukan saat MASTER sengaja dimatikan, atau dengan me-restart Keepalived setelah memastikan layanan siap.
Prosedur failback yang disarankan:
Prosedur manual ini lebih lambat tapi jauh lebih aman daripada membiarkan preemption merebut VIP saat layanan belum panas.
Jika link antar node putus tapi keduanya tetap hidup, masing-masing akan menganggap dirinya satu-satunya MASTER. Kedua node memasang VIP yang sama, dan traffic terpecah secara tidak konsisten. Ini adalah skenario paling berbahaya dalam VRRP.
nopreempt dan tracking agar perebutan VIP tidak liar.Deteksi dini lewat log dan monitoring:
sudo journalctl -u keepalived --no-pager | grep "Entering MASTER STATE"Jika log journalctl -u keepalived menunjukkan dua node berbeda memasuki MASTER STATE pada waktu yang hampir bersamaan, waspadai split-brain. Konfirmasi dengan mengecek VIP di kedua node:
ssh lb02 "ip -brief addr show | grep 192.168.1.100"Jika VIP 192.168.1.100 muncul di dua node sekaligus, split-brain terjadi. Segera matikan salah satu node atau hentikan service-nya untuk memulihkan konsistensi.
Episode 18 menyiapkan kalian untuk yang terburuk: backup yang bisa dipulihkan dengan cepat, kebijakan failback yang terkontrol, dan strategi menghadapi split-brain dari desain hingga deteksi. HA kalian kini punya rencana pemulihan, bukan sekadar toleransi kegagalan.
Inti yang harus dibawa pulang:
keepalived.conf secara berkala ke lokasi di luar node.keepalived -t, lalu restart.nopreempt memberi kontrol penuh atas waktu failback.Di episode 19 selanjutnya kita membahas CI/CD dan configuration validation — memvalidasi konfigurasi Keepalived di pipeline CI, deploy otomatis dengan konfigurasi yang diversioning, serta preflight checks untuk failover HA sebelum rilis ke produksi.