Mastering Keepalived & LVS: Build High‑Availability Load Balancers for OpenStack

Load Balancer Overview

A load balancer (LB) forwards IP traffic to multiple physical servers using load‑balancing algorithms. Hardware LBs use dedicated devices between clients and servers, while software LBs run on standard operating systems without special hardware.

OpenStack High‑Availability Solutions

OpenStack clusters typically use two HA patterns: HAProxy + Keepalived or Pacemaker + HAProxy. The latter is preferred for unified resource scheduling and stability, though Keepalived remains essential for virtual router failover in Neutron L3 HA.

1.1 Keepalived and LVS Overview

Keepalived extends the Linux Virtual Server (LVS) project, simplifying its configuration and enhancing stability. It provides load‑balancing and high‑availability for Linux‑based architectures, leveraging the kernel IPVS module for layer‑4 TCP/IP load balancing and offering health‑checking across layers 3, 4, 5/7.

Beyond health checks, Keepalived implements VRRP to achieve failover for LVS load‑balancing servers, operating as a user‑space process that monitors LVS nodes.

Keepalived Architecture

WatchDog : monitors the health of Checkers and VRRP subprocesses.

Checkers : perform health checks on real servers, the core of Keepalived’s reliability.

VRRPStack : handles failover between load balancers.

IPVS Wrapper : sends rules to the kernel IPVS code, creating and managing virtual servers.

Netlink Reflector : configures VIP addresses via the kernel NETLINK module, providing routing high‑availability.

1.2 Linux Virtual Server (LVS)

LVS, integrated into the Linux kernel, offers reliable, scalable, and cost‑effective load balancing for high‑performance services such as web, cache, DNS, FTP, mail, and streaming.

A typical LVS cluster has three layers:

Load Balancer layer : one or more Director servers running LVS, routing client requests to the Server Array.

Server Array layer : physical servers (Real Servers) providing the actual services.

Shared Storage layer : shared storage (e.g., NFS, GFS, GPFS) ensuring data consistency across Real Servers.

LVS Routing Methods

VSNAT (Virtual Server via Network Address Translation) rewrites destination IPs to the selected Real Server and rewrites source IPs on the response, causing all traffic to pass through the Director.

VSTUN (Virtual Server via IP Tunneling) forwards client requests through an IP tunnel; the Real Server replies directly to the client, reducing load on the Director.

VSDR (Virtual Server via Direct Routing) changes the MAC address of packets to send them directly to the Real Server, which replies directly, offering the highest performance but requiring the Director and Real Servers to share a physical network segment.

1.3 Virtual Router Redundancy Protocol (VRRP)

VRRP creates a virtual router group with one Master and one or more Backup routers. All hosts use the virtual IP of the group as their default gateway. If the Master fails, a Backup assumes the Master role, maintaining uninterrupted routing.

1.4 Keepalived Operation Principle

Keepalived runs on both active (Master) and standby (Backup) LVS routers, following VRRP. The Master forwards client requests to Real Servers and periodically sends VRRP advertisements. Backups listen for these advertisements; loss of advertisements triggers a failover, where a Backup becomes the new Master, takes over the VIP, and resumes health checking.

1.5 Keepalived Configuration

Configuration is divided into three sections:

Global configuration (global_defs): optional settings such as email notifications for failures.

VRRP configuration (vrrp_sync_group, vrrp_instance): defines VRRP groups, interfaces, router IDs, priorities, advertisement intervals, authentication, and virtual IP addresses.

Virtual server configuration (virtual_server): specifies the VIP, port, delay loop, load‑balancing algorithm, routing kind (NAT/DR/TUN), protocol, and Real Server definitions with health‑check parameters.

Example Configuration Snippet

global_defs {
  notification_email { [email protected] }
  notification_email_from [email protected]
  smtp_server 127.0.0.1
  smtp_connect_timeout 60
  router_id LVS_DEVEL
}

vrrp_sync_group VG1 {
  group { VRRP_EXT VRRP_INT }
}

vrrp_instance VRRP_EXT {
  state MASTER
  interface eth0
  virtual_router_id 50
  priority 100
  advert_int 1
  authentication { auth_type PASS auth_pass password123 }
  virtual_ipaddress { 10.0.0.1 }
}

vrrp_instance VRRP_INT {
  state MASTER
  interface eth1
  virtual_router_id 2
  priority 100
  advert_int 1
  authentication { auth_type PASS auth_pass password123 }
  virtual_ipaddress { 192.168.1.1 }
}

virtual_server 10.0.0.1 80 {
  delay_loop 6
  lb_algo rr
  lb_kind NAT
  protocol tcp
  real_server 192.168.1.20 80 { TCP_CHECK { connect timeout 10 } }
  real_server 192.168.1.21 80 { TCP_CHECK { connect timeout 10 } }
  real_server 192.168.1.22 80 { TCP_CHECK { connect timeout 10 } }
  real_server 192.168.1.23 80 { TCP_CHECK { connect timeout 10 } }
}

After editing /etc/keepalived/keepalived.conf, start and enable the service with systemctl start keepalived.service and systemctl enable keepalived.service.

Load‑Balancing Algorithms Supported by Keepalived

Round‑Robin

Weighted Round‑Robin

Least‑Connection

Weighted Least‑Connection

Destination Hash Scheduling

Source Hash Scheduling

Shortest Expected Delay

Routing Methods Comparison

NAT replaces destination and source IPs, causing the Director to handle both request and response traffic, which can become a bottleneck in large clusters.

DR allows Real Servers to reply directly to clients, eliminating the Director’s data‑path bottleneck and offering superior performance.