Understanding Keepalived: High‑Availability, VRRP Election, and Load‑Balancing Mechanisms

Preface

In a previous incident we encountered a MySQL failure; this time we face a different problem where Keepalived's virtual IP keeps drifting, causing continuous master‑slave switching and data‑sync failures. Although the exact issue could not be reproduced, we studied Keepalived's internals and performed extensive experiments on its core parameters.

The tutorial is divided into three parts: upper, middle, and lower sections, each covering specific knowledge points.

Upper Part – Core Concepts

How Keepalived provides traffic forwarding.

The election mechanism of Keepalived.

Load‑balancing algorithms used by Keepalived.

Middle Part – Detailed Mechanisms

Keepalived routing rules.

How Keepalived monitors services.

Failover process of Keepalived.

Architecture analysis of Keepalived.

Lower Part – Practical Deployment

Detailed Keepalived configuration.

Hands‑on deployment examples.

1. Keepalived and LVS Overview

1.1 Keepalived Overview

Keepalived is a lightweight high‑availability solution for Linux, requiring only a single configuration file, making it simpler to install than heavyweight tools like Heartbeat. It is widely adopted in enterprises as the HA component.

1.2 LVS Overview

Keepalived was originally created by Alexandre Cassen to simplify the configuration and improve the stability of the Linux Virtual Server (LVS) project, which is now part of the Linux kernel.

LVS (Linux Virtual Server) provides load‑balancing by distributing client requests to a pool of real servers based on predefined algorithms.

1.3 Basic LVS Principles

LVS creates a virtual IP (VIP) that clients contact; the LVS scheduler then forwards the request to one of the real servers according to the selected algorithm (e.g., round‑robin, weighted). The three LVS operation modes are NAT, TUN, and DR.

2. Keepalived Traffic Forwarding Principle

Keepalived leverages the IPVS (IP Virtual Server) module in the Linux kernel to provide load‑balancing and high‑availability. When two nodes run Keepalived, only the Master node holds the VIP and receives client traffic; the Backup node stays on standby.

3. Keepalived Master Election

Master election follows the VRRP (Virtual Router Redundancy Protocol) standard. VRRP creates a virtual router and VIP; the Master periodically broadcasts VRRP advertisements, while Backups listen and take over if the Master fails.

3.1 VRRP Protocol

Virtual router and virtual IP.

Master broadcasts VRRP packets.

Backup elects a new Master when needed.

3.2 vrrp_instance Configuration

Key parameters for election:

state – MASTER or BACKUP.

priority – numeric priority (1‑255).

nopreempt – disables pre‑emptive takeover.

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

Setting both nodes to BACKUP with a higher‑priority node using nopreempt prevents unnecessary master‑backup flapping.

3.3 vrrp_script Configuration

Scripts can adjust priority dynamically. Example monitoring MySQL:

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 the weight; otherwise it remains unchanged. Positive weight raises priority, negative weight lowers it, influencing election outcomes.

4. Keepalived Load‑Balancing Mechanism

4.1 Forwarding Mechanism

Keepalived runs in user space and starts the kernel LVS service to create a virtual server (VIP). It then populates IPVS tables with real servers and selects one based on the configured load‑balancing algorithm.

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

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 and high‑performance component in clustered environments. Understanding its underlying principles helps grasp general HA and load‑balancing concepts.

The article covered Keepalived’s IPVS integration, virtual server creation, VIP handling, load‑balancing algorithms, and the configuration fields (state, priority, nopreempt, weight) that control master election.

In the next part we will explore how real servers return data to clients, the LVS routing rules, and deeper monitoring and failover strategies.