, ,

Setting Up VRRP and Keepalived for Load Balancer Redundancy with HAProxy

To ensure high availability and redundancy in our load-balancing environment, we can leverage VRRP (Virtual Router Redundancy Protocol) with Keepalived. By configuring VRRP across two servers, we can assign virtual IPs (VIPs) that automatically migrate between servers in the event of a failure. This setup enables seamless failover, with each server acting as both a primary and backup for different virtual IPs. Below, we’ll explore the configuration of two servers that use HAProxy as their load balancer.

Configuration Overview

Our configuration uses Keepalived to set up VRRP instances on two servers. Each server has a slightly different setup to allow for active-passive redundancy. Let’s break down the configurations of Server 1 and Server 2:

  1. Health Check with VRRP Script:
    • Both servers run a script (chk_haproxy) that checks if the HAProxy process is active. This check is performed every 2 seconds.
    • If HAProxy fails, the script’s weight is reduced, influencing VRRP’s priority-based election to trigger a failover.
  2. VRRP Instances:
    • Two VRRP Instances (VI_1 and VI_2) are configured, each with its own virtual IP.
    • In the default state:
      • VI_1 is assigned to 192.168.10.1 and is active on Server 2 (configured as MASTER on Server 2 and BACKUP on Server 1).
      • VI_2 is assigned to 192.168.10.2 and is active on Server 1 (configured as MASTER on Server 1 and BACKUP on Server 2).
  3. Failover Mechanism:
    • The VRRP instances are prioritized with priority values. The server with the highest priority becomes the MASTER, while the other acts as BACKUP.
    • If the primary (or MASTER) server’s HAProxy process fails, the virtual IP associated with the failed instance will automatically migrate to the backup server, ensuring uninterrupted load balancing.

Configuration Details

Server 1 Configuration:

Copied!
vrrp_script chk_haproxy { script "killall -0 haproxy" # Check if HAProxy process is running interval 2 # Check every 2 seconds weight 2 # Weight to influence master election } vrrp_instance VI_1 { state BACKUP interface eth0 # Network interface to bind to virtual_router_id 51 priority 50 # Higher priority on the primary server advert_int 1 authentication { auth_type PASS auth_pass HAP0 # Set a stronger authentication password } virtual_ipaddress { 192.168.10.1 # Your VIP address } track_script { chk_haproxy } } vrrp_instance VI_2 { state MASTER interface eth0 # Network interface to bind to virtual_router_id 52 priority 100 # Higher priority on the primary server advert_int 1 authentication { auth_type PASS auth_pass HAP0 # Set a strong authentication password } virtual_ipaddress { 192.168.10.2 # Your VIP address } track_script { chk_haproxy } }

Server 2 Configuration:

Copied!
vrrp_script chk_haproxy { script "/usr/bin/killall -0 haproxy" # Check if HAProxy process is running interval 2 # Check every 2 seconds weight 2 # Weight to influence master election } vrrp_instance VI_1 { state MASTER interface eth0 # Network interface to bind to virtual_router_id 51 priority 100 # Lower priority on the backup server advert_int 1 authentication { auth_type PASS auth_pass HAP0 # Same password as on the primary server } virtual_ipaddress { 192.168.10.1 # Your VIP address } track_script { chk_haproxy } } vrrp_instance VI_2 { state BACKUP interface eth0 # Network interface to bind to virtual_router_id 52 priority 50 # Lower priority on the backup server advert_int 1 authentication { auth_type PASS auth_pass HAP0 # Same password as on the primary server } virtual_ipaddress { 192.168.10.2 # Your VIP address } track_script { chk_haproxy } }

Explanation of Key Configuration Elements

  • State (MASTER or BACKUP): Each server’s VRRP instance is either configured as MASTER or BACKUP for its respective virtual IP, allowing one VIP to reside on each server under normal conditions.
  • Priority: The priority setting determines which server is primary. Higher priority values designate the primary server in a VRRP election, meaning that if HAProxy is running smoothly, the higher-priority server will handle traffic for its configured VIP.
  • Virtual IP Address: Each VRRP instance is assigned a VIP that represents it in the network, ensuring that clients are routed to the correct server.

Failover in Action

If the HAProxy process stops on either server, the VRRP script’s reduced weight prompts a failover, making the backup server the new MASTER for the affected VIP. This migration is seamless, allowing uninterrupted load balancing.

Summary

With this configuration, we achieve a balanced and highly available setup where each VIP can failover to the other server if HAProxy fails. By using VRRP with Keepalived, we ensure that our load balancer is always ready to handle traffic, even if a single server experiences downtime. This configuration provides both reliability and scalability, making it an ideal choice for environments requiring robust failover capabilities.