Global Server Load Balancing

Global Server Load Balancing (GSLB) distributes client traffic across multiple geographically dispersed data centres using DNS as the steering mechanism. Tula's GSLB implementation is powered by gdnsd, a high-performance authoritative DNS server with integrated health checking, geographic routing, and failover capabilities.

What is GSLB?

Traditional load balancers distribute traffic among servers within a single site. GSLB operates at a higher level, directing users to the most appropriate site before a connection is ever established. It does this by controlling DNS responses: when a client resolves a hostname, the GSLB-enabled DNS server returns the IP address of the optimal data centre based on geographic proximity, site health, or administrative policy.

This DNS-based approach is transparent to clients and requires no special software or configuration on end-user devices. Every device that performs DNS resolution -- browsers, mobile apps, APIs -- automatically benefits from GSLB routing decisions.

How DNS-Based GSLB Works

1. DNS query. A client (or its recursive resolver) sends a DNS query for your service hostname, e.g., app.example.com.
2. Geographic and health evaluation. The GSLB-enabled authoritative DNS server (gdnsd) evaluates the source IP of the query against its GeoIP database and checks the health status of each candidate site.
3. Intelligent response. The server returns the IP address of the site that best matches the routing policy -- typically the geographically nearest healthy site.
4. Client connects. The client connects directly to the selected site. Subsequent requests use the cached DNS response until the TTL expires.

Because routing decisions happen at the DNS layer, GSLB adds no latency to the data path. Once the client has resolved the hostname, all traffic flows directly to the selected site without passing through any intermediary.

Use Cases

Multi-site disaster recovery. Automatically redirect all traffic to a surviving data centre when the primary site goes offline. DNS-based failover ensures continuity without requiring clients to change URLs or update their configurations.

Geographic routing. Direct European users to your Frankfurt data centre and North American users to your New York site, reducing latency and improving user experience. Tula supports granular geographic mapping down to the country level using MaxMind GeoIP2 databases.

Latency-based routing. Route users to the site that provides the lowest response time, regardless of geographic proximity. This accounts for network path efficiency rather than simple distance.

Regulatory compliance. Keep traffic within specific jurisdictions by ensuring that users in regulated regions are always directed to data centres in approved locations.

Capacity distribution. Spread traffic across sites to prevent any single data centre from becoming overwhelmed, using weighted DNS responses to control the proportion of traffic each site receives.

GSLB vs Traditional Load Balancing

GSLB and traditional load balancing are complementary. A typical production deployment uses GSLB to select the data centre, then a local load balancer (L4 or L7) within that site to distribute traffic across individual servers. Tula provides both capabilities in a single platform.

Getting Started

To deploy GSLB with Tula, you will need:

• Two or more Tula nodes in different locations, each configured with local load balancing for the backend servers at that site.
• Authoritative DNS delegation. Your domain registrar or parent DNS zone must delegate the service hostname (or a subdomain) to your Tula GSLB nodes using NS records.
• Health checks configured for each site so that gdnsd can detect outages and reroute traffic.

See GeoIP Routing for configuring geographic traffic steering and GSLB Failover for setting up disaster recovery between sites.