Server Load Balancing: VIPs, Real Servers and Health Checks

01 /What server load balancing does

Server load balancing advertises one virtual IP address (VIP) and distributes the connections arriving at it across two or more real servers. Clients only see the VIP. The balancer owns the address and keeps a table that maps every active flow to the real server handling it. The rest of the load balancing hub builds on this idea.

Three objects appear in almost every implementation. A real server is an address and port on a machine running the application. A virtual server is the VIP and port clients connect to. A bind ties a virtual port to one or more real ports. Foundry sold this as an appliance from around 1998: the ServerIron was marketed as a Layer 4 through 7 "web switch"; the original Foundry SLB configuration guide was among the most linked documents on this domain.

02 /Layer 4 balancing methods

The selection method (Foundry called it the predictor) decides which real server receives the next new connection.

None of these methods remember a client between connections; per-user server state needs a persistence rule.

03 /Health checks at Layer 3, 4 and 7

Checks are layered:

• Layer 3: ICMP echo to the server. Proves the host is up.
• Layer 4: a TCP handshake to the bound port. Proves a process is listening.
• Layer 7: an HTTP request such as GET /health, passing only on an expected status code or body string. Proves the application answers.

Each check has an interval, a failure count before the server is marked down and a recovery count before it returns. A server that passes Layer 4 but fails Layer 7 is the classic hung process: the socket accepts, the application never answers.

04 /NAT mode versus direct server return

In NAT mode the balancer rewrites the destination of each inbound packet from the VIP to the chosen real server. Return traffic must pass back through it so the source can be rewritten to the VIP, so the balancer is either the default gateway of the servers or it also source-NATs the client. NAT mode sees both directions and is required for any Layer 7 feature.

In direct server return (DSR, or transparent mode) the balancer changes only the destination MAC address. The real server carries the VIP on a loopback interface and replies straight to the client. Responses never touch the balancer, so a modest appliance can front heavy outbound traffic. The cost: no Layer 7 inspection and no server-side NAT. Foundry marketed its DSR mode under the name SwitchBack, around the early 2000s.

05 /Config shape in ServerIron-style CLI

The general shape of an SLB configuration on IronWare-era ServerIron software is below. It is illustrative: define the real servers, define the virtual server, bind the ports.

server real web1 10.1.1.11
 port http
 port http url "HEAD /"
server real web2 10.1.1.12
 port http
server virtual www 192.0.2.10
 port http
 bind http web1 http web2 http
!
show server real
show server virtual
show server bind

The url line attaches a Layer 7 check to the real port. The bind line maps the virtual HTTP port to each real HTTP port. Second-hand units still boot into this syntax (CLI reference).

06 /High availability of the balancer itself

The balancer is a single point of failure unless paired. The usual pattern is active/standby: two units share the VIP through a VRRP-style election (see VRRP and VSRP) and the standby takes the address within seconds of the active unit disappearing. Session synchronisation copies the flow table to the standby so established connections survive failover.

07 /Capacity terms that matter

Three numbers describe a balancer. Connections per second (CPS): how many new flows it can set up, the limit for busy web front ends. Concurrent sessions: the size of the flow table, exhausted first by long-lived connections. Throughput only matters in NAT mode, because DSR keeps the return direction off the box. Layer 7 processing lowers all three, the trade discussed under Layer 4 versus Layer 7.