Mastering Load Balancing: From HTTP Redirects to LVS Direct Routing

1. HTTP Redirection

When an HTTP client requests a URL, the web server can respond with a Location header pointing to a new URL, causing the client to issue a second request. This method suffers from throughput limits because the main server must handle all redirected traffic, and the depth of redirects varies, making load distribution unpredictable.

2. DNS Load Balancing

DNS resolves domain names to IP addresses and can return multiple A records, effectively distributing client requests across several servers. For example, using dig baidu shows three A records. DNS‑based balancing avoids the throughput bottleneck of HTTP redirects, but administrators cannot directly see which server handles a request, and DNS cannot incorporate HTTP‑level context.

3. Reverse Proxy Load Balancing

Reverse proxies forward HTTP requests to backend servers, waiting for responses before returning them to clients. They support weighted scheduling, health monitoring, and sticky sessions, but introduce additional processing overhead (thread creation, TCP connections, kernel‑user space switches). For static content, DNS‑based balancing may be more efficient.

4. IP Load Balancing (LVS‑NAT)

Linux Virtual Server (LVS) with NAT operates at the transport layer, rewriting destination IP addresses. The ipvsadm tool configures virtual services and real servers. Example commands:

echo 1 > /proc/sys/net/ipv4/ip_forward

route add default gw xx.xx.xx.xx

ipvsadm -A -t 111.11.11.11:80 -s rr

Adding two real servers with NAT:

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m

Running ipvsadm -L -n displays server status. NAT‑based LVS can achieve higher throughput than reverse proxies because packet forwarding occurs in the kernel.

5. Direct Routing (LVS‑DR)

LVS‑DR works at the data‑link layer, changing only the destination MAC address. Real servers send responses directly to clients, bypassing the load balancer, which removes the balancer’s bandwidth limitation. Configuration steps include adding an IP alias on the loopback interface and adjusting ARP settings:

echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

After setting up the alias (e.g., 10.10.120.193), use ipvsadm to create a virtual service and real servers with the -g flag for direct routing:

ipvsadm -A -t 10.10.120.193:80 -s rr

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g

Direct routing is ideal for high‑throughput services where response traffic far exceeds request traffic.

6. IP Tunnel (LVS‑TUN)

LVS‑TUN encapsulates incoming IP packets in a new IP header and forwards them through an IP tunnel to backend servers, which can reside in different network segments. This method also requires legitimate IP addresses for the real servers and is suitable when servers need to be geographically dispersed.

Both LVS‑DR and LVS‑TUN are appropriate for asymmetric web services; the choice depends on network topology and deployment requirements.