L'erreur GTM la plus courante est de gérer la santé du centre de données avec un drapeau up/down unique. En réalité, un centre de données peut être joignable alors que l'application est down ; l'application peut répondre alors que la base ne fonctionne pas ; le lien WAN peut être ouvert alors que l'accès côté LAN a échoué. Un modèle de santé à drapeau unique ne peut pas capturer ces distinctions.
Dans beaucoup d'organisations, le lien entre health-checks et réponses DNS est manuel ou fragmenté. Un système de monitoring émet une alerte, une équipe d'exploitation exécute un script, un enregistrement DNS est mis à jour à la main ou une automatisation séparée prend le relais. Cette chaîne réagit lentement et est vulnérable à l'erreur humaine aux moments critiques.
Les scénarios complexes sont encore plus difficiles. Des conditions comme « activer DC1 s'il a accès Internet et n'est pas en maintenance ; sinon renvoyer un enregistrement de secours si la santé applicative de DC2 ou l'accès de DC3 est positif » sont généralement gérées via des fichiers YAML, des scripts et des dépendances manuelles. Cela transforme une décision GTM en labyrinthe opérationnel difficile à comprendre ou à auditer.
Le flapping est un risque réel. Quand un health-check échoue momentanément et que le DNS change immédiatement, le trafic utilisateur est déplacé vers une autre région inutilement. De même, un succès bref peut ramener le trafic avant que le problème ne soit complètement résolu. Des seuils de succès et d'échecs consécutifs plus une logique de préservation d'état sont donc essentiels.
Les scénarios de health-check TR7 combinent centre de données, application, base, mode maintenance et checks personnalisés dans une seule couche de décision booléenne, liant les réponses DNS directement à la santé réelle du service.
TR7 évalue les décisions de santé GTM en combinant les checks automatiques de centre de données, les health-checks manuels et la logique de scénario dans un modèle unifié.
Les checks automatiques par centre de données, les checks HTTP/HTTPS/Oracle définis par l'utilisateur et les résultats de santé ADC peuvent tous être utilisés au sein de la même structure de décision. Cela lie la santé de l'infrastructure et de l'application en une seule décision GTM.
Les scénarios sont construits avec des groupes AND et OR. Ajouter `!` à un identifiant de health-check nie la condition, afin que des états comme le mode maintenance puissent être utilisés comme conditions négatives dans la même décision.
Les relations health-check, scénario et enregistrement DNS sont suivies via des cartes de type graphe. Quand un état de santé change, seuls les scénarios et enregistrements impactés sont réévalués.
Les health-checks HTTP et HTTPS peuvent vérifier les codes de statut et le contenu de la réponse, pas seulement l'ouverture du port. Les expressions JSONata ou les vérifications de contenu simples confirment que l'application renvoie réellement une réponse saine.
Les TR7 Health Check Scenarios couvrent un éventail de besoins GTM — des simples checks d'accès aux décisions multi-couches application et centre de données.
TR7 supporte des paramètres tels que méthode, URI, corps, en-têtes, codes de statut attendus, vérification de certificat et timeout pour les checks HTTP et HTTPS. Le check ne mesure donc pas seulement si une connexion peut être établie — il vérifie aussi que l'application renvoie la bonne réponse depuis le bon endpoint, rapprochant la décision GTM du comportement applicatif réel.
Pour les endpoints de santé qui renvoient du JSON, des champs spécifiques peuvent être évalués avec une expression JSONata. Une expression comme `status = "ok"` confirme non seulement que l'application répond mais qu'elle renvoie l'état de santé attendu. Le corps de la réponse est parsé dans la structure appropriée et l'expression y est évaluée. Cela donne une mesure de santé plus fiable pour les applications modernes basées sur des API JSON.
Pour les scénarios plus simples, le corps de la réponse peut être contrôlé pour la présence d'une chaîne spécifique. Cette approche est suffisante pour les health-checks d'application simples qui ne nécessitent pas une expression JSONata complète. Les équipes d'exploitation peuvent lier la décision DNS à la confirmation qu'un mot connu ou un état fixe apparaît dans la réponse de l'application, rendant les checks rapides et faciles à comprendre.
Les checks Oracle sont configurés via un scénario qui inclut des étapes pour établir une connexion, attendre et exécuter une commande. Les résultats sont évalués selon un nombre de lignes attendu ou un texte attendu. Cela permet aux réponses DNS d'être liées non seulement à la couche applicative mais aussi à l'accessibilité de la base, réduisant le point aveugle « l'application est up mais la base ne fonctionne pas » dans les applications métier critiques.
TR7 peut utiliser les checks `wanAccess`, `lanAccess`, `access`, `internet` et `maintenanceMode` par centre de données. Ces checks représentent indépendamment différents états d'accès et opérationnels de chaque centre de données. Des états comme le mode maintenance peuvent être traités comme conditions négatives dans un scénario plutôt que comme signaux de santé positifs, donnant aux décisions DNS une correspondance plus étroite avec la réalité opérationnelle.
Les scénarios sont construits avec des structures de groupes de conditions ; les conditions au sein d'un groupe suivent la logique AND tandis que les relations inter-groupes peuvent être OR ou AND. Ajouter `!` à un identifiant de health-check inverse la condition, permettant des constructions comme `dcAccess AND NOT maintenanceMode`. Des décisions GTM complexes peuvent être conçues sans écrire de scripts.
Les valeurs `requiredSuccess` et `requiredFailure` peuvent être configurées pour les health-checks. L'approche par défaut compte les succès ou échecs consécutifs avant qu'une transition d'état ne soit acceptée. Cela empêche les pertes de paquets momentanées, les pics de latence brefs ou les fluctuations passagères de service de changer immédiatement la réponse DNS, rendant le comportement GTM plus stable.
Les états des health-checks peuvent être persistés dans un fichier local et restaurés au redémarrage du système. Cela signifie que tous les états de santé n'ont pas besoin d'être ré-appris depuis zéro après chaque redémarrage. Cette continuité est particulièrement importante dans les environnements GTM plus grands avec de nombreux scénarios et enregistrements, donnant aux équipes d'exploitation un comportement plus prévisible après un redémarrage.
Les health-checks TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS et Oracle sont disponibles dans l'écosystème TR7. Coordonner les résultats de santé GTM et ADC permet aux décisions DNS de refléter l'état réel de la couche service. Ce large support de types rend possible la construction d'un modèle de santé non seulement pour les applications web mais pour les services d'entreprise multi-protocoles. Des scénarios de type script TCP send-receive sont aussi disponibles pour les besoins de checks personnalisés.
Pour que les scénarios de health-check fonctionnent de manière fiable, le format d'identifiant, la persistance d'état, la séquence de déclencheurs, le contrôle du nœud maître et la propagation des changements doivent tous être gérés clairement.
Le moteur de scénarios peut évaluer des types de health-check incluant static, dcCheck, http, https et oracle. Combinés à la famille élargie de health-checks GTM et ADC, des états de service multi-protocoles peuvent être amenés dans la structure de décision — important pour les architectures de service qui ne se limitent pas à un seul type de check HTTP.
Les health-checks automatiques par centre de données sont identifiés au format `auto|
Les health-checks définis par l'utilisateur sont créés avec des identifiants uniques. Ces identifiants peuvent être référencés directement dans les conditions de scénario, ce qui signifie que le même check HTTP, HTTPS ou Oracle peut être évalué à travers plusieurs scénarios GTM.
Quand un état de santé change, l'état du health-check concerné est d'abord mis à jour. Les scénarios liés sont ensuite réévalués et, si nécessaire, la configuration dynamique est régénérée. Ce flux garantit que les changements se propagent aux réponses DNS de manière contrôlée.
Des scénarios intégrés tels que `ALWAYS` et `NEVER` sont disponibles pour produire des décisions fixes. Avec `ALWAYS`, un enregistrement est toujours considéré comme éligible ; avec `NEVER`, un comportement désactivé est obtenu. C'est utile pour les tests, les retraits temporaires ou le routage inconditionnel.
Les actions de déclencheur sont exécutées uniquement sur le nœud maître GTM. Cela empêche la même action d'être exécutée à plusieurs reprises par plusieurs nœuds d'un cluster. Pour des actions telles que le déclenchement DR, les webhooks ou les notifications, ce contrôle fournit une sécurité opérationnelle.
Les organisations multi-sites peuvent ne pas vouloir qu'un centre de données soit considéré comme up sur un seul chemin d'accès. TR7 combine différentes routes d'accès dans la même décision DNS en utilisant des scénarios comme `wanAccess OR lanAccess`.
Pour les applications métier critiques, l'accessibilité du centre de données seule ne suffit pas. TR7 utilise des scénarios comme `dcAccess AND appHC AND dbHC` pour inclure l'IP pertinente dans la réponse DNS uniquement quand l'application et la base Oracle sont toutes deux saines.
Une équipe d'exploitation peut ne pas vouloir qu'un centre de données reçoive du trafic pendant la maintenance même s'il est techniquement joignable. TR7 peut retirer un site en maintenance de la réponse DNS via un scénario comme `dcAccess AND NOT maintenanceMode`.
Les applications modernes peuvent publier leur état de santé via un endpoint JSON. TR7 lie les réponses DNS à la santé applicative réelle en combinant un health-check HTTPS avec une expression JSONata comme `status = "ok"`.
Combinez les checks HTTP, HTTPS, Oracle et de centre de données dans des scénarios booléens. Laissez-nous parcourir un déploiement en direct dans votre propre environnement.