How LVS Load Balancer Distributes Traffic: Deep Dive into DR, NAT, and TUN Modes

Load Balancer Layer

The load balancer layer sits at the front of the cluster, consisting of one or more Director servers. The Director runs the IPVS core and acts like a router, using routing tables to forward client requests to the Real Server array.

The Director also runs the Ldirectord monitoring module to check the health of Real Servers, removing unavailable servers from the routing table.

Server Array Layer

The Server Array comprises the actual application servers (Real Servers) such as web, mail, FTP, DNS, or video servers, connected via high‑speed LAN or WAN. A Director can also serve as a Real Server.

Shared Storage Layer

Shared storage provides a common data area for all Real Servers, typically implemented with disk arrays. NFS can be used but may suffer performance issues under heavy load; cluster file systems like Red Hat GFS or Oracle OCFS2 are alternatives.

Director Server Platform

Director servers run Linux or FreeBSD; Linux 2.6 kernels include LVS modules natively. Real Servers can run Linux, Windows, Solaris, AIX, BSD, etc.

Load‑Balancing Algorithms

Various load‑balancing schemes exist (DNS round‑robin, client‑side scheduling, application‑layer scheduling, IP‑based scheduling). The most efficient is IP‑based scheduling implemented by the IPVS module.

DR (Direct Routing) Mode

DR creates a virtual server via Direct Routing. The scheduler rewrites the destination MAC address to the Real Server’s MAC, sending the packet directly. The Real Server replies directly to the client, bypassing the scheduler, offering the highest performance.

Key points:

The scheduler changes only the destination MAC; source IP remains the client IP (CIP) and destination IP remains the virtual IP (VIP).

Responses from Real Servers go straight to clients, reducing load on the scheduler.

All Real Servers and the scheduler must reside in the same LAN.

Real Servers bind the VIP on their loopback interface and suppress ARP responses.

Real Servers use the upstream router as their default gateway.

Real Servers must listen on the same port as the VIP.

NAT / FULL NAT Mode

NAT (Network Address Translation) rewrites both destination and source addresses at the scheduler. The client contacts the VIP; the scheduler translates the destination to a Real Server IP and port, forwards the packet, and later rewrites the source back to the VIP before sending the response to the client.

FULL NAT additionally rewrites the source address of the client’s request to the scheduler’s IP, and restores it on the return path, ensuring return traffic always passes through the scheduler.

Advantages and drawbacks:

NAT requires only one public IP on the scheduler.

Each Real Server’s gateway must be the scheduler’s internal IP.

NAT can translate both IP and port, allowing different ports on Real Servers.

Because all traffic passes through the scheduler, it can become a bottleneck under high load (typically 10‑20 nodes).

TUN (IP Tunneling) Mode

TUN (Virtual Server via IP Tunneling) encapsulates client packets in an IP tunnel to the Real Server. The Real Server processes the request and sends the response directly to the client using its own external address, bypassing the scheduler.

Key characteristics:

Real Servers must bind the VIP on their loopback interfaces.

The VIP‑to‑Real Server traffic travels through the tunnel, allowing different network segments.

Real Servers send responses directly to clients, not through the scheduler.

Operational complexity is higher, so TUN is less commonly used.

LVS Scheduling Algorithms

LVS provides two families of scheduling algorithms: static (rr, wrr, dh, sh) and dynamic (wlc, lc, lblc, lblcr). In production, common choices include round‑robin (rr), weighted least‑connection (wlc), and weighted round‑robin (wrr) for general services, while locality‑based least‑connection (lblc) and its replicated variant (lblcr) suit web or DB caches. Source‑hash (sh) and destination‑hash (dh) are useful in firewall clusters to maintain session affinity.