Master Keepalived: Build Reliable Linux Load‑Balancing and HA

Keepalived Introduction

Keepalived is a routing software written in C that provides simple, robust load‑balancing and high‑availability for Linux systems. It monitors server health, automatically removes failed nodes and adds recovered nodes without manual intervention.

Originally designed for LVS, it also implements the VRRP protocol to protect services such as Nginx, HAProxy, MySQL and others.

Application Scenarios

Manage LVS clusters

Implement high‑availability via VRRP

Health check and automatic failover

Two main uses are load‑balancing (LVS + Keepalived) and active‑passive high‑availability.

Working Principle

VRRP Protocol

VRRP (Virtual Router Redundancy Protocol) creates a virtual router IP shared by multiple physical routers or servers. The master handles ARP, ICMP and traffic forwarding, while backups listen and take over when the master fails.

VRRP uses a virtual router ID (VRID) and a priority (0‑255) to elect the master; the highest priority becomes master.

Core Components

Modules: core (process management), check (health checks), VRRP (protocol implementation). Additional modules include system call, watchdog, libipfwc and libipvs.

Layered Operation

Load‑balancing works at TCP/IP layers 3‑5, while high‑availability operates at layers 3, 4, 7 using appropriate health‑check protocols: ICMP for layer 3, TCP for layer 4, and HTTP for layer 7.

Process Model

When started, Keepalived launches three processes: a parent, a VRRP child and a checkers child. Health‑check failures cause the VRRP child to withdraw the virtual IP and switch to BACKUP state.

Configuration and Usage

Configuration files are hierarchical, using braces and include statements. Key sections include global_defs, vrrp_instance and virtual_server.

<code>global_defs {
    router_id LVS_DEVEL
}
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.119.130
    }
}
virtual_server 192.168.119.130 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    protocol TCP
    real_server 192.168.119.120 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 10
            retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}
</code>

Typical deployment steps: install Keepalived and Nginx, create health‑check scripts, configure master and backup instances, start services, verify VIP movement, and test failover.

Common Issues – Split‑Brain

When heartbeat links fail, both nodes may think they are master, leading to resource contention. Causes include network failures, firewall blocks, mismatched VRID, or mis‑configured heartbeat interfaces.

Mitigation methods: dual heartbeat links, STONITH devices, monitoring tools, disk locking, arbitration via external gateway, or automatic reboot of the isolated node.

Preventing Split‑Brain with Nginx Monitoring

A script checks Nginx port and process; if unhealthy, it stops Keepalived to avoid split‑brain.

Preventing VIP Flapping After Recovery

Set the

nopreempt

parameter so the original master does not automatically reclaim the virtual IP after recovery; manual restart is required.

Multicast Address Conflict

Multiple Keepalived groups in the same LAN may clash on the default multicast address 224.0.0.18. Configure a unique

vrrp_mcast_group4

address in each group to avoid conflicts.