Load Balancing Overview: Origins, Types, and LVS Principles

Origin of Load Balancing

In the early stage of a service, a single server is used to handle traffic, but as demand grows the server hits a performance ceiling regardless of optimization or hardware upgrades, prompting the need for a cluster of servers and a unified traffic entry point to distribute requests evenly.

The traffic dispatcher, or load balancer, uses balancing algorithms to spread user requests across multiple servers, improving overall system performance, scalability, and availability.

Types of Load Balancers

Broadly, load balancers fall into three categories: DNS‑based, hardware, and software solutions.

1. DNS‑Based Load Balancing

DNS load balancing maps a domain name to multiple IP addresses, each pointing to a different server instance. It is simple and low‑cost but suffers from slow failover due to DNS caching, coarse traffic granularity, limited scheduling algorithms (typically only round‑robin rr ), and a restriction on the number of IPs per response.

2. Hardware Load Balancing

Dedicated appliances such as F5 and A10 provide powerful, feature‑rich load balancing with support for many algorithms, high performance, stability, and built‑in security functions (firewall, DDoS protection, SNAT). Their drawbacks are high cost, poor scalability for small‑to‑medium enterprises, and complex maintenance.

3. Software Load Balancing

Software solutions run on ordinary servers. Common examples are Nginx , HAproxy , and LVS . They differ as follows:

Nginx : Layer‑7 load balancing, supports HTTP/E‑mail and also Layer‑4.

HAproxy : Strong Layer‑7 performance; used by OpenStack as the default LB.

LVS : Kernel‑mode, highest performance among software balancers, operates at Layer‑3.

Software balancers are easy to deploy, inexpensive, and flexible, allowing selection between Layer‑4 and Layer‑7 based on business needs.

LVS and Netfilter Basics

LVS (Linux Virtual Server) is an open‑source project initiated by Dr. Zhang Wensong and now part of the standard Linux kernel. It relies on the netfilter framework, which provides hook points (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING) for packet filtering, NAT, and connection tracking.

When a packet arrives, it traverses these hooks; LVS registers an ip_vs_in hook on the INPUT chain to implement its core IPVS logic.

LVS Operating Modes

LVS supports three primary modes—DR, NAT, and Tunnel—plus a proprietary FullNAT mode (originated by Baidu and later open‑sourced by Alibaba).

DR (Direct Routing) Mode

In DR mode the request packet is redirected to a real server (RS) without altering the source IP. The RS replies directly to the client, bypassing LVS on the return path, which yields very high performance and preserves the client’s IP.

Advantages: high throughput, minimal packet modification, client IP visibility.

Disadvantages: LVS and RS must reside on the same physical network, requires special kernel configuration, and does not support port mapping.

Typical use case: scenarios demanding the utmost performance where preserving client IP is essential.

NAT Mode

Both request and response traffic pass through LVS. LVS rewrites the destination IP to the RS’s IP on the request and later rewrites the source IP back to the virtual IP (VIP) on the response, enabling port translation and support for Windows servers.

Advantages: supports Windows, allows port mapping.

Disadvantages: RS must configure a gateway to LVS, bidirectional traffic increases load on LVS.

Typical use case: environments where Windows servers are involved and port translation is required.

Tunnel Mode

Requests are encapsulated with an additional IP header (IP‑in‑IP) and forwarded to the RS. The RS strips the tunnel header and processes the packet as if it arrived directly. Responses are sent from the RS using the VIP as source, allowing cross‑datacenter deployment.

Advantages: single‑arm architecture reduces LVS load, minimal packet alteration, supports cross‑datacenter routing.

Disadvantages: requires ipip module and tunnel interface on RS, possible fragmentation, fixed tunnel IP may cause uneven hash distribution, and no port mapping.

Typical use case: high‑performance scenarios that also need cross‑region traffic.

Conclusion

The article has covered the fundamentals of load balancing, the three main implementation categories, and an in‑depth look at LVS, its netfilter integration, and the DR, NAT, and Tunnel modes, laying a solid foundation for further practical exploration.