How to Configure Global Server Load Balancing

Global Server Load Balancing (GSLB) distributes traffic across geographically dispersed data centres using DNS. When a client resolves your service hostname, Tula's built-in GSLB engine (powered by gdnsd) returns the IP address of the most appropriate site based on health, proximity, or configured policy. This enables active-active multi-site architectures, geographic routing, and automatic disaster recovery at the DNS layer.

Prerequisites

• Multiple sites with Tula load balancers -- Each site should have working VIPs configured and serving traffic.
• Public IP addresses -- Each site needs a publicly routable VIP address that clients can reach.
• DNS delegation -- You must be able to delegate a DNS zone or subdomain to the Tula GSLB nodes.
• Network reachability -- The GSLB nodes must be able to reach VIP addresses at each remote site for health monitoring.

Step 1: Configure GSLB Zones

A GSLB zone defines the DNS domain that Tula will be authoritative for.

1. Navigate to GSLB > Zones in the Tula web interface and click Add Zone.
2. Enter the zone name -- the DNS domain or subdomain you are delegating to Tula (e.g., lb.example.com).
3. Configure the SOA record: primary nameserver FQDN (e.g., ns1.lb.example.com), contact email, and default TTL. A lower TTL (30-60 seconds) allows faster failover but increases query volume; a higher TTL (300 seconds) reduces load but slows failover.
4. Click Save.

Step 2: Add Site Records

Each site is represented as a DNS record within the GSLB zone. These records map to the VIP addresses at each data centre.

1. Navigate to GSLB > Records within your zone.
2. Click Add Record.
3. Configure the record:
   • Name: The hostname within the zone (e.g., www creates www.lb.example.com).
   • Type: Select A for IPv4 or AAAA for IPv6.
   • Sites: Add each site with its corresponding VIP address and a descriptive label (e.g., london-dc, frankfurt-dc).
4. Repeat for additional hostnames as needed.
5. Click Save.

Step 3: Configure Health Monitors for Remote Sites

GSLB health monitors ensure that Tula only returns DNS answers for healthy sites.

1. Navigate to GSLB > Health Monitors and click Add Monitor.
2. Configure: Target (remote VIP address), Check Type (TCP, HTTP, or HTTPS), Port, Interval (e.g., 10 seconds), Timeout (e.g., 5 seconds), and Failure threshold (consecutive failures before marking the site down).
3. Associate the monitor with the appropriate GSLB record.
4. Click Save.

Step 4: Set Up Routing Policy

Tula supports multiple GSLB routing policies that determine how traffic is distributed across sites.

• Failover (active-passive): All traffic goes to the primary site. If it fails, traffic shifts to the secondary. Best for disaster recovery.
• Round Robin: DNS responses rotate through all healthy sites equally. Simple and effective for even distribution.
• Weighted: Each site receives a proportion of traffic based on configured weights. Use this when sites have different capacities.
• GeoIP: Clients receive the IP of the geographically nearest site based on their source IP address. Requires a GeoIP database (Tula includes MaxMind GeoLite2 support).

To configure the policy:

1. In the GSLB record configuration, select the Routing Policy.
2. For Weighted routing, assign a weight to each site.
3. For GeoIP routing, assign geographic regions to each site and ensure the GeoIP database is loaded under System > GeoIP.
4. Click Save.

Step 5: Update DNS NS Records

Delegate the GSLB zone to your Tula nodes at your registrar or parent DNS provider:

1. Create NS records: lb.example.com. NS ns1.lb.example.com. (and ns2).
2. Create glue A records: ns1.lb.example.com. A <tula-node-1-ip> (and ns2).
3. Wait for propagation (typically minutes, up to 48 hours depending on parent zone TTL).

Step 6: Apply Configuration and Test

1. Click Apply Configuration in the Tula web interface.
2. Test DNS resolution from a client:

dig www.lb.example.com @<tula-node-ip>

3. Verify that the response returns the expected site IP. Repeat from different network locations if testing GeoIP routing.
4. Test failover by disabling a site's VIP and confirming that DNS responses update within the configured TTL plus health check interval.

TTL Recommendations

Keep in mind that some recursive resolvers may not honour low TTLs, so plan for a worst-case failover window of several minutes regardless of your configured TTL.