Ce chapitre contient les sections suivantes :
Cisco CSS Controller ou Nortel Alteon Controller peut se trouver sur la même machine qu'un serveur pour lequel vous équilibrez la charge des demande. On parle alors de co-implantation d'un serveur. Aucune configuration supplémentaire n'est requise.
La fonction haute disponibilité est désormais disponible pour Cisco CSS Controller et pour Nortel Alteon Controller.
Pour une meilleure tolérance aux pannes du contrôleur, la haute disponibilité intègre les fonctions suivantes :
Pour la syntaxe complète de xxxcontrol highavailability, voir ccocontrol highavailability — Contrôle de la haute disponibilité et nalcontrol highavailability — Contrôle de la haute disponibilité.
Pour configurer la haute disponibilité du contrôleur, procédez comme suit :
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role secondaryLes paramètres address (adresse) et partneraddress (adresse du partenaire) sont inversés entre les machines principale et secondaire.
xxxcontrol highavailability set beatinterval 1000
xxxcontrol highavailability usereach 10.20.20.20Vous devez configurer le même nombre de cibles à contacter sur le contrôleur local et sur le contrôleur partenaire.
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeoverCette option n'est requise que pour la maintenance.
Outre la perte de connectivité entre le contrôleur de secours et le contrôleur actif, détectée via les messages de signal de présence, un autre mécanisme de détection d'incidents appelé critères d'accessibilité est disponible.
Lorsque vous configurez la haute disponibilité des contrôleurs, vous pouvez indiquer une liste d'hôtes que chaque contrôleur doit pouvoir contacter pour fonctionner correctement. Vous devez choisir au moins un hôte pour chaque sous-réseau que la machine contrôleur utilise. Il peut s'agir de systèmes hôtes tels que des routeurs, des serveurs IP ou d'autres types d'hôtes.
L'accessibilité de l'hôte est obtenue grâce au conseiller de contact, qui lance un ping à l'hôte. Le basculement a lieu si les messages de signal de présence ne peuvent pas être transmis ou si les critères d'accessibilité sont mieux respectés par la machine contrôleur de secours que par la machine contrôleur principale. Pour prendre la décision sur la base de toutes les informations disponibles, le contrôleur actif envoie régulièrement au contrôleur de secours ses données d'accessibilité, et inversement. Les contrôleurs comparent alors leurs informations d'accessibilité avec celles de leur partenaire et décident lequel doit être actif.
Les deux machines contrôleurs sont configurées avec le rôle principale ou secondaire. Au démarrage, les contrôleurs s'échangent des informations jusqu'à ce que chaque machine soit synchronisée. A ce stade, le contrôleur principal passe à l'état actif et commence à calculer les pondérations et à mettre à jour le commutateur, tandis que la machine secondaire passe à l'état de veille (machine de secours) et surveille la disponibilité de la machine principale.
Si, à tout instant, la machine de secours décèle une défaillance de la machine principale, elle prend le relais des fonctions d'équilibrage de charge de la machine active (défaillante) et devient, à son tour, la machine active. Lorsque la machine principale redevient opérationnelle, les deux machines déterminent quel sera le contrôleur actif en fonction de la stratégie de récupération configurée.
Il existe deux types de stratégie de récupération :
Le contrôleur principal passe à l'état actif (calcule et met à jour les pondérations) dès qu'il redevient opérationnel. La machine secondaire se met en veille dès que la principale est active.
Le contrôleur secondaire actif reste actif même lorsque le contrôleur principal est redevenu opérationnel.
Le contrôleur principal passe à l'état de veille et requiert une intervention manuelle pour revenir à l'état actif.
La stratégie définie doit être identique pour les deux machines.
Pour des exemple de configuration haute disponibilité Cisco CSS Controller, voir Exemples.
Pour des exemple de configuration haute disponibilité Nortel Alteon Controller, voir Exemples.
La fonction contrôleur 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 contrôleur peut utiliser certains ou l'ensembles de collecteurs de mesures suivants pour les décisions de pondération :
Les mesures par défaut sont activeconn (connexions actives) et connrate (débit de la connexion).
Vous pouvez modifier le niveau d'importance relatif des valeurs de mesure. Les proportions sont des pourcentages ; la somme des proportions est égale à 100%. Les valeurs relatives aux connexions actives et au débit de la connexion sont utilisées par défaut et leurs proportions fixées à 50/50. Dans votre environnement,vous serez amené à essayer différentes combinaisons de proportions pour déterminer celui qui offre les meilleures performances.
Pour définir les valeurs de niveau d'importance, procédez comme suit :
Les pondérations sont définies en fonction du temps de réponse et de la disponibilité de l'application, 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, indiquez l'option fixedweight pour le serveur. Pour obtenir une description de l'option fixedweight, voir Pondérations fixées par le contrôleur.
Les pondérations définies s'appliquent à tous les serveurs fournissant un service. Pour chaque service, 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.
Si un conseiller détecte la défaillance d'un serveur, il attribue au serveur une pondération de -1. Pour Cisco CSS Controller et Nortel Alteon Controller le commutateur est informé que le serveur n'est pas disponible et le commutateur n'affecte plus de connexions au serveur.
Sans le contrôleur, les conseillers ne peuvent s'exécuter ni détecter les pannes de serveur. Si vous choisissez de lancer les conseillers mais ne voulez pas que le contrôleur mette à jour la pondération que vous avez fixée pour un serveur particulier, utilisez l'option fixedweight de la commande ccocontrol service pour Cisco CSS Controller ou de la commande nalcontrol server pour Nortel Alteon Controller.
La commande fixedweight vous permet d'affecter à la pondération la valeur souhaitée. La valeur de pondération du serveur reste fixe tant que le contrôleur est en activité à moins que vous n'émettiez une autre commande en attribuant la valeur no à l'option fixedweight.
Pour optimiser les performances globales, vous pouvez réduire la fréquence de collecte des mesures.
Le délai d'inactivité du consultant indique à quelle fréquence le consultant met à jour les pondérations des serveurs. Si le délai d'inactivité du consultant est trop court, le consultant interrompra constamment le commutateur et les performances déclineront. En revanche, s'il est trop long, l'équilibrage de charge du commutateur reposera sur des informations anciennes et incertaines.
Pour fixer le délai d'inactivité du consultant à 1 seconde, par exemple, entrez la commande suivante :
xxxcontrol consultant set IDconsultant sleeptime intervalle
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 service donné, l'écart en pourcentage de la pondération totale dépasse le seuil de sensibilité, les pondérations qu'utilise Load Balancer pour répartir les connexions sont réactualisées. 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, les pondérations qu'utilise Load Balancer ne sont pas mises à jour, car l'écart en pourcentage n'est pas supérieur au seuil. Si, en revanche la pondération totale passe de 100 à 106, les pondérations sont mises à jour. Pour attribuer au seuil de sensibilité du consultant une valeur autre que la valeur par défaut, entrez la commande suivante :
xxxcontrol consultant set consultantID sensitivity percentageChange
Dans la plupart des cas, vous n'aurez pas besoin de modifier cette valeur.
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. Considérez les conseillers comme des clients des serveurs d'application.
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 consultant. Elle apparaît dans le rapport du consultant. Le consultant calcule ensuite un ensemble de valeurs de pondération à partir de toutes ses sources, selon les proportions, puis transmet ces valeurs de pondération au commutateur. Le commutateur 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 consultant 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) pour informer le commutateur de l'inactivité du serveur. Le commutateur n'enverra donc plus aucune connexion en direction de ce serveur tant qu'il ne sera pas de nouveau actif.
Le délai d'inactivité du conseiller détermine la fréquence à 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 consultant. Si le délai d'inactivité du conseiller est trop court, le conseiller interrompra les serveurs constamment et les performances déclineront. En revanche, s'il est trop long, l'équilibrage de charge du consultant reposera sur des informations anciennes et incertaines.
Par exemple, pour fixer à 3 secondes l'intervalle du conseiller HTTP, entrez la commande suivante :
xxxcontrol metriccollector set IDconsultant:HTTP sleeptime 3
Vous pouvez définir le temps nécessaire à un conseiller pour détecter qu'un port particulier d'un serveur ou d'un service est défaillant. 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) au délai d'inactivité du conseiller et du consultant.
Pour attribuer, par exemple, la valeur 9 secondes à timeoutconnect pour le conseiller HTTP, entrez la commande suivante :
xxxcontrol metriccollector set IDconsultant:HTTP timeoutconnect 9
La valeur par défaut de connexion et de réception est trois fois supérieure à la valeur indiquée pour le délai d'inactivité du conseiller.
Les conseillers peuvent essayer de nouveau d'établir une connexion avant de marquer un serveur comme arrêté. Le serveur ne signale un serveur comme étant arrêté qu'après avoir effectué le nombre de tentatives de connexion fixé plus une. Si ce nombre n'a pas été défini, il est par défaut égal à zéro.
Pour le contrôleur CSS Cisco, fixez le nombre de tentatives à l'aide de la commande ccocontrol ownercontent set. Pour plus de détails, voir ccocontrol ownercontent — Contrôle du nom de propriétaire et de la règle de contenu.
Pour le contrôleur Nortel Alteon, fixez le nombre de tentatives à l'aide de la commande nalcontrol service set. Pour plus de détails, voir nalcontrol service — Configuration d'un service.
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 d'administration, tels que :
Il renvoie également les résultats au consultant. 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 (fonction) getLoad 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, puis attend une 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 consultant 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 consultant. 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 consultant. 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 pour fournir les informations sur les serveurs dont vous avez besoin. Un exemple de conseiller personnalisé, ADV_ctlrsample.java, est fourni pour les contrôleurs. Une fois Load Balancer installé, vous pouvez trouver le code exemple dans :
Le nom de fichier de votre conseiller personnalisé doit être au 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_ctrlsample 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 Windows, une commande de compilation peut avoir l'aspect suivant :
rép_install/java/bin/javac -classpath <root_install>ibm\edge\lb\servers\lib\ibmlb.jar ADV_pam.java
où :
Le résultat de la compilation est un fichier .class, par exemple :
ADV_pam.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é :
Démarrez le consultant, puis entrez la commande suivante pour démarrer le conseiller personnalisé :
où :
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 consultant afin que ces dernières soient utilisées dans l'algorithme de pondération du consultant. 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.
Les contrôleurs consultent d'abord la liste fournie de conseillers natifs. S'ils n'y trouvent pas le conseiller recherché, ils consultent la liste des conseillers personnalisés.
Un programme permettant de créer un conseiller de contrôleur type est présenté à la section Conseiller type. Après installation, ce conseiller exemple se trouve dans le répertoire suivant :
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 consultant 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 service pour Cisco CSS Controller ou le rapport du serveur pour Nortel Alteon Controller.
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 les contrôleurs.
Pour Nortel Alteon Controller, ajoutez un consultant de commutateur, puis un service.
où NomMetric est le nom du script System Metric.
Le script System Metric se trouve sur le serveur dorsal et s'exécute sur chacun des serveurs de la configuration sous le contenu de propriétaire ou le service indiqué. Deux scripts, cpuload et memload sont fournis, mais vous pouvez créer vos propres scripts System Metric personnalisés. Le script contient une commande de renvoi d'une valeur numérique. Cette valeur numérique représente une mesure de charge, et non un indicateur de disponibilité.
Restriction : Pour les systèmes Windows, si le nom du script system metric comporte une extension autre que ".exe", vous devez indiquer le nom complet du fichier (par exemple, monScriptSystemMetric.bat). Il s'agit d'une limitation du code Java.
Vous pouvez éventuellement écrire vos 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 :
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 les systèmes Windows : Affectez un alias à AUTRE_ADRESSE dans la pile Microsoft. Pour créer un alias d'adresse dans la pile Microsoft, voir la section sur la création d'un alias d'adresse dans la pile Microsoft d'un serveur de mesure.
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, les contrôleurs peuvent accepter de WLM des informations relatives à la charge et les utiliser dans le processus d'équilibrage de charge. Grâce au conseiller WLM, les contrôleurs ouvrent régulièrement des connexions via le port WLM sur chaque serveur de la table d'hôte consultant et acceptent les chiffres relatifs à la capacité renvoyés. Comme ces chiffres représentent la capacité encore disponible et que le consultant 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). Il existe plusieurs différences importantes entre le conseiller WLM et les autres conseillers contrôleur :
La fonction de consignation binaire permet de stocker les informations du serveur dans des fichiers binaires. Ces fichiers peuvent ensuite être traités pour analyser les informations relatives aux serveurs qui ont été rassemblées.
Les informations suivantes sont stockées dans le journal binaire pour chaque serveur défini dans la configuration.
Le consultant doit s'exécuter pour consigner des informations dans les journaux binaires.
Utilisez l'ensemble de commandes xxxcontrol consultant binarylog pour configurer la consignation binaire.
L'option start commencer à consigner les informations relatives au serveur dans les journaux binaires du répertoire logs. Un journal est créé au début de chaque heure, la date et l'heure constituant le nom du fichier.
L'option stop arrête la consignation des informations relatives au serveur dans les journaux binaires. Le service de consignation est arrêté par défaut.
L'option set interval contrôle la fréquence d'inscription des informations dans les journaux. Le consultant enverra les informations du serveur au serveur de consignation à chaque intervalle défini pour le consultant. Les informations sont écrites dans les journaux uniquement si l'intervalle de consignation indiqué a expiré depuis l'écriture du dernier enregistrement dans le journal. Par défaut, la valeur de l'intervalle de consignation est 60 secondes.
Il y a interaction entre les paramètres relatifs à l'intervalle défini pour le consultant et l'intervalle de consignation. Comme les informations ne sont pas fournies au serveur de consignation plus fréquemment que l'intervalle défini pour le consultant, l'indication d'un intervalle de consignation inférieur à l'intervalle du consultant, entraîne en réalité la définition d'un intervalle de consignation identique à l'intervalle du consultant.
Cette technique de consignation permet d'accéder aux informations du serveur quel que soit le niveau de granularité. Vous pouvez connaître toutes les modifications apportées au serveur qui sont vues par le consultant pour le calcul des pondérations du serveur. Cependant, ces informations peuvent ne pas être requises pour analyser l'utilisation et les tendances du serveur. La consignation des informations du serveur toutes les 60 secondes permet d'obtenir un aperçu de la progression des informations du serveur. La définition d'un intervalle de consignation très faible peut générer un nombre de données très important.
L'option set retention permet de contrôler la durée de conservation des fichiers journaux. Les journaux dont la durée de vie a dépassé la durée définie sont supprimés par le serveur de consignation. Ceci ne se produit que si le consultant appelle le serveur de consignation, de sorte que si vous arrêtez le consultant, les anciens fichiers journaux ne sont pas supprimés.
Un exemple de programme Java et un fichier de commandes sont fournis dans le répertoire suivant :
Ce modèle indique comment rappeler toutes les informations contenues dans les fichiers journaux pour les afficher à l'écran. Il peut être personnalisé pour effectuer n'importe quel type d'analyse.
Par exemple (à l'aide du script et du programme fournis) :
xxxlogreport 2002/05/01 8:00 2002/05/01 17:00
Cet exemple permet d'obtenir un rapport sur les informations du serveur du contrôleur de 8 à 17 heures le premier mai 2002.
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 lorsqu'un serveur est inactif ou simplement d'enregistrer l'erreur. Le répertoire suivant contient des exemples de script que vous pouvez personnaliser :
TPour exécuter les fichiers, copiez-les dans le répertoire suivant, puis renommez chaque fichier en fonction des directions indiquées dans le script :
Les exemples de scripts suivants, dans lesquels xxx est cco pour Cisco CSS Controller, et nal pour Nortel Alteon Controller sont fournis :