Linux Virtual Server (LVS) operates within the kernel space to distribute network traffic across multiple backend instances, creating scalable and fault-tolerant service architectures without modifying application code.

System Scaling Methodologies

Infrastructure expansion follows two fundamental patterns. Vertical scaling enhances existing server capacity through hardware upgrades—adding CPU cores, memory, or faster storage. This approach encounters physical limitations and cost inefficiencies as server grade increases. Horizontal scaling distributes workload across multiple commodity machines, forming clusters that communicate via internal networks. This architecture eliminates single-node bottlenecks and provides near-linear caapcity expansion.

Cluster Classification

Load Balancing (LB) clusters distribute incoming requests across multiple active nodes, with each participant handling a fraction of total traffic. High Availability (HA) clusters implement failover mechanisms ensuring continuous service despite component failures. High Performance Computing (HPC) clusters aggregate computational resources to reduce processing latency for complex calculations.

Reliability Engineering Metrics

System availability derives from Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR):

Availability = MTBF / (MTBF + MTTR)

This ratio ranges from 0 to 1, where values approaching 1 indicate superior uptime. Industry standards classify 95% availability as insufficient, while 99.9% (three nines) represents enterprise-grade reliability. Calculations assume 8,760 hours annually.

LVS Architectural Components

Virtual Server (VS): The logical service endpoint exposed to clients through a Virtual IP (VIP).

Director (DS): The traffic scheduler receiving client requests and applying forwarding rules. This node maintains the connection table and selects backend instances based on configured algorithms.

Real Server (RS): Backend nodes processing actual application requests and returning responses.

Addressing Scheme:

• CIP: Client source IP address
• VIP: Public-facing cluster address
• DIP: Director's internal network interface for RS communication
• RIP: Backend server addresses within the private network

NAT Forwarding Mode

Network Address Translation mode modifies packet headers at the Director. Client requests targeting the VIP undergo Destination NAT (DNAT), replacing the VIP with a selected RIP. Backend servers route responses back to the Director, wich performs Source NAT (SNAT) before returning traffic to the client.

Operational Flow:

1. Client transmits request to VIP
2. Director applies DNAT, forwarding to chosen RS
3. Backend processes request, returns to Director
4. Director translates source address to VIP
5. Response delivered to original client

This mode requires all traffic traversing the Director, creating a potential throughput limitation but simplifying backend configuration since Real Servers require no VIP awareness.

Scheduling Algorithms

Round Robin (rr): Sequential distribution across all healthy nodes.

Weighted Round Robin (wrr): Allocates proportionally based on node capacity weights.

Least Connection (lc): Directs requests to the node with fewest active connections.

Weighted Least Connection (wlc): Combines connection counts with server weights for intelligent distribution.

ipvsadm Configuration Reference

The ipvsadm utility manages virtual service tables:

# Define virtual service
ipvsadm -A -t <vip>:<port> -s <algorithm>

# Attach backend nodes
ipvsadm -a -t <vip>:<port> -r <rip>:<port> -m

# Persistence and weighting
ipvsadm -a -t <vip>:<port> -r <rip>:<port> -m -w <weight> -p <timeout>

Flags: -A (add virtual), -a (add real), -t (TCP service), -r (real server), -m (masquerade/NAT), -w (weight), -p (persistence), -C (clear table).

NAT Mode Deploymant

Topology:

• Client: 203.0.113.50
• Director (eth0): 10.0.1.10 (internal/DIP)
• Director (eth1): 203.0.113.10 (external/VIP)
• Web-Node01: 10.0.1.11
• Web-Node02: 10.0.1.12

Backend Preparation:

# On both web nodes
systemctl disable --now firewalld
setenforce 0
echo "<h1>Backend $(hostname)</h1>" > /var/www/html/index.html
systemctl restart httpd

# Configure default gateway via Director
nmcli con mod eth0 ipv4.gateway 10.0.1.10
nmcli con up eth0

Director Network Setup:

# Enable IP forwarding
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf

# Configure SNAT for outbound traffic
iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth1 -j SNAT --to-source 203.0.113.10

LVS Service Definition:

modprobe ip_vs
yum install -y ipvsadm

# Initialize empty ruleset
touch /etc/sysconfig/ipvsadm
systemctl enable --now ipvsadm

# Clear existing configuration
ipvsadm -C

# Create virtual service with round-robin
ipvsadm -A -t 203.0.113.10:80 -s rr

# Register backends with NAT mode
ipvsadm -a -t 203.0.113.10:80 -r 10.0.1.11:80 -m
ipvsadm -a -t 203.0.113.10:80 -r 10.0.1.12:80 -m

# Persist configuration
ipvsadm-save > /etc/sysconfig/ipvsadm

Weighted Distribution Configuration:

# Remove existing service
ipvsadm -D -t 203.0.113.10:80

# Recreate with weighted round-robin
ipvsadm -A -t 203.0.113.10:80 -s wrr

# Assign weights: node01 receives 2x traffic, node02 receives 3x
ipvsadm -a -t 203.0.113.10:80 -r 10.0.1.11:80 -m -w 2
ipvsadm -a -t 203.0.113.10:80 -r 10.0.1.12:80 -m -w 3

# Verify distribution ratios
ipvsadm -Ln --rate

Dynamic Node Management:

# Remove specific backend
ipvsadm -d -t 203.0.113.10:80 -r 10.0.1.11:80

# Add replacement node
ipvsadm -a -t 203.0.113.10:80 -r 10.0.1.13:80 -m -w 1

# Display active connections
ipvsadm -Lnc

Verification:

From the client host, repeated requests to 203.0.113.10 distribute across backends according to the active algorithm. Access logs on Web-Node01 and Web-Node02 reveal the Director's DIP (10.0.1.10) as the source address, confirming proper NAT translation.

For least-connection scheduling, substitute -s wlc during virtual service creation. This dynamically routes new requests to the backend with the lowest active connection count relative to its weight capacity.