Learn Keepalived - History, Background & Why Choose Keepalived

#Introduction

Before writing any configuration, it's important to know where Keepalived came from and why it's chosen by so many infrastructure teams. Episode 1 opens the history chapter: the VRRP protocol that forms its foundation, Keepalived's journey from an LVS utility to a complete HA solution, and an honest comparison with the alternatives.

You'll understand when Keepalived is the right choice and when other solutions like Corosync/Pacemaker make more sense. Knowing where a tool sits in its ecosystem helps you make architecture decisions that are not only right today, but five years from now.

What we'll cover: the birth of Keepalived, the evolution of the VRRP standard, comparison with Heartbeat and cluster managers, primary use cases, and the criteria for when Keepalived isn't a good fit. All of this becomes the lens through which you read the episodes that follow.

#History of Keepalived and VRRP

#The Birth of Keepalived

Keepalived was written by Alexandre Cassen in the early 2000s as a userspace daemon on top of Linux Virtual Server (LVS). The original idea was simple: wrap LVS and VRRP into a single daemon with one configuration file. That way, a node could act as a load balancer and a redundant router at the same time without writing hundreds of lines of scripts.

That's where the name comes from: keep and alive, keeping services alive. Since then, Keepalived has grown into a mature, community-maintained project with stable 2.x releases, and it's widely used as an HA frontend for HAProxy, Nginx, and network gateways.

#The Journey of the VRRP Standard

Keepalived implements the Virtual Router Redundancy Protocol (VRRP). This protocol is designed so a group of routers appears as a single virtual router. Its evolution is tied to three RFCs:

• RFC 2338 (1998): the first VRRP definition for IPv4, later known as VRRPv2.
• RFC 3768 (2004): a VRRPv2 revision that removed the authentication header because it proved insecure.
• RFC 5798 (2010): VRRPv3, adding IPv6 support and advertisement intervals in centiseconds.

Keepalived supports both VRRPv2 and VRRPv3. Understanding these RFCs is useful when we touch authentication in episode 9 and IPv6 in episode 10. Because the standard is public, Keepalived implementations can interoperate with other network devices that also speak VRRP.

#Comparison with Other HA Solutions

Keepalived isn't the only HA tool in the Linux world. Here's a brief comparison based on real-world needs.

#Heartbeat

Heartbeat is the predecessor of Keepalived that was popular in the era of the Linux-HA 2.0 project. It does heartbeat between nodes and moves resources through scripts. The main weaknesses: complex configuration and no built-in load balancing support. Keepalived is lighter and focused on VRRP plus LVS.

#Corosync/Pacemaker

Corosync provides membership and messaging between nodes, while Pacemaker is a cluster resource manager that can move services, filesystems, and IPs in a stateful way. This solution is far more powerful for complex workloads like database clusters, but also far more complex to learn and operate. For simple floating IP failover, Pacemaker is overkill.

#Native LVS

Native LVS via ipvsadm alone already provides load balancing, but it has no automatic failover mechanism. Keepalived was actually born to complement LVS: it's the one that monitors backend health and moves the VIP when a load balancer dies. This position is what keeps Keepalived relevant to this day.

#Comparison Summary

No single solution wins on every dimension. What sets Keepalived apart is its simplicity for network-layer needs:

• Keepalived: L4 failover plus load balancing in one lightweight daemon.
• Heartbeat: simple script-based heartbeat, now rarely used.
• Corosync/Pacemaker: cluster resource manager for stateful services.
• Native LVS: pure load balancing, without automatic failover.

Choose Keepalived when your need is VIPs and service availability; choose a cluster manager when the resources being managed go beyond an IP.

#Primary Keepalived Use Cases

#Floating IP Failover

The most common combination: two nodes and one virtual IP. When the active node dies, the VIP moves to the standby node within seconds. This pattern is used for API gateways, database VIPs, and NAT gateways. No client needs to change configuration because the address stays the same.

#HA Load Balancer Frontend

Keepalived is placed in front of HAProxy or Nginx. The virtual IP belongs to the load balancer, while the real servers are the application backends. When one load balancer dies, the other takes over the VIP without clients noticing. We dissect this architecture fully in episodes 6 and 14.

#Redundant Gateway

Keepalived can create a redundant default gateway: two routers share one VIP as the gateway, and the servers below always have a single reliable exit point. We cover the routing and policy routing details for this scenario in episode 12.

#Why Choose Keepalived

Three main reasons production teams choose Keepalived:

• Lightweight and focused: one daemon, one configuration file, no large cluster dependencies.
• Combines VRRP and LVS: failover and load balancing in one tool that complements each other.
• Mature and widely supported: used across the HAProxy, Nginx, and various infrastructure stacks.

Verify the daemon version you have as groundwork for the discussion ahead:

keepalived --version

The output of keepalived --version shows the VRRP version and build options. This information matters because features like auth_type and centisecond only exist in certain versions.

#When Keepalived Isn't a Good Fit

Keepalived isn't the answer to every HA problem. If your service needs majority consensus, quorum, or complex resource management, consider another solution. Scenarios like database clusters with stateful replication or disk fencing are better handled by Corosync/Pacemaker or a database-native solution.

#Closing

Episode 1 places Keepalived on the map of history and ecosystem: born from LVS, built on the VRRP standard, and competing with Heartbeat and Corosync/Pacemaker. You also understand its primary use cases: floating IP failover, HA load balancer frontend, and redundant gateway.

Key takeaways:

• Keepalived implements VRRP, the standard codified in RFC 2338, 3768, and 5798.
• It was born as an LVS plus VRRP wrapper by Alexandre Cassen.
• Heartbeat and Corosync/Pacemaker exist, but for different needs.
• Keepalived is best suited for L4 failover: VIPs and load balancing.
• keepalived --version tells you which features are available in your version.
• Note your version number, because features change between 2.x releases.

In episode 2, we'll dissect Keepalived core concepts and main architecture — the master/backup election mechanism, the role of keepalived.conf, the checkers, VRRP, and LVS components inside the daemon, and the relationship between them. This is the mental foundation you'll use in every episode that follows.