Marché #

Ce guide propose une approche structurée pour valider et dépanner les configurations GSLB (Global Server Load Balancing / GTM) dans RELIANOID environnements, en particulier lorsque les services doivent basculer automatiquement des sites sur site vers des sites de reprise après sinistre (DR).

Il comprend également les meilleures pratiques pour les adresses IP publiques basées sur les applications et les services GSLB internes.

Portée de la validation #

Ce guide s'applique à :

• Déploiements GSLB avec plusieurs sites (sur site + reprise après sinistre)
• Services exposés via des adresses IP publiques
• Basculement basé sur le DNS utilisant RELIANOID GSLB
• Scénarios de basculement automatique basés sur des contrôles d'intégrité

Éléments clés à valider #

Avant de dépanner le comportement de basculement, vérifiez les points suivants :

Configuration GSLB #

• Le service GSLB est correctement configuré avec :
  • Plusieurs sites backend (sur site + reprise après sinistre)
  • Politiques de résolution correctes (priorité, latence, etc.)
• La zone DNS et les enregistrements sont correctement définis.

Bilans de santé #

• Les examens médicaux sont :
  • Activé pour tous les services backend
  • Cibler correctement les points de terminaison de l'application (et pas seulement l'adresse IP/le port)
• Les codes de réponse attendus ou la validation du contenu sont configurés.

Configuration DNS #

• Les valeurs TTL sont correctement configurées (une valeur TTL faible est recommandée pour la reprise après sinistre).
• Le DNS faisant autorité pointe vers RELIANOID GSLB

Validation du basculement de l'environnement sur site vers le système de reprise après sinistre #

Étape 1 : Confirmer le fonctionnement normal (principal actif) #

• Résolution DNS des requêtes :

  creuser

• Vérifier que:
  • L'adresse IP résolue correspond au site sur site.
  • L'application est accessible et saine

Étape 2 : Simuler la défaillance #

Déclencher une condition de défaillance sur le site principal :

• Arrêt des services backend
• Point de terminaison de vérification de l'état du bloc
• Désactiver la ferme ou le backend

Étape 3 : Valider la détection du contrôle d’intégrité #

• Confirmer RELIANOID signale le site principal comme étant en panne
• Vérifiez les journaux et la surveillance pour vous assurer que :
  • Les contrôles sanitaires échouent comme prévu.
  • Aucun faux positif/négatif

Étape 4 : Valider le basculement DNS #

• Relancer la requête DNS :

  creuser

• Résultat attendu:
  • L'adresse IP devrait maintenant pointer vers le site de reprise après sinistre.

Remarque : la mise en cache DNS peut retarder la propagation en fonction du TTL.

Étape 5 : Valider la disponibilité de l’application #

• Accédez à l'application en utilisant l'adresse IP DR résolue.
• Confirmer:
  • L'application est entièrement fonctionnelle
  • Aucun problème de dépendance (base de données, API, etc.)

Problèmes courants et dépannage #

Basculement non déclenché #

• Les contrôles d'intégrité sont trop permissifs (par exemple, validation TCP au lieu de validation HTTP).
• Point de terminaison de contrôle d'intégrité incorrect
• Le serveur répond encore partiellement.

Fixer: Utiliser des vérifications au niveau de l'application (statut HTTP, corps de la réponse)

Le DNS résout toujours le serveur principal. #

• TTL trop élevé
• Mise en cache DNS côté client
• Serveurs DNS récursifs non actualisés

Fixer:

• TTL inférieur (par exemple, 30 à 60 secondes)
• Vider le cache DNS local
• Test avec des résolveurs externes (dig @8.8.8.8)

Site DR ne génère pas de trafic #

• Le système dorsal de reprise après sinistre n'est pas correctement configuré.
• Dépendances manquantes (base de données, stockage, authentification)
• Problèmes de pare-feu ou de routage

FixerVérifiez que l'ensemble de la pile de reprise après sinistre est prêt, et pas seulement l'équilibreur de charge.

Basculement intermittent (battements) #

• Bilans de santé instables
• Latence du réseau ou perte de paquets
• Réponses du serveur incohérentes

Fixer:

• Ajuster les intervalles et les seuils des contrôles de santé
• Augmenter la tolérance aux défaillances

Considérations relatives à la propriété intellectuelle publique en fonction des applications #

Lors de l'utilisation d'adresses IP publiques par site :

• Assurez-vous que chaque site affiche sa propre adresse IP publique.
• GSLB devrait renvoyer l'adresse IP correcte par site
• Valider:
  • Règles NAT et pare-feu
  • Certificats SSL par point de terminaison
  • Comportement cohérent de l'application sur tous les sites

Lignes directrices pour les services internes GSLB #

Pour les services à usage interne uniquement (DNS privé / applications internes) :

Configuration DNS #

• Utilisez des serveurs DNS internes intégrés à RELIANOID GSLB
• S'assurer que les clients règlent leurs problèmes par l'intermédiaire des résolveurs internes appropriés.

Considérations relatives au réseau #

• Vérifier le routage entre les sites (VPN/MPLS)
• Assurez-vous que le site de reprise d'activité est accessible depuis tous les réseaux clients.

Bilans de santé #

• Utiliser des points de terminaison internes (adresses IP privées)
• Valider les réponses de la couche application

Évitement du cerveau divisé #

• Assurez une synchronisation correcte entre les nœuds GSLB
• Évitez les situations où les deux sites sont considérés comme actifs à tort.

Pratiques d'excellence #

• Utilisez des valeurs TTL faibles pour un basculement plus rapide.
• Utilisez toujours les contrôles d'intégrité au niveau de l'application.
• Effectuez régulièrement des exercices de basculement.
• Surveiller la résolution DNS à l'échelle mondiale
• Garantir la parité de configuration entre le système principal et le système de secours

Liste de contrôle de validation #

[ ] Service GSLB configuré avec tous les sites
[ ] Contrôles sanitaires validés et fiables
[ ] TTL configuré correctement
[ ] Environnement de reprise après sinistre pleinement opérationnel
[ ] Basculement DNS testé et confirmé
[ ] Application testée après basculement
[ ] Services internes validés (le cas échéant)

Résumé #

Validation appropriée de RELIANOID GSLB assure un basculement automatique et transparent entre l'environnement sur site et l'environnement de reprise après sinistre, minimisant ainsi les temps d'arrêt et maintenant la continuité du service.

Un déploiement réussi nécessite une coordination entre :

• configuration DNS
• Bilans de santé
• Préparation de l'application
• Conception de réseau