Belajar Keepalived - LVS Integration & Load Balancing

#Pendahuluan

Keepalived bukan hanya mesin failover VIP; di dalamnya hidup subsistem LVS yang menjadikannya load balancer L4 murni di kernel Linux. Episode 6 membuka mode virtual_server: bagaimana satu VIP mendistribusikan traffic ke banyak backend, scheduler mana yang dipakai, dan bagaimana persistence menjaga sesi tetap lengket.

Di episode ini kalian akan menulis konfigurasi virtual_server yang lengkap, memilih lb_kind yang sesuai topologi, menambahkan health check per real server, dan memverifikasi hasilnya dengan ipvsadm. Ini adalah fondasi dari arsitektur HA load balancer frontend yang dijanjikan di episode 1.

#Anatomi virtual_server

#Blok Dasar

Blok virtual_server menghubungkan sebuah VIP dengan kumpulan real server:

virtual_server dasar

virtual_server 192.168.1.100 80 {
  delay_loop 6
  lb_algo rr
  lb_kind DR
  protocol TCP
  persistence_timeout 50
  real_server 10.0.0.11 80 {
    weight 1
    TCP_CHECK {
      connect_timeout 3
    }
  }
  real_server 10.0.0.12 80 {
    weight 1
    TCP_CHECK {
      connect_timeout 3
    }
  }
}

delay_loop: interval pengecekan backend dalam detik.
lb_algo: algoritma penjadwalan koneksi.
lb_kind: mode LVS, NAT, DR, atau TUN.
protocol: TCP atau UDP.
persistence_timeout: durasi sesi sticky dalam detik.

Blok virtual_server 192.168.1.100 80 membungkus dua real_server, masing-masing dengan health check TCP_CHECK yang memastikan port 80 benar-benar terbuka sebelum menerima traffic.

#Memilih lb_algo

Pilihan scheduler menentukan pola distribusi koneksi:

rr: round robin, merata untuk backend yang homogen.
wrr: weighted round robin, membagi sesuai weight.
lc: least connections, ke backend dengan koneksi paling sedikit.
wlc: weighted least connections, kombinasi weight dan beban.
sh: source hashing, backend dipilih dari hash alamat klien.
dh: destination hashing, cocok untuk cache dan proxy.

Untuk sebagian besar workload HTTP sederhana, rr atau wrr sudah cukup. lc dan wlc lebih adil saat durasi koneksi sangat bervariasi.

#Memilih lb_kind: NAT, DR, dan TUN

NAT: load balancer mengubah alamat sumber dan tujuan. Simpel tapi semua reply harus kembali lewat load balancer, jadi bisa menjadi bottleneck.
DR (direct routing): hanya request yang lewat load balancer; reply dikirim langsung dari backend. Backend harus punya VIP di interface loopback.
TUN: memakai tunneling IP-IP, cocok untuk backend lintas subnet.

Pilih DR untuk performa tinggi dengan backend di satu L2; pilih NAT saat simpel dan jumlah traffic kecil.

#Health Check untuk Backend

#TCP_CHECK dan HTTP_GET

LVS menyediakan beberapa tipe health check. Untuk layanan web, HTTP_GET lebih akurat daripada sekadar port:

HTTP_GET untuk backend

real_server 10.0.0.11 80 {
  weight 1
  HTTP_GET {
    url {
      path /healthz
      status_code 200
    }
    connect_timeout 3
    nb_get_retry 3
  }
}

Blok HTTP_GET meminta path /healthz dan hanya menganggap backend sehat jika responsnya 200. nb_get_retry 3 mengulang percobaan sebelum menyatakan backend gagal.

#Verifikasi dengan ipvsadm

Setelah daemon berjalan, periksa hasil di kernel:

Lihat tabel IPVS

sudo ipvsadm -L -n
sudo ipvsadm -L -n --stats

Output ipvsadm -L -n menampilkan VIP, real server, dan status weight. Bagian --stats memperlihatkan jumlah koneksi masuk dan keluar per backend, bukti traffic benar-benar terdistribusi.

#Persistence dan Sesi Lengket

persistence_timeout membuat koneksi dari klien yang sama selalu diarahkan ke backend yang sama dalam jendela waktu tertentu:

Persistence berbasis source

virtual_server 192.168.1.100 443 {
  delay_loop 6
  lb_algo wlc
  lb_kind DR
  protocol TCP
  persistence_timeout 600
  persistence_granularity 255.255.255.0
  real_server 10.0.0.11 443 {
    weight 2
    TCP_CHECK {
      connect_timeout 3
    }
  }
  real_server 10.0.0.12 443 {
    weight 1
    TCP_CHECK {
      connect_timeout 3
    }
  }
}

persistence_timeout 600 membuat sesi sticky selama 10 menit, dan persistence_granularity mengelompokkan klien per subnet sehingga hash lebih stabil. Untuk aplikasi yang menyimpan state di session server, parameter ini penting.

#Integrasi Failover dan Load Balancing

Keunggulan Keepalived adalah dua mode ini hidup berdampingan: vrrp_instance menjaga VIP, virtual_server mendistribusikan traffic. Saat satu node load balancer mati, VIP pindah ke node cadangan beserta seluruh konfigurasi IPVS-nya, sehingga klien tidak melihat gangguan.

Satu file, dua peran

vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}
 
virtual_server 192.168.1.100 80 {
  delay_loop 6
  lb_algo rr
  lb_kind DR
  protocol TCP
  real_server 10.0.0.11 80 {
    weight 1
    TCP_CHECK {
      connect_timeout 3
    }
  }
  real_server 10.0.0.12 80 {
    weight 1
    TCP_CHECK {
      connect_timeout 3
    }
  }
}

Konfigurasi vrrp_instance VI_1 dan virtual_server dalam satu file menghasilkan satu unit: failover VIP plus load balancing. Pastikan virtual_server hanya aktif di node yang menjadi MASTER.

#Penutup

Inti yang harus dibawa pulang:

virtual_server menggabungkan VIP dan kumpulan real server dalam satu blok.
lb_algo menentukan distribusi; pilih sesuai pola beban workload.
Mode DR unggul performa, NAT unggul kesederhanaan.
Health check backend memakai TCP_CHECK atau HTTP_GET per real server.
persistence_timeout membuat sesi klien tetap ke backend yang sama.
ipvsadm -L -n adalah jendela verifikasi tabel IPVS di kernel.

Di episode 7 selanjutnya kita membahas logging dan troubleshooting — level log Keepalived, integrasi syslog, teknik mendebug perubahan state VRRP dan failover IP, serta langkah-langkah menyelesaikan failure mode yang paling sering terjadi.