Operations 6 min read

Mastering Keepalived: How VRRP Powers High‑Availability Load Balancing

Keepalived, a C‑based routing failover tool originally built for LVS, uses the VRRP protocol to provide high‑availability for services like Nginx, HAProxy, and MySQL, managing virtual IPs, health checks, and rapid failover within seconds.

Open Source Linux
Open Source Linux
Open Source Linux
Mastering Keepalived: How VRRP Powers High‑Availability Load Balancing

Keepalived Overview

Keepalived is a routing failover software written in C. It was initially designed for the

LVS

load‑balancing solution to manage and monitor the status of service nodes in an LVS cluster, and later added high‑availability

VRRP

capabilities. Consequently, Keepalived can manage LVS as well as provide high‑availability solutions for other services such as

Nginx

,

Haproxy

, and

MySQL

.

Keepalived achieves high availability primarily through the

VRRP

protocol (Virtual Router Redundancy Protocol), which was created to solve the single‑point‑failure problem of static routing, ensuring continuous network operation when individual nodes fail.

Thus, Keepalived not only configures and manages LVS, but also performs health checks on LVS nodes and offers high‑availability for network services.

How Keepalived Works

In an interview scenario, the working principle can be explained as follows:

Keepalived architecture diagram
Keepalived architecture diagram

Keepalived high‑availability relies on VRRP communication.

(1) VRRP (Virtual Router Redundancy Protocol) was created to address static routing single‑point failures.

(2) VRRP uses an election mechanism to assign routing tasks to a selected router.

(3) VRRP communicates via IP multicast (default address 224.0.0.18) to achieve high‑availability between nodes.

(4) The master node sends packets; backup nodes listen. If a backup does not receive the master's packets, it initiates a takeover. Typically there is one master and one backup in Keepalived deployments.

(5) VRRP supports encrypted authentication, but Keepalived currently recommends plain‑text configuration for authentication type and password.

Keepalived service operation:

(1) Keepalived uses VRRP to communicate. VRRP’s election mechanism determines the master (higher priority) and backup. The master holds all resources, while the backup remains idle until the master fails, at which point the backup takes over and provides services.

(2) Only the master continuously sends VRRP broadcast packets to indicate it is alive. Backups do not pre‑empt the master. When the master becomes unavailable and its broadcasts stop, the backup starts relevant services and takes over resources, with failover times often under

1

second.

Functions of Keepalived Service

(1) Manage VIP

The Virtual IP (VIP) is a floating IP presented to external clients and can migrate between LVS instances.

(2) Monitor LVS dispatchers

The Keepalived instance on the active LVS announces its presence via multicast. If the backup does not receive this announcement within a time window, it assumes the master has failed and takes over the VIP.

(3) Manage Real Servers (RS)

Real Servers are the actual machines providing services such as web, mail, or FTP. Keepalived periodically performs health checks (e.g., using

elinks http://192.168.1.251 –dump

) to verify their availability.

Classic high‑availability web architecture: LVS + Keepalived + Nginx + Apache + PHP + eAccelerator (+ NFS optional)

Conclusion

This article provides a basic introduction to Keepalived. Future posts will cover installation, deployment, and practical high‑availability cluster scenarios.

high availabilityLoad BalancingVRRPLVSkeepalivedNetwork Failover
Open Source Linux
Written by

Open Source Linux

Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.