Belajar Keepalived - Health Check Advanced Patterns

#Pendahuluan

Health check sederhana seperti killall -0 hanya menjawab satu pertanyaan: apakah proses hidup? Episode 16 naik kelas: health check yang memahami layanan benar-benar, deteksi kegagalan yang bertingkat dan tidak gegabah, serta integrasi dengan restart dan alerting agar operator tahu sebelum klien mengeluh.

Ini adalah lapisan yang memisahkan HA yang berfungsi di demo dari HA yang bertahan di produksi. Kita akan memakai tipe health check lengkap Keepalived — TCP_CHECK, HTTP_GET, SSL_GET, MISC_CHECK — dan menyusun pola yang menyeimbangkan kecepatan deteksi dengan ketahanan terhadap flapping.

#Health Check untuk Layanan Eksternal

#HTTP_GET dengan Body Check

HTTP_GET bisa memverifikasi lebih dari sekadar status code, misalnya isi respons:

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

Blok HTTP_GET memeriksa bahwa /healthz mengembalikan 200, dengan nb_get_retry 3 untuk mengulang percobaan sebelum menyatakan gagal.

#SSL_GET untuk Layanan HTTPS

Untuk backend HTTPS, gunakan SSL_GET. Sintaksnya sama dengan HTTP_GET, dan Keepalived memakai OpenSSL untuk handshake:

real_server 10.0.0.12 8443 {
  weight 1
  SSL_GET {
    url {
      path /healthz
      status_code 200
    }
    connect_timeout 3
    nb_get_retry 2
  }
}

SSL_GET memastikan layanan tidak hanya membuka port, tapi benar-benar menyelesaikan TLS handshake sebelum dinilai sehat.

#Deteksi Kegagalan Bertingkat dengan rise dan fall

#Histeresis di vrrp_script

Di level instance, rise dan fall mencegah perubahan status yang terlalu reaktif:

vrrp_script chk_app {
  script "/etc/keepalived/checks/check-app.sh"
  interval 2
  weight -30
  rise 2
  fall 4
}

fall 4 berarti script harus gagal 4 kali berturut-turut sebelum priority diturunkan, dan rise 2 berarti harus sukses 2 kali sebelum status dinyatakan pulih. Pola ini menyerap gangguan sesaat seperti GC pause atau restart singkat tanpa memindahkan VIP.

#Tingkatan Weight Berlapis

Untuk penalti bertingkat, jalankan beberapa script dengan weight berbeda:

vrrp_script chk_port {
  script "/usr/bin/killall -0 nginx"
  interval 2
  weight -10
}
 
vrrp_script chk_api {
  script "/etc/keepalived/checks/check-api.sh"
  interval 2
  weight -30
}

Kegagalan chk_port menurunkan priority 10, sedangkan chk_api menurunkannya 30. Semakin dalam kerusakan, semakin besar penalti — hingga node lain akhirnya mengambil alih.

#Pola Restart Otomatis Layanan

#Restart Sebelum Failover

Sebelum menyerahkan VIP ke node lain, coba pulihkan dulu layanan di tempat. Script health check bisa menangani ini:

#!/usr/bin/env bash
if ! systemctl is-active --quiet myapp; then
  systemctl restart myapp
  sleep 3
fi
systemctl is-active --quiet myapp

Script systemctl is-active --quiet myapp mengembalikan exit code 0 hanya jika layanan aktif. Jika tidak, dia restart dulu lalu periksa ulang. Keepalived menilai kesehatan dari exit code final script.

#Membedakan Down Total dan Degradasi

Pastikan script membedakan kondisi fatal dari yang bisa dipulihkan: gunakan exit code non-zero yang berbeda, lalu di vrrp_script atur weight negatif yang lebih besar untuk kegagalan total. Dengan begitu, degradasi ringan cukup menurunkan priority sedikit tanpa memicu failover yang tidak perlu.

#Integrasi dengan Monitoring Alerts

#Notify ke Alerting

Hubungkan transisi state ke sistem alerting lewat notify hooks:

#!/usr/bin/env bash
STATE="${1:-}"
curl -fsS -X POST http://alertmanager:9093/api/v2/alerts \
  -H 'Content-Type: application/json' \
  -d "[{\"labels\":{\"alertname\":\"KeepalivedFailover\",\"node\":\"$(hostname)\",\"state\":\"$STATE\"}}]" || true

Perintah curl -fsS -X POST http://alertmanager:9093/api/v2/alerts mengirim alert ke Alertmanager setiap kali state berubah. Pasang script ini sebagai notify_master dan notify_backup agar setiap failover langsung terlihat.

#Verifikasi dari Sisi Health Check

Untuk memantau apakah kesehatan sudah benar, tes langsung dari baris perintah:

curl -fsS http://10.0.0.11:8080/healthz
echo $?

Output curl -fsS http://10.0.0.11:8080/healthz yang sukses menandakan backend sehat. Bandingkan hasil ini dengan penilaian Keepalived di log untuk memastikan health check kalian menggambarkan kondisi nyata.

#Penutup

Episode 16 menyempurnakan radar deteksi kalian: health check yang memahami layanan lewat HTTP_GET, SSL_GET, dan MISC_CHECK, deteksi bertingkat dengan rise dan fall, pola auto restart yang mengurangi failover yang tidak perlu, dan integrasi alerting yang membuat operator selalu tahu lebih dulu.

Inti yang harus dibawa pulang:

• HTTP_GET dan SSL_GET memeriksa aplikasi, bukan hanya port.
• rise dan fall menyerap gangguan sesaat tanpa memindahkan VIP.
• Weight berlapis membuat penalti sebanding dengan keparahan.
• Script health check bisa melakukan auto restart sebelum failover.
• Notify hooks menghubungkan transisi state ke Alertmanager.
• Uji health check dengan curl dan bandingkan dengan log Keepalived.

Di episode 17 selanjutnya kita membahas Keepalived di container dan virtual environments — menjalankan Keepalived di Docker dengan host networking, pola DaemonSet di Kubernetes, perhatian pada network namespace dan VIP, serta contoh stack HAProxy plus Keepalived berbasis container.