LVS Load Balancing Modes and Their Scheduling Algorithms

IP Virtual Server (IPVS) is an IP load‑balancing implementation built into the Linux kernel, offering the most efficient scheduler technology for distributing network traffic.

NAT mode : The original purpose of NAT is to map private IP addresses to public ones due to address shortage. By slightly modifying the NAT process, it can serve as a load‑balancing method: the director (DR) rewrites the destination IP of incoming packets to the IP of a selected real server, forwards the packet, and the real server returns the response to the DR, which then rewrites the source IP back to its own address before sending it to the client. All traffic, inbound and outbound, passes through the DR.

IP tunnel mode : Similar to a VPN, this mode encapsulates the original client packet with a new IP header (containing only the destination IP) and sends it to the real server. The real server decapsulates the packet, processes it, and replies directly to the client without passing through the DR again. The real server must support the IPTUNNEL protocol, which requires the appropriate kernel option to be compiled.

Direct routing mode : This mode operates at the data‑link layer (Layer 2). Both the DR and the real servers share the same virtual IP address, but only the DR answers ARP requests for that address. Clients send packets to the virtual IP, the DR receives them, selects a real server, rewrites the destination MAC address to that server’s MAC, and forwards the packet. The real server sees the packet as if it came directly from the client, processes it, and replies directly to the client. Because the DR must modify Ethernet headers, the DR and real servers must reside in the same broadcast domain (e.g., on the same switch).

LVS Load Balancing’s Eight Scheduling Algorithms

1. Round‑Robin Scheduling : Requests are distributed sequentially across the real servers, giving each server an equal share regardless of current load or connection count.

2. Weighted Round‑Robin Scheduling : Each real server is assigned a weight based on its processing capacity; the scheduler distributes requests proportionally to these weights, allowing more powerful servers to handle more traffic.

3. Least‑Connection Scheduling : The scheduler forwards each new request to the server with the fewest active connections, which helps balance load when servers have similar performance.

4. Weighted Least‑Connection Scheduling : Similar to Least‑Connection, but each server’s weight influences the selection, so higher‑weight servers can handle more connections while still considering current load.

5. Locality‑Based Least‑Connections Scheduling : Targets cache‑oriented clusters; the scheduler selects the server that most recently served the same destination IP address, provided it is not overloaded, otherwise it falls back to the standard least‑connection rule.

6. Locality‑Based Least‑Connections with Replication Scheduling : Extends the previous algorithm by maintaining a mapping from a destination IP to a group of servers. The scheduler picks the least‑connected server within that group, adds or removes servers from the group based on load, and periodically cleans up over‑loaded servers.

7. Destination Hashing Scheduling : Uses the destination IP address as a hash key to look up a static hash table that maps to a specific server; if the selected server is available and not overloaded, the request is sent there.

8. Source Hashing Scheduling : Uses the source IP address as a hash key to select a server from a static hash table, ensuring that requests from the same client are consistently directed to the same server when possible.

Source: http://bbs.linuxtone.org/thread-7153-1-1.html