Mastering Load Balancing: From HTTP Redirects to LVS DR & TUN

1. HTTP Redirection

When an HTTP client requests a URL, the web server can return a Location header that directs the client to a new URL, causing an automatic redirect. This approach suffers from throughput limits because the main server must share its capacity with the redirected servers, and the load on each target can vary widely, making it unsuitable for fine‑grained balancing.

2. DNS Load Balancing

DNS resolves a domain name to one or more IP addresses. By returning multiple A records, DNS can distribute client requests across several servers. Because DNS responses are cached, the system can theoretically scale to an unlimited number of back‑end servers, but administrators cannot see which server a client actually reaches, and DNS cannot incorporate HTTP‑level context into its decisions.

Can perform intelligent IP‑based routing.

Supports dynamic updates when IPs change, though cache latency is unavoidable.

Limitations include lack of visibility for debugging and inability to use request‑level information.

3. Reverse‑Proxy Load Balancing

Most modern web servers support reverse‑proxy balancing, which forwards every client request through a proxy that then contacts the back‑end servers. This model allows rich scheduling policies (e.g., weighted round‑robin), health monitoring, and session persistence, but introduces additional processing overhead on the proxy.

Rich scheduling options and real‑time health checks.

Higher concurrency requirements for the proxy.

Extra latency from connection setup and kernel‑user space switches.

Supports sticky sessions to keep a user on the same back‑end.

4. IP Load Balancing (LVS‑NAT)

LVS‑NAT operates at the transport layer, rewriting destination IP addresses of incoming packets and forwarding them to back‑end servers. The kernel’s Netfilter/iptables framework and the ipvsadm tool configure the rules. echo 1 > /proc/sys/net/ipv4/ip_forward Example of adding a virtual server with round‑robin scheduling: ipvsadm -A -t 111.11.11.11:80 -s rr Adding real servers (NAT mode) and checking their status with ipvsadm -L -n completes the setup.

5. Direct‑Routing Load Balancing (LVS‑DR)

LVS‑DR works at the data‑link layer, changing only the destination MAC address while keeping the IP unchanged. Responses bypass the load balancer, eliminating its bandwidth bottleneck.

Key configuration steps include enabling arp_ignore and arp_announce on the loopback interface and adding real servers with the -r flag. ipvsadm -A -t 10.10.120.193:80 -s rr LVS‑DR is ideal for high‑throughput services where response traffic far exceeds request traffic.

6. IP‑Tunnel Load Balancing (LVS‑TUN)

LVS‑TUN encapsulates incoming packets in a new IP header and forwards them through a tunnel to remote back‑end servers, allowing the servers to reside in different network segments while still participating in the load‑balancing pool.

Both LVS‑DR and LVS‑TUN are suited for asymmetric workloads; the choice depends on network topology and deployment requirements.