GSLB-Failover: warum Clients länger am alten Standort bleiben

Ein Standort fällt aus. Der Monitor auf der NetScaler erkennt es nach gut zehn Sekunden, GSLB beantwortet die nächste DNS-Anfrage mit dem anderen Standort, alles arbeitet wie konfiguriert. Ein Teil der Clients verbindet sich trotzdem weiter mit dem ausgefallenen Standort. Der GSLB-Failover ist zu diesem Zeitpunkt auf der NetScaler abgeschlossen, bei diesen Clients aber noch nicht angekommen. Dieser Beitrag zeigt, woraus sich die Dauer zusammensetzt, gemessen an meiner Testinstanz.

Der Unterschied liegt im Pfad

Beim Load Balancing steht die NetScaler im Datenpfad. Jede Verbindung läuft über den virtuellen Server, die Appliance entscheidet bei jeder neuen Verbindung und kann jederzeit umlenken.

Bei GSLB steht die NetScaler im Pfad der Namensauflösung. Sie arbeitet als autoritativer DNS-Server (ADNS) und beantwortet eine Frage: welche Adresse zu einem Namen gehört. Danach verbindet sich der Client direkt mit dieser Adresse. Die GSLB-Entscheidung ist an der Verbindung selbst nicht mehr beteiligt. Der Name Global Server Load Balancing führt hier leicht in die Irre: Verteilt werden DNS-Antworten, die Verbindungen laufen an der GSLB-Instanz vorbei.

GSLB entscheidet also einmal pro Namensauflösung, nicht einmal pro Verbindung. Daraus ergeben sich die Verzögerungen, die im Folgenden gemessen sind.

Wer die Antwort danach behält

Eine DNS-Antwort trägt eine TTL. Sie legt fest, wie lange ein Zwischenspeicher die Antwort verwenden darf. Auf diese TTL hat die GSLB-Instanz Einfluss, auf die Zwischenspeicher selbst nicht. Zwischen GSLB-Instanz und Verbindung liegen mehrere davon:

• Der Resolver, den der Client fragt. Hinter einem Resolver stehen meist viele Clients, die alle dieselbe gespeicherte Antwort bekommen. Manche Resolver lassen sich so einstellen, dass sie Antworten länger behalten als die TTL vorgibt. Ein Windows-DNS-Server hält sich an die TTL: In meiner Testumgebung holte er eine Antwort mit 60 Sekunden TTL direkt nach Ablauf neu. Eine Mindestdauer lässt sich dort nicht einstellen, nur eine Obergrenze (MaxTtl, Standard ein Tag).
• Der Zwischenspeicher des Betriebssystems, unter Windows der DNS-Client-Dienst.
• Der Zwischenspeicher der Anwendung. Java etwa richtet sich nicht nach der TTL, sondern nach der Eigenschaft networkaddress.cache.ttl. Mit installiertem Security Manager ist der Standard „für immer“, ohne ist er implementierungsabhängig.
• Bestehende Verbindungen. Sie lösen nicht neu auf. Eine offene TCP-Verbindung zum ausgefallenen Standort bleibt bestehen, bis sie abbricht oder geschlossen wird.

Wie lange ein GSLB-Failover wirklich dauert

Auf meiner Testinstanz (NetScaler 14.1) habe ich einen GSLB-vServer, also den virtuellen Server, an den Domäne und Standorte gebunden werden, mit einer Domäne und zwei Diensten aufgebaut, jeder mit einem TCP-Monitor in Standardeinstellung, Lastverteilung im Wechsel (Round Robin). Den Ausfall habe ich nachgestellt, indem ich das Ziel eines Monitors auf eine nicht erreichbare Adresse umgestellt habe. Abgefragt wurde fortlaufend direkt an der ADNS-Adresse.

Messung	Ergebnis auf meiner Testinstanz
TTL in der Antwort ohne eigene Einstellung	5 Sekunden
TTL nach Setzen von -TTL 30 an der Domäne	30 Sekunden
Antwort pro Anfrage	eine Adresse, abwechselnd die beiden Dienste
Ziel antwortet nicht mehr (keine Antwort auf den Verbindungsaufbau)	Dienst DOWN 12,0 s nach der ersten fehlgeschlagenen Probe, viermal gleich
Ziel lehnt die Verbindung aktiv ab (TCP-Reset)	Dienst DOWN mit der ersten fehlgeschlagenen Probe, zweimal gleich
Letzte Antwort mit dem ausgefallenen Dienst	in derselben Zehntelsekunde wie der Wechsel auf DOWN

Die zwölf Sekunden ergeben sich aus den Standardwerten des Monitors: Intervall 5 s, Antwortzeit 2 s, drei Versuche. Die dritte Probe startet nach 10 s und gilt nach weiteren 2 s als fehlgeschlagen. Ab diesem Moment antwortet die GSLB-Instanz ohne den ausgefallenen Dienst. Fällt ein Ziel zwischen zwei Proben aus, kommt die Wartezeit bis zur nächsten Probe hinzu, bis zu 5 s. Bei Standardwerten liegt die Erkennung damit zwischen 12 und 17 Sekunden.

Damit endet der Teil, den die NetScaler steuert. Der gesamte Zeitraum setzt sich so zusammen:

Abschnitt	Wovon er abhängt	Bei Standardwerten
Erkennung	Monitor: interval, resptimeout, retries	12 bis 17 s, bei TCP-Reset bis 5 s
Neue Antwort	Zustand des GSLB-Dienstes	gleichzeitig mit der Erkennung
Resolver	TTL, eigene Mindestwerte des Resolvers	bis 5 s, mit Mindestwert länger
Betriebssystem	TTL	bis 5 s
Anwendung	eigene Regel der Anwendung	von 0 bis Prozessende
Bestehende Verbindung	Lebensdauer der Verbindung	bis zum Abbruch
Rückkehr eines Standorts	Monitor: downTime	ein Dienst auf DOWN wird erst nach 30 s erneut geprüft

Die ersten beiden Zeilen lassen sich auf der NetScaler einstellen und messen. Die übrigen liegen außerhalb der Appliance, die TTL setzt dort nur die Obergrenze für Zwischenspeicher, die sich an sie halten.

Die TTL ist kein Umschaltzeitpunkt

Eine niedrige TTL verkürzt nur den Abschnitt, in dem sich Zwischenspeicher an sie halten. Anwendungen mit eigener Regel, Resolver mit Mindestwert und bestehende Verbindungen bleiben davon unberührt.

Gleichzeitig hat eine niedrige TTL einen Preis: Die Zwischenspeicher fragen häufiger nach, die ADNS-Instanzen bekommen entsprechend mehr Anfragen, und ihre Erreichbarkeit wird zur Voraussetzung für jede neue Verbindung. Ein bewusst gewählter und begründeter Wert ist deshalb tragfähiger als der kleinstmögliche. Die NetScaler setzt ohne eigene Einstellung 5 Sekunden, geändert wird der Wert pro Domäne mit dem Parameter -TTL am GSLB-vServer.

Was die GSLB-Instanz antwortet, wenn kein Standort mehr verfügbar ist

Auf meiner Testinstanz habe ich beide Dienste auf DOWN gesetzt. Die GSLB-Instanz antwortete daraufhin mit beiden Adressen in einer Antwort. Das ist das dokumentierte Standardverhalten: Ist der GSLB-vServer DOWN oder deaktiviert, enthält die Antwort die Adressen aller gebundenen Dienste.

Für diesen Fall gibt es zwei Einstellungen am GSLB-vServer:

• Empty Down Response (-EDR ENABLED): Die Antwort ist erfolgreich, enthält aber keine Adresse. Auf meiner Testinstanz meldete nslookup danach „Keine address (A)-Einträge“. Clients versuchen dann keine Verbindung zu einem Standort, der als DOWN gilt.
• Backup-Adresse pro Domäne (-backupIP): Sind alle Standorte DOWN, antwortet die GSLB-Instanz laut Dokumentation mit dieser Adresse, etwa einer Wartungsseite.

Wofür GSLB passt

Anwendungsfall	Warum es passt
Standortausfall überbrücken	Neue Namensauflösungen bekommen den verfügbaren Standort, ohne Handarbeit, mit der oben gemessenen Verzögerung
Zum nächstgelegenen Standort führen	Die Entscheidung wird einmal getroffen und gilt dann für eine Weile. Genau das passt zu DNS
Geplante Umzüge und Wartungen	Einen Standort deaktivieren und über Tage leerlaufen lassen. Die Trägheit der Zwischenspeicher spielt hier keine Rolle

Beim dritten Fall spielt die Verzögerung keine Rolle: Mit genug Vorlauf haben alle Zwischenspeicher die neue Antwort, bevor der alte Standort abgeschaltet wird.

Wofür GSLB nicht gebaut ist

Hochverfügbarkeit. Ein HA-Paar erklärt den Partner in der Standardeinstellung nach 3 Sekunden ohne Heartbeat für ausgefallen und übernimmt, ohne dass ein Client etwas neu auflösen muss. GSLB kann das prinzipbedingt nicht. Beides löst unterschiedliche Aufgaben und ergänzt sich.

Feinverteilung. Verteilt werden Namensauflösungen, nicht Benutzer und nicht Last. Auf meiner Testinstanz wechselte die Antwort mit jeder Anfrage. Steht vor vielen Clients ein Resolver, bekommen sie alle bis zum Ablauf der TTL dieselbe Adresse. Eine Verteilung von 50 zu 50 nach Anfragen ist deshalb keine Verteilung von 50 zu 50 nach Benutzern.

Sofortiger Failover. Siehe die Tabelle oben.

Die echte Antwort direkt abfragen

Ein Resolver liefert eine gespeicherte Antwort, die die GSLB-Instanz möglicherweise vor einiger Zeit gegeben hat. Für die Fehlersuche zählt die Antwort der GSLB-Instanz selbst, also die Abfrage direkt an ihrer ADNS-Adresse.

Die TTL verrät dabei, woher eine Antwort stammt. Die GSLB-Instanz liefert bei jeder Anfrage den vollen eingestellten Wert, auf meiner Testinstanz immer 5 beziehungsweise 30. Ein Resolver liefert die Restlaufzeit seines gespeicherten Eintrags: Bei zwei Abfragen im Abstand von vier Sekunden sank sie um vier.

# 1. Ueber den eigenen Resolver, zweimal: sinkt die TTL, kommt die Antwort aus einem Zwischenspeicher
Resolve-DnsName app.example.com -Type A -DnsOnly

# 2. Zwischenspeicher des Betriebssystems ansehen und leeren (keine Administratorrechte noetig)
Get-DnsClientCache -Entry app.example.com
Clear-DnsClientCache

# 3. Direkt an der ADNS-Adresse der GSLB-Instanz, ohne Resolver
Resolve-DnsName app.example.com -Type A -DnsOnly -Server <ADNS-Adresse>

app.example.com steht für die GSLB-Domäne, <ADNS-Adresse> für die Adresse des ADNS-Dienstes auf der NetScaler. Unterscheiden sich die Antworten aus Schritt 1 und Schritt 3, arbeitet GSLB korrekt und der Unterschied liegt in einem Zwischenspeicher.

Die direkte Abfrage zeigt die aktuelle Entscheidung der GSLB-Instanz, die Abfrage über den Resolver unter Umständen eine frühere.

Was du dir merkst

GSLB ist ein DNS-Server, der sich seine Antwort aussucht. Der Verkehr läuft danach direkt zum Standort, eine bestehende Verbindung lenkt GSLB nicht um. Die NetScaler schaltet die Antwort in Sekunden um, wie schnell die Clients folgen, bestimmen Zwischenspeicher und Verbindungen außerhalb der Appliance.

Quellen

• NetScaler: How DNS works with GSLB
• NetScaler: Protect the GSLB setup against failure
• NetScaler-Befehlsreferenz: gslb vserver
• NetScaler-Befehlsreferenz: lb monitor
• NetScaler-Befehlsreferenz: HA node

---

Eigene Messungen an einer Testinstanz mit NetScaler 14.1.