Mastering LVS: Deep Dive into Load Balancer Architectures and Scheduling Algorithms

1. LVS Cluster Architecture

The LVS (Linux Virtual Server) cluster is built from three logical layers:

Load Balancer layer – one or more Director servers run the ip_vs kernel module. The Director holds a virtual IP (VIP) and a routing table that maps the VIP to a set of real servers.

Server Array layer – the real application servers (Web, Mail, FTP, DNS, video, etc.). They can be any OS that supports IP networking (Linux, Windows, Solaris, AIX, BSD, …) and are usually connected by a high‑speed LAN or WAN.

Shared Storage layer – optional storage that provides consistent data to all real servers, typically via NFS or a cluster file system such as Red Hat GFS or Oracle OCFS2.

2. Load‑Balancing Modes Implemented by IPVS

IPVS provides three packet‑forwarding modes, each with different performance characteristics and network requirements:

Direct Routing (DR)

Network Address Translation (NAT) and Full NAT

IP Tunnel (TUN)

2.1 Direct Routing (DR) Mode

DR creates a virtual server by assigning the VIP to the Director. The Director rewrites only the destination MAC address of incoming packets and forwards them directly to the selected real server. The real server replies directly to the client, bypassing the Director on the return path.

The Director changes the packet’s destination MAC to the real server’s MAC while keeping the source IP (client IP) and destination IP (VIP) unchanged.

All real servers and the Director must reside on the same LAN so that MAC‑address rewriting works.

Each real server must bind the VIP on its lo (loopback) interface and disable ARP replies for that address (ARP suppression).

Real servers use the upstream router as their default gateway; they do not route through the Director.

Because the Director does not rewrite the destination port, real servers must listen on the same port as the VIP.

2.2 NAT and Full NAT Modes

NAT mode rewrites both the destination IP (VIP → real‑server IP) and the destination port before forwarding the packet. The response from the real server is sent back through the Director, which restores the source IP/port to the VIP before delivering it to the client.

Client sends a request to the VIP.

Director changes the destination IP/port to the selected real server and records the connection in a hash table.

Real server processes the request and sends the response to the Director.

Director rewrites the source IP/port back to the VIP and forwards the response to the client.

All traffic (request and response) passes through the Director, which can become a bottleneck under heavy load (typically 10‑20 % of total capacity).

Only one public IP is required on the Director.

Real servers must use the Director’s internal IP as their default gateway.

NAT can also translate ports, allowing the client‑side port to differ from the real‑server port.

Full NAT extends NAT by also rewriting the source IP of the client’s packet to the Director’s IP. When the response returns, the source IP is changed back to the VIP, providing symmetric address translation.

Client sends a packet to the VIP.

Director rewrites the destination IP to the real server and the source IP to the Director’s IP.

Real server processes the request and sends the reply to the Director’s IP.

Director rewrites the source IP back to the VIP and the destination IP to the client’s IP, then forwards the packet.

Full NAT does not require the Director and real servers to be on the same subnet.

Performance is slightly lower than DR (≈10 % slower) because of the extra source‑IP rewrite.

2.3 IP Tunnel (TUN) Mode

TUN (IP tunneling) encapsulates the client’s packet inside an IP tunnel and sends it to the selected real server. The real server decapsulates the packet, processes it, and sends the response directly to the client using the VIP as the source address.

Client sends a packet to the VIP.

Director encapsulates the packet in an IP tunnel and forwards it to the chosen real server.

Real server extracts the original payload, processes it (the VIP must be bound on the server’s loopback interface), and sends the response directly to the client. The source IP of the response is the VIP.

All real servers must bind the VIP on their loopback interfaces.

The VIP can be in a different subnet from the real servers because traffic travels through the tunnel.

Responses bypass the Director, reducing load on the load‑balancer.

Operational complexity is higher, so TUN is used less frequently.

3. LVS Scheduling Algorithms

LVS provides two families of scheduling algorithms that decide which real server will handle a given connection.

Fixed algorithms : round‑robin ( rr), weighted round‑robin ( wrr), destination‑hash ( dh), source‑hash ( sh).

Dynamic algorithms : weighted least‑connection ( wlc), least‑connection ( lc), locality‑based least‑connection ( lblc) and its replicated variant ( lblcr).

Typical selections:

Web, mail, MySQL services – rr, wrr, or wlc.

Web‑cache or DB‑cache clusters – lblc or lblcr (locality‑aware).

Firewall clusters – combine sh and dh to keep inbound and outbound flows symmetric.

When choosing an algorithm, consult the kernel implementation details and match the algorithm to the workload’s connection pattern and performance requirements.