Global server load balancing (GSLB) is a way of distributing users across two or more data centers, cloud regions or providers that all run the same application. When a user tries to connect, GSLB decides which location should serve them based on rules such as which sites are healthy, which is closest or fastest for that user, and how busy each one is. If one location fails, GSLB stops sending users there. It is a common building block for applications that need to stay available through a site outage or serve users in many regions.
At a glance
- Operates across sites or regions, choosing where a user goes before a local load balancer chooses a server.
- Most commonly works through the Domain Name System (DNS), answering each lookup with the address of the best location.
- Uses health checks so traffic moves away from a failed or degraded site.
- Routing policies can be based on geography, measured performance, weighting or failover priority.
- Available as appliance features, software, and managed DNS or traffic management services.
What problem it solves
An application that runs in a single data center or cloud region is exposed to a single point of failure: a power event, network outage or regional cloud incident takes it offline for everyone. Users far from that location also experience higher latency. Running the application in more than one place solves part of the problem, but users still need a way to reach the right copy and to be moved when one copy fails.
GSLB provides that steering. It keeps users pointed at healthy locations, can send them to the nearest or fastest site, and makes active-active or active-standby designs work without users changing anything. For disaster recovery, it can turn a manual DNS change during a crisis into an automated, tested policy.
How it works
DNS-based steering. The most common approach. The GSLB system acts as the authoritative DNS server for the application’s name. When a user’s resolver asks for the address, GSLB returns the address of the location chosen by its policy. A short time-to-live (TTL) on the answer encourages clients to check back often, so changes take effect sooner, though caching behavior varies.
Health monitoring. GSLB continuously checks each location, from simple reachability tests to checks that the application itself responds correctly. A location that fails its checks is removed from the answers until it recovers.
Routing policies. Common policies include geographic (send users to the site in their region, which can also support data residency rules), performance-based (send users to the site with the lowest measured latency), weighted (split traffic by percentage, for example during a migration) and failover (use the primary site unless it is down).
Anycast and proxy approaches. Some providers announce the same IP address from many locations, so the internet’s routing delivers each user to a nearby point, which then forwards traffic to a healthy origin. This can react faster than DNS because it does not depend on clients refreshing cached answers.
Behind GSLB. Each location still needs its own load balancing, capacity to absorb traffic moved from a failed site, and a way to keep application data synchronized. GSLB only handles the steering.
For multi-site and multi-provider designs, see our multi-cloud and cloud content delivery network pages.
When it matters for buyers
- Designing for regional outages. If an application must survive the loss of a data center or cloud region, GSLB is often how users are moved.
- Going multi-cloud. Steering across providers usually requires a GSLB service that isn’t tied to one of them.
- Serving users in several regions. Directing users to a nearby site can improve response times and help keep data in-region.
- Migrations. Weighted routing lets you shift traffic gradually from an old platform to a new one and roll back quickly.
- High availability claims. Ask how failover is actually triggered and how long it takes in practice.
Questions to ask vendors
- Is steering DNS-based, anycast-based or proxy-based, and what failover time should we expect in practice?
- What health checks are available, and can they test the application rather than just the server?
- Which routing policies are supported: geographic, latency, weighted, failover?
- Can it steer to endpoints in any cloud or data center, or only within your platform?
- How is it priced: per DNS query, per health check, per endpoint or a flat fee?
- What is the SLA for the GSLB service itself, and how is it protected from DDoS attacks?
- How do we test failover without disrupting users?
How it differs from a load balancer
A load balancer sits in front of a group of servers in one location and spreads requests among them, usually by passing traffic through itself. GSLB works a level higher, choosing which location a user goes to, and in its DNS-based form it never touches the application traffic at all; it only answers the question “where should this user connect?” That means DNS-based GSLB is limited by DNS caching in a way a local load balancer is not. The two are complementary: GSLB picks the site or region, and a load balancer there picks the server. A content delivery network is different again, serving cached content from its own edge rather than steering users to your sites.