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.
Keepalived Overview
Keepalived is a routing failover software written in C. It was initially designed for the
LVSload‑balancing solution to manage and monitor the status of service nodes in an LVS cluster, and later added high‑availability
VRRPcapabilities. 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
VRRPprotocol (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 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
1second.
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.
Open Source Linux
Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.