Ana içeriğe geç

GSLB Yük Dengeleme#

Derin Düşünce, yedi buçuk milyon yıl hesap yaptı ve sonuç olarak "42" dedi. Bizim yük dengeleyicimiz ise saniyenin binde birinde karar verir: bu isteği hangi sunucuya gönderelim? Ve cevabı her zaman "42"den daha kullanışlıdır.

GSLB (Global Server Load Balancing), DNS tabanlı bir trafik yönlendirme sistemidir. Ziyaretçiler domaininize eriştiğinde, GSLB en uygun sunucunun IP adresini döndürerek trafiği akıllıca dağıtır. Sunucu çöktü mü? Otomatik olarak sağlıklı olana yönlendirir. Evrenin sonu gelmeden, yani.

Nasıl Çalışır?#

Klasik DNS'te bir domain tek bir IP adresine işaret eder. GSLB'de ise bir havuz (pool) oluşturur, birden fazla sunucu ekler ve bir algoritma seçersiniz. Gerisi otomatik:

  1. Ziyaretçi uygulama.sirketiniz.com adresini yazar
  2. DNS sorgusu VeriTeknik ad sunucularına ulaşır
  3. GSLB havuzundaki algoritmaya göre en uygun sunucu seçilir
  4. Seçilen sunucunun IP adresi ziyaretçiye döndürülür
  5. Ziyaretçi doğrudan o sunucuya bağlanır

Bu işlem her DNS sorgusunda tekrarlanır — böylece trafik sürekli, akıllıca dağıtılır. Olasılıksızlık Motoru değil, saf mantık.

Havuz Oluşturma#

  1. GSLB menüsüne gidin
  2. Yeni Havuz butonuna tıklayın
  3. Formu doldurun:
    • FQDN — yük dengelenecek alan adı (ör. app.ornek.com)
    • Algoritma — trafik dağıtım yöntemi (detaylar aşağıda)
    • TTL — DNS yanıtının önbellek süresi, saniye cinsinden
  4. Üye Ekle ile sunucularınızı ekleyin:
    • Ad — sunucu tanımlayıcı ismi
    • IP Adresi — sunucunun IPv4 veya IPv6 adresi
    • Ağırlık — (weighted algoritması için) trafik payı
    • Öncelik — (failover algoritması için) yedekleme sırası
  5. Kaydet — havuz hemen aktif olur

FQDN hakkında bir not

GSLB havuzu oluşturduğunuz FQDN, VeriTeknik ad sunucularınız tarafından yönetilen bir domain olmalıdır. Başka bir sağlayıcının DNS'ini kullanıyorsanız, önce domain yönetiminizi VeriTeknik'e taşıyın — yoksa havuz çalışmaz. Adresinizi yanlış gezegene yazdırmak gibi bir şey olur.

Algoritmalar#

Her havuz bir algoritma ile çalışır. Algoritma, gelen her DNS sorgusunda hangi sunucunun seçileceğini belirler.

Round-Robin#

Sunucuları sırayla döner: A, B, C, A, B, C... Eşit güçteki sunucular arasında trafiği eşit dağıtmanın en basit yolu. Derin Düşünce gibi düşünmeye gerek yok — sıra kimde?

Ne zaman kullanılır: Tüm sunucular eşit kapasitedeyse ve basit dağıtım yeterliyse.

Weighted (Ağırlıklı)#

Her sunucuya bir ağırlık değeri atarsınız. Ağırlığı yüksek olan sunucu daha fazla trafik alır. Örneğin: A=70, B=30 ise trafiğin yaklaşık %70'i A'ya, %30'u B'ye gider.

Ne zaman kullanılır: Farklı kapasitedeki sunucular arasında orantılı dağıtım istiyorsanız. Yeni sunucuyu yavaşça devreye almak (canary deployment) için de idealdir.

Failover (Yedekleme)#

Birincil sunucu çalıştığı sürece tüm trafik ona gider. Çökerse, bir sonraki öncelikli sunucu devreye girer. Havluyu her zaman yanınızda taşımak gibi — asıl olan hazırlıklı olmaktır.

Her üyeye bir öncelik değeri atanır (düşük sayı = yüksek öncelik). Aynı öncelikteki birden fazla sunucu varsa aralarında round-robin yapılır.

Ne zaman kullanılır: Aktif-pasif yapılandırma istiyorsanız. Bir sunucu her zaman öncelikli, diğerleri yedek.

Least-Queue (En Az Kuyruk)#

Anlık kuyruk derinliği en düşük olan sunucuyu seçer. VT GSLBaaS protokolü üzerinden raporlanan queueDepth metriğini kullanır.

Ne zaman kullanılır: Sunucularınız VT GSLBaaS protokolünü destekliyorsa ve gerçek zamanlı iş yüküne göre dağıtım istiyorsanız.

Latency (Gecikme)#

En düşük yanıt süresine sahip sunucuyu seçer. VT GSLBaaS protokolü üzerinden raporlanan execTimeMs metriğini kullanır.

Ne zaman kullanılır: Kullanıcı deneyimini optimize etmek istiyorsanız — en hızlı yanıt veren sunucu her zaman önceliklidir.

Periodic (Dönemsel)#

TTL süresine göre sunucular arasında döner. Örneğin TTL=30 saniye ve 3 sunucu varsa: ilk 30 saniye A, sonraki 30 saniye B, sonraki 30 saniye C, sonra tekrar A. Saati kurun, sunucular nöbet değiştirir.

Ne zaman kullanılır: Belirli zaman dilimlerinde farklı sunucuları aktif tutmak istiyorsanız. Bakım pencereleri veya planlı geçişler için kullanışlıdır.

Geo (Coğrafi)#

Ziyaretçinin coğrafi konumuna göre en yakın sunucuyu seçer.

Yakında

Coğrafi algoritma şu anda geliştirme aşamasındadır. Aktif olduğunda MaxMind GeoIP veritabanı ile entegre çalışacaktır. Şimdilik weighted algoritmasına düşer — ki bu da fena değil, ama Zaphod'un iki başıyla yön bulmaya çalışması kadar da iyi değil.

Sağlık Kontrolleri#

GSLB'nin gerçek gücü sağlık kontrollerinde yatar. Bir sunucu çökerse, otomatik olarak havuzdan çıkarılır ve trafik sağlıklı sunuculara yönlendirilir. Sirius Sibernetik ürünlerinden farklı olarak, gerçekten çalışır.

HTTP / HTTPS Kontrolü#

Belirttiğiniz URL'ye düzenli olarak istek gönderir. HTTP 2xx yanıt alıyorsa sunucu sağlıklı, almıyorsa sağlıksız olarak işaretlenir.

Sağlık kontrolü yapılandırması:

  • Kontrol URL'si — sağlık kontrolü yapılacak adres (ör. https://app.ornek.com/health)
  • Kontrol aralığı — ne sıklıkta kontrol edilecek (varsayılan: 60 saniye)

VT GSLBaaS Protokolü#

Gelişmiş sağlık kontrolü için uygulamanız /.well-known/gslb endpointinden metrik raporlayabilir:

{
  "status": "healthy",
  "queueDepth": 5,
  "execTimeMs": 42
}
Alan Açıklama
status healthy veya unhealthy — sunucunun durumu
queueDepth Bekleyen istek sayısı — least-queue algoritması için
execTimeMs Ortalama yanıt süresi (ms) — latency algoritması için

42 ms

Eğer yanıt süreniz gerçekten 42 ms ise, tebrikler — Evrenin Nihai Sorusunun cevabıyla aynı hızdasınız. Ve bu oldukça iyi bir yanıt süresi.

Uygulamanıza Entegrasyon#

VT GSLBaaS protokolünü uygulamanıza entegre etmek için /.well-known/gslb endpointini oluşturmanız yeterli. GSLB sistemi bu endpoint'i periyodik olarak çağırarak sunucunuzun durumunu ve metriklerini alır.

Node.js / Express#

const os = require('os');

// Basit kuyruk sayacı
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();

  // Uygulama sağlık kontrolü — veritabanı, cache, vb.
  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()

    # Uygulama sağlık kontrolü
    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);

    // Uygulama sağlık kontrolü
    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 (Statik Sunucu)#

Uygulamanız statik dosya sunuyorsa veya proxy arkasındaysa, Nginx'ten doğrudan sağlık yanıtı döndürebilirsiniz:

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

Statik yanıtın sınırları

Nginx statik yanıtı her zaman aynı değerleri döner — gerçek kuyruk derinliği veya yanıt süresini yansıtmaz. Bu nedenle yalnızca basit sağlık kontrolü (healthy/unhealthy) için yeterlidir. least-queue veya latency algoritmalarını kullanıyorsanız, metrikleri uygulamanızdan döndürmeniz gerekir. Yoksa Deep Thought'un 7.5 milyon yıl düşünüp "42" demesi gibi — teknik olarak doğru ama pek işe yaramaz.

Yanıt gereksinimleri

  • Endpoint HTTP 200 dönmelidir (yanıt gövdesindeki status alanı sağlık durumunu belirler)
  • Content-Type: application/json olmalıdır
  • Yanıt süresi 5 saniyenin altında olmalıdır, aksi halde zaman aşımı sayılır
  • queueDepth ve execTimeMs alanları opsiyoneldir — yalnızca ilgili algoritmayı kullanıyorsanız gereklidir

TTL Ayarları#

TTL (Time to Live), DNS yanıtının istemci tarafında ne kadar süre önbelleğe alınacağını belirler. Düşük TTL daha sık güncelleme anlamına gelir, yüksek TTL ise daha az DNS sorgusu.

Senaryo Önerilen TTL
Yüksek erişilebilirlik, hızlı failover 10–30 saniye
Genel yük dengeleme 30–60 saniye
Kararlı yapılandırma, az değişiklik 300+ saniye

TTL çok düşük ayarlamayın

TTL=1 çekici görünebilir ama DNS sunucularınız üzerinde gereksiz yük oluşturur. 10 saniyenin altına inmek, Zaphod'un iki başıyla aynı anda iki farklı yöne bakmaya çalışması gibidir — teknik olarak mümkün, ama kimsenin işine yaramaz.

Havuz Durumunu İzleme#

GSLB sayfasında her havuzun güncel durumunu görebilirsiniz:

  • Havuz adı ve FQDN — hangi domain yük dengeleniyor
  • Algoritma — aktif dağıtım yöntemi
  • Üye sayısı ve durumu — kaç sunucu sağlıklı, kaçı sağlıksız
  • Son güncelleme — yapılandırma en son ne zaman ad sunucularına iletildi

Her üye için detaylı bilgi:

  • IP adresi — sunucunun adresi
  • Durum — sağlıklı (yeşil) veya sağlıksız (kırmızı)
  • Ağırlık / Öncelik — algoritma parametreleri
  • Metrikler — kuyruk derinliği, yanıt süresi (VT GSLBaaS ile)

Canlı Demo#

GSLB'nin nasıl çalıştığını görmek mi istiyorsunuz? Canlı demo sayfamız tam da bunun için var:

https://gslb-demo.veriteknik.com

Sayfayı her yenilediğinizde, GSLB algoritmasına göre farklı bir sunucu yanıt verir. Hangi lokasyondan geldiğini renkli badge'den anlarsınız — Ankara kırmızı, Bursa yeşil, İstanbul mavi. Sayfa ayrıca sunucunun CPU, bellek, kuyruk derinliği ve yanıt süresi metriklerini canlı olarak gösterir.

Birkaç kez F5'e basın. Otostopçunun başparmağını kaldırıp farklı araçlara binmesi gibi — her seferinde farklı bir sunucu sizi karşılar.

GSLB Test Aracı#

Kendi GSLB yapılandırmanızı test etmek için hazır bir Docker imajı sunuyoruz. Bu imaj, her lokasyon için farklı renk ve metriklerin gösterildiği minimal bir web servisi çalıştırır ve VT GSLBaaS health check formatını destekler.

Kurulum#

# İmajı çekin
docker pull ghcr.io/veriteknik/gslb-test:latest

# Ankara sunucusunda çalıştırın
docker run -d --name gslb-ankara \
  -e LOCATION=Ankara \
  -e PORT=3080 \
  -p 3080:3080 \
  ghcr.io/veriteknik/gslb-test:latest

# Bursa sunucusunda çalıştırın
docker run -d --name gslb-bursa \
  -e LOCATION=Bursa \
  -e PORT=3080 \
  -p 3080:3080 \
  ghcr.io/veriteknik/gslb-test:latest

Adım Adım Test#

  1. Servisleri deploy edin — Her sunucuya bir container kurun (yukarıdaki gibi)
  2. GSLB havuzu oluşturun — Ops Hub panelinden:
    • FQDN: gslb-test.sizindomain.com
    • Algoritma: Test etmek istediğiniz algoritmayı seçin
    • TTL: 10 saniye (hızlı geçiş görmek için)
  3. Üyeleri ekleyin — Her lokasyon için:
    • Ad: Ankara / Bursa
    • Adres: Sunucu IP adresi
    • Sağlık Kontrolü URL: http://<ip>:3080/health
    • Sağlık Kontrolü Tipi: VT GSLBaaS
  4. Tarayıcıda açın — gslb-test.sizindomain.com adresine gidin
  5. F5 ile yenileyin — Her yenilemede farklı lokasyon badge'i göreceksiniz

Test Endpointleri#

Endpoint Açıklama
GET / Lokasyon bilgisi ve canlı metrikler (CPU, RAM, kuyruk)
GET /health VT GSLBaaS formatında sağlık yanıtı
GET /api/info JSON metadata (lokasyon, hostname, uptime)

Lokasyon Renkleri#

Lokasyon Renk
Ankara Kırmızı
Bursa Yeşil
İstanbul Mavi
İzmir Mor
Frankfurt Sarı
Amsterdam Turkuaz

Yük simülasyonu

Test servisi CPU ve bellek metriklerini istek sayısına orantılı olarak artırır. Bu sayede least-queue veya latency algoritmalarını gerçekçi koşullarda test edebilirsiniz. Bir sunucuya çok istek gönderin, trafiğin diğerine kaydığını gözlemleyin.

Kaynak kodu: github.com/VeriTeknik/gslb-test

Yardım mı lazım?

GSLB yapılandırması, evrenin nihai cevabını bulmak kadar karmaşık olmak zorunda değil. Ama yine de yardım isterseniz biz buradayız. destek@veriteknik.com.tr adresinden yazın — Derin Düşünce'den daha hızlı yanıt veririz. Söz.