Gestionnaire, conseillers et système Metric Server (des composants Dispatcher, CBR et Site Selector)

Le présent chapitre explique comment configurer les paramètres d'équilibrage de charge et comment installer les fonctions gestionnaire, conseiller et Metric Server de Load Balancer.

Remarque :
Lors de la lecture de ce chapitre, si vous n'utilisez pas le composant Dispatcher, remplacez "dscontrol" par l'élément suivant :
Tableau 10. Tâches de configuration avancées pour Load Balancer
Tâche Description Informations connexes
Modification des paramètres de l'équilibrage de charge

Les paramètres d'équilibrage de charge suivants peuvent être modifiés :

  • Proportion de l'importance accordée aux données d'état.

    Le rapport par défaut est 50-50-0-0. Si vous utilisez la valeur par défaut, les informations fournies par les conseillers, par le système Metric Server et par VLM ne sont pas exploitées.

  • Pondérations
  • Pondérations fixées par l'administrateur
  • Intervalles gestionnaire
  • Seuil de sensibilité
  • Indice de lissage
Optimisation de la fonction d'équilibrage de charge fournie par Load Balancer
Utilisation des scripts pour la génération d'une alerte ou d'une erreur du serveur d'enregistrement lorsque le gestionnaire indique si le serveur est actif ou non Load Balancer fournit des exits utilisateur qui déclenchent des scripts que vous pouvez personnaliser lorsque le gestionnaire indique si le serveur est actif ou non Utilisation de scripts pour la génération d'une alerte ou d'une erreur du serveur d'enregistrement
Utilisation des conseillers Décrit et répertorie les conseillers, qui signalent les états spécifiques des serveurs Conseillers
Utilisation de l'option de demande ou réponse (URL) de conseiller HTTP ou HTTPS Définit une chaîne HTTP URL client unique propre à un service que vous voulez demander sur la machine Configuration du conseiller HTTP ou HTTPS à l'aide de l'option de demande ou de réponse (URL)
Utilisation d'un auto conseiller Fournit au serveur principal l'état de chargement d'une configuration WAN Load Balancer à deux niveaux Utilisation d'un conseiller Self dans une configuration WAN à deux niveaux
Création de conseillers personnalisés Explique comment écrire vos propres conseillers Création de conseillers personnalisés
Utilisation de l'agent Metric Server Le système Metric Server fournit des informations de chargement à Load Balancer Metric Server
Utilisation du conseiller WLM (Workload Manager) Le conseiller WLM fournit des informations de chargement à Load Balancer Conseiller Workload Manager

Optimisation de la fonction d'équilibrage de charge fournie par Load Balancer

La fonction gestionnaire de Load Balancer effectue l'équilibrage de charge en fonction des paramètres suivants :

Tous ces paramètres peuvent être modifiés en vue d'optimiser l'équilibrage de la charge du réseau.

Proportion de l'importance accordée aux données d'état

Le gestionnaire peut utiliser certains ou l'ensembles de facteurs externes suivants pour les décisions de pondération :

Outre la charge courante de chaque serveur et d'autres données nécessaires à ses calculs, le gestionnaire obtient les deux premières valeurs (nouvelles connexions et connexions actives) de la part de l'exécuteur. Ces valeurs dépendent de données générées et stockées en interne par l'exécuteur.

Remarque :
Pour Site Selector, le gestionnaire extrait les deux premières valeurs (unité centrale et mémoire) de Metric Server.

Vous pouvez modifier la proportion d'importance relative des quatre valeurs sur la base d'un cluster (ou nom de site). Les proportions sont des pourcentages ; la somme des proportions est égale à 100%. Le ratio par défaut est 50/50/0/0, ce qui revient à ignorer les informations système et celles transmises par les conseillers. Dans votre environnement, vous serez amené à essayer différentes combinaisons de proportions pour déterminer celle qui offre les meilleures performances.

Remarque :
Lorsque vous ajoutez un conseiller (autre que WLM), si la proportion du port est égale à zéro, le gestionnaire ajoute 1 à cette valeur. Etant donné que la somme des proportions relatives doit être égale à 1, la valeur 1 est soustraite de la valeur la plus élevée.

Lorsque vous ajoutez le conseiller WLM, si la proportion de la mesure système est égale à zéro, le gestionnaire ajoute alors 1 à cette valeur. Etant donné que la somme des proportions relatives doit être égale à 1, la valeur 1 est soustraite de la valeur la plus élevée.

Le nombre de connexions actives dépend du nombre de clients ainsi que du délai nécessaire pour accéder aux services offerts par les machines serveurs d'équilibrage de charge. Si les connexions client sont rapides (comme dans le cas de courtes pages Web obtenues par HTTP GET), le nombre de connexions actives est faible. Si les connexions client sont lentes (comme dans le cas de requêtes de base de données), le nombre de connexions actives est plus élevé.

Il est recommandé de ne pas attribuer des valeurs trop basses aux nouvelles connexions et aux connexions actives. Si la valeur 20 (au moins) n'est pas attribuée aux deux première valeurs, vous désactivez l'équilibrage de charge et le lissage.

Pour définir la proportion des valeurs d'importance, utilisez la commande dscontrol cluster set cluster proportions. Pour plus d'informations, voir dscontrol cluster — Configuration des clusters.

Pondérations

Les pondérations sont définies par le gestionnaire en fonction des décomptes internes de l'exécuteur, du retour d'informations des conseillers et du retour d'informations procuré par un programme de contrôle système, tel que Metric Server. Si vous voulez définir des pondérations manuellement lors de l'exécution du gestionnaire, indiquez l'option fixedweight lors de l'exécution de la commande dscontrol server. Pour la description de l'option fixedweight, voir Pondérations fixées par le gestionnaire.

Les pondérations définies s'appliquent à tous les serveurs connectés sur un même port. Pour chaque port, les demandes sont réparties entre les serveurs selon la pondération relative de chacun. Par exemple, si un serveur a une pondération (paramètre Weight) de 10 et un autre de 5, le premier recevra deux fois plus de demandes que le second.

Pour définir la limite de pondération maximale d'un serveur, entrez la commande dscontrol port set port weightbound weight. Cette commande intervient sur l'écart existant entre les serveurs au niveau du nombre de demandes reçues par chacun. Si la limite de pondération maximale est de 1, tous les serveurs peuvent avoir une pondération égale à 1, 0 en veille, ou -1 si désactivé. A mesure que cette valeur augmente, l'écart entre les pondérations des serveurs augmente également. Avec une limite de pondération de 2, un serveur donné pourra recevoir deux fois plus de demandes qu'un autre. Avec une limite de pondération de 10, un serveur pourra recevoir dix fois plus de demandes qu'un autre. La limite de pondération maximale par défaut est de 20.

Si un conseiller détecte la défaillance d'un serveur, il en informe le gestionnaire qui attribue au serveur une pondération de zéro. Ainsi, l'exécuteur n'enverra pas de nouvelles connexions à ce serveur tant que cette pondération restera égale à zéro. Si ce serveur disposait d'une ou plusieurs connexions avant la modification de sa pondération, les connexions pourront toutefois s'achever normalement.

Si tous les serveurs sont arrêtés, le gestionnaire définit la pondération à une valeur correspondant à la moitié de la limite de pondération maximale.

Pondérations fixées par le gestionnaire

Sans le gestionnaire, les conseillers ne peuvent pas être lancés ni détecter les pannes de serveur. Si vous choisissez de lancer les conseillers mais ne voulez pas que le gestionnaire mette à jour la pondération que vous fixée pour un serveur particulier, utilisez l'option fixedweight de la commande dscontrol server. Par exemple :

dscontrol server set cluster:port:server fixedweight yes

Une fois la valeur yes attribuée à l'option fixedweight, utilisez la commande dscontrol server set weight pour attribuer la valeur souhaitée à la pondération. La valeur de pondération du serveur ne change pas pendant que le gestionnaire est actif jusqu'à ce que vous exécutiez une autre commande dscontrol server en attribuant la valeur no à l'option fixedweight. Pour plus d'informations, voir dscontrol server — Configuration des serveurs.

Envoie d'une réinitialisation TCP à un serveur arrêté (composant Dispatcher uniquement)

Si la réinitialisation TCP est activée, Dispatcher envoie une réinitialisation TCP au client lorsque celui-ci est connecté à un serveur de pondération 0. La pondération d'un serveur est égale à zéro si elle est ainsi configurée ou si un conseiller l'a déclaré arrêté. Une réinitialisation TCP provoque la fermeture immédiate de la connexion. Cette fonction est utile pour les connexions longues durées où elle donne au client la possibilité de renégocier plus vite une connexion refusée. Activez la réinitialisation TCP à l'aide de la commande dscontrol port add|set port reset yes. La valeur par défaut est no.

Remarque :
La réinitialisation TCP s'applique à toutes les méthodes de réacheminement de Dispatcher. Toutefois, pour pouvoir utiliser la fonction de réinitialisation TCP, vous devez définir le paramètre clientgateway de la commande dscontrol executor avec une adresse de routeur.

Associée à la réinitialisation TCP, la fonction tentative du conseiller est utile à configurer. Avec cette fonctionnalité, un conseiller peut renouveler une tentative de connexion avant de déclarer un serveur arrêté. Ainsi, le conseiller ne déclare prématurément pas un serveur arrêté au risque de provoquer des incidents de réinitialisation de connexion. En clair, le fait que le conseiller échoue à la première tentative ne signifie pas nécessairement que la connexion existante est coupée. Pour plus d'informations, voir Tentative du conseiller.

Intervalles gestionnaire

Pour optimiser les performances générales du réseau, la fréquence des interactions entre le gestionnaire et l'exécuteur est limitée. Pour modifier cet intervalle d'interaction, entrez les commandes dscontrol manager interval et dscontrol manager refresh.

L'intervalle gestionnaire indique la fréquence selon laquelle le gestionnaire réactualise les pondérations des serveurs utilisés par l'exécuteur pour acheminer les connexions. Si l'intervalle gestionnaire est trop court, le gestionnaire interrompra l'exécuteur constamment et les performances déclineront. Dans le cas contraire, le routage des demandes assuré par l'exécuteur reposera sur des informations anciennes et incertaines.

Par exemple, pour définir un intervalle gestionnaire d'une seconde, entrez la commande suivante :

 dscontrol manager interval 1

Le seuil de régénération du gestionnaire détermine la fréquence selon laquelle le gestionnaire demande des données d'état à l'exécuteur. Le seuil de régénération dépend de la durée de l'intervalle.

Par exemple, pour fixer à 3 intervalles le seuil de régénération du gestionnaire, entrez la commande suivante :

  dscontrol manager refresh 3

Après cette commande, le gestionnaire devra patienter 3 intervalles avant de demander des données d'état à l'exécuteur.

Seuil de sensibilité

D'autres méthodes d'optimisation de l'équilibrage de charge des serveurs sont disponibles. Pour fonctionner en vitesse maximale, les pondérations des serveurs ne sont actualisées que si les pondérations ont évolué de manière significative. La mise à jour constante des pondérations pour un écart mineur de l'état des serveurs induirait un surcroît d'activité injustifié. Lorsque, pour tous les serveurs d'un port donné, l'écart en pourcentage de la pondération totale dépasse le seuil de sensibilité, le gestionnaire réactualise les pondérations des serveurs utilisés par l'exécuteur pour répartir les connexions. Supposons par exemple que la pondération totale passe de 100 à 105. L'écart est de 5%. Avec un seuil de sensibilité par défaut de 5, le gestionnaire ne met pas à jour les pondérations utilisées par l'exécuteur, car l'écart en pourcentage n'est pas supérieur au seuil. Si, en revanche la pondération totale passe de 100 à 106, le gestionnaire met à jour les pondérations. Pour attribuer au seuil de sensibilité du gestionnaire une valeur autre que la valeur par défaut (par exemple, 6), entrez la commande suivante :

  dscontrol manager sensitivity 6 

Dans la plupart des cas, vous n'aurez pas besoin de modifier cette valeur.

Indice de lissage

Le gestionnaire calcule dynamiquement les pondérations des serveurs. Il en découle qu'une fois mise à jour, une nouvelle pondération peut être très différente de l'ancienne. Dans la plupart des cas, cela ne porte pas à conséquence. Cependant, cela peut parfois induire de fortes variations dans la manière dont l'équilibrage de charge est effectué pour les demandes. Par exemple, l'un des serveurs peut finir par réceptionner la plupart des demandes du fait d'une pondération élevée. Le gestionnaire s'apercevra alors que le serveur en question traite un nombre élevé de connexions et répond lentement. Il transposera alors la pondération sur des serveurs moins encombrés et le même phénomène se reproduira, induisant une exploitation improductive des ressources.

Pour corriger ce dysfonctionnement, le gestionnaire utilise un indice de lissage. L'indice de lissage limite l'écart de pondération d'un serveur, filtrant et uniformisant effectivement la variation dans la répartition des demandes. Plus l'indice de lissage sera élevé, moins les pondérations des serveurs varieront. Plus l'indice de lissage sera faible, plus les pondérations des serveurs changeront. La valeur par défaut de l'indice de lissage est de 1,5. Avec un index de 1,5, les pondérations des serveurs seront plutôt fluctuantes. Pour un index de 4 ou 5, ces pondérations seront plus constantes. Par exemple, pour fixer l'indice de lissage à 4, entrez la commande suivante :

  dscontrol manager smoothing 4

Dans la plupart des cas, vous n'aurez pas besoin de modifier cette valeur.

Utilisation de scripts pour la génération d'une alerte ou d'une erreur du serveur d'enregistrement

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 suivant contient des exemples de script que vous pouvez personnaliser :

Pour pouvoir exécuter les fichiers, vous devez les déplacer dans le répertoire suivant et supprimer l'extension de fichier "sample" :

Les scripts exemples suivants sont fournis :

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é.

Considérations à prendre en compte lors de l'utilisation des scripts serverUp et serverDown :

Conseillers

Les conseillers sont des agents de Load Balancer. Ils ont pour rôle d'évaluer l'état et la charge des serveurs. Ils effectuent cette tâche via un échange proactif de type client/serveur. Les conseillers peuvent être considérés comme des clients des serveurs d'application.

Le produit fournit plusieurs conseillers pour les protocoles les plus couramment utilisés. Cependant, l'utilisation de tous les conseillers fournis avec chaque composant de Load Balancer ne présente aucun intérêt. (Par exemple, n'utilisez pas le conseiller Telnet avec le composant CBR.) Load Balancer prend également en charge le concept de «conseiller personnalisé» permettant aux utilisateurs d'écrire leurs propres conseillers.

Restrictions d'utilisation des applications de serveur de liaison : Pour utiliser des conseillers sur des serveurs de liaison, démarrez deux instances du serveur : une instance pour une liaison sur cluster:port et l'autre pour une liaison sur serveur:port. Pour savoir s'il s'agit d'un serveur de liaison, lancez la commande netstat -an et recherchez serveur:port. S'il ne s'agit pas d'un serveur de liaison, le résultat de la commande est 0.0.0.0:80. S'il s'agit d'un serveur de liaison, une adresse du type 192.168.15.103:80 apparaît.

Sur les systèmes HP-UX et Solaris, restriction d'utilisation de serveurs de liaison : Si vous utilisez la commande arp publish au lieu de la commande ifconfig alias, Load Balancer accepte l'utilisation de conseillers lors de l'équilibrage de la charge des serveurs de liaison (autres composants Load Balancer tels que CBR Locator ou Site Selector compris) lorsqu'ils sont reliés à l'adresse IP du cluster. Toutefois, si vous utilisez des conseillers sur des serveurs de liaison, ne co-implantez pas Load Balancer sur la même machine qu'un serveur de liaison.

Remarque :
Si Load Balancer s'exécute sur un ordinateur doté de plusieurs cartes réseau et que vous voulez que le trafic du conseiller passe par une carte particulière, vous pouvez imposer une adresse spécifique comme adresse IP source des paquets. Pour ce faire, ajoutez à la ligne java...SRV_XXXConfigServer... du fichier script de démarrage approprié de Load Balancer (dsserver, cbrserver ou ssserver) les éléments suivants :
-DLB_ADV_SRC_ADDR=adresse_IP

Fonctionnement des conseillers

Les conseillers ouvrent régulièrement une connexion TCP avec chaque serveur et envoient un message de demande au serveur. Le contenu du message dépend du protocole exécuté sur le serveur. Par exemple, le conseiller HTTP envoie une demande HTTP «HEAD» au serveur.

Les conseillers attendent ensuite une réponse du serveur. Une fois la réponse obtenue, le conseiller évalue l'état du serveur. Pour calculer la valeur de la «charge», la plupart des conseillers mesurent le délai de réponse du serveur, puis ils utilisent cette valeur (en millisecondes) comme valeur de charge.

Le conseiller reporte cette valeur au gestionnaire. Elle apparaît dans le rapport du gestionnaire, dans la colonne «Port». Le gestionnaire calcule ensuite un ensemble de valeurs de pondération à partir de toutes ses sources, selon les proportions, et définit ces valeurs de pondération dans la fonction exécuteur. L'exécuteur utilise ces pondérations pour équilibrer la charge des nouvelles connexions client entrantes.

Si le conseiller détermine que le serveur est actif et que son état est correct, il renvoie au gestionnaire une valeur de charge positive non nulle. Si le conseiller détermine que le serveur n'est pas actif, il renvoie une valeur de charge spéciale négative (-1). Le gestionnaire et l'exécuteur n'enverront plus aucune connexion en direction de ce serveur tant qu'il ne sera pas de nouveau actif.

Remarque :
Avant d'envoyer le message de demande initial, le conseiller envoie une demande Ping au serveur. Cela a pour but d'obtenir rapidement l'état de la machine pour déterminer si elle est en ligne. Une fois que le serveur a répondu au ping, aucun autre ping n'est envoyé. Pour désactiver les pings, ajoutez -DLB_ADV_NO_PING dans le fichier script de lancement de Load Balancer.

Démarrage et arrêt d'un conseiller

Vous pouvez lancer un conseiller pour un port particulier de tous les clusters (conseiller de groupe). Vous pouvez également choisir d'exécuter différents conseillers sur le même port mais sur des clusters différents (conseiller spécifique cluster/site). Par exemple, si Load Balancer est défini avec trois clusters (cluster A, cluster B, cluster C), pour chaque cluster le port 80 a une fonction différente.

Lorsque vous utilisez la configuration exemple précédente, vous pouvez choisir d'arrêter le conseiller personnalisé ADV_custom pour le port 80 sur un cluster uniquement ou pour les deux clusters (cluster B et cluster C).

Intervalles conseiller

Remarque :
Les valeurs par défaut du conseiller doivent fonctionner pour la plupart des scénarios possibles. Soyez prudent lorsque vous entrez des valeurs autres que celles fournies par défaut.

L'intervalle conseiller détermine la fréquence selon laquelle un conseiller demande des données d'état aux serveurs associés au port dont il a la charge, puis transmet ces données au gestionnaire. Si l'intervalle conseiller est trop court, le conseiller interrompra les serveurs constamment et les performances déclineront. Dans le cas contraire, les décisions d'allocation de pondérations prises par le gestionnaire reposeront sur des informations anciennes et incertaines.

Par exemple, pour fixer à 3 secondes l'intervalle du conseiller HTTP sur le port 80, entrez la commande suivante :

  dscontrol advisor interval http 80 3

Notez qu'il n'est pas logique de spécifier un intervalle conseiller inférieur à l'intervalle gestionnaire. L'intervalle conseiller par défaut est sept secondes.

Délai de rapport du conseiller

Pour s'assurer que le gestionnaire n'utilise pas d'informations périmées pour ses décisions d'équilibrage de charge, le gestionnaire n'utilisera pas les informations d'un conseiller dont l'horodatage sera antérieur à celui défini dans le délai de rapport du conseiller. Le délai de rapport du conseiller doit être supérieur à l'intervalle de sondage du conseiller. Si le délai est inférieur, le gestionnaire ignore les états qu'il est censé exploiter. Par défaut, les rapports des conseillers n'ont pas de délai d'expiration — la valeur par défaut est Unlimited (illimité).

Par exemple, pour fixer à 30 secondes l'intervalle du conseiller HTTP sur le port 80, entrez la commande suivante :

dscontrol advisor timeout http 80 30 

Pour obtenir plus d'informations sur la définition du délai de rapport du conseiller, voir dscontrol advisor — Contrôle du conseiller.

Délai de connexion du conseiller et délai de réception pour les serveurs

Pour Load Balancer, vous pouvez définir les valeurs de délai du conseiller lorsqu'une erreur au niveau d'un port particulier du serveur (service) est détectée. Les valeurs de délai d'erreur serveur (connecttimeout et receivetimeout) déterminent la durée attendue par un conseiller avant de signaler qu'une connexion ou une réception n'a pas abouti.

Pour obtenir une détection d'erreur serveur très rapide, attribuez la valeur la plus basse (une seconde) aux délais de connexion et de réception du conseiller et attribuez la valeur la plus basse (une seconde) à l'intervalle du gestionnaire et du conseiller.

Remarque :
Si le trafic de votre environnement atteint un volume modéré voire élevé et que le temps de réponse du serveur augmente, vérifiez que vous n'avez pas attribué des valeurs trop faibles à connecttimeout et à receivetimeout. Sinon, le conseiller peut indiquer de manière prématuré une erreur réseau lorsqu'un serveur est occupé.

Par exemple, pour attribuer la valeur 9 secondes à connecttimeout et à receivetimeout pour le conseiller HTTP sur le port 80, entrez la commande suivante :

dscontrol advisor connecttimeout http 80 9
dscontrol advisor receivetimeout http 80 9  

La valeur par défaut de connexion et de réception est trois fois supérieure à la valeur indiquée pour l'intervalle du conseiller.

Tentative du conseiller

Les conseillers peuvent essayer de nouveau d'établir une connexion avant de marquer un serveur comme arrêté. Le conseiller ne déclare un serveur comme étant arrêté qu'après avoir effectué le nombre de tentatives de connexion fixé plus une. Il est préférable que le nombre de tentatives ne dépasse pas 3. La commande ci-après fixe 2 tentatives pour le conseiller LDAP du port 389 :

dscontrol advisor retry ldap 389 2

Liste des conseillers

Configuration du conseiller HTTP ou HTTPS à l'aide de l'option de demande ou de réponse (URL)

L'option d'URL du conseiller HTTP ou HTTPS est disponible pour les composants Dispatcher et CBR.

Après avoir lancé un conseiller HTTP ou HTTPS, vous pouvez définir une chaîne d'URL HTTP client unique, propre au service auquel vous souhaitez accéder sur le serveur. Le conseiller peut ainsi contrôler l'état des services d'un serveur. Vous pouvez effectuer cette opération en définissant des serveurs logiques avec des noms de serveurs uniques ayant la même adresse IP physique. Pour plus d'informations, voir Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).

Pour chaque serveur logique défini sous le port HTTP, vous pouvez indiquer une chaîne HTTP URL client unique, spécifique du service pour lequel vous voulez interroger le serveur. Le conseiller HTTP ou HTTPS utilise la chaîne advisorrequest pour vérifier l'état des serveurs. La valeur par défaut est HEAD / HTTP/1.0. La chaîne advisorresponse est la réponse que le conseiller recherche dans la réponse HTTP. Le conseiller utilise la chaîne advisorresponse pour effectuer une comparaison par rapport à la réponse réelle reçue du serveur. La valeur par défaut est null.

Important : Si l'URL HTTP contient un espace :

Lorsque vous créez la demande que le conseiller HTTP ou HTTPS envoie aux serveurs dorsaux pour vérifier s'ils fonctionnent, vous tapez le début de la demande HTTP et Load Balancer la complète en spécifiant les éléments suivants :

\r\nAccept:
*/*\r\nUser-Agent:IBM_Load_Balanacer_HTTP_Advisor\r\n\r\n 

Si vous souhaitez ajouter d'autres zones d'en-tête HTTP avant que Load Balancer ajoute cette chaîne en fin de la demande, insérez votre propre chaîne \r\n dans la demande. Voici un exemple de ce que vous devez taper pour ajouter la zone d'en-tête d'hôte HTTP à votre demande :

GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHôte: www.w3.org
Remarque :
Après le démarrage d'un conseiller HTTP ou HTTPS pour un numéro de port HTTP spécifié, la valeur de demande et réponse du conseiller est activée pour les serveurs sous ce port HTTP.

Pour plus d'informations, voir dscontrol server — Configuration des serveurs.

Utilisation d'un conseiller Self dans une configuration WAN à deux niveaux

Le conseiller self est disponible dans le composant Dispatcher.

Lorsque Load Balancer se trouve dans une configuration WAN (wide area network) à deux niveaux, un conseiller self est fourni qui rassemble des informations de statut de chargement sur les serveurs dorsaux.

Figure 31. Exemple de configuration WAN à deux niveaux utilisant le conseiller self
Configuration WAN à deux niveaux utilisant le conseiller self

Dans cet exemple, le conseiller self ainsi que le système Metric Server se trouvent sur deux machines Dispatcher dont l'équilibrage de charge est assuré par le système Load Balancer de niveau supérieur. Le conseiller self mesure de manière spécifique les connexions par seconde sur les serveurs dorsaux du système Dispatcher se trouvant au niveau de l'exécutant.

Le conseiller self inscrit les résultats dans le fichier dsloadstat. Load Balancer fournit également une mesure externe appelée dsload. L'agent du système Metric Server de chaque machine Dispatcher exécute son fichier de configuration qui appelle le script dsload de mesure externe. Le script dsload extrait une chaîne du fichier dsloadstat et le renvoie à l'agent du système Metric Server. Ensuite, chaque agent du système Metric Server (de chaque élément Dispatcher) renvoie la valeur de statut de chargement à l'élément Load Balancer se trouvant au niveau supérieur. Cette valeur sera utilisée pour déterminer le système Dispatcher qui transmettra les demandes client.

L'exécutable dsload se trouve dans le répertoire suivant :

Pour plus d'informations sur l'utilisation de Dispatcher dans des configurations WAN, voir Configuration du support de réseau étendu pour Dispatcher. Pour plus d'informations sur le système Metric Server, voir Metric Server.

Création de conseillers personnalisés

Le conseiller personnalisé est un petit programme Java, que vous fournissez sous forme de fichier classe, appelé par le code de base. Le code de base fournit tous les services administratifs, tels que le démarrage et l'arrêt d'une instance du conseiller personnalisé, la génération d'états et de rapports et l'enregistrement des informations de l'historique dans un fichier journal. Il renvoie également les résultats au composant gestionnaire. Régulièrement, le code de base lance un cycle de conseiller au cours duquel il évalue individuellement tous les serveurs de sa configuration. Il commence par ouvrir une connexion avec la machine serveur. Si la connexion s'ouvre, le code de base appelle la méthode « getLoad» (fonction) dans le conseiller personnalisé. Ce dernier effectue la procédure nécessaire à l'évaluation du serveur. Généralement, il envoie au serveur un message défini par l'utilisateur et attend la réponse. L'accès à la connexion ouverte est fourni au conseiller personnalisé. Le code de base ferme ensuite la connexion au serveur et envoie au gestionnaire les informations relatives à la charge.

Le code de base et le conseiller personnalisé peuvent opérer en mode normal ou en mode replace. Le choix du mode de fonctionnement est indiqué dans le fichier du conseiller personnalisé en tant que paramètre dans la méthode du constructeur.

En mode normal, le conseiller personnalisé échange des données avec le serveur et le code du conseiller de base évalue la durée de l'échange et calcule la valeur de la charge. Le code de base renvoie cette valeur au gestionnaire. Le conseiller personnalisé doit simplement retourner un zéro (succès) ou une valeur négative (échec). Lorsque dans le ficher du constructeur, la valeur false est attribuée à l'indicateur replace, le mode normal est défini.

En mode replace, le code de base n'effectue aucune mesure de temps. Le code du conseiller personnalisé effectue toutes les opérations nécessaires, puis renvoie une valeur de charge. Le code de base accepte la valeur et la retourne au gestionnaire. Pour obtenir de meilleurs résultats, situez votre valeur de charge entre 10 et 1000, 10 représentant un serveur rapide et 1000 un serveur plus lent. Lorsque dans le fichier du constructeur, la valeur true est attribuée à l'indicateur replace, le mode replace est défini.

Avec cette fonctionnalité, vous pouvez développer vos propres conseillers qui fourniront les informations sur les serveurs dont vous avez besoin. Un exemple de conseiller personnalisé, ADV_exemple.java, est fourni avec le produit Load Balancer.

Une fois Load Balancer installé, vous pouvez trouver le code exemple dans :

Remarque :
Si vous ajoutez un conseiller personnalisé à Dispatcher, ou tout autre composant compatible avec Load Balancer, vous devez arrêter, puis redémarrer dsserver (ou le service pour les systèmes Windows) pour que le processus Java puisse lire les nouveaux fichiers de classes du conseiller personnalisé. Les fichiers de classes du conseiller personnalisé ne sont chargés qu'au démarrage. Il n'est pas nécessaire d'arrêter l'exécuteur. Ce dernier continue à s'exécuter après arrêt de dsserver, ou du service.

Si le conseiller personnalisé fait référence à d'autres classes Java, le chemin d'accès aux classes du fichier script de lancement de Load Balancer (dsserver, cbrserver, ssserver) doit être mis à jour pour inclure l'emplacement.

Conseiller WAS

Le répertoire d'installation de Load Balancer contient des fichiers exemple de conseiller personnalisé spécifiques au conseiller WebSphere Application Server (WAS).

Les fichiers exemple de conseiller WebSphere Application Server se trouvent dans le même répertoire que le fichier ADV_exemple.java.

Convention d'attribution de nom

Le nom de fichier de votre conseiller personnalisé doit avoir le format «ADV_monconseiller.java.» Il doit être précédé du préfixe «ADV_» en majuscules. Tous les caractères suivants doivent être en minuscules.

Conformément aux conventions Java, le nom de la classe définie dans le fichier doit correspondre au nom du fichier. Si vous copiez le code exemple, veillez à remplacer toutes les occurrences de «ADV_exemple» dans le fichier par le nom de votre nouvelle classe.

Compilation

Les conseillers personnalisés sont écrits en langage Java. Utilisez le compilateur Java qui est installé avec Load Balancer. Les fichiers suivants sont référencés pendant la compilation :

Le chemin d'accès aux classes doit désigner à la fois le fichier du conseiller personnalisé et le fichier de classes de base lors de la compilation.

Pour les systèmes Windows, exemple de commande de compilation :

rép_install/java/bin/javac -classpath 
    rép_install\lb\servers\lib\ibmlb.jar ADV_fred.java

où :

Le résultat de la compilation est un fichier .class, par exemple :

ADV_fred.class

Avant de lancer le conseiller, copiez le fichier de classe dans le répertoire suivant :

Remarque :
Si vous le souhaitez, vous pouvez compiler les conseillers personnalisés sur un système d'exploitation et l'exécuter sur un autre. Par exemple, vous pouvez compiler le conseiller sur des systèmes Windows, copier le fichier .class (en binaire) sur une machine AIX à partir de laquelle vous exécutez le conseiller personnalisé.

Pour les systèmes AIX, HP-UX, Linux et Solaris, la syntaxe est similaire.

Exécution

Pour exécuter le conseiller personnalisé, vous devez tout d'abord copier le fichier .class dans le répertoire d'installation approprié :

Configurez le composant, démarrez la fonction gestionnaire, puis exécutez la commande permettant de lancer le conseiller personnalisé.

dscontrol advisor start fred 123

où :

Si le conseiller personnalisé fait référence à d'autres classes Java, le chemin d'accès aux classes du fichier script de lancement de Load Balancer (dsserver, cbrserver, ssserver) doit être mis à jour pour inclure l'emplacement.

Sous-programmes requis

Comme tous les conseillers, un conseiller personnalisé étend la fonction de la base du conseiller, intitulée ADV_Base. En fait, c'est la base du conseiller qui effectue la plupart des fonctions du conseiller, telles que la communication des charges au gestionnaire afin que ces dernières soient utilisées dans l'algorithme de pondération du gestionnaire. La base du conseiller effectue également les opérations de connexion et de fermeture de la connexion et fournit des méthodes d'envoi et de réception qui seront utilisées par le conseiller. Le conseiller n'est lui-même utilisé que pour l'envoi de données vers le port du serveur conseillé et pour la réception de données sur ce dernier. Les méthodes TCP de la base du conseiller sont programmées pour calculer la charge. Un indicateur du constructeur de ADV_base remplace, si vous le souhaitez, la charge existante par la nouvelle charge renvoyée par le conseiller.

Remarque :
Selon la valeur définie dans le constructeur, la base du conseiller fournit la charge à l'algorithme de pondération à une certaine fréquence. Si le véritable conseiller n'a pas terminé ses opérations afin de renvoyer une charge valide, la base du conseiller utilise la charge précédente.

Ci-dessous, sont énumérées les méthodes de classe de base.

Ordre de recherche

Load Balancer consulte tout d'abord la liste des conseillers en langage naturel. S'il ne trouve pas un conseiller donné, Load Balancer consulte la liste des conseillers personnalisés du clients.

Affectation du nom et du chemin

Conseiller type

Un programme permettant de créer un conseiller type est présenté à la section Conseiller type. Après installation, ce conseiller exemple se trouve dans le répertoire suivant :

Metric Server

Cette fonction est disponible pour tous les composants Load Balancer.

Metric Server fournit des informations de charge à Load Balancer sous forme de mesures système en indiquant l'état d'intégrité des serveurs. Le gestionnaire Load Balancer adresse des demandes aux agents du système Metric Server situés sur chacun des serveurs, leur attribuant des pondérations destinées au processus d'équilibrage de charge à l'aide des données rassemblées par les agents. Les résultats sont regroupés dans le rapport du gestionnaire.

Remarque :
Lorsque deux mesures sont collectées et normalisées pour chaque serveur sous la forme d'une seule valeur de charge système, des erreurs d'arrondi peuvent se produire.

Pour plus d'informations sur le fonctionnement de Metric Server (démarrage et arrêt) et sur l'utilisation des journaux Metric Server, voir Utilisation du composant Metric Server.

Pour obtenir un exemple de configuration, voir la figure 5.

Restrictions relatives à WLM

Comme le conseiller WLM, le rapport du Metric Server concerne l'ensemble des systèmes de serveurs et non chaque démon de serveur associé à un protocole. WLM et Metric Server placent leurs résultats dans la colonne relative au système du rapport du gestionnaire. Par conséquent, il n'est pas possible d'exécuter simultanément le conseiller WLM et Metric Server.

Conditions préalables

L'agent Metric Server doit être installé et en cours d'exécution sur tous les serveurs dont la charge est équilibrée.

Conditions d'utilisation de Metric Server

La procédure ci-après permet de configurer Metric Server pour Network Dispatcher. Vous pouvez configurer Metric Server pour les autres composants de Load Balancer à l'aide d'une procédure similaire.

Pour exécuter le système Metric Server ailleurs que sur l'hôte local, vous devez modifier le fichier metricserver sur le serveur ayant fait l'objet d'un équilibrage de charge. Insérez la ligne suivante après "java" dans le fichier metricserver :

-Djava.rmi.server.hostname=AUTRE_ADRESSE

Ajoutez en outre la ligne suivante avant les instructions "if" dans le fichier metricserver : hostname AUTRE_ADRESSE.

Pour la plateforme Windows : Vous devez également affecter un alias à AUTRE_ADRESSE dans la pile Microsoft de la machine Metric Server. par exemple :

call netsh interface ip add
address "Local Area Connection" 
   addr=9.37.51.28 mask=255.255.240.0

Lorsque vous collectez des mesures de domaines différents, vous devez affecter de manière explicite au paramètre java.rmi.server.hostname du script serveur (dsserver, cbrserver, etc.) le nom de domaine complet (FQDN) de la machine qui demande les mesures. Cela est nécessaire car, suivant votre configuration et votre système d'exploitation, InetAddress.getLocalHost.getHostName() risque de ne pas renvoyer la valeur FQDN.

Conseiller Workload Manager

Le code de WLM ne s'exécute que sur des grands systèmes MVS. Il peut être utilisé pour demander la charge sur la machine MVS.

Si MVS Workload Management a été configuré sur votre système OS/390, Dispatcher peut accepter de WLM des informations relatives à la charge et les utiliser dans le processus d'équilibrage de charge. Grâce au conseiller WLM, Dispatcher ouvre régulièrement des connexions via le port WLM sur chaque serveur de la table d'hôte Dispatcher et accepte les chiffres relatifs à la capacité renvoyés. Comme ces chiffres représentent la capacité encore disponible et que Dispatcher attend des valeurs représentant la charge sur chaque machine, le conseiller inverse et normalise les chiffres relatifs à la capacité pour obtenir des valeurs de charge (ainsi, des chiffres de capacité élevés correspondent à des valeurs de charge faibles et représentent un serveur en bon état). Les valeurs de charge obtenues sont placées dans la colonne relative au système du rapport du gestionnaire.

Il existe plusieurs différences importantes entre le conseiller WLM et les autres conseillers Dispatcher :

  1. Les autres conseillers ouvrent des connexions aux serveurs en utilisant le même port que pour le trafic client normal. Le conseiller WLM ouvre des connexions aux serveurs en utilisant un port différent de celui utilisé pour le trafic normal. Sur chaque machine serveur, l'agent WLM doit être configuré pour effectuer l'écoute sur le port sur lequel le conseiller Dispatcher WLM a été lancé. Le port WLM par défaut est 10007.
  2. Les autres conseillers évaluent uniquement les serveurs définis dans la configuration cluster:port:serveur de Dispatcher pour laquelle le port serveur correspond au port conseiller. Le conseiller WLM fournit des conseils sur chaque serveur de la configuration de Dispatcher (quel que soit l'élément cluster:port). Vous ne devez donc pas définir de serveurs non WLM lorsque vous utilisez le conseiller WLM.
  3. Les autres conseillers placent les informations relatives à la charge dans la colonne «Port» du rapport du gestionnaire. Le conseiller WLM place les informations sur la charge dans la colonne System du rapport du gestionnaire.
  4. Il est possible d'utiliser les conseillers de protocole avec le conseiller WLM. Les conseillers de protocole évaluent la charge des serveurs sur le port utilisé pour le trafic normal et le conseiller WLM évalue la charge du système sur le port WLM.

Restrictions relatives à Metric Server

Comme l'agent Metric Server, le rapport de l'agent WLM concerne les systèmes de serveur dans leur ensemble et non chacun des démons de serveur associés à un protocole. Metric Server et WLM placent leurs résultats dans la colonne relative au système du rapport du gestionnaire. Par conséquent, il n'est pas possible d'exécuter simultanément le conseiller WLM et Metric Server.