Learn Keepalived - Core Concepts & Main Architecture

#Introduction

Episode 2 enters the heart of Keepalived: VRRP concepts and the daemon architecture. This is the mental foundation that determines whether you operate Keepalived with confidence or merely copy configuration examples. In this episode we dissect what a virtual router is, how MASTER and BACKUP election works, and how keepalived.conf orchestrates everything.

Keepalived isn't a single magical monolithic program. It's a daemon that manages three subsystems: VRRP for VIP failover, checkers for health checks, and LVS for load balancing. Understanding the three separately will make episodes 3 through 22 much easier to digest.

We start with the VRRP mechanism, then read the anatomy of keepalived.conf, and close with the overall daemon architecture.

#VRRP Mechanism: Election and Advertisement

#Virtual Router and Virtual IP

A group of nodes that share one virtual_router_id forms a virtual router. They appear as one logical router with a single virtual IP (VIP). Clients treat the VIP as a permanent address, even though behind the scenes the VIP moves between nodes depending on conditions.

VRRPv2 sends advertisements to multicast 224.0.0.18 with the virtual MAC 00:00:5E:00:01:XX, where XX is the virtual_router_id in hexadecimal. Because this MAC is unique per virtual router, there's no collision between VRRP groups on the same network.

#Priority, Advert, and Election

Each node within a virtual router has a priority between 1 and 254. The node with the highest priority becomes MASTER, the rest become BACKUP. Here's what happens:

• The MASTER sends advertisements periodically according to advert_int, 1 second by default.
• BACKUPs use these advertisements as a sign that the MASTER is still alive.
• If no advertisement arrives within the master down interval, a BACKUP promotes itself to MASTER.
• Priority 255 is reserved for the IP address owner, the node that physically owns the VIP.

This election is deterministic: whoever has the highest priority wins, and this applies to every VRRP instance independently.

#Skew Time and Master Down Interval

VRRP accounts for skew time so that failover doesn't happen all at the exact same moment across every BACKUP. The formula is simple:

skew_time = (256 - priority) / 256 seconds
master_down_interval = (3 * advert_int) + skew_time

The consequence: a BACKUP with a higher priority waits less time before taking over, so the node that genuinely deserves to be MASTER will win. You can optimize advert_int and this timing in episode 15.

#Anatomy of keepalived.conf

#Main Configuration Structure

All Keepalived configuration lives in a single file, usually /etc/keepalived/keepalived.conf. This file is composed of YAML-like blocks: global_defs, vrrp_script, vrrp_instance, and virtual_server.

global_defs {
  router_id LB-01
}
 
vrrp_script chk_haproxy {
  script "/usr/bin/killall -0 haproxy"
  interval 2
  weight -20
}
 
vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  advert_int 1
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
  track_script {
    chk_haproxy
  }
}

The vrrp_instance VI_1 block defines one VRRP instance: interface, virtual_router_id, priority, and the list of VIPs. The vrrp_script block defines a health check that is then tracked by the instance. We'll dissect both fully in episodes 4 and 5.

#Important Parameters Inside vrrp_instance

The parameters most commonly tweaked:

• state: initial status, MASTER or BACKUP.
• interface: the NIC where VRRP runs.
• virtual_router_id: the VRRP group identifier, values 1 to 255.
• priority: 1 to 254, the higher the more right to become MASTER.
• advert_int: advertisement interval in seconds, default 1.
• authentication: protection for VRRP packets, covered in episode 9.

The most common mistake: two nodes using inconsistent virtual_router_id or priority values. Keepalived won't form a proper virtual router if these parameters differ.

#Daemon Components: VRRP, Checkers, and LVS

#The VRRP Subsystem

The VRRP subsystem is the failover engine: it handles advertisements, election, and the adding and removing of VIPs on interfaces. When the state changes from MASTER to BACKUP, this subsystem releases the VIP; when it rises to MASTER, it adds the VIP to the interface.

#The Checkers Subsystem

The checkers subsystem runs health checks. It's the one that executes scripts in vrrp_script, checks TCP ports, or makes HTTP requests to backends. Its results are used to decide whether an instance deserves to stay MASTER.

#The LVS Subsystem

The LVS subsystem interacts with the kernel through IPVS. It translates virtual_server into IPVS rules, adding and removing real servers according to health check results. This is where load balancing actually happens at the kernel layer.

#The Relationship Between the Three Subsystems

The three don't run independently. The typical flow: checkers make sure services are healthy, VRRP keeps the VIP on the right node, and LVS distributes traffic to healthy backends. If the service on the MASTER node dies, checkers apply a negative weight so the instance drops, then VRRP moves the VIP to the BACKUP.

#Verifying the Architecture Practically

To see which blocks are valid in your version, run a syntax check before changing anything:

sudo keepalived -t -f /etc/keepalived/keepalived.conf

The keepalived -t command validates the configuration file and shows the number of VRRP instances and virtual servers that will be formed. Make sure the result is error-free before restarting the daemon.

Once the daemon is running, check the VRRP status in the logs:

sudo journalctl -u keepalived --no-pager -n 20

The journalctl -u keepalived logs show state transitions like Entering MASTER STATE or Entering BACKUP STATE. Reading these logs from the start will help a lot in episode 7.

#Closing

Episode 2 gives you the architecture map of Keepalived: the VRRP election mechanism based on priority and advertisement, the anatomy of keepalived.conf with its vrrp_instance block, and the three daemon subsystems working together — VRRP, checkers, and LVS.

Key takeaways:

• A virtual router is a group of nodes sharing one virtual_router_id and one VIP.
• MASTER is chosen by the highest priority; BACKUPs wait for the master_down_interval.
• Skew time lets higher-priority nodes take over sooner.
• keepalived.conf consists of global_defs, vrrp_script, vrrp_instance, and virtual_server.
• The VRRP, checkers, and LVS subsystems cooperate within one daemon.
• keepalived -t and journalctl -u keepalived are mandatory first checks.

In episode 3, we get to work: installation and hello Keepalived — installing the daemon on Ubuntu and RHEL, creating the first floating IP configuration, starting the service, and watching two nodes fight over MASTER status. Time to get your hands on real configuration!