Panduan Install Keepalived VRRP di Debian 13 dengan 3 Node HAProxy untuk High Availability dan Failover Otomatis

Dalam infrastruktur server modern, ketersediaan layanan menjadi salah satu faktor penting yang menentukan kualitas sebuah sistem. Website, aplikasi bisnis, portal pendidikan, API, dan layanan internal perusahaan harus tetap dapat diakses meskipun salah satu server mengalami gangguan.

Salah satu masalah yang sering muncul adalah single point of failure (SPOF), yaitu kondisi ketika sebuah komponen menjadi titik kegagalan tunggal. Sebagai contoh, sebuah aplikasi telah menggunakan beberapa backend server untuk membagi beban trafik, tetapi seluruh trafik tetap melewati satu server HAProxy. Jika server HAProxy tersebut mengalami kerusakan, layanan tetap tidak dapat diakses meskipun seluruh backend sebenarnya masih berjalan normal.

Untuk mengatasi masalah tersebut, administrator dapat menggabungkan HAProxy dan Keepalived menggunakan protokol VRRP (Virtual Router Redundancy Protocol).

HAProxy bertugas mendistribusikan trafik ke beberapa backend server. Sementara itu, Keepalived mengelola mekanisme redundansi alamat IP virtual melalui VRRP sehingga alamat layanan dapat berpindah ke node lain ketika node yang aktif mengalami kegagalan.

Dalam tutorial ini, kita akan membangun arsitektur high availability menggunakan tiga node Debian 13 Server. Ketiga node menjalankan HAProxy dan Keepalived, dengan satu node aktif sebagai pemilik Virtual IP (VIP) dan dua node lainnya bertindak sebagai kandidat pengambil alih.

Panduan ini mencakup perencanaan topologi, instalasi paket, konfigurasi HAProxy, konfigurasi VRRP, integrasi pemeriksaan kesehatan layanan, pengujian failover, serta troubleshooting.

1. Memahami Arsitektur HAProxy dan Keepalived

Apa itu HAProxy?

HAProxy merupakan perangkat lunak load balancer dan proxy yang dapat mendistribusikan koneksi masuk ke beberapa server tujuan. HAProxy mendukung berbagai skenario, termasuk load balancing HTTP, HTTPS, dan TCP.

Contohnya, sebuah website mempunyai tiga backend server. Daripada mengarahkan seluruh trafik ke satu server, HAProxy dapat mendistribusikan koneksi ke ketiga backend berdasarkan algoritma yang dipilih.

Manfaat HAProxy antara lain:

• Membagi trafik ke beberapa backend server.
• Memeriksa ketersediaan backend menggunakan health check.
• Mengurangi ketergantungan terhadap satu backend.
• Mendukung terminasi TLS dan pengaturan trafik TCP maupun HTTP.
• Menyediakan statistik untuk membantu pemantauan layanan.

Namun, HAProxy yang hanya berjalan pada satu node belum menghilangkan risiko kegagalan load balancer itu sendiri.

Apa itu Keepalived?

Keepalived merupakan perangkat lunak untuk mendukung high availability pada Linux. Salah satu fitur utamanya adalah implementasi VRRP, yang memungkinkan beberapa node berpartisipasi dalam kepemilikan alamat IP virtual.

VIP adalah alamat IP yang digunakan klien untuk mengakses layanan. Alamat ini berbeda dari IP fisik setiap node.

Misalnya, klien mengakses layanan melalui alamat 192.168.10.100. Alamat tersebut merupakan VIP yang pada kondisi normal dimiliki oleh node pertama. Jika node pertama gagal dan kegagalannya terdeteksi oleh mekanisme pemantauan, node kedua dapat mengambil alih VIP tersebut.

Klien tetap menggunakan alamat layanan yang sama. Mereka tidak perlu mengetahui perubahan node yang memegang VIP.

Mengapa HAProxy perlu diintegrasikan dengan Keepalived?

Kedua komponen tersebut memiliki fungsi berbeda dan saling melengkapi.

Komponen	Fungsi utama
HAProxy	Menerima dan mendistribusikan trafik ke backend
Keepalived	Mengelola kepemilikan VIP dan pemilihan node aktif
VRRP	Mengatur pemilihan pemilik VIP dan mekanisme failover
Health check	Memeriksa kondisi backend atau proses HAProxy
Backend server	Menjalankan aplikasi atau layanan yang diakses pengguna

Dengan desain ini, kegagalan salah satu node load balancer tidak harus menyebabkan layanan berhenti total.

Perlu dipahami bahwa VRRP menyediakan redundansi kepemilikan alamat IP, bukan replikasi konfigurasi. Ketiga node tetap harus memiliki konfigurasi HAProxy yang konsisten.

2. Topologi Jaringan Tiga Node

Topologi yang digunakan dalam tutorial ini terdiri atas tiga node load balancer dan tiga backend server.

Spesifikasi lingkungan laboratorium

Gunakan jaringan lokal yang sama untuk ketiga node Keepalived agar komunikasi VRRP dapat berlangsung secara langsung.

Node	IP Address	Peran
LB1	192.168.10.11/24	Prioritas tertinggi
LB2	192.168.10.12/24	Kandidat failover pertama
LB3	192.168.10.13/24	Kandidat failover kedua
VIP	192.168.10.100/24	Alamat layanan bersama
Backend 1	192.168.20.11	Web server pertama
Backend 2	192.168.20.12	Web server kedua
Backend 3	192.168.20.13	Web server ketiga

Contoh ini mengasumsikan jaringan frontend 192.168.10.0/24 dan jaringan backend 192.168.20.0/24 sudah memiliki konektivitas yang benar.

Ganti seluruh alamat IP sesuai dengan topologi jaringan yang digunakan. Pastikan VIP belum digunakan oleh perangkat lain dan ketiga node LB berada pada segmen Layer 2 yang mendukung perpindahan VIP.

Diagram alur trafik

                 CLIENT
                    |
                    |
            VIP 192.168.10.100
                    |
          +---------+---------+
          |         |         |
       +------+  +------+  +------+
       | LB1  |  | LB2  |  | LB3  |
       | HAProxy  | HAProxy  | HAProxy
       | VRRP |  | VRRP |  | VRRP |
       +------+  +------+  +------+
          |         |         |
          +---------+---------+
                    |
             Backend Network
                    |
         +----------+----------+
         |          |          |
      +------+   +------+   +------+
      | WEB1 |   | WEB2 |   | WEB3 |
      +------+   +------+   +------+

Diagram tersebut menunjukkan hubungan logis antara ketiga node load balancer dan backend. Pada kondisi normal, hanya satu node yang memegang VIP. Node lain tetap menjalankan layanan dan siap mengambil alih.

Trafik klien masuk melalui VIP, kemudian HAProxy pada node pemilik VIP meneruskannya ke backend yang tersedia.

Bagaimana proses failover bekerja?

Dalam kondisi normal:

1. LB1 mempunyai prioritas VRRP tertinggi.
2. LB1 menjadi pemilik VIP 192.168.10.100.
3. Klien mengirimkan permintaan ke VIP.
4. HAProxy pada LB1 meneruskan permintaan ke backend.
5. LB2 dan LB3 tetap aktif sebagai kandidat failover.

Ketika LB1 mengalami kegagalan yang terdeteksi:

1. LB1 berhenti mengirimkan iklan VRRP atau health check HAProxy menunjukkan kegagalan lokal.
2. Keepalived pada node kandidat menentukan bahwa LB1 tidak lagi memenuhi kondisi MASTER.
3. LB2, sebagai kandidat dengan prioritas tertinggi yang masih tersedia, mengambil alih VIP.
4. Trafik baru masuk ke HAProxy pada LB2.

Jika LB2 kemudian gagal, LB3 dapat mengambil alih selama node tersebut sehat dan memenuhi kondisi pemilihan VRRP.

Waktu perpindahan tidak selalu seketika. Durasi failover dipengaruhi interval VRRP, mekanisme health check, kondisi jaringan, dan waktu konvergensi ARP.

3. Persiapan Debian 13 Server

Sebelum memulai konfigurasi, pastikan ketiga node menggunakan Debian 13 Server dan memiliki koneksi jaringan yang berfungsi.

Langkah 1: Perbarui sistem

Jalankan perintah berikut pada masing-masing node:

sudo apt update
sudo apt upgrade -y

Perbarui indeks paket dan instal pembaruan sistem yang tersedia. Pada server produksi, lakukan pembaruan sesuai prosedur pemeliharaan yang telah ditetapkan.

Langkah 2: Verifikasi alamat IP

Jalankan:

ip -br address
ip route

Pastikan LB1, LB2, dan LB3 memiliki alamat IP yang sesuai dengan tabel topologi.

Periksa juga nama antarmuka jaringan:

ip -br link

Contoh nama antarmuka adalah ens18, enp1s0, atau eth0. Nama aktual dapat berbeda pada setiap instalasi.

Langkah 3: Uji konektivitas antar-node

Dari LB1, uji koneksi menuju LB2 dan LB3:

ping -c 4 192.168.10.12
ping -c 4 192.168.10.13

Uji pula koneksi ke seluruh backend:

ping -c 4 192.168.20.11
ping -c 4 192.168.20.12
ping -c 4 192.168.20.13

Jika ping gagal, periksa konfigurasi IP, routing, VLAN, firewall, dan konektivitas fisik atau virtual sebelum melanjutkan.

Perlu diingat bahwa kegagalan ping tidak selalu berarti layanan HTTP tidak tersedia. Beberapa sistem memang memblokir ICMP.

4. Instalasi HAProxy dan Keepalived

Instal kedua paket pada LB1, LB2, dan LB3.

sudo apt update
sudo apt install -y haproxy keepalived curl

Verifikasi versi paket:

haproxy -vv
keepalived --version

Aktifkan layanan agar berjalan otomatis saat boot:

sudo systemctl enable haproxy keepalived

Untuk sementara, kita akan menyelesaikan konfigurasi HAProxy sebelum mengaktifkan Keepalived.

Catatan: jangan mengasumsikan bahwa paket yang terpasang pada ketiga node selalu memiliki versi yang sama. Gunakan repositori Debian yang sesuai dan periksa kompatibilitas sintaks konfigurasi.

5. Konfigurasi HAProxy pada Tiga Node

HAProxy harus memiliki konfigurasi yang konsisten pada LB1, LB2, dan LB3. Dengan demikian, node yang mengambil alih VIP dapat langsung melayani trafik menggunakan konfigurasi yang sama.

Langkah 1: Siapkan halaman uji pada backend

Jika belum memiliki aplikasi backend, gunakan web server sederhana untuk pengujian.

Pada backend pertama, instal Nginx:

sudo apt update
sudo apt install -y nginx

Ganti halaman default dengan identitas backend:

echo "Backend WEB1 - 192.168.20.11" \
  | sudo tee /var/www/html/index.html

Lakukan hal serupa pada backend kedua dan ketiga, dengan teks WEB2 dan WEB3.

Pastikan Nginx berjalan:

sudo systemctl enable --now nginx

Verifikasi akses HTTP dari node load balancer:

curl -i http://192.168.20.11/
curl -i http://192.168.20.12/
curl -i http://192.168.20.13/

Jika respons HTTP tidak diterima, periksa firewall dan status Nginx pada backend.

Langkah 2: Cadangkan konfigurasi HAProxy

Pada setiap load balancer, simpan salinan konfigurasi awal:

sudo cp /etc/haproxy/haproxy.cfg \
  /etc/haproxy/haproxy.cfg.bak

Langkah 3: Konfigurasikan HAProxy

Edit file:

sudo nano /etc/haproxy/haproxy.cfg

Contoh konfigurasi berikut menggunakan HTTP pada port 80 dan statistik HAProxy pada port 8404.

global
    log /dev/log local0
    log /dev/log local1 notice
    daemon
    maxconn 4000

defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5s
    timeout client  30s
    timeout server  30s

frontend http_front
    bind :80
    default_backend web_backend

backend web_backend
    balance roundrobin
    option httpchk GET /
    http-check expect status 200
    default-server inter 3s fall 3 rise 2
    server web1 192.168.20.11:80 check
    server web2 192.168.20.12:80 check
    server web3 192.168.20.13:80 check

listen stats
    bind 192.168.10.11:8404
    mode http
    stats enable
    stats uri /stats
    stats refresh 10s

Penting: blok listen stats di atas mengikat alamat IP LB1 secara spesifik. Jangan menyalin blok tersebut apa adanya ke LB2 dan LB3. Sesuaikan alamat bind menjadi 192.168.10.12:8404 pada LB2 dan 192.168.10.13:8404 pada LB3.

Untuk lingkungan produksi, lindungi halaman statistik dengan autentikasi dan batasi akses menggunakan firewall atau jaringan manajemen. Hindari mengekspos statistik HAProxy ke jaringan publik.

Jika ingin konfigurasi yang lebih mudah dipelihara, statistik dapat diikat ke alamat manajemen yang tersedia pada masing-masing node.

Penjelasan konfigurasi

global mengatur parameter global HAProxy, termasuk logging dan batas koneksi.

defaults menyediakan pengaturan dasar yang diwarisi oleh bagian lain, seperti mode HTTP dan timeout.

frontend http_front menerima koneksi klien melalui port 80.

backend web_backend menentukan kelompok backend yang menerima trafik. Algoritma roundrobin membagi permintaan secara bergiliran ke server yang sehat.

option httpchk GET / mengaktifkan pemeriksaan HTTP ke backend. HAProxy tidak hanya mengandalkan status koneksi TCP, tetapi juga memeriksa respons aplikasi sesuai konfigurasi health check.

default-server inter 3s fall 3 rise 2 mengatur interval pemeriksaan dan jumlah kegagalan atau keberhasilan berurutan sebelum status server berubah. Dalam contoh ini, pemeriksaan dilakukan setiap tiga detik, dan backend memerlukan tiga kegagalan berurutan untuk ditandai tidak sehat serta dua keberhasilan untuk kembali dianggap sehat.

Langkah 4: Validasi konfigurasi

Jangan langsung melakukan restart tanpa validasi.

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Jika konfigurasi valid, lanjutkan:

sudo systemctl restart haproxy
sudo systemctl status haproxy --no-pager

Jika layanan gagal berjalan, periksa log:

sudo journalctl -u haproxy -n 100 --no-pager

Ulangi langkah validasi dan pengujian pada ketiga node.

Langkah 5: Uji HAProxy secara langsung

Dari masing-masing load balancer, jalankan:

curl -i http://127.0.0.1/

Jika berhasil, respons seharusnya menampilkan isi halaman dari salah satu backend yang sehat.

Ulangi beberapa kali untuk melihat distribusi trafik:

for i in $(seq 1 10); do
    curl -s http://127.0.0.1/
    echo
done

Hasil dapat memperlihatkan respons dari WEB1, WEB2, dan WEB3. Distribusi persisnya bergantung pada algoritma, koneksi, status backend, dan kondisi pengujian.

Pada tahap ini, HAProxy sudah dapat melakukan load balancing, tetapi VIP belum dikelola oleh Keepalived.

6. Konfigurasi Keepalived VRRP pada Tiga Node

Konfigurasi VRRP menentukan node mana yang memegang VIP. Pada skenario ini, LB1 mempunyai prioritas 150, LB2 prioritas 120, dan LB3 prioritas 100.

Ketiga node menggunakan VRRP instance dengan identitas yang sama, VIP yang sama, dan antarmuka jaringan yang sesuai.

Langkah 1: Tentukan antarmuka dan parameter VRRP

Sebelum mengedit konfigurasi, tentukan nilai berikut:

• Antarmuka frontend, misalnya ens18.
• VIP layanan, yaitu 192.168.10.100/24.
• VRID, yaitu 51, yang harus sama pada ketiga node dalam satu grup VRRP.
• Prioritas LB1: 150.
• Prioritas LB2: 120.
• Prioritas LB3: 100.

VRID harus unik dalam segmen jaringan untuk menghindari benturan dengan grup VRRP lain yang tidak berkaitan.

Langkah 2: Konfigurasi LB1

Edit file berikut pada LB1:

sudo nano /etc/keepalived/keepalived.conf

Gunakan konfigurasi:

global_defs {
    router_id LB1
}

vrrp_script chk_haproxy {
    script "/usr/local/sbin/check_haproxy.sh"
    interval 2
    timeout 2
    fall 2
    rise 2
    weight -60
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens18
    virtual_router_id 51
    priority 150
    advert_int 1

    unicast_src_ip 192.168.10.11
    unicast_peer {
        192.168.10.12
        192.168.10.13
    }

    virtual_ipaddress {
        192.168.10.100/24 dev ens18
    }

    track_script {
        chk_haproxy
    }
}

Walaupun LB1 memiliki prioritas tertinggi, state BACKUP digunakan untuk membiarkan pemilihan master dilakukan melalui mekanisme VRRP. Dengan nopreempt tidak digunakan dan prioritas LB1 tertinggi, LB1 yang sehat biasanya akan mengambil alih VIP kembali setelah pulih.

Jika ingin mempertahankan node yang saat ini memegang VIP meskipun node berprioritas lebih tinggi pulih, konfigurasi nopreempt dapat dipertimbangkan dengan pengaturan state yang sesuai.

Langkah 3: Konfigurasi LB2

Pada LB2, gunakan konfigurasi berikut:

global_defs {
    router_id LB2
}

vrrp_script chk_haproxy {
    script "/usr/local/sbin/check_haproxy.sh"
    interval 2
    timeout 2
    fall 2
    rise 2
    weight -60
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens18
    virtual_router_id 51
    priority 120
    advert_int 1

    unicast_src_ip 192.168.10.12
    unicast_peer {
        192.168.10.11
        192.168.10.13
    }

    virtual_ipaddress {
        192.168.10.100/24 dev ens18
    }

    track_script {
        chk_haproxy
    }
}

Langkah 4: Konfigurasi LB3

Pada LB3:

global_defs {
    router_id LB3
}

vrrp_script chk_haproxy {
    script "/usr/local/sbin/check_haproxy.sh"
    interval 2
    timeout 2
    fall 2
    rise 2
    weight -60
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens18
    virtual_router_id 51
    priority 100
    advert_int 1

    unicast_src_ip 192.168.10.13
    unicast_peer {
        192.168.10.11
        192.168.10.12
    }

    virtual_ipaddress {
        192.168.10.100/24 dev ens18
    }

    track_script {
        chk_haproxy
    }
}

Sesuaikan ens18 dengan antarmuka aktual di setiap server. Ketiga konfigurasi di atas menggunakan unicast VRRP agar komunikasi antar-node diarahkan secara eksplisit ke alamat IP peer.

Unicast bukan satu-satunya pilihan. Jika jaringan mendukung multicast VRRP dengan benar, konfigurasi multicast juga dapat digunakan. Pilihan unicast sering membantu pada lingkungan virtualisasi atau jaringan yang membatasi multicast, tetapi tetap membutuhkan aturan firewall dan konektivitas peer yang benar.

Mengapa prioritas berbeda?

Prioritas menentukan preferensi pemilihan MASTER dalam kondisi normal.

• LB1 dengan prioritas 150 menjadi kandidat utama.
• LB2 dengan prioritas 120 mengambil alih jika LB1 tidak tersedia atau tidak lagi memenuhi syarat.
• LB3 dengan prioritas 100 menjadi kandidat berikutnya.

Angka tersebut adalah nilai contoh. Desain sebenarnya perlu mempertimbangkan kapasitas CPU, RAM, jaringan, dan kemampuan setiap node menangani seluruh trafik ketika menjadi MASTER.

7. Membuat Health Check HAProxy untuk Keepalived

Salah satu kesalahan konfigurasi yang sering terjadi adalah hanya memeriksa apakah proses HAProxy aktif. Pemeriksaan seperti systemctl is-active haproxy berguna, tetapi belum tentu membuktikan bahwa HAProxy benar-benar dapat menerima trafik dan mengakses backend.

Untuk laboratorium ini, kita menggunakan skrip pemeriksaan lokal yang memastikan HAProxy aktif dan port 80 dapat menerima koneksi.

Langkah 1: Buat skrip pemeriksaan

Jalankan pada ketiga node:

sudo nano /usr/local/sbin/check_haproxy.sh

Isi skrip:

#!/bin/sh

systemctl is-active --quiet haproxy || exit 1

/usr/bin/curl \
  --silent \
  --show-error \
  --max-time 2 \
  --output /dev/null \
  http://127.0.0.1/ || exit 1

exit 0

Skrip tersebut melakukan dua pemeriksaan: memastikan service HAProxy aktif dan mencoba permintaan HTTP ke HAProxy lokal.

Karena HAProxy dikonfigurasi menggunakan bind :80, permintaan ke 127.0.0.1:80 dapat diterima melalui listener tersebut.

Langkah 2: Atur izin file

sudo chown root:root /usr/local/sbin/check_haproxy.sh
sudo chmod 750 /usr/local/sbin/check_haproxy.sh

Jalankan pengujian manual:

sudo /usr/local/sbin/check_haproxy.sh
echo $?

Kode keluar 0 menandakan pemeriksaan berhasil. Kode selain 0 menandakan kegagalan.

Langkah 3: Pahami bobot health check

Pada contoh VRRP, skrip menggunakan:

weight -60

Artinya, ketika skrip gagal sesuai parameter pemeriksaannya, bobot efektif prioritas dapat dikurangi sebesar 60. LB1 yang semula memiliki prioritas 150 dapat turun menjadi 90, sehingga LB2 dengan prioritas 120 berpotensi mengambil alih VIP.

Bobot negatif tersebut tidak otomatis menjamin failover pada semua kondisi. Hasilnya dipengaruhi oleh konfigurasi tracking, status skrip, dan aturan pemilihan MASTER.

Jika skrip gagal, node tetap hidup, tetapi HAProxy tidak dapat melayani trafik, penyesuaian prioritas dapat memicu perpindahan VIP ke node yang lebih sehat.

Namun, skrip ini hanya memeriksa jalur HTTP lokal secara sederhana. Jika seluruh backend mati, pemeriksaan tersebut bisa tetap gagal karena HAProxy tidak dapat memperoleh respons backend yang valid. Hal ini dapat menyebabkan perpindahan VIP yang tidak menyelesaikan masalah, karena node lain mungkin menghadapi kegagalan backend yang sama.

Untuk lingkungan produksi, pertimbangkan pemeriksaan yang dirancang khusus untuk kondisi layanan, dengan menghindari perpindahan VIP berulang akibat gangguan backend yang bersifat bersama.

8. Validasi Konfigurasi Keepalived

Sebelum mengaktifkan layanan, pastikan konfigurasi tidak memiliki kesalahan sintaks.

Pada setiap node:

sudo keepalived --config-test \
  --config-file=/etc/keepalived/keepalived.conf

Jika opsi tersebut tidak tersedia pada versi yang terpasang, periksa:

keepalived --help
man keepalived

Gunakan opsi validasi yang didukung oleh versi Keepalived pada sistem tersebut.

Periksa kembali:

• Nama antarmuka yang benar.
• Alamat unicast_src_ip yang sesuai dengan node.
• Daftar unicast_peer yang berisi dua node lainnya.
• virtual_router_id yang sama pada semua node.
• VIP yang sama pada semua node.
• Prioritas berbeda untuk ketiga node.
• Jalur skrip health check yang benar.
• Izin eksekusi skrip.
• Tidak ada VIP yang digunakan perangkat lain.

Setelah seluruh konfigurasi valid, aktifkan Keepalived pada ketiga node:

sudo systemctl enable --now keepalived

Jika Keepalived sudah berjalan, gunakan restart setelah memvalidasi perubahan konfigurasi:

sudo systemctl restart keepalived

Periksa status:

sudo systemctl status keepalived --no-pager

Periksa log:

sudo journalctl -u keepalived -n 100 --no-pager

9. Memverifikasi Kepemilikan VIP

Setelah Keepalived aktif, periksa alamat IP pada masing-masing node:

ip -br address

Dalam kondisi normal, VIP 192.168.10.100 hanya boleh muncul pada satu node yang bertindak sebagai MASTER.

Jika LB1 menjadi MASTER, alamat tersebut seharusnya terlihat pada antarmuka ens18 milik LB1.

Pada LB2 dan LB3, VIP tidak seharusnya terpasang ketika keduanya berada dalam kondisi BACKUP.

Untuk melihat status VRRP dari log:

sudo journalctl -u keepalived \
  --since "10 minutes ago" --no-pager

Perhatikan pesan perpindahan state seperti BACKUP ke MASTER atau sebaliknya.

Jika VIP muncul pada lebih dari satu node, hentikan pengujian trafik produksi dan periksa konfigurasi VRRP, konektivitas peer, VRID, serta aturan jaringan. Kondisi ini dapat menyebabkan konflik IP dan gangguan koneksi.

10. Menguji Akses Layanan Melalui VIP

Dari komputer klien yang dapat menjangkau jaringan frontend, jalankan:

curl -i http://192.168.10.100/

Jika konfigurasi benar, klien akan menerima respons HTTP dari backend yang dipilih HAProxy.

Ulangi beberapa kali:

for i in $(seq 1 10); do
    curl -s http://192.168.10.100/
    echo
done

Perhatikan perubahan identitas backend dalam respons.

Perlu diperhatikan bahwa koneksi persisten, caching, algoritma load balancing, dan kondisi backend dapat memengaruhi distribusi hasil. Pengujian ini dimaksudkan untuk memastikan layanan melalui VIP dapat diakses, bukan membuktikan pemerataan trafik secara matematis.

11. Simulasi Failover Otomatis

Pengujian failover harus dilakukan secara terkontrol. Gunakan lingkungan laboratorium atau jendela pemeliharaan yang telah disetujui.

Skenario 1: Mematikan HAProxy pada LB1

Pada LB1:

sudo systemctl stop haproxy

Tunggu health check mendeteksi kegagalan. Karena konfigurasi skrip menggunakan interval dua detik dan dua kegagalan berturut-turut, perpindahan dapat terjadi setelah beberapa detik, ditambah waktu pemilihan VRRP dan konvergensi jaringan.

Periksa VIP pada LB2 dan LB3:

ip -br address

Jika konfigurasi bekerja sesuai rancangan, LB2 dapat mengambil alih VIP karena prioritas efektif LB1 telah turun.

Uji akses klien:

curl -i --max-time 5 http://192.168.10.100/

Setelah pengujian, hidupkan kembali HAProxy pada LB1:

sudo systemctl start haproxy

Periksa status layanan dan perpindahan VIP. Dengan konfigurasi prioritas yang digunakan, LB1 yang sehat biasanya kembali menjadi kandidat utama.

Skenario 2: Mematikan node LB1

Untuk mensimulasikan kegagalan node, matikan LB1 hanya jika kondisi laboratorium memungkinkan:

sudo poweroff

VIP seharusnya berpindah ke LB2. Jika LB2 juga gagal, LB3 menjadi kandidat berikutnya.

Pengujian ini berbeda dari menghentikan HAProxy. Ketika seluruh node gagal, Keepalived tidak dapat memindahkan VIP karena tidak ada node yang masih berfungsi.

Skenario 3: Menguji failover dari LB2 ke LB3

Ketika LB2 memegang VIP, hentikan HAProxy pada LB2 atau simulasikan kegagalan node sesuai prosedur yang aman.

Periksa apakah LB3 mengambil alih VIP dan apakah klien tetap dapat mengakses layanan.

Skenario 4: Mengamati waktu pemulihan

Jalankan pemantauan dari klien:

while true; do
    date
    curl -sS --connect-timeout 2 --max-time 4 \
      http://192.168.10.100/ || echo "REQUEST FAILED"
    sleep 1
done

Hentikan pemantauan dengan Ctrl+C.

Hasil pengujian dapat menunjukkan beberapa permintaan gagal selama perpindahan VIP. Failover IP tidak menjamin seluruh koneksi TCP atau sesi aplikasi yang sedang berlangsung tetap utuh.

Koneksi baru umumnya akan diarahkan ke node yang memegang VIP setelah perpindahan selesai, sedangkan koneksi lama mungkin harus dibangun kembali.

12. Firewall dan Persyaratan Jaringan

Agar VRRP berfungsi, komunikasi antar-node harus diizinkan. Jika menggunakan unicast, pastikan paket VRRP dengan IP protocol number 112 dapat melewati firewall di antara ketiga node.

VRRP bukan layanan TCP atau UDP pada port tertentu. Karena itu, membuka port TCP 112 saja tidak menyelesaikan kebutuhan komunikasi VRRP.

Selain itu, pastikan:

• TCP port 80 dapat diakses dari jaringan klien ke VIP.
• TCP port 80 dapat diakses HAProxy ke backend.
• TCP port 8404 hanya dapat diakses dari jaringan manajemen jika statistik digunakan.
• Komunikasi unicast VRRP antar-node diizinkan.
• Kebijakan keamanan hypervisor, switch virtual, atau cloud tidak memblokir perpindahan VIP atau pembaruan ARP.

Pada sebagian lingkungan virtualisasi, pengelolaan VIP tambahan membutuhkan konfigurasi jaringan khusus. Jangan menganggap semua jaringan cloud mengizinkan mekanisme VIP berbasis VRRP secara otomatis.

13. Kesalahan yang Sering Terjadi

VIP tidak muncul pada node mana pun

Penyebab yang mungkin:

• Keepalived gagal membaca konfigurasi.
• Nama antarmuka salah.
• Alamat sumber unicast tidak sesuai.
• Skrip health check selalu gagal.
• Firewall memblokir protokol VRRP.
• Node tidak dapat berkomunikasi dengan peer.

Cara mengatasinya adalah memeriksa log Keepalived, menguji skrip secara manual, memvalidasi konfigurasi, dan memastikan alamat IP antarmuka benar.

VIP muncul pada lebih dari satu node

Kondisi ini dapat mengindikasikan split-brain atau kegagalan komunikasi antar-node.

Periksa VRID, konfigurasi peer, konektivitas Layer 2, dan firewall. Jangan menyelesaikan masalah dengan sekadar mengubah prioritas tanpa memahami penyebabnya.

HAProxy berjalan tetapi layanan tidak dapat diakses

Periksa apakah HAProxy mendengarkan port yang benar:

sudo ss -lntp

Periksa status backend melalui permintaan HTTP langsung dan log HAProxy.

Periksa pula firewall, routing, dan alamat bind frontend.

Failover tidak terjadi ketika HAProxy gagal

Penyebab umum:

• Skrip pemeriksaan tidak dapat dijalankan.
• Izin file tidak benar.
• Skrip memeriksa kondisi yang tidak sesuai.
• Penyesuaian prioritas tidak cukup untuk mengubah hasil pemilihan.
• Parameter tracking atau state tidak sesuai dengan desain.

Uji skrip dengan akun dan lingkungan eksekusi yang sesuai, lalu periksa log Keepalived.

VIP berpindah terus-menerus

Perpindahan yang berulang atau flapping dapat disebabkan oleh health check yang terlalu sensitif, backend yang tidak stabil, gangguan jaringan, atau perbedaan kondisi antar-node.

Sesuaikan interval, jumlah kegagalan berurutan, dan logika pemeriksaan. Jangan menurunkan interval secara berlebihan hanya untuk mengejar failover yang tampak lebih cepat.

Layanan pulih tetapi sesi pengguna terputus

Perpindahan VIP tidak mereplikasi tabel koneksi TCP, sesi aplikasi, atau status transaksi secara otomatis.

Untuk mengurangi dampak, rancang aplikasi agar mendukung retry, gunakan session storage bersama bila diperlukan, dan pastikan operasi transaksi aman terhadap permintaan ulang.

14. Best Practice untuk Lingkungan Produksi

Konfigurasi laboratorium di atas cocok untuk memahami konsep dasar, tetapi penerapan produksi memerlukan beberapa lapisan pengamanan tambahan.

Samakan konfigurasi HAProxy

Ketiga node harus menggunakan konfigurasi HAProxy yang konsisten. Gunakan sistem version control, template konfigurasi, atau automation seperti Ansible agar perubahan tidak dilakukan secara manual dan berbeda antar-node.

Setiap perubahan sebaiknya melewati validasi sintaks sebelum diterapkan.

Buat health check yang mewakili kondisi layanan

Pemeriksaan proses saja tidak cukup. Namun, health check yang terlalu luas juga berisiko memicu perpindahan VIP karena kegagalan backend yang dialami semua node.

Pisahkan indikator kesehatan proses HAProxy, kemampuan menerima koneksi, dan kesehatan aplikasi. Tentukan dengan jelas kondisi mana yang seharusnya memicu failover VIP.

Lindungi komunikasi dan antarmuka administrasi

Batasi akses ke statistik HAProxy, SSH, dan antarmuka manajemen. Gunakan firewall, autentikasi yang kuat, serta jaringan administrasi terpisah jika memungkinkan.

Untuk layanan HTTPS, siapkan konfigurasi sertifikat dan kebijakan TLS yang konsisten pada semua node HAProxy.

Pertimbangkan perilaku failback

Failback adalah proses ketika node berprioritas tinggi kembali mengambil alih VIP setelah pulih.

Dalam konfigurasi prioritas yang digunakan pada tutorial ini, LB1 dapat mengambil alih VIP kembali. Perilaku ini berguna jika LB1 memang dirancang sebagai node utama, tetapi perpindahan berulang dapat mengganggu koneksi.

Pertimbangkan apakah sistem membutuhkan preemption atau justru mempertahankan node yang saat ini aktif sampai terjadi kegagalan berikutnya.

Pantau ketiga node

Gunakan monitoring untuk mengawasi:

• Status HAProxy dan Keepalived.
• Node yang sedang memegang VIP.
• Kesehatan backend.
• Latensi dan tingkat kegagalan HTTP.
• CPU, RAM, dan penggunaan jaringan.
• Perubahan state VRRP dan frekuensi failover.

Sistem seperti Prometheus dan Grafana dapat membantu memvisualisasikan metrik, sementara log sistem dapat digunakan untuk investigasi insiden.

Siapkan pengujian failover berkala

Failover yang belum pernah diuji hanya memberikan keyakinan, bukan bukti bahwa sistem bekerja.

Lakukan simulasi terjadwal untuk memastikan VIP benar-benar berpindah, layanan dapat diakses kembali, dan mekanisme monitoring memberikan peringatan ketika terjadi gangguan.

15. Batasan Arsitektur dan Pertimbangan Lanjutan

Walaupun tiga node HAProxy dan Keepalived meningkatkan redundansi, desain ini tidak menghilangkan seluruh kemungkinan kegagalan.

Jika ketiga node bergantung pada satu switch, satu jalur jaringan, satu sumber daya listrik, atau satu host virtualisasi, komponen bersama tersebut masih dapat menjadi single point of failure.

Selain itu, jika seluruh backend tidak tersedia, pemindahan VIP tidak akan membuat aplikasi kembali sehat. Masalah tersebut harus diselesaikan pada lapisan backend.

VRRP juga tidak otomatis menyinkronkan konfigurasi, sertifikat TLS, koneksi TCP, ataupun sesi pengguna antar-node.

Untuk meningkatkan ketahanan sistem, pertimbangkan pemisahan domain kegagalan, redundansi jaringan, backup konfigurasi, pengujian pemulihan, serta strategi ketersediaan backend.

Terakhir, jangan menyamakan high availability dengan jaminan zero downtime. HAProxy dan Keepalived mengurangi dampak kegagalan, tetapi jeda perpindahan VIP dan pemulihan koneksi tetap mungkin terjadi.

Kesimpulan

Integrasi HAProxy dan Keepalived VRRP pada Debian 13 memungkinkan administrator membangun layanan load balancer dengan tiga node yang memiliki mekanisme failover otomatis.

HAProxy menangani distribusi trafik dan pemeriksaan kesehatan backend, sedangkan Keepalived mengelola VIP dan pemilihan node aktif melalui VRRP.

Agar implementasi berhasil, pastikan ketiga node mempunyai konfigurasi yang konsisten, komunikasi VRRP berfungsi, health check dirancang dengan tepat, dan perpindahan VIP diuji dalam kondisi normal maupun kegagalan.

Untuk lingkungan produksi, lengkapi implementasi dengan monitoring, pengamanan jaringan, manajemen konfigurasi, serta prosedur pengujian pemulihan. Pendekatan ini membantu membangun infrastruktur yang lebih tahan terhadap kegagalan tanpa mengabaikan keterbatasan failover berbasis VIP.

Frequently Asked Questions (FAQ)

1. Apa fungsi Keepalived pada HAProxy?

Keepalived mengelola Virtual IP menggunakan VRRP sehingga node HAProxy lain dapat mengambil alih alamat layanan ketika node aktif mengalami kegagalan yang terdeteksi.

2. Mengapa menggunakan tiga node HAProxy?

Tiga node menyediakan satu node utama dan dua kandidat failover. Jika node pertama gagal, node kedua dapat mengambil alih, kemudian node ketiga menjadi kandidat berikutnya jika node kedua juga gagal.

3. Apakah ketiga node HAProxy harus memiliki konfigurasi yang sama?

Ya, konfigurasi frontend, backend, health check, sertifikat yang diperlukan, dan kebijakan keamanan harus konsisten agar perpindahan VIP tidak menyebabkan perubahan perilaku layanan.

4. Apakah Keepalived menjamin zero downtime?

Tidak. Perpindahan VIP membutuhkan waktu dan koneksi yang sedang berlangsung dapat terputus. Mekanisme retry pada aplikasi dan pengujian failover dapat membantu mengurangi dampaknya.

5. Apakah VRRP menggunakan port TCP atau UDP?

VRRP menggunakan IP protocol number 112, bukan port TCP atau UDP 112. Firewall harus mengizinkan paket VRRP yang diperlukan.

6. Apakah VIP dapat berpindah jika proses HAProxy mati tetapi server masih hidup?

Ya, jika health check Keepalived mendeteksi kegagalan dan konfigurasi tracking menghasilkan perubahan prioritas yang memungkinkan node lain mengambil alih VIP.

7. Apakah ketiga node harus berada dalam satu subnet?

Dalam topologi standar yang menggunakan VIP Layer 2, ketiga node umumnya berada pada segmen jaringan yang sama. Desain lintas subnet membutuhkan pendekatan routing dan arsitektur yang berbeda.

8. Bagaimana cara mengetahui node yang memegang VIP?

Jalankan ip -br address pada ketiga node. VIP seharusnya terpasang pada node yang sedang berstatus MASTER.

9. Apakah Keepalived menggantikan fungsi load balancing HAProxy?

Tidak. Keepalived mengelola redundansi VIP, sedangkan HAProxy mendistribusikan trafik ke backend. Keduanya memiliki fungsi yang berbeda.

10. Apakah arsitektur ini dapat digunakan pada Proxmox atau VMware?

Ya, selama konfigurasi jaringan virtual mendukung komunikasi VRRP dan perpindahan VIP. Pastikan pula kebijakan keamanan virtual switch dan jaringan tidak menghalangi pembaruan ARP atau trafik antar-node.

11. Apa yang terjadi jika seluruh backend server mati?

VIP mungkin tetap tersedia, tetapi HAProxy tidak dapat memberikan respons aplikasi yang berhasil. Kondisi ini membutuhkan pemantauan backend dan penanganan kegagalan pada lapisan aplikasi.

12. Apakah konfigurasi HAProxy perlu disinkronkan otomatis?

Sangat disarankan. Gunakan Ansible, version control, atau sistem manajemen konfigurasi agar perubahan pada ketiga node dapat divalidasi dan diterapkan secara konsisten.

Ingin membangun load balancer yang lebih andal menggunakan Debian 13, HAProxy, dan Keepalived VRRP?

Praktikkan konfigurasi tiga node pada lingkungan laboratorium, kemudian uji failover dengan mematikan HAProxy dan menyimulasikan kegagalan node. Jangan hanya memastikan layanan berjalan—pastikan juga layanan dapat pulih ketika terjadi gangguan.

💬 Punya pengalaman menggunakan HAProxy, Keepalived, VRRP, atau teknologi high availability lainnya? Bagikan pengalaman, kendala, dan solusi yang pernah Anda temukan di kolom komentar.

📢 Bagikan artikel ini kepada rekan sysadmin, network engineer, DevOps engineer, dan siswa TKJ/TJKT yang sedang mempelajari administrasi server Linux.

📚 Jelajahi juga artikel terkait tentang konfigurasi HAProxy, DNS Server BIND9, Linux server hardening, monitoring Prometheus dan Grafana, serta troubleshooting jaringan.

Ikuti terus pembaruan tutorial Linux, server, networking, virtualisasi, cloud computing, dan DevOps untuk membangun infrastruktur IT yang lebih andal, aman, dan siap menghadapi kebutuhan masa depan.