Understanding Load Balancing: From DNS to LVS and Its Modes Explained

Origin of Load Balancing

In the early stages of a service, a single server is used to handle traffic. As demand grows, a single server hits performance limits regardless of hardware, prompting the need to cluster multiple servers to increase overall processing capacity.

To expose the clustered service, a unified traffic entry point— a load balancer— is required to distribute incoming requests across the servers using balancing algorithms.

Improves overall system performance.

Enhances system scalability.

Increases system availability.

Load Balancing Types

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

DNS 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 has notable drawbacks.

Server failover latency is high; DNS caches can delay updates.

Traffic distribution granularity is coarse; some ISPs do not rotate IPs.

Only round‑robin (RR) scheduling is supported; weight or hash algorithms are unavailable.

UDP packet size limits restrict the number of IPs (e.g., Alibaba DNS caps at 10 IPs per domain).

Hardware Load Balancing

Dedicated appliances (e.g., F5, A10) provide powerful, feature‑rich load balancing but are expensive and typically used only by large enterprises.

Strong functionality: supports all OSI layers and many algorithms.

High performance, far exceeding common software balancers.

Robust stability due to extensive testing.

Built‑in security features such as firewalls and DDoS protection.

High cost.

Poor extensibility; customization is limited.

Complex debugging and maintenance requiring specialized staff.

Software Load Balancing

Software balancers run on ordinary servers. Common options include Nginx, HAproxy, and LVS. Nginx: Layer‑7 balancing for HTTP/E‑mail, also supports Layer‑4. HAproxy: Layer‑7 rules with strong performance; used by OpenStack. LVS: Kernel‑mode, highest performance among software balancers, operates at Layer‑3.

Easy to deploy and maintain.

Cost‑effective; software is free.

Flexible: choose between Layer‑4 and Layer‑7 based on business needs.

LVS Overview

LVS (Linux Virtual Server) was initiated by Dr. Zhang Wensong and is a popular open‑source project. It is part of the standard Linux kernel, offering reliability, high performance, scalability, and low‑cost operation.

Netfilter Basics

LVS relies on the Linux kernel's netfilter framework. Netfilter provides a set of hook functions for packet filtering, NAT, and connection tracking. The five hook points are: PREROUTING: Packet enters network layer before routing. INPUT: Packet destined for the local host. FORWARD: Packet to be forwarded to another interface. OUTPUT: Packet generated by the local host. POSTROUTING: Packet leaves the network stack after routing.

LVS Working Principle

LVS registers a hook function ip_vs_in on the INPUT chain. When a packet matches a configured VIP:Port, LVS selects a real server (RS) and rewrites packet headers before forwarding.

LVS Modes

DR Mode (Direct Routing)

DR forwards client packets directly to the chosen RS; the RS replies directly to the client, bypassing LVS for the response.

Response traffic does not pass through LVS, yielding high performance. Minimal packet modification preserves the client’s source IP.

LVS and RS must reside on the same physical network (no cross‑datacenter support). RS requires proper loopback and kernel parameter configuration. Port mapping is not supported.

Use DR when maximum performance is required and preserving the client IP is essential.

NAT Mode

In NAT, both request and response traffic pass through LVS. LVS rewrites the destination IP to the RS and later rewrites the source IP back to the VIP before sending the response to the client.

Supports Windows servers. Allows port mapping; LVS can modify destination ports as needed.

RS must configure a gateway pointing to LVS. Bidirectional traffic increases load on LVS.

Choose NAT when the backend runs Windows or when port translation is required.

Tunnel Mode

Tunnel encapsulates the original packet inside an additional IP header (IPIP). The client request reaches LVS, which adds the tunnel header and forwards it to the RS. The RS removes the tunnel header and replies using the VIP as source, allowing cross‑datacenter deployment.

Single‑arm architecture reduces load on LVS. Minimal packet modification retains full client information. Supports cross‑datacenter traffic.

RS must have the ipip module installed. RS must configure tunl0 with the VIP. Encapsulation may cause fragmentation, affecting performance. Fixed tunnel source IP can lead to uneven hash distribution on RS NICs. Port mapping is not supported.

Use Tunnel when high forwarding performance and cross‑datacenter capability are needed, provided the deployment complexities can be handled.

FullNAT Mode

FullNAT is a proprietary mode originally from Baidu and later open‑sourced by Alibaba. It is not included in the upstream kernel. The source code is available at: https://github.com/alibaba/lvs FullNAT will be covered in a dedicated future article.

Overall, the article provides a comprehensive overview of load balancing concepts, the role of LVS within the Linux kernel, and detailed mechanics of its major operating modes.