Übersicht #

Dieser Leitfaden bietet einen strukturierten Ansatz zur Validierung und Fehlerbehebung von GSLB-Konfigurationen (Global Server Load Balancing / GTM) in RELIANOID Umgebungen, insbesondere wenn von einem automatischen Failover der Dienste von lokalen Systemen auf Disaster-Recovery-Standorte (DR-Standorte) ausgegangen werden soll.

Es enthält außerdem Best Practices für anwendungsbasierte öffentliche IPs und interne GSLB-Dienste.

Validierungsumfang #

Dieser Leitfaden gilt für:

• GSLB-Implementierungen mit mehreren Standorten (lokal + DR)
• Dienste, die über öffentliche IP-Adressen zugänglich sind
• DNS-basiertes Failover mittels RELIANOID GSLB
• Automatische Failover-Szenarien basierend auf Integritätsprüfungen

Wichtige zu validierende Komponenten #

Bevor Sie die Fehlersuche beim Failover-Verhalten durchführen, überprüfen Sie Folgendes:

GSLB-Konfiguration #

• Der GSLB-Dienst ist ordnungsgemäß konfiguriert mit:
  • Mehrere Backend-Standorte (On-Premise + DR)
  • Korrekte Auflösungsrichtlinien (Priorität, Latenz usw.)
• DNS-Zone und -Einträge sind korrekt definiert

Gesundheitschecks #

• Gesundheitschecks sind:
  • Für alle Backend-Dienste aktiviert
  • Anwendungsendpunkte korrekt ansprechen (nicht nur IP/Port)
• Die erwarteten Antwortcodes oder die Inhaltsvalidierung sind konfiguriert.

DNS-Konfiguration #

• Die TTL-Werte sind entsprechend konfiguriert (niedrige TTL-Werte werden für Failover empfohlen).
• Autoritatives DNS verweist auf RELIANOID GSLB

Validierung des Failovers von On-Premise zu DR #

Schritt 1: Normalbetrieb bestätigen (Primär aktiv) #

• DNS-Auflösung abfragen:

  graben

• Überprüfe das:
  • Die aufgelöste IP-Adresse entspricht dem Standort vor Ort.
  • Die Anwendung ist zugänglich und gesund.

Schritt 2: Fehler simulieren #

Einen Fehlerzustand auf dem primären Standort auslösen:

• Backend-Dienste stoppen
• Blockieren Sie den Endpunkt für die Gesundheitsprüfung.
• Farm oder Backend deaktivieren

Schritt 3: Validierung der Integritätsprüfung #

• Schichtannahme RELIANOID markiert die primäre Website als „UNTERWÄRTS“
• Überprüfen Sie Protokolle und Überwachungsfunktionen, um Folgendes sicherzustellen:
  • Die Gesundheitschecks schlagen erwartungsgemäß fehl.
  • Keine falsch positiven/falsch negativen Werte

Schritt 4: DNS-Failover überprüfen #

• DNS-Abfrage erneut ausführen:

  graben

• Erwartetes Ergebnis:
  • Die IP-Adresse sollte nun auf die DR-Website aufgelöst werden.

Hinweis: Die DNS-Zwischenspeicherung kann die Weitergabe je nach TTL verzögern.

Schritt 5: Verfügbarkeit der Anwendung prüfen #

• Greifen Sie über die aufgelöste DR-IP-Adresse auf die Anwendung zu.
• Bestätigen:
  • Die Anwendung ist voll funktionsfähig
  • Keine Abhängigkeitsprobleme (Datenbank, APIs usw.).

Häufige Probleme und Fehlerbehebung #

Failover nicht ausgelöst #

• Zu nachlässige Gesundheitsprüfungen (z. B. TCP- statt HTTP-Validierung).
• Falscher Endpunkt für die Gesundheitsprüfung
• Backend reagiert noch teilweise

Lösung : Überprüfungen auf Anwendungsebene verwenden (HTTP-Status, Antworttext)

DNS-Auflösung erfolgt weiterhin auf primären Server #

• TTL zu hoch
• Clientseitiges DNS-Caching
• Rekursive DNS-Server werden nicht aktualisiert

Beheben :

• Niedrigere TTL (z. B. 30–60 Sekunden)
• Leeren Sie den lokalen DNS-Cache.
• Test mit externen Resolvern (dig @8.8.8.8)

DR-Website bedient derzeit keinen Datenverkehr #

• DR-Backend nicht ordnungsgemäß konfiguriert
• Fehlende Abhängigkeiten (Datenbank, Speicher, Authentifizierung)
• Firewall- oder Routing-Probleme

Behebung : Überprüfen Sie die vollständige Bereitschaft des DR-Stacks, nicht nur des Load Balancers.

Intermittierendes Failover (Flapping) #

• Instabile Gesundheitschecks
• Netzwerklatenz oder Paketverlust
• Inkonsistente Backend-Antworten

Beheben :

• Gesundheitsprüfungsintervalle und Schwellenwerte anpassen
• Erhöhung der Ausfalltoleranz

Anwendungsbezogene Überlegungen zum öffentlichen geistigen Eigentum #

Bei Verwendung öffentlicher IP-Adressen pro Standort:

• Stellen Sie sicher, dass jede Website ihre eigene öffentliche IP-Adresse angibt.
• GSLB sollte die korrekte IP-Adresse pro Standort zurückgeben.
• Bestätigen:
  • NAT- und Firewall-Regeln
  • SSL-Zertifikate pro Endpunkt
  • Einheitliches Anwendungsverhalten auf allen Websites

Richtlinien für interne GSLB-Dienste #

Für ausschließlich interne Dienste (privates DNS / interne Anwendungen):

DNS-Konfiguration #

• Verwenden Sie interne DNS-Server, die in die Datenbank integriert sind. RELIANOID GSLB
• Stellen Sie sicher, dass die Anfragen der Kunden über die richtigen internen Ansprechpartner bearbeitet werden.

Überlegungen zum Netzwerk #

• Routing zwischen Standorten prüfen (VPN/MPLS)
• Stellen Sie sicher, dass der DR-Standort von allen Client-Netzwerken aus erreichbar ist.

Gesundheitschecks #

• Interne Endpunkte (private IPs) verwenden
• Antworten der Anwendungsschicht validieren

Vermeidung von Split-Brain-Syndrom #

• Stellen Sie die ordnungsgemäße Synchronisierung zwischen den GSLB-Knoten sicher.
• Vermeiden Sie Szenarien, in denen beide Standorte fälschlicherweise als aktiv betrachtet werden.

Praxisbeispiele #

• Verwenden Sie niedrige TTL-Werte für ein schnelleres Failover.
• Verwenden Sie stets Integritätsprüfungen auf Anwendungsebene.
• Führen Sie regelmäßig Ausfallübungen durch.
• DNS-Auflösung global überwachen
• Stellen Sie sicher, dass die Konfigurationen von primärem und DR-System übereinstimmen.

Validierungs-Checkliste #

[ ] GSLB-Dienst mit allen Standorten konfiguriert
[ ] Gesundheitschecks validiert und zuverlässig
[ ] TTL entsprechend konfiguriert
[ ] DR-Umgebung voll funktionsfähig
[ ] DNS-Failover getestet und bestätigt
[ ] Anwendung nach Failover getestet
[ ] Interne Dienste validiert (falls zutreffend)

Zusammenfassung #

Ordnungsgemäße Validierung von RELIANOID GSLB gewährleistet ein nahtloses automatisches Failover von On-Premises- zu DR-Umgebungen, minimiert Ausfallzeiten und erhält die Servicekontinuität aufrecht.

Für eine erfolgreiche Implementierung ist eine Koordination zwischen folgenden Gruppen erforderlich:

• DNS-Konfiguration
• Gesundheitschecks
• Anwendungsbereitschaft
• Netzwerk-Design