Unlocking Keepalived: How VRRP and IPVS Deliver High‑Availability Load Balancing

Preface

The author encountered a strange MySQL outage caused by Keepalived’s virtual IP constantly drifting, leading to repeated master‑slave switches and synchronization failures. Although the exact issue could not be reproduced, a deep dive into Keepalived’s principles and core configuration parameters was performed.

1. Keepalived and LVS Overview

1.1 Keepalived Overview

Keepalived is a lightweight high‑availability solution for Linux, requiring only a single configuration file. Compared with heavyweight tools like Heartbeat, it is easier to install and is widely adopted in enterprises for HA scenarios.

1.2 LVS Overview

Originally written by Alexandre Cassen, Keepalived simplifies the configuration of the Linux Virtual Server (LVS) project and enhances its stability. LVS, short for Linux Virtual Server, is an open‑source load‑balancing module now integrated into the Linux kernel.

1.3 LVS Basic Principle

LVS creates a virtual IP (VIP) that clients address. The LVS scheduler then distributes incoming requests to a pool of real servers based on a selected algorithm (e.g., round‑robin, weighted round‑robin, least‑connection, etc.).

2. Keepalived Traffic Forwarding Principle

Keepalived leverages the IPVS module (IP Virtual Server) inside the Linux kernel to provide load‑balancing and high‑availability. When two Keepalived instances run on separate nodes, only one becomes the Master and holds the VIP; the other stays in Backup mode, receiving no traffic.

3. How Keepalived Elects a Master

Master election follows the VRRP (Virtual Router Redundancy Protocol) standard. Each node runs VRRP, broadcasting advertisements; the node with the highest priority becomes Master. A simple heartbeat mechanism replaces the Master’s periodic VRRP messages; if a Backup does not receive them within a timeout, it triggers a new election.

3.1 VRRP Protocol

VRRP provides a virtual router and virtual IP, allowing a group of physical routers to appear as a single logical router. The Master continuously sends VRRP advertisements; backups listen and stand by.

3.2 vrrp_instance Configuration

Key parameters for master election:

state – MASTER or BACKUP

priority – numeric value 1‑255

nopreempt – when set, a higher‑priority node will not pre‑empt an existing Master

vrrp_instance VI_1 {
    # node is BACKUP
    state BACKUP
    # priority 100
    priority 100
    # non‑preempt mode
    nopreempt
}

Setting both nodes to BACKUP with a high‑priority node in non‑preempt mode prevents unnecessary master‑backup flapping when the original Master recovers.

3.3 vrrp_script Configuration

Scripts can adjust a node’s priority dynamically. The example monitors a MySQL container and changes priority by a weight value.

vrrp_script restart_mysql {
    # monitor and restart MySQL container
    script "/usr/local/keepalived/restart_mysql.sh"
    interval 5
    weight -20
}

If the script returns 0 (service healthy), the node’s priority is increased by weight; otherwise it remains unchanged. The article details the switch‑over logic for both positive and negative weight values.

4. Keepalived Load‑Balancing Mechanism

4.1 Forwarding Mechanism

Keepalived runs in user space and starts the kernel’s LVS service to create a virtual server (VIP). Real servers are defined in virtual_server blocks, each with health‑check settings.

virtual_server 192.168.56.88 80 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    protocol tcp
    # server 1
    real_server 192.168.56.11 80 {
        TCP_CHECK { connect timeout 10 }
    }
    # server 2
    real_server 192.168.56.12 80 {
        TCP_CHECK { connect timeout 10 }
    }
    # server 3
    real_server 192.168.56.13 80 {
        TCP_CHECK { connect timeout 10 }
    }
}

4.2 Load‑Balancing Algorithms

The lb_algo field selects the scheduling algorithm. Common choices are:

rr – Round‑Robin

wrr – Weighted Round‑Robin

lc – Least‑Connection

wlc – Weighted Least‑Connection

dh – Destination‑Hash

sh – Source‑Hash

5. Summary

Keepalived is a widely used high‑availability component that builds on LVS/IPVS to provide virtual IPs, VRRP‑based master election, and flexible load‑balancing algorithms. Understanding its core principles—VRRP election, vrrp_instance/vrrp_script configuration, and IPVS scheduling—helps engineers design robust, fault‑tolerant services. The next article will explore how real servers return data to clients, covering LVS routing rules, monitoring, and failover details.