Mastering Linux Virtual Server (LVS): Architecture, Models, and Scheduling Algorithms

Table of Contents

LVS Introduction

LVS Architecture and Operation

LVS Introduction

The rapid growth of the Internet has caused multimedia servers to face a surge in concurrent requests, making CPU and I/O bottlenecks inevitable; therefore, a single server cannot meet high‑load demands, and load‑balancing with multiple servers becomes essential. Linux Virtual Server (LVS) provides a cost‑effective, easily scalable solution by presenting a virtual server that distributes traffic across a pool of real servers.

LVS Architecture and Operation

1. LVS Structure

LVS consists of a front‑end load balancer (LB) and a back‑end cluster of real servers (RS) connected via LAN or WAN. To clients, the LB appears as a single virtual server; the LB forwards client requests to RSs based on configured packet‑forwarding policies and load‑balancing algorithms, and RSs return responses to the clients.

2. LVS Kernel Model

1. When a client request reaches the load balancer's kernel space, it first hits the PREROUTING chain. 2. If the kernel finds the destination address belongs to the local machine, the packet is sent to the INPUT chain. 3. LVS comprises the user‑space tool ipvsadm and the kernel module IPVS; ipvsadm defines rules, and IPVS applies them in the INPUT chain. If a packet's destination address and port are not in the rule set, the packet is passed to user space. 4. If the packet matches a rule, its destination address is rewritten to the predefined backend server and the packet is forwarded to the POSTROUTING chain. 5. Finally, the packet leaves via the POSTROUTING chain toward the backend server.

3. LVS Packet Forwarding Models

1. NAT Model

① The client sends a request to the load balancer (VIP) with source IP CIP. ② The load balancer rewrites the packet's destination to the real server's IP (RIP) and forwards it. ③ The real server processes the request and returns a response to LVS. ④ LVS changes the source address to its own and sends the response back to the client. Note: In NAT mode, the real server's gateway must point to LVS, otherwise packets cannot reach the client.

2. Direct Routing (DR) Model

① The client sends a request to VIP. ② LVS rewrites the source MAC to its own DIP MAC and the destination MAC to the real server's RIP MAC, then forwards the packet. ③ The real server receives the packet, processes it, and sends the response directly to the client via its eth0 interface. Note: The loopback interface's VIP must not respond to ARP requests on the local network.

3. TUN Model

① The client sends a request to VIP. ② LVS encapsulates the packet with a new IP header, changing the source to DIP and destination to RIP, then forwards it. ③ The real server removes the outer IP header, processes the inner request (which targets the loopback VIP), and sends the response back to the client via eth0. Note: The loopback VIP must not appear on the shared network.

4. LVS Scheduling Algorithms

Static Algorithms (4)

RR : Round‑Robin – distributes requests evenly without considering server load.

WRR : Weighted Round‑Robin – assigns more requests to servers with higher capacity.

DH : Destination‑Hash – hashes the destination IP to select a server.

SH : Source‑Hash – hashes the source IP to select a server.

Dynamic Algorithms (6)

LC : Least Connections – sends requests to the server with the fewest active connections.

WLC : Weighted Least Connections – similar to LC but weighted by server capacity.

SED : Shortest Expected Delay – selects the server with the smallest estimated delay.

NQ : Never Queue – assigns a request to any server with zero connections, avoiding queuing.

LBLC : Locality‑Based Least Connections – prefers the server that previously served the same target IP.

LBLCR : Locality‑Based Least Connections with Replication – maintains a pool of servers per target IP and selects the least‑connected server within the pool.