FOUNDRYNETNo. 001SEPTEMBER 2026SECTION 01LOAD BALANCING
Server Load Balancing Guide
Four guides on distributing traffic across servers and sites, from the connection table up to the URL. The section inherits the ServerIron documentation that engineers linked to for a decade and restates it for any load balancer you run today.
01 /Contents
- 01Server Load Balancing: VIPs, Real Servers and Health ChecksGuide
A server load balancer presents one virtual IP for a pool of real servers, spreads connections across the pool and drops any member that fails a health check.
- 02Global Server Load Balancing (GSLB): DNS-Based Site SelectionGuide
GSLB steers each client to the best data centre by answering DNS queries with the address of a site that is healthy, close and not overloaded.
- 03Session Persistence on a Load Balancer: Sticky Session MethodsGuide
Persistence, or sticky sessions, makes a load balancer send a returning client to the same real server it used before, because the application keeps state there.
- 04Layer 4 vs Layer 7 Load Balancing: What Each Layer SeesGuide
A Layer 4 balancer forwards on addresses and ports. A Layer 7 balancer reads the request and routes on URL, header or cookie. It sees more and costs more.
01.1 /Orientation
A load balancer sits between clients and a pool of servers and decides, per connection or per request, which server answers. The client sees one address, the virtual IP; the balancer keeps a table of real servers, checks that each one is alive, and forwards traffic according to a method such as round robin or least connections. That single sentence hides most of the interesting engineering: what a health check should test, what happens to an open connection when a server fails, how a shopping cart survives being sent to a different server, and how a company with two data centres steers a user to the nearer one before the first packet is sent.
The guides are ordered the way a deployment is designed. Server load balancing covers the local case: VIPs, methods, health checks, NAT versus direct server return, and high availability of the balancer itself. Global server load balancing moves the decision into DNS so that whole sites can fail over or share load. Session persistence deals with the stateful applications that break under naive balancing, and Layer 4 versus Layer 7 explains what the balancer can see at each layer, what that visibility costs, and when content switching is worth it.
Foundry Networks sold this function as the ServerIron family, marketed first as a web switch and later as an application switch. The configuration model was simple and has aged well as a teaching device: define real servers, define a virtual server, bind ports, attach health checks. The guides show that shape where it helps, always labelled as illustrative, and the ServerIron profile in the archive covers the hardware itself. Nothing in this section requires that hardware; the concepts map directly onto any modern appliance, software balancer or cloud service.
Two habits separate load balancing that works from load balancing that pages you at night. First, health checks must test what the client needs, not what is convenient: a TCP handshake on port 443 proves nothing about the application behind it. Second, persistence should be the exception, designed in deliberately with a timeout, not a default that hides a stateful application until the day a server is drained. Both points recur throughout the section because both are where the original documentation was quietest.
The recovered documents listed in the margin were the ServerIron server load balancing configuration chapters, the GSLB and URL switching application notes, the session persistence note and the application availability solution page. Their subjects are covered here in current terms; the documents themselves are not reproduced.