Load Balancing Methods and Algorithms

Load balancing is the process of distributing network traffic across multiple servers (or other resources) to ensure no single server becomes overwhelmed, thereby improving responsiveness, reliability, and availability. It is a fundamental component of high-availability architectures and is used in data centers, cloud environments, and enterprise networks.

The primary goals of load balancing are: - High Availability: If one server fails, traffic is redirected to healthy servers. - Scalability: New servers can be added without disrupting service. - Performance: Requests are distributed to avoid bottlenecks. - Efficient Resource Utilization: Each server handles a fair share of the load.

Load balancers can be hardware-based (e.g., F5 BIG-IP, Citrix ADC) or software-based (e.g., HAProxy, Nginx, AWS ELB). They operate at various OSI layers: Layer 4 (transport) or Layer 7 (application).

A load balancer sits between clients and backend servers. When a client sends a request, the load balancer intercepts it, selects a backend server based on a configured algorithm, and forwards the request. The response flows back through the load balancer (or directly to the client if using Direct Server Return).

Key components: - Virtual IP (VIP): The IP address clients connect to. - Real Servers: The backend servers that actually process requests. - Server Pool: A group of real servers managed by the load balancer. - Health Monitors: Mechanisms to check server health (e.g., ICMP ping, TCP port check, HTTP GET). - Persistence: Ensures a client's subsequent requests go to the same server (session stickiness).

Load balancing algorithms determine how to select a server for each new request. The N10-009 exam tests the following:

Round Robin - Distributes requests sequentially across the server pool. - Simple and works well when servers have similar capacity. - Does not account for current load or server performance.

Least Connections - Sends requests to the server with the fewest active connections. - More dynamic than round robin; adapts to varying request processing times. - Default algorithm in many load balancers (e.g., HAProxy).

Weighted Round Robin - Assigns a weight to each server based on capacity. - Servers with higher weights receive more requests. - Useful in heterogeneous environments.

Weighted Least Connections - Combines weights with connection counts. - Servers with higher weight and fewer connections get priority.

Source IP Hash - Uses a hash of the client's source IP to select a server. - Ensures the same client always goes to the same server (built-in persistence). - Useful for session-based applications.

Least Response Time - Sends requests to the server with the fastest response time. - Requires continuous monitoring of server response times.

Some applications require that a client's requests go to the same server throughout a session (e.g., shopping cart). Persistence methods include: - Source IP Affinity: Uses the client's IP address (via hash) to map to a server. - Cookie Insertion: The load balancer inserts a cookie into the response that identifies the server. - Cookie Learning: The load balancer reads an existing application cookie to determine the server.

Health checks are critical for ensuring traffic is only sent to healthy servers. Types: - ICMP Ping: Checks basic reachability. - TCP Port Check: Attempts a TCP connection to a specific port. - HTTP/HTTPS Check: Sends an HTTP GET request and expects a specific status code (e.g., 200 OK). - Script-based Check: Runs a custom script on the server.

Health check parameters: - Interval: How often the check is performed (default often 5 seconds). - Timeout: How long to wait for a response (default 2-3 seconds). - Threshold (fails): Number of consecutive failures before marking server down (default 2-3). - Threshold (successes): Number of consecutive successes to mark server up (default 2-3).

Example configuration for HAProxy (software load balancer):

frontend http-in
    bind *:80
    default_backend servers

backend servers
    balance roundrobin
    server web1 192.168.1.10:80 check inter 2000 fall 3 rise 2
    server web2 192.168.1.11:80 check inter 2000 fall 3 rise 2

Verification commands (depending on platform): - show stat (HAProxy) - show lbal vservers (Cisco) - show pool (F5)

Load balancers often work with: - Firewalls: Load balancers may be placed behind firewalls for security. - DNS: Global Server Load Balancing (GSLB) uses DNS to distribute traffic across geographic locations. - SSL Termination: Load balancers can offload SSL decryption to reduce server load. - Content Caching: Some load balancers cache static content to improve performance.

The N10-009 exam expects you to:

An online retailer uses a load balancer in front of three web servers. Each server maintains a shopping cart in memory. The load balancer must ensure that a user's requests go to the same server throughout their session. The solution uses Source IP Hash algorithm, which hashes the client's IP to select a server. This provides built-in persistence without needing cookies. However, if many users share the same public IP (e.g., corporate NAT), they all hash to the same server, causing imbalance. To mitigate, the load balancer uses Cookie Insertion instead: it inserts a cookie named BIGipServer into the HTTP response, which encodes the server identifier. On subsequent requests, the load balancer reads the cookie and forwards to the correct server. Misconfiguration example: if the persistence timeout is set too low (e.g., 1 minute), users may lose their session during checkout. Best practice: set persistence timeout to 30 minutes and use health checks with a 5-second interval and 2-second timeout.

A video streaming platform uses a load balancer with Least Connections algorithm. Each streaming request holds a TCP connection for a long duration (e.g., 30 minutes). A round-robin algorithm would overload servers with longer-lived connections because it doesn't consider current load. Least Connections sends new requests to the server with the fewest active connections, balancing the load more evenly. The load balancer also performs TCP port health checks on port 443. In production, the load balancer handles 100,000 concurrent connections across 10 servers. The team observes that one server occasionally has 30% more connections than others due to variable stream lengths. They switch to Weighted Least Connections by assigning higher weights to servers with more CPU resources, achieving better balance.

A multinational corporation uses DNS-based GSLB to distribute traffic across data centers in New York, London, and Tokyo. Each data center has a local load balancer that distributes traffic within the site. The GSLB uses Round Robin across sites but also considers proximity using GeoIP. If the New York site fails a health check (e.g., HTTP 503), the GSLB removes its IP from DNS responses. However, DNS caching can cause clients to hit the failed site for up to the TTL (e.g., 300 seconds). To reduce failover time, the TTL is set to 30 seconds. The local load balancers use Least Connections internally. Common pitfall: misconfigured health checks that mark a site as down due to a single failed server, causing unnecessary failover. Best practice: health checks should target a synthetic endpoint that verifies overall site health.