Learn Keepalived - Distributed HA Architectures

#Introduction

As traffic grows, a single MASTER load balancer is no longer enough. Episode 14 scales the architecture up: comparing active-active and active-passive topologies, building HA with many load balancer nodes, and understanding the failover consequences for connections that hold state.

The architecture decisions in this episode determine your maximum capacity and operational simplicity. There's no single right answer; what exists is a trade-off between performance, complexity, and readiness for incidents.

#Active-Active vs Active-Passive

#Active-Passive: Simple and Safe

This is the basic pattern you've been using since episode 3: one MASTER holds all the VIPs, other nodes wait. Its strength is simplicity and ease of understanding; its weakness is that one node sits idle and capacity is limited to a single node.

#Active-Active: Using All Nodes

With several VRRP instances of differing priority, every node can become MASTER for a portion of the VIPs:

vrrp_instance VI_WEB {
  state MASTER
  interface eth0
  virtual_router_id 80
  priority 110
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}
 
vrrp_instance VI_API {
  state BACKUP
  interface eth0
  virtual_router_id 81
  priority 90
  virtual_ipaddress {
    192.168.1.101/24 dev eth0
  }
}

On node A, VI_WEB becomes MASTER and VI_API waits. On node B, the configuration is reversed. The result: two nodes carry real load, and each one is the other's backup.

#Choosing Based on Load

Choose active-passive when traffic still fits on one node and simplicity is worth more. Choose active-active when a single node's capacity is nearly exhausted or when you want to split load per service. Keep in mind: active-active must still be able to hold the entire load on one node when the other dies.

#Keepalived with Many Load Balancer Nodes

#Three Nodes or More

VRRP doesn't limit the number of nodes. Add a third node with a middle priority as a safety layer:

lb01:  priority 110 (MASTER)
lb02:  priority 100 (BACKUP utama)
lb03:  priority 90  (BACKUP kedua)

With the priorities above, a failure of lb01 promotes lb02, and a failure of lb02 promotes lb03. All nodes share the same virtual_router_id and VIP list, and every node runs an identical virtual_server.

#Configuration Consistency

The key to many nodes is identical configuration in the VRRP and LVS blocks. A small difference like one different real_server produces different IPVS tables and inconsistent traffic. Episode 11 taught how to guarantee this with templates and drift control.

#IPVS Connection Synchronization

#The Connection Table Problem

LVS keeps its connection table in the kernel of the MASTER node. When failover happens, the new node doesn't know about in-flight connections, so established sessions can be cut. For re-connect tolerant services this is acceptable; for others, synchronization is needed.

#The IPVS Sync Daemon

IPVS provides a synchronization daemon to copy the connection table between nodes:

sudo ipvsadm --start-daemon primary --mcast-interface eth0
sudo ipvsadm --start-daemon backup --mcast-interface eth0

The ipvsadm --start-daemon primary command on the MASTER node sends copies of the connection table, and ipvsadm --start-daemon backup on other nodes receives them. Combine with Keepalived via notify hooks so the sync daemon follows the failover.

#Synchronization Limits

IPVS synchronization copies active connections, not application state. If sessions live in the backend (session cookies, JWT), IPVS synchronization isn't needed. If state lives in the load balancer's memory, consider moving the state to the backend or using strict sticky sessions.

#Stateful Failover Considerations

#Placing State in the Backend

The most resilient way: move state from the load balancer to the backend. With backend sessions or stateless JWTs, any load balancer node can serve any session, and failover becomes seamless with no synchronization at all.

#Separating Roles with vrrp_sync_group

If one service holds state and another doesn't, separate their instances. Group the stateful instances with vrrp_sync_group so they always move together, and let stateless instances move independently. This separation keeps a failure from spreading further than it needs to.

#Closing

Episode 14 expands your architecture from a pair into a cluster: active-active with per-instance priority, many load balancer nodes supporting each other, IPVS connection synchronization for in-flight sessions, and state placement strategies so failover stays seamless.

Key takeaways:

• Active-passive is simple; active-active uses all nodes.
• Active-active must still hold the entire load on a single node.
• Many nodes share the same virtual_router_id and identical LVS configuration.
• ipvsadm --start-daemon synchronizes the connection table between nodes.
• IPVS synchronization doesn't replace application state.
• Keep state in the backend so failover is truly seamless.

In episode 15 next, we cover performance tuning and latency reduction — tuning advert_int and election timing, understanding skew time and master down interval, and adjusting the daemon for large-scale HA with low-latency failover.