Load Balancer fournit des exits utilisateur qui déclenchent des scripts que vous pouvez personnaliser. Vous pouvez
créer des scripts afin d'effectuer des actions automatisées. Il est,
par exemple, possible de prévenir un administrateur lorsque le
gestionnaire indique qu'un serveur est inactif ou simplement
d'enregistrer l'erreur.
Le répertoire
racine_install/servers/samples
contient des exemples de script que vous pouvez personnaliser. Pour pouvoir exécuter les
fichiers, vous devez les déplacer dans le répertoire
racine_install/servers/bin
et supprimer l'extension de fichier ″sample″. Les scripts
exemples suivants sont fournis :
- serverDown — le gestionnaire indique qu'un serveur est inactif.
- serverUp — le gestionnaire indique qu'un serveur est à nouveau actif.
- managerAlert — il est indiqué que
tous les serveurs d'un port particulier sont inactifs.
- managerClear — au moins un serveur
est à nouveau disponible actif après qu'il a été indiqué que tous les
serveurs étaient inactifs pour un port particulier.
Si tous les serveurs d'un cluster sont marqués comme étant arrêtés (par l'utilisateur
ou par les conseillers), la fonction managerAlert (si elle est configurée) démarre et le composant Load
Balancer tente de router le trafic vers les serveurs en utilisant une technique de permutation circulaire. Le script serverDown ne démarre pas lorsque le dernier serveur du cluster est détecté comme étant hors ligne.
De par sa conception, Load Balancer continue à router le trafic au cas où un serveur redeviendrait actif et répondrait à la demande. Si ce composant interrompait le trafic, le client ne recevrait pas de
réponse. Lorsque Load Balancer détecte que le premier serveur d'un cluster est redevenu actif, le script managerClear (s'il est configuré) démarre mais le script serverUp (s'il est configuré) ne s'exécute pas tant qu'un autre serveur n'est pas réactivé.
Voici quelques considérations à prendre en compte lors de l'utilisation des scripts serverUp et serverDown :
- Si vous définissez un cycle de gestionnaire inférieur à 25 % de la durée du
conseiller, les états des serveurs démarrés ou arrêtés générés peuvent être erronés. Par
défaut, le gestionnaire est exécuté toutes les 2 secondes, mais le conseiller l'est toutes
les 7 secondes. Par conséquent, le gestionnaire attend de nouvelles informations du
conseiller tous les 4 cycles. Toutefois, si vous supprimez cette restriction
(en définissant un cycle de gestionnaire supérieur à 25 % de la durée du
conseiller), les performances seront considérablement réduites car un même serveur
pourra alors être conseillé par plusieurs conseillers.
- Lorsqu'un serveur est arrêté, le script serverDown démarre. Toutefois, si vous
exécutez une commande serverUp, le serveur est considéré comme actif jusqu'à ce que le
gestionnaire obtienne de nouvelles informations du cycle du conseiller. Si le serveur
est toujours arrêté, le script serverDown est à nouveau exécuté.