Ce module permet d'effectuer un check up dynamique des membres du groupe de répartition de charge (équipiers). Ce check up peut être activé pour un ou plusieurs équipiers et il est indépendant des requêtes de mandataire inverse proprement dites.
Pour fonctionner, ce module nécessite le chargement préalable de
Le mécanisme de check up est activé via l'utilisation de paramètres
supplémentaires de la directive
Ce module définit un nouveau drapeau d'état status pour BalancerMember :
"C
". Lorsque l'équipier est mis hors service suite à un
disfonctionnement déterminé par le module de check up, ce drapeau est activé
et peut être lu (et modifié) via le balancer-manager
.
Paramètre | Défaut | Description | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
hcmethod | None | Aucun check up dynamique n'est effectué. Les choix possibles sont :
| ||||||||||||||||||||||||
hcpasses | 1 | Nombre de check up à passer avec succès avant de remettre en service l'équipier | ||||||||||||||||||||||||
hcfails | 1 | Nombre de check up échoués avant mettre hors service l'équipier | ||||||||||||||||||||||||
hcinterval | 30 | Intervalle entre deux check up en secondes (par défaut effectué toutes les 30 secondes). Utilise la syntaxe time-interval. | ||||||||||||||||||||||||
hcuri | URI supplémentaire à ajouter à l'URL de l'équipier pour le check up. | |||||||||||||||||||||||||
hctemplate | Nom du modèle créé via | |||||||||||||||||||||||||
hcexpr | Nom de l'expression créée via Si ce paramètre est absent, un état HTTP de 2xx à 3xx est interprété comme un check up réussi. |
L'exemple suivant montre comment configurer le check up pour différents serveurs d'arrière-plan :
Dans ce scénario, on teste l'équipier http://www.example.com/
en lui
envoyant une requête GET /status.php
et en regardant si la réponse
contient la chaîne Under maintenance. Si c'est le cas, le check up est
considéré comme ayant échoué et l'équipier est mis hors service. Ce check up
dynamique est effectué toutes les 30 secondes, ce qui correspond à la valeur par
défaut.
On teste l'équipier http://www2.example.com/
en lui envoyant
simplement une requête HEAD
toutes les 10 secondes et en vérifiant
que la réponse HTTP est bien un code d'état de 2xx, 3xx ou 4xx. On teste
l'équipier http://www3.example.com/
en vérifiant simplement toutes
les 5 secondes que le socket vers ce serveur est bien opérationnel. Si ce
serveur est marqué "hors service", il lui faudra 2 check up réussis pour être
réactivé et participer à nouveau à la répartition de charge. Si à ce moment-là
il échoue à 3 check up successifs, il sera à nouveau mis hors service. Enfin,
l'équipier http://www4.example.com/
ne fait l'objet d'aucun check
up.
La directive hcexpr
.
Si l'on utilise une méthode de check up (par exemple GET
)
qui génère un corps de réponse, ce corps peut lui-même être ausculté via
ap_expr
en utilisant la fonction associée aux expressions
hc()
spécifique à ce module.
Dans l'exemple suivant, on envoie une requête GET
au serveur
d'arrière-plan, et si le corps de la réponse contient la chaîne Under
maintenance, ce serveur d'arrière-plan est mis hors service.
NOTE: Comme le corps de la réponse peut être assez grand, il est recommandé de privilégier un check up basé sur les codes d'état.
La directive hctemplate
.
Si Apache httpd et APR ont été compilés avec le support des threads, le
module de check up peut confier ce travail à un jeu de threads associé au
processus Watchdog, ce qui permet l'exécution des check up en parallèle. La
directive 0
signifie qu'aucun
jeu de threads ne sera utilisé, et le check up des différents équipiers sera
alors effectué séquentiellement.