Mastering Load Balancing: From HTTP Redirects to LVS IP Tunneling

Understanding "balance" means distributing traffic so that no server is overloaded and each can operate at its maximum capacity, taking into account differing hardware, bandwidth, and multi‑role servers.

1. HTTP Redirection

When a client requests a URL, the web server can respond with a Location header, causing the client to request a new URL. This method suffers from two main drawbacks:

Throughput limitation : the front‑end server must handle the total request rate before distributing to back‑end servers, which quickly becomes a bottleneck as the number of back‑ends grows.

Variable redirect depth : static pages and dynamic pages incur different loads, making it hard for the front‑end to predict actual server load.

Therefore, the cost of redirecting must be outweighed by the benefit of moving the request.

2. DNS Load Balancing

DNS resolves a domain name to one or more IP addresses. By returning multiple A records, DNS can act as a simple load balancer, directing clients to different servers without a dedicated front‑end.

Features:

Intelligent resolution based on client IP, allowing geographic proximity selection.

Dynamic DNS updates when server IPs change (subject to caching delays).

Limitations:

Admins cannot directly see which server a client reaches, complicating debugging.

Cannot incorporate HTTP‑level context (e.g., URL‑based routing).

Real‑time load‑aware routing requires custom DNS logic, which is often unavailable.

Cache propagation can cause stale mappings.

Overall, DNS may not achieve fine‑grained workload distribution.

3. Reverse‑Proxy Load Balancing

Most mainstream web servers support reverse‑proxy balancing, forwarding HTTP requests to back‑end servers.

Key characteristics:

All client requests pass through the proxy, which must wait for back‑end responses before replying.

Rich scheduling policies (e.g., weighted distribution) enable “more capable servers do more work”.

High concurrency requirements on the proxy because it operates at the HTTP layer.

Forwarding incurs overhead (thread creation, TCP connections, kernel‑user switches), which becomes noticeable when back‑end processing is very fast.

Proxies can monitor back‑end health (load, latency, connection count) and adjust policies accordingly.

Sticky sessions keep a client’s series of requests on the same back‑end, preserving session state.

4. IP Load Balancing (LVS‑NAT)

LVS (Linux Virtual Server) uses the Netfilter/IPVS kernel modules to perform load balancing at the transport layer (NAT).

Typical setup steps:

Enable packet forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward Ensure real servers use the NAT box as their default gateway, e.g., route add default gw xx.xx.xx.xx Add a virtual service: ipvsadm -A -t 111.11.11.11:80 -s rr (RR = round‑robin)

Add real servers: ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m and ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m (‑m = NAT mode)

Check status with ipvsadm -L -n Experiments show NAT‑based balancing can double the throughput compared with reverse‑proxy, but for large payloads the advantage diminishes.

5. Direct Routing (LVS‑DR)

DR operates at the data‑link layer, changing only the destination MAC address so that responses bypass the scheduler.

Configuration highlights:

Assign a virtual IP (VIP) as an alias on the loopback interface of the scheduler, e.g., ip addr add 10.10.120.193/32 dev lo.

Prevent ARP conflicts on the real servers:

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

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

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

echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce

Create the virtual service: ipvsadm -A -t 10.10.120.193:80 -s rr Add real servers with the -g flag to use direct routing: ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g and ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g DR removes the bandwidth limitation of the scheduler, allowing the aggregate outbound capacity of the real servers to be fully utilized.

6. IP Tunnel (LVS‑TUN)

LVS‑TUN encapsulates the client’s packet in a new IP header and sends it through an IP tunnel to a remote real server; the server’s reply goes directly to the client. This enables load‑balancing across different WAN segments while still using LVS.

Both DR and TUN are suited for services where response traffic far exceeds request traffic, and the choice depends on network topology and deployment needs.