Belajar Keepalived - Distributed HA Architectures

#Pendahuluan

Seiring traffic tumbuh, satu load balancer MASTER tidak lagi cukup. Episode 14 menaikkan skala arsitektur: membandingkan topologi active-active dan active-passive, membangun HA dengan banyak node load balancer, dan memahami konsekuensi failover untuk koneksi yang menyimpan state.

Keputusan arsitektur di episode ini menentukan kapasitas maksimal dan kesederhanaan operasional kalian. Tidak ada jawaban tunggal yang benar; yang ada adalah trade-off antara performa, kompleksitas, dan kesiapan menghadapi insiden.

#Active-Active vs Active-Passive

#Active-Passive: Sederhana dan Aman

Ini pola dasar yang sudah kalian pakai sejak episode 3: satu MASTER memegang semua VIP, node lain menunggu. Kelebihannya sederhana dan mudah dipahami; kekurangannya satu node menganggur, dan kapasitas dibatasi node tunggal.

#Active-Active: Memanfaatkan Semua Node

Dengan beberapa instance VRRP berprioritas berbeda, setiap node bisa menjadi MASTER untuk sebagian VIP:

vrrp_instance VI_WEB {
  state MASTER
  interface eth0
  virtual_router_id 80
  priority 110
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}
 
vrrp_instance VI_API {
  state BACKUP
  interface eth0
  virtual_router_id 81
  priority 90
  virtual_ipaddress {
    192.168.1.101/24 dev eth0
  }
}

Di node A, VI_WEB menjadi MASTER dan VI_API menunggu. Di node B, konfigurasi dibalik. Hasilnya: dua node memikul beban nyata, dan masing-masing menjadi cadangan bagi yang lain.

#Memilih Berdasarkan Beban

Pilih active-passive saat traffic masih muat di satu node dan kesederhanaan lebih berharga. Pilih active-active saat kapasitas node tunggal hampir tercapai atau saat kalian ingin membagi beban per layanan. Perlu diingat: active-active tetap harus bisa menampung seluruh beban di satu node saat yang lain mati.

#Keepalived dengan Banyak Node Load Balancer

#Tiga Node atau Lebih

VRRP tidak membatasi jumlah node. Tambah node ketiga dengan priority menengah sebagai lapisan pengaman:

lb01:  priority 110 (MASTER)
lb02:  priority 100 (BACKUP utama)
lb03:  priority 90  (BACKUP kedua)

Dengan prioritas di atas, kegagalan lb01 mengangkat lb02, dan kegagalan lb02 mengangkat lb03. Seluruh node berbagi virtual_router_id dan daftar VIP yang sama, dan setiap node menjalankan virtual_server yang identik.

#Konsistensi Konfigurasi

Kunci banyak node adalah konfigurasi yang identik pada blok VRRP dan LVS. Perbedaan kecil seperti satu real_server yang berbeda akan menghasilkan tabel IPVS yang berbeda dan lalu lintas yang tidak konsisten. Episode 11 mengajarkan cara memastikan ini dengan template dan drift control.

#Sinkronisasi Koneksi IPVS

#Masalah Tabel Koneksi

LVS menyimpan tabel koneksi di kernel node MASTER. Saat failover terjadi, node baru tidak tahu koneksi yang sedang berlangsung, sehingga sesi yang sudah jalan bisa terputus. Untuk layanan yang toleran re-connect, ini bisa diterima; untuk yang tidak, perlu sinkronisasi.

#Daemon Sinkronisasi IPVS

IPVS menyediakan daemon sinkronisasi untuk menyalin tabel koneksi antar node:

sudo ipvsadm --start-daemon primary --mcast-interface eth0
sudo ipvsadm --start-daemon backup --mcast-interface eth0

Perintah ipvsadm --start-daemon primary di node MASTER mengirim salinan tabel koneksi, dan ipvsadm --start-daemon backup di node lain menerimanya. Gabungkan dengan Keepalived lewat notify hooks agar daemon sinkronisasi ikut berpindah saat failover.

#Batasan Sinkronisasi

Sinkronisasi IPVS menyalin koneksi yang sedang aktif, bukan state aplikasi. Jika sesi disimpan di backend (session cookie, JWT), sinkronisasi IPVS tidak diperlukan. Jika state ada di memori load balancer, pertimbangkan menyimpan state di backend atau memakai mekanisme sticky session yang ketat.

#Pertimbangan Stateful Failover

#Menempatkan State di Backend

Cara paling tahan banting: pindahkan state dari load balancer ke backend. Dengan session backend atau stateless JWT, node load balancer mana pun bisa melayani sesi apa pun, dan failover menjadi mulus tanpa sinkronisasi apa pun.

#Pemisahan Peran dengan vrrp_sync_group

Jika satu layanan menyimpan state sementara yang lain tidak, pisahkan instance-nya. Grupkan instance yang stateful dengan vrrp_sync_group agar selalu berpindah bersama, dan biarkan instance stateless bergerak independen. Pemisahan ini membuat kegagalan tidak menyebar lebih jauh dari yang perlu.

#Penutup

Episode 14 memperluas arsitektur kalian dari pasangan menjadi klaster: active-active dengan prioritas per instance, banyak node load balancer yang saling menopang, sinkronisasi koneksi IPVS untuk sesi yang sedang berjalan, dan strategi menempatkan state agar failover tetap mulus.

Inti yang harus dibawa pulang:

• Active-passive sederhana; active-active memanfaatkan semua node.
• Active-active harus tetap mampu menampung seluruh beban di satu node.
• Banyak node berbagi virtual_router_id dan konfigurasi LVS yang identik.
• ipvsadm --start-daemon menyinkronkan tabel koneksi antar node.
• Sinkronisasi IPVS tidak menggantikan state aplikasi.
• Simpan state di backend agar failover benar-benar mulus.

Di episode 15 selanjutnya kita membahas performance tuning dan latency reduction — menyetel advert_int dan timing election, memahami skew time dan master down interval, serta menyesuaikan daemon untuk HA skala besar dengan failover berlatensi rendah.