# Global Server Load Balancing (GSLB): Dienste weltweit orchestrieren

TL;DR / Management Summary Während lokaler Loadbalancer den Traffic innerhalb eines Rechenzentrums verteilt, sorgt Global Server Load Balancing (GSLB) für die Verteilung über Kontinente hinweg. Ein Senior Admin nutzt GSLB (meist via DNS oder Anycast), um User zum geografisch nächsten RZ zu leiten (Latenz-Optimierung) und um im Falle eines Totalausfalls eines Standorts den Traffic vollautomatisch global umzuleiten. Es ist die ultimative Form der Hochverfügbarkeit für globale Unternehmen.

# 1. Konzepte des GSLB

DNS als Schiedsrichter.

In 90% der Fälle wird GSLB über das DNS-Protokoll realisiert.

  1. Request: User fragt wiki.de an.
  2. GSLB Controller: Prüft die Quell-IP des Users.
  3. Entscheidung:
    • User kommt aus Berlin -> Antwort: IP des RZ Frankfurt.
    • User kommt aus New York -> Antwort: IP des RZ Virginia.
  4. Health Check: Ist das RZ Frankfurt offline, liefert der GSLB Controller für den Berliner User automatisch die IP von Virginia zurück.

# 2. Anycast vs. DNS-GSLB

Zwei Wege zum Ziel.

# 1. Anycast (Artikel 576)

Mehrere Standorte haben die exakt gleiche IP. Das BGP-Routing im Internet leitet das Paket zum physisch nächsten Hop.

# 2. DNS-GSLB (Standard)

Der DNS-Server antwortet dynamisch mit unterschiedlichen IPs.

# 3. Deep Dive: Geo-IP Routing & Proximity

Die beste User-Experience.

Professionelle GSLB-Systeme (wie F5 BIG-IP DNS) nutzen Latenz-Tabellen.

# 4. Day-2 Operations: Disaster Recovery Schwenk

Den ‘Big Red Button’ vorbereiten.

GSLB ist der Schlüssel zum standortübergreifenden DR (Artikel 606).

# 5. Troubleshooting & “War Stories”

Wenn die Welt auf dem Kopf steht.

# Top 3 Fehlerbilder

  1. Symptom: User in Deutschland landen auf dem US-Server.

    • Ursache: Der User nutzt einen öffentlichen DNS (wie 8.8.8.8). Der GSLB-Server sieht nur die IP des Google-Resolvers (USA) und nicht die des Users.
    • Lösung: Nutzung von EDNS-Client-Subnet (ECS). Der Resolver gibt einen Teil der User-IP an den GSLB weiter.

  2. Symptom: “Flapping” zwischen Standorten.

    • Ursache: Identische Latenzwerte zu beiden RZs. Das System springt bei jeder kleinen Schwankung hin und her.
    • Lösung: Hysterese und feste Prioritäten (Tiering) einführen.

  3. Symptom: Kapazitäts-Überlauf am kleinen Standort.

    • Fix: Nutzen Sie “Overflow-Routing”. Wenn RZ-A zu 80% ausgelastet ist, schickt GSLB neue User zu RZ-B, auch wenn die Latenz dort höher ist.

# “War Story”: Die “DNS-Caching” Katastrophe

Ein Admin verließ sich für sein DR auf ein GSLB-System mit einer TTL von 1 Stunde. Das Ereignis: Ein Stromausfall im Haupt-RZ legte alles lahm. Der GSLB schaltete sofort um. Das Ergebnis: Die Hälfte der User konnte 60 Minuten lang nicht arbeiten, da ihre Firmen-PCs oder lokalen ISPs die “alte” (tote) IP noch im Cache hatten. Lehre: Für GSLB-Infrastrukturen sind TTLs von 30 bis 60 Sekunden Pflicht. GSLB ist nur so agil wie sein langsamster Cache.

# 6. Monitoring & Reporting

Die globale Verfügbarkeit.

# Global Health Dashboard

Überwachen Sie in Echtzeit:

# 7. Fazit & Empfehlung

GSLB ist die Versicherung gegen regionale Katastrophen.

# Anhang: Cheatsheet (GSLB Strategien)

Strategie Logik Anwendungsfall
Failover Primär / Sekundär Klassisches DR
Geolocation Nach Land / IP Compliance (Datenhoheit)
Proximity Beste Latenz Performance (Web-Apps)
Weighted % Verteilung Migrationen / Canary

# Referenzen