Skip to content

GSLB Load Balancing#

Deep Thought spent seven and a half million years computing and came up with "42." Our load balancer decides in a fraction of a millisecond: which server should handle this request? And the answer is always more useful than "42."

GSLB (Global Server Load Balancing) is a DNS-based traffic routing system. When visitors access your domain, GSLB returns the IP address of the most suitable server, distributing traffic intelligently. Server down? It automatically routes to a healthy one. Before the end of the universe, that is.

How It Works#

In traditional DNS, a domain points to a single IP address. With GSLB, you create a pool, add multiple servers, and choose an algorithm. The rest is automatic:

  1. A visitor types app.yourcompany.com
  2. The DNS query reaches VeriTeknik name servers
  3. GSLB selects the best server based on the pool's algorithm
  4. The selected server's IP address is returned to the visitor
  5. The visitor connects directly to that server

This happens on every DNS query — traffic is continuously and intelligently distributed. No Improbability Drive, just pure logic.

Creating a Pool#

  1. Go to the GSLB menu
  2. Click New Pool
  3. Fill in the form:
    • FQDN — the domain to load balance (e.g. app.example.com)
    • Algorithm — the traffic distribution method (details below)
    • TTL — DNS response cache duration, in seconds
  4. Click Add Member to add your servers:
    • Name — a label for the server
    • IP Address — the server's IPv4 or IPv6 address
    • Weight — (for weighted algorithm) traffic share
    • Priority — (for failover algorithm) backup order
  5. Save — the pool goes live immediately

A note about FQDNs

The FQDN you create a GSLB pool for must be managed by VeriTeknik name servers. If you're using another provider's DNS, migrate your domain management to VeriTeknik first — otherwise the pool won't work. It's like writing your address on the wrong planet.

Algorithms#

Each pool runs an algorithm. The algorithm determines which server is selected for every incoming DNS query.

Round-Robin#

Cycles through servers in order: A, B, C, A, B, C... The simplest way to evenly distribute traffic across equally capable servers. No need to think like Deep Thought — whose turn is it?

When to use: All servers have equal capacity and simple distribution is sufficient.

Weighted#

You assign a weight value to each server. Higher weight means more traffic. For example: A=70, B=30 means roughly 70% goes to A and 30% to B.

When to use: Proportional distribution across servers with different capacities. Also ideal for gradually bringing a new server online (canary deployment).

Failover#

All traffic goes to the primary server as long as it's running. If it goes down, the next-priority server takes over. Like always carrying your towel — the point is being prepared.

Each member gets a priority value (lower number = higher priority). If multiple servers share the same priority, round-robin is used among them.

When to use: Active-passive configuration. One server is always primary, the others are standby.

Least-Queue#

Selects the server with the lowest queue depth at any given moment. Uses the queueDepth metric reported via the VT GSLBaaS protocol.

When to use: Your servers support the VT GSLBaaS protocol and you want distribution based on real-time workload.

Latency#

Selects the server with the lowest response time. Uses the execTimeMs metric reported via the VT GSLBaaS protocol.

When to use: Optimizing user experience — the fastest-responding server always gets priority.

Periodic#

Rotates between servers based on TTL intervals. For example, with TTL=30 seconds and 3 servers: first 30 seconds to A, next 30 to B, next 30 to C, then back to A. Set the clock, servers take shifts.

When to use: When you want different servers active during specific time windows. Useful for maintenance windows or planned transitions.

Geo (Geographic)#

Selects the server closest to the visitor's geographic location.

Coming Soon

The geographic algorithm is currently in development. When active, it will integrate with the MaxMind GeoIP database. For now, it falls back to weighted — which isn't bad, but not quite as good as Zaphod trying to navigate with two heads pointing in different directions.

Health Checks#

GSLB's real power lies in health checks. When a server goes down, it's automatically removed from the pool and traffic routes to healthy servers. Unlike Sirius Cybernetics products, it actually works.

HTTP / HTTPS Check#

Regularly sends requests to the URL you specify. If it receives an HTTP 2xx response, the server is healthy; otherwise it's marked unhealthy.

Health check configuration:

  • Check URL — the address to monitor (e.g. https://app.example.com/health)
  • Check interval — how often to check (default: 60 seconds)

VT GSLBaaS Protocol#

For advanced health checking, your application can report metrics from the /.well-known/gslb endpoint:

{
  "status": "healthy",
  "queueDepth": 5,
  "execTimeMs": 42
}
Field Description
status healthy or unhealthy — the server's state
queueDepth Number of pending requests — used by least-queue algorithm
execTimeMs Average response time (ms) — used by latency algorithm

42 ms

If your response time is genuinely 42 ms, congratulations — you're running at the same speed as the Ultimate Answer to the Ultimate Question. And that's a pretty solid response time.

Integrating with Your Application#

To integrate the VT GSLBaaS protocol, simply create a /.well-known/gslb endpoint in your application. The GSLB system will periodically call this endpoint to retrieve your server's status and metrics.

Node.js / Express#

const os = require('os');

// Simple request counter
let activeRequests = 0;

app.use((req, res, next) => {
  activeRequests++;
  res.on('finish', () => activeRequests--);
  next();
});

app.get('/.well-known/gslb', (req, res) => {
  const startTime = Date.now();

  // Application health check — database, cache, etc.
  const isHealthy = checkDatabaseConnection() && checkCacheConnection();

  res.json({
    status: isHealthy ? 'healthy' : 'unhealthy',
    queueDepth: activeRequests,
    execTimeMs: Date.now() - startTime
  });
});

Python / Flask#

import time
import threading

active_requests = 0
lock = threading.Lock()

@app.before_request
def track_request_start():
    global active_requests
    with lock:
        active_requests += 1

@app.after_request
def track_request_end(response):
    global active_requests
    with lock:
        active_requests -= 1
    return response

@app.route('/.well-known/gslb')
def gslb_health():
    start = time.time()

    # Application health check
    healthy = check_database() and check_redis()

    return jsonify({
        'status': 'healthy' if healthy else 'unhealthy',
        'queueDepth': active_requests,
        'execTimeMs': round((time.time() - start) * 1000)
    })

PHP / Laravel#

// routes/web.php
Route::get('/.well-known/gslb', function () {
    $start = microtime(true);

    // Application health check
    try {
        DB::connection()->getPdo();
        $healthy = true;
    } catch (\Exception $e) {
        $healthy = false;
    }

    return response()->json([
        'status'     => $healthy ? 'healthy' : 'unhealthy',
        'queueDepth' => DB::table('jobs')->count(),
        'execTimeMs' => round((microtime(true) - $start) * 1000),
    ]);
});

Nginx (Static Server)#

If your application serves static files or runs behind a proxy, you can return a health response directly from Nginx:

location = /.well-known/gslb {
    default_type application/json;
    return 200 '{"status":"healthy","queueDepth":0,"execTimeMs":1}';
}

Limitations of static responses

A static Nginx response always returns the same values — it doesn't reflect actual queue depth or response time. This makes it suitable only for basic health checks (healthy/unhealthy). If you're using least-queue or latency algorithms, you need to return metrics from your application. Otherwise it's like Deep Thought spending 7.5 million years thinking and coming up with "42" — technically correct, but not terribly useful.

Response requirements

  • The endpoint must return HTTP 200 (the status field in the response body determines health state)
  • Must set Content-Type: application/json
  • Response time must be under 5 seconds, otherwise it's treated as a timeout
  • queueDepth and execTimeMs fields are optional — only required if you're using the corresponding algorithm

TTL Settings#

TTL (Time to Live) determines how long a DNS response is cached on the client side. Lower TTL means more frequent updates; higher TTL means fewer DNS queries.

Scenario Recommended TTL
High availability, fast failover 10–30 seconds
General load balancing 30–60 seconds
Stable configuration, few changes 300+ seconds

Don't set TTL too low

TTL=1 might look appealing, but it creates unnecessary load on your DNS servers. Going below 10 seconds is like Zaphod trying to look in two different directions with both heads at once — technically possible, but nobody benefits.

Monitoring Pool Status#

On the GSLB page, you can see the current status of each pool:

  • Pool name and FQDN — which domain is being load balanced
  • Algorithm — the active distribution method
  • Member count and status — how many servers are healthy vs. unhealthy
  • Last update — when the configuration was last pushed to name servers

Detailed info per member:

  • IP address — the server's address
  • Status — healthy (green) or unhealthy (red)
  • Weight / Priority — algorithm parameters
  • Metrics — queue depth, response time (with VT GSLBaaS)

Live Demo#

Want to see GSLB in action? Our live demo page is made for exactly that:

https://gslb-demo.veriteknik.com

Every time you refresh the page, a different server responds based on the GSLB algorithm. You can tell which location served you by the colored badge — Ankara is red, Bursa is green, Istanbul is blue. The page also shows live CPU, memory, queue depth, and response time metrics.

Hit F5 a few times. Like a hitchhiker sticking out their thumb and getting picked up by different ships — a different server greets you each time.

GSLB Test Tool#

We provide a ready-made Docker image to test your own GSLB configuration. It runs a minimal web service that displays location-specific colors and metrics, and supports the VT GSLBaaS health check format.

Setup#

# Pull the image
docker pull ghcr.io/veriteknik/gslb-test:latest

# Run on your Ankara server
docker run -d --name gslb-ankara \
  -e LOCATION=Ankara \
  -e PORT=3080 \
  -p 3080:3080 \
  ghcr.io/veriteknik/gslb-test:latest

# Run on your Bursa server
docker run -d --name gslb-bursa \
  -e LOCATION=Bursa \
  -e PORT=3080 \
  -p 3080:3080 \
  ghcr.io/veriteknik/gslb-test:latest

Step-by-Step Testing#

  1. Deploy the services — Run a container on each server (as above)
  2. Create a GSLB pool — From the Ops Hub panel:
    • FQDN: gslb-test.yourdomain.com
    • Algorithm: Choose the algorithm you want to test
    • TTL: 10 seconds (for quick rotation)
  3. Add members — For each location:
    • Name: Ankara / Bursa
    • Address: Server IP address
    • Health Check URL: http://<ip>:3080/health
    • Health Check Type: VT GSLBaaS
  4. Open in browser — Navigate to gslb-test.yourdomain.com
  5. Refresh with F5 — You'll see a different location badge each time

Test Endpoints#

Endpoint Description
GET / Location info and live metrics (CPU, RAM, queue)
GET /health Health response in VT GSLBaaS format
GET /api/info JSON metadata (location, hostname, uptime)

Location Colors#

Location Color
Ankara Red
Bursa Green
Istanbul Blue
Izmir Purple
Frankfurt Yellow
Amsterdam Teal

Load simulation

The test service increases CPU and memory metrics proportionally to request count. This lets you test least-queue or latency algorithms under realistic conditions. Send many requests to one server and watch traffic shift to the other.

Source code: github.com/VeriTeknik/gslb-test

Need help?

Configuring GSLB doesn't have to be as complex as computing the Ultimate Answer. But if you'd like a hand, we're here. Write to destek@veriteknik.com.tr — we respond faster than Deep Thought. Promise.