Master LVS Load Balancing: Build High‑Performance Linux Clusters Step‑by‑Step

Introduction

LVS (Linux Virtual Server) is a free‑software virtual server cluster system created in May 1998, offering high‑performance, high‑availability load balancing for Linux servers at low cost.

Cluster Basics

A cluster is a group of independent computers connected by a high‑speed network, managed as a single system to improve availability and scalability. Main benefits include high scalability, high availability, high performance, and cost‑effectiveness.

Cluster types:

LB : Load Balancing – highly scalable, stretchable clusters.

HA : High Availability – highly available clusters.

HP : High Performance – high‑performance clusters.

Cluster solutions:

Hardware level: F5 BIG‑IP, Citrix Netscaler, A10, Array, Redware.

Software level: lvs (transport layer), haproxy, nginx (application layer).

LVS Components

ipvsadm

– command‑line tool for managing LVS services (user space). ipvs – kernel module that provides LVS services (kernel space).

LVS Terminology

VIP : Virtual IP address presented to clients.

RIP : Real server IP address.

DIP : Director IP address used for communication with real servers.

CIP : Client IP address.

RS : Real server.

LVS Types

LVS‑NAT (Network Address Translation): RS uses private addresses; all traffic passes through the Director.

LVS‑DR (Direct Routing): Only request packets pass through the Director; responses go directly from RS to clients.

LVS‑TUN (Tunneling): All IPs are public; requests pass through Director, responses bypass it; no port mapping.

Scheduling Algorithms

Static methods: rr: round robin. wrr: weighted round robin. sh: source hashing (session binding). dh: destination hashing.

Dynamic methods: lc: least connection. wlc: weighted least connection. sed: shortest expected delay. nq: never queue. lblc: locality‑based least connection. lblcr: replicated locality‑based least connection.

ipvsadm Command Overview

General syntax examples:

ipvsadm -A -t|u|f service-address [-s scheduler]

ipvsadm -D -t|u|f service-address

ipvsadm -C

– clear all services. ipvsadm -L -n – list services and real servers.

Key options for defining services and nodes: -A add a service. -D delete a service. -E edit a service. -t TCP service. -u UDP service. -f firewall mark. -s scheduler. -a add a real server. -d delete a real server. -e edit a real server. -r specify real server IP:port. -m NAT model, -g DR model, -i TUN model.

LVS‑NAT Model Configuration

Example commands (temporary configuration):

#ifconfig eth0 172.16.10.100/16 up

#route add default gw 172.16.10.12

#ifconfig eth0 172.16.10.212/16 up

#ifconfig eth0 192.168.1.10/24 up

#ifconfig eth1 172.16.10.12/16 up

#yum -y install ipvsadm

#echo 1 > /proc/sys/net/ipv4/ip_forward

#ipvsadm -A -t 192.168.1.10:80 -s rr

#ipvsadm -a -t 192.168.1.10:80 -r 172.16.10.100 -m

#ipvsadm -a -t 192.168.1.10:80 -r 172.16.10.212 -m

LVS‑DR Model Configuration

DR avoids the Director bottleneck by letting responses bypass it. Kernel parameters must be tuned:

#echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

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

#echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

#echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

Real servers and Director are configured with appropriate IPs and routes, then the following commands set up the DR cluster:

#ipvsadm -A -t 192.168.1.10:80 -s rr

#ipvsadm -a -t 192.168.1.10:80 -r 172.16.10.100 -g

#ipvsadm -a -t 192.168.1.10:80 -r 172.16.10.212 -g

Web Server Load Balancing Example

Topology includes a Director (VIP 192.168.1.10, DIP 172.16.10.12), two Real servers (RIP 172.16.10.100/212), a PHP server, NFS server, and a MySQL server.

Steps:

Configure NFS shared directory and permissions.

Deploy Discuz files, set ownership, and adjust permissions.

Configure Apache virtual hosts on each Real server to proxy PHP to the PHP server.

Mount the NFS share on Real servers and set auto‑mount.

Enable IP forwarding and set up ipvsadm rules as shown above.

After starting services, accessing the web site shows balanced requests; checking the Director reveals which Real server handled each request, confirming successful load balancing.

Conclusion

Using LVS, a functional load‑balancing cluster can be built with only a few commands. Understanding the underlying principles and practicing the configurations are essential for mastering high‑availability services.