Mastering Load Balancing: HTTP Redirect, DNS, Reverse Proxy, and LVS Techniques

Before diving in, understand that “balance” does not mean giving every physical server the same amount of work; servers differ in hardware, bandwidth, and roles, so true balance aims to avoid overload and maximize each server’s contribution.

1. HTTP Redirection

When an HTTP proxy (e.g., a browser) requests a URL, the web server can return a new URL in the Location header, causing the proxy to request the new URL automatically.

Performance drawbacks:

Throughput limitation: the main server’s throughput must match the combined capacity of the redirected servers; otherwise, adding more servers does not increase overall capacity.

Different redirect depths: static pages and complex dynamic pages have unpredictable load, making site‑wide redirection unsuitable.

We need to weigh the overhead of redirecting requests against processing the actual request; the smaller the former, the more valuable the redirect, as seen in many mirror download sites.

2. DNS Load Balancing

DNS provides domain name resolution; a domain can map to multiple IP addresses, allowing DNS to act as a load‑balancing scheduler.

Example using dig to view Baidu's DNS records shows three A records:

Compared with HTTP redirection, DNS‑based load balancing eliminates the need for a “master” site; DNS records are cached, so there is no throughput limit and the number of real servers can theoretically grow without bound.

Features:

Intelligent resolution based on client IP.

Dynamic DNS updates when IP changes (subject to cache delay).

Drawbacks:

Operators cannot directly see which server a client is routed to, complicating debugging.

Scheduling cannot consider HTTP‑level context.

Adjusting scheduling based on real‑time server load requires custom DNS logic, which is complex.

DNS caching at various levels can cause inconsistent routing.

Overall, DNS may not achieve fine‑grained workload balance; choice depends on needs.

3. Reverse‑Proxy Load Balancing

Most mainstream web servers support reverse‑proxy load balancing, which forwards HTTP requests.

Compared with HTTP redirection and DNS, the reverse‑proxy sits between clients and real servers:

All HTTP requests to real servers pass through the scheduler.

The scheduler must wait for the real server’s response and forward it to the client.

Characteristics:

Rich scheduling policies, e.g., weighted distribution.

High concurrency requirements for the proxy server.

Forwarding incurs overhead (thread creation, TCP connections, header parsing, user‑kernel switches), which becomes noticeable for very short backend processing times.

The proxy can monitor backend metrics (load, response time, availability, connections, traffic) and adjust policies.

Supports session persistence (“sticky sessions”).

4. IP Load Balancing (LVS‑NAT)

Because reverse‑proxy overhead limits scalability, load balancing can be moved below the HTTP layer using NAT.

Linux kernels 2.4+ include Netfilter; iptables manages filter tables. Since kernel 2.6, the IPVS module implements IP load balancing.

Check if IPVS is installed (output of a module list) and manage it with ipvsadm:

Configuration steps:

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

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

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

Running ipvsadm -L -n shows server status. Experiments show NAT‑based balancing can achieve roughly twice the throughput of reverse‑proxy, though for large payloads the gap narrows.

Limitations include the NAT server’s network bandwidth; mixing DNS with NAT clusters can mitigate this.

5. Direct Routing (LVS‑DR)

Direct routing operates at layer 2, changing the destination MAC address without altering the IP, so responses go directly from the real server to the client.

Typical setup: one load‑balancer, two real servers, three external IPs, with an IP alias (e.g., 10.10.120.193) on the balancer.

Add the alias to the loopback interface and adjust ARP settings to prevent ARP conflicts:

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

Configure LVS‑DR with ipvsadm:

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

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

LVS‑DR’s main advantage is that response traffic bypasses the balancer, so the system is not limited by the balancer’s outbound bandwidth.

6. IP Tunnel (LVS‑TUN)

LVS‑TUN encapsulates the client’s IP packet in a new IP packet and forwards it to the real server, which can reside in a different WAN segment; the server’s reply reaches the client directly.

Both LVS‑DR and LVS‑TUN suit asymmetric request/response workloads; the choice depends on network topology and the need for geographic distribution.

Source: http://m.blog.csdn.net/article/details?id=41478111