Overzicht #

Deze handleiding biedt een gestructureerde aanpak voor het valideren en oplossen van problemen met GSLB-configuraties (Global Server Load Balancing / GTM). RELIANOID omgevingen, met name wanneer van services wordt verwacht dat ze automatisch overschakelen van on-premises naar Disaster Recovery (DR)-locaties.

Het omvat tevens best practices voor applicatiegebaseerde openbare IP-adressen en interne GSLB-services.

Validatiebereik #

Deze handleiding is van toepassing op:

• GSLB-implementaties met meerdere locaties (on-premises + DR)
• Diensten die via openbare IP-adressen worden aangeboden
• DNS-gebaseerde failover met behulp van RELIANOID GSLB
• Automatische failover-scenario's op basis van statuscontroles

Belangrijke componenten om te valideren #

Voordat u problemen met failover-gedrag oplost, controleert u het volgende:

GSLB-configuratie #

• De GSLB-service is correct geconfigureerd met:
  • Meerdere backend-sites (on-premise + disaster recovery)
  • Correcte resolutiebeleidsregels (prioriteit, latentie, enz.)
• De DNS-zone en -records zijn correct gedefinieerd.

Gezondheidchecks #

• Gezondheidscontroles omvatten:
  • Ingeschakeld voor alle backendservices
  • Het correct targeten van applicatie-eindpunten (niet alleen IP/poort)
• Verwachte responscodes of inhoudsvalidatie is geconfigureerd.

DNS-configuratie #

• De TTL-waarden zijn correct geconfigureerd (een lage TTL wordt aanbevolen voor failover).
• De gezaghebbende DNS-server verwijst naar RELIANOID GSLB

Failover van on-premise naar noodherstelomgeving valideren #

Stap 1: Controleer of de normale werking (primair actief) is. #

• DNS-resolutie opvragen:

  graven

• Verifieer dat:
  • Het gevonden IP-adres komt overeen met de on-premises locatie.
  • De applicatie is toegankelijk en gezond.

Stap 2: Simuleer een storing #

Activeer een foutconditie op de primaire site:

• Stop backend-services
• Blokkeer het eindpunt voor gezondheidscontroles
• Schakel de farm of backend uit.

Stap 3: Valideer de detectie van de gezondheidscontrole #

• Bevestigen RELIANOID markeert de primaire locatie als OMLAAG
• Controleer de logboeken en de monitoring om er zeker van te zijn dat:
  • De gezondheidschecks voldoen niet aan de verwachtingen.
  • Geen vals-positieve/vals-negatieve resultaten.

Stap 4: Valideer DNS-failover #

• Voer de DNS-query opnieuw uit:

  graven

• Verwacht resultaat:
  • Het IP-adres zou nu moeten verwijzen naar de DR-site.

Let op: DNS-caching kan de propagatie vertragen, afhankelijk van de TTL.

Stap 5: Controleer de beschikbaarheid van de applicatie #

• Open de applicatie via het opgeloste DR IP-adres.
• Bevestigen:
  • De applicatie is volledig functioneel.
  • Geen afhankelijkheidsproblemen (database, API's, enz.)

Veelvoorkomende problemen en probleemoplossing #

Failover niet geactiveerd #

• Gezondheidscontroles te tolerant (bijv. TCP-validatie in plaats van HTTP-validatie)
• Onjuist eindpunt voor gezondheidscontrole
• De backend reageert nog steeds gedeeltelijk.

BepalenGebruik controles op applicatieniveau (HTTP-status, antwoordbody)

DNS verwijst nog steeds naar de primaire server. #

• TTL te hoog
• DNS-caching aan de clientzijde
• Recursieve DNS-servers niet vernieuwd

Bepalen:

• Lagere TTL (bijv. 30-60 seconden)
• Leeg de lokale DNS-cache.
• Test met externe resolvers (dig @8.8.8.8)

DR-site verwerkt geen verkeer. #

• DR-backend niet correct geconfigureerd
• Ontbrekende afhankelijkheden (database, opslag, authenticatie)
• Firewall- of routeringsproblemen

Bepalen: Valideer de gereedheid van de volledige DR-stack, niet alleen de load balancer.

Intermitterende failover (flapping) #

• Onstabiele gezondheidscontroles
• Netwerklatentie of pakketverlies
• Inconsistente reacties van de backend

Bepalen:

• Stel de intervallen en drempelwaarden voor gezondheidscontroles in.
• Verhoog de fouttolerantie

Overwegingen met betrekking tot op aanvragen gebaseerd openbaar intellectueel eigendom #

Bij gebruik van openbare IP-adressen per site:

• Zorg ervoor dat elke site zijn eigen openbare IP-adres adverteert.
• GSLB zou per site het juiste IP-adres moeten retourneren.
• Valideren:
  • NAT- en firewallregels
  • SSL-certificaten per eindpunt
  • Consistent applicatiegedrag op alle locaties.

Richtlijnen voor interne GSLB-diensten #

Voor diensten die uitsluitend intern worden gebruikt (privé-DNS / interne applicaties):

DNS-configuratie #

• Gebruik interne DNS-servers die geïntegreerd zijn met RELIANOID GSLB
• Zorg ervoor dat klanten hun problemen via de juiste interne oplossers oplossen.

Netwerk overwegingen #

• Controleer de routering tussen locaties (VPN/MPLS).
• Zorg ervoor dat de DR-site bereikbaar is vanaf alle clientnetwerken.

Gezondheidchecks #

• Gebruik interne eindpunten (privé-IP-adressen)
• Valideer reacties op de applicatielaag

Vermijden van gespleten hersenen #

• Zorg voor een goede synchronisatie tussen de GSLB-nodes.
• Vermijd situaties waarin beide sites ten onrechte als actief worden beschouwd.

Best Practices #

• Gebruik lage TTL-waarden voor een snellere failover.
• Gebruik altijd gezondheidscontroles op applicatieniveau.
• Voer regelmatig failover-oefeningen uit.
• Wereldwijde monitoring van DNS-resolutie
• Zorg voor configuratiegelijkheid tussen de primaire server en de noodremserver (DR).

Validatiechecklist #

[ ] GSLB-service geconfigureerd met alle sites
[ ] Gezondheidscontroles gevalideerd en betrouwbaar
[ ] TTL correct geconfigureerd
[ ] DR-omgeving volledig operationeel
[ ] DNS-failover getest en bevestigd
[ ] Applicatie getest na failover
[ ] Interne services gevalideerd (indien van toepassing)

Samenvatting #

Correcte validatie van RELIANOID GSLB zorgt voor een naadloze, automatische failover van on-premises naar disaster recovery-omgevingen, waardoor downtime tot een minimum wordt beperkt en de servicecontinuïteit wordt gewaarborgd.

Een succesvolle implementatie vereist coördinatie tussen:

• DNS-configuratie
• Gezondheidchecks
• gereedheid voor de applicatie
• Netwerk ontwerp