How Keepalived Achieves High‑Availability Load Balancing with LVS and VRRP

Introduction

When the virtual IP (VIP) managed by Keepalived drifts, MySQL master‑slave failover can loop, causing data‑sync failures. This summary explains the internal mechanisms of Keepalived, Linux Virtual Server (LVS), and the Virtual Router Redundancy Protocol (VRRP) that enable high availability and load balancing.

Keepalived and LVS Overview

Keepalived

Keepalived is a lightweight HA solution for Linux. It requires only a single configuration file and builds on the LVS project to provide health‑checking, VIP management, and failover capabilities.

LVS

LVS (Linux Virtual Server) is an open‑source load‑balancing framework integrated into the Linux kernel via the IPVS module. It creates a virtual IP that clients contact; the kernel scheduler then forwards each request to a real server according to a selected algorithm.

Basic LVS Principle

Clients send traffic to the VIP; the kernel’s IPVS table contains real‑server entries and health status. The scheduler selects a server using algorithms such as round‑robin, weighted round‑robin, least‑connection, etc.

DNS‑based round‑robin resolution

Client‑side scheduling

Application‑layer scheduling

IP‑address‑based scheduling (implemented by the IPVS kernel module)

Keepalived Traffic Forwarding

Keepalived starts the kernel’s LVS service to create a virtual server (VIP). Only the node in MASTER state receives client traffic; the BACKUP node remains on standby.

Master Election with VRRP

VRRP Protocol

VRRP creates a virtual router and a shared VIP. The master periodically broadcasts ARP packets; backups listen and take over the VIP if the master stops broadcasting.

Virtual router and VIP

Master broadcasts ARP messages

Backup elects a new master when needed

vrrp_instance Configuration

The three key parameters are: state: MASTER or BACKUP priority: integer 1‑255, higher value wins nopreempt: when set, a higher‑priority node will not pre‑empt an existing master

vrrp_instance VI_1 {
    state BACKUP          # node starts as backup
    priority 100          # base priority
    nopreempt             # disable pre‑emptive takeover
}

Setting both nodes to state BACKUP and adding nopreempt to the higher‑priority node prevents unnecessary master‑backup flapping.

vrrp_script for Dynamic Priority

A script can modify the node’s effective priority based on service health. The script must exit with 0 for healthy and non‑zero for unhealthy.

vrrp_script check_mysql {
    script "/usr/local/keepalived/check_mysql.sh"
    interval 5            # run every 5 seconds
    weight -20            # adjust priority by -20 when script fails
}

If the script returns 0, the configured weight is added to the base priority. If it returns non‑zero, the weight is not applied. Priority values are clamped to the range 1‑254.

Positive weight example : a weight of +10 raises the effective priority when the service is healthy, making the node more likely to become master.

Negative weight example : a weight of –20 lowers the effective priority when the service is unhealthy, allowing a backup node to take over.

Example scenario:

Node 1: priority 100, nopreempt Node 2: priority 90, pre‑emptive (default)

If MySQL on Node 1 fails, its effective priority drops (e.g., to 80). Node 2’s priority (90) then exceeds Node 1’s, so Node 2 becomes MASTER. When MySQL recovers, Node 1’s priority returns to 100 but does not pre‑empt because nopreempt is set.

Load‑Balancing Mechanism

IPVS Forwarding

Keepalived runs a user‑space LVS router process. The MASTER node (active router) creates the VIP and populates the IPVS table with real‑server entries and health checks. BACKUP nodes remain standby.

virtual_server 192.168.56.88 80 {
    delay_loop 6
    lb_algo rr            # round‑robin
    lb_kind NAT
    protocol tcp
    real_server 192.168.56.11 80 {
        TCP_CHECK { connect timeout 10 }
    }
    real_server 192.168.56.12 80 {
        TCP_CHECK { connect timeout 10 }
    }
    real_server 192.168.56.13 80 {
        TCP_CHECK { connect timeout 10 }
    }
}

Supported Scheduling Algorithms

rr – Round‑Robin

wrr – Weighted Round‑Robin

lc – Least‑Connection

wlc – Weighted Least‑Connection

sh – Destination‑address hash

dh – Source‑address hash

Conclusion

Keepalived combines the IPVS kernel module, VRRP, and flexible configuration blocks ( vrrp_instance, vrrp_script, virtual_server) to provide high‑availability, high‑performance load balancing. Master election is governed by state, priority, nopreempt, and dynamic weight adjustments, while the IPVS table implements the actual traffic distribution. Understanding these mechanisms enables engineers to design robust HA clusters and apply the same principles to other HA or load‑balancing solutions.