Mastering Linux Virtual Server (LVS): Architecture, Modes, and ipvsadm Guide

1. Introduction to LVS

LVS (Linux Virtual Server) is a kernel‑based load‑balancing solution that creates a high‑performance, highly available server cluster using IP load‑balancing techniques. It is built into the Linux kernel since version 2.4, requiring no patches.

General Architecture

The LVS cluster consists of a load balancer (director) that receives client requests and forwards them to a pool of real servers (RS). The architecture is transparent to clients and does not require changes to client or server applications.

Load balancer (director): the front‑end machine that distributes client requests.

Server pool: the real servers that actually process requests (Web, Mail, FTP, DNS, etc.).

Shared storage: provides a common data area for the server pool, enabling identical services such as databases or distributed file systems.

Advantages and Disadvantages

High concurrency: operates at the kernel network layer, supporting tens of thousands of concurrent connections with low CPU and memory usage.

Low cost: a single server can replace expensive hardware load balancers.

Simple configuration: a few commands or scripts are sufficient.

Multiple scheduling algorithms: eight built‑in methods can be chosen based on workload.

Various working models: NAT, Direct Routing, TUN, FULL‑NAT, etc.

Broad applicability: works for HTTP, database, DNS, FTP and other services.

Limitations: operates at layer 4 only, so it cannot apply layer‑7 rules and is less suitable for small‑scale deployments.

Components and Terminology

ipvsadm : user‑space tool for managing LVS clusters.

ipvs : kernel module that performs packet forwarding based on ipvsadm rules.

VS – Virtual Server (virtual service).

Director (DS) – Load balancer.

RS – Real Server (backend server).

CIP – Client IP.

VIP – Virtual IP of the director.

DIP – Director IP.

RIP – Real Server IP.

Working Models

The director works in kernel space using Netfilter hooks. The typical packet flow is:

Client request arrives at the director and hits the PREROUTING chain.

If the destination IP matches the local machine, the packet is sent to the INPUT chain.

IPVS checks the packet against defined rules; if matched, the destination IP is rewritten to the selected real server and the packet proceeds to POSTROUTING.

The packet is then forwarded to the real server.

The real server processes the request and sends the response back through the director.

2. Load‑Balancing Modes

LVS‑NAT Mode

In NAT mode the director rewrites both the destination IP (DNAT) and the source IP (SNAT). All client traffic and responses pass through the director, which can become a bottleneck for very high traffic.

Client request reaches the director (VIP) and is DNAT‑ed to the selected real server (RIP).

The real server processes the request and sends the response back to the director.

The director SNAT‑s the response to the virtual IP before forwarding it to the client.

LVS‑DR (Direct Routing) Mode

Both director and real servers share the same virtual IP. The director only rewrites the MAC address and forwards the packet; the response bypasses the director and goes directly to the client.

Client request arrives at the director (VIP) and is forwarded to the chosen real server after changing the destination MAC to the server's MAC.

The real server receives the packet directly, processes it, and sends the response back to the client using the virtual IP as source.

LVS‑TUN (IP Tunneling) Mode

Requests are encapsulated in an additional IP header and sent to the real server; responses are sent directly to the client, allowing the real servers to be in different networks.

Client sends request to VIP.

Director encapsulates the packet with a new IP header (source DIP, destination RIP) and forwards it.

Real server decapsulates, processes the request, and sends the response directly to the client.

FULL‑NAT Mode

FULL‑NAT performs DNAT on the request and SNAT on the response (four NAT operations). It allows real servers to reside in different VLANs or networks but incurs higher processing overhead.

Client sends request to VIP.

Director DNATs the destination to the selected real server and SNATs the source to its own IP.

Real server processes the request and sends the response back to the director.

Director SNATs the source back to VIP and forwards the response to the client.

Comparison of Modes

In NAT and FULL‑NAT both request and response traverse the director; in DR and TUN only the request passes through the director while the response goes directly to the client. DR operates at layer 2 (MAC rewrite), TUN at layer 3 (IP encapsulation).

3. Scheduling Algorithms

LVS provides eight connection‑level scheduling algorithms:

Round‑Robin (rr)

Weighted Round‑Robin (wrr)

Least‑Connection (lc)

Weighted Least‑Connection (wlc)

Locality‑Based Least Connections (lblc)

Locality‑Based Least Connections with Replication (lblcr)

Destination Hashing (dh)

Source Hashing (sh)

4. Managing LVS with ipvsadm

Installation

yum install ipvsadm -y

Common Commands

ipvsadm --help               # Show usage
-A, --add-service ...         # Add a virtual service (VIP:port)
-a, --add-server ...          # Add a real server to a service
-L, --list ...                # List current configuration
-C, --clear                  # Remove all virtual services
-R, --restore ...            # Restore rules from stdin
-S, --save ...                # Save current rules to stdout
-p, --persistent timeout    # Enable persistent connections
-s, --scheduler method       # Choose scheduling algorithm (rr, wrr, lc, wlc, lblc, lblcr, dh, sh)

Example Scripts

Director script (dr.sh):

#!/bin/bash
VIP=10.1.210.58
RIP1=10.1.210.52
RIP2=10.1.210.53
PORT=80
ifconfig ens192:1 $VIP broadcast $VIP netmask 255.255.255.255 up
echo 1 > /proc/sys/net/ipv4/ip_forward
route add -host $VIP dev ens192:1
/sbin/ipvsadm -C
/sbin/ipvsadm -A -t $VIP:80 -s wrr
/sbin/ipvsadm -a -t $VIP:80 -r $RIP1 -g -w 1
/sbin/ipvsadm -a -t $VIP:80 -r $RIP2 -g -w 1
/sbin/ipvsadm -ln

Real‑server script (rs.sh):

#!/bin/bash
VIP=10.1.210.58
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce
ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
/sbin/route add -host $VIP dev lo:0

5. Persistent Connections

Persistent connections keep requests from the same client directed to the same real server for a configurable timeout, solving session‑affinity problems for stateful applications. LVS supports three persistence modes:

PCC – per‑client persistence (same IP always goes to the same server).

PPC – per‑port persistence (same client IP and service port go to the same server).

PFMC – firewall‑mark persistence (multiple services share the same persistence based on iptables MARK).

Persistence is enabled with the -p timeout option when adding a virtual service, e.g., ipvsadm -A -t 10.1.210.58:80 -s rr -p 300.