Transloadit

What is Global Server Load Balancing?

Global server load balancing routes clients among endpoints in different geographic regions. Decisions may incorporate endpoint health, latency, capacity, policy, or user location.

How Global Server Load Balancing works

GSLB is a vendor term rather than a protocol. RFC 3568 describes the same job as request routing and sorts the known mechanisms into DNS, transport-layer, and application-layer techniques. The DNS form is common because every client already resolves names: an authoritative name server answers the same name with different addresses according to policy, measurements, or both, and the address returned is often a virtual IP in front of a regional pool that does its own local load balancing. The other forms act later. Anycast announces one address from several sites and leaves the choice of site to network routing. An application-layer balancer either redirects the client, for example with an HTTP 302, or proxies the request and picks a region for each one. DNS and application-layer balancers can weigh network proximity or latency, load and capacity, health-check results, and rules such as geography or weights. Anycast on its own follows network routing only: RFC 3568 notes that routing protocols are typically not load sensitive and that server load is not considered, and a site keeps receiving traffic for as long as its route is announced, which is why RFC 4786 calls coupling the announcement to the service’s availability desirable.

Key facts

  1. How fast does DNS-based GSLB move traffic away from a failed region? Gradually, not at one moment. Detection comes first and depends on the check interval and on how many consecutive failed checks the balancer requires (Route 53 calls this the failure threshold). After the authoritative answer changes, lookups that are not served from a cache get the new answer, while a resolver that cached the old answer may keep using it for the rest of its TTL. The new answer names a region that passes its checks if one does; when none does, the balancer’s fallback rule applies, and Route 53, for example, returns the primary record when both records of a failover pair are unhealthy. A TTL is how long a resolver may use a cached answer before it has to ask again, and the balancer cannot recall an answer it has already given. A shorter TTL narrows the window and increases the query volume on the DNS servers. An answer can still outlive its TTL: RFC 3568 notes that many DNS implementations do not honor the TTL, and RFC 8767 lets a resolver keep serving an expired answer when its attempt to refresh it fails. The k8gb project reports downtime roughly equal to the DNS TTL when a service behind its GSLB fails; that is one project’s observation, not an upper bound. Changing the DNS answer also does not move connections that are already open: AWS notes for its DNS-based Region failover that existing connections take time to complete, depending on client behavior and connection reuse. Cloudflare lists slower failover as a limitation of its DNS-only load balancing compared with its proxied mode.
  2. Whose location does a DNS-based decision use? The recursive resolver’s, unless the resolver sends the EDNS Client Subnet option. Amazon Route 53 documents both cases: it uses the resolver’s source IP address when the resolver does not support the option and a shortened form of the user’s address when it does. RFC 7871, which describes the option, recommends that it be turned off by default for privacy reasons. A proxying balancer locates the client from the client’s own connection instead.
  3. What does a passing health check prove? Only what the check requests. In Route 53, a TCP health check passes once a connection is established, an HTTP or HTTPS check requires a 2xx or 3xx status code, and a string-matching check also requires given text in the response body; its HTTPS checks do not validate the certificate. A region whose front end accepts connections while the application behind it fails passes a TCP check. Pointing the check at a URL that exercises the dependencies your users need is a design choice you make, not something the balancer infers.
  4. Anycast or DNS steering? With anycast the routing system picks the site, so the choice does not depend on cached DNS answers, but the operator has limited control: RFC 4786 describes load distribution between anycast nodes as generally unbalanced, and says the routing decision has to stay stable for longer than a transaction, because one client-server interaction usually has to stay with the same node from start to finish. That matters for long-lived flows such as bulk downloads and media streaming. DNS GSLB can return different addresses by policy and inherits the caching limits above. The two are also combined, for example by giving the request-routing DNS servers themselves an anycast address.

When Global Server Load Balancing matters

GSLB matters once a service runs in more than one region and needs a rule for which region each client uses and what happens when a region fails. The mechanism you choose sets how quickly traffic moves and how accurately clients are located: DNS answers are cached, and location-based DNS policies see the resolver’s address unless the resolver passes on part of the client’s, while a proxying balancer decides per request but has every request pass through it.

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free