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.
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 :
|
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 |
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.
Le gestionnaire peut utiliser certains ou l'ensembles de facteurs externes suivants pour les décisions de pondération :
ou —
Unité centrale : Pourcentage de l'unité centrale utilisé sur chaque serveur d'équilibrage de charge (entré à partir de l'agent Metric Server). Pour Site Selector uniquement, cette proportion apparaît à la place de la colonne de la proportion des connexions actives.
ou —
Mémoire : Pourcentage de mémoire utilisée (entré à partir de l'agent Metric Server) sur chaque serveur d'équilibrage de charge. Pour Site Selector uniquement, cette proportion apparaît à la place de la colonne de la proportion des nouvelles connexions.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :
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.
-DLB_ADV_SRC_ADDR=adresse_IP
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.
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.
dscontrol advisor start http clusterA:80Cette commande lance le conseiller HTTP sur le port 80 pour le cluster A. Le conseiller HTTP fonctionne sur tous les serveurs connectés au port 80 pour le cluster A.
dscontrol advisor start ADV_custom 80Cette commande lance le conseiller ADV_custom sur le port 80 pour la cluster B et la cluster C. Le conseiller personnalisé fonctionne sur tous les serveurs connectés au port 80 pour la cluster B et la cluster C. (Pour obtenir plus d'informations sur les conseillers personnalisés, voir Création de conseillers personnalisés.)
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).
dscontrol advisor stop ADV_custom clusterB:80
dscontrol advisor stop ADV_custom 80
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.
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.
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.
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.
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
Utilisez l'assistant TLS si vous constatez que l'assistant SSL indique que les serveurs sont arrêtés, savez que les serveurs sont actifs et recevez des messages de type "No ciphers found".
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 :
server set cluster:port:serveur advisorrequest "head / http/1.0" server set cluster:port:serveur advisorresponse "HTTP 200 OK"
dscontrol server set cluster:port:serveur advisorrequest "\"head / http/1.0\"" dscontrol server set cluster:port:serveur advisorresponse "\"HTTP 200 OK\""
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
Pour plus d'informations, voir dscontrol server — Configuration des serveurs.
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.
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.
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 :
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.
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.
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.
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 :
Pour les systèmes AIX, HP-UX, Linux et Solaris, la syntaxe est similaire.
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.
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.
Ci-dessous, sont énumérées les méthodes de classe de base.
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.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
<root_install>ibm\edge\lb\servers\lib\CustomAdvisors
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 :
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.
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.
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.
L'agent Metric Server doit être installé et en cours d'exécution sur tous les serveurs dont la charge est équilibrée.
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.
port correspond au port RMI sur lequel fonctionnent tous les agents du système Metric Server. La valeur par défaut du port RMI est 10004, cette valeur est définie dans le fichier metricserver.cmd.
systemMetric correspond au nom du script (se trouvant sur le serveur dorsal) qui doit s'exécuter sur chacun des serveurs de la configuration sous le cluster indiqué (ou nom de site). Deux scripts sont fournis au client : cpuload et memload . Vous pouvez également créer des scripts de mesure système personnalisés. Le script contient une commande qui renvoie une valeur numérique comprise entre 0 et 100 ou la valeur -1 si le serveur est arrêté. Cette valeur numérique doit représenter une mesure de charge et non une valeur de disponibilité.
Restriction : Sous Windows, si le nom du script System Metric comporte une extension autre que ".exe", vous devez indiquer le nom complet du fichier (par exemple, "monscriptsyst.bat"). Cette restriction est due à une limitation Java.
Les clients peuvent éventuellement écrire leurs propres fichiers scripts personnalisés qui définiront la commande passée par Metric Server sur les serveurs. Vérifiez que tous les scripts personnalisés sont exécutables et se trouvent dans le répertoire suivant :
Les scripts personnalisés doivent renvoyer une valeur de charge comprise entre 0 et 100.
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.
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 :
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.