Nginx and LVS

As business traffic scales beyond what a single server can absorb, load balancing becomes a cornerstone of high-availability architecture. In the Linux ecosystem, LVS (Linux Virtual Server) and Nginx are the two most widely adopted load balancing solutions. They operate at different layers of the network stack and serve distinct purposes, though they are frequently deployed together. This article examines their core principles, configuration approaches, and how to choose between them.

LVS: Kernel-Space Layer 4 Load Balancing

LVS is an open-source project initiated by Dr. Wensong Zhang. At its core lies the IPVS kernel module, which operates at the transport layer (Layer 4). Rather than inspecting application payloads, LVS rewrites packet address information to forward traffic to backend real servers.

Three Forwarding Modes

• NAT mode: The director rewrites the destination IP address and port. Both request and response packets pass through the director, which supports arbitrary network topologies but can become a bandwidth bottleneck.
• Direct Routing (DR) mode: The director only rewrites the MAC address of the frame, and real servers reply directly to clients. This delivers the highest performance and is the most commonly used mode, though it requires the director and real servers to reside in the same LAN.
• TUN mode: Requests are encapsulated via IP tunneling, allowing real servers to be distributed across a wide area network. This suits cross-data-center deployments.

Key Characteristics

• Runs in kernel space at Layer 4 without parsing application-layer content, delivering extremely high forwarding performance capable of handling hundreds of thousands of concurrent connections.
• Minimal resource consumption and excellent stability.
• Relatively complex configuration; it does not include native health checking, so Keepalived is typically paired with it for node monitoring and virtual IP failover.

Nginx: Flexible Layer 7 Reverse Proxy and Load Balancer

Nginx is renowned as a high-performance web server, but it is equally capable as a reverse proxy and load balancer. It primarily operates at the application layer (Layer 7), and since version 1.9, its stream module has also provided Layer 4 proxying.

Load Balancing Capabilities

• Built-in scheduling algorithms including round robin, weighted round robin, ip_hash, and least_conn.
• Traffic distribution based on application-layer information such as URL, Host header, and cookies, enabling static/dynamic separation and canary releases.
• Passive health checking via max_fails and fail_timeout; active probing is available in commercial builds and third-party modules.

Configuration Example

upstream backend {
    least_conn;
    server 192.168.1.10:8080 weight=3 max_fails=2 fail_timeout=10s;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 backup;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

This configuration distributes requests by least connections, assigns weights, and defines failure thresholds for each backend node.

LVS vs. Nginx: A Side-by-Side Comparison

In short, LVS excels in raw performance and throughput, while Nginx offers greater flexibility and a richer feature set.

Combined Architecture: LVS Plus Nginx

In large-scale, high-concurrency systems, the two are often combined into a two-tier "Layer 4 plus Layer 7" load balancing system:

1. First tier (LVS): Using DR mode, LVS exposes a virtual IP to absorb massive concurrent connections and forwards traffic evenly to a backend Nginx cluster.
2. Second tier (Nginx): Based on Layer 7 information such as URL and Host, Nginx routes requests precisely to application servers while handling caching, compression, and other edge functions.
3. High availability: Keepalived provides active-passive failover for LVS directors, enabling automatic virtual IP migration and eliminating single points of failure.

This architecture leverages LVS's kernel-level forwarding efficiency and Nginx's application-layer intelligence, making it a standard ingress pattern at many internet-scale companies.

Selection Guidelines

• Extremely high traffic, Layer 4 forwarding only (for example, database proxies or long-connection services): Choose LVS, preferably in DR mode.
• Content-based routing, static/dynamic separation, or canary releases: Choose Nginx.
• Small to medium workloads: Nginx alone is usually sufficient and keeps operational overhead low.
• Ultra-large scale: Deploy LVS with Nginx to balance performance and flexibility.

Conclusion

LVS and Nginx are not competitors; they are complementary. LVS operates at the kernel's Layer 4 boundary to solve the traffic entry problem with extreme performance. Nginx runs in user space at Layer 7 to solve traffic distribution with rich functionality. Understanding their respective layers, capability boundaries, and deployment constraints is essential for designing a load balancing architecture that is both efficient and stable.