Global Server Load Balancing (GSLB): DNS-Based Site Selection

01 /How DNS-based GSLB works

Every connection begins with a name lookup. If the authoritative answer for www.example.com can vary per query, it can point each client at the data centre best placed to serve it. A GSLB device is an authoritative DNS server, or a proxy in front of one, that orders the A and AAAA records it returns based on live measurements of each site.

Each site runs its own local server load balancer with a VIP. GSLB decides which VIP to advertise; local SLB decides which real server behind it takes the connection. The ServerIron generation could do both on one box.

02 /The authoritative DNS proxy model

There are two ways into the resolution path. The first makes the GSLB device the authoritative server for the zone. The second, which the original Foundry GSLB application note described for the ServerIron, is the proxy model: the existing authoritative servers stay in place, the GSLB device fronts them on a VIP and inspects each response on the way out. When a response contains addresses of sites it monitors, it reorders them so the preferred site comes first.

03 /Site selection metrics

The device evaluates a chain of metrics per query and stops at the first that yields a single winner. The order is configurable; a typical chain runs health, then proximity or RTT, then load, then a tie-breaker.

04 /TTL trade-offs and DNS caching

GSLB only works if resolvers come back and ask again; the TTL on the returned record controls that. A short TTL (30 to 60 seconds) drains a failed site within a minute, at the price of many more queries and slightly higher latency on first connections. A long TTL is cheap but pins clients to a dead site until it expires.

Real caching is worse than the TTL implies. Some resolvers clamp low TTLs to a floor. Browsers and operating systems keep their own caches. Some runtimes resolve a name once at start-up and never again. Plan for a tail of clients arriving at the old site long after expiry, and keep the old VIP answering or redirecting for them.

05 /Anycast versus GSLB

IP anycast announces the same prefix from several sites and lets BGP route each client to the topologically nearest one. It needs no DNS tricks and reacts to site failure at routing-convergence speed. It suits stateless, short-transaction services such as DNS itself, and long-lived TCP sessions poorly, because a mid-session route change lands the client on a site with no record of the connection. GSLB reacts more slowly but keeps each session on one site and can weigh load and health, not just topology. Many deployments run anycast for DNS and GSLB for the application; see core routing.

06 /Active/active versus active/DR sites

In an active/active design every site serves traffic and GSLB spreads clients by proximity or load. It uses all the hardware and proves every site daily, but the application must tolerate users split across sites, which usually means replicated state. In an active/DR design GSLB returns only the primary site while healthy and switches every answer to the standby when checks fail. It is simpler and the standby can be smaller, but the failover path runs only during incidents, so test it on a schedule.

07 /How GSLB and local SLB fit together

GSLB health checks target the site VIP; when the local balancer marks every real server down, the VIP fails and GSLB stops advertising the site. Local SLB handles persistence, Layer 7 switching and server-level failover inside the site. Keep the GSLB check interval longer than the local one so a single server restart does not flap the site out. The load balancing hub follows this two-tier model.