Le module additionnel Traffic Distributor (TD) sur Stack Harbor PaaS inclut un module de contrôle de santé intégré qui sonde les backends à un intervalle configurable et retire les défaillants du pool de routage. Une fois rétabli, le backend est réintégré automatiquement. Le module est activé avec des valeurs par défaut raisonnables ; le reste de cette page explique ce que signifient ces valeurs et comment les modifier.
Où se trouve la configuration
Ouvrez le panneau NGINX Config sur le nœud TD et naviguez vers /etc/nginx/nginx-jelastic.conf sous Root. Double-cliquez pour l’ouvrir dans un nouvel onglet en édition. Autour de la ligne 50, vous trouverez le bloc de configuration du module. Dans la section upstream common, cherchez la directive check — c’est le module de contrôle de santé.
La directive check
La directive accepte un ou plusieurs paramètres :
check interval={interval} fall={fail_count} rise={rise_count} [timeout={timeout}] [default_down={true/false}] [port={port}] [type={type}]
Ce que chacun fait :
interval— délai entre deux sondes consécutives, en millisecondes.fail_count— nombre de sondes consécutives en échec avant que le backend soit marqué down.rise_count— nombre de sondes consécutives réussies avant qu’un backend précédemment down soit marqué up.timeout— délai d’attente d’une réponse avant qu’une sonde soit comptée comme en échec (millisecondes). Optionnel.default_down— état initial.truesignifie que le backend démarre down jusqu’àrise_countsondes réussies ;falsequ’il démarre up. Par défauttrue.port— port à sonder.0(par défaut) utilise le port par défaut du backend pour le protocole configuré.type— protocole à utiliser pour la sonde. Optionnel. Choix :tcp— simple connexion socket TCP.ssl_hello— envoie un TLS Client Hello et attend un Server Hello en réponse.http— envoie une requête HTTP et analyse la réponse (un200est le critère de succès).mysql— se connecte au serveur MySQL et lit le message d’accueil.ajp— envoie un paquet AJPCpinget attend une réponseCpong.fastcgi— envoie une requête FastCGI et analyse la réponse.
Exemple détaillé
Prenons un TD configuré ainsi :
check interval=3000 fall=3 rise=3 type=http
Les deux backends sont sondés pour une réponse 200 toutes les 3 secondes. Si trois sondes consécutives échouent, le backend est marqué down et exclu du routage — tout le trafic part vers le backend survivant. Quand le backend défaillant se rétablit, trois sondes réussies consécutives le repassent up et il rejoint la rotation.
Si votre backend est un primaire MySQL derrière TD, vous mettriez type=mysql plutôt ; pour un service à terminaison TLS qui demande une sonde TLS, type=ssl_hello.
Appliquer le changement sans redémarrage
Après sauvegarde de nginx-jelastic.conf, vous n’avez pas à redémarrer tout le processus NGINX. Utilisez Reload configuration dans le menu du module — un rechargement gracieux qui maintient les connexions ouvertes et applique les nouveaux paramètres en quelques secondes. Confirmez dans la fenêtre.
Quand resserrer les valeurs par défaut
intervalplus court etfail_countplus bas — détection de panne plus rapide, changements de routage plus agressifs. Utile quand un backend défaillant aurait un impact utilisateur visible (services d’authentification, parcours de paiement). Attention au balancement si vos backends sont bruyants.rise_countplus élevé — attendre plus longtemps avant de renvoyer du trafic vers un backend rétabli. Utile quand le backend a besoin de chauffer après un redémarrage.timeoutplus court — éliminer plus vite les backends lents. Utile quand la latence compte plus que l’exactitude absolue.
Pages connexes
- Aperçu de Traffic Distributor — ce qu’est TD et quand l’utiliser.
- Installation de Traffic Distributor — comment attacher TD à un environnement.
- Intégration de Traffic Distributor — placer TD devant un ou plusieurs environnements.
- Déploiement Blue-Green — utiliser TD pour basculer le trafic entre deux environnements parallèles.
- Tests A/B — utiliser TD pour répartir le trafic par ratio.