Version 7.0
Numéro de document : GC31-6921-00
Important |
---|
Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à l'annexe E, Remarques. |
Première édition (juin 2008)
La présente édition s'applique à :
et à toutes les versions et modifications ultérieures jusqu'à spécification contraire dans de nouvelles éditions.
Pour commander des publications, prenez contact avec votre ingénieur commercial IBM ou votre agence commerciale IBM.
(C) Copyright International Business Machines Corporation 2008. All rights reserved.
U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Composant CBR (Content Based Routing)
Composant Cisco CSS Controller
Composant Nortel Alteon Controller
Fonctions et fonctions avancées de Load Balancer
Administration et identification des incidents de Load Balancer
Le présent document explique comment installer, configurer, utiliser et dépanner IBM(R) WebSphere(R) Application Server Load Balancer pour AIX(R), HP-UX, Linux(TM), Solaris et Windows(R). Ce produit était connu sous les noms de Edge Server Network Dispatcher, SecureWay(R) Network Dispatcher, eNetwork Dispatcher et Interactive Network Dispatcher.
Le Guide d'administration de Load Balancer s'adresse à des administrateurs réseau et système chevronnés, qui connaissent parfaitement leurs systèmes d'exploitation et les services Internet fournis. Aucune connaissance préalable de Load Balancer n'est requise.
Ce manuel n'assure pas le support des versions antérieures de Load Balancer.
Le site Web du centre de documentation Edge Components propose un lien vers la version courante du présent manuel aux formats HTML et PDF.
Pour obtenir les mises à jour les plus récentes de Load Balancer, visitez la page Web d'assistance et le lien vers le site des notes techniques.
Pour accéder à ces sites ainsi qu'aux pages Web associées, cliquez sur les liens répertoriés à la section Documents associés et sites Web.
Des fonctions d'accessibilité permettent aux personnes à mobilité réduite ou malvoyantes d'utiliser sans problème les logiciels. Les principales fonctions d'accessibilité de Load Balancer sont les suivantes :
Vos commentaires sont importants dans la mesure où ils nous aident à offrir des informations précises et de qualité. Pour tout commentaire sur ce manuel ou sur toute autre documentation Edge :
Cette section présente Load Balancer et ses composants, décrit en détail les fonctions de configuration disponibles, répertorie les matériels et logiciels requis et fournit des instructions d'installation. Elle se compose des chapitres suivants :
Ce chapitre contient une présentation générale de Load Balancer et comporte les sections suivantes :
La section Gestion du réseau : Fonctions Load Balancer requises contient une liste complète des fonctions avancées de configuration fournies par chacun des composants de Load Balancer, qui vous permettra de déterminer celles qui sont les mieux adaptées à la gestion de votre réseau.
Load Balancer est une solution logicielle de distribution des demandes client entrantes à plusieurs serveurs. Il permet d'optimiser les performances en orientant les demandes de session TCP/IP vers différents serveurs au sein d'un groupe, assurant ainsi une répartition équilibrée des demandes entre tous les serveurs. Cette procédure d'équilibrage de charge est parfaitement transparente, tant pour l'utilisateur que pour les applications. Load Balancer s'avère particulièrement utile pour les applications telles que les serveurs de messagerie électronique, les serveurs Internet (WWW), les demandes de bases de données parallèles distribuées et autres applications TCP/IP.
Appliqué à des serveurs Web, Load Balancer peut contribuer à accroître les capacités d'un site en apportant une solution puissante, souple et modulable aux incidents liés à la surcharge des réseaux. Si les visiteurs ne peuvent pas accéder à votre site pendant les périodes d'affluence, Load Balancer peut déterminer automatiquement le serveur le mieux placé pour traiter les demandes en instance. De cette manière, la rentabilité de votre site augmente en même temps que la satisfaction de vos clients.
Load Balancer comprend les cinq composants suivants qui, employés conjointement ou séparément, vous permettront d'obtenir les meilleurs résultats en matière d'équilibrage de charge :
Pour le protocole HTTP, vous pouvez utiliser le composant Dispatcher pour équilibrer la charge à partir du contenu de la demande du client. Le choix du serveur est fonction du résultat de la comparaison de l'URL à une règle donnée. Le routage cbr de Dispatcher (méthode d'acheminement cbr) ne requiert pas Caching Proxy.
Pour plus d'informations sur les composants Dispatcher, CBR, Site Selector, Cisco CSS Controller et Nortel Alteon Controller, voir Composants de Load Balancer.
Le nombre d'utilisateurs et de réseaux qui se connectent au réseau mondial Internet connaît une croissance exponentielle. Cette croissance entraîne des problèmes d'évolutivité pouvant limiter l'accès des utilisateurs aux sites les plus fréquentés.
Actuellement, les administrateurs de réseau utilisent diverses méthodes pour optimiser l'accessibilité. Avec certaines de ces méthodes, vous pouvez, par exemple, sélectionner un autre serveur de manière aléatoire lorsque le premier choisi répond trop lentement ou ne répond pas. Cette approche est peu pratique, peu conviviale et inefficace. Autre méthode utilisée, l'approche circulaire standard, dans laquelle le serveur de noms de domaine sélectionne tour à tour des serveurs pour traiter les demandes. Cette approche est sans doute meilleure que la première, mais reste inefficace dans la mesure où l'acheminement du trafic s'effectue sans tenir compte de la charge des serveurs. En outre, même si un serveur est défaillant, les demandes continuent de lui être adressées.
Né de ce besoin d'une solution plus puissante, Load Balancer apporte nombre d'améliorations par rapport aux solutions antérieures comparables :
Pour répondre à l'augmentation du nombre de demandes client, IND permet d'ajouter des serveurs de manière dynamique, ouvrant ainsi l'accès à des dizaines de millions de demandes chaque jour sur des dizaines, voire des centaines, de serveurs.
L'équilibrage de charge permet à chaque groupe de serveurs d'utiliser ses ressources matérielles de manière optimale en réduisant les surcharges qui se produisent fréquemment avec une méthode de permutation de serveurs circulaire classique.
Load Balancer utilise les protocoles TCP/IP ou UDP/IP standard. Il peut être ajouté à n'importe quel réseau sans qu'aucune modification matérielle soit nécessaire. C'est un produit simple à installer et à configurer.
Avec la méthode d'acheminement de niveau MAC simple qu'il utilise, Dispatcher se contente de surveiller les transmissions entrantes du client vers le serveur. Il n'effectue aucun contrôle des transmissions en sortie, du serveur vers le client. Si l'on compare à d'autres méthodes, cet aspect réduit sensiblement son impact sur les performances des applications et permet même d'accroître celles du réseau.
Les composants Dispatcher, Cisco CSS Controller et Nortel Alteon Controller disposent d'une fonction intégrée assurant une haute disponibilité ; à tout moment, une machine de secours peut assurer l'équilibrage de charge en cas de défaillance du serveur principal. Si l'un des serveurs ne répond plus, le traitement des demandes se poursuit sur un autre serveur. L'arrêt d'un serveur ne constitue plus une défaillance majeure et le site conserve ainsi sa haute disponibilité.
Pour plus d'informations, voir Haute disponibilité fournie par Load Balancer
Associé à Caching Proxy, le composant CBR peut relayer les demandes HTTP et HTTPS (SSL) vers des serveurs spécifiques en fonction du contenu demandé. Par exemple, si une demande contient la chaîne "/cgi-bin/" dans la partie répertoire de l'URL et que le serveur est un serveur local, CBR peut acheminer la demande vers un ensemble de serveurs spécialisés dans les demandes cgi et choisir parmi ceux-ci le serveur optimal.
Le composant Dispatcher assure aussi l'acheminement sur la base du contenu, mais ne nécessite pas que Caching Proxy soit installé. Etant donné que la fonction CBR du composant Dispatcher est exécutée dans le noyau à la réception des paquets, l'acheminement est plus rapide que celui réalisé par le composant CBR. Le composant Dispatcher exécute la fonction de routage cbr pour HTTP (avec la règle de type de contenu) et HTTPS (avec l'affinité des ID de session).
Le composant Dispatcher offre une fonctionnalité de haute disponibilité intégrée, de sorte que Dispatcher ne constitue plus un point unique de défaillance dans votre réseau. Cette dernière implique l'utilisation d'une deuxième machine Dispatcher, chargée de contrôler la machine principale, et qui reste en attente, prête à assurer l'équilibrage de charge en cas d'incident sur la machine principale. Le composant Dispatcher offre également la fonction de haute disponibilité réciproque qui permet à deux machines de travailler simultanément en mode principal et secondaire l'une avec l'autre. Voir Configuration de la haute disponibilité.
Vous pouvez également atteindre un niveau de haute disponibilité avec le composant CBR lorsque vous utilisez une configuration à deux niveaux avec une machine Dispatcher répartissant la charge sur plusieurs serveurs dotés de CBR.
Les contrôleurs étant dotés d'une fonctionnalité de haute disponibilité, chaque contrôleur ne constitue plus un point unique de défaillance. Le contrôleur d'un poste peut être configuré en tant que contrôleur principal et celui d'un autre poste en tant que contrôleur de secours. Le contrôleur de secours surveille le contrôleur principal et se tient prêt à fournir aux commutateurs les mesures de pondération de serveur adéquates en cas de défaillance du contrôleur principal. Pour plus d'informations, voir Haute disponibilité.
Ce chapitre contient une présentation générale des composants Load Balancer et comporte les sections suivantes :
La section Gestion du réseau : Fonctions Load Balancer requises contient une liste complète des fonctions avancées de configuration fournies par chacun des composants de Load Balancer, qui vous permettra de déterminer celles qui sont les mieux adaptées à la gestion de votre réseau.
Les cinq composants de Load Balancer sont Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller et Nortel Alteon Controller. Load Balancer permet d'utiliser ces composants séparément ou ensemble, selon la configuration de votre site. La section qui suit présente ces composants.
Le composant Dispatcher assure l'équilibrage de la charge du trafic entre les serveurs via une combinaison unique de logiciels d'équilibrage de charge et de gestion. Dispatcher peut aussi détecter l'échec d'un serveur et canaliser le trafic sur les serveurs qui l'entourent. Dispatcher prend en charge les protocoles HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP et toute application de type TCP ou UDP sans état.
Toutes les demandes de client adressées à la machine Dispatcher sont acheminées vers le serveur le mieux adapté, compte tenu de mesures définies de façon dynamique. Vous pouvez utiliser les valeurs par défaut associées à ces mesures ou les modifier au cours du processus de configuration.
Dispatcher offre trois méthodes d'acheminement (indiquées sur le port) :
Le composant Dispatcher constitue la clé de voûte d'une gestion efficace et durable d'un réseau de serveurs étendu et modulable. Avec Dispatcher, vous pouvez lier différents serveurs en un seul serveur virtuel. De cette manière, le site est associé à une adresse IP unique. Dispatcher fonctionne indépendamment de tout serveur de noms de domaine ; toutes les demandes sont dirigées sur l'adresse IP de la machine Dispatcher.
Dispatcher présente des avantages spécifiques indéniables en matière d'équilibrage de charge sur des serveurs en cluster. Ces atouts permettent de mettre en oeuvre une gestion de site aussi efficace que stable.
La Figure 1 est la représentation physique d'un site utilisant une configuration de réseau Ethernet. La machine Dispatcher peut être installée sans apporter de changement physique à la physionomie du réseau. Après acheminement d'une demande de client au serveur optimal par Dispatcher, la réponse correspondante est transmise directement du serveur au client sans intervention de Dispatcher lorsque la méthode d'acheminement MAC est utilisée.
Figure 2. Exemple de site utilisant Dispatcher et Metric Server pour gérer les serveurs
La Figure 2 représente un site dans lequel tous les serveurs se trouvent sur un réseau local. Le composant Dispatcher permet d'acheminer les demandes et le composant Metric Server permet de fournir les informations de charge du système à la machine Dispatcher.
Dans cet exemple, le démon Metric Server est installé sur chaque serveur principal. Vous pouvez utiliser Metric Server avec le composant Dispatcher ou tout autre composant Load Balancer.
Figure 3. Exemple de site utilisant Dispatcher pour gérer les serveurs locaux et éloignés
La prise en charge de réseau étendu de Dispatcher permet d'utiliser à la fois des serveurs locaux et éloignés (c'est-à-dire des serveurs résidant sur différents sous-réseaux). La Figure 3 présente une configuration dans laquelle une machine Dispatcher locale (Dispatcher 1) sert de point d'entrée pour l'ensemble des demandes. Elle distribue ces demandes entre ses propres serveurs locaux (Serveur A, Serveur B, Serveur C) et à la machine Dispatcher éloignée (Dispatcher 2), qui équilibre la charge sur ses serveurs locaux (Serveur G, Serveur H, Serveur I).
Lors de l'utilisation de la méthode d'acheminement NAT de Dispatcher ou du support GRE, le support de réseau étendu avec Dispatcher peut aussi être assuré sans utiliser de serveur Dispatcher sur le site distant (où se trouvent les serveurs D, E et F). Pour plus d'informations, voir Réacheminement NAT/NAPT de Dispatcher (méthode d'acheminement nat) et Support GRE (Generic Routing Encapsulation).
CBR coopère avec Caching Proxy pour relayer les demandes des clients aux serveurs HTTP ou HTTPS (SSL) indiqués. Il permet de manipuler les détails de la mémoire cache pour accélérer le rappel des documents Web avec une petite largeur de bande. CBR et Caching Proxy examinent les requêtes HTTP à l'aide des types de règle indiqués.
CBR permet de spécifier un ensemble de serveurs qui prend en charge une demande en fonction de son contenu. CBR vous permet d'indiquer plusieurs serveurs pour chaque type de requête. Par conséquent, les requêtes peuvent être équilibrées pour obtenir une réponse optimale du client. CBR peut aussi détecter les incidents qui se produisent sur un serveur et arrêter d'acheminer des demandes vers ce dernier. L'algorithme d'équilibrage de charge utilisé par le composant CBR est identique à l'algorithme éprouvé utilisé par le composant Dispatcher.
Lorsqu'une demande est reçue par Caching Proxy, elle est comparée aux règles qui ont été définies dans le composant CBR. En cas de correspondance, l'un des serveurs associés à cette règle est désigné pour prendre en charge la demande. Caching Proxy continue alors son traitement normal pour acheminer la demande vers le serveur sélectionné.
CBR offre les mêmes fonctions que Dispatcher à l'exception des fonctions de haute disponibilité, de sous-agent SNMP, de réseau étendu et de quelques commandes de configuration.
Caching Proxy doit être en fonction pour permettre à CBR d'équilibrer la charge des demandes des clients.
Figure 4. Exemple de site utilisant CBR pour gérer les serveurs locaux
La Figure 4 montre la représentation logique d'un site utilisant CBR pour acheminer des demandes issues des serveurs locaux. Le composant CBR utilise Caching Proxy pour acheminer les demandes des clients (HTTP ou HTTPS) aux serveurs en fonction du contenu de l'adresse URL.
Site Selector fonctionne avec d'autres serveurs de noms pour équilibrer la charge sur un groupe de serveurs à l'aide des mesures et des pondérations recueillies. Vous pouvez créer une configuration de site pour assurer l'équilibrage de charge sur un groupe de serveurs sur la base du nom de domaine utilisé pour la demande d'un client.
Un client envoie une demande de résolution de nom de domaine à un serveur de noms appartenant au réseau. Le serveur de noms achemine la demande vers la machine Site Selector. Site Selector résout le nom de domaine en adresse IP de l'un des serveurs qui a été configuré sous le nom du site. Site Selector renvoie l'adresse IP du serveur sélectionné au serveur de noms. Le serveur de noms renvoie l'adresse IP au client.
Metric Server est un composant de Load Balancer qui surveille le système et doit être installé sur chaque serveur avec équilibrage de charge de votre configuration. Metric Server permet à Site Selector de surveiller le niveau d'activité d'un serveur, de détecter le moment où un serveur est le moins chargé et de détecter un serveur défaillant. Par charge, on entend le travail effectivement fourni par le serveur. En personnalisant les fichiers script de mesure du système, vous pouvez choisir le type de mesure utilisé pour évaluer la charge. Site Selector peut être configuré en fonction de chaque environnement, en tenant compte de facteurs tels que la fréquence des accès, le nombre total d'utilisateurs et les différents types d'accès (requêtes courtes, longues, à forte ou faible consommation de ressources CPU).
La Figure 5 illustre un site utilisant le composant Site Selector pour répondre aux demandes. Serveur 1, Serveur 2 et Serveur 3 sont des serveurs locaux. Serveur 4, Serveur 5 et Serveur 6 sont des serveurs distants.
Un client envoie une demande de résolution de nom de domaine à un serveur de noms client. Le serveur de noms client achemine la demande vers la machine Site Selector (chemin d'accès 1) via DNS. Site Selector résout ensuite le nom de domaine en adresse IP de l'un des serveurs. Site Selector renvoie l'adresse IP du serveur sélectionné au serveur de noms client. Le serveur de noms renvoie l'adresse IP au client.
Une fois que le client a reçu l'adresse IP du serveur, il achemine les demandes d'application directement au serveur sélectionné (chemin d'accès 2).
Cisco CSS Controller constitue une solution complémentaire avec les commutateurs Cisco CSS série 11000. La solution combinée réunit de robustes fonctions d'acheminement de paquets et de routage de contenu aux algorithmes de reconnaissance sophistiqués de Load Balancer pour déterminer la disponibilité et les informations de charge du service (base de données ou application serveur principal). La fonction Cisco CSS Controller fait appel à l'algorithme de calcul de pondération de Load Balancer, aux conseillers standard et personnalisés et à Metric Server pour déterminer les mesures, la santé et la charge du service. Cisco CSS Controller utilise ces informations pour générer les mesures de pondération du service, qu'il envoie au serveur Cisco CSS Switch pour la sélection du service optimal, l'optimisation de la charge et la tolérance aux pannes.
Cisco CSS Controller suit de nombreux critères, dont :
Lorsqu'un serveur Cisco CSS Switch, sans Cisco CSS Controller, détermine la santé d'un service fournisseur de contenu, il utilise les temps de réponse aux demandes de contenu ou d'autres mesures de réseau. Avec Cisco CSS Controller, le serveur Cisco CSS Switch se décharge de ces activités sur le serveur Cisco CSS Controller. Cisco CSS Controller influence la pondération du service ou sa faculté à servir le contenu, et active ou suspend un service, selon le cas, lorsque le service devient disponible ou indisponible.
Cisco CSS Controller :
Cisco CSS Controller, conjointement au serveur Cisco CSS Switch, constitue une solution idéale qui combine la commutation de contenu à haute vitesse avec la reconnaissance d'applications sophistiquées, la tolérance aux pannes et l'optimisation de la charge des services. Cisco CSS Controller appartient à une solution globale complémentaire située entre le serveur Cisco CSS Switch et la fonction Load Balancer d'IBM WebSphere Application Server.
Nortel Alteon Controller, conjointement à la famille Nortel Alteon de commutateurs Web, constitue une solution complémentaire qui combine capacité et vitesse de transmission des paquets des commutateurs avec la reconnaissance des algorithmes sophistiqués de Load Balancer pour déterminer la pondération de charge des serveurs.
Nortel Alteon Controller permet de développer des conseillers personnalisés capables d'évaluations avec reconnaissance des applications plus intelligentes de la disponibilité et de la charge des applications utilisées pour déployer des services.
Le composant Metric Server fournit des informations relatives à la charge du système, telles que l'utilisation de la mémoire et de la CPU, ainsi qu'une structure vous permettant de développer des dispositifs personnalisés de mesure de la charge système.
Nortel Alteon Controller collecte de nombreux types de mesures pour déterminer les pondérations des serveurs dont la charge est équilibrée par des commutateurs Nortel Alteon Web Switches, notamment :
Nortel Alteon Controller utilise SNMP pour communiquer avec le commutateur. Les informations de configuration, d'état et de connexion sont extraites du commutateur. Lorsque le contrôleur a calculé les pondérations du serveur, celles-ci sont définies sur le commutateur. Le commutateur se sert des pondérations définies par le contrôleur pour sélectionner le serveur le mieux à même de traiter les demandes de service des clients.
Figure 7. Exemple de site utilisant Nortel Alteon Controller pour gérer les serveurs locaux
La gestion du contrôleur peut s'effectuer à l'aide d'un navigateur, d'une interface graphique distante ou d'une interface de ligne de commande.
Nortel Alteon Controller, associé à la famille Nortel Alteon des commutateurs Web, constitue une solution idéale qui combine la commutation de paquets avec la reconnaissance d'applications sophistiquées, la tolérance aux pannes et l'optimisation de la charge des serveurs. Nortel Alteon Controller fait partie d'une solution complémentaire entre la famille Nortel Alteon des commutateurs et WebSphere d'IBM.
Ce chapitre présente toutes les fonctions de configuration des composants de Load Balancer de sorte que vous puissiez déterminer celles qui sont les mieux adaptées à la gestion de votre réseau :
Pour optimiser l'équilibrage de la charge sur les serveurs et garantir le choix du serveur approprié, voir :
Dispatcher assure l'équilibrage de charge sur vos serveurs pour les protocoles HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP et toute application de type TCP ou UDP sans état.
_ Pour configurer Load Balancer à partir d'une autre machine que celle où réside ce composant, voir Administration à distance de Load Balancer.
_ Pour exécuter Dispatcher sur la même machine qu'un serveur Web dont vous équilibrez la charge, voir Utilisation de serveurs implantés au même endroit.
_ Pour supprimer de votre réseau les restrictions liées au principe de point de défaillance unique à l'aide de Dispatcher, voir Haute disponibilité simple et Haute disponibilité réciproque.
Lors de l'équilibrage de la charge du trafic SSL (HTTPS) :
_ Pour vous assurer que le client utilise le même serveur SSL pour plusieurs connexions, voir Fonctionnement de la fonction d'affinité pour Load Balancer.
_ Pour vous assurer que le client utilise le même serveur pour le trafic HTTP et SSL, voir Affinité de ports croisés.
_ Pour vous assurer que le client utilise le même serveur pour plusieurs connexions, voir Fonctionnement de la fonction d'affinité pour Load Balancer.
_ Pour vous assurer qu'un groupe de clients utilise le même serveur pour plusieurs connexions, voir Masque d'adresse de l'affinité (masque de maintien de routage).
_ Pour supprimer un serveur de votre configuration (pour des besoins de maintenance, par exemple) sans interrompre le trafic client, voir Mise au repos de la gestion des connexions serveur.
Pour diriger les clients vers différents groupes de serveurs pour la même adresse Web, vous pouvez ajouter des "règles" à la configuration de Dispatcher. Pour plus d'informations, voir Configuration d'un équilibrage de charge basé sur des règles.
_ Pour diriger les clients vers différents groupes de serveurs en fonction de l'adresse IP source du client, voir Utilisation de règles basées sur l'adresse IP des clients.
_ Pour diriger les clients vers différents groupes de serveurs en fonction du port du client, voir Utilisation de règles basées sur le port du client.
_ Pour diriger les clients vers différents groupes de serveurs en fonction de l'heure, voir Utilisation de règles basées sur l'heure.
_ Pour diriger les clients vers des serveurs en fonction des bits TOS (Type Of Service, type de services) des paquets réseau, voir Utilisation de règles basées sur le type de services (TOS).
_ Pour diriger les clients vers différents groupes de serveurs en fonction du trafic sur le site :
_ à l'aide du nombre de connexions par seconde, voir Utilisation de règles basées sur le nombre de connexions par seconde.
_ à l'aide du nombre total de connexions actives, voir Utilisation de règles basées sur le nombre total de connexions actives.
_ par réservation et partage de la largeur de bande entre différentes adresses Web, voir Utilisation de règles basées sur la largeur de bande réservée et sur la largeur de bande partagée.
_ en vous assurant que le trafic est correctement évalué pour chaque ensemble de serveurs, voir Option d'évaluation de serveur.
_ Pour diriger le trafic excédentaire vers un ensemble de serveurs par défaut (par exemple, des serveurs qui répondront "site occupé"), voir Utilisation de règles toujours vraies.
_ Pour remplacer l'affinité client afin de garantir qu'un client ne reste pas "maintenu" à un serveur de débordement, voir Substitution d'affinité de port.
Pour vous assurer que les clients SSL reviennent au même serveur, sur la base de l'ID SSL de la demande client
_ Reportez-vous à la page ***.
Pour acheminer les clients HTTP vers différents groupes de serveurs à l'aide de règles basées sur la correspondance avec le contenu de l'adresse URL de la demande client, voir Routage cbr de Dispatcher (méthode d'acheminement cbr) et Utilisation de règles basées sur le contenu des demandes.
_ Pour différencier deux adresses URL et leurs applications de service, voir Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
_ Pour vous assurer que les clients reviennent au même serveur lors de la demande d'un contenu similaire dans plusieurs connexions à l'aide de cookies créés par vos serveurs Web, voir Affinité de cookie passif.
_ Pour équilibrer le trafic Web sur des serveurs relais avec mémoire cache permettant de placer un contenu unique en cache sur chaque serveur (augmentant ainsi la taille de la mémoire cache du site en éliminant les éléments superflus placés en mémoire cache sur plusieurs machines), voir Affinité URI.
La méthode d'acheminement CBR de Dispatcher présente l'avantage de répondre plus rapidement aux requêtes client que le composant CBR. De plus, elle ne requiert pas l'installation et l'emploi du module Caching Proxy.
Si votre réseau inclut du trafic SSL (client via serveur) totalement sécurisé, l'utilisation du composant CBR (conjointement au module Caching Proxy) présente l'avantage de traiter le chiffrement et le déchiffrement requis pour effectuer un routage par contenu. Pour des connexions totalement sécurisées, la méthode d'acheminement CBR de Dispatcher ne peut être configurée qu'avec affinité d'ID SSL car elle ne peut pas traiter le chiffrement et le déchiffrement pour effectuer un réel routage par contenu sur l'URL de la requête client.
L'équilibrage de charge d'un réseau étendu peut être obtenu à l'aide de plusieurs méthodes distinctes.
_ Pour équilibrer la charge sur des serveurs éloignés à l'aide de la fonction de réseau étendu de Dispatcher, voir Configuration du support de réseau étendu pour Dispatcher et Support GRE (Generic Routing Encapsulation).
_ Pour équilibrer la charge sur des serveurs éloignés à l'aide de la méthode d'acheminement NAT de Dispatcher, voir Réacheminement NAT/NAPT de Dispatcher (méthode d'acheminement nat).
_ Pour équilibrer la charge d'une adresse Web sur plusieurs démons de serveur d'une même machine, écoutant chacun un port différent, voir Réacheminement NAT/NAPT de Dispatcher (méthode d'acheminement nat).
_ Pour placer le trafic de Dispatcher sur un autre réseau que celui du trafic client (afin d'améliorer les performances en réduisant les conflits sur le réseau externe), voir Utilisation d'une configuration réseau privée.
_ Pour combiner plusieurs adresses Web en une seule configuration, voir Utilisation d'un cluster générique pour combiner les configurations serveurs.
_ Pour équilibrer la charge de pare-feu, voir Utilisation du cluster générique pour équilibrer la charge des pare-feux.
_ Pour acheminer le trafic de tous les ports de destination, voir Utilisation du port générique pour acheminer le trafic destiné à un port non configuré.
_ Pour détecter les éventuelles attaques de "refus de service", voir Détection d'attaque de refus de service.
_ Pour analyser le trafic du serveur, voir Utilisation de la consignation binaire pour analyser les statistiques des serveurs.
_ Pour générer des alertes lorsque des serveurs sont marqués comme actifs ou inactifs, voir Utilisation de scripts pour la génération d'une alerte ou d'une erreur du serveur d'enregistrement.
CBR intègre l'équilibrage de charge au module Caching Proxy de WebSphere Application Server pour relayer les demandes des clients aux serveurs HTTP ou HTTPS (SSL) indiqués. Pour pouvoir utiliser CBR, vous devez installer et configurer le module Caching Proxy sur le même poste. Pour plus d'informations sur la configuration de Caching Proxy en vue d'utiliser CBR, voir Etape 1. Configuration de Caching Proxy pour utiliser CBR.
Le composant CBR (ou la méthode d'acheminement CBR du composant Dispatcher), procure à vos clients les avantages suivants :
_ Equilibrage de la charge des requêtes client pour différents types de contenus sur des groupes de serveurs. (Voir Equilibrage de la charge des requêtes pour différents types de contenus.)
_ Amélioration du temps de réponse par optimisation de la répartition du contenu de votre site entre vos serveurs Web. (Voir Division du contenu de votre site pour améliorer le temps de réponse.)
_ Préservation du trafic client en cas de défaillance du serveur par affectation de plusieurs serveurs à chaque partie de votre site. (Voir Copie de sauvegarde du contenu du serveur Web.)
Si votre réseau nécessite le trafic SSL (client via serveur) totalement sécurisé, l'utilisation du composant CBR (conjointement au module Caching Proxy) présente l'avantage de traiter le chiffrement/déchiffrement SSL requis pour effectuer un routage par contenu.
Pour des connexions SSL totalement sécurisées, la méthode d'acheminement CBR de Dispatcher ne peut être configurée qu'avec affinité d'ID SSL car elle ne peut pas traiter le chiffrement/déchiffrement pour effectuer un réel routage par contenu sur l'URL de la requête client.
Pour le trafic HTTP, l'utilisation de la méthode d'acheminement CBR de Dispatcher présente l'avantage de répondre plus rapidement aux requêtes client que le composant CBR. De plus, elle ne requiert pas l'installation et l'emploi du module Caching Proxy.
_ Pour configurer Load Balancer à partir d'une autre machine que celle où réside ce composant, voir Administration à distance de Load Balancer.
_ CBR peut s'exécuter sur le même poste qu'un serveur dont vous équilibrez la charge. Pour plus d'informations, voir Utilisation de serveurs implantés au même endroit.
_ Pour optimiser l'utilisation de la CPU en exécutant plusieurs processus Caching Proxy, voir Utilisation de plusieurs processus Caching Proxy pour optimiser l'utilisation de la CPU.
Pour autoriser le routage par contenu du trafic SSL :
_ Par le biais d'une connexion sécurisée à chaque extrémité (client à proxy et proxy à serveur), voir Equilibrage de charge sur les connexions sécurisées (SSL).
_ Par le biais de connexions sécurisées côté client à proxy uniquement, voir Equilibrage de charge client-proxy dans SSL et proxy-serveur dans HTTP.
_ Pour différencier deux URL et leurs applications de service, voir Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
Pour diriger les clients vers différents groupes de serveurs pour la même adresse Web, vous pouvez ajouter des "règles" à la configuration de CBR. Pour plus d'informations, voir Configuration d'un équilibrage de charge basé sur des règles.
_ Pour diriger les clients vers différents groupes de serveurs en fonction du contenu de l'adresse URL demandée, voir Utilisation de règles basées sur le contenu des demandes.
_ Pour diriger les clients vers différents groupes de serveurs en fonction de l'adresse IP source du client, voir Utilisation de règles basées sur l'adresse IP des clients.
_ Pour diriger les clients vers différents groupes de serveurs en fonction de l'heure, voir Utilisation de règles basées sur l'heure.
_ Pour diriger les clients vers différents groupes de serveurs en fonction du trafic sur le site :
à l'aide du nombre de connexions par seconde, voir Utilisation de règles basées sur le nombre de connexions par seconde.
à l'aide du nombre total de connexions actives, voir Utilisation de règles basées sur le nombre total de connexions actives.
_ Pour diriger le trafic excédentaire vers un ensemble de serveurs par défaut (par exemple, des serveurs qui répondront "site occupé"), voir Utilisation de règles toujours vraies.
_ Pour remplacer l'affinité client afin de garantir qu'un client ne reste pas "maintenu" à un serveur de débordement, voir Substitution d'affinité de port.
_ Pour vous assurer qu'un client utilise le même serveur pour plusieurs connexions, voir Fonctionnement de la fonction d'affinité pour Load Balancer.
_ Pour supprimer un serveur de votre configuration (pour des besoins de maintenance, par exemple) sans interrompre le trafic client, voir Mise au repos de la gestion des connexions serveur.
_ Pour vous assurer que les clients reviennent au même serveur lors de la demande d'un contenu similaire dans plusieurs connexions sans se baser sur des cookies créés par vos serveurs Web, voir Affinité de cookie actif.
_ Pour vous assurer que les clients reviennent au même serveur lors de la demande d'un contenu similaire dans plusieurs connexions à l'aide de cookies créés par vos serveurs Web, voir Affinité de cookie passif.
_ Pour équilibrer le trafic Web sur des serveurs relais avec mémoire cache permettant de placer un contenu unique en cache sur chaque serveur (augmentant ainsi la taille de la mémoire cache du site en éliminant les éléments superflus placés en mémoire cache sur plusieurs machines), voir Affinité URI.
_ Pour supprimer de votre réseau les restrictions liées au principe de point de défaillance unique à l'aide de Dispatcher utilisé dans une configuration de second niveau avec CBR, voir Haute disponibilité fournie par Load Balancer.
_ Pour analyser le trafic du serveur, voir Utilisation de la consignation binaire pour analyser les statistiques des serveurs.
_ Pour générer des alertes lorsque des serveurs sont marqués comme actifs ou inactifs, voir Utilisation de scripts pour la génération d'une alerte ou d'une erreur du serveur d'enregistrement.
Site Selector équilibre la charge d'une requête de service d'annuaire dans un groupe de serveurs
_ Pour configurer Load Balancer à partir d'une autre machine que celle où réside ce composant, voir Administration à distance de Load Balancer.
_ Site Selector peut s'exécuter sur la même machine qu'un serveur dont vous équilibrez la charge sans configuration supplémentaire.
_ La haute disponibilité est inhérente aux méthodologies DNS (Domain Name System) qui utilisent plusieurs modules Site Selector redondants pour une parfaite configuration du serveur de noms parent et un positionnement approprié des méthodes de reprise DNS normales. La retransmission des demandes et le renouvellement des transferts de zone sont des exemples de méthodes de reprise DNS normales.
_ Pour supprimer de votre réseau les restrictions liées au principe de point de défaillance unique à l'aide de Dispatcher utilisé dans une configuration de second niveau avec Site Selector, voir Haute disponibilité fournie par Load Balancer.
_ Pour vous assurer que le client utilise le même serveur pour plusieurs demandes de serveur de noms, voir Fonctionnement de la fonction d'affinité pour Load Balancer.
_ Pour garantir l'affinité client à serveur à l'aide de la méthode DNS standard de définition de la durée de vie (TTL, Time To Live), voir Remarques relatives à la durée de vie (TTL).
Pour acheminer les requêtes des clients vers différents groupes de serveurs pour la résolution des noms de domaine, vous pouvez ajouter des "règles" à la configuration de Site Selector. Pour plus d'informations, voir Configuration d'un équilibrage de charge basé sur des règles.
_ Pour diriger les clients vers différents groupes de serveurs en fonction de l'adresse IP source du client, voir Utilisation de règles basées sur l'adresse IP des clients.
_ Pour diriger les clients vers différents groupes de serveurs en fonction de l'heure, voir Utilisation de règles basées sur l'heure.
_ Pour diriger les clients vers différents ensembles de serveurs en fonction des valeurs de charge de l'ensemble de serveurs, voir :
_ Pour diriger le trafic excédentaire vers un ensemble de serveurs par défaut (par exemple, des serveurs qui répondront "site occupé"), voir Utilisation de règles toujours vraies.
Site Selector peut s'exécuter dans un réseau local (LAN) comme dans un réseau étendu (WAN).
Dans un réseau étendu :
_ Pour équilibrer la charge des demandes de serveur de noms des clients à l'aide d'une technique de permutation circulaire pondérée, aucune configuration supplémentaire n'est nécessaire.
_ Pour évaluer la proximité au réseau du serveur de noms du client par rapport aux serveurs qui fournissent l'application requise (serveurs de destination), reportez-vous à la section Utilisation de la fonction de proximité réseau (Network Proximity).
_ Pour générer des alertes lorsque des serveurs sont marqués comme actifs ou inactifs, voir Utilisation de scripts pour la génération d'une alerte ou d'une erreur du serveur d'enregistrement.
Cisco CSS Controller améliore la fonction d'équilibrage des charges des serveurs Cisco Switch en prêtant plus d'attention aux applications et au système. Le contrôleur utilise des mesures plus appropriées aux applications et au système pour calculer dynamiquement les pondérations des serveurs. Les pondérations sont transmises au commutateur à l'aide de SNMP. Le commutateur utilise les pondérations lors du traitement des demandes des clients ce qui optimise la charge des serveurs et augmente la tolérance aux pannes.
Pour optimiser l'équilibrage de la charge sur les serveurs et garantir le choix du serveur approprié, voir :
_ Optimisation de la fonction d'équilibrage de charge fournie par Load Balancer
_ Conseillers et Création de conseillers personnalisés
_ Pour configurer Load Balancer à partir d'une autre machine que celle où réside ce composant, voir Administration à distance de Load Balancer.
_ Cisco CSS Controller peut s'exécuter sur le même poste qu'un serveur dont vous équilibrez la charge sans configuration supplémentaire.
_ Pour supprimer de votre réseau les restrictions liées au principe de point de défaillance unique, le composant Cisco CSS Switch comme le composant Cisco CSS Controller intègrent des fonctions de haute disponibilité. Pour le commutateur, les fonctions de haute disponibilité sont accessibles via le protocole de redondance CSS. Pour le composant Cisco CSS Controller, un protocole propriétaire permet la configuration en secours automatique des deux contrôleurs.
Pour plus d'informations sur la fonction de haute disponibilité, voir Haute disponibilité.
_ Pour analyser le trafic du serveur, voir Utilisation de la consignation binaire pour analyser les statistiques des serveurs.
_ Pour générer des alertes lorsque des serveurs sont marqués comme actifs ou inactifs, voir Utilisation de scripts pour la génération d'une alerte ou d'une erreur du serveur d'enregistrement.
Nortel Alteon Controller améliore la fonction d'équilibrage des charges des serveurs Nortel Alteon Switch en prêtant plus d'attention aux applications et au système. Le contrôleur utilise des mesures plus appropriées aux applications et au système pour calculer dynamiquement les pondérations des serveurs. Les pondérations sont transmises au commutateur à l'aide de SNMP. Le commutateur utilise les pondérations lors du traitement des demandes des clients ce qui optimise la charge des serveurs et augmente la tolérance aux pannes.
Pour optimiser l'équilibrage de la charge sur les serveurs et garantir le choix du serveur approprié, voir :
_ Optimisation de la fonction d'équilibrage de charge fournie par Load Balancer
_ Conseillers et Création de conseillers personnalisés
_ Pour configurer Load Balancer à partir d'une autre machine que celle où réside ce composant, voir Administration à distance de Load Balancer.
_ Nortel Alteon Controller peut s'exécuter sur le même poste qu'un serveur dont vous équilibrez la charge sans configuration supplémentaire.
_ Pour supprimer de votre réseau les restrictions liées au principe de point de défaillance unique, le commutateur Web comme le contrôleur Nortel Alteon intègrent des fonctions de haute disponibilité. Pour le commutateur, la haute disponibilité est accessible via le protocole de redondance pour les connexions aux serveurs et les services. Le contrôleur Nortel Alteon offre la haute disponibilité via un protocole propriétaire qui permet la configuration en secours automatique de deux contrôleurs.
Pour plus d'informations sur la fonction de haute disponibilité, voir Haute disponibilité.
_ Pour analyser le trafic du serveur, voir Utilisation de la consignation binaire pour analyser les statistiques des serveurs.
_ Pour générer des alertes lorsque des serveurs sont marqués comme actifs ou inactifs, voir Utilisation de scripts pour la génération d'une alerte ou d'une erreur du serveur d'enregistrement.
Le présent chapitre décrit l'installation de Load Balancer à l'aide des outils de création de packages du système et la configuration requise pour tous les systèmes d'exploitation pris en charge.
Pour les instructions d'installation à l'aide du programme d'installation du produit, reportez-vous au document intitulé Concepts, planification et installation pour Edge Components.
Le SDK Java 2 est automatiquement installé avec Load Balancer sur toutes les plateformes.
Si vous migrez à partir d'une version antérieure de Load Balancer ou réinstallez un système d'exploitation, avant d'effectuer l'installation, vous pouvez sauvegarder des fichiers de configuration ou des fichiers script antérieurs de Load Balancer.
Suivant le type d'installation, les packages du composant Load Balancer qui sont répertoriés dans cette section ne sont pas tous fournis.
Pour plus d'informations sur les conditions matérielles et logicielles requises, y compris les navigateurs pris en charge, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
Le Tableau 1 répertorie les images installp de
Load Balancer et l'ordre d'installation recommandé à l'aide de
l'outil d'installation de packages système.
Tableau 1. Images installp d'AIX
Base | ibmlb.base.rte |
Administration (avec messages) |
|
Pilote de périphérique | ibmlb.lb.driver |
Licence | ibmlb.lb.license |
Composants Load Balancer (avec messages) |
|
Documentation (avec messages) |
|
Serveur de mesures | ibmlb.ms.rte |
Où composant correspond à disp (Dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) ou nal (Nortel Alteon Controller). Vous pouvez éventuellement sélectionner le ou les composant(s) à installer.
Où langue peut prendre les valeurs suivantes :
Le package de la documentation contient uniquement de l'anglais. Les traductions de l'ensemble des documentations Load Balancer se trouvent sur le site Web : www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Si une version antérieure est déjà installée sur votre système, supprimez-la avant d'installer la nouvelle. Assurez-vous, tout d'abord, que tous les exécuteurs et serveurs sont arrêtés. Puis, pour désinstaller l'intégralité du produit, entrez installp -u ibmlb (ou l'ancien nom, par exemple, intnd). Pour désinstaller certains jeux de fichiers, spécifiez-les au lieu d'entrer le nom du module.
Lorsque vous installez le produit, le choix vous est offert d'installer tout ou partie des composants suivants :
Effectuez les opérations ci-dessous pour installer Load Balancer pour les systèmes AIX :
A l'aide de SMIT :
Après l'exécution de la commande, appuyez sur Fin, puis sélectionnez l'option permettant de quitter Smit à partir du menu de sortie ou appuyez sur F12. Si vous utilisez SMITTY, appuyez sur F10 pour quitter le programme.
A partir de l'invite de commande :
Si vous effectuez l'installation à partir d'un CD-ROM, entrez les commandes suivantes pour le monter :
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Pour savoir quelle(s) commande(s) utiliser pour installer les packages Load Balancer
choisis pour les systèmes AIX, reportez-vous au tableau suivant :
Tableau 2. Commandes d'installation AIX
Base | installp -acXgd périphérique ibmlb.base.rte |
Administration (avec messages) | installp -acXgd périphérique ibmlb.admin.rte ibmlb.msg.langue.admin |
Pilote de périphérique | installp -acXgd périphérique ibmlb.lb.driver |
Licence | installp -acXgd périphérique ibmlb.lb.license |
Composants Load Balancer (avec msgs). Inclut : Dispatcher, CBR, Site Selector, Cisco CSS Controller et Nortel Alteon Controller | installp -acXgd périphérique ibmlb.composant.rte ibmlb.msg.langue.lb |
Documentation (avec messages) | installp -acXgd périphérique ibmlb.doc.rte ibmlb.msg.en_US.lb |
Serveur de mesures | installp -acXgd périphérique ibmlb.ms.rte |
La variable unité prend les valeurs suivantes :
Assurez-vous que la colonne de résultat du résumé d'opération contient la mention "SUCCESS" (réussite) pour chaque composant de Load Balancer installé (état APPLY). Ne poursuivez pas avant d'avoir réussi à installer tous les composants choisis.
installp -ld périphérique
La variable unité prend les valeurs suivantes :
Pour démonter le CD-ROM, tapez la commande suivante :
unmount /cdrom
lslpp -h | grep ibmlb
Si vous avez installé l'intégralité du produit, cette commande génère le résultat suivant :
ibmlb.base.rte ibmlb.admin.rte ibmlb.lb.driver ibmlb.lb.license ibmlb.<composant>.rte ibmlb.doc.rte ibmlb.ms.rte ibmlb.msg.langue.admin ibmlb.msg.en_US.doc ibmlb.msg.langue.lb
Les chemins d'installation de Load Balancer sont les suivants :
Pour l'administration à distance de Load Balancer, à l'aide de l'invocation RMI (Remote Method Invocation), vous devez installer les modules Administration, Base, Composant et Licence sur le client. Pour plus d'informations sur l'invocation RMI, voir Remote Method Invocation (RMI).
Pour plus d'informations sur les conditions matérielles et logicielles requises, y compris les navigateurs pris en charge, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
La présente section explique comment installer Load Balancer sur les systèmes HP-UX à partir du CD-ROM du produit.
Avant de commencer la procédure d'installation, veillez à disposer des droits d'accès de superutilisateur pour installer le logiciel.
Si une version antérieure est déjà installée sur votre système, supprimez-la avant d'installer la nouvelle. Vérifiez d'abord que l'exécuteur et le serveur sont arrêtés. Puis, pour désinstaller Load Balancer, voir Instructions de désinstallation des packages.
Le Tableau 3 répertorie les noms des packages d'installation de Load
Balancer et l'ordre suivant lequel ils doivent être installés à l'aide de
l'outil d'installation des packages du système.
Tableau 3. Détails de l'installation des packages de Load Balancer sous HP-UX
Description du package | Nom du package HP-UX |
Base | ibmlb.base |
Administration et messages | ibmlb.admin ibmlb.nlv-lang |
Licence de Load Balancer | ibmlb.lic |
Composants de Load Balancer | ibmlb.composant |
Documentation | ibmlb.doc |
Serveur de mesures | ibmlb.ms |
Remarques :
|
La procédure ci-après décrit les étapes requises pour effectuer cette tâche.
su - root Mot de passe : motdepasse
swinstall -s /source nom_package
source représentant le chemin d'accès absolu au répertoire du package et nom_package, le nom du package.
Pour installer le package de base de Load Balancer (ibmlb.base) à partir du répertoire racine du CD, exécutez la commande suivante :
swinstall -s /source ibmlb.base
Pour installer tous les packages de Load Balancer, à partir du répertoire racine du CD, exécutez la commande suivante :
swinstall -s /source ibmlb
Exécutez la commande swlist pour répertorier tous les packages installés. Exemple,
swlist -l fileset ibmlb
Utilisez la commande swremove pour désinstaller les packages. Supprimez les packages dans l'ordre inverse de leur installation. Vous pouvez par exemple exécuter les commandes suivantes :
swremove ibmlb
Pour ne désinstaller qu'un package, par exemple le composant Dispatcher :
swremove ibmlb.disp
Pour plus d'informations sur les conditions matérielles et logicielles requises, y compris les navigateurs pris en charge, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
La présente section explique comment installer Load Balancer sur les systèmes Linux à partir du CD-ROM du produit.
Avant de commencer la procédure d'installation, veillez à disposer des droits d'accès de superutilisateur pour installer le logiciel.
Si une version antérieure est déjà installée sur votre système, supprimez-la avant d'installer la nouvelle. Assurez-vous, tout d'abord, que tous les exécuteurs et serveurs sont arrêtés. Puis, pour désinstaller l'intégralité du produit, entrez rpm -e nom_pkg. Procédez à la désinstallation dans l'ordre inverse des procédures du package d'installation, en vous assurant que les packages d'administration sont les derniers à être désinstallés.
Pour installer Load Balancer :
L'image d'installation est un fichier au format eLBLX-version:tar.z.
Voici la liste des packages RPM qui peuvent être installés.
Où --
Le package de la documentation contient uniquement de l'anglais. Les traductions de l'ensemble des documentations Load Balancer se trouvent sur le site Web : www.ibm.com/software/webservers/appserv/ecinfocenter.html.
La commande d'installation des packages doit être émise à partir du répertoire où sont situés les fichiers RPM. Entrez la commande suivante pour installer chaque package: rpm -i package.rpm.
Systèmes Red Hat Linux : Suite à un problème Red Hat Linux connu, vous devez également supprimer les fichiers RPM _db*, sous peine de générer une erreur.
rpm -qa | grep ibmlb
L'installation du produit complet génère une liste semblable à la suivante :
Pour l'administration à distance de Load Balancer, à l'aide de l'invocation RMI (Remote Method Invocation), vous devez installer les modules Administration, Base, Composant et Licence sur le client. Pour plus d'informations sur l'invocation RMI, voir Remote Method Invocation (RMI).
Pour plus d'informations sur les conditions matérielles et logicielles requises, y compris les navigateurs pris en charge, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
La présente section explique comment installer Load Balancer sur les systèmes Solaris à partir du CD-ROM du produit.
Avant de commencer la procédure d'installation, veillez à disposer des droits d'accès de superutilisateur pour installer le logiciel.
Si une version antérieure est déjà installée sur votre système, supprimez-la avant d'installer la nouvelle. Vérifiez d'abord que les exécuteurs et les serveurs sont arrêtés. Puis, pour désinstaller Load Balancer, entrez pkgrm nom_pkg.
Pour installer Load Balancer :
A l'invite, entrez pkgadd -d chemin d'accès où chemin d'accès est le nom d'unité du lecteur de CD-ROM ou le répertoire du disque dur contenant le package ; par exemple, pkgadd -d /cdrom/cdrom0/.
Voici la liste des packages affichés et leur ordre d'installation recommandé.
Le package de la documentation (ibmlbdoc) contient uniquement de l'anglais. Les traductions de l'ensemble des documentations Load Balancer se trouvent sur le site Web : www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Pour installer tous les packages, entrez "all" et appuyez sur la touche Entrée. Pour installer uniquement certains composants, entrez le ou les noms correspondants aux packages à installer séparés par un espace ou par une virgule et appuyez sur la touche Entrée. Vous serez peut-être invité à changer vos droits d'accès à certains répertoires ou fichiers. Il suffit d'appuyer sur le bouton Entrée ou de répondre "yes". Vous devez installer les packages prérequis (car l'installation s'effectue suivant l'ordre alphabétique et non en fonction des éléments prérequis). Si vous indiquez "all" et que vous répondez "yes" à toutes les questions, l'installation se déroule sans incident.
Pour n'installer que le composant Dispatcher, la documentation et le système Metric Server, installez : ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc et ibmlbms.
Pour l'administration à distance de Load Balancer, à l'aide de l'invocation RMI (Remote Method Invocation), vous devez installer les modules Administration, Base, Composant et Licence sur le client. Pour plus d'informations sur l'invocation RMI, voir Remote Method Invocation (RMI).
Les chemins d'installation de Load Balancer sont les suivants :
Pour plus d'informations sur les conditions matérielles et logicielles requises, y compris les navigateurs pris en charge, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
La présente section explique comment installer Load Balancer sur les systèmes Windows à partir du CD-ROM du produit.
Un choix de packages à installer vous est proposé :
Pour l'administration à distance de Load Balancer, à l'aide de l'invocation RMI (Remote Method Invocation), vous devez installer les modules Administration, Licence et Composant sur le client. Pour plus d'informations sur l'invocation RMI, voir Remote Method Invocation (RMI).
Restrictions : La version Windows de Load Balancer ne peut pas être installée sur la même machine qu'IBM Firewall.
Avant de commencer la procédure d'installation, assurez-vous que vous vous êtes connecté en qualité d'administrateur ou d'utilisateur doté de privilèges administratifs.
Si une version antérieure est déjà installée sur votre système, supprimez-la avant d'installer la nouvelle. Pour effectuer une désinstallation en utilisant la fonction Ajouter/Supprimer un programme, procédez comme suit :
Pour installer Load Balancer :
E:\setup
Les chemins d'installation de Load Balancer sont les suivants :
Mise à jour Vous pouvez obtenir le groupe de correctifs Edge Components pour AIX, HP-UX, Linux, Solaris ou Microsoft Windows par le biais de :
Pour plus d'informations sur les systèmes d'exploitation pris en charge, accédez au site de support IBM et consultez Configuration requise pour WebSphere Application Server.
Le lien vers les groupes de mises à jour ou de correctifs Edge Components est accesible à la section Téléchargements recommandés pour WebSphere Application Server du site de support IBM.
Avant d'installer le groupe de mises à jour ou de correctifs, arrêtez et désinstallez toutes les versions existantes de Load Balancer antérieures à la version vers laquelle vous effectuez la mise à niveau.
dscontrol executor stop
L'exécuteur Load Balancer peut toujours s'exécuter, même si dsserver est arrêté. Si vous recevez un message indiquant que dsserver ne fonctionne pas, démarrez dsserver et exécutez à nouveau la commande.
dsserver stop
Tableau 4. Commandes spécifiques au système pour désinstaller Load Balancer
Commandes spécifiques au système pour désinstaller Load Balancer | |
---|---|
Plateforme | Commandes |
AIX | Désinstallez tous les packages de Load Balancer à l'aide de la
commande :
installp -u ibmlb |
HP-UX | Désinstallez tous les packages de Load Balancer à l'aide de la
commande :
swremove ibmlb |
Linux |
|
Solaris |
|
Si Load Balancer n'est pas installé, vous devez uniquement installer le fichier de licence de Load Balancer, lb70Full.LIC, avant d'installer un groupe de mises à jour ou de correctifs. Vous pouvez obtenir la licence en installant le module Licence de Load Balancer.
Pour installer un groupe de correctifs ou de mises à jour :
Commandes spécifiques au système pour installer un groupe de mises à jour ou un groupe de correctifs | |
---|---|
Système | Commandes |
AIX |
|
HP-UX |
swinstall -s /source nom_package source représentant le chemin d'accès au répertoire du package et nom_package, le nom du package. Par exemple, pour installer le package de base à partir du répertoire courant, exécutez la commande suivante : swinstall -s /lb ibmlb.base |
Linux |
rpm -iv nom_package où nom_package est le nom du package. Par exemple, la commande suivante permet d'installer tous les packages de Load Balancer lorsqu'ils se trouvent dans le répertoire courant : rpm -iv ibmlb*.rpm
|
Solaris |
pkgadd -d chemin d'accès nom_package chemin d'accès représentant le chemin d'accès au répertoire du package et nom_package, le nom du package. Par exemple, pour installer le package d'administration à partir du répertoire courant, exécutez la commande suivante : pkgadd -d . ibmlbadm |
Ce tableau répertorie tous les packages fournis avec Edge Components et l'ordre suivant lequel ils doivent être installés. Installez les packages inclus dans le groupe de mises à jour ou de correctifs selon l'ordre spécifié dans le tableau suivant.
Liste des packages | |
Composants installés | Mettre à jour les packages (répertoriés de manière générique) dans cet ordre |
|
|
Documentation de Edge Components | doc-lang |
Utilisez le programme d'installation de Edge Components pour la mise à niveau suivante
Pour la plupart des composants, lorsque le groupe de mises à jour ou de correctifs est supprimé, les fichiers de configuration sont enregistrés dans le répertoire anciens fichiers/composant. Vous pouvez utiliser ces fichiers de configuration avec la version réinstallée du produit afin de conserver la configuration corrigée dans la version pré-corrigée. Pour le composant Load Balancer, vous devez enregistrer manuellement les fichiers de configuration pour conserver la configuration corrigée.
Cette section contient des informations pour la configuration d'un démarrage rapide ainsi que des remarques relatives à la planification, et présente les diverses méthodes de configuration du composant Dispatcher de Load Balancer. Elle se compose des chapitres suivants :
Cet exemple de démarrage rapide indique comment configurer trois postes de travail connectés en local avec la méthode d'acheminement mac de Dispatcher pour équilibrer la charge du trafic Web entre deux serveurs Web. Cette configuration est également valable pour l'équilibrage de tout autre trafic d'applications TCP ou UDP sans état.
Figure 8. Configuration Dispatcher locale simple
La méthode d'acheminement mac est la méthode d'acheminement par défaut avec laquelle Dispatcher équilibre la charge des demandes entrantes sur le serveur, ce dernier renvoyant la réponse directement au client. Pour plus d'informations sur la méthode d'acheminement MAC de Dispatcher, voir Réacheminement MAC de Dispatcher (méthode d'acheminement mac).
Pour l'exemple à démarrage rapide, vous devez disposer de trois postes de travail et de quatre adresses IP. Un poste de travail est la répartiteur ; les deux autres postes sont les serveurs Web. Chaque serveur Web requiert une adresse IP. Le poste de travail Dispatcher requiert deux adresses : l'adresse de non-acheminement (adresse NFA) et l'adresse du cluster (adresse dont la charge est équilibrée), que vous fournissez aux clients pour accéder à votre site Web.
Poste de travail | Nom | Adresse IP |
---|---|---|
1 | server1.Intersplashx.com | 9.47.47.101 |
2 | server2.Intersplashx.com | 9.47.47.102 |
3 | server3.Intersplashx.com | 9.47.47.103 |
Masque réseau = 255.255.255.0 |
Chaque poste de travail ne contient qu'une carte d'interface réseau Ethernet standard.
Name= www.Intersplashx.com IP=9.47.47.104
Ajoutez un alias pour www.Intersplashx.com à l'interface de bouclage de server2.Intersplashx.com et server3.Intersplashx.com.
ifconfig lo0 alias www.Intersplashx.com netmask 255.255.255.255
ifconfig lo0:1 plumb www.Intersplashx.com netmask 255.255.255.0 up
Vous venez de terminer les étapes de configuration requises pour les deux serveurs Web.
A l'aide de Dispatcher, vous pouvez créer une configuration à l'aide de l'invite de commande, de l'assistant de configuration ou de l'interface graphique.
Si vous utilisez l'invite de commande, suivez la procédure ci-dessous.
dscontrol executor start
dscontrol cluster add www.Intersplashx.com
dscontrol port add www.Intersplashx.com:80
dscontrol server add www.Intersplashx.com:80:server2.Intersplashx.com
dscontrol server add www.Intersplashx.com:80:server3.Intersplashx.com
dscontrol executor configure www.Intersplashx.com
dscontrol manager start
Dispatcher procède maintenant à l'équilibrage de charge en fonction des performances des serveurs.
dscontrol advisor start http 80
Dispatcher vérifie désormais que les demandes des clients ne sont pas envoyées vers un serveur Web arrêté.
La configuration de base comportant des serveurs liés en local est maintenant terminée.
Vérifiez que la configuration fonctionne :
Pour plus d'informations sur l'utilisation de l'interface graphique, voir Interface graphique et Annexe A, Interface graphique utilisateur : Instructions générales.
Pour plus d'informations sur l'utilisation de l'assistant de configuration, voir Configuration à l'aide de l'assistant de configuration.
Il y a plusieurs manières de configurer Load Balancer pour assurer le support de votre site. Si votre site ne comprend qu'un seul nom de système hôte auquel tous vos clients se connectent, vous pouvez ne définir qu'un seul cluster de serveurs. Pour chaque serveur, configurez un port par l'intermédiaire duquel Load Balancer communique. Voir la Figure 9.
Figure 9. Exemple de composant Dispatcher configuré avec un cluster et 2 ports
Dans cet exemple de composant Dispatcher, un cluster est défini sur www.productworks.com. Il dispose de deux ports : le port 80 pour HTTP et le port 443 pour SSL. Un client adressant une requête à l'adresse http://www.productworks.com (port 80) accède à un autre serveur qu'un client s'adressant à https://www.productworks.com (port 443).
Si le site est très étendu et qu'il comporte un grand nombre de serveurs, chacun étant dédié à un protocole en particulier, une autre méthode de configuration de Load Balancer sera peut-être préférable. Dans ce cas, vous pouvez définir un cluster pour chaque protocole, avec un seul port mais plusieurs serveurs, comme illustré par la Figure 10.
Dans cet exemple de composant Dispatcher, deux clusters sont définis : www.productworks.com pour le port 80 (HTTP) et www.testworks.com pour le port 443 (SSL).
Une troisième configuration de Load Balancer pourra s'avérer nécessaire si votre site abrite plusieurs sociétés ou services, chacun accédant à votre site par une adresse URL distincte. Dans ce cas, vous pouvez définir un cluster pour chaque société ou service ainsi qu'un nombre de ports variable pour réceptionner les connexions de cette adresse URL, comme illustré par la Figure 11.
Figure 11. Exemple de composant Dispatcher configuré avec 2 clusters, chacun étant associé à 2 ports
Dans cet exemple de composant Dispatcher, deux clusters sont définis avec le port 80 pour HTTP et le port 23 pour Telnet pour chacun des sites www.productworks.com et www.testworks.com.
Le présent chapitre décrit les aspects que l'administrateur de réseau doit prendre en compte avant d'installer et de configurer le composant Dispatcher.
Le présent chapitre se compose des sections suivantes :
Dispatcher se compose des fonctions suivantes :
L'utilisation du gestionnaire n'est que facultative. Toutefois, s'il n'est pas utilisé, l'équilibrage de charge se fait sur la base d'une planification circulaire pondérée, elle-même basée sur les mesures de charge des serveurs et les conseillers ne sont pas disponibles.
Dispatcher fournit également des conseillers qui n'échangent pas d'informations relatives aux protocoles, tels que le conseiller DB2(R) qui indique l'état des serveurs DB2 et le conseiller ping qui indique si le serveur répond à une commande ping. Pour obtenir une liste des conseillers, voir Liste des conseillers.
Vous avez également la possibilité de développer vos propres conseillers (voir Création de conseillers personnalisés).
L'utilisation des conseillers est facultative mais recommandée.
Les trois fonctions clés de Dispatcher (l'exécuteur, le gestionnaire et les conseillers) agissent en collaboration pour équilibrer et répartir entre les serveurs les requêtes réceptionnées. Outre la gestion des requêtes d'équilibrage de charge, l'exécuteur contrôle le nombre de nouvelles connexions, de connexions actives et de connexions terminées. Il assure également le retrait des connexions terminées ou réinitialisées et transmet ces informations au gestionnaire.
Le gestionnaire recueille les informations transmises par l'exécuteur, les conseillers et par tout programme de contrôle tel que Metric Server. Sur la base de ces informations, le gestionnaire ajuste les capacités des machines serveurs, pour chaque port, et transmet ces données à l'exécuteur qui en tient compte pour l'équilibrage de charge des nouvelles connexions.
Les conseillers contrôlent chaque serveur relié au port dont ils ont la charge afin de déterminer leur temps de réponse et leur disponibilité, puis renvoient ces informations au gestionnaire. Les conseillers détectent également si un serveur est opérationnel ou non. Sans la contribution du gestionnaire et des conseillers, l'exécuteur assure une planification circulaire basée sur les capacités courantes des serveurs.
Avec Dispatcher, vous pouvez choisir l'une des trois méthodes d'acheminement spécifiées au niveau du port : acheminement MAC, acheminement NAT/NAPT ou acheminement CBR (routage par contenu).
La méthode d'acheminement MAC de Dispatcher (qui est la méthode d'acheminement par défaut) permet d'équilibrer la charge de la demande entrante sur le serveur sélectionné et de faire en sorte que le serveur renvoie une réponse directement au client sans impliquer le composant Dispatcher. Ainsi, Dispatcher se contente de surveiller les flux entrants du client vers le serveur. Il n'effectue aucun contrôle des transmissions en sortie, du serveur vers le client. Cet aspect réduit sensiblement son impact sur les performances des applications et permet même d'accroître celles du réseau.
La méthode d'acheminement peut être sélectionnée lors de l'ajout d'un port à l'aide de la commande dscontrol port add cluster:port method valeur. La valeur de la méthode d'acheminement par défaut est mac. Vous ne pouvez spécifier le paramètre method que lorsque le port est ajouté. Une fois le port ajouté, vous ne pouvez pas modifier les paramètres de la méthode d'acheminement. Pour plus d'informations, voir dscontrol port -- Configuration des ports.
Restriction sous Linux : les systèmes Linux emploient un modèle fondé sur l'hôte pour afficher les adresses matérielles sous la forme d'adresses IP à l'aide du protocole ARP. Ce modèle n'est pas compatible avec les conditions requises par le serveur d'arrière-plan ou le serveur co-implanté à haute disponibilité pour la prise en charge de la méthode d'acheminement MAC de Load Balancer. Pour modifier le comportement du système Linux afin de le rendre compatible avec l'acheminement MAC de Load Balancer, voir les solutions présentées dans Solutions alternatives pour l'affectation d'alias à l'unité de bouclage sous Linux lors de l'utilisation de la méthode d'acheminement MAC de Load Balancer.
Restriction sous Linux lors de l'utilisation de serveurs zSeries ou S/390 : il existe des limitations lorsque vous utilisez des serveurs zSeries ou S/390 dotés de cartes OSA (Open System Adapter). Voir Incident : Sous Linux, la configuration de Dispatcher est limitée lorsque vous utilisez des serveurs zSeries ou S/390 dotés de cartes OSA (Open System Adapter) pour obtenir des solutions alternatives.
Si vous utilisez NAT ou NAPT, il n'est pas nécessaire que les serveurs d'équilibrage de charge se trouvent sur un réseau local. Si vous préférez disposer de serveurs à distance, utilisez la méthode d'acheminement NAT plutôt que la technique d'encapsulation GRE/WAN. Vous pouvez également utiliser la fonction NAPT pour accéder à plusieurs démons de serveur situés sur chaque machine serveur faisant l'objet d'un équilibrage de charge, où chaque démon écoute sur un port unique.
Vous pouvez configurer un serveur à plusieurs démons de deux façons différentes.
L'application fonctionne bien avec des protocoles de niveau supérieur tels que HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, etc.
Restrictions :
Vous avez besoin de trois adresses IP pour la machine Dispatcher : l'adresse nfa, l'adresse de cluster et l'adresse de retour. Pour implémenter NAT/NAPT, procédez comme suit (voir également Etapes de configuration des méthodes d'acheminement nat ou cbr de Dispatcher) :
dscontrol server add cluster:port:serveur mapport valeur returnaddress adresseretour router adresseretour
Mappe le numéro du port de destination de la demande client (pour Dispatcher) au numéro de port du serveur que Dispatcher utilise pour équilibrer la charge de la demande du client. Mapport permet à Load Balancer de recevoir une demande de client sur un port et de la transmettre à un autre port sur la machine serveur. Le paramètre mapport permet d'équilibrer la charge des demandes d'un client sur une machine serveur sur laquelle peuvent s'exécuter plusieurs démons serveur. La valeur par défaut du paramètre mapport est le numéro de port de destination de la demande du client.
L'adresse retour correspond à une adresse ou à un nom d'hôte unique que vous configurez sur la répartiteur. Dispatcher utilise l'adresse de retour comme adresse source lors de l'équilibrage de charge de la demande du client sur le serveur. Elle permet de garantir que le serveur renvoie le paquet à la répartiteur, au lieu de l'envoyer directement au client. (Dispatcher transmettra ensuite le paquet IP au client.) Vous devez indiquer la valeur d'adresse de retour lors de l'ajout du serveur. Vous ne pouvez pas modifier l'adresse de retour sauf si vous supprimez le serveur et que vous l'ajoutez à nouveau. Elle ne peut pas non plus être identique à l'adresse de cluster, de serveur ou NFA.
Lorsque vous utilisez les méthodes d'acheminement nat ou cbr, vous devez définir une adresse de retour permettant la communication entre Load Balancer et les serveurs d'arrière-plan. Le nombre de connexions que Load Balancer peut maintenir avec le serveur d'arrière-plan est limité par le nombre d'adresses de retour définies. Load Balancer utilise des ports basés uniquement sur les adresses de retour et non pas sur la combinaison adresse de retour et serveur. Les connexions supplémentaires échouent, lorsque tous les ports disponibles sont occupés. Dans un environnement occupé, utilisez plusieurs adresses de retour afin d'éviter le problème de disponibilité des ports.
Adresse du routeur vers le serveur distant. S'il s'agit d'un serveur rattaché en local, entrez son adresse, sauf s'il réside sur la même machine que Load Balancer. Dans ce cas, continuez à utiliser l'adresse réelle du routeur.
Le composant Dispatcher permet d'exécuter la fonction de routage cbr pour HTTP (avec la règle de type de contenu) et HTTPS (avec l'affinité des ID de session SSL) sans Caching Proxy. Pour le trafic HTTP et HTTPS, la méthode d'acheminement cbr du composant Dispatcher peut fournir une fonction de routage cbr plus rapide que le composant CBR, qui nécessite le module Caching Proxy.
Pour HTTP : La sélection du serveur, pour la fonction de routage cbr de Dispatcher, est effectuée sur la base du contenu d'une adresse URL ou d'un en-tête HTTP. Cette option est configurée à l'aide du type de règle "Contenu". Lors de la configuration de la règle de contenu, spécifiez la chaîne de recherche "pattern" et un ensemble de serveurs pour la règle. Lors du traitement d'une nouvelle demande entrante, cette règle compare la chaîne indiquée à l'URL du client ou à l'en-tête HTTP spécifié dans la demande du client.
Si Dispatcher trouve la chaîne dans la demande du client, il transmet la demande à l'un des serveurs de la règle. Dispatcher achemine ensuite les données de la réponse du serveur vers le client (méthode d'acheminement cbr).
Si Dispatcher ne trouve pas la chaîne dans la demande du client, il ne sélectionne pas de serveur dans l'ensemble de serveurs de la règle.
Pour HTTPS (SSL) : L'acheminement CBR (content-based routing) de Dispatcher basée sur la zone de session SSL ID de la demande client. Avec SSL, une demande client contient l'ID session SSL d'une session antérieure, et les serveurs gèrent une cache de leurs connexions SSL précédentes. L'affinité de l'ID de session SSL de Dispatcher permet au client et au serveur d'établir une nouvelle connexion à l'aide des paramètres de sécurité de la connexion précédente au serveur. En éliminant la renégociation des paramètres de sécurité SSL, comme les clés partagées et les algorithmes de chiffrement, les serveurs sauvegardent des cycles CPU et le client obtient une réponse plus rapidement. Pour activer l'affinité de l'ID de session SSL : le type de protocole indiqué pour le port doit être SSL et le délai de maintien de routage du port doit être associé à une valeur autre que zéro. Si le délai de maintien de routage est dépassé, le client peut être envoyé à un autre serveur.
Vous avez besoin de trois adresses IP pour la machine Dispatcher : l'adresse nfa, l'adresse de cluster et l'adresse de retour. Pour implémenter la fonction de routage cbr de Dispatcher (voir également Etapes de configuration des méthodes d'acheminement nat ou cbr de Dispatcher) :
dscontrol server add cluster:port:serveur mapport valeur returnaddress adresseretour router adresseretour
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern masque
où masque indique le masque à utiliser pour une règle de type de contenu. Pour plus d'informations sur le type de règle de contenu, voir Utilisation de règles basées sur le contenu des demandes. Pour plus d'informations sur les expressions valides de masque, voir l'Annexe B, Syntaxe des règles de contenu (modèle).
Figure 12. Exemple d'utilisation des méthodes d'acheminement nat ou cbr de Dispatcher
Vous avez besoin d'au moins trois adresses IP pour la machine Dispatcher. Pour la Figure 12, les étapes minimales de configuration des méthodes nat ou cbr de Dispatcher sont les suivantes :
1. Démarrage de l'exécuteur dscontrol executor start 2. Définition de la passerelle client dscontrol executor set clientgateway 1.2.3.5 REMARQUE : si votre sous-réseau ne dispose pas de routeur local, vous devez configurer une machine pour l'acheminement des adresses IP et l'utiliser comme passerelle client. Reportez-vous à la documentation de votre système d'exploitation pour déterminer la manière d'activer l'acheminement des adresses IP. 3. Définition de l'adresse de cluster dscontrol cluster add 1.2.3.44 4. Configuration de l'adresse de cluster dscontrol executor configure 1.2.3.44 5. Définition du port avec une méthode nat ou cbr dscontrol port add 1.2.3.44:80 method nat ou dscontrol port add 1.2.3.44:80 method cbr protocol http 6. Configuration d'une adresse de retour alias sur Load Balancer (à l'aide de la carte ethernet 0) REMARQUE : Sur les systèmes Linux, vous n'avez pas besoin de créer un alias pour l'adresse de retour si vous utilisez la méthode de transfert nat sur une machine co-implantée. dscontrol executor configure 10.10.10.99 ou utilisez la commande ifconfig (pour Linux ou UNIX uniquement) : sous AIX : ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0 HP-UX : ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up sous Linux : ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up Solaris : ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up 7. Définition des serveurs d'arrière-plan dscontrol server add 1.2.3.4:80:192.10.10.10 router 10.10.10.6 returnaddress 10.10.10.99
La passerelle client (1.2.3.5) correspond à l'adresse du routeur 1 entre Load Balancer et le client. Le routeur (10.10.10.6) correspond à l'adresse du routeur 2 entre Load Balancer et le serveur d'arrière-plan. Si vous n'êtes pas sûr de l'adresse de la passerelle client ou du routeur 2, vous pouvez utiliser un programme traceroute avec l'adresse du client (ou du serveur) pour déterminer l'adresse du routeur. La syntaxe d'appel de ce programme varie en fonction du système d'exploitation utilisé. Pour plus d'informations sur ce programme, consultez la documentation afférente à votre programme d'exploitation.
Si le serveur se trouve sur le même sous-réseau que Load Balancer (c'est-à-dire si traceroute ne désigne aucun routeur), entrez l'adresse du serveur comme adresse de routeur. Cependant, si le serveur réside sur la même machine que Load Balancer, entrez plutôt l'adresse du routeur que celle du serveur. L'adresse du routeur est celle utilisée dans la commande "server add", sur la machine Load Balancer, à l'étape 7.
Avec le partitionnement du serveur, vous pouvez effectuer une distinction plus avancée entre des URL particulières et leurs applications spécifiques. Par exemple, un serveur Web permet de gérer des pages JSP, des pages HTML, des fichiers GIF, des requêtes de base de données, etc. Load Balancer permet maintenant de partitionner un cluster et un serveur spécifiques d'un port en plusieurs serveurs logiques. Ainsi, vous pouvez appliquer le conseiller sur un service particulier de la machine afin de détecter si un moteur de servlet ou une demande de base de données s'exécute très rapidement ou s'il ne s'exécute pas du tout.
Le partitionnement de serveur permet à Load Balancer de détecter, par exemple, que le service HTML traite les pages rapidement mais que la connexion à la base de données à été interrompue. Ainsi vous pouvez distribuer la charge en fonction de la charge de travail de chaque service plus granulaire et non en fonction uniquement de la pondération serveur.
Le partitionnement de serveur peut se révéler utile s'il est associé aux conseillers HTTP et HTTPS. Par exemple, lorsque vous disposez d'un serveur HTML qui gère des pages HTML, GIF et JSP, si vous définissez le serveur (par ajout) une seule fois sur le port 80, vous ne recevez qu'une valeur de charge pour la totalité du serveur HTTP. Ceci peut vous induire en erreur car il est possible que le service GIF ne fonctionne pas sur le serveur. Dispatcher continue d'acheminer les pages GIF vers le serveur, mais le client n'obtient qu'un message de dépassement de délai ou d'erreur.
Si vous définissez le serveur trois fois (par exemple, ServerHTML, ServerGIF et ServerJSP) sur le port et que vous définissez le paramètre advisorrequest du serveur avec une chaîne différente pour chaque serveur logique, vous pouvez demander des informations concernant l'état d'un service particulier sur le serveur. ServerHTML, ServerGIF et ServerJSP correspondent à trois serveurs logiques partitionnés à partir d'un serveur physique. Pour ServerJSP, vous pouvez définir la chaîne advisorrequest afin d'interroger le service sur la machine qui gère les pages JSP. Pour ServerGIF, vous pouvez définir la chaîne advisorrequest afin d'interroger le service GIF. Pour ServerHTML, vous pouvez définir la chaîne advisorrequest afin d'interroger le service HTML. Ainsi, lorsque le client n'obtient pas de réponse de l'interrogation advisorrequest du service GIF, Dispatcher marque ce serveur logique (ServerGIF) comme inactif tandis que les deux autres serveurs logiques peuvent parfaitement fonctionner. Dispatcher n'achemine plus de pages GIF vers le serveur physique, mais peut encore envoyer des requêtes JSP et HTML au serveur.
Pour plus d'informations sur le paramètre advisorrequest, voir Configuration du conseiller HTTP ou HTTPS à l'aide de l'option de requête ou de réponse (URL).
Dans la configuration de Dispatcher, vous pouvez représenter un serveur physique ou un serveur logique à l'aide de la hiérarchie cluster:port:serveur. Le serveur peut être une adresse IP unique de la machine (serveur physique) sous la forme d'un nom symbolique ou d'une adresse IP. Ou, si vous définissez le serveur afin qu'il représente un serveur partitionné, vous devez alors fournir une adresse de serveur pouvant être résolue pour le serveur physique dans le paramètre address de la commande dscontrol server add. Pour plus d'informations, voir dscontrol server -- Configuration des serveurs.
Voici un exemple de partitionnement de serveurs physiques en serveurs logiques afin de gérer différents types de demandes.
Cluster: 1.1.1.1 Port: 80 Server: A (IP address 1.1.1.2) HTML server Server: B (IP address 1.1.1.2) GIF server Server: C (IP address 1.1.1.3) HTML server Server: D (IP address 1.1.1.3) JSP server Server: E (IP address 1.1.1.4) GIF server Server: F (IP address 1.1.1.4) JSP server Rule1: /*.htm Server: A Server: C Rule2: /*.jsp Server: D Server: F Rule3: /*.gif Server: B Server: E
Dans cet exemple, le serveur 1.1.1.2 est divisé en deux serveurs logiques : "A" (gérant les demandes HTML) et "B" (gérant les demandes GIF). Le serveur 1.1.1.3 est divisé en deux serveurs logiques : "C" (gérant les demandes HTML) et "D" (gérant les demandes JSP). Le serveur 1.1.1.4 est partitionné en deux serveurs logiques : "E" (gérant les demandes GIF) et "F" (gérant les demandes JSP).
Figure 13. Exemple de Dispatcher utilisant la haute disponibilité
La fonctionnalité de haute disponibilité requiert une deuxième machine. La première se charge de l'équilibrage de charge pour la totalité du trafic client, comme dans une configuration à une seule machine. La seconde machine Dispatcher surveille le bon fonctionnement de la première et reprend l'équilibrage de charge si elle détecte un échec de la première machine.
Chacune des deux machines se voit affecter un rôle spécifique, principal ou de sauvegarde. La machine principale envoie régulièrement les données de connexion à la machine de secours. Pendant que la machine principale est active (équilibrage de charge), la machine de sauvegarde est en état d'attente et ses données s'actualisent en permanence, ce qui lui permet de prendre le relais des opérations en cas de besoin.
Les sessions de communication entre les deux machines sont désignées par le terme signal de présence. Ces signaux permettent à chaque machine de contrôler l'état de l'autre.
Si la machine de sauvegarde détecte que la machine principale est défaillante, elle prend en charge l'équilibrage de charge. A cette étape, les états respectifs des deux machines s'inversent : la machine de secours devient active et la machine principale passe en attente.
Dans la configuration à haute disponibilité, les deux machines doivent se trouver sur le même sous-réseau et leur configuration doit être identique.
Pour plus d'informations sur la configuration de la haute disponibilité, voir Haute disponibilité.
Figure 14. Exemple de Dispatcher utilisant la haute disponibilité réciproque
La fonctionnalité à haute disponibilité réciproque implique l'utilisation de deux machines. Les deux machines effectuent l'équilibrage de la charge du trafic client de manière active et assurent réciproquement la sauvegarde l'une de l'autre. Dans une configuration à haute disponibilité, une seule machine effectue l'équilibrage de charge. Dans une configuration à haute disponibilité réciproque, les deux machines assument l'équilibrage de charge d'une partie du trafic du client.
Pour la haute disponibilité réciproque, le trafic client est affecté à chaque machine sur la base d'une adresse de cluster. Chaque cluster peut être configuré avec l'adresse de non-acheminement (NFA) de sa machine principale. La machine du Dispatcher principal effectue normalement l'équilibrage de charge pour ce cluster. En cas de panne, l'autre machine assume l'équilibrage de charge pour son propre cluster et pour celui du Dispatcher qui est en panne.
La Figure 14 illustre une configuration de haute disponibilité réciproque avec "cluster partagé A" et "cluster partagé B". Chaque répartiteur peut acheminer activement des paquets pour son cluster principal. Si l'un des répartiteurs venait à échouer et ne pouvait plus activement acheminer les paquets pour son cluster principal, l'autre répartiteur pourrait le remplacer et acheminerait les paquets pour son cluster de sauvegarde.
Pour plus d'informations sur la configuration de la haute disponibilité et de la haute disponibilité réciproque, voir Haute disponibilité.
Avant d'effectuer les opérations décrites dans le présent chapitre, voir Planification de Dispatcher. Ce chapitre explique comment créer une configuration de base pour le composant Dispatcher de Load Balancer.
Avant de suivre les étapes de configuration détaillées dans ce tableau, assurez-vous que la
machine Dispatcher et toutes les machines serveurs sont connectées au réseau, ont des
adresses IP valides et peuvent communiquer entre elles par ping.
Tableau 7. Tâches de configuration pour la fonction Dispatcher
Tâche | Description | Informations connexes |
---|---|---|
Configuration de la machine Dispatcher. |
Définition de la configuration de l'équilibrage de charge.
| Configuration de la machine Dispatcher |
Configuration des machines en vue de l'équilibrage de charge. | Affectation d'un alias à l'unité de bouclage, recherche et suppression de la route supplémentaire | Configuration des serveurs pour l'équilibrage de la charge |
Quatre méthodes permettent une configuration de base de Dispatcher :
C'est la méthode de configuration de Dispatcher la plus directe. Les valeurs des paramètres de commandes doivent être saisies à l'aide de caractères anglais. Les seules exceptions s'appliquent aux noms d'hôte (utilisés dans les commandes cluster, server et highavailability) et aux noms de fichiers (utilisés dans les commandes file).
Pour démarrer Dispatcher à partir de la ligne de commande, procédez comme suit :
Vous pouvez utiliser une version abrégée des paramètres de la commande dscontrol en entrant simplement la ou les quelques lettres d'identification des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, vous pouvez entrer dscontrol he f au lieu de dscontrol help file.
Pour démarrer l'interface de ligne de commande, entrez dscontrol pour ouvrir une invite dscontrol.
Pour fermer l'interface de ligne de commande, entrez exit ou quit.
Vous pouvez entrer les commandes de configuration Dispatcher dans un fichier script de configuration pour les exécuter simultanément. Voir Exemples de fichiers de configuration Load Balancer.
dscontrol file appendload mon_script
dscontrol file newload mon_script
Pour sauvegarder la configuration en cours dans un fichier script (par exemple, savescript), exécutez la commande suivante :
dscontrol file save savescript
Cette commande enregistre le fichier script de configuration dans le répertoire ...ibm/edge/lb/servers/configurations/dispatcher.
Pour des instructions générales et un exemple de l'interface graphique, voir Figure 41.
Pour démarrer l'interface graphique, procédez comme suit :
dsserver
Pour configurer le composant Dispatcher à partir de l'interface graphique, vous devez d'abord sélectionner Dispatcher dans l'arborescence. Vous pouvez lancer l'exécuteur et le gestionnaire une fois que vous vous êtes connecté à un hôte. Vous pouvez également créer des clusters contenant des ports et des serveurs, puis lancer des conseillers pour le gestionnaire.
Vous pouvez utiliser l'interface graphique pour toute opération normalement exécutée par la commande dscontrol. Par exemple, pour définir un cluster à l'aide de la ligne de commande, entrez la commande dscontrol cluster add cluster. Pour définir un cluster à partir de l'interface graphique, cliquez sur Exécuteur à l'aide du bouton droit de la souris, puis dans le menu en incrustation qui apparaît, cliquez sur le bouton Ajout d'un cluster à l'aide du bouton gauche de la souris. Entrez l'adresse du cluster dans la fenêtre en incrustation, puis cliquez sur OK.
Les fichiers de configuration Dispatcher existants peuvent être chargés à l'aide des options Chargement de la nouvelle configuration (pour remplacer intégralement la configuration en cours) et Ajout à la configuration en cours (pour mettre à jour la configuration en cours) du menu en incrustation Hôte. Vous devez sauvegarder régulièrement votre configuration Dispatcher dans un fichier en utilisant l'option Sauvegarder le fichier de configuration sous... du menu en incrustation Hôte. Le menu Fichier situé en haut de l'interface graphique permet de sauvegarder les connexions à l'hôte en cours dans un fichier ou de restaurer les connexions dans des fichiers existants sur tous les composants Load Balancer.
Les commandes de configuration peuvent également être exécutées à distance. Pour plus d'informations, voir Remote Method Invocation (RMI).
Pour exécuter une commande à partir de l'interface graphique : mettez le noeud Hôte en surbrillance dans l'arborescence de l'interface graphique, puis sélectionnez Envoyer la commande... dans le menu en incrustation Hôte. Dans la zone d'entrée de commande, exécutez la commande à exécuter, par exemple executor report. Les résultats et l'historique des commandes sont exécutés lors de la session courante et s'affichent dans la fenêtre ouverte.
Vous pouvez accéder à l'Aide en cliquant sur le point d'interrogation situé dans l'angle supérieur droit de la fenêtre Load Balancer.
Pour plus d'informations sur l'utilisation de l'interface graphique, voir l'Annexe A, Interface graphique utilisateur : Instructions générales.
Si vous utilisez l'assistant de configuration, suivez la procédure ci-dessous.
dsserver
Cet assistant vous guide dans les étapes requises pour la création d'une configuration de base pour le composant Dispatcher. Vous devez répondre à quelques questions concernant votre réseau. Vous serez guidé dans la configuration d'un cluster pour permettre à Dispatcher d'équilibrer le trafic dans un groupe de serveurs.
La configuration de la machine Dispatcher ne peut être effectuée que par le superutilisateur (pour les systèmes AIX, HP-UX, Linux ou Solaris) ou l'administrateur (pour les systèmes Windows).
Sur toutes les plateformes prises en charge, Load Balancer peut avoir un serveur co-implanté. La co-implantation implique que Load Balancer peut être implanté physiquement sur le serveur dont il assure l'équilibrage de charge.
Pour la machine Dispatcher, lorsque vous utilisez la méthode d'acheminement mac, vous avez besoin d'au moins deux adresses IP valides. Pour la méthode d'acheminement cbr ou nat, vous avez besoin d'au moins trois adresses IP valides :
Cette adresse constitue l'adresse IP principale de la machine Dispatcher et est appelée l'adresse de non-réacheminement (NFA). Il s'agit par défaut de l'adresse renvoyée par la commande hostname. Utilisez cette adresse pour vous connecter à la machine en vue de tâches administratives, telles que la configuration à distance avec Telnet ou l'accès au sous-agent SNMP. Si la machine Dispatcher peut déjà renvoyer des demandes vers d'autres machines du réseau (par la technique de la triangulation ping), il n'y rien de plus à faire pour définir l'adresse de non-réacheminement.
Une adresse de cluster est une adresse associée à un nom de système hôte (par exemple www.société_X.com). Cette adresse IP est utilisée par un client pour se connecter aux serveurs du cluster en question. Dispatcher assure l'équilibrage de charge pour cette adresse.
Dispatcher utilise l'adresse de retour comme adresse source lors de l'équilibrage de charge de la demande du client sur le serveur. Elle permet de garantir que le serveur renvoie le paquet à la répartiteur, au lieu de l'envoyer directement au client. (Dispatcher transmettra ensuite le paquet IP au client.) Vous devez indiquer la valeur d'adresse de retour lors de l'ajout du serveur. Vous ne pouvez pas modifier l'adresse de retour sauf si vous supprimez le serveur et que vous l'ajoutez à nouveau.
Le nombre de connexions que Load Balancer peut maintenir avec le serveur d'arrière-plan est limité par le nombre d'adresses de retour définies. Load Balancer utilise des ports basés uniquement sur les adresses de retour et non pas sur la combinaison adresse de retour et serveur. Les connexions supplémentaires échouent, lorsque tous les ports disponibles sont occupés. Dans un environnement occupé, utilisez plusieurs adresses de retour afin d'éviter le problème de disponibilité des ports.
Systèmes Solaris uniquement :
Par exemple, pour modifier le paramètre par défaut, éditez le fichier /opt/ibm/edge/lb/servers/ibmlb.conf comme suit :
Pour prendre en charge plusieurs types de cartes, dupliquez la ligne du fichier ibmlb.conf, puis modifiez chaque ligne en fonction du type de carte dont vous disposez.
Par exemple, pour utiliser deux cartes Ethernet 100 Mbps, le fichier ibmlb.conf doit comporter une seule ligne indiquant l'unité eri.
Pour utiliser une carte Ethernet 10Mbps et une carte Ethernet 100Mbps, le fichier ibmlb.conf doit comporter deux lignes, l'une indiquant l'unité le et l'autre l'unité eri.
ifconfig -a
Si vous obtenez le résultat suivant :
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 9.42.93.208 netmask fffffc00 broadcast 9.42.95.255 ether 0:3:ba:2d:24:45
modifiez le fichier ibmlb.conf comme suit :
eri -1 0 ibmlb
Par exemple, si la configuration des clusters X et Y est annulée pour qu'ils soient utilisés par le composant CBR sur les cartes répertoriées dans le fichier ibmlb.conf, l'annulation est effectuée lors du lancement des commandes dscontrol executor start ou dscontrol executor stop. Ce résultat n'est peut-être pas souhaité. Lorsque les clusters X et Y sont configurés dans le script goAliases, ils sont automatiquement reconfigurés une fois Dispatcher Executor lancé ou arrêté.
Assurez-vous que la transmission Internet n'est pas activée pour le protocole TCP/IP.
La Figure 15 montre un exemple de Dispatcher configuré avec un seul cluster, deux ports et trois serveurs.
Figure 15. Exemple d'adresses IP nécessaires pour la machine Dispatcher
Pour obtenir une aide sur les commandes utilisées lors de cette procédure, voir le Guide des commandes Dispatcher et CBR.
Pour plus d'informations sur le fichier de configuration type, voir Exemples de fichiers de configuration Load Balancer.
Systèmes AIX, HP-UX, Linux ou Solaris : Pour démarrer la fonction serveur, entrez dsserver.
Systèmes Windows : La fonction serveur démarre automatiquement en tant que service.
Pour démarrer la fonction exécuteur, tapez la commande dscontrol executor start. Notez que vous pouvez également modifier divers paramètres de l'exécuteur à cette occasion. Voir le Guide des commandes Dispatcher et CBR.
Utilisez cette adresse pour vous connecter à la machine en vue de tâches administratives, comme l'utilisation de Telnet ou SMTP, par exemple. Par défaut, cette adresse correspond au nom d'hôte.
Pour définir l'adresse de non-réacheminement, exécutez la commande dscontrol executor set nfa adresse_IP ou éditez le fichier de configuration type. adresse_IP peut être le nom symbolique ou l'adresse IP.
Dispatcher équilibrera les demandes envoyées à l'adresse du cluster entre les serveurs configurés sur les ports associés à ce cluster.
Le cluster est soit un nom symbolique, soit l'adresse en notation décimale à point, soit l'adresse spéciale 0.0.0.0 qui définit un cluster générique. Pour définir un cluster, entrez la commande dscontrol cluster add. Pour définir les options de cluster, tapez la commande dscontrol cluster set ou utilisez l'interface graphique pour lancer des commandes. Les clusters génériques peuvent être utilisés pour remplacer plusieurs adresses IP afin de permettre l'équilibrage de charge pour les paquets entrants. Pour plus d'informations, voir Utilisation d'un cluster générique pour combiner les configurations serveurs, Utilisation du cluster générique pour équilibrer la charge des pare-feux et Utilisation d'un cluster générique avec Caching Proxy pour le proxy transparent.
Lorsque le cluster est défini, vous devez normalement configurer son adresse sur l'une des cartes d'interface réseau de la machine Dispatcher. Pour ce faire, émettez la commande dscontrol executor configure adresse_cluster. Cette commande recherche une carte avec une adresse existante et appartenant au même sous-réseau que l'adresse du cluster. La commande de configuration de la carte système est ensuite lancée pour l'adresse du cluster en utilisant la carte trouvée et le masque de réseau de l'adresse existante figurant sur cette carte. Exemple :
dscontrol executor configure 204.67.172.72
Vous pouvez configurer des adresses de clusters ajoutées à un serveur en attente en mode haute disponibilité ou des adresses de clusters ajoutées à un répartiteur de réseau étendu jouant le rôle de serveur distant. Il est également inutile d'exécuter la commande de configuration de l'exécuteur si vous utilisez le modèle de script goIdle, en mode autonome. Pour plus d'informations sur le script goIdle, voir Utilisation de scripts.
Dans de rares cas, vous pouvez avoir une adresse qui ne correspond pas à une adresse de sous-réseau existante. Vous devez alors utiliser l'autre forme de la commande de configuration de l'exécuteur et fournir de manière explicite le nom et le masque de réseau de l'interface. Entrez la commande dscontrol executor configure adresse_cluster nom_interface masque_réseau.
Exemples :
dscontrol executor configure 204.67.172.72 en0 255.255.0.0 (systèmes AIX) dscontrol executor configure 204.67.172.72 eth0:1 255.255.0.0 (systèmes Linux) dscontrol executor configure 204.67.172.72 eri0 255.255.0.0 (systèmes Solaris) dscontrol executor configure 204.67.172.72 en1 255.255.0.0 (systèmes Windows)
Pour vous servir de l'autre forme de la commande de configuration de l'exécuteur sous Windows, vous devez déterminer le nom de l'interface à utiliser. Si votre machine comporte une seule carte Ethernet, l'interface porte le nom en0. Si vous ne disposez que d'une seule carte en anneau à jeton (Token Ring), l'interface porte le nom tr0. Si la machine comporte plusieurs cartes de l'un ou l'autre type, il est nécessaire de déterminer le mappage des cartes. Procédez comme suit :
Le résultat apparaît à l'écran. Pour connaître le nom de l'interface à utiliser pour la configuration Load Balancer, recherchez l'adresse IP de votre machine Load Balancer dans les lignes suivantNumber of NIC records.
L'adresse IP de votre machine Load Balancer apparaît sous la forme : ia->adr_ai. Le nom d'interface associé apparaît sous la forme : ifp->nom_if.
les noms d'interface attribués par la commande executor configure correspondent aux noms d'interface listés dans cette commande.
Après avoir accédé à ces informations de mappage, vous pouvez créer un alias reliant l'interface réseau à l'adresse du cluster.
Sous Linux ou UNIX(R), la commande de configuration de l'exécuteur exécute des commandes ifconfig.
Lorsque vous utilisez des serveurs de liaison qui opèrent une liaison à une liste d'adresses IP ne contenant pas celle du serveur, faites appel à la commande arp publish plutôt qu'à ifconfig pour définir dynamiquement une adresse IP sur la machine Load Balancer. Par exemple :
arp -s <cluster> <adresse MAC Load Balancer> pub
Pour définir un port, exécutez la commande dscontrol port add cluster:port, éditez le fichier de configuration type ou utilisez l'interface graphique. La valeur de cluster peut être le nom symbolique ou l'adresse IP. Port représente le numéro du port utilisé pour ce protocole. A ce stade, vous avez également la possibilité de modifier divers paramètres de ports. Vous devez définir et configurer tous les serveurs pour un port. Voir Guide des commandes Dispatcher et CBR.
Le numéro de port 0 (zéro) est utilisé pour spécifier un port générique. Ce port acceptera le trafic vers un port non défini sur le cluster. Le port générique est utilisé pour configurer des règles et des serveurs pour n'importe quel port. Vous pouvez également utiliser cette fonction en cas de configuration de serveur et de règle identique pour plusieurs ports. Le trafic sur un port peut influencer les décisions d'équilibrage de charge pour le trafic sur les autres ports. Pour plus de détails sur les cas d'utilisation d'un port générique, voir Utilisation du port générique pour acheminer le trafic destiné à un port non configuré.
Pour définir un serveur avec équilibrage de charge, entrez la commande dscontrol server add cluster:port:serveur, éditez le fichier de configuration type ou utilisez l'interface graphique. cluster et serveur peuvent correspondre à des noms symboliques ou à des adresses IP. Port représente le numéro du port utilisé pour ce protocole. Pour effectuer l'équilibrage de charge, vous devez définir plusieurs serveurs sur le port d'un cluster.
Serveurs de liaison : Si le composant Dispatcher équilibre la charge entre des serveurs de liaison, les serveurs doivent être configurés pour effectuer la liaison avec l'adresse du cluster. Etant donné que Dispatcher réachemine les paquets sans modifier l'adresse IP de destination, lorsque ceux-ci arrivent, l'adresse de cluster qu'ils contiennent indique la destination. Si un serveur a été configuré pour être lié à une adresse IP autre que l'adresse de cluster, il ne pourra pas accepter les demandes destinées au cluster.
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.
Colocalisation de plusieurs adresses : Dans une configuration de co-implantation, l'adresse du serveur co-implanté ne doit pas être la même que celle de non-réacheminement (NFA). Vous avez la possibilité d'utiliser une autre adresse si votre machine a été définie avec des adresses IP multiples. En ce qui concerne le composant Dispatcher, le serveur co-implanté doit être défini comme co-implanté via la commande dscontrol server. Pour plus d'informations sur les serveurs co-implantés, voir Utilisation de serveurs implantés au même endroit.
Pour plus d'informations sur la syntaxe de la commande dscontrol server, voir dscontrol server -- Configuration des serveurs.
La fonction gestionnaire permet d'améliorer l'équilibrage de charge. Pour démarrer le gestionnaire, exécutez la commande dscontrol manager start, éditez le fichier de configuration type ou utilisez l'interface graphique.
Les conseillers transmettent au gestionnaire des informations complémentaires sur la capacité à répondre aux demandes des serveurs ayant fait l'objet d'un équilibrage de charge. Chaque conseiller est spécifique à un protocole. Par exemple, tapez la commande suivante pour lancer le conseiller HTTP :
dscontrol advisor start http portPour consulter la liste des conseillers et des ports par défaut, voir le Guide des commandes Dispatcher et CBR. Pour lire la description de chaque conseiller, voir Liste des conseillers.
Si vous démarrez des conseillers, vous pouvez modifier le niveau d'importance donné aux informations des conseillers entrant dans les décisions d'équilibrage de la charge. Pour définir les proportions du cluster, entrez la commande dscontrol cluster set cluster proportions. Pour plus d'informations, voir Proportion de l'importance accordée aux données d'état.
Exécutez ces procédures si l'une des conditions ci-dessous est remplie :
Remarques :
Si vous utilisez la méthode de réacheminement MAC, Dispatcher équilibrera la charge uniquement entre des serveurs qui permettent de configurer l'unité de bouclage avec une adresse IP supplémentaire. C'est pourquoi le serveur d'arrière-plan ne répondra jamais aux demandes ARP (protocole de résolution d'adresses). Suivez les étapes indiquées dans cette section pour configurer les serveurs avec équilibrage de charge.
Pour que les serveurs bénéficiant d'un équilibrage de charge fonctionnent, vous devez définir (ou de préférence affecter un alias à) l'unité de bouclage (souvent appelé lo0) en fonction de l'adresse de cluster. Si vous utilisez la méthode d'acheminement MAC, le composant Dispatcher ne modifie pas l'adresse IP de destination dans le paquet TCP/IP avant de retransmettre ce paquet au serveur TCP. Si l'unité de bouclage est définie, ou se voit affecter l'adresse de cluster comme alias, les serveurs avec équilibrage de charge accepteront les paquets envoyés à cette adresse de cluster.
Si votre système d'exploitation supporte l'attribution d'alias aux interfaces réseau (comme par exemple les systèmes AIX, HP-UX, Linux, Solaris ou Windows), vous devez affecter l'adresse de cluster comme alias à l'unité de bouclage. L'utilisation d'un système d'exploitation prenant en charge les alias à pour avantage de permettre la configuration de serveurs avec équilibrage de charge desservant plusieurs adresses de cluster.
IMPORTANT : Pour les systèmes Linux, voir Solutions alternatives pour l'affectation d'alias à l'unité de bouclage sous Linux lors de l'utilisation de la méthode d'acheminement MAC de Load Balancer.
Si le système d'exploitation de votre serveur ne supporte pas les alias, vous devez définir l'adresse de cluster comme alias pour l'unité de bouclage.
Pour définir l'unité de bouclage ou lui affecter un alias, utilisez la commande requise par votre système d'exploitation comme indiqué dans le Tableau 8.
Tableau 8. Commandes pour l'affectation d'un alias à l'unité de bouclage (lo0) pour Dispatcher
Sur certains systèmes d'exploitation, il se peut qu'une route par défaut ait été créée. Dans ce cas, elle doit être supprimée.
route print
IMPORTANT : Sous Windows 2003, toute route supplémentaire doit être ignorée. En cas d'incidents avec le routage après l'établissement d'alias, supprimez l'alias, puis rajoutez-le à l'aide d'un autre masque de réseau.
netstat -nr
Exemple pour Windows :
Active Routes: Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 9.67.128.1 9.67.133.67 1 9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1 9.67.128.0 255.255.248.0 9.67.133.67 9.67.133.67 1 9.67.133.67 255.255.255.255 127.0.0.1 127.0.0.1 1 9.67.133.158 255.255.255.255 127.0.0.1 127.0.0.1 1 9.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 224.0.0.0 9.67.133.158 9.67.133.158 1 224.0.0.0 224.0.0.0 9.67.133.67 9.67.133.67 1 255.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1
9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1
Vous devez supprimer la route supplémentaire. Pour cela, utilisez la commande correspondant à votre système d'exploitation fournie dans le Tableau 9.
Exemple : Pour supprimer la route supplémentaire comme indiqué pour l'exemple "Routes actives" de l'étape 2, entrez :
route delete 9.0.0.0 9.67.133.158
Tableau 9. Commandes de suppression d'une route supplémentaire pour Dispatcher
A l'aide de l'exemple fourni dans la Figure 15, pour configurer un serveur exécutant AIX, la commande serait :
route delete -net 204.0.0.0 204.67.172.72
Pour vérifier la configuration d'un serveur d'arrière-plan, effectuez les étapes suivantes à partir d'une autre machine du même sous-réseau lorsque Load Balancer n'est pas en cours d'exécution et que le cluster n'est pas configuré :
arp -d cluster
ping cluster
La commande ping doit rester sans réponse. Si une réponse est renvoyée, assurez-vous que vous n'avez pas attribué l'adresse du cluster à l'interface à l'aide de la commande ifconfig. Vérifiez qu'aucune machine n'a une entrée ARP publiée pour l'adresse du cluster.
arp -a
La sortie de la commande doit contenir l'adresse MAC de votre serveur. Emettez la commande :
arp -s cluster adresse_mac_serveur
arp -d cluster
Certaines versions de Linux émettent des réponses ARP pour toute adresse IP configurée sur la machine, quelle que soit l'interface installée. Il choisit également une adresse IP de source ARP pour les requêtes ARP who-has en se basant sur toutes les adresses IP définies sur la machine, quelle que soit l'interface sur laquelle ces adresses sont configurées. L'ensemble du trafic d'un cluster est dirigé indistinctement vers un seul serveur.
Si vous utilisez la méthode d'acheminement MAC de Dispatcher, un mécanisme doit être mis en oeuvre pour s'assurer que le trafic destiné au cluster peut être accepté par les piles des serveurs d'arrière-plan, y compris la machine de secours haute disponibilité co-implantée, lorsque la haute disponibilité et la co-implantation sont utilisées conjointement.
Dans la plupart des cas, vous devez affecter l'adresse du cluster en tant qu'alias à l'unité de bouclage. Pour les serveurs d'arrière-plan, le cluster doit être associé à un alias sur l'unité de bouclage. Si vous utilisez la haute disponibilité et la co-implantation, des clusters doivent être associés à un alias sur l'unité de bouclage pour les serveurs d'équilibrage de charge de secours.
Pour s'assurer que les systèmes Linux n'affichent pas les adresses dans l'unité de bouclage, vous devez les rendre compatibles avec l'acheminement MAC de Dispatcher. Vous avez le choix entre quatre solutions.
# sysctl -w net.ipv4.conf.all.hidden=1 net.ipv4.conf.lo.hidden=1Il est ensuite possible d'affecter des alias aux clusters selon la méthode normale, comme dans l'exemple suivant :
# ifconfig lo:1 $CLUSTER_ADDRESS netmask 255.255.255.255 up
# sysctl -w net.ipv4.conf.all.arp_ignore=3 net.ipv4.conf.all.arp_announce=2Pour affecter des alias aux clusters, utilisez la commande suivante :
# ip addr add $CLUSTER_ADDRESS/32 scope host dev loUne commande similaire doit se trouver dans les scripts go* pour les configurations de haute disponibilité et de co-implantation.
# iptables -t nat -A PREROUTING -d $CLUSTER_ADDRESS -j REDIRECTLes systèmes Linux effectuent alors une conversion NAT de la destination sur chaque paquet, en convertissant l'adresse de cluster en adresse d'interface. Cette méthode entraîne une baisse de débit d'environ 6,4 % en terme de nombre de connexions par seconde. Elle est compatible avec n'importe quelle distribution de stock prise en charge ; aucun module de noyau ou correctif+compilation+installation de noyau n'est requis.
# modprobe noarp # noarpctl add $CLUSTER_ADDRESS adresse-principale-nicoù adresse-principale-nic est une adresse appartenant au même sous-réseau que l'adresse du cluster. Il est ensuite possible d'affecter des alias aux clusters selon la méthode normale, comme dans l'exemple suivant :
# ifconfig lo:1 cluster address netmask 255.255.255.255 up
Cette section contient des informations pour la configuration d'un démarrage rapide ainsi que des remarques relatives à la planification, et présente les diverses méthodes de configuration du composant CBR de Load Balancer. Elle se compose des chapitres suivants :
Cet exemple de démarrage rapide indique comment configurer trois postes de travail connectés en local en associant le composant CBR au module Caching Proxy pour équilibrer la charge du trafic Web entre deux serveurs Web. (Par souci de simplicité, cet exemple se base sur des serveurs résidant sur le même segment de réseau local, alors que CBR ne l'impose pas.)
Figure 16. Configuration CBR locale simple
Pour l'exemple à démarrage rapide, vous devez disposer de trois postes de travail et de quatre adresses IP. L'un des postes de travail est utilisé comme machine CBR et les deux autres comme serveurs Web. Chaque serveur Web requiert une adresse IP. Le poste CBR requiert une adresse réelle et une adresse pour l'équilibrage de charge.
Pour pouvoir utiliser CBR, vous devez installer module Caching Proxy sur le même serveur. Pour configurer Caching Proxy pour CBR, voir Etape 1. Configuration de Caching Proxy pour utiliser CBR.
Poste de travail | Nom | Adresse IP |
---|---|---|
1 | server1.monsiteweb.com | 9.27.27.101 |
2 | server2.monsiteweb.com | 9.27.27.102 |
3 | server3.monsiteweb.com | 9.27.27.103 |
Masque réseau = 255.255.255.0 |
Chaque poste de travail ne contient qu'une carte d'interface réseau Ethernet standard.
Nom= www.monsiteweb.com IP=9.27.27.104
A l'aide de CBR, vous pouvez créer une configuration à l'aide de l'invite de commande, de l'assistant de configuration ou de l'interface graphique. Pour cet exemple de démarrage rapide, les étapes de configuration s'effectuent via l'invite de commande.
A partir d'une invite, effectuez les opérations ci-dessous.
cbrcontrol executor start
ibmproxy
cbrcontrol cluster add www.monsiteweb.com
cbrcontrol port add www.mywebsite.com:80
cbrcontrol server add www.monsiteweb.com:80:server2.monsiteweb.com
cbrcontrol server add www.monsiteweb.com:80:server3.monsiteweb.com
cbrcontrol rule add www.monsiteweb.com:80:memberRule type content pattern uri=*/member/*
cbrcontrol rule add www.monsiteweb.com:80:guestRule type content pattern uri=*/guest/*
Dans cet exemple, l'utilisation de la règle de contenu permet d'envoyer les demandes des clients adressées au site Web www.monsiteweb.com vers un autre serveur en fonction d'un répertoire désigné dans leur chemin de requête d'URI. Pour plus d'informations, voir Annexe B, Syntaxe de règle de contenu (modèle).
cbrcontrol rule useserver www.monsiteweb:80:memberRule server2.monsiteweb.com
cbrcontrol rule useserver www.monsiteweb:80:guestRule server3.monsiteweb.com
CBR procède maintenant à l'équilibrage de charge en fonction d'une règle de contenu. Un client dont la demande d'URL contient /member/ sera dirigé vers server2.monsiteweb.com. Un client dont la demande d'adresse URL contient /guest/ sera dirigé vers server3.monsiteweb.com.
cbrcontrol manager start
cbrcontrol advisor start http 80
CBR vérifie désormais que les demandes des clients ne sont pas envoyées vers un serveur Web arrêté.
La configuration de base comportant des serveurs liés en local est maintenant terminée.
Vérifiez que la configuration fonctionne :
cbrcontrol server report www.monsiteweb.com:80:La colonne du nombre total de connexions des deux serveurs doit contenir la valeur "2."
Pour plus d'informations sur l'utilisation de l'interface graphique de CBR, voir Interface graphique et Annexe A, Interface graphique utilisateur : Instructions générales.
Pour plus d'informations sur l'utilisation de l'assistant de CBR, voir Assistant de configuration.
La configuration de CBR pour assurer le support de votre site peut s'effectuer de plusieurs manières. Si votre site ne comprend qu'un seul nom de système hôte auquel tous vos clients se connectent, vous pouvez ne définir qu'un seul cluster de serveurs. Pour chaque serveur, configurez un port par l'intermédiaire duquel CBR communique. Voir la Figure 9.
Figure 17. Exemple de composant CBR configuré avec un cluster et 2 ports
Dans cet exemple de composant CBR, un cluster est défini sur www.productworks.com. Il dispose de deux ports : le port 80 pour HTTP et le port 443 pour SSL. Un client adressant une requête à l'adresse http://www.productworks.com (port 80) accédera à un autre serveur qu'un client s'adressant à https://www.productworks.com (port 443).
Si le site est très étendu et qu'il comporte un grand nombre de serveurs, chacun étant dédié à un protocole en particulier, CBR doit être configuré selon une autre méthode. Dans ce cas, vous pouvez définir un cluster pour chaque protocole, avec un seul port mais plusieurs serveurs, comme illustré par la Figure 10.
Figure 18. Exemple de composant CBR configuré avec deux clusters, chacun étant associé à un port
Dans cet exemple de composant CBR, deux clusters sont définis : www.productworks.com pour le port 80 (HTTP) et www.testworks.com pour le port 443 (SSL).
Une troisième configuration de CBR est nécessaire si votre site abrite plusieurs sociétés ou services, chacun accédant à votre site par une adresse URL distincte. Dans ce cas, vous pouvez définir un cluster pour chaque société ou service ainsi qu'un nombre de ports variable pour réceptionner les connexions de cette URL, comme illustré par la Figure 11.
Figure 19. Exemple de composant CBR configuré avec 2 clusters, chacun étant associé à 2 ports
Dans cet exemple de composant CBR, deux clusters sont définis avec le port 80 (HTTP) et le port 443 (SSL) pour chacun des sites www.productworks.com et www.testworks.com.
Le présent chapitre décrit les aspects que l'administrateur réseau doit prendre en compte avant d'installer et de configurer le composant CBR avec Caching Proxy.
Le présent chapitre contient la section suivante :
Le composant CBR permet d'équilibrer la charge du trafic HTTP et SSL à l'aide de Caching Proxy qui permet de transmettre la demande par un serveur proxy. CBR permet d'équilibrer la charge des serveurs configurés à partir de votre fichier de configuration CBR à l'aide des commandes cbrcontrol.
La structure de CBR ressemble beaucoup à celle de Dispatcher. CBR comprend les fonctions suivantes :
L'utilisation du gestionnaire n'est que facultative. Toutefois, s'il n'est pas utilisé, l'équilibrage de charge se fait sur la base d'une planification circulaire pondérée, elle-même basée sur les mesures de charge des serveurs et les conseillers ne seront pas disponibles.
Les trois fonctions clés de CBR (l'exécuteur, le gestionnaire et les conseillers) agissent en collaboration pour équilibrer et répartir entre les serveurs les requêtes réceptionnées. Outre la gestion des requêtes d'équilibrage de charge, l'exécuteur contrôle le nombre de nouvelles connexions et de connexions actives, et transmet ces informations au gestionnaire.
CBR vous permet de spécifier un ensemble de serveurs devant prendre en charge une demande client en fonction de son contenu. Le composant CBR vous permet de compartimenter votre site en plusieurs parties, chacune pouvant être traitée par des ensembles de serveurs différents. Ce partitionnement est transparent pour les clients accédant à votre site.
Vous pouvez répartir votre site en affectant à certains serveurs le traitement de requêtes cgi uniquement, et en affectant à un autre ensemble de serveurs le traitement de toutes les autres requêtes. Ceci mettrait fin au ralentissement de l'activité des serveurs dû au calcul d'énormes scripts cgi au cours d'un trafic HTML normal, et permettrait ainsi aux clients d'obtenir de meilleurs temps de réponse. Avec cette méthode, vous pouvez également utiliser des postes de travail plus puissants pour des requêtes normales. Ainsi, les clients obtiendraient un meilleur temps de réponse sans pour autant occasionner des frais de mise à niveau de tous vos serveurs. Vous pouvez également affecter des postes de travail plus puissants pour des requêtes cgi.
Vous pouvez également partitionner votre site en dirigeant vers un ensemble de serveurs les clients qui accèdent à des pages nécessitant une opération d'enregistrement, et en acheminant toutes les autres requêtes vers un deuxième ensemble de serveurs. Ainsi, les navigateurs occasionnels qui accèdent à votre site n'accapareront plus les ressources qui pourraient être utilisées par des clients devant effectuer des opérations d'enregistrement sur votre site. Cela vous permettrait également d'utiliser des postes de travail plus puissants pour traiter les clients qui se sont enregistrés.
Il est possible de combiner les deux pour plus de souplesse et pour un meilleur service.
CBR vous permet d'indiquer plusieurs serveurs pour chaque type de requête. Par conséquent, les requêtes peuvent être équilibrées pour obtenir une réponse optimale du client. L'affectation de plusieurs serveurs à chaque partie de votre site vous permet de vous protéger en cas de défaillance d'un poste de travail ou d'un serveur. CBR reconnaîtra la défaillance et continuera d'équilibre la charge des requêtes client aux autres serveurs du groupe.
Caching Proxy communique avec un processus CBR via son interface de module d'extension. Le processus CBR doit s'exécuter sur la machine locale pour ce travail. Ces deux processus étant distincts, plusieurs instances Caching Proxy peuvent s'exécuter et travailler avec une seule instance de processus CBR. Vous pouvez adopter ce type de configuration pour isoler des adresses ou des fonctions entre les divers processus Caching Proxy ou pour optimiser l'utilisation des ressources de la machine en définissant plusieurs processus Caching Proxy en charge du trafic client. Les instances proxy sont à l'écoute sur différents ports ou en liaison avec des adresses IP uniques sur le même port, selon les besoins du trafic.
CBR et Caching Proxy examinent les requêtes HTTP à l'aide des types de règle indiqués. Pendant l'exécution, Caching Proxy accepte les demandes client et interroge le composant CBR pour savoir quel est le meilleur serveur. Lorsqu'il reçoit cette demande, CBR la compare à un ensemble de règles prioritaires. Dès qu'il en trouve une qui correspond, un serveur approprié est sélectionné dans un ensemble de serveurs préconfigurés. Enfin, CBR indique à Caching Proxy le serveur sélectionné, et les demandes sont transmises à ce dernier.
Une fois que vous avez défini un cluster pour la répartition de charge, assurez-vous que toutes les requêtes envoyées à ce cluster ont une règle qui choisira un serveur. Si aucune règle correspondant à une requête spécifique n'est trouvée, Caching Proxy enverra une page d'erreur au client. Le moyen le plus facile pour s'assurer que toutes les demandes correspondront à une règle est de créer une règle "toujours vraie" avec un niveau de priorité élevé. Vérifiez que les serveurs auxquels se réfère cette règle peuvent traiter toutes les demandes non gérées explicitement par les règles ayant des niveaux de priorité moins élevés. (Remarque : Les règles de priorité inférieure sont évaluées en premier.)
Pour plus d'informations, voir Configuration d'un équilibrage de charge basé sur des règles.
CBR et Caching Proxy peuvent recevoir une transmission SSL d'un client vers le proxy (côte client-serveur) ainsi que prendre en charge une transmission d'un proxy vers un serveur SSL (côté proxy-serveur). Si vous définissez un port SSL sur un serveur dans la configuration CBR pour qu'il reçoive la demande SSL provenant d'un client, vous pouvez gérer un site complètement sécurisé, en utilisant CBR pour équilibrer la charge entre les serveurs sécurisés SSL.
En plus des autres modifications du fichier ibmproxy.conf pour CBR, une instruction de configuration doit être ajoutée au fichier ibmproxy.conf pour que Caching Proxy active le chiffrement SSL du proxy vers le serveur. Le format est le suivant :
proxy structure_uri structure_url adresse
où uri_structure correspond à la structure à respecter (par exemple : /secure/*), url_structure à un URL de remplacement (par exemple : https://clusterA/secure/*) et adresse à l'adresse du cluster (par exemple : clusterA).
CBR et Caching Proxy peuvent également recevoir une transmission SSL d'un client et déchiffrer la demande SSL avant d'acheminer la demande par proxy à un serveur HTTP. Pour que CBR prenne en charge la transmission client-proxy pour SSL et proxy-client pour HTTP, utilisez le mot clé facultatif mapport dans la commande cbrcontrol server. Il permet d'indiquer si le port du serveur est différent du port d'entrée du client. Voici un exemple d'ajout de port avec le mot clé mapport, dans lequel le port du client est 443 (SSL) et le port du serveur est 80 (HTTP) :
cbrcontrol server add cluster:443 mapport 80
Le numéro de port de mapport peut correspondre à n'importe quel entier positif. La valeur par défaut correspond au numéro de port entrant du client.
Etant donné que CBR doit être capable de traiter une demande HTTP pour un serveur configuré sur le port 443 (SSL), un conseiller spécial ssl2http est fourni. Il démarre sur le port 443 (le port entrant du client) et opère sur le ou les serveurs configurés pour ce port. Si deux clusters sont configurés et que pour chacun d'entre eux, le port 443 et les serveurs sont configurés avec un paramètre mapport différent, une seule instance du conseiller peut ouvrir le port approprié. Voici un exemple de cette configuration :
Executor Cluster1 Port:443 Server1 mapport 80 Server2 mapport 8080 Cluster2 Port:443 Server3 mapport 80 Server4 mapport 8080 Manager Advisor ssl2http 443
Avant d'effectuer les opérations décrites dans le présent chapitre, voir Planification de CBR (Content Based Routing). Ce chapitre explique comment créer une configuration de base pour le composant CBR de Load Balancer.
Avant de suivre les étapes de configuration détaillées dans ce tableau, assurez-vous que le poste CBR et tous les postes serveurs sont connectés au réseau, que leurs adresses IP sont valides et qu'ils peuvent communiquer entre eux par ping.
Tableau 10. Tâches de configuration pour le composant CBR
Tâche | Description | Informations connexes |
---|---|---|
Configurer le poste CBR | Conditions requises | Configuration de la machine CBR |
Configuration des machines en vue de l'équilibrage de charge. | Définition de la configuration de l'équilibrage de charge. | Etape 7. Définition des serveurs avec équilibrage de charge |
Quatre méthodes permettent de créer une configuration de base du composant CBR de Load Balancer :
Pour utiliser le composant CBR, Caching Proxy doit être installé.
C'est la méthode de configuration de CBR la plus directe. Les valeurs des paramètres de commandes doivent être saisies à l'aide de caractères anglais. Les seules exceptions s'appliquent aux noms d'hôte (utilisés dans les commandes cluster et server) et aux noms de fichiers.
Pour démarrer CBR à partir de l'invite de commande, procédez aux opérations ci-dessous.
Pour les systèmes Windows : cliquez sur Démarrer > Paramètres (pour Windows 2000) > Panneau de configuration > Outils d'administration > Services. Cliquez à l'aide du bouton droit de la souris sur IBM Content Based Routing et sélectionnez Démarrer. Pour arrêter le service, suivez la même procédure en sélectionnant Arrêter.
Vous pouvez entrer une version abrégée des paramètres de contrôle cbrcontrol. Il suffit d'entrer les lettres spécifiques des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, vous pouvez entrer cbrcontrol he f au lieu de cbrcontrol help file.
Pour démarrer l'interface de ligne de commande, entrez cbrcontrol pour ouvrir une invite cbrcontrol.
Pour fermer l'interface de ligne de commande, entrez exit ou quit.
Remarques :
( ) parenthèses ouvrante et fermante
& perluète
| barre verticale
! point d'exclamation
* astérisque
Le shell du système d'exploitation peut interpréter ces caractères comme des caractères spéciaux et les convertir en texte de remplacement avant leur évaluation par cbrcontrol.
Les caractères spéciaux de la liste précédente sont facultatifs dans la commande cbrcontrol rule add. Ils sont employés lors de l'indication d'un motif pour une règle de contenu. Par exemple, la commande suivante n'est valide qu'avec l'invite cbrcontrol>>.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*
Pour que cette commande fonctionne à partir de l'invite du système d'exploitation, placez le motif entre guillemets (" ") comme suit :
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Si vous omettez les guillemets, le motif sera peut-être tronqué lors de la sauvegarde de la règle dans CBR. Les guillemets ne sont pas pris en charge avec l'invite cbrcontrol>>.
Vous pouvez entrer les commandes de configuration CBR dans un fichier script de configuration pour les exécuter simultanément.
cbrcontrol file appendload mon_script
cbrcontrol file newload mon_script
Pour sauvegarder la configuration en cours dans un fichier script (par exemple, savescript), exécutez la commande suivante :
cbrcontrol file save savescript
Cette commande enregistre le fichier script de configuration dans le répertoire ...ibm/edge/lb/servers/configurations/cbr.
Pour des instructions générales et un exemple de l'interface graphique, voir Figure 41.
Pour démarrer l'interface graphique, procédez comme suit :
Pour pouvoir configurer le composant CBR à partir de l'interface graphique, vous devez d'abord sélectionner Content Based Routing dans l'arborescence. Vous pouvez lancer le gestionnaire une fois que vous vous êtes connecté à un hôte. Vous pouvez également créer des clusters contenant des ports et des serveurs, puis lancer des conseillers pour le gestionnaire.
Vous pouvez utiliser l'interface graphique pour toute opération normalement exécutée par la commande cbrcontrol. Par exemple, pour définir un cluster à l'aide de l'invite de commande, exécutez la commande cbrcontrol cluster add cluster. Pour définir un cluster à partir de l'interface graphique, cliquez sur Exécuteur à l'aide du bouton droit de la souris, puis dans le menu en incrustation qui apparaît, cliquez sur le bouton Ajout d'un cluster à l'aide du bouton gauche de la souris. Entrez l'adresse du cluster dans la fenêtre en incrustation, puis cliquez sur OK.
Les fichiers de configuration CBR existants peuvent être chargés à l'aide des options Chargement de la nouvelle configuration (pour remplacer intégralement la configuration en cours) et Ajout à la configuration en cours (pour mettre à jour la configuration en cours) du menu en incrustation Hôte. Vous devez sauvegarder régulièrement votre configuration CBR dans un fichier, en utilisant l'option Sauvegarder le fichier de configuration en... du menu en incrustation Hôte. Le menu Fichier situé en haut de l'interface graphique permet de sauvegarder les connexions à l'hôte en cours dans un fichier ou de restaurer les connexions dans des fichiers existants sur tous les composants Load Balancer.
Vous pouvez accéder à l'Aide en cliquant sur le point d'interrogation situé dans l'angle supérieur droit de la fenêtre Load Balancer.
Pour exécuter une commande à partir de l'interface graphique : mettez le noeud Hôte en surbrillance dans l'arborescence de l'interface graphique, puis sélectionnez Envoyer la commande... dans le menu en incrustation Hôte. Dans la zone d'entrée de commande, exécutez la commande à exécuter, par exemple executor report. Les résultats et l'historique des commandes exécutées lors de la session courante s'affichent dans la fenêtre ouverte.
Pour plus d'informations sur l'utilisation de l'interface graphique, voir Annexe A, Interface graphique utilisateur : Instructions générales.
Si vous utilisez l'assistant de configuration, suivez la procédure ci-dessous.
Pour ce faire, démarrez l'assistant à partir de l'invite en entrant cbrwizard. Ou alors, sélectionnez l'assistant de configuration dans le menu des composants CBR proposé par l'interface graphique.
Pour les systèmes AIX, HP-UX, Linux ou Solaris : Pour lancer Caching Proxy, entrez ibmproxy
Pour les systèmes Windows : Démarrez Caching Proxy à partir du panneau Services : Démarrer > Paramètres (pour Windows 2000) > Panneau de configuration > Outils d'administration > Services
Cet assistant vous guide, pas à pas, pendant la création d'une configuration de base du composant CBR. Il vous demande des renseignements sur votre réseau et vous guide pendant l'installation d'un cluster permettant à CBR d'équilibrer la charge du trafic d'un groupe de serveurs.
La configuration de la machine CBR ne peut être effectuée que par le superutilisateur (pour les systèmes AIX, HP-UX, Linux ou Solaris) ou l'administrateur (pour les systèmes Windows).
Vous aurez besoin d'une adresse IP pour chaque cluster de serveurs configuré. Une adresse de cluster est une adresse associée à un nom de système hôte (par exemple www.société_X.com). Cette adresse IP est utilisée par un client pour se connecter aux serveurs du cluster en question. Cette adresse se trouve dans la requête URL du client. Toutes les requêtes envoyées à la même adresse de cluster font l'objet d'un équilibrage de charge par CBR.
Pour les systèmes Solaris uniquement : Pour pouvoir utiliser le composant CBR, vous devez modifier les valeurs système par défaut attribuées aux communications IPC (Inter-process Communication). Vous devez augmenter la taille maximale du segment de mémoire partagée et le nombre d'identificateurs de sémaphores. Pour configurer la prise en charge de CBR, ajoutez les instructions suivantes dans le fichier /etc/system, puis réamorcez le système :
set shmsys:shminfo_shmmax=0x02000000 set semsys:seminfo_semmap=750 set semsys:seminfo_semmni=30 set semsys:seminfo_semmns=750 set semsys:seminfo_semmnu=30 set semsys:seminfo_semume=30
Si vous n'attribuez pas au segment de mémoire partagée les valeurs ci-dessus, la commande cbrcontrol executor start échouera.
Pour utiliser le composant CBR, Caching Proxy doit être installé.
Apportez les modifications ci-dessous au fichier de configuration de Caching Proxy (ibmproxy.conf) :
Vérifiez que la directive d'URL entrante CacheByIncomingUrl a la valeur "off" (valeur par défaut).
Dans la section des règles de mappage du fichier de configuration, ajoutez pour chaque cluster une règle de mappage du type suivant :
Proxy /* http://cluster.domain.com/* cluster.domain.com
Quatre entrées doivent être modifiées pour le plug-in CBR :
Les ajouts spécifiques au fichier de configuration de chaque système d'exploitation sont répertoriés ci-dessous.
Figure 20. Fichier de configuration CBR pour les systèmes AIX, Linux et Solaris
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerTerm
Figure 21. Fichier de configuration CBR pour les systèmes HP-UX
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerTerm
Figure 22. Fichier de configuration CBR pour les systèmes Windows
ServerInit C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerInit PostAuth C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostAuth PostExit C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostExit ServerTerm C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerTerm
Pour démarrer la fonction serveur CBR, entrez cbrserver sur l'invite de commande.
Un fichier de configuration par défaut (default.cfg) est chargé automatiquement lors du démarrage de cbrserver. Si vous sauvegardez la configuration CBR dans default.cfg, toutes les données enregistrées dans ce fichier sont automatiquement chargées au prochain démarrage de cbrserver.
Pour démarrer la fonction exécuteur, exécutez la commande cbrcontrol executor start. Notez que vous pouvez également modifier divers paramètres de l'exécuteur à cette occasion. Voir dscontrol executor -- Contrôle de l'exécuteur.
CBR équilibrera les requêtes envoyées au cluster entre les serveurs correspondants configurés sur les ports de ce cluster.
Le cluster est le nom symbolique situé sur la portion hôte de l'URL et qui doit correspondre au nom utilisé dans l'instruction Proxy du fichier ibmproxy.conf.
Les clusters définis dans CBR doivent correspondre à la demande entrante. Un cluster doit être défini à l'aide du nom d'hôte ou de l'adresse IP contenue dans la demande entrante. Par exemple, si la demande est entrée sous forme d'adresse IP, le cluster doit être défini en tant que cette adresse IP. Si plusieurs noms d'hôte se résolvent en une seule adresse IP (et que les demandes peuvent arriver avec l'un de ces noms d'hôte), tous les noms d'hôte doivent être définis en tant que clusters.
Pour définir un cluster, tapez la commande suivante :
cbrcontrol cluster add cluster
Pour définir les options de cluster, tapez la commande suivante :
cbrcontrol cluster set valeur d'option de cluster
Pour plus d'informations, voir le Guide des commandes Dispatcher et CBR.
Si vous exécutez Caching Proxy dans une configuration de proxy inverse, lors de l'équilibrage de charge pour plusieurs sites Web, vous devez ajouter l'adresse de cluster de chaque site Web au moins à l'une des cartes d'interface réseau du système Load Balancer. Sinon, vous pouvez ignorer cette étape.
Pour les systèmes AIX, HP-UX, Linux ou Solaris : Pour ajouter
l'adresse de cluster à l'interface réseau, servez-vous de la commande ifconfig. Utilisez
la commande adaptée à votre système d'exploitation comme indiqué dans le Tableau 11.
Tableau 11. Commandes pour l'affectation d'un alias à la carte d'interface réseau
AIX | ifconfig nom_interface alias adresse_cluster netmask masque_réseau |
HP-UX | ifconfig nom_interface adresse_cluster netmask masque_réseau up |
Linux | ifconfig nom_interface adresse_cluster netmask masque_réseau up |
Solaris 8, Solaris 9 et Solaris 10 | ifconfig nom_interface addif adresse_cluster netmask masque_réseau up |
Sous Windows 2000 : Pour ajouter l'adresse de cluster à l'interface réseau, procédez comme suit :
Sous Windows 2003 : Pour ajouter l'adresse de cluster à l'interface réseau, procédez comme suit :
Le numéro de port est le port à partir duquel les applications serveur sont à l'écoute. Pour le composant CBR avec Caching Proxy exécutant le trafic HTTP, il s'agit en général du port 80.
Pour définir le port du cluster défini à l'étape précédente, exécutez la commande suivante :
cbrcontrol port add cluster:port
Pour définir les options de port, exécutez la commande suivante :
cbrcontrol port set cluster:port option value
Pour plus d'informations, voir Guide des commandes Dispatcher et CBR.
Les serveurs sont les postes qui exécutent les applications dont vous souhaitez équilibrer la charge. Le serveur est l'adresse à nom symbolique ou notation décimale de la machine serveur. Pour définir un serveur dans le cluster et le port, tapez la commande suivante :
cbrcontrol server add cluster:port:serveur
Vous devez définir un ou plusieurs serveurs par port sur un cluster pour pouvoir procéder à l'équilibrage des charges.
Il s'agit de l'étape clé de la configuration CBR avec Caching Proxy. Une règle définit la manière dont une requête URL sera reconnue et envoyée à l'un des ensembles de serveurs appropriés. Le type de règle spéciale utilisé par CBR est appelé règle de contenu. Pour définir une règle de contenu, tapez la commande suivante :
cbrcontrol rule add cluster:port:règle type content pattern pattern
La valeur pattern est l'expression régulière qui est comparée à l'URL de chaque requête client. Pour plus d'informations sur la configuration de la structure, voir Annexe B, Syntaxe de règle de contenu (modèle).
Certains autres types de règles définis dans Dispatcher peuvent également être utilisés dans CBR. Pour plus d'informations, voir Configuration d'un équilibrage de charge basé sur des règles.
Lorsqu'une règle correspond à une requête client, l'ensemble de serveurs de la règle est interrogé pour déterminer le meilleur serveur. L'ensemble de serveurs de la règle est un sous-ensemble de serveurs définis dans le port. pour ajouter des serveurs à un ensemble de serveurs de la règle, exécutez la commande suivante :
cbrcontrol rule useserver cluster:port:serveur de règle
La fonction gestionnaire permet d'améliorer l'équilibrage de charge. Pour démarrer le gestionnaire, tapez la commande suivante :
cbrcontrol manager start
Les conseillers transmettent au gestionnaire des informations complémentaires sur la capacité à répondre aux demandes des serveurs ayant fait l'objet d'un équilibrage de charge. Chaque conseiller est spécifique à un protocole. Par exemple, tapez la commande suivante pour lancer le conseiller HTTP :
cbrcontrol advisor start http port
Si vous démarrez des conseillers, vous pouvez modifier le niveau d'importance donné aux informations des conseillers entrant dans les décisions d'équilibrage de la charge. Pour définir les proportions du cluster, entrez la commande cbrcontrol cluster set cluster proportions. Pour plus d'informations, voir Proportion de l'importance accordée aux données d'état.
/opt/ibm/edge/lb/servers/lib
/opt/ibm/edge/lb/servers/lib
C:\Program Files\IBM\edge\lb\servers\lib
Dans le nouvel environnement, démarrez Caching Proxy, en entrant ibmproxy à partir de l'invite
Pour configurer CBR, procédez comme suit :
Cette section contient des informations pour la configuration d'un démarrage rapide ainsi que des remarques relatives à la planification, et présente les diverses méthodes de configuration du composant Site Selector de Load Balancer. Elle se compose des chapitres suivants :
Cet exemple de démarrage rapide montre comment créer une configuration de nom de site à l'aide de Site Selector pour équilibrer la charge sur un ensemble de serveurs sur la base du nom de domaine utilisé dans la demande d'un client.
Figure 23. Configuration Site Selector simple
Cet exemple de configuration de démarrage rapide nécessite :
Pour cet exemple de démarrage rapide, le domaine du site de la compagnie est ma_boutique_web.com. Site Selector est responsable du sous-domaine ma_boutique_web.com. Vous devez donc définir un sous-domaine dans ma_boutique_web.com. Par exemple : apps.ma_boutique_web.com. Site Selector n'est pas un système DNS totalement implémenté, tel que BIND, et agit en tant que noeud terminal dans une hiérarchieDNS. Site Selector a autorité sur le sous-domaine apps.ma_boutique_web.com. Le sous-domaine apps.ma_boutique_web.com contiendra les noms de site suivants : marketing.apps.ma_boutique_web.com et développeur.apps.ma_boutique_web.com.
apps.ma_boutique_web.com. IN NS siteselector.ma_boutique_web.com
A l'aide de Site Selector, vous pouvez créer une configuration à l'aide de l'invite de commande, de l'assistant de configuration ou de l'interface graphique. Pour cet exemple de démarrage rapide, les étapes de configuration s'effectuent via l'invite de commande.
A partir d'une invite, effectuez les opérations ci-dessous.
sscontrol nameserver start
sscontrol sitename add marketing.apps.ma_boutique_web.com
sscontrol sitename add développeur.apps.ma_boutique_web.com
sscontrol server add marketing.apps.mywebshop.com:server1+server2
sscontrol server add développeur.apps.ma_boutique_web.com:serveur3+serveur4
sscontrol manager start
sscontrol advisor start http marketing.apps.ma_boutique_web.com:80
sscontrol advisor start ftp developer.apps.mywebshop.com:21
Site Selector vérifie désormais que les demandes des clients ne sont pas envoyées vers un serveur arrêté.
La configuration de base de Site Selector est maintenant terminée.
Vérifiez que la configuration fonctionne :
sscontrol server status marketing.apps.ma_boutique_web.com:
sscontrol server status développeur.apps.ma_boutique_web.com:
Le nombre total de réussites d'accès de chaque serveur doit s'ajouter aux demandes de commande ping et d'application.
Pour plus d'informations sur l'utilisation de l'interface graphique de Site Selector, voir Interface graphique et Annexe A, Interface graphique utilisateur : Instructions générales.
Pour plus d'informations sur l'utilisation de l'assistant de Site Selector, voir Assistant de configuration.
Le présent chapitre décrit les aspects que l'administrateur de réseau doit prendre en compte avant d'installer et de configurer le composant Site Selector.
Le présent chapitre se compose des sections suivantes :
Site Selector fonctionne avec un serveur de noms de domaine pour équilibrer la charge sur un groupe de serveurs à l'aide des mesures et des pondérations recueillies. Vous pouvez créer une configuration de site pour assurer l'équilibrage de charge sur un groupe de serveurs sur la base du nom de domaine utilisé pour la demande d'un client.
Limitations : Les seules requêtes DNS prises en charge par Site Selector sont celles de type A. Tous les autres types de requête génèrent le code retour NOTIMPL (Not Implemented - non implémenté). Si tout un domaine est attribué à Site Selector, assurez-vous qu'il ne reçoive que des requêtes de type A.
Figure 24. Exemple d'environnement DNS
Lors de la définition d'un sous-domaine de Site Selector dans l'environnement DNS, Site Selector doit disposer de droits d'accès à ce sous-domaine. Par exemple (voir la Figure 24), votre entreprise dispose de droits d'accès au domaine entreprise.com. Elle dispose de plusieurs sous-domaines. Site Selector doit disposer de droits d'accès à siteload.entreprise.com et les serveurs DNS gardent leurs droits d'accès à atlanta.entreprise.com et à boston.entreprise.com.
Pour permettre au serveur de noms de l'entreprise de reconnaître les droits d'accès de Site Selector au sous-domaine siteload, il est nécessaire d'ajouter une entrée dans le fichier de données du serveur de noms. Par exemple, sur les systèmes AIX, une entrée de serveur de noms a l'apparence suivante :
siteload.entreprise.com. IN NS siteselector.entreprise.com.
Où siteselector.entreprise.com correspond au nom d'hôte de la machine Site Selector. Des entrées équivalentes doivent être insérées dans les autres fichiers de base de données utilisés par les serveurs DNS.
Un client envoie une demande de résolution de nom de domaine à un serveur de noms appartenant au réseau. Le serveur de noms achemine la demande vers la machine Site Selector. Site Selector résout le nom de domaine en adresse IP de l'un des serveurs qui a été configuré sous le nom du site. Site Selector renvoie l'adresse IP du serveur sélectionné au serveur de noms. Le serveur de noms renvoie l'adresse IP au client. (Site Selector joue le rôle de serveur de noms non récurrents (noeud feuille) et renvoie une erreur s'il ne résout pas la demande de nom de domaine.
Voir la Figure 5 qui montre un site dans lequel Site Selector est utilisé avec un système DNS pour équilibrer la charge entre des serveurs locaux et éloignés.
Site Selector se compose des fonctions suivantes :
L'utilisation du gestionnaire n'est que facultative. Toutefois, s'il n'est pas utilisé, l'équilibrage de charge se fait sur la base d'une planification circulaire pondérée, elle-même basée sur les mesures de charge des serveurs et les conseillers ne seront pas disponibles.
Metric Server permet à Site Selector de surveiller le niveau d'activité d'un serveur, de détecter le moment où un serveur est le moins chargé et de détecter un serveur défaillant. Par charge, on entend le travail effectivement fourni par le serveur. L'administrateur système Site Selector contrôle le type de mesure employé pour évaluer la charge. Site Selector peut être configuré en fonction de chaque environnement, en tenant compte de facteurs tels que la fréquence des accès, le nombre total d'utilisateurs et les différents types d'accès (requêtes courtes, longues, à forte ou faible consommation de ressources CPU).
L'équilibrage de charge est basée sur les pondérations de serveur. Pour Site Selector, il existe quatre niveaux d'importance des informations que le gestionnaire utilise pour déterminer les pondérations :
Les valeurs CPU et mémoire sont fournies par Metric Server. Par conséquent, l'utilisation de Metric Server est recommandée avec le composant Site Selector.
Pour plus d'informations, voir Metric Server.
Les quatre fonctions clés de Site Selector (serveur de noms, gestionnaire, Metric Server et conseillers) interagissent afin d'équilibrer les demandes entrantes entre les serveurs et de les résoudre.
L'équilibrage de charge utilisant le système DNS nécessite la désactivation de l'enregistrement en mémoire cache de la résolution des noms. La valeur TTL (time to live) détermine l'efficacité de ce type d'équilibrage de charge. Elle détermine la période pendant laquelle la réponse résolue reste en mémoire cache sur un autre serveur de noms. Les valeurs TTL peu élevées permettent d'effectuer plus rapidement les modifications subtiles de la charge du serveur ou du réseau. La désactivation de l'enregistrement en mémoire cache oblige toutefois les clients à contacter le serveur de noms autorisé pour chaque demande de résolution de nom, augmentant potentiellement le temps d'attente des clients. Tenez compte de l'impact sur l'environnement de la désactivation de l'enregistrement en mémoire cache lorsque vous choisissez une valeur TTL. Vous devez en outre savoir que l'équilibrage de charge DNS peut être limité par l'enregistrement en mémoire cache côté client de la résolution des noms.
Vous pouvez configurer la durée de vie (TTL) à l'aide de la commande sscontrol sitename [add | set] . Pour plus d'informations, voir sscontrol sitename -- Configuration d'un nom de site.
Network proximity correspond au calcul de la position de chaque serveur par rapport au client émettant la demande. Pour déterminer la proximité réseau, l'agent Metric Server (qui doit se trouver sur chaque serveur dont la charge est équilibrée) envoie une commande ping à l'adresse IP client et renvoie le temps de réponse à Site Selector. Site Selector utilise la réponse de proximité dans la décision relative à l'équilibrage de charge. Il combine la valeur de la réponse de proximité réseau avec la pondération provenant du gestionnaire pour créer une valeur de pondération finale pour le serveur.
L'utilisation de la fonction de proximité réseau (Network Proximity) avec Site Selector est facultative.
Site Selector fournit les options de proximité réseau suivantes pouvant être définies par nom de site :
Si cette option est associée à la valeur oui, Metric Server envoie une commande ping au client pour obtenir le temps de réponse de proximité. Le serveur de noms attend que tous les serveurs Metric répondent ou que le délai d'expiration se termine. Ensuite, pour chaque serveur, le serveur de noms combine le temps de réponse de proximité avec la pondération que le gestionnaire a calculée pour créer une valeur de "pondération combinée". Site Selector fournira au client l'adresse IP du serveur associée à la meilleure pondération combinée. (Normalement, la plupart des serveurs de noms client observent un dépassement de délai de 5 secondes. Site Selector tente de répondre avant la fin de ce délai.)
Si la valeur est non, une résolution de nom est fournie au client en fonction des pondérations de gestionnaire actuelles. Ensuite, Metric Server envoie une commande ping au client pour obtenir le temps de réponse de proximité. Le serveur de noms met en cache le temps de réponse qu'il reçoit de Metric Server. Lorsque le client renvoie une deuxième requête, le serveur de noms combine la pondération du gestionnaire actuelle avec la valeur de réponse ping mise en cache pour chaque serveur afin d'obtenir le serveur associé à la meilleure "pondération combinée". Site Selector renvoie l'adresse IP de ce serveur au client pour la deuxième requête.
Les options de proximité réseau peuvent être définies dans la commande sscontrol sitename [add | set] . Pour plus d'informations, voir le Guide des commandes Site Selector.
Avant d'effectuer les opérations décrites dans le présent chapitre, voir Planification de Site Selector. Ce chapitre explique comment créer une configuration de base pour le composant Site Selector de Load Balancer.
Tableau 12. Tâches de configuration pour le composant Site Selector
Tâche | Description | Informations connexes |
---|---|---|
Configuration de la machine Site Selector. | Conditions requises | Configuration de la machine Site Selector |
Configuration des machines en vue de l'équilibrage de charge. | Définition de la configuration de l'équilibrage de charge. | Etape 4. Définition des serveurs avec équilibrage de charge |
Quatre méthodes permettent de créer une configuration de base du composant Site Selector de Load Balancer :
C'est la méthode de configuration de Site Selector la plus directe. Les valeurs des paramètres de commandes doivent être saisies à l'aide de caractères anglais. Les seules exceptions s'appliquent aux noms d'hôte (utilisés dans les commandes site name et server) et aux noms de fichiers.
Pour démarrer Site Selector à partir de la ligne de commande :
Vous pouvez entrer une version abrégée des paramètres de commandes sscontrol. Il suffit d'entrer les lettres spécifiques des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, entrez sscontrol he f à la place de sscontrol help file.
Pour démarrer l'interface de ligne de commande, entrez sscontrol pour ouvrir une invite sscontrol.
Pour fermer l'interface de ligne de commande, entrez exit ou quit.
Les commandes permettant de configurer Site Selector peuvent être entrées dans un fichier script de configuration et exécutées simultanément.
sscontrol file appendload mon_script
sscontrol file newload mon_script
Pour sauvegarder la configuration en cours dans un fichier script (par exemple, savescript), exécutez la commande suivante :
sscontrol file save savescript
Cette commande enregistre le fichier script de configuration dans le répertoire ...ibm/edge/lb/servers/configurations/ss.
Pour des instructions générales et un exemple de l'interface graphique, voir la Figure 41.
Pour démarrer l'interface graphique, procédez comme suit :
Pour pouvoir configurer le composant Site Selector à partir de l'interface graphique, vous devez d'abord sélectionner Site Selector dans l'arborescence. Une fois connecté à un hôte sur lequel ssserver est exécuté, vous pouvez créer des noms de site contenant des serveurs, démarrer le gestionnaire et lancer des conseillers.
Vous pouvez utiliser l'interface graphique pour toute opération normalement exécutée par la commande sscontrol. Par exemple, pour définir un nom de site à partir de la ligne de commande, vous devez entrer la commande sscontrol sitename add nom_site. Pour définir un nom de site à partir de l'interface graphique, cliquez à l'aide du bouton droit de la souris sur Serveur de noms, puis dans le menu en incrustation, sélectionnez Ajouter un nom de site. Entrez le nom du site dans le menu en incrustation, puis cliquez sur OK.
Les fichiers de configuration Site Selector existants peuvent être chargés à l'aide des options Chargement de la nouvelle configuration (pour remplacer intégralement la configuration en cours) et Ajout à la configuration en cours (pour mettre à jour la configuration en cours) du menu en incrustation Hôte. Vous devez sauvegarder régulièrement votre configuration Site Selector dans un fichier en utilisant l'option Sauvegarder le fichier de configuration sous du menu en incrustation Hôte. Le menu Fichier situé en haut de l'interface graphique permet de sauvegarder les connexions à l'hôte en cours dans un fichier ou de restaurer les connexions dans des fichiers existants sur tous les composants Load Balancer.
Pour exécuter une commande à partir de l'interface graphique : mettez le noeud Hôte en surbrillance dans l'arborescence de l'interface graphique, puis sélectionnez Envoyer la commande... dans le menu en incrustation Hôte. Dans la zone d'entrée de commande, exécutez la commande à exécuter, par exemple nameserver status. Les résultats et l'historique des commandes exécutées lors de la session courante s'affichent dans la fenêtre ouverte.
Vous pouvez accéder à l'Aide en cliquant sur le point d'interrogation situé dans l'angle supérieur droit de la fenêtre Load Balancer.
Pour plus d'informations sur l'utilisation de l'interface graphique, voir Annexe A, Interface graphique utilisateur : Instructions générales.
Si vous utilisez l'assistant de configuration, suivez la procédure ci-dessous.
ssserver
.Vous pouvez lancer cet assistant à partir de l'invite en entrant la commande sswizard Ou alors, sélectionnez l'assistant de configuration dans le menu des composants Site Selector proposé par l'interface graphique.
L'assistant de Site Selector vous guide pas à pas dans le processus de création d'une configuration de base pour le composant Site Selector. Il vous demande des renseignements sur votre réseau et vous guide pour la configuration d'un nom de site permettant à Site Selector d'équilibrer le trafic entre un groupe de serveurs.
La configuration de la machine Site Selector ne peut être effectuée que par le superutilisateur (pour les systèmes AIX, HP-UX, Linux ou Solaris) ou l'administrateur (pour les systèmes Windows).
Vous aurez besoin d'un nom d'hôte complet ne pouvant être résolu comme nom de site pour le groupe de serveurs que vous configurez. Le nom de site est celui utilisé pour les clients pour accéder à votre site (par exemple, www.yourcompany.com). Site Selector équilibrera la charge du trafic pour ce nom de site entre les serveurs du groupe auquel le nom DNS a été attribué.
Pour démarrer la fonction serveur Site Selector, entrez ssserver sur l'invite de commande.
Pour démarrer le serveur de noms, exécutez la commande sscontrol nameserver start.
Vous pouvez également lancer le serveur de noms à l'aide du mot clé bindaddress pour établir un lien uniquement avec l'adresse indiquée.
Site Selector équilibrera les requêtes envoyées au nom de site aux serveurs correspondants configurés pour cela.
Un nom de site est un nom d'hôte impossible à résoudre, qui sera demandé par le client. Le nom de site doit être un nom de domaine complet (comme www.dnsdownload.com). Lorsqu'un client demande ce nom de site, l'une des adresses IP de serveur associées au nom de site est renvoyée.
Pour définir un nom de site, tapez la commande suivante :
sscontrol sitename add nom_site
Pour définir les options du nom de site, tapez la commande suivante :
sscontrol sitename set valeur_option_nom_site
Pour plus d'informations, voir Guide des commandes Site Selector.
Les serveurs sont les postes qui exécutent les applications dont vous souhaitez équilibrer la charge. Le serveur est l'adresse à nom symbolique ou notation décimale de la machine serveur. Pour définir un serveur sur le nom de site défini à l'étape 3, entrez la commande suivante :
sscontrol server add nom_site:serveur
Vous devez définir plusieurs serveurs sous un nom de site afin de permettre l'équilibrage de charge.
La fonction gestionnaire permet d'étendre la fonction d'équilibrage de charge. Avant de lancer la fonction gestionnaire, vérifiez que le système Metric Server est installé sur toutes les machines dont la charge est équilibrée.
Pour démarrer le gestionnaire, tapez la commande suivante :
sscontrol manager start
Les conseillers transmettent au gestionnaire des informations complémentaires sur la capacité à répondre aux demandes des serveurs ayant fait l'objet d'un équilibrage de charge. Chaque conseiller est spécifique à un protocole. Load Balancer fournit de nombreux conseillers. Par exemple, pour lancer le conseiller HTTP pour un nom de site particulier, exécutez la commande suivante :
sscontrol advisor start http nom_site:port
Pour plus d'informations sur l'utilisation des mesures du système et de Metric Server, voir Metric Server.
Si vous démarrez des conseillers, vous pouvez modifier le niveau d'importance donné aux informations fournies par ces derniers (port) et entrant dans les décisions d'équilibrage de la charge. Pour définir le niveau d'importance du nom de site, émettez la commande sscontrol sitename set nom_site proportions. Pour plus d'informations, voir Proportion de l'importance accordée aux données d'état.
Il est recommander d'utiliser Metric Server avec le composant Site Selector. Pour plus d'informations sur la configuration de Metric Server sur tous les serveurs dont Site Selector assure l'équilibrage de charge, voir Metric Server.
Cette section contient des informations pour la configuration d'un démarrage rapide ainsi que des remarques relatives à la planification, et présente les diverses méthodes de configuration du composant Cisco CSS Controller de Load Balancer. Elle se compose des chapitres suivants :
Cet exemple de démarrage rapide montre comment créer une configuration à l'aide du composant Cisco CSS Controller. Cisco CSS Controller fournit des informations de pondération de serveur qui permettent à Cisco CSS Switch d'optimiser la sélection des serveurs lors des décisions d'équilibrage de la charge.
Figure 25. Configuration Cisco CSS Controller simple
Cet exemple de configuration de démarrage rapide nécessite :
Avant de d'effectuer la configuration de cet exemple, procédez aux vérifications suivantes :
Avec Cisco CSS Controller, vous pouvez créer une configuration à l'aide de la ligne de commande ou de l'interface graphique. Pour cet exemple de démarrage rapide, les étapes de configuration s'effectuent via l'invite de commande.
A partir d'une invite, effectuez les opérations ci-dessous.
ccocontrol consultant add SwConsultant-1 address 9.17.32.50 community public
Cette opération vérifie la connectivité à Cisco CSS Switch et vérifie que le nom de communauté en lecture/écriture SNMP fonctionne correctement.
ccocontrol ownercontent add SwConsultant-1:OwnerContent-1 ownername OwnerName-1 contentrule ContentRule-1
Ces valeurs doivent correspondre aux attributs équivalents sur Cisco CSS Switch.
Cisco CSS Controller peut maintenant communiquer avec le commutateur via SNMP et obtenir les informations de configuration nécessaires. Une fois cette procédure effectuée, Cisco CSS Controller contiendra les informations relatives aux services configurés sur Cisco CSS Switch pour le contenu de propriétaire indiqué.
ccocontrol ownercontent metrics SwConsultant-1:OwnerContent-1 activeconn 45 connrate 45 http 10
Cette commande configure les informations de mesure et les proportions à collecter auprès des services pour le calcul de pondération. La somme des proportions de toutes les mesures doit être égale à 100.
ccocontrol consultant start SwConsultant-1
Cette commande lance tous les collecteurs de mesures et démarre les calculs de pondération de service. Cisco CSS Controller communique les résultats de ses calculs de pondération de service à Cisco CSS Switch à l'aide de SNMP.
La configuration de base de Cisco CSS Controller est maintenant terminée.
Vérifiez que la configuration fonctionne :
Pour plus d'informations sur l'utilisation de l'interface graphique de Cisco CSS Controller, voir Interface graphique et Annexe A, Interface graphique utilisateur : Instructions générales.
Le présent chapitre décrit les aspects que l'administrateur de réseau doit prendre en compte avant d'installer et de configurer le composant Cisco CSS Controller.
Le présent chapitre se compose des sections suivantes :
Pour plus d'informations sur les conditions matérielles et logicielles requises, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
Vous avez également besoin des éléments suivants :
Cisco CSS Controller gère une série de consultants de commutateur. Chaque consultant détermine les pondérations des services dont la charge est équilibrée par un seul commutateur. Le commutateur auquel le consultant fournit les pondérations est configuré pour l'équilibrage de charge de contenu. Le consultant utilise le protocole SNMP pour transmettre au commutateur les pondérations calculées. Le commutateur utilise les pondérations reçues pour sélectionner un service pour la règle de contenu dont il équilibre la charge lorsque l'algorithme d'équilibrage de charge est pondéré par permutation circulaire (round-robin). Pour déterminer les pondérations, le consultant utilise un ou plusieurs des éléments d'information suivants :
Pour une description de l'équilibrage de charge par contenu et des informations détaillées sur la configuration du commutateur, reportez-vous au manuel Cisco Content Services Switch Getting Started Guide.
Pour qu'un consultant obtienne les informations dont il a besoin afin de déterminer les pondérations d'un service, les éléments suivants sont nécessaires :
Comme indiqué à la Figure 26, il est possible de connecter le consultant au réseau derrière le ou les commutateurs pour lesquels il fournit des pondérations. Certains paramètres doivent être configurés sur le commutateur, d'autres sur le contrôleur, pour activer la connectivité entre le contrôleur, le commutateur et les services.
Dans la Figure 26 :
Pour des informations détaillées sur la configuration des réseaux VLAN et du routage IP sur le commutateur, reportez-vous au manuel Cisco Content Services Switch Getting Started Guide.
Figure 26. Exemple de consultant connecté derrière les commutateurs
Pour la gestion de Cisco CSS Controller, vous pouvez utiliser l'une des interfaces suivantes :
Pour la gestion à distance, dans la Figure 27 :
Pour des informations détaillées, reportez-vous au manuel Cisco Content Services Switch Getting Started Guide.
La haute disponibilité du contrôleur augmente la tolérance aux pannes de Load Balancer. Conçue avec un souci de haute disponibilité dans la transmission des paquets, la haute disponibilité du contrôleur implique l'exécution simultanée de deux contrôleurs, l'un assurant le rôle de contrôleur principal, l'autre celui de contrôleur secondaire.
Chaque contrôleur est configuré avec les mêmes informations de commutateur et un seul contrôleur est actif à la fois. Ainsi, du fait de la logique de haute disponibilité, seule le contrôleur actif calcule et met à jour les pondérations.
La haute disponibilité du contrôleur communique avec ses partenaires à l'aide de simples paquets UDP (user datagram protocol) transmis via une adresse et un port que l'utilisateur configure. Ces paquets sont utilisés pour l'échange d'informations entre les contrôleurs dans le cadre de la haute disponibilité (accès aux informations) et pour déterminer la disponibilité du contrôleur des partenaires (signaux de présence). Si le contrôleur secondaire détecte que le contrôleur actif est en erreur pour une raison ou une autre, il prend le relais du contrôleur actif défaillant. Le contrôleur secondaire devient alors le contrôleur actif, et commence à calculer les nouvelles pondérations et à mettre à jour le commutateur avec ces nouvelles valeurs.
Outre sur les partenaires, la haute disponibilité peut être configurée sur les cibles accédées. La haute disponibilité des contrôleurs utilise les informations d'accès pour déterminer le contrôleur actif et le contrôleur secondaire. Le contrôleur actif est celui qui peut contacter (par test ping) le plus de cibles et qui est accessible depuis son partenaire.
Pour plus d'informations, voir Haute disponibilité.
Lorsque le consultant détecte qu'un service n'est pas disponible, il met ce service en suspens sur le commutateur pour que ce dernier prenne pas le service en compte lors de l'équilibrage de la charge des demandes. Une fois le service de nouveau disponible, le consultant active le service sur le commutateur pour qu'il soit de nouveau pris en compte dans l'équilibrage de la charge des demandes.
Cisco CSS Controller enregistre des entrées dans les journaux suivants :
Ces journaux se trouvent dans les répertoires suivants :
Vous pouvez définir la taille et le niveau de consignation de chaque journal. Pour plus d'informations, voir Utilisation des journaux Load Balancer.
Avant d'effectuer les opérations décrites dans le présent chapitre, voir Planification de Cisco CSS Controller. Ce chapitre explique comment créer une configuration de base pour le composant Cisco CSS Controller de Load Balancer.
Avant de suivre une des méthodes de configuration décrites dans ce chapitre :
Tableau 13. Tâches de configuration pour le composant Cisco CSS Controller
Tâche | Description | Informations connexes |
---|---|---|
Configuration de la machine Cisco CSS Controller | Conditions requises | Configuration du contrôleur pour les commutateurs Cisco CSS |
Test de la configuration | Confirmation du bon fonctionnement de la configuration | Test de vérification de la configuration |
Trois méthodes permettent de créer une configuration de base pour le composant Cisco CSS Controller de Load Balancer :
C'est la méthode de configuration de Cisco CSS Controller la plus directe. Les procédures décrites dans ce manuel reposent sur l'utilisation de l'invite de commande. Les valeurs des paramètres de commandes doivent être saisies à l'aide de caractères anglais. Les seules exceptions s'appliquent aux noms d'hôte (utilisés, par exemple, dans la commande consultant add) et aux noms de fichiers.
Pour démarrer Cisco CSS Controller à partir de la ligne de commande :
Remarques :
Vous pouvez entrer une version abrégée des paramètres de contrôle ccocontrol. Il suffit d'entrer les lettres spécifiques des paramètres. Ainsi, pour obtenir de l'aide sur la commande file save, vous pouvez entrer ccocontrol he f au lieu de ccocontrol help file.
Pour démarrer l'interface de ligne de commande, entrez ccocontrol afin d'ouvrir une invite ccocontrol.
Pour fermer l'interface de ligne de commande, entrez exit ou quit.
La configuration définie peut-être sauvegardée dans un fichier XML. La configuration peut ainsi être chargée ultérieurement lorsque vous voulez la recréer rapidement.
Pour exécuter le contenu d'un fichier XML (par exemple, monscript.xml), utilisez l'une ou l'autre des commandes suivantes :
ccocontrol file save NomFichierXML
ccocontrol file load NomFichierXML
La commande de chargement (load) n'est utilisable qu'après exécution d'une commande file save.
Les fichiers XML sont sauvegardés dans le répertoire ...ibm/edge/lb/servers/configurations/cco/.
Pour des instructions générales et un exemple de l'interface graphique, voir Figure 41.
Pour démarrer l'interface graphique, procédez comme suit :
ccoserver.
Pour configurer le composant Cisco CSS Controller à partir de l'interface graphique :
Vous pouvez utiliser l'interface graphique pour toute opération effectuée via la commande ccocontrol. Exemple :
Pour exécuter une commande à partir de l'interface graphique, procédez comme suit :
Les résultats et l'historique des commandes exécutées lors de la session courante s'affichent dans la fenêtre Résultats.
Vous pouvez accéder à l'Aide en cliquant sur le point d'interrogation situé dans l'angle supérieur droit de la fenêtre Load Balancer.
Pour plus d'informations sur l'utilisation de l'interface graphique, voir Annexe A, Interface graphique utilisateur : Instructions générales.
La configuration de la machine Cisco CSS Controller ne peut être effectuée que par le superutilisateur (pour les systèmes AIX, HP-UX, Linux ou Solaris) ou l'administrateur (pour les systèmes Windows).
Le consultant doit pouvoir se connecter à Cisco CSS Switch en tant qu'administrateur Cisco CSS Switch.
Lors de la configuration du consultant, vous devez configurer une adresse et un nom de communauté SNMP qui correspondent aux attributs équivalents de Cisco CSS Switch.
Pour obtenir une aide sur les commandes utilisées lors de cette procédure, voir le Guide des commandes Cisco CSS Controller.
Si ccoserver ne s'exécute pas déjà, entrez ccoserver en tant que superutilisateur pour le démarrer.
Entrez ccocontrol pour démarrer l'interface de ligne de commande.
Vous devez configurer le nom de communauté SNMP et l'adresse du commutateur. Ces valeurs doivent correspondre aux attributs équivalents sur Cisco CSS Switch.
Pour ajouter un consultant, entrez :
consultant add ID_consultant_commutateur address adresse_IP_commutateur community nom_communauté
Un contenu de propriétaire est une représentation d'une règle de contenu pour un propriétaire, défini sur Cisco CSS Switch. Le nom du propriétaire et le nom de la règle de contenu doivent être définis de la même manière que sur le commutateur.
Pour définir un contenu de propriétaire, entrez :
ownercontent add ID_consultant_commutateur:ID_contenu_propriétaire ownername nom_propriétaire contentrule nom_règle_contenu
Une fois le contenu de propriétaire défini, le consultant complète la configuration en récupérant les services configurés sur le commutateur. Comparez la configuration sur le commutateur et sur le consultant pour vous assurer que les services correspondent.
Les mesures permettent de déterminer les pondérations des services et les proportions associées (importance d'une mesure par rapport à une autre), et peuvent être toute combinaison de mesures de données de connexion, de mesures de conseiller d'application et de mesures de serveur de mesures. La somme des proportions doit toujours être égale à 100.
Lorsque le contenu de propriétaire est configuré, les mesures par défaut définies sont activeconn et connrate. Si vous voulez des mesures supplémentaires ou différentes des mesures par défaut, entrez :
ownercontent metrics ID_consultant_commutateur:ID_contenu_propriétaire mesure1 NiveauImportance1 mesure2 NiveauImportance2...mesureN NiveauImportanceN
Pour démarrer le consultant, entrez :
consultant start ID_consultant_commutateur
Les collecteurs de mesure démarrent et le calcul des pondération commence.
Si les mesures système sont définies à l'étape 5, le serveur de mesures doit être démarré sur les machines de service. Pour plus d'informations sur le serveur de mesures, voir Metric Server.
Pour configurer la haute disponibilité, entrez :
highavailability add address adresse_IP partneraddress adresse_IP port 80 role principal
Dans un environnement à haute disponibilité, vous pouvez configurer plusieurs commutateurs. Pour garantir que les informations de pondération sont encore disponibles lorsqu'un commutateur prend le relais d'un autre, Cisco CSS Controller doit être configuré de manière à fournir les pondérations de tous les commutateurs et de leurs homologues de secours.
Pour des informations détaillées sur l'emploi et la configuration de la haute disponibilité des composants Controller, voir Fonctions avancées de Cisco CSS Controller et Nortel Alteon Controller.
Vérifiez que la configuration fonctionne :
Cette section contient des informations pour la configuration d'un démarrage rapide ainsi que des remarques relatives à la planification, et présente les diverses méthodes de configuration du composant Nortel Alteon Controller de Load Balancer. Elle se compose des chapitres suivants :
Cet exemple de démarrage rapide montre comment créer une configuration à l'aide du composant Nortel Alteon Controller. Nortel Alteon Controller fournit les pondérations des serveurs à Nortel Alteon Web Switch. Ces pondérations sont utilisées afin de sélectionner des serveurs pour des services dont le commutateur équilibre la charge.
Figure 28. Configuration Nortel Alteon Controller simple
Cet exemple de configuration de démarrage rapide nécessite :
Avant de d'effectuer la configuration de cet exemple, procédez aux vérifications suivantes :
Avec Nortel Alteon Controller, vous pouvez créer une configuration à l'aide de la ligne de commande ou de l'interface graphique. Pour cet exemple de démarrage rapide, les étapes de configuration s'effectuent via l'invite de commande.
A partir d'une invite, effectuez les opérations ci-dessous.
nalcontrol consultant add Consultant-1 address 9.87.32.50
Cette opération vérifie la connectivité à Nortel Alteon Web Switch et vérifie que les noms de communauté SNMP fonctionnent correctement.
nalcontrol service add Consultant-1:Service-1 vsid 1 vport 80
Nortel Alteon Controller communiquera avec le commutateur via SNMP et obtiendra de celui-ci les informations de configuration nécessaires. Une fois cette procédure effectuée, Nortel Alteon Controller contiendra les informations relatives aux serveurs configurés sur Nortel Alteon Web Switch pour le service.
nalcontrol service metrics Consultant-1:Service-1 http 40 activeconn 30 connrate 30
Cette commande configure les informations de mesure à collecter auprès des serveurs et l'importance relative de ces mesures lors du calcul des pondérations.
nalcontrol consultant start Consultant-1
Cette commande lance tous les collecteurs de mesures et démarre les calculs de pondération de serveur. Nortel Alteon Controller communique les résultats de ses calculs de pondération de serveur à Nortel Alteon Web Switch à l'aide de SNMP.
La configuration de base de Nortel Alteon Controller est maintenant terminée.
Vérifiez que la configuration fonctionne :
Pour plus d'informations sur l'utilisation de l'interface graphique de Nortel Alteon Controller, voir Interface graphique et Annexe A, Interface graphique utilisateur : Instructions générales.
Le présent chapitre décrit les aspects que l'administrateur de réseau doit prendre en compte avant d'installer et de configurer le composant Nortel Alteon Controller.
Le présent chapitre se compose des sections suivantes :
Pour plus d'informations sur les conditions matérielles et logicielles requises, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
Vous avez également besoin des éléments suivants :
Nortel Alteon Controller gère une série de consultants de commutateur. Chaque consultant détermine les pondérations des serveurs dont la charge est équilibrée par un seul commutateur. Le commutateur auquel le consultant fournit les pondérations est configuré pour l'équilibrage de charge de contenu. Le consultant utilise le protocole SNMP pour transmettre au commutateur les pondérations calculées. Le commutateur utilise les pondérations reçues pour sélectionner un serveur pour le service dont il équilibre la charge. Pour déterminer les pondérations, le consultant utilise un ou plusieurs des éléments d'information suivants :
Pour une description de l'équilibrage de la charge des serveurs et des informations détaillées sur la configuration du commutateur, reportez-vous au manuel "Nortel Alteon Web OS Application Guide".
Pour qu'un consultant obtienne les informations dont il a besoin afin de déterminer les pondérations d'un serveur, les éléments suivants sont nécessaires :
Le consultant peut être connecté au réseau devant ou derrière le ou les commutateurs pour lesquels il fournit des pondérations. Certains paramètres doivent être configurés sur le commutateur, d'autres sur le contrôleur, pour activer la connectivité entre le contrôleur, le commutateur et les serveurs.
Dans la Figure 29 :
Pour des informations détaillées sur la configuration des réseaux VLAN et du routage IP sur le commutateur, reportez-vous au manuel "Nortel Alteon Web OS Application Guide" ou au Guide des commandes.
Figure 29. Exemple de consultant connecté derrière le commutateur
Dans la Figure 30 :
Figure 30. Exemple de consultant connecté via un intranet situé devant le commutateur
Pour la gestion de Nortel Alteon Controller, vous pouvez utiliser l'une des interfaces suivantes :
Dans la Figure 31 :
Lorsqu'un consultant calcule les pondérations des serveurs qui fournissent un service dont la charge est équilibrée par un commutateur, ce consultant désactive la vérification normale de l'état des serveurs sur le commutateur afin de réduire tout trafic inutile vers les serveurs. Le consultant réactive la vérification d'état lorsqu'il arrête de fournir des pondérations pour le service. L'intervalle de vérification de l'état d'un serveur est défini par la variable MIB slbNewCgRealServerPingInterval.
Lorsque le consultant détecte qu'un serveur n'est pas disponible, il fixe le nombre maximum de connexions du serveur à zéro pour que le commutateur ne prenne pas le serveur en compte lorsqu'il équilibre la charge des demandes. Lorsque le serveur est de nouveau disponible, le nombre maximum de connexions revient à sa valeur d'origine. Le nombre maximum de connexions d'un serveur est défini par la variable MIB slbNewCfgRealServerMaxCons.
Lorsqu'une pondération est calculée pour un serveur réel, elle est définie pour le serveur. La valeur de pondération d'un serveur est définie par la variable MIB slbNewCfgRealServerWeight.
le commutateur permet de configurer certains serveurs en tant que serveurs de secours pour les autres. Lorsque le commutateur détecte qu'un serveur doté d'un serveur de secours n'est pas disponible, il peut commencer à envoyer les demandes à ce serveur de secours. Lorsque le consultant calcule les pondérations pour un service doté d'un serveur de secours, il effectue ce calcul à la fois pour les serveurs principaux et pour les serveurs de secours de sorte qu'il dispose des pondérations requises lorsque la sélection d'un serveur de secours s'avère nécessaire.
La pondération d'un serveur de secours peut être plus élevée que celle d'un serveur principal. En effet, aucune demande ne lui étant transmise, sa charge est faible tant que le commutateur ne l'utilise pas.
Pour éviter les serveurs inactifs, les serveurs d'un service sont généralement les serveurs de secours des serveurs d'un autre service. Lors de la mise en oeuvre d'une configuration de ce type, évitez d'affecter les mêmes serveurs réels à plusieurs services simultanément actifs. Si cela se produit, le consultant remplace la pondération du serveur pour chaque service dont le serveur fait partie.
Chaque serveur réel est identifié par un entier et dispose d'un attribut de pondération et d'adresse IP. Deux serveurs réels peuvent avoir la même adresse IP. Auquel cas, les deux serveurs réels sont associés au même serveur physique. Les serveurs réels identifiés comme serveurs de secours ne peuvent être configurés comme tels que pour un seul service. Si les mêmes serveurs physiques assurent la sauvegarde de serveurs affectés à plusieurs services, ils doivent être configurés une fois pour chaque service et recevoir une identification de serveur propre à chaque service. Les serveurs de secours ont ainsi une pondération unique affectée pour chaque service service dont ils assurent la sauvegarde.
Figure 32. Exemple de consultant configuré avec des serveurs de secours
Les serveurs d'un commutateur peuvent être configurés comme appartenant à plusieurs groupes et les groupes du commutateur configurés pour prendre en charge plusieurs services.
Comme il est possible de configurer le même serveur pour plusieurs services, la pondération est calculée pour chaque service auquel le serveur participe. La pondération peut donc parfois être incorrecte car le service pour lequel elle est prévue n'est pas connu en permanence.
De plus, si le consultant détermine les pondérations pour un service et pas pour un autre, il est possible que la vérification de l'état des serveurs soit désactivée sur le service pour lequel le consultant ne calcule pas les pondérations. Dans ce cas, le commutateur risque de ne pas correctement équilibrer la charge de ce service.
En conséquence, vous devez vous assurer qu'un serveur réel n'a pas été affecté à plusieurs services dont la charge est équilibrée. Cela ne signifie pas qu'un même serveur ne peut pas traiter les demandes de plusieurs services, mais qu'un serveur réel ayant un seul identificateur doit être configuré sur le commutateur de chaque service dont le serveur gère les demandes.
Nortel Alteon Controller et Nortel Alteon Web Switch intègrent des fonctions de haute disponibilité.
Vous pouvez configurer deux contrôleurs pour s'exécuter sur différents systèmes dans une configuration de secours automatique.
Deux commutateurs ou plus peuvent se servir mutuellement de serveur de secours lorsque vous les configurez en tant que routeur d'interface IP virtuelle (VIR) ou de routeur de serveur IP virtuel (VSR).
Un consultant (géré par le contrôleur) fournit des pondérations pour un commutateur uniquement. Un commutateur de secours pouvant prendre le relais du commutateur principal, vous devez configurer le contrôleur avec un consultant pour chaque commutateur ayant la possibilité de devenir le commutateur principal. De cette manière, lorsqu'un commutateur devient le principal, vous avez la garantie qu'il reçoit le pondérations requises.
En outre, lorsque les contrôleurs sont connectés à un VIR, ils peuvent communiquer avec les serveurs, les commutateurs et le contrôleur de secours, même s'ils perdent la connectivité à l'un des commutateurs.
Pour des informations détaillées sur la haute disponibilité au niveau du commutateur, reportez-vous au manuel "Nortel Alteon Web OS Application Guide".
La haute disponibilité du contrôleur augmente la tolérance aux pannes de Load Balancer. Conçue avec un souci de haute disponibilité dans la transmission des paquets, la haute disponibilité du contrôleur implique l'exécution simultanée de deux contrôleurs, l'un assurant le rôle de contrôleur principal, l'autre celui de contrôleur secondaire.
Chaque contrôleur est configuré avec les mêmes informations de commutateur. Comme avec la haute disponibilité classique, un seul contrôleur est actif à la fois. Ainsi, du fait de la logique de haute disponibilité, seule le contrôleur actif calcule et met à jour les pondérations.
La haute disponibilité du contrôleur communique avec ses partenaires à l'aide de simples paquets UDP (user datagram protocol) transmis via une adresse et un port que l'utilisateur configure. Ces paquets sont utilisés pour l'échange d'informations entre les contrôleurs dans le cadre de la haute disponibilité (accès aux informations) et pour déterminer la disponibilité du contrôleur des partenaires (signaux de présence). Si le contrôleur secondaire détecte que le contrôleur actif est en erreur pour une raison ou une autre, il prend le relais du contrôleur actif défaillant. Le contrôleur secondaire devient alors le contrôleur actif, et commence à calculer les nouvelles pondérations et à mettre à jour le commutateur avec ces nouvelles valeurs.
Outre sur les partenaires, la haute disponibilité peut être configurée sur les cibles accédées. Comme avec la haute disponibilité classique, la haute disponibilité des contrôleurs utilise les informations d'accès pour déterminer le contrôleur actif et le contrôleur secondaire. Le contrôleur actif est celui qui peut contacter (par test ping) le plus de cibles et qui est accessible depuis son partenaire.
Pour plus d'informations, voir Haute disponibilité.
Dans la Figure 33 :
Figure 33. Exemple de haute disponibilité de Nortel Alteon Controller et Nortel Alteon Web Switch
Pour ne pas avoir à modifier trop souvent les pondérations, vous pouvez configurer un seuil de sensibilité pour le consultant. Le seuil de sensibilité indique la quantité de modifications requises entre la nouvelle et l'ancienne pondérations pour que la pondération soit changée. Pour plus d'informations, voir Seuil de sensibilité.
Si le commutateur est trop occupé à mettre à jour des pondérations, vous pouvez augmenter la durée d'inactivité du consultant pour réduire le trafic entre le contrôleur et les serveurs plus le commutateur. La durée d'inactivité fixe le nombre de secondes entre chaque cycle de définition des pondérations.
Si les serveurs gèrent trop de demandes de surveillance provenant du consultant, vous pouvez modifier la du rée d'inactivité des collecteurs de mesures. Pour plus d'informations, voir Délai d'inactivité dans le calcul des pondérations.
Cisco CSS Controller enregistre des entrées dans les journaux suivants :
Ces journaux se trouvent dans les répertoires suivants :
Vous pouvez définir la taille et le niveau de consignation de chaque journal. Pour plus d'informations, voir Utilisation des journaux Load Balancer.
Avant d'effectuer les opérations décrites dans le présent chapitre, voir Planification de Nortel Alteon Controller. Ce chapitre explique comment créer une configuration de base pour le composant Nortel Alteon Controller de Load Balancer.
Avant de suivre une des méthodes de configuration décrites dans ce chapitre, vérifiez que Nortel Alteon Web Switch et tous les serveurs sont correctement configurés.
Tableau 14. Tâches de configuration pour le composant Nortel Alteon Controller
Tâche | Description | Informations connexes |
---|---|---|
Configuration de Nortel Alteon Web Switch et des serveurs | Configuration du commutateur. | Configuration du commutateur, page (SETSWITCH) |
Configuration de la machine Nortel Alteon Controller | Configuration du contrôleur. | Etape 1. Démarrage de la fonction serveur |
Test de la configuration | Confirmation du bon fonctionnement de la configuration | Test de vérification de la configuration |
Trois méthodes permettent de créer une configuration de base pour le composant Nortel Alteon Controller de Load Balancer :
C'est la méthode de configuration de Nortel Alteon Controller la plus directe. Les procédures décrites dans ce manuel reposent sur l'utilisation de l'invite de commande.
Pour démarrer Nortel Alteon Controller à partir de la ligne de commande :
.Remarques :
Vous pouvez utiliser une version abrégée des paramètres de la commande nalcontrol en entrant simplement la ou les quelques lettres d'identification des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, vous pouvez entrer nalcontrol he f au lieu de nalcontrol help file.
Pour fermer l'interface de ligne de commande, entrez exit or quit.
Remarques :
La configuration définie peut-être sauvegardée dans un fichier XML. La configuration peut ainsi être chargée ultérieurement lorsque vous voulez la recréer rapidement.
Pour exécuter le contenu d'un fichier XML (par exemple, monscript.xml), utilisez les commandes suivantes :
nalcontrol file save NomFichierXML
La commande de chargement (load) n'est utilisable qu'après exécution d'une commande file save.
nalcontrol file load NomFichierXML
La commande de chargement (load) n'est utilisable qu'après exécution d'une commande file save.
Les fichiers XML sont sauvegardés dans le répertoire ...ibm/edge/lb/servers/configurations/nal/.
Pour avoir un exemple de l'interface graphique, voir Figure 41.
Pour démarrer l'interface graphique, procédez comme suit :
Pour configurer le composant Nortel Alteon Controller à partir de l'interface graphique :
Vous pouvez utiliser l'interface graphique pour toute opération effectuée via la commande nalcontrol. Exemple :
Pour exécuter une commande à partir de l'interface graphique, procédez comme suit :
Les résultats et l'historique des commandes exécutées lors de la session courante s'affichent dans la fenêtre Résultats.
Vous pouvez accéder à l'aide en cliquant sur le point d'interrogation situé dans l'angle supérieur droit de la fenêtre Load Balancer.
Pour plus d'informations sur l'utilisation de l'interface graphique, voir Annexe A, Interface graphique utilisateur : Instructions générales.
Pour obtenir une aide sur les commandes utilisées lors de cette procédure, voir Guide des commandes Nortel Alteon Controller.
Avant de configurer la machine Nortel Alteon Controller :
Si nalserver ne s'exécute pas déjà, entrez nalserver en tant que superutilisateur pour le démarrer.
Entrez nalcontrol pour démarrer l'interface de ligne de commande.
Pour ajouter un consultant de commutateur, entrez :
consultant add ID_consultant_commutateur address adresse_IP_commutateur
Pour ajouter un service, entrez :
service add ID_consultant_commutateur:ID_service vsid ID_serveur_virtuel vport numéro_port_virtuel
Un service est identifié par un identificateur de serveur virtuel (VSID) et un numéro de port virtuel (VPORT), tous deux associés à un serveur virtuel précédemment configuré sur le commutateur.
Les mesures sont les informations permettant de déterminer les pondérations des serveurs. A chaque mesure est affectée un niveau d'importance indiquant son importance par rapport aux autres mesures. Vous pouvez configurer toute combinaison de mesures : mesures de données de connexion, mesures de conseiller d'application et mesures de serveur de mesures. La somme des proportions doit toujours être égale à 100.
Lorsqu'un service est configuré, les mesures par défaut définies sont activeconn et connrate. Si vous voulez des mesures supplémentaires ou différentes des mesures par défaut, entrez :
service metrics ID_consultant_commutateur:ID_service nom_mesure 50 nom_mesure2 50
Pour démarrer le consultant, entrez :
consultant start ID_consultant_commutateur
Les collecteurs de mesure démarrent et le calcul des pondération commence.
Pour configurer la haute disponibilité, entrez :
highavailability add address adresse_IP partneraddress adresse_IP port 80 role principal
Pour des informations détaillées sur l'emploi et la configuration de la haute disponibilité des composants Controller, voir Fonctions avancées de Cisco CSS Controller et Nortel Alteon Controller.
Si les mesures système sont définies à l'étape 5, le serveur de mesures doit être démarré sur les machines de service. Pour plus d'informations sur le serveur de mesures, voir Metric Server.
Modifier la configuration de Nortel Alteon Web Switch permet de régénérer la configuration du contrôleur. Entrez :
service refresh
Avant de régénérer la configuration, arrêtez le consultant. Une fois la configuration mise à jour, redémarrez le consultant.
Vérifiez que la configuration fonctionne :
Cette section contient des informations relatives aux fonctions et fonctions avancées disponibles de configuration de Load Balancer. Elle se compose des chapitres suivants :
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.
Tableau 15. 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 :
| 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 le niveau d'importance relatif des quatre valeurs sur la base d'un cluster (ou nom de site). Les proportions correspondent à des pourcentages ; la somme des proportions relatives 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 obtenir une description de l'option fixedweight, voir Pondérations fixées par l'administrateur.
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, exécutez 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 avez fixée pour un serveur particulier, utilisez l'option fixedweight de la commande dscontrol server. Exemple :
dscontrol server set cluster:port:serveur 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 reste fixe tant que le gestionnaire est en activité à moins que vous n'émettiez 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, exécutez 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, exécutez 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), exécutez 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, exécutez 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 d'installation, ...ibm/edge/lb/servers/samples, contient des exemples de script que vous pouvez personnaliser. Pour pouvoir exécuter les fichiers, vous devez les déplacer dans le répertoire ...ibm/edge/lb/servers/bin 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.
Restriction relative à l'utilisation des serveurs 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.
Pour les systèmes HP-UX et Solaris, restriction relative à l'utilisation des 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 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_personnalisé 80Cette commande lance le conseiller ADV_personnalisé 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 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_personnalisé clusterB:80
dscontrol advisor stop ADV_personnalisé 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, exécutez 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, exécutez 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 l'erreur serveur la plus 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, exécutez 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
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 d'arrière-plan 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_Network_Dispatcher_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 et rassemble des informations de statut de chargement sur les serveurs d'arrière-plan.
Figure 34. Exemple de 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 d'arrière-plan 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 répartiteur 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 ...ibm/edge/lb/ms/script de Load Balancer.
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 (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 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_sample.java, est fourni avec le produit
Load Balancer. Une fois Load Balancer installé, le code exemple se trouve
dans le répertoire d'installation
...<rép-
install>/servers/samples/CustomAdvisors.
Le répertoire d'installation par défaut est :
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 conseillers personnalisés 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 ê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_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.
Exemple de commande de compilation sous Windows :
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 .class dans le répertoire d'installation ...ibm/edge/lb/servers/lib/CustomAdvisors.
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é :
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_fred.class
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 natifs. S'il ne trouve pas un conseiller donné, Load Balancer consulte la liste des conseillers personnalisés du client.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Program Files\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 ...ibm/edge/lb/servers/samples/CustomAdvisors .
Cette fonction est disponible pour tous les composants Load Balancer.
Metric Server fournit à Load Balancer les informations de téléchargement, sous la forme de données numériques système, relatives à l'état 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 de 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 d'arrière-plan) 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, "monScriptSystemMetric.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 ...ibm/edge/lb/ms/script. 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.
Sous Windows : Vous devez également affecter un alias à AUTRE_ADRESSE dans la pile Microsoft de la machine Metric Server. 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.
Le présent chapitre explique comment configurer les paramètres d'équilibrage de charge et comment installer les fonctions avancées de Load Balancer.
Tableau 16. Tâches de configuration avancées pour Load Balancer
Tâche | Description | Informations connexes |
---|---|---|
Placement de Load Balancer sur une machine dont il équilibre la charge | Installation d'une machine Load Balancer co-implantée. | Utilisation de serveurs implantés au même endroit |
Configuration de la haute disponibilité ou de la haute disponibilité réciproque | Installe une deuxième répartiteur comme répartiteur de secours. | Haute disponibilité |
Configuration d'un équilibrage de charge basé sur des règles | Définition des conditions sous lesquelles un sous-ensemble donné de serveurs est utilisé. | Configuration d'un équilibrage de charge basé sur des règles |
Utilisation de la substitution d'affinité de port pour fournir au serveur un dispositif de remplacement de la fonction de maintien de routage de port. | Permet à un serveur de remplacer sur son port les paramètres de maintien de routage. | substitution d'affinité de port |
Utilisation de la fonction de maintien de routage (affinité) pour fidéliser un port de cluster. | Permet aux demandes clients d'être acheminées vers le même serveur. | Fonctionnement de la fonction d'affinité pour Load Balancer |
Utilisation de l'affinité de ports croisés pour étendre la fonction de maintien de routage (affinité) aux autres ports. | Permet aux demandes clients reçues par des ports différents d'être dirigées vers le même serveur. | Affinité de ports croisés |
Utilisation du masque d'adresse d'affinité pour désigner une adresse de sous-réseau IP commune. | Permet aux demandes clients reçues par le même sous-réseau d'être dirigées vers un même serveur. | Masque d'adresse de l'affinité (masque de maintien de routage) |
Utilisation de l'affinité de cookie actif pour l'équilibrage de charge des serveurs pour le composant CBR | Option de règle permettant de conserver l'affinité pour un serveur particulier. | Affinité de cookie actif |
Utilisation de l'affinité de cookie pour le routage en fonction du contenu de Dispatcher et le composant CBR | Option de règle permettant de conserver l'affinité pour un serveur particulier en fonction de la valeur nom du cookie/cookie. | Affinité de cookie passif |
Utilisation de l'affinité d'URI pour effectuer l'équilibrage de charge au sein des serveurs Caching avec un contenu unique à placer en mémoire cache sur chaque serveur | Option de règle permettant de conserver l'affinité pour un serveur particulier en fonction de l'URI. | Affinité d'URI |
Configuration du support de réseau étendu pour Dispatcher | Installe une répartiteur distante pour l'équilibrage de charge sur un réseau étendu. Ou effectue l'équilibrage de charge dans un réseau étendu (sans Dispatcher distant) à l'aide d'une plateforme de serveur prenant en charge GRE. | Configuration du support de réseau étendu pour Dispatcher |
Utilisation de liens explicites | Evitez d'ignorer Dispatcher dans vos liens. | Utilisation de liens explicites |
Utilisation d'un réseau privé | Configurez le répartiteur (Dispatcher) pour qu'il assure l'équilibrage de charge des serveurs sur un réseau privé. | Utilisation d'une configuration réseau privée |
Utilisation d'un cluster générique pour combiner des configurations serveur communes | Les adresses non explicitement configurées utiliseront le cluster générique pour équilibrer le trafic. | Utilisation d'un cluster générique pour combiner les configurations serveurs |
Utilisation d'un cluster générique pour équilibrer la charge des pare-feux. | La totalité du trafic sera équilibré sur les pare-feux. | Utilisation du cluster générique pour équilibrer la charge des pare-feux |
Utilisation d'un cluster générique avec Caching Proxy pour le proxy transparent | Permet d'utiliser Dispatcher pour activer un proxy transparent. | Utilisation d'un cluster générique avec Caching Proxy pour le proxy transparent |
Utilisation du port générique pour acheminer le trafic destiné à un port non configuré | Prend en charge le trafic qui n'est configuré pour aucun port particulier. | Utilisation du port générique pour acheminer le trafic destiné à un port non configuré |
Utilisation de la détection de "refus de service" pour indiquer aux administrateurs (via une alerte) des attaques éventuelles | Dispatcher analyse les demandes entrantes d'un certain nombre de connexions partielles sur les serveurs. | Détection d'attaque de refus de service |
Utilisation de la consignation binaire pour analyser les statistiques des serveurs. | Permet d'enregistrer les informations sur les serveurs dans des fichiers binaires et d'extraire ces informations. | Utilisation de la consignation binaire pour analyser les statistiques des serveurs |
Utilisation d'une configuration de client co-implanté | Autoriser Load Balancer à résider sur la même machine qu'un client | Utilisation d'un client co-implanté |
Load Balancer peut se trouver sur la même machine qu'un serveur pour lequel il équilibre la charge des demandes. On parle alors de co-implantation d'un serveur. La co-implantation s'applique aux composants Dispatcher et Site Selector. Elle est également prise en charge pour le composant CBR, mais uniquement avec des serveurs Web et un serveur Caching Proxy de type serveur de liaison.
Systèmes Linux : Pour configurer simultanément la co-implantation et la haute disponibilité lors de l'exécution du composant Dispatcher avec la méthode d'acheminement MAC, voir Solutions alternatives pour l'affectation d'alias à l'unité de bouclage sous Linux lors de l'utilisation de la méthode d'acheminement MAC de Load Balancer.
Systèmes Windows : Pour configurer simultanément la co-implantation et la haute disponibilité lors de l'exécution du composant Dispatcher avec la méthode d'acheminement MAC, voir Configuration de la co-implantation et de la haute disponibilité (systèmes Windows).
Systèmes Solaris : Dans cet environnement, vous ne pouvez pas configurer de conseillers WAN lorsque le point d'entrée est co-implanté. Voir Utilisation de conseillers distants avec le support de réseau étendu de Dispatcher.
Dans les versions précédentes, il était nécessaire de préciser que l'adresse du serveur co-implanté devait être la même que l'adresse de non-acheminement (NFA) dans la configuration. Cette restriction a maintenant été éliminée.
Pour configurer un serveur afin qu'il soit co-implanté, la commande dscontrol server propose l'option collocated qui peut être oui ou non. La valeur par défaut est non. L'adresse du serveur doit être une adresse IP valide d'une carte d'interface réseau sur la machine. Le paramètre collocated ne doit pas être défini pour les serveurs co-implantés à l'aide de la méthode d'acheminement NAT ou CBR de Dispatcher.
Vous pouvez configurer un serveur co-implanté de l'une des manières suivantes :
Pour l'acheminement NAT ou CBR de Dispatcher, vous devez configurer (alias) une adresse NFA de carte réseau inutilisée. Le serveur doit être configuré pour écouter cette adresse. Configurez le serveur en utilisant la syntaxe de commande suivante :
dscontrol server add cluster:port:nouvel_alias address nouvel_alias router ip_routeur returnaddress adresseretour
Si vous n'effectuez pas cette configuration, des erreurs système risquent de se produire et le serveur peut ne pas répondre.
Lorsque vous configurez un serveur co-implanté avec la méthode d'acheminement NAT de Dispatcher, le routeur spécifié dans la commande dscontrol server add doit correspondre à une adresse de routeur réelle et non à l'adresse IP du serveur.
Vous pouvez désormais configurer la prise en charge de la co-implantation sur tous les systèmes d'exploitation lors de la configuration de la méthode d'acheminement NAT de Dispatcher si vous exécutez les étapes suivantes sur la répartiteur :
arp -s hostname ether_addr pub
en utilisant l'adresse MAC locale pour ether_addr. L'application peut ainsi envoyer le trafic à l'adresse de retour du noyau.
Le composant CBR prend en charge la co-implantation sur toutes les plateformes sans qu'il soit nécessaire de procéder à des configurations supplémentaires. Vous devez toutefois utiliser des serveurs Web et Caching Proxy de liaison.
Site Selector prend en charge la co-implantation sur toutes les plateformes sans qu'aucune configuration supplémentaire ne soit requise.
La fonction de haute disponibilité (configurable avec la commande dscontrol highavailability) est disponible pour le composant Dispatcher (mais pas pour les composants CBR et Site Selector).
Pour améliorer la disponibilité de Dispatcher, la fonction de haute disponibilité de Dispatcher utilise les mécanismes suivants :
Au moins une des paires de signaux de présence doit utiliser si possible un sous-réseau différent du trafic classique du cluster. Un trafic distinct de signaux de présence permet d'éviter les faux relais lors des fortes charges réseau et d'améliorer les temps de reprise totale.
La syntaxe complète de la commande dscontrol highavailability est fournie dans la section dscontrol highavailability -- Contrôle de la haute disponibilité.
Pour plus d'informations sur les tâches détaillées ci-dessous, voir Configuration de la machine Dispatcher.
dscontrol highavailability heartbeat add adresse_source adresse_destination
Machine principale (primary) - highavailability heartbeat add 9.67.111.3 9.67.186.8 machine de secours (backup) - highavailability heartbeat add 9.67.186.8 9.67.111.3Au moins, une des paires de signaux de présence doit disposer des NFA de la paire en tant qu'adresse source et de destination.
Au moins une des paires de signaux de présence doit utiliser si possible un sous-réseau différent du trafic classique du cluster. Un trafic distinct de signaux de présence permet d'éviter les faux relais lors des fortes charges réseau et d'améliorer les temps de reprise totale.
Définit le nombre de secondes nécessaires à l'exécuteur pour arrêter les signaux de présence de disponibilité pour dépassement du délai d'expiration. Exemple :
dscontrol executor set hatimeout 3
La valeur par défaut est de 2 secondes.
dscontrol highavailability reach add 9.67.125.18Les cibles à atteindre sont recommandées mais pas obligatoires. Pour plus d'informations, voir Détections des incidents en utilisant signal de présence et cible à atteindre.
dscontrol highavailability backup add primary [auto | manual] port
dscontrol highavailability backup add backup [auto | manual] port
dscontrol highavailability backup add both [auto | manual] port
dscontrol highavailability statusChacune des machines doit avoir le rôle (principal, secondaire ou les deux), les états et sous-états qui conviennent. La machine principale doit être active et synchronisée ; la machine de secours doit être en mode veille et se synchroniser rapidement avec l'autre. Les deux stratégies doivent être identiques.
dscontrol cluster set clusterA hôte_principal dispatcherNFA1 dscontrol cluster set clusterB hôte_principal dispatcherNFA2
dscontrol cluster set clusterB hôte_principal dispatcherNFA2 dscontrol cluster set clusterA hôte_principal dispatcherNFA1
Remarques :
Outre les critères de détection d'incidents de base (perte de connectivité entre le système Dispatcher de secours et le système Dispatcher 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 Dispatcher, vous pouvez indiquer une liste d'hôtes auxquels chaque système Dispatcher doit pouvoir accéder pour fonctionner correctement. Les deux partenaires en haute disponibilité sont toujours en contact par l'intermédiaire de signaux de présence et ils se communiquent le nombre de cibles à contacter auxquelles ils peuvent chacun accéder (via la commande ping). Si le serveur en attente parvient à accéder à un plus grand nombre de cibles à contacter (via la commande ping) que le serveur actif, une reprise survient.
Les signaux de présence sont envoyés par la répartiteur active et doivent être reçus par la répartiteur en veille toutes les demi secondes. Si la répartiteur en veille ne parvient pas à recevoir un signal de présence dans les 2 secondes, une reprise survient. Une reprise n'est effectuée par la répartiteur de secours que si tous les signaux de présence échouent. En d'autres termes, lorsque deux paires de signaux de présence sont configurées, les deux signaux de présence doivent échouer. Pour stabiliser un environnement en haute disponibilité et éviter les reprises, ajoutez plusieurs paires de signaux de présence.
Pour les cibles à contacter, vous devez choisir au moins un hôte pour chaque sous-réseau que la répartiteur utilise. Il peut s'agir de systèmes hôtes tels que les routeurs, les 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. La reprise 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 répartiteur de secours que par la répartiteur principale. Pour prendre la décision sur la base de toutes les informations disponibles, le répartiteur actif envoie régulièrement au répartiteur de secours ses données d'accessibilité. La répartiteur de secours compare ensuite ces données aux siennes, puis décide de procéder ou non au basculement.
Deux machines Dispatcher sont configurées : la machine principale et une deuxième machine appelée machine de sauvegarde (ou de secours). Au démarrage, la machine principale transmet toutes les données de connexion à la machine de secours afin d'obtenir une parfaite synchronisation. La machine principale devient active, c'est-à-dire qu'elle commence l'équilibrage de charge. Parallèlement, la machine de secours contrôle l'état de la machine principale et conserve l'état de veille.
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 principale et devient, à son tour, la machine active. Une fois la machine principale redevenue opérationnelle, les machines se comportent selon la stratégie de reprise après incident définie par l'utilisateur. Il existe deux types de stratégie :
La stratégie définie doit être identique pour les deux machines.
La stratégie de reprise manuelle oblige l'utilisateur à forcer le routage des paquets vers une machine spécifique, à l'aide de la commande "takeover". La reprise manuelle s'avère utile lorsque l'autre machine doit subir des opérations de maintenance. La stratégie de reprise automatique est conçue pour un fonctionnement normal sans surveillance.
Dans le cas d'une configuration à haute disponibilité réciproque, il n'existe pas de défaillance par cluster. Si l'une des machines est victime d'une défaillance, même si celle-ci ne concerne qu'un des clusters, l'autre machine prendra le relais pour chacun des deux clusters.
Pour que Dispatcher puisse acheminer les paquets de données, chaque adresse de cluster doit posséder un alias la reliant à une interface réseau.
Pour plus d'informations sur l'association d'alias à la carte d'interface réseau, voir Etape 5. Affectation d'un alias à la carte d'interface réseau.
Dans la mesure où les machines Dispatcher changent d'état lorsqu'une défaillance est détectée, les commandes citées plus haut doivent être lancées automatiquement. Dispatcher exécutera des scripts créés par l'utilisateur pour le faire. Le répertoire ...ibm/edge/lb/servers/samples contient des scripts exemple qui doivent être déplacés dans le répertoire ...ibm/edge/lb/servers/bin pour s'exécuter. Les scripts s'exécutent automatiquement uniquement si dsserver est en cours d'exécution.
Remarques :
Les scripts exemples suivants peuvent être utilisés :
Sur les systèmes Windows : Si, dans votre configuration, Site Selector équilibre la charge de deux machines Dispatcher fonctionnant en environnement à haute disponibilité, vous devrez définir un alias pour les systèmes Metric Server dans la pile Microsoft des systèmes Metric Server. Insérez cet alias dans le script goActive. Exemple :
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
Supprimez les alias des scripts goStandby et goInOp. Exemple :
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
Si la machine est équipée de plusieurs cartes d'interface réseau, vérifiez dans un premier temps l'interface à utiliser en entrant la commande suivante au niveau de l'invite : netsh interface ip show address. Elle renvoie la liste des interfaces configurées et le numéro de la connexion au réseau local (par exemple, "Local Area Connection 2") permettant de déterminer celle à utiliser.
Sous Linux pour S/390(R) : Dispatcher génère automatiquement un protocole de résolution d'adresse ATM pour transférer les adresses IP d'une machine Dispatcher vers une autre. Ce mécanisme est donc lié au type de réseau sous-jacent. Lors de l'exécution de Linux pour S/390, Dispatcher ne peut effectuer des reprises en haute disponibilité de manière native (complètes avec transferts d'adresse IP) que sur les interfaces qui peuvent générer automatiquement un protocole de résolution d'adresse ATM et configurer l'adresse sur l'interface locale. Ce mécanisme ne fonctionne pas sur les interfaces point à point telles qu'IUCV et CTC et ne fonctionne pas correctement dans certaines configurations de qeth/QDIO.
Pour les interfaces et configurations dans lesquelles la fonction de reprise IP native de Dispatcher ne fonctionne pas correctement, le client peut insérer les commandes appropriées dans les scripts go pour transférer manuellement les adresses. Ces topologies réseau peuvent ainsi également bénéficier de la haute disponibilité.
Il est possible de configurer à la fois la haute disponibilité et la co-implantation sur les serveurs Windows. Des étapes supplémentaires sont toutefois nécessaires pour configurer ensemble ces fonctionnalités Load Balancer sur des systèmes Windows.
Sur les systèmes Windows, lorsque vous utilisez la co-implantation avec la haute disponibilité, vous avez besoin d'une adresse IP supplémentaire (espèce d'adresse IP factice) qui peut être ajoutée à l'adaptateur de bouclage sur le système Windows. L'adaptateur de bouclage doit être installé sur les machines principale et de secours. Pour installer le périphérique de bouclage sur les systèmes Windows, suivez les étapes décrites dans Configuration des serveurs pour l'équilibrage de la charge.
Lorsque les étapes vous invitent à ajouter l'adresse IP de cluster au bouclage, vous devez ajouter une adresse IP factice, et non l'adresse du cluster. En effet, les scripts go* à haute disponibilité pour les systèmes Windows doivent supprimer, puis ajouter l'adresse du cluster au périphérique de bouclage, selon que la machine Load Balancer est active ou de secours.
Les systèmes Windows ne permettent pas de supprimer la dernière adresse IP configurée du périphérique de bouclage car ce dernier ne fonctionne pas en mode DHCP. L'adresse factice permet à Load Balancer de supprimer à tout moment son adresse de cluster. L'adresse IP factice ne sera pas utilisée pour n'importe quel type de trafic et peut servir sur les machines actives ou de secours.
Mettez à jour et déplacez les scripts go* de Load Balancer sur les machines actives et de secours, puis démarrez Dispatcher. L'adresse du cluster est ajoutée, puis supprimée de l'interface réseau et du périphérique de bouclage aux moments opportuns.
Vous pouvez utiliser un équilibrage basé sur des règles pour déterminer de manière précise quand et pourquoi des paquets sont envoyés à des serveurs et quels sont ces serveurs. Load Balancer parcourt toute les règles que vous ajoutez, de la première à la dernière priorité et s'arrête sur la première règle vérifiée avant d'équilibrer la charge en fonction du contenu entre les serveurs associés à cette règle. Ils équilibrent déjà la charge en fonction de la destination et du port, mais l'utilisation de règles permet d'étendre votre capacité à répartir les connexions.
Dans la plupart des cas lors de la configuration de règles, vous devez configurer une règle par défaut toujours vraie afin d'intercepter les demandes provenant des autres règles de priorité élevée. Il peut s'agir d'une réponse du type "Désolé, ce site est actuellement inaccessible. Faites une nouvelle tentative ultérieurement" lorsque tous les autres serveurs ne peuvent pas traiter la demande client.
Vous devez utiliser l'équilibrage de charge dépendant des règles avec Dispatcher et Site Selector lorsque vous voulez utiliser un sous-ensemble de serveurs pour une raison quelconque. Vous devez toujours utiliser des règles pour le composant CBR.
Vous pouvez sélectionner les types de règles suivants :
Planifiez la logique à suivre par les règles avant de commencer à ajouter des règles à votre configuration.
Toutes les règles possèdent un nom, un type, une priorité et peuvent avoir une valeur de début et une valeur de fin ainsi qu'un ensemble de serveurs. En outre, à la règle de type contenu du composant CBR est associée une structure d'expression standard. (Pour obtenir des exemples et des scénarios sur le mode d'utilisation de la règle de contenu et la syntaxe de motif valide pour la règle de contenu, voir Annexe B, Syntaxe de règle de contenu (modèle).)
Les règles sont évaluées en fonction de leur priorité : en d'autres termes, une règle de priorité 1 (nombre le moins élevé) avant une règle de priorité 2 (nombre plus élevé). La première règle vérifiée est utilisée. Lorsqu'une règle est vérifiée, aucune autre règle n'est évaluée.
Pour qu'une règle soit vérifiée, elle doit remplir deux conditions :
Si aucun serveur n'est associé à une règle, cette dernière ne doit remplir que la première condition pour être vérifiée. Dans ce cas, Dispatcher abandonne la demande de connexion, Site Selector renvoie la demande de serveur de nom avec une erreur et CBR provoque une page d'erreur Caching Proxy.
Si aucune règle n'est vérifiée, Dispatcher sélectionne un serveur parmi l'ensemble des serveurs disponibles du port, Site Selector sélectionne un serveur parmi l'ensemble des serveurs disponibles sur le nom du site et CBR provoque l'affichage d'une page d'erreur par Caching Proxy.
Ce type de règle est disponible dans le composant Dispatcher, CBR ou Site Selector.
Vous pouvez souhaiter utiliser des règles basées sur l'adresse IP des clients pour trier les clients et leur affecter des ressources en fonction de leur provenance.
Par exemple, vous constatez la présence sur le réseau d'un nombre important de transmissions impayées et donc indésirables en provenance de clients appartenant à un ensemble spécifique d'adresses IP. Vous créez donc une règle à l'aide de la commande dscontrol rule , par exemple :
dscontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
Cette règle "ni" permet de trier les connexions des clients indésirables. Ajoutez ensuite à la règle les serveurs qui doivent être accessibles, ou si vous n'ajoutez pas de serveurs à la règle, les demandes provenant des adresses 9.x.x.x ne sont pas transmises par l'un de vos serveurs.
Ce type de règle est disponible uniquement avec le composant Dispatcher.
Vous pouvez souhaiter utiliser des règles basées sur le port client lorsque vos clients utilisent un type de logiciel nécessitant un port spécifique de TCP/IP lors des demandes.
Vous pouvez, par exemple, créer une règle spécifiant que toute demande dont le port client est 10002, doit utiliser un ensemble de serveurs rapides spéciaux car vous savez que les demandes client associées à ce port proviennent d'un groupe de clients privilégiés.
Ce type de règle est disponible dans le composant Dispatcher, CBR ou Site Selector.
Vous pouvez souhaiter utiliser des règles basées sur l'heure en vue de la planification des pondérations. Si par exemple votre site Web est surchargé chaque jour pendant les mêmes créneaux horaires, il est préférable de dédier cinq serveurs supplémentaires aux heures de pointe.
Ce type de règle est également intéressant lorsque vous voulez arrêter certains serveurs chaque jour à minuit, pour des raisons de maintenance. Dans ce cas, vous pouvez définir une règle qui exclut ces serveurs pendant la période de maintenance nécessaire.
Ce type de règle est disponible uniquement avec le composant Dispatcher.
Vous pouvez souhaiter utiliser des règles fondées sur le contenu du champ "type de service" (TOS) de l'en-tête IP. Par exemple, si la valeur TOS d'une demande client entrante indique un service normal, cette demande peut être routée vers un ensemble de serveurs. Si une autre demande arrive, munie cette fois d'une valeur TOS différente indiquant une priorité de service élevée, elle peut être dirigée vers un autre ensemble de serveurs.
La règle TOS permet de configurer entièrement chacun des bits de l'octet TOS en utilisant la commande dscontrol rule. Utilisez 0 ou 1 pour les bits importants que vous souhaitez apparier dans l'octet TOS. La valeur x est utilisée par défaut. Voici un exemple d'ajout d'une règle TOST :
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
Ce type de règle est disponible dans les composants Dispatcher et CBR.
Vous pouvez souhaiter utiliser des règles basées sur le nombre de connexions par seconde lorsque vous devez partager certains serveurs avec d'autres applications. Vous pouvez, par exemple, définir deux règles :
Vous pouvez aussi utiliser Telnet et vouloir lui réserver deux des cinq serveurs, sauf lorsque le nombre de connexions par seconde dépasse un certain niveau. Ainsi, Dispatcher équilibre la charge entre les cinq serveurs, pendant les heures de pointe.
Définition de l'option d'évaluation de règle "upserversonrule" avec la règle de type "connexion" : Si, lorsque vous utilisez la règle de type connexions et définissez l'option upserversonrule, certains serveurs de l'ensemble de serveurs sont inactifs, vous pouvez préserver les serveurs actifs d'une surcharge. Pour plus d'informations, voir Option d'évaluation de serveur.
Ce type de règle est disponible dans le composant Dispatcher ou CBR.
Vous pouvez souhaiter utiliser des règles basées sur le nombre total de connexions actives d'un port lorsque les serveurs sont surchargés et commencent à ignorer certains paquets. Dans ce cas, certains serveurs Web continuent d'accepter les connexions même s'ils ne disposent pas d'un nombre suffisant d'unités d'exécution pour répondre à la demande. Il en résulte que le poste client réclame un certain délai de temporisation et que le client accédant à votre site Web n'est pas servi. Vous pouvez utiliser des règles basées sur le nombre de connexions actives pour équilibrer les pondérations d'un pool de serveurs.
Par exemple, vous savez par expérience que les serveurs arrêteront leur service après avoir accepté 250 connexions. Vous pouvez créer une règle à l'aide de la commande dscontrol rule ou cbrcontrol rule, par exemple :
dscontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 ou cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
Vous pouvez ensuite ajouter à la règle vos serveurs en cours plus d'autres serveurs qui, autrement seraient utilisés pour d'autres processus.
Les règles de largeur de bande réservée et partagée sont disponibles uniquement dans le composant Dispatcher.
Pour les règles de largeur de bande, Dispatcher calcule la largeur de bande en tant que débit auquel les données sont délivrées aux clients par un ensemble de serveurs spécifique. Dispatcher effectue le suivi de la capacité aux niveaux du serveur, de la règle, du port, du cluster et de l'exécuteur. Pour chacun de ces niveaux, il existe une zone compteur d'octets : les kilo-octets transmis par seconde. Dispatcher calcule ces débits sur un intervalle de 60 secondes. Vous pouvez consulter ces valeurs de débit dans l'interface ou dans la sortie d'un rapport de ligne de commande.
La règle de largeur de bande réservée permet de contrôler le nombre de kilo-octets délivrés par seconde à un ensemble de serveurs. En définissant un seuil (définition d'une plage de largeur de bande précise) pour chaque ensemble de serveurs dans la configuration, vous pouvez contrôler et garantir le montant de la largeur de bande utilisé par chaque combinaison cluster-port.
Voici un exemple d'ajout de règle de largeur de bande réservée :
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
Les valeurs de début et de fin sont indiquées en kilo-octets par seconde.
Avant de configurer la règle de largeur de bande partagée, vous devez indiquer la quantité maximale de largeur de bande (kilo-octets par seconde) pouvant être partagée au niveau de l'exécuteur ou du cluster à l'aide de la commande dscontrol executor ou dscontrol cluster avec l'option sharedbandwidth. La valeur sharebandwidth ne doit pas dépasser la largeur totale de bande (capacité réseau totale) disponible. L'utilisation de la commande dscontrol pour définir la largeur de bande partagée ne fournit qu'une limite maximale pour la règle.
Voici des exemples de la syntaxe de la commande.
dscontrol executor set sharedbandwidth taille dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth taille
La taille de l'option sharedbandwidth correspond à une valeur entière (kilo-octets par seconde). La valeur par défaut est zéro. Si la valeur est zéro, la bande passante ne peut pas être partagée.
Le partage de la largeur de bande au niveau du cluster permet au cluster d'utiliser une largeur de bande maximale indiquée. Tant que la largeur de bande utilisée par le cluster est inférieure à la quantité indiquée, cette règle est respectée (true). Lorsque la largeur totale de bande utilisée dépasse la quantité indiquée, cette règle n'est plus respectée (false).
Le partage de la largeur de bande au niveau de l'exécuteur permet à toute la configuration Dispatcher de partager une quantité maximale de largeur de bande. Tant que la largeur de bande utilisée au niveau de l'exécuteur est inférieure à la quantité indiquée, cette règle est respectée (true). Lorsque la largeur totale de bande utilisée dépasse la quantité définie, cette règle n'est plus respectée (false).
Ci-dessous, se trouvent des exemples d'ajout ou de définition d'une règle sharedbandwidth.
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel valeur dscontrol rule set 9.20.34.11:80:shrule sharelevel valeur
La valeur de l'option sharelevel est soit exécuteur, soit cluster. Sharelevel est un paramètre requis dans la règle sharebandwidth
Dispatcher permet d'attribuer une largeur de bande indiquée à des ensembles de serveurs dans votre configuration à l'aide de la règle largeur de bande réservée. En précisant un début et une fin de plage, vous pouvez contrôler la plage de kilo-octets livrée aux clients par un ensemble de serveurs. Dès que la règle n'est plus vraie (limite de plage dépassée), la règle de priorité inférieure suivante est appliquée. S'il s'agit d'une règle "toujours vraie", un serveur peut être sélectionné pour envoyer une réponse "site occupé" au client.
Prenons, par exemple, un groupe de trois serveurs sur le port 2222. Si la largeur de bande réservée est fixée à 300, le nombre maximal de kilo-octets par seconde est 300, sur une durée de 60 secondes. Lorsque ce débit est excédé, la règle n'est plus respectée. Si cette règle est la seule, Dispatcher sélectionne l'un des trois serveurs pour traiter la demande. S'il existe une règle "toujours vraie" de priorité inférieure, la demande est dirigée vers un autre serveur et reçoit la réponse "site occupé".
La règle de largeur de bande partagée offre aux clients l'accès à des serveurs supplémentaires. Plus précisément, lorsqu'elle est utilisée comme règle de priorité inférieure faisant suite à une règle de largeur de bande réservée, un client peut encore accéder à un serveur lorsque la largeur de bande réservée a été dépassée.
Par exemple, si vous placez une règle de largeur de bande partagée après une règle de largeur de bande réservée, vous permettez aux clients d'accéder à trois serveurs de manière contrôlée. Tant qu'il reste de la largeur de bande réservée à utiliser, la règle est vraie et l'accès accordé. Lorsqu'il ne reste plus de largeur de bande réservée disponible, cette règle n'est plus vraie et la suivante est appliquée. Si la règle suivante est une règle "toujours vraie", la demande est au besoin dirigée vers un autre serveur.
En utilisant les règles de largeur de bande réservée et partagée comme indiqué dans l'exemple ci-dessus , permet plus de souplesse et de contrôle au niveau des accords (ou refus) d'accès aux serveurs. Les serveurs d'un port particulier peuvent se voir attribuer une largeur de bande limitée, tandis que d'autres peuvent utiliser autant de largeur de bande que disponible.
Ce type de règle est disponible uniquement avec le composant Site Selector.
Pour la règle Mesure de tous les serveurs, vous choisissez une mesure système (cpuload, memload ou votre propre script de mesure système personnalisé) et Site Selector compare la valeur de mesure système (renvoyée par l'agent du système Metric Server se trouvant dans chaque serveur d'équilibrage de charge) avec les valeurs de début et de fin indiquées dans la règle. La valeur de mesure de tous les serveurs de l'ensemble de serveurs doit être définie dans la plage afin que la règle puisse s'exécuter.
Ci-dessous, se trouve un exemple d'ajout de mesure à toutes les règles de la configuration.
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
Ce type de règle est disponible uniquement avec le composant Site Selector.
Pour la règle Moyenne des mesures, vous choisissez une mesure système (cpuload, memload ou votre propre script de mesure système personnalisé) et Site Selector compare la valeur de mesure système (renvoyée par l'agent du système Metric Server se trouvant dans chaque serveur d'équilibrage de charge) avec les valeurs de début et de fin indiquées dans la règle. La moyenne des valeurs des mesures système de tous les serveurs de l'ensemble de serveurs doit être définie dans la plage pour que la règle puisse s'exécuter.
Ci-dessous, se trouve un exemple d'ajout de règle de moyenne des mesures à votre configuration.
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
Ce type de règle est disponible dans le composant Dispatcher, CBR ou Site Selector.
Une règle peut être créée comme règle "toujours vraie." Ces règle seront toujours sélectionnées, sauf si tous les serveurs associés sont arrêtés. Pour cette raison, leur niveau de priorité est généralement inférieur à celui de autres règles.
Vous pouvez même avoir plusieurs règles "toujours vraies", chacune d'elles associée à un ensemble de serveurs. La première règle vérifiée pour laquelle un serveur est disponible est choisie. Supposons par exemple que vous disposiez de six serveurs. Vous voulez que deux d'entre eux traitent le trafic quelles que soient les circonstances, à moins qu'ils soient tous les deux arrêtés. Si les deux premiers serveurs sont arrêtés, vous voulez qu'un deuxième jeu de serveurs traite le trafic. Enfin, si les quatre serveurs sont arrêtés, vous utiliserez les deux derniers pour traiter le trafic. Vous pouvez définir trois règles "toujours vraie". Le premier jeu de serveurs est toujours choisi, tant que l'un d'eux est actif. Si les deux serveurs sont arrêtés, l'un des serveurs du deuxième jeu est choisi, etc.
Autre exemple : il se peut que vous vouliez une règle "toujours vraie" pour garantir que les clients entrants qui ne remplissent aucune des règles définies ne sont pas pris en charge. Il vous faut donc créer, à l'aide de la commande dscontrol rule, la règle suivante :
dscontrol rule add 130.40.52.153:80:jamais type true priority 100
Vous n'ajoutez alors pas de serveur à cette règle, ce qui provoque l'abandon sans réponse des paquets des clients.
Vous pouvez définir plusieurs règles "toujours vraies", puis choisir ensuite celle qui doit être exécutée en modifiant les niveaux de priorité.
Ce type de règle est disponible dans le composant CBR ou Dispatcher (lorsque vous utilisez la méthode d'acheminement CBR de Dispatcher).
Vous pouvez utiliser des règles basées sur le contenu pour envoyer des demandes à des ensembles de serveurs spécialement configurés pour prendre en charge une partie du trafic de votre site. Par exemple, vous pouvez utiliser un ensemble de serveurs pour la prise en charge de toutes les demandes cgi-bin, un autre pour les demandes audio, et un troisième pour toutes les autres demandes. Vous pouvez ajouter une règle dont la structure correspond au chemin d'accès du répertoire cgi-bin, une autre correspondant au type de vos fichiers audio, et une troisième règle "toujours vraie" pour prendre en charge le reste du trafic. Vous ajouterez ensuite les serveurs appropriés à chaque type de règle.
Important : Pour obtenir des exemples et des scénarios sur le mode d'utilisation de la règle de contenu et la syntaxe de motif valide pour la règle de contenu, voir Annexe B, Syntaxe de règle de contenu (modèle).
La substitution d'affinité de port permet le remplacement du maintien de routage du port d'un serveur spécifique. Par exemple, dans le cas où vous utilisez une règle pour limiter le nombre de connexions alloué à chaque serveur d'application et disposez d'un serveur de débordement à règle fixe qui annonce "please try again later" à propos de cette application. Le délai du maintien de routage du port est de 25 minutes et vous ne souhaitez pas que le client soit maintenu sur ce serveur. La substitution d'affinité de port vous permet alors de changer de serveur de débordement afin de remplacer l'affinité qui est habituellement associée à ce port. Ainsi, les demandes ultérieures du client destinées au cluster seront transmises au serveur d'applications ayant le plus de disponibilités et non pas au serveur de débordement, afin d'équilibrer la charge.
Pour plus d'informations sur la syntaxe de commande de la substitution d'affinité de port, en utilisant l'option de serveur maintien de routage, voir dscontrol server -- Configuration des serveurs.
Vous pouvez ajouter des règles à l'aide de la commande dscontrol rule add , en modifiant le fichier de configuration exemple ou en utilisant l'interface graphique. Vous pouvez ajouter une ou plusieurs règles à chaque port que vous avez défini.
Il s'agit d'une procédure en deux étapes : vous devez ajouter la règle, puis définir les serveurs sur lesquels les services doivent être effectués si la règle est vraie. Supposons par exemple que l'administrateur système veuille déterminer le taux d'utilisation des serveurs proxy pour chaque division du site. Une adresse IP est octroyée à chaque division. Créez le premier jeu de règles en fonction des adresses IP des clients pour séparer les charges individuelles de chaque division :
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
Ajoutez ensuite un serveur distinct à chaque règle, puis mesurez la charge de chaque serveur pour facturer correctement les divisions en fonction des services qu'elles utilisent. Exemple :
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
L'option d'évaluation de serveur est disponible uniquement dans le composant Dispatcher.
La commande dscontrol rule a une option d'évaluation de serveur pour les règles. L'option evaluate permet de choisir d'évaluer les conditions de la règle parmi tous les serveurs du port ou d'évaluer les conditions de la règle des serveurs faisant partie de la règle. (Dans les versions précédentes de Load Balancer, il n'était possible de mesurer que la condition de chaque règle parmi tous les serveurs du port.)
Remarques :
Ci-dessous, se trouvent des exemples d'ajout ou de définition de l'option d'évaluation au niveau d'une règle de largeur de bande réservée.
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate niveau dscontrol rule set 9.22.21.3:80:rbweval evaluate niveau
Vous pouvez attribuer la valeur port, règle ou upserversonrule au niveau d'évaluation. La valeur par défaut est port.
L'option permettant de mesurer les conditions de la règle dans les serveurs de la règle permet de configurer deux règles ayant les caractéristiques suivantes :
Par conséquence, lorsque le trafic dépasse le seuil des serveurs dans la première règle, le trafic est envoyé au serveur "site occupé" dans la deuxième règle. Lorsque le trafic est inférieur au seuil des serveurs de la première règle, le trafic reprend pour les serveurs de la première règle.
Lors de l'utilisation des deux règles décrites dans l'exemple précédent, si vous attribuez l'option port à l'option d'évaluation pour la première règle (évaluation des conditions de la règle dans tous les serveurs du port), lorsque le trafic dépasse la limite de cette règle, le trafic est envoyé au serveur "site occupé" associé à la deuxième règle.
La première règle mesure l'ensemble du trafic du serveur (incluant le serveur "site occupé") sur le port afin de déterminer si le trafic a dépassé la limite. Alors que la surcharge diminue pour les serveurs associés à la première règle, le trafic se poursuit sur le serveur "site occupé" étant donné que le trafic sur ce port dépasse toujours la limite de la première règle.
Pour les composants Dispatcher et CBR : Vous activez la fonction d'affinité lorsque vous faites en sorte que le maintien de routage d'un port de clusters soit conservé. Lorsque vous configurez un port de cluster de telle sorte que le routage soit conservé, les demandes clients peuvent être dirigées vers le même serveur. Cette opération peut être effectuée en attribuant un nombre de secondes à l'option délai de maintien de routage au niveau de l'exécuteur, du cluster ou du port. Lorsque vous attribuez la valeur zéro au délai de maintien de routage, cette fonction est désactivée.
Lors de l'activation de l'affinité de ports croisés, les valeurs de délai de maintien de routage des ports partagés doit avoir la même valeur (différente de zéro). Pour plus d'informations, voir Affinité de ports croisés.
Pour le composant Site Selector : Vous activez la fonction d'affinité lorsque vous faites en sorte que le maintien de routage d'un nom de site soit conservé. La configuration du maintien de routage pour un nom de site permet au client d'utiliser le même serveur pour plusieurs requêtes de service annuaire. Cette opération peut être effectuée en attribuant un nombre de secondes à l'option délai de maintien de routage sur le nom de site. Lorsque vous attribuez la valeur zéro au délai de maintien de routage, cette fonction est désactivée.
Le délai de maintient de routage pour un serveur est le délai entre la fermeture d'une connexion et l'ouverture d'une nouvelle connexion au cours de laquelle un client est renvoyé au même serveur utilisé lors de la première connexion. Passé le délai de maintien de routage, le client peut être envoyé à un serveur autre que le premier. Ce délai est configuré à l'aide de la commande dscontrol executor, port ou cluster.
Lorsque l'affinité est désactivée, dès qu'une connexion TCP est reçue d'un client, Load Balancer utilise le serveur correct et lui transmet les paquets. Si une autre connexion arrive du même client, Load Balancer la traite comme si les deux connexions n'étaient pas liées et utilise à nouveau le serveur correct.
Lorsque l'affinité est activée, si une autre demande est reçue du même client, la demande est acheminée vers le même serveur.
Progressivement, le client arrête d'envoyer des transactions et l'enregistrement d'affinité disparaît. D'où l'importance du "délai" de maintien de routage. La durée de vie de chaque enregistrement d'affinité est déterminée en secondes par le "délai de maintien de routage". Lorsque des demandes suivantes sont reçues lors du délai de maintien de routage, l'enregistrement d'affinité est toujours valide et la demande est toujours acheminée vers le même serveur. Si aucune connexion supplémentaire n'est reçue lors du délai de maintien de routage, l'enregistrement est vidé. Un nouveau serveur sera sélectionné pour toute connexion reçue une fois ce délai écoulé.
La commande server down (dscontrol server down) est utilisée pour arrêter un serveur. Ce dernier ne s'arrête pas tant que le délai de maintien de routage n'arrive pas à expiration.
L'affinité de ports croisés s'applique uniquement aux méthodes d'acheminement MAC et NAT/NATP du composant Dispatcher.
L'affinité de ports croisés se définit comme l'extension à plusieurs ports de la fonction maintien de routage. Par exemple, si la demande d'un client est d'abord reçue par un port puis une deuxième demande de ce client par un autre port, l'affinité de ports croisés permet au répartiteur d'envoyer cette demande au même serveur. Pour utiliser cette fonction, les ports doivent :
Il est possible de relier plusieurs ports au même trans ports. Quand un même client se connectera, à l'avenir, sur le même port ou sur un port partagé, ses connexions seront traitées par le même serveur. Voici un exemple de configuration de ports multiples munis d'une affinité de ports croisés au port 10 :
dscontrol port set cluster:20 crossport 10 dscontrol port set cluster:30 crossport 10 dscontrol port set cluster:40 crossport 10
Après l'établissement de l'affinité de ports croisés, vous disposez de la possibilité de modifier le délai de maintien de routage du port. Il est cependant recommandé de choisir la même valeur pour tous les délais de maintien de routage des ports partagés. Dans le cas contraire, des résultats inattendus peuvent se produire.
Pour supprimer l'affinité de ports croisés, replacez la valeur trans ports sur son propre numéro de port. Voir dscontrol port -- Configuration des ports, pour plus d'informations sur la syntaxe de commande de l'option trans ports.
Le masque d'adresse de l'affinité ne s'applique qu'au composant Dispatcher.
Le masque d'adresse de l'affinité est une amélioration de la fonction de maintien de routage, destinée aux clients de groupe situés à des adresses de sous-réseau communes. La sélection du masque de maintien de routage de la commande dscontrol port permet de masquer les bits communs à poids fort de l'adresse IP sur 32 bits. Si cette fonction est configurée, lors de la première connexion d'un client à un port, toutes les connexions suivantes des clients ayant la même adresse de sous-réseau (indiquée par la partie masquée de l'adresse) seront dirigées vers le même serveur.
Par exemple, si vous souhaitez que toutes les demandes client disposant d'une adresse de réseau classe A identique soient envoyées au même serveur, fixez à 8 (bits) la valeur du port du masque de maintien de routage. En ce qui concerne les demandes de clients de groupe possédant la même adresse de réseau classe B, fixez la valeur du masque de maintien de routage à 16 (bits). Pour les demandes de clients de groupe disposant de la même adresse de réseau classe C, fixez la valeur du masque de maintien de routage à 24 (bits).
Pour obtenir de meilleurs résultats, fixez la valeur du masque de maintien de routage dès le lancement de Load Balancer. Si vous modifiez cette valeur, les résultats seront imprévisibles.
Interaction avec l'affinité de ports croisés : Lors de l'activation de l'affinité de ports croisés, les valeurs de délai de maintien de routage des ports partagés doivent avoir la même valeur (différente de zéro). Pour plus d'informations, voir Affinité de ports croisés.
Pour activer le masque d'adresse d'affinité, émettez une commande dscontrol port du type :
dscontrol port set cluster:port stickytime 10 stickymask 8
Les valeurs possibles des masques de maintien de routage sont 8, 16, 24 et 32. Une valeur de 8 indique que les 8 premiers bits à poids fort de l'adresse IP (adresse de réseau classe A) seront masqués. Une valeur de 16 indique que les 16 premiers bits à poids fort de l'adresse IP (adresse de réseau classe B) seront masqués. Une valeur de 24 indique que les 24 premiers bits à poids fort de l'adresse IP (adresse de réseau classe C) seront masqués. Si vous spécifiez une valeur de 32, l'adresse IP toute entière sera masquée, ce qui entraînera la désactivation de la fonction de masque d'adresse d'affinité. La valeur par défaut du masque de maintien de routage est 32.
Voir dscontrol port -- Configuration des ports, pour plus d'informations sur la syntaxe de commande du masque de maintien de routage (fonction de masque d'adresse d'affinité).
La mise au repos de la gestion des connexions s'applique aux composants Dispatcher et CBR.
Pour retirer un serveur de la configuration Load Balancer quelle qu'en soit la raison (mises à jour, mises à niveau, service, etc), vous pouvez utiliser la commande dscontrol manager quiesce. La sous-commande quiesce permet aux connexions de s'achever (sans avoir été traitées) et transmet les connexions ultérieures du client vers le serveur mis au repos si la connexion est associée à un délai de maintien de routage et que ce dernier n'est pas arrivé à expiration. La sous-commande quiesce désactive toute nouvelle connexion au serveur.
Utilisez l'option "Mettre au repos maintenant" si le délai de maintien de routage est défini et que vous voulez que les nouvelles connexions soient envoyées à un autre serveur (et non au serveur mis au repos) avant que le délai de maintien de routage n'expire. Voici un exemple d'utilisation de cette option pour mettre le serveur 9.40.25.67 au repos :
dscontrol manager quiesce 9.40.25.67 now
L'option now détermine comment les options avec maintien de routage seront gérées.
Il s'agit de la manière la moins brusque de placer des serveurs au repos. Par exemple, vous pouvez mettre au repos un serveur puis attendre le moment où le trafic est faible (peut-être le matin) pour retirer complètement le serveur de la configuration.
Vous pouvez définir les types d'affinité suivants dans la commande dscontrol rule :
L'affinité de cookie actif ne s'applique qu'au composant CBR.
L'affinité de cookie passif s'applique au composant CBR et à la méthode d'acheminement CBR du composant Dispatcher.
L'affinité d'URI s'applique au composant CBR et à la méthode d'acheminement CBR du composant Dispatcher.
L'option d'affinité par défaut est "none". La valeur zéro (inactif) doit être associée à l'option stickytime de la commande port pour affecter la valeur de cookie actif ou URI à l'option d'affinité de la commande rule. Lorsque l'affinité de cette dernière est définie, il devient impossible d'activer l'option stickytime de la commande port.
L'affinité de cookie actif ne s'applique qu'au composant CBR.
Elle permet de "fidéliser" les clients à un serveur donné. Pour l'activer, attribuez un nombre positif au paramètre stickytime (délai de maintien de routage) d'une règle et optez pour l'affinité de cookie actif ("activecookie"), lors de l'ajout de la règle ou à l'aide de la commande rule set. Pour obtenir des informations sur la syntaxe de cette commande, voir dscontrol rule -- Configuration des règles.
Lorsqu'une règle a été activée pour l'affinité de cookie actif, l'équilibrage de charge des nouvelles demandes client est effectué à l'aide d'algorithmes CBR standard, tandis que les demandes suivantes du même client sont envoyées au serveur initialement choisi. Le serveur choisi est stocké en tant que cookie dans la réponse au client. Tant que les demandes suivantes du client contiennent ce cookie et qu'elles arrivent dans le délai de maintien de routage, le client conserve l'affinité pour le serveur initial.
L'affinité de cookie actif permet d'assurer qu'un client fait l'objet d'un équilibrage de charge vers le même serveur pendant une période déterminée. A cet effet, un cookie est envoyé pour être stocké par le navigateur des clients. Ce cookie indique les cluster:port:règle adoptés pour la prise de décision, le serveur cible de l'équilibrage de charge et la date d'expiration de l'affinité. Il est au format suivant : IBMCBR=cluster:port:règle+serveur-heure! Les informations cluster:port:règle et serveur sont codées pour ne révéler aucune information sur la configuration CBR.
Lorsqu'une règle est déclenchée et que l'affinité de cookie actif est activée, le cookie envoyé par le client est examiné.
Le nouveau cookie est ensuite inséré dans les en-têtes qui reviennent au client. Le navigateur du client renvoie les demandes suivantes lorsqu'il est configuré pour accepter les cookies.
Chaque instance d'affinité du cookie a une longueur de 65 octets et se termine au point d'exclamation. Ainsi, un cookie de 4096 octets peut contenir environ 60 règles de cookie actif individuel par domaine. Une fois le cookie entièrement plein, les instances d'affinité expirées sont supprimées. Si toutes les instances sont encore valides, les plus anciennes sont supprimées et les nouvelles pour la règle en cours ajoutées.
Pour la commande rule, vous ne pouvez attribuer que la valeur activecookie (cookie actif) à l'option d'affinité de cookie actif lorsque le délai de maintien de routage est zéro (non activé). Lorsque l'affinité de cookie actif est active au niveau d'une règle, vous ne pouvez pas activer le maintien de routage sur le port.
Pour activer l'affinité de cookie actif pour une règle donnée, utilisez la commande rule set :
rule set cluster:port:règle stickytime 60 rule set cluster:port:règle affinity activecookie
Le maintien de routage d'une règle est normalement utilisé pour les interfaces CGI ou les servlets qui enregistrent l'état du client sur le serveur. Cet état est identifié par un ID cookie (cookie serveur). L'état du client figure uniquement sur le serveur sélectionné. Pour maintenir cet état d'une demande à l'autre, le client a besoin du cookie du serveur.
Le délai d'expiration par défaut de l'affinité de cookie actif correspond au délai du serveur auquel s'ajoute le délai de maintien de routage plus vingt-quatre heures. Si les heures sont inexactes sur les systèmes de vos clients (ceux qui envoient des requêtes à la machine CBR), par exemple, s'ils dépassent de plus de 24 heures le délai du serveur), ces systèmes ignorent les cookies provenant de la CBR car ils considèrent que ces cookies ont déjà expiré. Pour rallonger le délai d'expiration, modifiez le script cbrserver. Dans le fichier script, modifiez la ligne javaw en y ajoutant le paramètre suivant après LB_SERVER_KEYS : -DCOOKIEEXPIREINTERVAL=X où X correspond au nombre de jours à ajouter au délai d'expiration.
Sur les systèmes AIX, Solaris et Linux, le fichier cbrserver se trouve dans le répertoire /usr/bin.
Sur les systèmes Windows, le fichier cbrserver se trouve dans le répertoire \winnt\system32.
L'affinité de cookie passif s'applique à la méthode d'acheminement CBR (content-based routing) du composant Dispatcher et au composant CBR. Pour obtenir la procédure de configuration de la méthode d'acheminement CBR de Dispatcher, voir Routage cbr de Dispatcher (méthode d'acheminement cbr).
L'affinité de cookie passif offre une façon de fidéliser les clients à un serveur donné. Lorsque vous attribuez la valeur "cookiepassif" à l'affinité d'une règle, l'affinité de cookie passif permet d'équilibrer la charge du trafic Web destiné au même serveur, en fonction des cookies d'auto-identification générés par les serveurs. Vous configurez l'affinité de cookie passif au niveau de la règle.
Lors du déclenchement de la règle, si l'affinité de cookie passif est activée, Load Balancer choisit le serveur en fonction du nom du cookie se trouvant dans l'en-tête HTTP de la demande client. Load Balancer commence à comparer le nom du cookie dans l'en-tête HTTP du client à la valeur du cookie configurée pour chaque serveur.
La première fois que Load Balancer détecte un serveur dont la valeur de cookie contient le nom de cookie du client, Load Balancer choisit ce serveur pour la demande.
Si le nom du cookie est introuvable dans la demande client ou s'il ne correspond à aucun contenu des valeurs de cookie des serveurs, le serveur est choisi à l'aide de la méthode de sélection existante ou de la technique de permutation circulaire pondérée.
Pour configurer l'affinité de cookie passif :
Pour la commande rule, vous ne pouvez attribuer que la valeur passivecookie (cookie passif) à l'option d'affinité de cookie passif lorsque le délai de maintien de routage est zéro (non activé). Lorsque l'affinité de cookie passif est active au niveau d'une règle, il n'est pas possible d'activer le maintien de routage sur le port.
L'affinité d'URI s'applique à la méthode d'acheminement CBR de Dispatcher et au composant CBR. Pour obtenir la procédure de configuration de la méthode d'acheminement CBR de Dispatcher, voir Routage cbr de Dispatcher (méthode d'acheminement cbr).
L'affinité URI permet d'équilibrer le trafic Web sur des serveurs Caching Proxy, ce qui permet de mettre en mémoire cache un contenu unique sur un serveur spécifique. Ainsi, vous augmentez la capacité de la mémoire cache du site en éliminant les éléments superflus placés en mémoire cache sur plusieurs machines. Configurez l'affinité d'URI au niveau de la règle. Une fois que la règle est déclenchée, si l'affinité d'URI est activée et que le même ensemble de serveurs est actif et répond, Load Balancer transmet les nouvelles demandes client entrantes ayant le même URI au même serveur.
Généralement, Load Balancer peut distribuer des demandes à plusieurs serveurs gérant un contenu identique. Lorsque vous utilisez Load Balancer avec un groupe de serveurs de mise en mémoire cache, le contenu dont l'accès est souvent demandé peut être placé dans la mémoire cache de tous les serveurs. En répliquant le contenu placé en mémoire cache identique, vous pouvez prendre en charge un grand nombre de clients. Cela est particulièrement utile pour les sites Web dont le volume est important.
Cependant, si le site Web prend en charge un trafic client modéré vers un contenu très divers et que vous préférez une mémoire cache répartie sur plusieurs serveurs, votre site sera plus performant si chaque serveur de mise en cache comporte un contenu unique et que Load Balancer distribue la demande uniquement au serveur de mise en cache avec ce contenu.
Avec l'affinité d'URI, Load Balancer vous permet de distribuer le contenu mis en cache vers des serveurs individuels, éliminant la mise en cache superflue de contenu sur plusieurs machines. Grâce à cette fonction, les performances des sites ayant un contenu divers utilisant les serveurs Caching Proxy sont améliorées. Les demandes identiques sont envoyées au même serveur, plaçant ainsi en mémoire cache le contenu uniquement sur les serveurs individuels. La taille de la mémoire cache s'accroît avec chaque nouveau serveur ajouté au pool.
Pour configurer l'affinité d'URI :
Pour la commande rule, vous ne pouvez attribuer que la valeur URI à l'option d'affinité d'URI lorsque le délai de maintien de routage est zéro (non activé). Lorsque l'affinité d'URI est active au niveau d'une règle, il n'est pas possible d'activer le maintien de routage sur le port.
Cette fonction est disponible uniquement pour le composant Dispatcher.
Si vous n'utilisez ni le support de réseau étendu de Dispatcher ni la méthode d'acheminement CBR de Dispatcher, la configuration de Dispatcher requiert que la machine Dispatcher et ses serveurs soient tous connectés au même segment de réseau local (voir la Figure 35). Une demande client arrive à la répartiteur et est envoyée au serveur. Du serveur, la réponse est renvoyée directement au client.
Figure 35. Exemple de configuration consistant en un seul segment de réseau local
La fonction de répartiteur étendu permet la prise en charge des serveurs hors site, appelés serveurs éloignés (voir la Figure 36). Si GRE n'est pas pris en charge sur le site distant et que la méthode d'acheminement NAT de Dispatcher n'est pas utilisée, le site distant doit correspondre à une machine Dispatcher éloignée (Dispatcher 2) et aux serveurs associés localement (Serveur G, Serveur H et Serveur I). Le paquet d'un client passe d'Internet à la répartiteur initiale. Il passe ensuite à un système Dispatcher distant géographiquement et enfin à l'un de ses serveurs locaux.
Tous les systèmes Dispatcher (locaux ou éloignés) doivent exécuter le même type de système d'exploitation et de plateforme pour exécuter des configurations de réseau étendu.
Figure 36. Exemple de configuration utilisant des serveurs locaux et éloignés
Cela permet à une adresse de cluster de supporter l'ensemble des demandes client du monde entier, tout en répartissant la charge entre l'ensemble des serveurs.
Le système Dispatcher qui reçoit le paquet en premier peut tout de même être connecté à des serveurs locaux et répartir la charge entre ses serveurs locaux et les serveurs distants.
Pour configurer un support de réseau étendu :
dscontrol server add cluster:port:serveur router adresse
Pour obtenir plus d'informations sur le mot clé router, voir dscontrol server -- Configuration des serveurs.
Sur les machines Dispatcher servant de point d'entrée :
Les machines Dispatcher servant de point d'entrée et fonctionnant sous AIX, Linux (à l'aide de GRE) ou Solaris affichent correctement les charges des conseillers. Les autres plateformes doivent compter sur l'équilibrage de la charge à l'aide de la technique de permutation circulaire ou utiliser les méthodes de transfert nat/cbr de Dispatcher au lieu d'un réseau étendu.
Systèmes AIX
Systèmes HP-UX
Systèmes Linux
Systèmes Solaris
arp -s mon_adresse_cluster mon_adresse_mac pub
Systèmes Windows
Sur des répartiteurs distants : Exécutez les étapes de configuration suivantes pour chaque adresse de cluster distante. Pour définir une configuration de haute disponibilité à l'emplacement distant du composant Dispatcher, vous devez effectuer l'opération sur les deux systèmes.
Systèmes AIX
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
Systèmes HP-UX, Linux, Solaris et Windows
Figure 37. Exemple de configuration en réseau étendu avec des composants Load Balancer éloignés
Cet exemple s'applique à la configuration illustrée à la Figure 37.
Vous trouverez ci-après la méthode à utiliser pour configurer les machines Dispatcher afin qu'elles supportent l'adresse de cluster xebec sur le port 80. LB1 est défini comme "point d'entrée" Load Balancer. Il est supposé qu'une connexion Ethernet est utilisée. LB1 comporte cinq serveurs définis : trois serveurs locaux (ServeurA, ServeurB, ServeurC) et deux serveurs éloignés (LB2 et LB3). Par ailleurs, trois serveurs locaux ont été définis pour chacun des serveurs distants LB2 et LB3.
Sur la console de la première répartiteur (LB1), procédez comme suit :
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
Sur la console de la deuxième répartiteur (LB2) :
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
Sur la console de la troisième répartiteur (LB3) :
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
GRE (Generic Routing Encapsulation) est un protocole Internet défini dans RFC 1701 et RFC 1702. Lorsque vous utilisez GRE, Load Balancer peut encapsuler les paquets IP de clients dans des paquets IP/GRE et les transmettre aux plateformes de serveur telles qu'OS/390 qui prennent en charge GRE. Le support GRE permet au composant Dispatcher d'équilibrer la charge des paquets sur plusieurs adresses de serveurs associées à une adresse MAC.
Load Balancer implémente GRE en tant qu'élément de sa fonction de réseau étendu. Ainsi, Load Balancer peut fournir l'équilibrage de charge de réseau étendu directement aux systèmes de serveur pouvant désencapsuler les paquets GRE. Il n'est pas nécessaire que Load Balancer soit installé sur le site éloigné si les serveurs éloignés prennent en charge les paquets GRE encapsulés. Load Balancer encapsule les paquets WAN, la valeur décimale 3735928559 étant attribuée à l'ensemble de zones de clés GRE.
Dans cet exemple (Figure 38), afin d'ajouter le serveurD éloigné, qui prend en charge GRE, définissez-le dans la configuration Load Balancer comme si vous définissiez un serveur WAN dans la hiérarchie cluster:port:serveur :
dscontrol server add cluster:port:ServeurD router Routeur1
Les systèmes Linux disposent en natif d'une possibilité d'excapsulation GRE permettant à Load Balancer d'équilibrer la charge d'images de serveur Linux pour S/390, lorsque de nombreuses images de serveur se partagent une adresse MAC. Ainsi, le point d'entrée Load Balancer peut équilibrer la charge directement sur des serveurs Linux WAN sans passer par Load Balancer sur le site éloigné. Les conseillers du point d'entrée Load Balancer peuvent alors traiter directement chaque serveur éloigné.
Sur le point d'entrée Load Balancer, procédez à la configuration décrite pour WAN.
Pour configurer chaque serveur d'arrière-plan Linux, entrez les commandes ci-après en tant que superutilisateur. (Ces commandes peuvent être ajoutées à la fonction de démarrage du système de sorte que les modifications soient conservées entre les réamorçages.)
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add adresse_cluster dev gre-nd
En règle générale, les fonctions d'équilibrage de charge de Dispatcher fonctionnent indépendamment de la physionomie des sites sur lesquels le produit est installé. Il existe cependant une zone dans laquelle le contenu du site peut s'avérer important et dans laquelle les décisions prises au sujet de ce contenu peuvent avoir une influence non négligeable sur l'efficacité de Dispatcher. Il s'agit de la zone d'adressage de liens.
Lorsque vos pages indiquent des liens pointant sur des serveurs individuels de votre site, un client est en réalité forcé à s'adresser à une machine déterminée, détournant de ce fait toute fonction d'équilibrage de charge éventuellement mise en oeuvre. Pour cette raison, utilisez systématiquement l'adresse de Dispatcher dans tous les liens figurant sur vos pages. Il est à noter que le type d'adressage utilisé n'est pas toujours apparent, notamment si votre site applique une procédure de programmation automatique permettant la création dynamique de HTML. Pour optimiser l'équilibrage de charge, identifiez les éventuelles occurrences d'adressage explicite et évitez-les autant que possible.
Vous pouvez configurer Dispatcher et les machines serveurs TCP de sorte qu'ils utilisent un réseau privé. Cette configuration peut réduire l'encombrement des accès utilisateurs ou du réseau externe, susceptible d'affecter les performances.
Pour AIX, cette configuration peut également tirer parti des vitesses élevées du commutateur SP(TM) High Performance Switch, si vous utilisez Dispatcher et les machines serveurs TCP comme noeuds sur un cadre SP.
Pour créer un réseau privé, chaque machine doit être équipée d'au moins deux cartes de réseau local, l'une d'elles étant reliée au réseau privé. La deuxième carte de réseau local doit être également configurée sur un sous-réseau différent. La répartiteur transmettra alors les demandes aux machines serveurs TCP par l'intermédiaire du réseau privé.
Systèmes Windows : Configurez également chaque adresse NFA avec la commande executor configure.
Les serveurs ajoutés à l'aide de la commande dscontrol server add doivent être ajoutés avec les adresses de réseau privé. Par exemple, reprenant le cas du serveur A de la Figure 39, la syntaxe de la commande sera la suivante :
dscontrol server add adresse_cluster:80:10.0.0.1
et non
dscontrol server add adresse_cluster:80:9.67.131.18
Si vous utilisez Site Selector pour fournir des données de charge à Dispatcher, Site Selector doit être configuré pour acheminer ces états vers les adresses privées.
Figure 39. Exemple de réseau privé utilisant Dispatcher
L'utilisation d'une configuration de réseau privé ne s'applique qu'au composant Dispatcher.
L'utilisation d'un cluster générique pour combiner les configurations serveurs ne s'applique qu'au composant Dispatcher.
Le terme "générique" fait référence à l'aptitude du cluster à s'adapter à plusieurs adresses IP (c'est-à-dire à fonctionner comme un "joker"). L'adresse 0.0.0.0 permet d'indiquer un cluster générique.
Si vous devez assurer l'équilibrage de plusieurs adresses de cluster ayant des configurations port/serveur identiques, vous pouvez combiner tous les clusters dans une seule configuration de cluster générique.
Vous devez toujours configurer de manière explicite chaque adresse de cluster sur les cartes réseau de votre poste Dispatcher. Toutefois, vous ne devez ajouter aucune des adresses de cluster à la configuration de Dispatcher à l'aide de la commande dscontrol cluster add.
Ajoutez simplement le cluster générique (adresse 0.0.0.0), et configurez les ports et les serveurs correctement pour l'équilibrage de charge. Tout trafic à destination des adresses configurées sur les cartes est équilibré en utilisant la configuration du cluster générique.
L'avantage de cette approche réside dans le fait que le trafic vers toutes les adresses de clusters est pris en compte lors du choix du meilleur serveur. Si un cluster est particulièrement chargé et qu'il a créé de nombreuses connexions sur l'un des serveurs, le trafic vers les autres adresses de cluster est équilibré en tenant compte de cette information.
Vous pouvez combiner le cluster générique avec des clusters réels si certaines adresses de cluster ont une configuration port/serveur unique alors que d'autres partagent la même configuration. Les configurations uniques doivent être attribuées à une adresse de cluster réelle. Toutes les configurations communes peuvent être attribuée au cluster générique.
L'utilisation du cluster générique pour équilibrer la charge des pare-feux ne s'applique qu'au composant Dispatcher. L'adresse 0.0.0.0 permet d'indiquer un cluster générique.
Vous pouvez utiliser le cluster générique pour équilibrer le trafic vers des adresses qui ne sont pas explicitement configurées sur une carte réseau du poste Dispatcher. Pour que cela fonctionne, le répartiteur doit au moins être en mesure de voir la totalité du trafic qu'il est supposé équilibrer. Le poste répartiteur ne verra pas le trafic vers des adresses non explicitement configurées sur l'une de ses cartes réseau, excepté s'il est configuré en tant que route par défaut pour certains trafic.
Une fois Dispatcher configuré comme route par défaut, le trafic TCP ou UDP passant par la répartiteur est équilibré en utilisant la configuration du cluster générique.
C'est ce principe qui est utilisé pour équilibrer les pare-feux. Les pare-feux peuvent traiter des paquets à destination de n'importe quelle adresse et de n'importe quel port. Pour cette raison, vous devez être en mesure d'équilibrer le trafic indépendamment de l'adresse ou du port cible.
Les pare-feux permettent de gérer le trafic de clients non sécurisés vers des serveurs sécurisés et les réponses de ces serveurs, ainsi que le trafic de clients sécurisés vers des serveurs non sécurisés et les réponses de ces derniers.
Vous devez configurer deux machines Dispatcher : l'une pour envoyer le trafic non-sécurisé vers les adresses de pare-feux non sécurisés et l'autre le trafic sécurisé vers les adresses de pare-feux sécurisés. Comme ces deux machines Dispatcher doivent utiliser le cluster générique et le port générique avec des adresses de serveur différentes, les deux répartiteurs doivent se trouver sur deux machines distinctes.
L'utilisation du cluster générique avec Caching Proxy pour le proxy transparent ne s'applique qu'au composant Dispatcher. L'adresse 0.0.0.0 permet d'indiquer un cluster générique.
La fonction de cluster générique permet également d'utiliser Dispatcher pour activer une fonction de proxy transparent pour un serveur Caching Proxy se trouvant sur le même système que Dispatcher. Cette fonction est disponible sous AIX uniquement car il doit y avoir communication entre le composant Dispatcher et le composant TCP du système d'exploitation.
Pour activer cette fonction, vous devez lancer Caching Proxy écoutant les demandes client sur le port 80. Vous configurez ensuite un cluster générique (0.0.0.0). Dans le cluster générique, vous configurez le port 80. Dans le port 80, vous configurez l'adresse NFA de la répartiteur en tant que serveur unique. Désormais, tout trafic client vers une adresse du port 80 est acheminé vers le serveur Caching Proxy exécuté sur le poste de travail Dispatcher. La demande client est ensuite traitée par un proxy comme d'habitude et la réponse est envoyée de Caching Proxy au client. Dans ce mode, le composant Dispatcher n'effectue pas l'équilibrage de charge.
Le port générique permet de gérer le trafic destiné à un port non explicitement configuré. Ce principe est utilisé pour équilibrer la charge des pare-feux. Il est également utilisé pour assurer la bonne gestion du trafic destiné à un port non configuré. En définissant un port générique sans serveur, vous garantissez que toutes les demandes en direction de ce port non configuré sont supprimées et non renvoyées au système d'exploitation. Le numéro de port 0 (zéro) permet d'indiquer un port générique, par exemple :
dscontrol port add cluster:0
Lors de la configuration d'un cluster pour le traitement du port FTP passif et du port générique, le port FTP passif utilise par défaut l'intégralité de la fourchette de ports TCP non privilégiés pour les connexions aux données. Cela signifie que pour un client connecté via un cluster d'équilibrage de charge à un port de contrôle FTP, toutes les connexions de contrôle ultérieures et les connexions aux ports dont le numéro est élevé (port > 1023) à ce même cluster seront automatiquement acheminées par Load Balancer vers le même serveur que la connexion de contrôle FTP.
Si le port générique et le port FTP d'un même cluster ne possèdent pas le même jeu de serveurs, les applications dont le numéro de port est élevé (port > 1023) peuvent échouer lorsqu'il existe une connexion de contrôle FTP pour un client. Par conséquent, la configuration de jeux de serveurs différents pour le port FTP et le port générique sur un même cluster n'est pas recommandée. Si vous optez pour ce scénario, la fourchette de ports passifs du démon FTP doit être définie dans la configuration de Load Balancer.
Cette fonction est disponible uniquement pour le composant Dispatcher.
Dispatcher permet de détecter les attaques de "refus de service" possible et d'en alerter l'administrateur. Pour cela, Dispatcher analyse les demandes entrantes d'un certain nombre de connexions partielles TCP sur les serveurs, point commun des attaques de refus de service. Dans une attaque de refus de service, un site reçoit une grand nombre de paquets SYN d'un grand nombre d'adresses IP source et de numéros de port source, mais le site ne reçoit pas les paquets suivants de ces connexions TCP. De cette manière, vous avez un grand nombre de connexion partielles TCP sur les serveurs. Les serveurs peuvent devenir très lents et peuvent ne plus accepter de nouvelles connexions entrantes.
Load Balancer fournit des exits utilisateur qui déclenchent des scripts que vous pouvez personnaliser. Ces scripts avertissent l'administrateur d'une attaque de refus de service possible. Dispatcher met à votre disposition les fichiers script exemple ci-après dans le répertoire ...ibm/edge/lb/servers/samples.
Pour pouvoir exécuter les fichiers, vous devez les déplacer dans le répertoire ...ibm/edge/lb/servers/bin et supprimer l'extension de fichier ".sample".
Pour implémenter la détection d'attaque DoS, définissez le paramètre maxhalfopen dans la commande dscontrol port de la manière suivante :
dscontrol port set 127.40.56.1:80 maxhalfopen 1000
Dans l'exemple ci-dessus, Dispatcher compare le nombre total de connexions partielles (pour tous les serveurs se trouvant sur le cluster 127.40.56.1 du port 80) avec la valeur maximale de 100 (indiqué par le paramètre maxhalfopen). Si le nombre de connexions partielles dépasse la limite, un script d'alerte (halfOpenAlert) est appelé. Lorsque le nombre de connexions partielles est inférieur à la limite, un autre script d'alerte (halfOpenAlertDone) est effectué pour indiquer que l'attaque est terminée.
Pour déterminer comment définir la valeur maxhalfopen : Régulièrement (toutes les 10 minutes, par exemple), effectuez un rapport de connexion partielle (dscontrol port halfopenaddressreport cluster:port) lorsque le trafic de votre site est normal ou élevé. Le rapport de connexion partielle renvoie un message "Nombre total de connexions partielles reçues". Vous devez attribuer au paramètre maxhalfopen une valeur supérieure de 50 à 200% au nombre le plus élevée de connexions partielles rencontrées par votre site.
Le paramètre halfopenaddressport permet d'effectuer un rapport de données statistiques ainsi que de générer des entrées dans le journal (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) pour toutes les adresses client (jusqu'à environ 8000 paires d'adresses) qui ont accédé à des serveurs disposant de connexions partielles.
Pour renforcer la protection des serveurs dorsaux contre les attaques de refus de service, vous pouvez configurer des clusters et des ports génériques. En particulier, ajoutez sous chaque cluster configuré un port générique sans serveur. Ajoutez également un cluster générique doté d'un port générique, mais sans serveur. Ces actions ont pour résultat le rejet des paquets qui ne sont pas adressés à un cluster ni à un port non génériques. Pour obtenir des informations sur les clusters et les ports génériques, voir Utilisation d'un cluster générique pour combiner les configurations serveurs et Utilisation du port générique pour acheminer le trafic destiné à un port non configuré.
L'option 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.
Certaines de ces informations sont extraites de l'exécuteur comme faisant partie du cycle du gestionnaire. C'est pourquoi, le gestionnaire doit être en cours d'exécution afin que les informations puissent être consignées dans les journaux binaires.
Utilisez l'ensemble de commandes dscontrol binlog 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 gestionnaire enverra les informations du serveur au serveur de consignation à chaque intervalle défini pour le gestionnaire. 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 gestionnaire 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 gestionnaire, l'indication d'un intervalle de consignation inférieur à l'intervalle du gestionnaire, entraîne en réalité la définition d'un intervalle de consignation identique à l'intervalle du gestionnaire. 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 gestionnaire 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. Cela se produit uniquement si le serveur de consignation est appelé par le gestionnaire. Par conséquent, si le gestionnaire est arrêté, les fichiers journaux plus anciens ne sont pas supprimés.
L'option status renvoie les paramètres courants de la fonction de consignation, c'est-à-dire l'état actif ou inactif du service, l'intervalle de consignation et la durée de conservation.
Un exemple de programme Java et un fichier de commandes ont été fournis dans le répertoire ...ibm/edge/lb/servers/samples/BinaryLog. 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) :
dslogreport 2001/05/01 8:00 2001/05/01 17:00
Cet exemple permet d'obtenir un rapport sur les informations du serveur Dispatcher de 8 à 17 heures le premier mai 2001. (Pour CBR, utilisez cbrlogreport.)
Seuls les systèmes Linux acceptent des configurations dans lesquelles le client réside sur la même machine que Load Balancer.
Les configurations avec client co-implanté risque de ne pas fonctionner correctement sur les autres plateformes car Load Balancer utilise des techniques différentes pour examiner les paquets entrants selon les systèmes d'exploitation pris en charge. La plupart du temps, sur les systèmes autres que Linux, Load Balancer ne reçoit pas de paquets de la machine locale. Il reçoit les paquets provenant uniquement du réseau. C'est la raison pour laquelle les demandes envoyées à l'adresse du cluster à partir de la machine locale ne sont pas reçues par Load Balancer et ne peuvent pas être traitées.
Le présent chapitre se compose des 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 demandes. 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 Nortel Alteon Controller.
Pour une meilleure tolérance aux pannes du contrôleur, la haute disponibilité intègre les fonctions suivantes :
Voir ccocontrol highavailability -- Contrôle de la haute disponibilité et nalcontrol highavailability -- Contrôle de la haute disponibilité pour obtenir la syntaxe complète de xxxcontrol highavailability.
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 secondary
Les 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.20
Vous 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 takeover
Cette option n'est requise que pour la maintenance.
Remarques :
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 exemples de configuration haute disponibilité Cisco CSS Controller, voir Exemples.
Pour des exemples 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 correspondent à des pourcentages ; la somme des proportions relatives 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, exécutez 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 IDconsultant sensitivity pourcentageChangement
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, exécutez 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 l'erreur serveur la plus 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, exécutez 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 d'informations, 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 d'informations, 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é, le code exemple se trouve dans le répertoire d'installation ...ibm/edge/lb/servers/samples/CustomAdvisors.
Les répertoires d'installation par défaut sont :
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 rép_install\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 .class dans le répertoire d'installation ...ibm/edge/lb/servers/lib/CustomAdvisors.
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é :
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_pam.class
Démarrez le consultant, puis exécutez 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.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Program Files\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 ...ibm/edge/lb/servers/samples/CustomAdvisors .
Metric Server fournit à Load Balancer les informations de téléchargement, sous la forme de données numériques système, relatives à l'état 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 d'arrière-plan 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 ...ibm/edge/lb/ms/script. Les scripts personnalisés doivent renvoyer une valeur de charge.
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 ce faire, reportez-vous à la page ***.
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 :
L'option 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 ...ibm/edge/lb/servers/samples/BinaryLog. 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 d'installation, ...ibm/edge/lb/servers/samples, contient des exemples de script que vous pouvez personnaliser. Pour exécuter les fichiers, copiez-les dans le répertoire ...ibm/edge/lb/servers/bin , 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 :
Cette section contient des informations relatives à l'administration et à l'identification des incidents liés à Load Balancer. Elle se compose des chapitres suivants :
Le présent chapitre explique comment exploiter et gérer Load Balancer et inclut les sections suivantes :
Load Balancer offre deux manières différentes d'exécuter ses programmes de configuration sur une machine autre que celle sur laquelle se trouve Load Balancer. La communication entre les programmes de configuration (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) et le serveur (dsserver, cbrserver, etc.) peut s'établir de l'une des manières suivantes :
L'administration à distance via RMI est plus rapide que l'administration basée sur le Web.
L'administration basée sur le Web, outre qu'elle s'effectue à distance, présente l'avantage d'être une méthode sécurisée et authentifiée, capable de communiquer avec la machine Load Balancer même en présence d'un pare-feu. De plus, cette méthode d'administration ne requiert pas d'installation particulière et utilise des clés d'authentification (lbkeys) sur la machine client éloignée qui communique avec la machine Load Balancer.
Pour RMI, la commande permettant de connecter une machine Load Balancer pour l'administration à distance est dscontrol host:hôte_éloigné.
Si l'appel RMI vient d'une machine autre que la machine locale, une séquence d'authentification clé publique/clé privée se produit avant l'acceptation de la commande de configuration.
Les communications entre les programmes de contrôle exécutés sur la même machine que les serveurs du composant ne sont pas authentifiées.
La commande suivante permet de générer des clés publiques et privées à utiliser pour l'authentification à distance :
Cette commande s'exécute uniquement sur la même machine que Load Balancer.
L'option create permet de créer une clé privée dans le répertoire key des serveurs (...ibm/edge/lb/servers/key/) et de créer des clés publiques dans le répertoire keys d'administration (...ibm/edge/lb/admin/keys/) pour chacun des composants Load Balancer. Le nom de fichier de la clé publique est : composant- AdresseServeur-PortRMI. Ces clés publiques doivent ensuite être transmises aux clients distants et placés dans le répertoire keys d'administration.
Pour une machine Load Balancer avec une adresse de nom d'hôte 10.0.0.25 utilisant le port RMI par défaut pour chaque composant, la commande lbkeys create génère les fichiers suivants :
Le jeu de fichiers d'administration a été installé sur une autre machine. Les fichiers de clés publiques doivent être placés dans le répertoire ...ibm/edge/lb/admin/keys sur la machine client distante.
Le client éloigné sera désormais autorisé à configurer Load Balancer sur 10.0.0.25.
Ces mêmes clés doivent être utilisées sur tous les clients éloignés que vous souhaitez autoriser à configurer Load Balancer sur 10.0.0.25.
Si vous devez de nouveau exécuter la commande lbkeys create, un nouveau jeu de clés publiques/privées sera généré. Ceci signifie que tous les clients distants qui ont tenté de se connecter à l'aide des clés précédentes ne seront plus autorisés. La nouvelle clé doit être placée dans le répertoire adéquat sur les clients auxquels vous voulez attribuer des autorisations.
La commande lbkeys delete permet de supprimer les clés privées et publiques sur la machine serveur. Si ces clés sont supprimées, aucun client distant ne sera autorisé à se connecter aux serveurs.
L'option force peut être associée à la commande lbkeys et à la commande lbkeys delete. Elle permet de supprimer les invites demandant si vous voulez remplacer ou supprimer les clés existantes.
Après avoir établi la connexion RMI, vous pouvez naviguer entre les programmes de configuration à l'aide des commandes dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol, dswizard, cbrwizard et sswizard, émises à partir d'une invite de commande. Vous pouvez également configurer Load Balancer à l'aide de l'interface graphique en entrant la commande lbadmin à partir d'une invite de commande.
La machine client sur laquelle s'effectue l'administration à distance requiert les éléments suivants pour l'administration basée sur le Web :
La machine hôte à laquelle vous accédez pour l'administration à distance basée sur le Web requiert les éléments suivants :
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\PROGRA~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\PROGRA~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\PROGRA~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\PROGRA~1\IBM\edge\lb\admin\* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\lang\*où lang désigne le sous-répertoire de votre langue de travail (par exemple, en_US)
Pour les systèmes Linux et UNIX :
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/lang/* /opt/ibm/edge/lb/documentation/lang/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Pour s'exécuter, l'administration basée sur le Web doit être lancée sur la machine hôte Load Balancer en émettant la commande lbwebaccess à partir de l'invite de commande de l'hôte.
Vous devez également indiquer l'ID utilisateur et le mot de passe d'accès distant à l'hôte. Cet ID utilisateur et ce mot de passe sont identiques à l'ID utilisateur et au mot de passe d'administration Caching Proxy.
Pour afficher l'administration basée sur le Web de Load Balancer, accédez à l'URL suivante du navigateur Web à partir de l'emplacement distant :
http:// nom_hôte/lb-admin/lbadmin.html
Où nom_hôte est le nom de la machine à laquelle vous accédez pour communiquer avec Load Balancer.
Une fois la page Web chargée, l'interface graphique Load Balancer, nécessaire à l'administration à distance basée sur le Web, s'affiche dans la fenêtre du navigateur.
A partir de l'interface graphique Load Balancer, vous pouvez également exécuter des commandes de contrôle de la configuration. Pour émettre une commande à partir de l'interface graphique, procédez comme suit :
Régénération à distance de la configuration
Avec l'administration à distance basée sur le Web, lorsque plusieurs administrateurs mettent à jour la configuration Load Balancer à partir de postes distants, vous devez régénérer la configuration pour, par exemple, visualiser le cluster, le port ou le serveur ajouté (ou supprimé) par un autre administrateur. L'interface graphique de l'administration à distance basée sur le Web propose les fonctions Régénérer la configuration et Régénérer toutes les configurations.
Pour régénérer la configuration à partir de l'interface graphique basée sur le Web :
Load Balancer enregistre les entrées dans un journal du serveur, un journal du gestionnaire, un journal du contrôleur de mesures (consignation des communications avec les agents Metric Server) et dans un journal pour chaque conseiller utilisé.
Vous pouvez définir le niveau de consignation pour déterminer le détail des messages consignés dans les journaux. Au niveau 0, les erreurs sont enregistrées dans un fichier journal et Load Balancer consigne également les en-têtes et les enregistrements des événements survenus une seule fois (par exemple, un message indiquant que le lancement d'un conseiller sera enregistré dans le journal du gestionnaire). Le niveau 1 inclut les données en circulation, et ainsi de suite jusqu'au niveau 5, qui inclut tous les messages émis susceptibles d'aider à résoudre un incident lorsque cela s'avère nécessaire. La valeur par défaut du journal du gestionnaire, du conseiller, du serveur ou du sous-agent est 1.
Vous pouvez également fixer la taille maximale d'un fichier journal. Lorsque vous attribuez une taille maximale au fichier journal, ce dernier fonctionne en boucle. Lorsque le fichier atteint la taille indiquée, les entrées suivantes sont écrites en haut du fichier et remplacent les entrées existantes. Lorsque vous spécifiez une nouvelle taille pour un fichier journal, elle ne doit pas être inférieure à sa taille courante. Les entrées de fichier journal sont horodatées, ce qui permet de déterminer l'ordre dans lequel elles ont été créées.
Plus le niveau de consignation choisi est élevé, plus la taille du fichier journal doit être définie judicieusement. Au niveau 0, il sera probablement sage de laisser la taille du fichier journal à sa valeur par défaut (1 Mo). Par contre, à partir du niveau 3, limitez la taille du fichier journal sans trop d'excès pour lui garder son utilité.
Par défaut, les journaux générés par Load Balancer sont stockés dans le répertoire des journaux de l'installation de Load Balancer. Pour modifier ce chemin, définissez la variable lb_logdir dans le script dsserver.
Systèmes AIX, HP-UX, Linux et Solaris : Le script dsserver se trouve dans le répertoire /usr/bin. Dans ce script, la variable lb_logdir indique le répertoire par défaut. Vous pouvez modifier cette variable pour indiquer le répertoire de fichiers journaux de votre choix. Exemple :
LB_LOGDIR=/chemin\de\mes\fichiers\journaux/
Systèmes Windows : Le fichier dsserver se trouve dans le répertoire système Windows C:\WINNT\SYSTEM32, pour Windows 2003. Dans le fichier dsserver, la variable lb_logdir indique le répertoire par défaut. Vous pouvez modifier cette variable pour indiquer le répertoire de fichiers journaux de votre choix. Exemple :
set LB_LOGDIR=c:\chemin\de\mes\fichiers\journaux\
Quel que soit le système d'exploitation utilisé, assurez-vous qu'il n'y a pas d'espace avant ou après le signe égal et que le chemin se termine par une barre oblique ("/" ou "\" selon le cas).
La fonction de consignation binaire de Load Balancer utilise le répertoire contenant les autres fichiers journaux. Voir Utilisation de la consignation binaire pour analyser les statistiques des serveurs.
Vous pouvez définir le niveau de consignation pour déterminer le détail des messages consignés dans les journaux. Au niveau 0, les erreurs sont enregistrées dans un fichier journal et Load Balancer consigne également les en-têtes et les enregistrements des événements survenus une seule fois (par exemple, un message indiquant que le lancement d'un conseiller sera enregistré dans le journal du consultant). Le niveau 1 inclut les données en circulation, et ainsi de suite jusqu'au niveau 5, qui inclut tous les messages émis susceptibles d'aider à résoudre un incident lorsque cela s'avère nécessaire. Le niveau par défaut des journaux est 1.
Vous pouvez également fixer la taille maximale d'un fichier journal. Dans ce cas, le fichier se bouclera ; une fois sa taille maximale atteinte, les nouvelles entrées seront consignées au début du fichier, écrasant les entrées les plus anciennes. Lorsque vous spécifiez une nouvelle taille pour un fichier journal, elle ne doit pas être inférieure à sa taille courante. Les entrées de fichier journal sont horodatées, ce qui permet de déterminer l'ordre dans lequel elles ont été créées.
Plus le niveau de consignation choisi est élevé, plus la taille du fichier journal doit être définie judicieusement. Au niveau 0, il sera probablement sage de laisser la taille du fichier journal à sa valeur par défaut (1 Mo). Par contre, à partir du niveau 3, limitez la taille du fichier journal sans trop d'excès pour lui garder son utilité.
Cisco CSS Controller et Nortel Alteon Controller ont les journaux suivants :
Voici un exemple de configuration du niveau de consignation ou la taille maximale du journal du contrôleur de mesures qui consigne les événements de communication avec les agents Metric Server :
xxxcontrol metriccollector set IDconsultant:IDservice:NomSystemMetric loglevel x logsize y
Par défaut, les journaux générés par les contrôleurs sont stockés dans le répertoire des journaux de l'installation du contrôleur. Pour modifier ce chemin, définissez la variable xxx_logdir dans le script xxxserver.
Systèmes AIX, HP-UX, Linux et Solaris : Le script xxxserver se trouve dans le répertoire /usr/bin. Dans ce script, la variable xxx_logdir indique le répertoire par défaut. Vous pouvez modifier cette variable pour indiquer le répertoire de fichiers journaux de votre choix. Exemple :
xxx_LOGDIR=/chemin\de\mes\fichiers\journaux/
Systèmes Windows : Le fichier xxxserver se trouve dans le répertoire système Windows, généralement C:\WINNT\SYSTEM32. Dans le fichier xxxserver, la variable xxx_logdir indique le répertoire par défaut. Vous pouvez modifier cette variable pour indiquer le répertoire de fichiers journaux de votre choix. Exemple :
set xxx_LOGDIR=c:\chemin\de\mes\fichiers\journaux\
Quel que soit le système d'exploitation utilisé, assurez-vous qu'il n'y a pas d'espace avant ou après le signe égal et que le chemin se termine par une barre oblique ("/" ou "\" selon le cas).
La fonction de consignation binaire de Load Balancer utilise le répertoire contenant les autres fichiers journaux. Voir Utilisation de la consignation binaire pour analyser les statistiques des serveurs.
La présente section explique comment utiliser et gérer le composant Dispatcher.
Pour Load Balancer, les connexions sont considérées comme périmées lorsqu'aucune activité ne s'est produite sur cette connexion pendant le nombre de secondes indiquées dans le délai d'attente. Lorsque ce nombre de secondes est dépassé et qu'aucune activité n'a eu lieu, Load Balancer supprime cet enregistrement de connexion de ces tables et le trafic à venir pour cette connexion est ignoré.
Au niveau du port, par exemple, vous pouvez indiquer la valeur du délai d'attente à partir de la commande dscontrol port set staletimeout.
Le délai d'attente peut être défini au niveau de l'exécuteur, du cluster et du port. Au niveau de l'exécuteur et du cluster, la valeur par défaut est 300 secondes et le filtrage est effectué jusqu'au port. Au niveau du port, la valeur par défaut dépend du port. Certains ports bien définis ont des valeurs de délai d'attente différentes. Par exemple, le port telnet 23 a une valeur par défaut de 259 200 secondes.
Certains services ont également leurs propres valeurs de délai d'attente. Par exemple, LDAP (Lightweight Directory Access Protocol) dispose d'un paramètre de configuration appelé idletimeout. Lorsque le nombre de secondes indiqué à l'aide de ce paramètre est dépassé, la fermeture d'une connexion de client inactif est provoquée. Vous pouvez attribuer la valeur 0 à ce paramètre, ce qui signifie que la fermeture de la connexion ne sera jamais provoquée.
Des problèmes de connectivité peuvent se produire lorsque la valeur du délai d'attente de Load Balancer est inférieure à la valeur du délai du service. Dans le cas de LDAP, la valeur par défaut du paramètre staletimeout (délai d'attente) de Load Balancer est 300 secondes. Si aucune activité ne se produit sur la connexion pendant 300 secondes, Load Balancer supprime l'enregistrement de connexion de ses tables. Si la valeur idletimeout est supérieure à 300 secondes (ou si elle est égale à 0), le client peut encore croire qu'une connexion au serveur est établie. Lorsque le client transmet des paquets, ces derniers seront ignorés par Load Balancer. De cette façon, LDAP est bloqué lorsqu'une demande au serveur est effectuée. Pour éviter ce problème, attribuez une valeur différente de zéro au paramètre, identique ou inférieure à la valeur du paramètre staletimeout de Load Balancer.
Une fois tous les paquets de données transmis, un client envoie un paquet FIN pour informer le serveur que la transaction est terminée. Lorsque Dispatcher réceptionne le paquet FIN, il remplace l'état de la transaction, active, par FIN. Lorsqu'une transaction est à l'état FIN, la mémoire réservée à la connexion est libérée.
Pour améliorer les performances de l'affectation et de la réutilisation des enregistrements de connexions, utilisez la commande executor set fintimeout pour contrôler la période pendant laquelle Dispatcher doit conserver les connexions à l'état FIN, c'est-à-dire actives, dans les tables Dispatcher et en état d'accepter le trafic. Lorsqu'une connexion à l'état FIN dépasse la valeur fintimeout, elle est supprimée des tables Dispatcher et prête à être utilisée. Vous pouvez modifier la valeur du délai d'expiration FIN à l'aide de la commande dscontrol executor set fincount.
Utilisez la commande dscontrol executor set staletimeout pour contrôler la période pendant laquelle Dispatcher doit conserver les connexions à l'état Established lorsqu'aucun trafic n'a été détecté comme étant actif dans les tables Dispatcher, et en état d'accepter le trafic. Pour plus d'informations, voir Utilisation de la valeur du délai d'attente.
Divers diagrammes peuvent être affichés en fonction des informations visualisées par l'exécuteur et transmises au gestionnaire. (Le gestionnaire doit s'exécuter pour pouvoir utiliser l'option de menu Contrôler de l'interface graphique).
Un système de gestion de réseau est un programme qui s'exécute en continu et qui sert à surveiller et à refléter l'état d'un réseau et à contrôler ce dernier. SNMP (Simple Network Management Protocol), protocole courant permettant de communiquer avec des périphériques d'un réseau, est la norme de gestion de réseau en cours. Les périphériques de réseau sont généralement dotés d'un agent SNMP et d'un ou de plusieurs sous-agents. L'agent SNMP communique avec le poste de gestion de réseau ou répond aux requêtes SNMP de l'invite de commande. Le sous-agent SNMP extrait et met à jour des données et transmet ces dernières à l'agent SNMP de sorte que celui-ci communique en retour avec le demandeur.
Dispatcher donne une Bibliothèque d'informations de gestion SNMP (ibmNetDispatcherMIB) et un sous-agent SNMP. Cela permet d'utiliser un système de gestion de réseau (tel que Tivoli(R) NetView(R), Tivoli Distributed Monitoring ou HP OpenView) pour surveiller l'état, le débit et l'activité de Dispatcher. Les données MIB décrivent la gestion de Dispatcher et reflètent l'état en cours de ce dernier. Elles sont installées dans le sous-répertoire ..lb/admin/MIB.
Le système de gestion de réseau utilise des commandes SNMP GET pour consulter les valeurs MIB des autres machines. Il peut ensuite vous envoyer une notification en cas de dépassement des valeurs seuil indiquées. Vous pouvez ensuite changer les performances de Dispatcher en modifiant les données de configuration de Dispatcher, afin d'effectuer une mise au point proactive ou de résoudre les incidents liés à Dispatcher avant qu'ils se transforment en pannes de serveur Web ou Dispatcher.
Le système fournit généralement un agent SNMP pour chaque poste de gestion de réseau. L'utilisateur adresse une commande GET à l'agent SNMP. En retour, ce dernier émet une commande GET pour extraire les valeurs de variables MIB indiquées à partir d'un sous-agent responsable de ces dernières.
Dispatcher fournit un sous-agent qui permet la mise à jour et l'extraction de données MIB. Le sous-agent répond aux données MIB appropriées lorsque l'agent SNMP émet une commande GET. L'agent SNMP communique les données au poste de gestion de réseau. Celui-ci peut vous envoyer une notification en cas de dépassement des valeurs seuil indiquées.
Le support SNMP de Dispatcher comporte un sous-agent SNMP qui utilise la fonction DPI(R) (Distributed Program Interface). Il s'agit d'une interface entre un agent SNMP et les sous-agents de ce dernier. Windows utilise l'agent d'extension Windows en tant qu'interface entre un agent SNMP et les sous-agents de ce dernier.
Figure 40. Commandes SNMP pour les systèmes Linux et UNIX
Les systèmes AIX fournissent un agent SNMP qui utilise le protocole SNMP Multiplexer (SMUX) et fournissent DPID2, qui est un exécutable supplémentaire fonctionnant comme traducteur entre DPI et SMUX.
Pour les systèmes HP-UX, vous devez obtenir un agent SNMP fonctionnant avec SMUX car HP-UX n'en fournit pas. Load Balancer fournit DPID2 pour les systèmes HP-UX.
Les systèmes Linux fournissent un agent SNMP qui utilise SMUX. La plupart des versions Linux (Red Hat, par exemple) sont livrées avec un package UCD SNMP. UCD SNMP version 4.1 ou ultérieure dispose d'agents SMUX actifs. Load Balancer fournit DPID2 pour les systèmes Linux.
Pour les systèmes Solaris, vous devez obtenir un agent SNMP fonctionnant avec SMUX car Solaris n'en fournit pas. Load Balancer fournit DPID2 pour les systèmes Solaris dans le répertoire /opt/ibm/edge/lb/servers/samples/SNMP.
L'agent DPI doit fonctionner comme un superutilisateur. Avant d'exécuter le démon DPID2, mettez à jour les fichiers /etc/snmpd.peers et /etc/snmpd.conf comme suit :
Pour les systèmes AIX et Solaris :
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "mot_de_passe_dpid"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 mot_de_passe_dpid #dpid
Pour les systèmes Linux :
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "mot_de_passe_dpid"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 mot_de_passe_dpid
Vous devez également associer un commentaire à toutes les lignes du fichier snmpd.conf qui commencent pas les mots suivants : com2sec, group, view ou access.
Pour installer le support SNMP de HP-UX :
Pour utiliser Load Balancer SNMP avec SuSE Linux, procédez comme suit :
Régénérez snmpd (s'il s'exécute déjà) de sorte qu'il relise le fichier snmpd.conf :
refresh -s snmpd
Démarrez l'homologue DPID SMUX :
dpid2
Les démons doivent être lancés dans l'ordre suivant :
Pour installer le support SNMP de Solaris, procédez aux opérations ci-dessous.
/etc/rc3.d/S76snmpdx en /etc/rc3.d/K76snmpdx
/etc/rc3.d/S77dmi en /etc/rc3.d/K77dmi
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: /usr/local/lib:/usr/local/ssl/lib:/usr/lib
export PATH=/usr/local/sbin:/usr/local/bin:$PATH
export SNMPCONFPATH =/etc/snmp
export MIBDIRS=/usr/local/share/snmp/mibs
cp /opt/ibm/edge/lb/servers/samples/SNMP/dpid2 /usr/local/sbin/dpid2
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "mot_de_passe_dpid"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 mot_de_passe_dpid
Remarques :
Sur le site Web http://sunfreeware.com/, les noms portent l'extension .gz, aussi ne leur appliquez pas la commande de décompression gunzip ou untar. Utilisez plutôt la commande pkgadd NomModule.
Pour installer le support SNMP de Windows :
L'exécuteur étant en cours de fonctionnement, lancez la commande dscontrol subagent start [nom_communauté] pour définir le nom de communauté utilisé entre l'agent d'extension Windows et l'agent SNMP.
IMPORTANT : Sous Windows 2003, par défaut SNMP ne répond à aucun nom de communauté présenté. Dans ce cas, le sous-agent SNMP ne répond à aucune demande SNMP. Pour vous assurez que le sous-agent SNMP réponde au nom de communauté, vous devez affecter aux propriétés du service SNMP le nom de communauté et les hôtes de destination appropriés. Configurez les propriétés de la sécurité SNMP de la manière suivante :
SNMP communique en envoyant et en recevant des interruptions, messages envoyés par des périphériques gérés afin de signaler des conditions d'erreur ou la survenue d'événements importants, par exemple, le dépassement d'un seuil.
Le sous-agent utilise les interruptions suivantes :
L'interruption indHighAvailStatus annonce que la valeur de la variable (hasState) correspondant à l'état de la haute disponibilité a changé. Les valeurs possibles de hasState sont :
L'interruption indSrvrGoneDown annonce que la pondération du serveur spécifié par les segments (ID cluster), psNum (numéro port) et ssID (ID serveur) de l'identificateur d'objet est passée à zéro. Le dernier nombre total de connexions actives du serveur est envoyé avec l'interruption. Cette interruption indique que, pour le répartiteur, le serveur spécifié a été arrêté.
L'interruption indDOSAttack indique que numhalfopen (nombre de connexions partielles constituées uniquement de paquets SYN) a dépassé le seuil maxhhalfopen pour le port précisé par les segments csID (ID cluster) et psNum (numéro port) de l'identificateur d'objet. Le nombre de serveurs configurés sur le port est transmis dans l'interruption. Cette interruption indique que Load Balancer peut faire l'objet d'une attaque de refus de service.
L'interruption indDOSAttackDone indique que numhalfopen (nombre de connexions partielles constituées uniquement de paquets SYN) est en deçà du seuil maxhalfopen pour le port précisé par les segments csID et psNum de l'identificateur d'objet. Le nombre de serveurs configurés sur le port est transmis dans l'interruption. Lorsque Load Balancer détermine que l'attaque de refus de service est terminée, cette interruption est envoyée après l'interruption indDOSAttack.
Pour les systèmes Linux et UNIX, en raison d'une restriction au niveau de l'interface API SMUX, il se peut que l'ID entreprise signalé dans des interruptions provenant du sous-agent ibmNetDispatcher corresponde à l'ID entreprise de dpid2 et non à celui d'ibmNetDispatcher, 1.3.6.1.4.1.2.6.144. Cependant, les utilitaires de gestion SNMP peuvent déterminer la source de l'interruption car les données contiennent un ID objet provenant du MIB ibmNetDispatcher.
Le support SNMP est activé à l'aide de la commande dscontrol subagent start. Il est désactivé à l'aide de la commande dscontrol subagent stop.
Pour plus d'informations sur la commande dscontrol, voir dscontrol subagent -- Configuration du sous-agent SNMP.
Le pare-feu ipchains est intégré au noyau Linux. Lors de l'exécution simultanée de Load Balancer et de ipchains, Load Balancer voit les paquets avant ipchains. Vous pouvez ainsi utiliser ipchains pour renforcer un système Load Balancer Linux, tel qu'un système Load Balancer permettant de charger des pare-feux d'équilibrage de charge.
Lorsque ipchains ou iptables est configuré pour une utilisation restreinte (aucun trafic entrant ou sortant autorisé), la partie dédiée à l'acheminement des paquets de Load Balancer continue de fonctionner normalement.
Notez que ipchains et iptables ne permettent pas le filtrage du trafic entrant avant l'équilibrage de la charge.
Le fonctionnement correct de l'ensemble de Load Balancer nécessite l'autorisation de trafic supplémentaire. Voici quelques exemples de communication :
En règle générale, la stratégie ipchains adaptée aux systèmes Load Balancer consiste à refuser tout type de trafic, sauf celui à destination et provenant des serveurs d'arrière-plan, du système Load Balancer à haute disponibilité partenaire, des cibles à atteindre ou des hôtes de configuration.
N'activez pas iptables lorsque Load Balancer s'exécute avec le noyau Linux version 2.4.10.x. En effet, l'activation sous cette version de noyau Linux peut provoquer à terme une dégradation des performances.
Pour désactiver iptables, listez les modules (lsmod) pour savoir lesquels utilisent ip_tables et ip_conntrack, puis supprimez ceux-ci à l'aide des commandes rmmod ip_tables et rmmod ip_conntrack. Lorsque vous réamorcez la machine, ces modules sont de nouveau ajoutés de sorte que vous devez répéter cette procédure après chaque réamorçage.
Pour plus d'informations, voir Incident : Les iptables Linux interfèrent avec le routage de paquets.
La présente section explique comment utiliser et gérer le composant CBR de Load Balancer.
CBR et Caching Proxy gèrent conjointement les demandes HTTP et HTTPS (SSL) via l'interface API du plug-in de Caching Proxy. Caching Proxy doit être en cours d'exécution sur la même machine pour que CBR puisse commencer à effectuer l'équilibrage de charge des serveurs. Configurez CBR et Caching Proxy en respectant les instructions de la section Exemple de configuration CBR.
Après avoir lancé CBR, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux utilisés par CBR sont similaire à ceux de Dispatcher. Pour plus d'informations, voir Utilisation des journaux Load Balancer.
Après avoir lancé Site Selector, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux employés par Site Selector sont similaires à ceux utilisés dans Dispatcher. Pour plus d'informations, voir Utilisation des journaux Load Balancer.
Après avoir lancé Cisco CSS Controller, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux utilisés par Cisco CSS Controller sont similaires à ceux de Dispatcher. Pour plus d'informations, voir Utilisation des journaux Load Balancer.
Après avoir lancé Nortel Alteon Controller, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux utilisés par Nortel Alteon Controller sont similaires à ceux de Dispatcher. Pour plus d'informations, voir Utilisation des journaux Load Balancer.
Metric Server fournit à Load Balancer des informations relatives à la charge des serveurs. Il réside sur chaque serveur soumis à l'équilibrage de charge.
Systèmes Linux et UNIX :
Systèmes Windows :
Cliquez sur Démarrer > Paramètres (pour Windows 2000) > Panneau de configuration > Outils d'administration > Services. Cliquez à l'aide du bouton droit de la souris sur IBM Metric Server, puis sélectionnez Démarrer. Pour arrêter le service, suivez la même procédure en sélectionnant Arrêter.
Modifiez le niveau de consignation dans le script de démarrage de Metric Server. Vous pouvez indiquer un niveau de consignation compris entre 0 et 5, à l'instar de la plage admise pour les journaux de Load Balancer. Cette action génère un journal des agents dans le répertoire ...ms/logs.
Ce chapitre permet la détection et la résolution des incidents associés à Load Balancer.
Utilisez les informations de cette section pour rassembler les données nécessaires au service d'assistance IBM. Les informations sont classées sous les rubriques suivantes :
Le composant Dispatcher (et lui seul), dispose d'un outil d'identification des incidents qui collecte automatiquement les données propres au système d'exploitation et les fichiers de configuration de composants donnés. Pour lancer cet outil, entrez lbpd à partir du répertoire approprié, c'est-à-dire :
Pour les systèmes Linux et UNIX : /opt/ibm/edge/lb/servers/bin/
Pour les systèmes Windows : C:\Program Files\IBM\edge\lb\servers\bin
Cet outil d'identification des incidents regroupe les données collectées dans des fichiers comme suit :
Pour les systèmes Linux et UNIX : /opt/ibm/edge/lb/lbpmr.tar.Z
Pour les systèmes Windows : C:\Program Files\IBM\edge\lb\lbpmr.zip
Avant d'appeler le service d'assistance IBM, regroupez les informations ci-après.
dscontrol file save primary.cfg
Cette commande place le fichier de configuration dans le répertoire .../ibm/edge/lb/servers/configuration/composant/.
java -fullversion
Sur les systèmes AIX, HP-UX, Linux et Solaris : netstat -ni
Sur les systèmes Windows : ipconfig /all
Commande requise à partir de tous les serveurs et de Load Balancer.
Sur les systèmes AIX, HP-UX, Linux et Solaris : netstat -nr
Sur les systèmes Windows : route print
Commande requise à partir de tous les serveurs et de Load Balancer.
En cas d'incident dans un environnement de haute disponibilité, regroupez les informations requises ci-après.
Systèmes AIX, HP-UX, Linux et Solaris : /opt/ibm/edge/lb/servers/bin
Systèmes Windows : C:\Program Files\ibm\edge\lb\servers\bin
Les scripts à extraire sont les suivants :
goActive
goStandby
goIdle (s'il existe)
goInOp (s'il existe)
Extrayez aussi les fichiers de configuration. Voir Informations générales (obligatoires).
En cas d'incident lié aux conseillers (par exemple lorsque des conseillers déclarent par erreur des serveurs inactifs), regroupez les informations requises ci-après.
dscontrol advisor loglevel http 80 5
ou
dscontrol advisor loglevel NomConseiller port niveau_journal
ou
dscontrol advisor loglevel NomConseiller cluster:port niveau_journal
ou
nalcontrol metriccollector set IDconsultant:IDservice:nom_mesure loglevel valeur
Cette ligne de commande crée un journal nommé ADV_NomConseiller ; par exemple, ADV_http.log. Ce journal se trouve dans les répertoires suivants :
Plateformes AIX, HP-UX, Linux et Solaris : /opt/ibm/edge/lb/servers/logs/composant
Plateformes Windows : C:\Program Files\ibm\edge\lb\servers\logs\composant
Où composant correspond à :
dispatcher = Dispatcher
cbr = CBR (Content Based Routing)
cco = Cisco CSS Controller
nal = Nortel Alteon Controller
ss = Site Selector
L'appel ADVLOG génère des instructions dans le fichier journal des conseillers lorsque le niveau de consignation est inférieur à celui associé aux conseillers. Si le niveau de consignation est 0, l'instruction est toujours générée. Vous ne pouvez pas utiliser ADVLOG à partir du constructeur. Le fichier journal n'est créé qu'une fois que l'exécution du constructeur du conseiller personnalisé est terminée car le nom du fichier journal dépend des informations définies dans le constructeur.
Il existe cependant une autre manière de déboguer votre conseiller personnalisé qui permet d'éviter cette restriction. Vous pouvez utiliser des instructions System.out.println(message) pour imprimer les messages à l'écran. Editez le script dsserver et remplacez javaw par java pour que les instructions d'impression apparaissent dans la fenêtre. La fenêtre utilisée pour démarrer dsserver ne doit pas être fermée, pour que les impressions soient affichées. Si vous utilisez une plateforme Windows, vous devez arrêter le service Dispatcher, puis le démarrer manuellement à partir d'une fenêtre pour apercevoir les messages.
Pour plus d'informations sur ADVLOG, reportez-vous au document Programming Guide for Edge Components.
En cas d'incident lié au routage par contenu (CBR), regroupez les informations requises ci-après.
Systèmes Linux et UNIX : /etc/
Systèmes Windows : C:\Program Files\IBM\edge\cp\etc\en_US\
Systèmes Linux et UNIX : /opt/ibm/edge/lb/servers/configurations/cbr
Systèmes Windows : C:\Program Files\IBM\edge\lb\servers\configurations\cbr
Si vous n'arrivez pas à accéder au cluster, il est possible que l'une des machines Load Balancer ou les deux aient attribué un alias au cluster. Pour déterminer laquelle détient le cluster, procédez comme suit :
ping cluster arp -aSi vous utilisez des méthodes d'acheminement NAT ou CBR de Dispatcher, lancez également une commande ping vers l'adresse de retour.
Sur les systèmes AIX et HP-UX : netstat -ni
Sur les systèmes Linux et Solaris : ifconfig -a
Sur les systèmes Windows : ipconfig /all
Si vous n'obtenez pas de réponse à la commande ping et que vous n'utilisez pas l'ULB, il est possible qu'aucune des machine n'ait attribué d'alias à l'adresse IP du cluster sur son interface, par exemple en0, tr0 et ainsi de suite.
Si vous n'arrivez pas à résoudre des incidents de routage et que toute vos tentatives ont échoué, exécutez la commande suivante pour lancer une trace du trafic réseau :
iptrace -a -s adresse_IP_Client_EnEchec -d adresse_IP_cluster -b iptrace.trc
Exécutez la trace, recréez l'incident, puis tuez le processus.
tcpdump -i lan0 host cluster et host client
Vous devrez peut-être télécharger tcpdump de l'un des sites d'archivage de logiciels HP-UX GNU.
tcpdump -i eth0 host cluster et host client
Exécutez la trace, recréez l'incident, puis tuez le processus.
snoop -v adresse_IP_client adresse_IP_destination > snooptrace.out
Vous pouvez également augmenter les niveaux de différents journaux (par exemple, journal du gestionnaire, journal du conseiller, etc.) et analyser les informations qu'ils contiennent.
Pour identifier un incident déjà résolu dans un correctif Service Release, recherchez les mises à niveau disponibles. Pour obtenir la liste des défauts Edge Components corrigés, reportez-vous à la page Web d'assistance de WebSphere Application Server : http://www.ibm.com/software/webservers/appserv/was/support/. A partir de cette page, cliquez sur le lien permettant d'accéder au site de téléchargement des correctifs.
La version correcte du code Java est installée lors de l'installation de Load Balancer.
Voir Informations connexes pour obtenir des liens vers les pages Web de support et de bibliothèque. La page de support Web contient un lien à l'aide sous la forme de notes techniques.
Pour les opérations répertoriées, voir le tableau indiqué.
Tableau 17. Résolution des incidents liés à Dispatcher
Symptôme | Cause possible | Voir... |
---|---|---|
Dispatcher ne fonctionne pas correctement | Conflit de numéros de port | Vérification des numéros de port Dispatcher |
Le serveur configuré ne répond pas aux requêtes d'équilibrage de charge | Conflit d'adresses ou adresse erronée | Incident : Le répartiteur et le serveur ne répondent pas |
Absence de prise en charge des connexions des machines client ou dépassement de délai des connexions |
| Incident : Les requêtes Dispatcher ne sont pas équilibrées |
Les machines client ne sont pas prises en charge ou le délai imparti à ces connexions est dépassé | La fonction haute disponibilité est inopérante | Incident : La fonction à haute disponibilité de Dispatcher n'est pas activée |
Impossible d'ajouter un signal de présence (plateforme Windows) | L'adresse source n'est pas configurée sur un adaptateur | Incident : Impossible d'ajouter un signal de présence (plateforme Windows) |
Le serveur ne livre pas les requêtes (plateforme Windows) | Une route supplémentaire a été créée dans la table de routage | Incident : Routes supplémentaires (Windows 2000) |
Les conseillers ne fonctionnent pas correctement en réseau étendu | Les conseillers ne fonctionnent pas sur les machines distantes | Incident : Les conseillers ne fonctionnent pas correctement |
Dispatcher, Microsoft IIS et SSL ne fonctionnent pas ou risquent de s'arrêter | Impossible d'envoyer des données codées via les protocoles | Incident : Dispatcher, Microsoft IIS et SSL ne fonctionnent pas (plateforme Windows) |
Connexion à une machine distante refusée | Une ancienne version des clés est encore utilisée | Incident : Connexion du répartiteur à une machine distante |
Echec de la commande dscontrol ou lbadmin, le message "Le serveur ne répond pas" ou "Impossible d'accéder au serveur RMI" s'affiche |
| Incident : La commande dscontrol ou lbadmin n'a pas abouti |
Message d'erreur "Impossible de trouver le fichier..." lors de l'exécution de Netscape (en tant que navigateur par défaut) pour afficher l'aide en ligne (plateforme Windows) | Paramétrage incorrect pour l'association de fichier HTML | Incident : Message d'erreur "Impossible de trouver le fichier..." lorsque vous tenter d'afficher l'aide en ligne (plateforme Windows) |
L'interface graphique ne démarre pas correctement | Espace de pagination insuffisant | Incident : L'interface graphique ne démarre pas correctement |
Erreur lors de l'exécution de Dispatcher lorsque Caching Proxy est installé | Rapports avec le fichier Caching Proxy | Incident : Erreur lors de l'exécution de Dispatcher lorsque Caching Proxy est installé |
L'interface utilisateur graphique ne s'affiche pas correctement. | La résolution est incorrecte. | Incident : L'interface graphique ne démarre pas correctement |
Les panneaux d'aide apparaissent parfois sous d'autres fenêtres | Restriction Java | Incident : Sous Windows, les fenêtres d'aide sont parfois masquées par d'autres fenêtres ouvertes |
Load Balancer ne peut ni traiter ni transmettre de cadre | Une adresse MAC unique est nécessaire pour chaque carte NIC | Incident : Load Balancer ne peut ni traiter ni transmettre de cadre |
Un écran bleu apparaît | Aucune carte réseau n'est installée et configurée | Incident : Un écran bleu s'affiche au démarrage de l'exécuteur Load Balancer |
La fonction Path MTU Discovery permet d'éviter le trafic retour | Le cluster est associé à un alias sur l'unité de bouclage | Incident : La fonction Path MTU Discovery permet d'éviter le trafic retour avec Load Balancer |
La fonction haute disponibilité de Load Balancer en mode réseau étendu est inopérante | La répartiteur distante doit être définie en tant que serveur d'un cluster sur la répartiteur locale | Incident : La fonction haute disponibilité de Load Balancer en mode réseau étendu est inopérante |
Arrêt (ou comportement imprévu) de l'interface graphique lors du chargement d'un fichier de configuration volumineux. | La mémoire est insuffisante pour permettre à Java de traiter une modification de l'interface graphique de cette ampleur | Incident : Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux |
Adresses IP non résolues correctement sur la connexion distante | Lors de l'utilisation d'un client distant sur une implémentation SSL, des noms d'hôtes ou des noms de domaines complets ne sont pas correctement convertis en adresses IP | Incident : Adresses IP non résolues correctement sur la connexion distante |
L'interface coréenne de Load Balancer affiche des polices non souhaitées ou qui se chevauchent sous AIX et Linux | Vous devez modifier les polices de caractères par défaut | Incident : L'interface coréenne de Load Balancer affiche des polices non souhaitées ou qui se chevauchent sous AIX et Linux |
Sous Windows, lorsqu'un alias a été attribué à l'unité de bouclage de MS, le système d'exploitation ne répond pas correctement à l'adresse d'alias lors de l'émission d'une commande telle que hostname | Dans la liste des connexions réseau, le nouvel alias ne doit pas se trouver au-dessus de l'adresse locale | Incident : Sous Windows, adresse d'alias renvoyée au lieu de l'adresse locale lors de l'émission de commandes telles que hostname |
Comportement inattendu de l'interface graphique lors de l'utilisation de Windows avec une carte vidéo Matrox AGP | Incident lors de l'utilisation de cartes Matrox AGP en cours d'exécution de l'interface graphique de Load Balancer | Incident : Sous Windows, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP |
Comportement inattendu, tel un arrêt du système, lors de l'exécution de "rmmod ibmlb" sous Linux | Incident lors du retrait manuel du noyau du module Load Balancer (ibmlb). | Incident : Comportement inattendu lors de l'exécution de rmmod ibmlb (systèmes Linux) |
Temps de réponse important lors de l'exécution de commandes sur la machine Dispatcher | Un temps de réponse important peut être dû à une surcharge de la machine liée à un volume élevé de trafic client | Incident : Temps de réponse important lors de l'exécution de commandes sur la répartiteur |
Pour la méthode d'acheminement MAC de Dispatcher, le conseiller SSL ou HTTPS n'enregistrement pas les charges des serveurs | Incident lié au fait que l'application serveur SSL n'est pas configurée avec l'adresse IP du cluster | Incident : Le conseiller SSL ou HTTPS n'enregistre pas les charges des serveurs (avec l'acheminement MAC) |
Déconnexion de l'hôte lors de l'administration Web à distance via Netscape | Cette déconnexion se produit lors du redimensionnement de la fenêtre du navigateur | Incident : Déconnexion de l'hôte lors du redimensionnement de la fenêtre du navigateur Netscape en cours d'administration Web |
Regroupement de connexions activé et serveur Web établissant une liaison à 0.0.0.0 | Configurez le serveur Microsoft IIS en tant que serveur de liaison | Incident : Regroupement de connexions activé et serveur Web établissant une liaison à 0.0.0.0 |
Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent sur la ligne de commande | Modifiez les propriétés des polices de la fenêtre de la ligne de commande | Incident : Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent dans la fenêtre de l'invite de commande |
Sous HP-UX, le message suivant est généré : java.lang.OutOfMemoryError unable to create new native thread | Certaines installations HP-UX autorisent par défaut 64 unités d'exécution par processus. Cela est suffisant. | Incident : Sous HP-UX, la mémoire est insuffisante pour Java et une erreur d'unité d'exécution s'est produite |
Sous Windows, les conseillers et les cibles à contacter marquent tous les serveurs comme étant arrêtés | Le déchargement des tâches n'est pas désactivé ou il doit activer ICMP. | Incident : Sous Windows, les conseillers et les cibles à contacter marquent tous les serveurs comme étant arrêtés |
Sous Windows, la résolution de l'adresse IP en nom d'hôte n'est pas possible lorsque plusieurs adresses sont configurées sur un adaptateur | L'adresse IP que vous voulez comme nom d'hôte doit d'abord apparaître dans le registre. | Incident : Sous Windows, la résolution de l'adresse IP en nom d'hôte n'est pas possible lorsque plusieurs adresses sont configurées sur un adaptateur |
Sous Windows, les conseillers ne fonctionnent pas dans une configuration en haute disponibilité après une panne réseau | Lorsque le système détecte une panne réseau, il efface sa mémoire cache ARP (Address Resolution Protocol) | Incident : Sous Windows, les conseillers ne fonctionnent pas dans une configuration en haute disponibilité après une panne réseau |
Sur les systèmes Linux, la commande "IP address add" et les alias de bouclage de cluster multiples sont incompatibles | Lorsque vous attribuez des alias à plusieurs adresses sur l'unité de bouclage, vous devez utiliser la commande ifconfig et non la commande ip address add | Incident : Sous Linux, n'utilisez pas la commande "IP address add" lors de l'affectation d'alias à plusieurs clusters de l'unité de bouclage |
Message d'erreur : "Adresse de routeur non spécifiée ou non valide pour la méthode port" lors de la tentative d'ajout d'un serveur | Liste de contrôle permettant d'identifier l'incident qui s'est produit lors de l'ajout d'un serveur | Incident : Message d'erreur "Adresse de routeur non spécifiée ou non valide pour la méthode port" |
Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de session de terminal à partir de laquelle ils ont été lancés | Utilisez la commande nohup afin que les processus lancés ne reçoivent pas un signal d'arrêt lorsque vous quittez la session de terminal. | Incident : Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de terminal à partir de laquelle ils ont été lancés |
Un ralentissement se produit lors du chargement des configurations Load Balancer | Ce délai peut provenir des appels DNS effectués pour résoudre et vérifier l'adresse du serveur. | Incident : Délai lors du chargement d'une configuration Load Balancer |
Sous Windows, un message d'erreur s'affiche pour indiquer qu'il existe un conflit d'adresses IP avec un autre système du réseau | Si la fonction de haute disponibilité est configurée, il est possible que des adresses de cluster soient définies sur les deux systèmes pendant une courte période et qu'elles génèrent ce message d'erreur. | Incident : Sur les systèmes Windows, un message d'erreur lié à un conflit d'adresses IP apparaît à l'écran |
Les machines principale et de secours sont toutes deux activées en mode haute disponibilité. | Cet incident peut survenir lorsque les scripts go ne sont pas exécutés sur la machine principale ou la machine de secours. | Incident : Les machines principale et de secours sont toutes deux activées en mode haute disponibilité |
Les demandes client échouent lorsque Dispatcher tente de renvoyer des réponses de grande page | Les demandes client générant des réponses de grande page arrivent à expiration si la taille maximale en transmission (MTU) n'est pas définie correctement sur la répartiteur lors de l'utilisation de la méthode de transfert nat ou cbr. | Incident : Les demandes client échouent lors de la tentative de renvoi de réponses de grande page |
Sous Windows, l'erreur "Le serveur ne répond pas" survient lors de l'exécution d'une commande "dscontrol" ou "lbadmin" | Lorsqu'il existe plusieurs adresses IP sur un système Windows et que le fichier hôte ne spécifie pas l'adresse à associer au nom d'hôte. | Incident : Sous Windows, l'erreur "Le serveur ne répond pas" survient lors de l'exécution d'une commande "dscontrol" ou "lbadmin" |
Les machines Dispatcher à haute disponibilité risquent de ne pas être synchronisées sous Linux pour S/390 avec des périphériques qeth | Lors de l'utilisation de la haute disponibilité sur des systèmes Linux S/390 avec le pilote réseau qeth, la synchronisation des machines Dispatcher active et de secours risque d'échouer. | Incident : Les machines Dispatcher à haute disponibilité risquent de ne pas être synchronisées sur les systèmes Linux pour S/390 avec des pilotes qeth |
Conseils pour la configuration de la fonction de haute disponibilité pour Load Balancer | Ces conseils visent à réduire les incidents liés à la haute disponibilité tels que :
| Incident : Conseils sur la configuration de la haute disponibilité |
Limitations de la configuration de l'acheminement MAC pour Dispatcher avec les plateformes zSeries et S/390 | Sous Linux, il existe des limitations lorsque vous utilisez des serveurs zSeries ou S/390 dotés de cartes OSA (Open System Adapter). Des solutions alternatives sont fournies. | Sous Linux, il existe des limitations de la configuration Dispatcher lorsque vous utilisez des serveurs zSeries ou S/390 dotés de cartes OSA (Open System Adapter) |
Sur certaines versions de Red Hat Linux, des fuites de mémoire se produisent en cas d'exécution de Load Balancer configuré avec le gestionnaire et les conseillers | Les versions IBM Java SDK de JVM et la bibliothèque NPTL (Native POSIX Thread Library) livrée avec certaines distributions de Linux, comme Red Hat Enterprise Linux 3.0, peuvent être à l'origine de la fuite de mémoire. | Incident : Sur certaines versions de Linux, des fuites de mémoire se produisent en cas d'exécution de Dispatcher configuré avec le gestionnaire et les conseillers |
Sur SUSE Linux Enterprise Server 9, un rapport Dispatcher indique que les paquets sont acheminés (le nombre de paquets augmente), alors que les paquets n'atteignent jamais le serveur dorsal | Le module NAT iptables est chargé. Cette version d'iptables contient une erreur possible, bien que non confirmée, entraînant un comportement étrange lors des interactions avec Dispatcher. | Incident : Sur SUSE Linux Enterprise Server 9, Dispatcher réachemine des paquets alors qu'ils n'atteignent jamais le serveur dorsal |
Sous Windows, lors de l'utilisation de la fonction de haute disponibilité de Dispatcher, des incidents peuvent se produire lors du relais. | Si le goScript configurant l'adresse IP de cluster sur la machine active s'exécute avant celui qui annule la configuration de l'adresse IP de cluster sur la machine de secours, des incidents risquent de se produire. | Incident : Sous Windows, un message d'erreur lié à un conflit d'adresses IP apparaît à l'écran lors de la reprise de la haute disponibilité |
Sous Linux, des iptables peuvent interférer avec le routage de paquets | Les iptables Linux peuvent interférer avec l'équilibrage de charge du trafic et doivent être désactivées sur la machine Load Balancer. | Incident : Les iptables Linux peuvent interférer avec le routage de paquets |
Un message d'avertissement sur un ensemble de fichiers Java s'affiche lors de l'installation de correctifs de service ou lors de l'installation en mode natif, à l'aide des outils de création de packages du système | L'installation du produit comporte plusieurs packages qu'il n'est pas nécessaire d'installer sur la même machine, donc chacun de ces packages installe un ensemble de fichiers Java. En cas d'installation sur la même machine, un message d'avertissement indique que l'ensemble de fichiers Java appartient également à un autre ensemble de fichiers. | Un message d'avertissement Java s'affiche lors de l'installation de correctifs de service |
Mise à niveau de l'ensemble de fichiers Java fourni avec les installations Load Balancer | En cas d'incident au niveau de l'ensemble de fichiers Java, contactez le service d'assistance IBM pour recevoir une mise à niveau de l'ensemble de fichiers Java qui a été fourni avec l'installation Load Balancer. | Mise à niveau de l'ensemble de fichiers Java fourni avec l'installation Load Balancer |
Sous Windows, des connexions persistantes peuvent être supprimées lors de la reprise de la haute disponibilité | Sur les systèmes d'exploitation Microsoft Windows, des connexions persistantes peuvent être supprimées lors de la reprise de la haute disponibilité. Cet incident se produit uniquement lorsqu'un serveur co-implanté utilise la méthode d'acheminement MAC. | Incident : Des connexions persistantes peuvent être supprimées lors de la reprise de la haute disponibilité |
L'installation du programme ne s'exécute pas sur un système d'exploitation Linux 32 bits pour zSeries |
L'installation de WebSphere Edge Server à l'aide de ./install sur le système d'exploitation Linux 32 bits pour zSeries affiche le message "JVM introuvable".
| Incident : L'installation de WebSphere Edge Server à l'aide de ./install sur le système d'exploitation Linux 32 bits pour zSeries affiche le message "JVM introuvable" |
Sous Linux, le processus de désinstallation échoue |
Le processus de désinstallation de WebSphere Edge Server s'arrête sous Linux.
| Incident : Sous Linux, la désinstallation de WebSphere Edge Server s'arrête |
Tableau 18. Résolution des incidents liés à CBR
Symptôme | Cause possible | Voir. |
CBR ne fonctionne pas correctement | Conflit de numéros de port | Vérification des numéros de port CBR |
Echec de la commande cbrcontrol ou lbadmin, le message "Le serveur ne répond pas" ou "Impossible d'accéder au serveur RMI" s'affiche | Echec des commandes en raison d'une pile mise sur "sock". Ou les commandes n'ont pas abouti car cbrserver n'a pas été lancé | Incident : Echec de la commande cbrcontrol ou lbadmin |
La charge des demandes n'est pas équilibrée | Caching Proxy a été lancé avant l'exécuteur | Incident : Les requêtes ne sont pas équilibrées |
Sous Solaris, la commande cbrcontrol executor start renvoie le message "Erreur : l'exécuteur n'a pas démarré " | Echec de la commande car les valeurs IPC par défaut du système doivent être modifiées ou que le lien d'accès à la bibliothèque est incorrect. | Incident : Sur les systèmes Solaris, la commande cbrcontrol executor start n'aboutit pas |
La règle d'URL ne fonctionne pas | Erreur de syntaxe ou de configuration | Incident : Erreur de syntaxe ou de configuration |
Comportement inattendu de l'interface graphique lors de l'utilisation de systèmes Windows avec une carte vidéo Matrox AGP | Incident lors de l'utilisation de cartes Matrox AGP en cours d'exécution de l'interface graphique de Load Balancer | Incident : Sous Windows, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP |
Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux. | La mémoire est insuffisante pour permettre à Java de traiter une modification de l'interface graphique de cette ampleur | Incident : Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux |
Déconnexion de l'hôte lors de l'administration Web à distance via Netscape | Cette déconnexion se produit lors du redimensionnement de la fenêtre du navigateur | Incident : Déconnexion de l'hôte lors du redimensionnement de la fenêtre du navigateur Netscape en cours d'administration Web |
Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent sur la ligne de commande | Modifiez les propriétés des polices de la fenêtre de l'invite de commande | Incident : Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent dans la fenêtre de l'invite de commande |
Sous HP-UX, le message suivant est généré : java.lang.OutOfMemoryError unable to create new native thread | Certaines installations HP-UX autorisent par défaut 64 unités d'exécution par processus. Cela est suffisant. | Incident : Sous HP-UX, la mémoire est insuffisante pour Java et une erreur d'unité d'exécution s'est produite |
Sous Windows, les conseillers et les cibles à contacter marquent tous les serveurs comme étant arrêtés | Le déchargement des tâches n'est pas désactivé ou il doit activer icmp. | Incident : Sous Windows, les conseillers et les cibles à contacter marquent tous les serveurs comme étant arrêtés |
Sous Windows, la résolution de l'adresse IP en nom d'hôte est impossible lorsque plusieurs adresses sont configurées sur un adaptateur | L'adresse IP que vous voulez comme nom d'hôte doit d'abord apparaître dans le registre. | Incident : Sous Windows, la résolution de l'adresse IP en nom d'hôte n'est pas possible lorsque plusieurs adresses sont configurées sur un adaptateur |
Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de session de terminal à partir de laquelle ils ont été lancés | Utilisez la commande nohup afin que les processus lancés ne reçoivent pas un signal d'arrêt lorsque vous quittez la session de terminal. | Incident : Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de terminal à partir de laquelle ils ont été lancés |
Tableau 19. Résolution des incidents liés à Site Selector
Symptôme | Cause possible | Voir... |
---|---|---|
Site Selector ne s'exécute pas correctement | Conflit de numéros de port | Vérification des numéros de port Site Selector |
Site Selector n'effectue pas de demandes entrantes permutées de façon circulaire à partir des clients Solaris | Les système Solaris exécutent un "démon de mémoire cache de service annuaire" | Incident : Site Selector ne permet pas le trafic de façon circulaire à partir des clients Solaris |
Echec de la commande sscontrol ou lbadmin, le message "Le serveur ne répond pas" ou "Impossible d'accéder au serveur RMI" s'affiche | Echec des commandes en raison d'une pile mise sur "sock". Ou les commandes n'ont pas abouti car ssserver n'a pas été lancé. | Incident : échec de la commande sscontrol ou lbadmin |
Echec du démarrage de ssserver sous Windows | Les systèmes Windows ne nécessitent pas toujours la présence du nom d'hôte dans le système DNS. | Incident : Echec du démarrage de ssserver sous Windows |
Machine ayant des chemins en double pour lequel l'équilibrage de charge ne s'effectue pas correctement -- la résolution de nom semble ne pas aboutir | Machine Site Selector ayant plusieurs cartes associées au même sous-réseau | Incident : Site Selector possède des chemins en double pour lequel l'équilibrage de charge ne s'effectue pas correctement |
Comportement inattendu de l'interface graphique lors de l'utilisation de Windows avec une carte vidéo Matrox AGP | Incident lors de l'utilisation de cartes Matrox AGP en cours d'exécution de l'interface graphique de Load Balancer | Incident : sous Windows, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP |
Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux. | La mémoire est insuffisante pour permettre à Java de traiter une modification de l'interface graphique de cette ampleur | Incident : Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux |
Déconnexion de l'hôte lors de l'administration Web à distance via Netscape | Cette déconnexion se produit lors du redimensionnement de la fenêtre du navigateur | Incident : Déconnexion de l'hôte lors du redimensionnement de la fenêtre du navigateur Netscape en cours d'administration Web |
Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent sur la ligne de commande | Modifiez les propriétés des polices de la fenêtre de la ligne de commande | Incident : Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent dans la fenêtre de l'invite de commande |
Sous HP-UX, le message suivant est généré : java.lang.OutOfMemoryError unable to create new native thread | Certaines installations HP-UX autorisent par défaut 64 unités d'exécution par processus. Cela est suffisant. | Incident : Sous HP-UX, la mémoire est insuffisante pour Java et une erreur d'unité d'exécution s'est produite |
Sous Windows, les conseillers et les cibles à contacter marquent tous les serveurs comme étant arrêtés | Le déchargement des tâches n'est pas désactivé ou il doit activer icmp. | Incident : Sous Windows, les conseillers et les cibles à contacter marquent tous les serveurs comme étant arrêtés |
Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de session de terminal à partir de laquelle ils ont été lancés | Utilisez la commande nohup afin que les processus lancés ne reçoivent pas un signal d'arrêt lorsque vous quittez la session de terminal. | Incident : Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de terminal à partir de laquelle ils ont été lancés |
Tableau 20. Résolution des incidents liés à Controller for Cisco CSS Switches
Symptôme | Cause possible | Voir... |
---|---|---|
échec du lancement de ccoserver | Conflit de numéros de port | Vérification des numéros de port Cisco CSS Controller |
Echec de la commande ccocontrol ou lbadmin, le message "Le serveur ne répond pas" ou "Impossible d'accéder au serveur RMI" s'affiche | Echec des commandes en raison d'une pile mise sur "sock". Ou les commandes n'aboutissent pas car ccoserver n'a pas été lancé. | Incident : Echec de la commande ccocontrol ou lbadmin |
Erreur de réception : Impossible de créer un registre sur le port 13099 | Licence du produit expirée | Incident : Impossible de créer un registre sur le port 13099 |
Comportement inattendu de l'interface graphique lors de l'utilisation de Windows avec une carte vidéo Matrox AGP | Incident lors de l'utilisation de cartes Matrox AGP en cours d'exécution de l'interface graphique de Load Balancer | Incident : Sous Windows, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP |
Réception d'une erreur de connexion lors de l'ajout d'un consultant | Paramètres de configuration incorrects sur le commutateur ou le contrôleur | Incident : Réception d'une erreur de connexion lors de l'ajout d'un consultant |
Pondérations non actualisées sur le commutateur | Communication entre le contrôleur et le commutateur impossible ou interrompue | Incident : Pondérations non actualisées sur le commutateur |
La commande de régénération n'a pas actualisé la configuration du consultant | Communication entre le commutateur et le contrôleur impossible ou interrompue | Incident : La commande d'actualisation n'a pas mis à jour la configuration du consultant |
Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux. | La mémoire est insuffisante pour permettre à Java de traiter une modification de l'interface graphique de cette ampleur | Incident : Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux |
Déconnexion de l'hôte lors de l'administration Web à distance via Netscape | Cette déconnexion se produit lors du redimensionnement de la fenêtre du navigateur | Incident : déconnexion de l'hôte lors du redimensionnement de la fenêtre du navigateur Netscape en cours d'administration Web |
Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent sur la ligne de commande | Modifiez les propriétés des polices de la fenêtre de la ligne de commande | Incident : Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent dans la fenêtre de l'invite de commande |
Sous HP-UX, le message suivant est généré : java.lang.OutOfMemoryError unable to create new native thread | Certaines installations HP-UX autorisent par défaut 64 unités d'exécution par processus. Cela est suffisant. | Incident : Sous HP-UX, la mémoire est insuffisante pour Java et une erreur d'unité d'exécution s'est produite |
Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de session de terminal à partir de laquelle ils ont été lancés | Utilisez la commande nohup afin que les processus lancés ne reçoivent pas un signal d'arrêt lorsque vous quittez la session de terminal. | Incident : Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de terminal à partir de laquelle ils ont été lancés |
Tableau 21. Résolution des incidents liés à Nortel Alteon Controller
Symptôme | Cause possible | Voir... |
---|---|---|
échec du lancement de nalserver | Conflit de numéros de port | Vérification des numéros de port Nortel Alteon Controller |
Echec de la commande nalcontrol ou lbadmin, le message "Le serveur ne répond pas" ou "Impossible d'accéder au serveur RMI" s'affiche | Echec des commandes en raison d'une pile mise sur "sock". Ou les commandes n'ont pas abouti car nalserver n'a pas été lancé. | Incident : Echec de la commande nalcontrol ou lbadmin |
Erreur de réception : Impossible de créer un registre sur le port 14099 | Licence du produit expirée | Incident : Impossible de créer un registre sur le port 14099 |
Comportement inattendu de l'interface graphique lors de l'utilisation de Windows avec une carte vidéo Matrox AGP | Incident lors de l'utilisation de cartes Matrox AGP en cours d'exécution de l'interface graphique de Load Balancer | Incident : Sous Windows, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP |
Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux. | La mémoire est insuffisante pour permettre à Java de traiter une modification de l'interface graphique de cette ampleur | Incident : Arrêt (ou comportement imprévu) de l'interface graphique lors de la tentative de chargement d'un fichier de configuration volumineux |
Déconnexion de l'hôte lors de l'administration Web à distance via Netscape | Cette déconnexion se produit lors du redimensionnement de la fenêtre du navigateur | Incident : Déconnexion de l'hôte lors du redimensionnement de la fenêtre du navigateur Netscape en cours d'administration Web |
Réception d'une erreur de connexion lors de l'ajout d'un consultant | Paramètres de configuration incorrects sur le commutateur ou le contrôleur | Incident : Réception d'une erreur de connexion lors de l'ajout d'un consultant |
Pondérations non actualisées sur le commutateur | Communication entre le contrôleur et le commutateur impossible ou interrompue | Incident : Pondérations non actualisées sur le commutateur |
La commande de régénération n'a pas actualisé la configuration du consultant | Communication entre le commutateur et le contrôleur impossible ou interrompue | Incident : La commande d'actualisation n'a pas mis à jour la configuration du consultant |
Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent sur la ligne de commande | Modifiez les propriétés des polices de la fenêtre de la ligne de commande | Incident : Sous Windows, des caractères nationaux Latin-1 endommagés apparaissent dans la fenêtre de l'invite de commande |
Sous HP-UX, le message suivant est généré : java.lang.OutOfMemoryError unable to create new native thread | Certaines installations HP-UX autorisent par défaut 64 unités d'exécution par processus. Cela est suffisant. | Incident : Sous HP-UX, la mémoire est insuffisante pour Java et une erreur d'unité d'exécution s'est produite |
Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de session de terminal à partir de laquelle ils ont été lancés | Utilisez la commande nohup afin que les processus lancés ne reçoivent pas un signal d'arrêt lorsque vous quittez la session de terminal. | Incident : Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de terminal à partir de laquelle ils ont été lancés |
Tableau 22. Résolution des incidents liés à Metric Server
Symptôme | Cause possible | Voir... |
---|---|---|
Sous Windows, IOException de Metric Server lors de l'exécution de fichiers de mesures utilisateur de format .bat ou .cmd | Le nom complet des mesures est obligatoire | Incident : Sous Windows, IOException de Metric Server lors de l'exécution de fichiers de mesures utilisateur de format .bat ou .cmd |
Le système Metric Server ne fournit pas à la machine Load Balancer les informations relatives à la charge. | Causes possibles :
| Incident : Metric Server n'indique pas les charges à la machine Load Balancer |
L'entrée "Signature is necessary for access to agent" (signature nécessaire pour accéder à l'agent) apparaît dans le journal de la machine Metric Server lors du transfert des fichiers de clés vers le serveur | Echec de l'autorisation du fichier de clés en raison d'une altération. | Incident : Le journal de Metric Server indique qu'une signature est nécessaire pour accéder à l'agent |
Sur les systèmes AIX, lorsque Metric Server s'exécute dans des conditions difficiles sur un système multiprocesseur (AIX 4.3.3 ou AIX 5.1), il est possible que le résultat de la commande ps -vg soit altéré | Le correctif APAR IY33804 rectifie cet incident AIX identifié | Incident : Sur les systèmes AIX, lorsque Metric Server s'exécute dans des conditions difficiles, il est possible que le résultat de la commande ps vg soit altéré |
Configuration de Metric Server à deux niveaux avec l'équilibrage de charge de Site Selector entre des machines Dispatcher haute disponibilité | Metric Server (dans une configuration de second niveau) n'est pas configuré pour écouter une nouvelle adresse IP. | Incident : Configuration de Metric Server dans une configuration de second niveau avec équilibrage de la charge entre des machines Dispatcher haute disponibilité par Site Selector |
Les scripts (metricserver, cpuload, memload) exécutés sur des machines Solaris dotées de plusieurs CPU génèrent des messages de console non souhaités | Ce comportement est dû à l'utilisation de la commande système VMSTAT pour collecter des statistiques sur la CPU et la mémoire à partir du noyau. | Incident : Les scripts exécutés sur des machines Solaris dotées de plusieurs CPU génèrent des messages de console non souhaités |
Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de session de terminal à partir de laquelle ils ont été lancés | Utilisez la commande nohup afin que les processus lancés ne reçoivent pas un signal d'arrêt lorsque vous quittez la session de terminal. | Incident : Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de terminal à partir de laquelle ils ont été lancés |
La valeur de mesure renvoie -1 après le démarrage de Metric Server | Cet incident peut provenir de la perte d'intégrité des fichiers de clés lors de leur transfert au client. | Incident : Après le démarrage de Metric Server, la valeur de mesure renvoie -1 |
En cas d'incidents lors de l'exécution de Dispatcher, il se peut que l'une des applications utilise un numéro de port généralement utilisé par Dispatcher. A noter que le serveur Dispatcher utilise les numéros de port suivants :
Si une autre application utilise l'un des numéros de port Dispatcher, vous pouvez soit modifier les numéros de port Dispatcher, soit modifier le numéro de port de l'application.
Pour modifier les numéros de port de Dispatcher, procédez comme suit :
Modifiez le numéro du port RMI de l'application, comme suit :
En cas d'incidents lors de l'exécution de CBR, il se peut que l'une des applications utilise un numéro de port généralement utilisé par CBR. Prenez en compte que CBR utilise le numéro de port suivant :
Si une autre application utilise l'un des numéros de port CBR, vous pouvez soit modifier les numéros de port de CBR, soit modifier le numéro de port de l'application.
Pour modifier les numéros de port de CBR, procédez comme suit :
Modifiez le numéro du port RMI de l'application, comme suit :
En cas d'incidents lors de l'exécution du composant Site Selector, il se peut que l'une des applications utilise un numéro de port généralement utilisé par Site Selector. A noter que Site Selector utilise les numéros de port suivants :
Si une autre application utilise l'un des numéros de port Site Selector, vous pouvez soit modifier les numéros de port Site Selector, soit modifier le numéro de port de l'application.
Pour modifier les numéros de port de Site Selector, procédez comme suit :
Modifiez le numéro du port RMI de l'application, comme suit :
En cas d'incidents lors de l'exécution du composant Cisco CSS Controller, il se peut que l'une des applications utilise un numéro de port généralement utilisé par le serveur Cisco CSS Controller. A noter que Cisco CSS Controller utilise les numéros de port suivants :
13099 pour recevoir des commandes de ccocontrol
10004 pour envoyer des demandes de mesure au système Metric Server
13199 pour le port du serveur RMI
Si une autre application utilise l'un des numéros de port Cisco CSS Controller, vous pouvez soit modifier les numéros de port Cisco CSS Controller, soit modifier le numéro de port de l'application.
Pour modifier les numéros de port de Cisco CSS Controller, procédez comme suit :
Modifiez le numéro du port RMI de l'application, comme suit :
En cas d'incidents lors de l'exécution du composant Nortel Alteon Controller, il se peut que l'une des applications utilise un numéro de port généralement utilisé par le serveur Nortel Alteon Controller. A noter que Nortel Alteon Controller utilise les numéros de port suivants :
14099 pour recevoir les commandes de nalcontrol
10004 pour envoyer des demandes de mesure au système Metric Server
14199 pour le port du serveur RMI
Si une autre application utilise l'un des numéros de port Nortel Alteon Controller, vous pouvez soit modifier les numéros de port de Nortel Alteon Controller, soit modifier le numéro de port de l'application.
Pour modifier les numéros de port Nortel Alteon Controller, procédez comme suit :
Modifiez le numéro du port RMI de l'application, comme suit :
Cet incident se produit lorsqu'une autre application utilise l'un des ports utilisés par Dispatcher. Pour plus d'informations, voir Vérification des numéros de port Dispatcher.
Cet incident se produit lorsque qu'une adresse autre que l'adresse spécifiée est utilisée. Lorsque vous placez le Dispatcher et le serveur sur le même poste, assurez-vous que l'adresse NFA est utilisée ou est configurée comme utilisant le même poste. Vérifiez également l'adresse dans le fichier hôte.
Les symptômes de cet incident sont l'absence de prise en charge des connexions des machines client ou le dépassement du délai des connexions. Effectuez les contrôles suivants pour diagnostiquer cet incident :
Sous Windows et les autres plateformes, voir également Configuration des serveurs pour l'équilibrage de charge.
Cet incident se produit lorsqu'un environnement de haute disponibilité Dispatcher est configuré et que les connexions à partir des machines client ne sont pas prises en charge ou que le délai imparti à ces connexions est dépassé. Effectuez les contrôles suivants pour corriger ou diagnostiquer l'incident :
Les étapes suivantes permettent de vérifier de manière efficace que les scripts de haute disponibilité fonctionnent correctement :
Ces deux rapports sont identiques si les scripts sont correctement configurés.
Cette erreur Windows se produit lorsque l'adresse source n'est pas configurée sur un adaptateur. Effectuez les contrôles suivants pour corriger ou diagnostiquer l'incident :
dscontrol executor configure <adresse IP>
Après la configuration des serveurs, il se peut qu'une ou plusieurs routes supplémentaires aient été créées par inadvertance. Si elles ne sont pas supprimées, ces routes empêchent l'exécution de Dispatcher. Pour vérifier et supprimer ces routes, voir Configuration des serveurs pour l'équilibrage de charge.
Si vous utilisez un support de réseau étendu et que les conseillers ne semblent pas fonctionner correctement, vérifiez qu'ils sont bien lancés sur les répartiteurs locaux et distants.
Une commande ping ICMP est envoyée aux serveurs avant la demande du conseiller. S'il existe un pare-feu entre Load Balancer et les serveurs, vérifiez qu'il autorise les commandes ping. Si cette configuration pose un problème de sécurité pour votre réseau, modifiez l'instruction java dans dsserver pour désactiver toutes les commandes ping vers les serveurs en ajoutant la propriété java suivante :
LB_ADV_NO_PING="true" java -DLB_ADV_NO_PING="true"
Voir Utilisation de conseillers distants avec le support de réseau étendu de Dispatcher.
Lorsque vous utilisez Dispatcher, Microsoft IIS et SSL, s'ils ne fonctionnent pas ensemble, il se peut qu'un incident lié à la sécurité SSL se soit produit. Pour plus d'informations sur la génération d'une paire de clés, l'acquisition d'un certificat, l'installation d'un certificat avec une paire de clés et la configuration d'un répertoire pour SSL, voir la documentation Microsoft Information and Peer Web Services.
Dispatcher utilise des clés pour vous permettre de vous connecter à une machine distante et la configurer. Les clés indiquent un port RMI pour la connexion. Il est possible de changer de port RMI pour des raisons de sécurité ou de conflits. Lorsque vous changez les ports RMI, le nom de fichier ou la clé est différent(e). Si votre répertoire contient plusieurs clés pour la même machine distante et qu'elles indiquent des ports RMI différents, l'invite de commande essaie la première qu'elle trouve. Si elle n'est pas appropriée, la connexion est refusée. La connexion ne sera établie que si vous supprimez la clé incorrecte.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Ceci peut être source de problèmes lorsqu'une des consoles d'administration s'exécute sur la même machine qu'un pare-feu ou passe par un pare-feu. Par exemple, lorsque Load Balancer s'exécute sur la même machine qu'un pare-feu alors que vous exécutez des commandes dscontrol, des erreurs de type Erreur : aucune réponse du serveur peuvent s'afficher.
Pour éviter ce type d'incident, modifiez le fichier script ndserver afin de définir le port qu'utilise RMI pour le pare-feu (ou autre application). Remplacez la ligne LB_RMISERVERPORT=10199 par LB_RMISERVERPORT= votrePort. Où votrePort est un autre port.
Lorsque vous avez terminé, réexécutez la commande dsserver et ouvrez le trafic des ports 10099, 10004, 10199 et 10100 ou du port d'adresse hôte choisi pour l'exécution de la console d'administration.
Par exemple : java -Djava.rmi.server.hostname="10.1.1.1"
Sous Windows, lorsque vous utilisez Netscape en tant que navigateur par défaut, le message d'erreur suivant peut s'afficher : "Impossible de trouver le fichier '<nomfichier>.html' (ou l'un de ses composants). Vérifiez que le chemin et le nom de fichier sont corrects et que toutes les bibliothèques nécessaires sont disponibles.
Le problème est dû à un réglage incorrect pour l'association de fichier HTML. La solution est la suivante :
Pour que l'interface graphique, lbadmin, fonctionne correctement, vous devez disposer d'une quantité d'espace de pagination suffisante. Dans le cas contraire, l'interface graphique peut ne pas démarrer complètement. Si cela se produit, vérifiez l'espace de pagination et augmentez-la si nécessaire.
Si vous désinstallez Load Balancer afin de réinstaller une autre version et qu'une erreur se produit lorsque vous démarrez le composant Dispatcher, vérifiez si Caching Proxy est installé. Caching Proxy est lié à l'un des fichiers Dispatcher. Ce fichier se désinstalle une fois la désinstallation de Caching Proxy terminée.
Pour résoudre ce problème :
Si des incidents relatifs à l'apparence de l'interface graphique de Load Balancer se produisent, vérifiez la configuration de la résolution du bureau du système d'exploitation. Pour un affichage de l'interface graphique optimal, nous vous recommandons d'utiliser une résolution de 1024x768 pixels.
Sous Windows, lorsque vous ouvrez la fenêtre d'aide, cette dernière peut disparaître en arrière-plan sous les fenêtres existantes. Si cela se produit, cliquez sur la fenêtre pour qu'elle s'affiche à nouveau en premier plan.
Sous Solaris, chaque carte réseau possède la même adresse MAC par défaut. Cela fonctionne correctement lorsque chaque carte se trouve sur un sous-réseau IP différent. Cependant, dans un environnement commuté, lorsque plusieurs cartes NIC ayant la même adresse MAC et la même adresse de sous-réseau IP communiquent avec le même commutateur, ce dernier envoie l'ensemble du trafic associé à l'adresse MAC (et aux adresses IP) via le même câble. Seule la carte ayant la dernière placé un cadre sur ce réseau voit les paquets IP associés aux deux cartes. Solaris peut ignorer les paquets d'une adresse IP valide arrivant à l'interface "incorrecte".
Si toutes les interfaces réseau ne sont pas conçues pour Load Balancer conformément à la configuration définie dans le fichier ibmlb.conf, et que la carte NIC non définie dans ibmlb.conf reçoit un cadre, Load Balancer ne peut ni traiter ni transmettre le cadre.
Pour éviter ce problème, vous devez remplacer la valeur par défaut et définir une adresse unique pour chaque interface. Utilisez cette commande :
ifconfig interface ether adressemac
Exemple :
ifconfig eri0 ether 01:02:03:04:05:06
Sous Windows, vous devez avoir une carte réseau installée et configurée avant le démarrage de l'exécuteur.
Le système d'exploitation AIX contient une fonction de mise en réseau appelée Path MTU Discovery. Lors d'une transaction avec un client, si le système d'exploitation détermine qu'une unité de transmission maximale (MTU) inférieure doit être utilisée pour les paquets sortants, la fonction Path MTU Discovery entraîne la création par AIX d'une route de rappel de cette unité. La nouvelle route est réservée à cette adresse IP client et enregistre l'unité MTU qui permet d'atteindre celle-ci.
Lors de la création de la route, un incident peut survenir sur les serveurs en raison de l'association du cluster à un alias sur l'unité de bouclage. Si l'adresse de la passerelle pour la route entre dans le sous-réseau du cluster ou du masque réseau, les systèmes AIX créent la route sur l'unité de bouclage. Cet événement s'est produit car il s'agissait de l'alias de la dernière interface associé à ce sous-réseau.
Par exemple, si le cluster s'appelle 9.37.54.69, le masque réseau 255.255.255.0 et la passerelle prévue 9.37.54.1, les systèmes AIX utilisent l'unité de bouclage pour la route. En raison de cette action, les réponses du serveur ne sortent jamais et le client dépasse le délai d'attente. Habituellement, le client voit une réponse du cluster, puis il ne reçoit plus rien lorsque la route est créée.
Deux solutions permettent de pallier cet incident :
Remarques :
Lorsque vous configurez un mode WAND (Wide Area Load Balancer), vous devez définir la répartiteur distante en tant que serveur d'un cluster sur votre répartiteur locale. Habituellement, vous utilisez l'adresse de non-réacheminement (NFA) de la répartiteur distante pour l'adresse de destination du serveur distant. Dans ce cas, si vous configurez ensuite sur le répartiteur distant la fonction haute disponibilité, cette dernière reste inopérante. La cause : le répartiteur local désigne toujours le poste principal côté distant lorsque vous utilisez l'adresse NFA.
Pour éviter cet incident :
Lorsque le répartiteur principal distant entre en service, elle associe cette adresse à un alias sur la carte, permettant ainsi l'acceptation du trafic. En cas de défaillance, l'adresse se déplace sur la machine de secours qui continue à accepter le trafic destiné à cette adresse.
Lors de l'utilisation d'une administration lbadmin ou Web (lbwebaccess) pour charger un fichier de configuration volumineux (200 commandes add ou plus), l'interface graphique peut s'arrêter ou avoir un comportement imprévu, comme un temps de réponse excessif lorsque vous apportez des modifications à l'écran.
Cela vient du fait que la mémoire est insuffisante pour permettre à Java de traiter une configuration de cette ampleur.
L'environnement d'exécution dispose d'une option permettant d'augmenter la mémoire disponible dont peut disposer Java.
Il s'agit de l'option -Xmxn où n correspond à la taille maximale, en octets, de la mémoire. n doit être un multiple de 1024 et supérieur à 2 Mo. La valeur n peut être suivie du caractère k ou K pour indiquer qu'il s'agit de kilo-octets ou du caractère m ou M pour indiquer qu'il s'agit de méga-octets. Par exemple, -Xmx128M et -Xmx81920k sont valides. La valeur par défaut est 64M. Solaris 8 accepte une valeur maximale de 4000M.
Par exemple, pour ajouter cette option, ouvrez le fichier script lbadmin, modifiez "javaw" en "javaw -Xmxn" comme suit. (Pour les systèmes AIX, modifiez "java" en "java -Xmxn") :
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH% %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
Aucune valeur n particulière n'est recommandée, mais elle doit être supérieure à l'option par défaut. Pour commencer, vous pouvez doubler cette dernière.
Si l'administration Load Balancer (lbadmin) se déconnecte du serveur après mise à jour de la configuration, vérifiez la version de dsserver vous essayez de configurer sur le serveur et qu'il s'agit de la même version que celle de lbadmin ou dscontrol.
Lorsqu'un client distant est utilisé sur une implémentation SSL, des noms d'hôtes ou des noms de domaines complets ne sont pas correctement convertis en adresses IP au format d'adresse IP. L'implémentation SSL doit ajouter à la résolution des noms de domaines des données propres à la connexion.
Si les adresses IP ne sont pas correctement résolues sur la connexion distante, indiquez l'adresse IP au format d'adresse IP.
Pour rectifier les problèmes de chevauchement de polices ou de polices indésirables sur l'interface coréenne de Load Balancer, procédez comme suit :
Systèmes AIX
-Monotype-TimesNewRomanWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
Systèmes Linux
-monotype- timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
Sous Windows, lorsqu'un alias a été attribué à l'unité de bouclage de MS, le système d'exploitation renvoie l'adresse d'alias au lieu de l'adresse locale lors de l'émission d'une commande telle que hostname. Pour rectifier cette erreur, veillez à placer le nouvel alias au-dessous de l'adresse locale dans la liste des connexions réseau. Ainsi, l'adresse locale est utilisée avant l'alias de bouclage.
Pour consulter la liste des connexions réseau, procédez comme suit :
Sous Windows, l'interface graphique de Load Balancer peut se comporter de manière inattendue lorsque vous utilisez une carte vidéo Matrox AGP. Lorsque vous cliquez sur un bouton de la souris, un espace légèrement plus large que le pointeur de la souris peut être altéré avec inversion possible de la mise en évidence ou déplacement des images sur l'écran. Les anciennes cartes Matrox n'ont pas présenté ce type de comportement. Il n'existe pas de rectificatif pour les cartes Matrox AGP.
Sur les systèmes Linux, si dsserver est encore actif lors du retrait manuel du module Load Balancer du noyau, un comportement inattendu, tel qu'un arrêt du système ou des noyaux java, peut se produire. Avant de retirer manuellement du noyau le module Load Balancer, vous devez arrêter dsserver.
Si la commande "dsserver stop" ne fonctionne pas, arrêtez le processus Java avec SRV_KNDConfigServer. Pour arrêtez le processus, recherchez l'identifiant correspondant à l'aide de la commande ps -ef | grep SRV_KNDConfigServer, puis mettez fin à ce processus à l'aide de la commande kill id_processus.
Vous pouvez, en toute sécurité, exécuter la commande "rmmod ibmlb" de retrait du noyau du module Load Balancer.
Si vous exécutez le composant Dispatcher pour l'équilibrage de charge, le trafic client peut surcharger l'ordinateur. Le module Load Balancer du noyau est hautement prioritaire, et s'il gère constamment des paquets de clients, il est possible que le reste du système ne réponde plus. L'exécution de commandes dans l'espace utilisateur peut être très longue ou ne jamais se terminer.
Dans ce cas, vous devez restructurer votre configuration de sorte que le trafic ne surcharge pas la machine Load Balancer. Vous pouvez également répartir la charge sur plusieurs machines Load Balancer ou remplacer votre machine par un ordinateur plus performant et plus rapide.
Lorsque vous essayez de déterminer si la longueur des temps de réponse provient d'un volume important de trafic client, vérifiez si cela se produit aux heures de pointe. Une mauvaise configuration des systèmes entraînant des boucles de routage peut provoquer le même incident. Mais avant de modifier la configuration de Load Balancer, vérifiez si les symptômes ne sont pas liés à une charge trop importante au niveau du client.
Lorsque vous utilisez la méthode d'acheminement MAC, Load Balancer envoie des paquets aux serveurs en utilisant l'adresse du cluster pour laquelle un alias a été défini sur l'unité de bouclage. Certaines applications serveurs (telle SSL) exigent que les informations de configuration (tels les certificats) soient définies en fonction de l'adresse IP. L'adresse IP doit être l'adresse du cluster configurée sur l'unité de bouclage de façon à correspondre au contenu des paquets entrants. Si vous ne configurez pas l'application serveur avec l'adresse IP du cluster, la demande client n'est pas correctement acheminée vers le serveur.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) du navigateur Netscape dans lequel s'affiche l'interface graphique de Load Balancer. En effet, étant donné que Netscape recharge une page à chaque redimensionnement de la fenêtre du navigateur, une déconnexion de l'hôte en découle. Vous devez donc vous reconnecter à l'hôte après chaque modification de la taille de la fenêtre. Si vous réalisez l'administration Web à distance basée sur une plateforme Windows, utilisez Internet Explorer.
Lorsque vous exécutez le serveur Microsoft IIS, version 5.0 sur des serveurs d'arrières-plan Windows, vous devez configurer le serveur Microsoft IIS en tant que serveur de liaison. Sinon, le regroupement de connexions est activé par défaut, et le serveur Web établit une liaison à 0.0.0.0 et écoute la totalité du trafic, au lieu d'établir une liaison aux adresses IP virtuelles configurées en tant qu'identificateurs multiples pour le site. Si une application de l'hôte local s'arrête alors que le regroupement de connexions est activé, les conseillers des serveurs AIX ou Windows ND détectent cet arrêt. En revanche, si l'application d'un hôte virtuel s'arrête alors que l'hôte local reste actif, les conseillers ne détectent pas l'incident et le serveur Microsoft IIS continue à répondre à la totalité du trafic, y compris à celui de l'application arrêtée.
Pour déterminer si le regroupement de connexions est activé et si le serveur Web établit une liaison à 0.0.0.0, exécutez la commande suivante :
netstat -an
Les instructions de configuration du serveur Microsoft IIS en tant que serveur de liaison (qui désactive le regroupement de connexions), sont disponibles sur le site Web de Microsoft Aide et Support. Selon l'information recherchez, vous pouvez également vous rendre sur les sites suivants :
Dans une fenêtre de ligne de commande du système d'exploitation Windows, certains caractères nationaux de la famille Latin-1 sont altérés. Par exemple, la lettre "a" avec tilde s'affiche sous la forme d'un symbole pi. Pour rectifier cette erreur, vous devez modifier les propriétés de police de la fenêtre de ligne de commande. Pour modifier la police, procédez comme suit :
Certaines installations HP-UX 11i sont préconfigurées pour n'autoriser que 64 unités d'exécution par processus. Toutefois, certaines configurations Load Balancer en requièrent davantage. Pour les systèmes HP-UX, définissez les unités d'exécution par processus sur au moins 256. Pour augmenter cette valeur, utilisez l'utilitaire "sam" pour définir le paramètre de noyau max_thread_proc. Si vous pensez avoir besoin d'un nombre d'unités d'exécution plus important, vous pouvez affecter à ce paramètre une valeur supérieure à 256.
Pour augmenter la valeur du paramètre max_thread_proc, procédez comme suit :
Lorsque vous configurez votre adaptateur sur une machine Load Balancer, vous devez vérifier que les deux paramètres suivants sont corrects pour que le conseiller puisse fonctionner :
Sous Windows, lorsque vous configurez un adaptateur avec plusieurs adresses IP, configurez d'abord dans le registre l'adresse IP à affilier au nom d'hôte.
Load Balancer dépendant de InetAddress.getLocalHost() dans de nombreuses instances (par exemple, lbkeys create), l'attribution comme alias de plusieurs adresses IP à un même adaptateur peut être source d'incident. Pour éviter cela, entrez l'adresse IP à utiliser pour la résolution du nom d'hôte en premier dans le registre. Exemple :
Par défaut, lorsque le système d'exploitation Windows détecte une panne réseau, il efface sa mémoire cache ARP (protocole de résolution d'adresse) et toutes les entrées statiques. Lorsque le réseau est à nouveau disponible, la mémoire cache ARP est de nouveau alimentée par les demandes ARP envoyées sur le réseau.
Dans une configuration en haute disponibilité, les deux serveurs assurent les opérations principales lorsqu'une perte de la connectivité réseau affecte l'un d'eux. Lorsque la demande ARP est envoyée pour alimenter la mémoire cache ARP, les deux serveurs répondent et la mémoire cache ARP marque alors l'entrée comme non valide. Par conséquent, les conseillers ne peuvent pas créer de socket vers les serveurs de secours.
Vous pouvez résoudre cet incident en empêchant Windows d'effacer la mémoire cache ARP lors d'une perte de connectivité. Microsoft a publié un article expliquant comment effectuer cette tâche. Cet article se trouve sur le site Web de Microsoft, dans la base de connaissances Microsoft (référence 239924), à l'adresse suivante : http://support.microsoft.com/default.aspx?scid=kb;en-us;239924.
Vous trouverez ci-après un récapitulatif des étapes, décrites dans l'article Microsoft, permettant d'empêcher le système d'effacer la mémoire cache ARP.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Certaines considérations doivent être prises en compte lors de l'utilisation de serveurs Linux (noyau 2.4.x) et de la méthode d'acheminement MAC de Dispatcher. Si une adresse de cluster a été configurée pour le serveur sur l'unité de bouclage à l'aide de la commande ip address add , vous ne pouvez attribuez un alias qu'à une seule adresse de cluster.
Lorsque vous affectez un alias à plusieurs clusters sur l'unité de bouclage, utilisez la commande ifconfig (par exemple,
ifconfig lo:num adresse du cluster netmask 255.255.255.255 up
En outre, les méthodes de configuration d'interface ifconfig et ip sont incompatibles. La meilleure pratique consiste, pour un site, à choisir une méthode et à ne pas en changer.
Lors de l'ajout de serveurs à la configuration Dispatcher, le message d'erreur suivant peut être généré : "Erreur : Adresse de routeur non spécifiée ou non valide pour la méthode port".
Utilisez cette liste de contrôle pour identifier l'incident :
Par défaut, le paramètre router a la valeur 0, ce qui indique que le serveur est local. Lorsque vous définissez l'adresse du routeur du serveur à une valeur autre que 0, cela indique qu'il s'agit d'un serveur distant, installé dans un sous-réseau différent. Pour plus d'informations sur le paramètre router dans la commande d'ajout de serveur, voir dscontrol server -- Configuration des serveurs.
Si le serveur ajouté est installé dans un sous-réseau différent, le paramètre router doit correspondre à l'adresse du routeur devant être utilisé dans le sous-réseau local pour communiquer avec le serveur distant.
Sur les systèmes Solaris, si vous démarrez les scripts Load Balancer (tels que dsserver ou lbadmin) à partir d'une fenêtre de terminal et que vous quittez cette dernière, le processus Load Balancer s'arrête.
Pour résoudre cet incident, démarrez les scripts Load Balancer à l'aide de la commande nohup. Par exemple : nohup dsserver. Cette commande permet d'éviter que les processus lancés à partir de la session de terminal ne reçoive un signal d'arrêt du terminal lorsque ce dernier est fermé. L'exécution du processus peut ainsi se poursuivre même après la fermeture de la session de terminal. Spécifiez la commande nohup avant les scripts Load Balancer dont le traitement doit continuer après la fermeture d'une session de terminal.
Le chargement d'une configuration Load Balancer peut prendre un certain temps en raison des appels DNS effectués pour résoudre et vérifier l'adresse du serveur.
Si le système DNS de la machine Load Balancer n'est pas correctement configuré ou s'il prend du temps, le chargement de la configuration ralentit à cause de l'envoi des demandes DNS sur le réseau par les processus Java.
Une solution consiste à ajouter les adresses et les noms d'hôte du serveur au fichier local /etc/hosts.
Si la fonction de haute disponibilité est configurée, il est possible que des adresses de cluster soient définies sur les deux systèmes pendant une courte période et que le système génère l'affichage d'un message d'erreur pour indiquer un conflit d'adresses IP avec un autre système du réseau. Dans ce cas, vous pouvez ignorer ce message. Il est possible qu'une adresse de cluster soit configurée en même temps sur les deux systèmes de haute disponibilité, notamment lors du démarrage de chaque système ou lors de l'initiation d'une procédure de reprise.
Vérifiez les scripts go* pour vous assurer que vous avez défini ou supprimé correctement les configurations des adresses de cluster. Si vous avez exécuté un fichier de configuration et installé des scripts go*, vérifiez que des commandes "executor configure" n'ont pas été définies pour les adresses de cluster dans le fichier de configuration car ces commandes entrent en conflit avec les commandes de configuration et de suppression de configuration indiquées dans les scripts go*.
Pour plus d'informations sur les scripts go* lors de la configuration de la fonction de haute disponibilité, voir Utilisation des scripts.
Cet incident peut survenir lorsque les scripts go ne sont pas exécutés sur la machine principale ou la machine de secours. Ces scripts ne peuvent pas s'exécuter si dsserver n'est pas démarré sur les deux machines. Vérifiez sur les deux machines que dsserver est en cours d'exécution.
Les demandes client générant des réponses de grande page arrivent à expiration si la taille maximale en transmission (MTU) n'est pas définie correctement sur le répartiteur. En effet, pour les méthodes de transfert cbr et nat du composant Dispatcher, Dispatcher utilise la valeur MTU par défaut au lieu de la négocier.
La valeur MTU est définie sur chaque système d'exploitation en fonction du type de support de communication (par exemple, Ethernet ou Token-Ring). La valeur MTU des routeurs du segment local peut être inférieure si ces derniers se connectent à un autre type de support de communication. Dans le cas d'un trafic TCP normal, une négociation MTU survient lors de la configuration de la connexion et la valeur MTU la plus faible est utilisée pour envoyer des données entre les machines.
Dispatcher ne prend pas en charge la négociation de la valeur MTU pour sa méthode de transfert cbr ou nat car il est activement impliqué comme noeud final des connexions TCP. Pour les méthodes de transfert cbr et nat, Dispatcher utilise par défaut la valeur MTU 1500 . Cette valeur correspondant à la taille type de MTU pour un réseau Ethernet standard, la plupart des clients n'ont pas besoin de la modifier.
Lorsque vous utilisez la méthode de transfert cbr ou nat de Dispatcher, si vous disposez d'un routeur vers le segment local dont la valeur MTU est la plus faible, vous devez définir la même valeur MTU sur le répartiteur.
Pour résoudre cet incident, définissez la taille de segment maximale (mss) à l'aide de la commande suivante : dscontrol executor set mss nouvelle_valeur
Exemple :
dscontrol executor set mss 1400
La valeur par défaut de mss est 1460.
Le paramètre mss ne s'applique pas à la méthode d'acheminement Mac de Dispatcher ou à tout composant de Load Balancer autre que Dispatcher.
Lorsqu'il existe plusieurs adresses IP sur un système Windows et que le fichier hôte ne spécifie pas l'adresse à associer au nom d'hôte, le système d'exploitation choisit d'associer au nom d'hôte l'adresse la plus petite.
Pour résoudre cet incident, remplacez le fichier c:\Windows\system32\drivers\etc\hosts par le nom d'hôte de votre machine et l'adresse IP à lui associer.
IMPORTANT : L'adresse IP ne peut pas correspondre à une adresse de cluster.
Lors de l'utilisation de la haute disponibilité sur des systèmes Linux pour S/390 avec le pilote réseau qeth, la synchronisation des machines Dispatcher active et de secours risque d'échouer. Il se peut que cet incident soit limiter au noyau 2.6 de Linux.
Si cet incident survient, procédez comme suit :
Définissez un périphérique réseau CTC (canal à canal) entre les images Dispatcher actives et de secours et ajoutez un signal de présence entre les adresses IP des deux noeuds CTC.
Avec la fonction de haute disponibilité pour Load Balancer, une machine partenaire peut prendre le relais de l'équilibrage de charge en cas de défaillance ou d'arrêt du partenaire principal. Pour maintenir les connexions entre les deux partenaires, des enregistrements de connexion sont transmis entre les deux machines. Lorsque le partenaire de secours prend en charge la fonction d'équilibrage de charge, l'adresse IP de cluster est supprimée de la machine de secours et ajoutée dans la nouvelle machine principale. De nombreuses considérations temporelles et de configuration peuvent avoir un impact sur cette opération de reprise.
Les conseils répertoriés dans cette section peuvent répondre à des incidents potentiels de configuration de la haute disponibilité, comme :
Les conseils suivants sont pratiques pour garantir le succès de la configuration de la haute disponibilité sur les machines Load Balancer.
Exemples de commandes de haute disponibilité :
dscontrol highavailability heartbeat add ... dscontrol highavailability backup add ... dscontrol highavailability reach add ...
La plupart du temps, vous devez positionner les définitions de haute disponibilité à la fin du fichier. Les instructions de cluster, port et serveur doivent être placées avant celles de haute disponibilité. En effet, lors de la synchronisation de la haute disponibilité, les définitions de cluster, port et serveur sont recherchées à la réception d'un enregistrement de connexion.
Si le cluster, port et serveur n'existent pas, l'enregistrement de connexion est annulé. En cas de reprise alors que l'enregistrement de connexion n'a pas été répliqué sur la machine partenaire, la connexion échoue.
L'exception à cette règle est l'utilisation de serveurs co-implantés, configurés avec la méthode d'acheminement MAC. Dans ce cas, les instructions de haute disponibilité doivent précéder les instructions du serveur co-implanté. Si ce n'est pas le cas, Load Balancer reçoit une demande sur le serveur co-implanté, mais celle-ci ressemble à une demande entrante adressée au cluster et fait l'objet d'un équilibrage de charge. Ceci risque de conduire à un bouclage des paquets sur le réseau et à un excès de trafic. Lorsque les instructions de haute disponibilité sont placées avant le serveur co-implanté, Load Balancer est informé qu'il ne doit pas acheminer le trafic entrant sauf s'il se trouve à l'état ACTIF.
Pour remédier à ce comportement, ajoutez un délai de veille dans le script goActive. Le délai de veille nécessaire dépend du déploiement. Un délai de veille de 10 est recommandé pour commencer.
Par défaut, les machines tentent de communiquer toutes les demi-secondes et détectent une défaillance après 4 échecs. Si une machine est occupée, des échecs risquent de se produire alors que le système fonctionne encore correctement. Vous pouvez augmenter le nombre de tentatives avant échec en lançant la commande :
dscontrol executor set hatimeout <valeur>
Pour ce faire, les anciennes connexions ne doivent pas rester en mémoire pendant une période trop longue. Des incidents ont été notamment relevés au niveau des ports LDAP et de longues périodes de staletimeout (de plus d'une journée). La définition d'une valeur staletimeout élevée entraîne la mise en mémoire des anciennes connexions, ce qui pousse un plus grand nombre d'enregistrements de connexion d'être transmis en synchronisation, et également une consommation accrue de mémoire sur les deux machines.
Si la synchronisation échoue avec une période staletimeout raisonnable, vous pouvez améliorer le délai d'attente de la synchronisation grâce à la commande :
e xm 33 5 nouveau_délaiCette commande n'est pas stockée dans le fichier de configuration lorsque ce dernier est sauvegardé. Si vous souhaitez que ce paramètre soit conservé entre les arrêts, vous devez donc l'ajouter manuellement au fichier de configuration.
La valeur du délai d'attente est stockée en une demi-seconde. La nouvelle valeur par défaut de nouveau_délai est : 100 (50 secondes).
En général, avec la méthode d'acheminement MAC, les serveurs de la configuration Load Balancer doivent tous se trouver sur le même segment de réseau, quelle que soit la plateforme. Les périphériques de réseau actifs comme le routeur, les passerelles et les pare-feux interfèrent avec Load Balancer. En effet, Load Balancer fonctionne comme un routeur spécialisé, modifiant uniquement les en-têtes de couche liaison de données pour son tronçon suivant et final. Toute topologie de réseau dans laquelle le tronçon suivant n'est pas final n'est pas valide pour Load Balancer.
Il existe une limitation pour les serveurs zSeries et S/390 qui partagent la carte OSA car cette dernière a un fonctionnement différent de la plupart des cartes réseau. La carte OSA possède sa propre implémentation de couche réseau, (sans aucun rapport avec Ethernet), qui est présentée aux hôtes Linux et z/OS se trouvant derrière elle. En réalité, les cartes OSA ressemblent à des hôtes Ethernet-Ethernet (et non à des hôtes OSA) et les hôtes qui l'utilisent y répondent comme s'il s'agissait d'Ethernet.
La carte OSA exécute également certaines fonctions directement relatives à la couche IP : par exemple, la réponse aux demandes de protocole de résolution d'adresses. Ou encore, la carte OSA partagée achemine les paquets IP en fonction d'une adresse IP de destination, et non d'une adresse Ethernet comme un commutateur de couche 2. En pratique, la carte OSA est un segment de réseau avec une passerelle vers elle-même.
Load Balancer s'exécutant sur un hôte Linux S/390 ou zSeries peut acheminer le trafic vers des hôtes se trouvant sur la même carte OSA ou sur des hôtes Ethernet. Tous les hôtes se trouvant sur la même carte OSA partagée se trouvent effectivement sur le même segment.
Load Balancer peut effectuer un acheminement à partir d'une carte OSA partagée en raison de la nature de la passerelle OSA. Cette dernière reconnaît le port OSA qui possède l'IP de cluster. Le pont reconnaît l'adresse MAC des hôtes directement connectés au segment Ethernet. Par conséquent, Load Balancer peut effectuer un acheminement par méthode MAC sur une passerelle OSA.
Toutefois, Load Balancer ne peut pas effectuer d'acheminement vers une carte OSA partagée, notamment lorsqu'il se trouve sous une machine S/390 Linux et que le serveur dorsal se trouve sur une carte OSA différente de celle de Load Balancer. Le processus OSA du serveur dorsal annonce l'adresse MAC OSA pour l'IP de serveur, mais à l'arrivée d'un paquet avec l'adresse de destination Ethernet de l'OSA du serveur et l'IP du cluster, la carte OSA du serveur ne sait pas lequel de ses hôtes, le cas échéant, doit recevoir ce paquet. Les principes qui gouvernent l'acheminement MAC OSA-Ethernet à partir d'une carte OSA partagée ne fonctionnent pas lors des tentatives d'acheminement vers une carte OSA partagée.
Solution :
Les configurations Load Balancer qui utilisent les serveurs zSeries ou S/390 dotés de cartes OSA proposent deux moyens de remédier à l'incident décrit :
Si les serveurs de la configuration Load Balancer se trouvent sur le même type de plateforme zSeries ou S/390, vous pouvez définir des connexions point à point (CTC ou IUCV) entre Load Balancer et chaque serveur. Configurez les noeuds finaux avec les adresses IP privées. La connexion point à point est réservée au trafic Load Balancer-serveur. Ajoutez ensuite les serveurs avec l'adresse IP du noeud final du serveur du tunnel. Dans cette configuration, le trafic du cluster passe par la carte OSA de Load Balancer et est acheminé via la connexion point à point, là où le serveur répond par sa propre route par défaut. La réponse utilise la carte OSA du serveur pour son émission, et il peut s'agir ou non de la même carte.
Si les serveurs de la configuration Load Balancer ne se trouvent pas sur le même type de plateforme zSeries ou S/390, ou s'il n'est pas possible de définir une connexion point à point entre Load Balancer et chaque serveur, il est préférable d'utiliser la fonctionnalité GRE (Generic Routing Encapsulation) de Load Balancer, protocole permettant à Load Balancer d'effectuer un acheminement via des routeurs.
Lors de l'utilisation de GRE, le paquet IP client->cluster est reçu par Load Balancer, encapsulé puis envoyé au serveur. Au niveau du serveur, le paquet IP client->cluster original est encapsulé et le serveur répond directement au client. L'avantage que présente l'utilisation de GRE est que Load Balancer visualise uniquement le trafic client-serveur, et non le trafic serveur-client. L'inconvénient est qu'elle réduit la taille de segment maximal de la connexion TCP à cause de la surcharge d'encapsulation.
Pour configurer Load Balancer pour un acheminement avec encapsulation GRE, ajoutez les serveurs à l'aide de la commande suivante :
dscontrol server add cluster_add:port:backend_server router backend_server
Où le routeur backend_server est valide si Load Balancer et le serveur dorsal se trouvent sur le même sous-réseau IP. Sinon, indiquez comme routeur l'adresse IP valide du tronçon suivant.
Pour configurer les systèmes Linux afin qu'ils exécutent une excapsulation GRE native, lancez les commandes suivantes pour chaque serveur dorsal :
modprobe ip_gre ip tunnel add grelb0 mode gre ikey 3735928559 ip link set grelb0 up ip addr add cluster_addr dev grelb0
Lors de l'exécution de Load Balancer configuré avec les fonctions de gestionnaire et de conseillers, des fuites de mémoire importantes peuvent se produire sur certaines versions Red Hat Linux. La fuite de mémoire Java augmente si le paramètre d'intervalle de temps défini pour le conseiller est petit.
Les versions IBM Java SDK de JVM et la bibliothèque NPTL (Native POSIX Thread Library) livrée avec certaines distributions de Linux, comme Red Hat Enterprise Linux 3.0, peuvent être à l'origine de la fuite de mémoire. La bibliothèque d'unités d'exécution améliorée NPTL est livrée avec certaines distributions de systèmes Linux, comme Red Hat Enterprise Linux 3.0.
Pour les informations les plus récentes sur les systèmes Linux et le kit IBM Java SDK livré avec ces systèmes, voir http://www.ibm.com/developerworks/java/jdk/linux/tested.html .
Utilisez comme outil de diagnostic la commande vmstat ou ps pour détecter les fuites de mémoire.
Pour remédier à une fuite de mémoire, exécutez la commande suivante avant d'exécuter la machine Load Balancer pour désactiver la bibliothèque NPTL :
export LD_ASSUME_KERNEL=2.4.10
Lorsque vous utilisez la méthode d'acheminement MAC sur Suse Linux Enterprise Server 9, le rapport de Dispatcher peut indiquer un réacheminement du paquet (le nombre de paquets augmente), alors que ce dernier n'atteint jamais le serveur dorsal.
Lorsque cet incident se produit, l'un et/ou l'autre des cas suivant peut se présenter :
ip_finish_output2: No header cache and no neighbour!
ICMP Destination unreachable: Fragmentation Needed
Cet incident peut être lié au module NAT iptables chargé. Sur SLES 9, cette version d'iptables contient une erreur possible, bien que non confirmée, entraînant un comportement étrange lors des interactions avec Dispatcher.
Solution :
Déchargez le module NAT iptables et le module Connection Tracking.
Exemple :
# lsmod | grep ip iptable_filter 3072 0 iptable_nat 22060 0 ip_conntrack 32560 1 iptable_nat ip_tables 17280 2 iptable_filter,iptable_nat ipv6 236800 19 # rmmod iptable_nat # rmmod ip_conntrack
Supprimez les modules dans leur ordre d'utilisation. Plus précisément, vous pouvez supprimer un module uniquement si le nombre de références (dernière colonne de la sortie lsmod) est égal à zéro. Si vous avez configuré des règles dans iptables, vous devez les supprimer. Par exemple : iptables -t nat -F.
Le module iptable_nat utilise ip_conntrack, vous devez d'abord supprimer le module iptable_nat, puis le module ip_conntrack.
Sous Windows, si vous utilisez la fonction haute disponibilité de Load Balancer en cas de reprise, les goScripts permettent de configurer l'IP cluster sur le Load Balancer actif et à annuler la configuration de l'IP cluster sur le système de secours. Des incidents risquent de se produire si le goScript configurant l'adresse IP de cluster de la machine active s'exécute avant celui annulant la configuration de l'adresse IP de cluster sur la machine de secours. Un message en incrustation risque de signaler que le système a détecté un conflit d'adresses IP. Si vous exécutez la commande ipconfig \all, vous risquez également de voir l'adresse IP 0.0.0.0 sur la machine.
Solution :
Exécutez la commande suivante pour annuler manuellement la configuration de l'adresse IP de cluster à partir de la machine principale :
dscontrol executor unconfigure clusterIP
L'adresse 0.0.0.0 est alors supprimée de la pile IP Windows.
Une fois que le partenaire à haute disponibilité publie l'adresse IP de cluster, exécutez la commande suivante pour ajouter manuellement le retour IP de cluster :
dscontrol executor configure clusterIP
Une fois la commande générée, vérifiez une nouvelle fois l'adresse IP de cluster sur la pile IP Windows en lançant la commande suivante :
ipconfig /all
Les iptables Linux peuvent interférer avec l'équilibrage de charge du trafic et doivent être désactivées sur le répartiteur.
Exécutez la commande suivante pour déterminer si les iptables sont chargés :
lsmod | grep ip_tables
Le résultat de la dernière commande doit s'apparenter au suivant :
ip_tables 22400 3 iptable_mangle,iptable_nat,iptable_filter
Exécutez la commande suivante pour chaque iptable listé dans le résultat pour afficher les règles des tables:
iptables -t <short_name> -L
Exemple :
iptables -t mangle -L iptables -t nat -L iptables -t filter -L
Si iptable_nat est chargé, il doit être déchargé. Comme iptable_nat est dépendant de iptable_conntrack, supprimez également iptable_conntrack. Exécutez la commande suivante pour décharger ces deux iptables:
rmmod iptable_nat iptable_conntrack
Load Balancer fournit un ensemble de fichiers Java avec l'installation du produit. L'installation du produit comporte plusieurs packages qu'il n'est pas nécessaire d'installer sur la même machine (par exemple, le package Metric Server, le package d'administration et le package du produit de base). Ces trois packages de codes exigent le fonctionnement d'un ensemble de fichiers Java, mais chacun peut être installé sur des machines distinctes. Chacun de ces packages installe un ensemble de fichiers Java. S'il est installé sur la même machine, l'ensemble de fichiers Java appartient à chacun de ces ensembles de fichiers. Lorsque vous installez le deuxième et le troisième ensembles de fichiers Java, vous recevez un message d'avertissement indiquant que l'ensemble de fichiers appartient également à un autre ensemble de fichiers.
Lorsque vous installez du code à l'aide de méthodes d'installation natives (par exemple, installp sur AIX), ignorez les messages d'avertissement indiquant que l'ensemble de fichiers Java appartient à un autre ensemble de fichiers.
Pendant le processus d'installation de Load Balancer, un ensemble de fichiers Java est également installé. Load Balancer est la seule application utilisant la version Java qui s'installe avec le produit. Ne procédez pas tout seul à la mise à niveau de cette version de l'ensemble de fichiers Java. En cas d'incident nécessitant une mise à niveau de l'ensemble de fichiers Java, contactez le service d'assistance IBM pour recevoir une mise à niveau officielle de l'ensemble de fichiers Java qui a été fourni avec l'installation Load Balancer.
Sous Windows, des connexions persistantes peuvent être supprimées lors de la reprise de la haute disponibilité. Cet incident se produit uniquement lorsqu'un serveur co-implanté utilise la méthode d'acheminement MAC.
Lorsqu'une adresse IP de cluster est supprimée à partir de l'interface ethernet ou de interface de bouclage, toutes les connexions relatives à cette adresse IP sont publiées. Lorsque le système d'exploitation reçoit un paquet d'une connexion publiée, il envoie une réponse RST au client et la connexion est terminée.
Pour éviter de supprimer des connexions pendant une reprise à haute disponibilité, vous ne devez pas utiliser de serveur co-implanté sur les systèmes d'exploitation Windows lorsque vous utilisez la méthode d'acheminement MAC.
Cet incident est dû à une restriction de Edge Installer sur les systèmes d'exploitation Linux 32 bits zSeries.
Vous pouvez résoudre cet incident en effectuant une installation manuelle du système d'exploitation Linux 32 bits zSeries. Pour plus d'informations, voir Installation des systèmes Linux.
Cet incident est dû à une restriction de Edge Installer sur les systèmes d'exploitation Linux.
Pour désinstaller WebSphere Edge Server d'un système d'exploitation Linux, vous devez désinstaller le produit manuellement. Pour se faire, exécutez la commande rpm -e 'rpm -qa | grep ibmlb'
Pour ne désinstaller qu'un seul package, exécutez la commande rpm -e <package name>. Les noms de package se trouvent dans la section Installation des systèmes Linux. Désinstallez les packages dans l'ordre inverse de celui dans lequel ils ont été installés.
Cet incident se produit lorsqu'une autre application utilise l'un des ports utilisés par CBR. Pour plus d'informations, voir Vérification des numéros de port CBR.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Ceci peut être source de problèmes lorsqu'une des consoles d'administration s'exécute sur la même machine qu'un pare-feu ou passe par un pare-feu. Par exemple, lorsque Load Balancer s'exécute sur la même machine qu'un pare-feu alors que vous exécutez des commandes cbrcontrol, des erreurs de type Erreur : aucune réponse du serveur peuvent s'afficher.
Pour éviter ce type d'incident, modifiez le fichier script cbrserver afin de définir le port qu'utilise RMI pour le pare-feu (ou autre application). Remplacez la ligne LB_RMISERVERPORT=11199 par LB_RMISERVERPORT= votrePort. Où votrePort est un autre port.
Lorsque vous avez terminé, réexécutez la commande cbrserver et ouvrez le trafic des ports 11099, 10004, 11199 et 11100 ou du port d'adresse hôte choisi pour l'exécution de la console d'administration.
Caching Proxy et CBR ont été lancés, mais les requêtes ne sont pas équilibrées. Cette erreur peut se produire lorsque vous démarrez Caching Proxy avant l'exécuteur. Si c'est le cas, le journal stderr de Caching Proxy contient le message d'erreur indiquant l'échec de la connexion à l'exécuteur (ndServerInit). Pour éviter cet incident, démarrez l'exécuteur avant Caching Proxy.
Sur les systèmes Solaris, la commande cbrcontrol executor start renvoie le message suivant : "Erreur : l'exécuteur n'a pas été lancé". Cette erreur se produit si vous ne configurez pas les communications IPC (Inter-process Communication) pour le système de telle sorte que la taille maximale d'un segment de mémoire partagée et des ID sémaphore soit supérieure à la valeur par défaut du système d'exploitation. Pour augmenter la taille du segment de mémoire partagée et des ID sémaphore, vous devez modifier le fichier /etc/system. Pour plus d'informations sur la configuration du fichier, voir page ***.
Si la règle d'URL ne fonctionne pas, cela peut être dû à une erreur de syntaxe ou de configuration. Pour ce problème, vérifiez :
Sous Windows, l'interface graphique de Load Balancer peut se comporter de manière inattendue lorsque vous utilisez une carte vidéo Matrox AGP. Lorsque vous cliquez sur un bouton de la souris, un espace légèrement plus large que le pointeur de la souris peut être altéré avec inversion possible de la mise en évidence ou déplacement des images sur l'écran. Les anciennes cartes Matrox n'ont pas présenté ce type de comportement. Il n'existe pas de rectificatif pour les cartes Matrox AGP.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) du navigateur Netscape dans lequel s'affiche l'interface graphique de Load Balancer. En effet, étant donné que Netscape recharge une page à chaque redimensionnement de la fenêtre du navigateur, une déconnexion de l'hôte en découle. Vous devez donc vous reconnecter à l'hôte après chaque modification de la taille de la fenêtre. Si vous réalisez l'administration Web à distance basée sur une plateforme Windows, utilisez Internet Explorer.
Dans une fenêtre de ligne de commande du système d'exploitation Windows, certains caractères nationaux de la famille Latin-1 sont altérés. Par exemple, la lettre "a" avec tilde s'affiche sous la forme d'un symbole pi. Pour rectifier cette erreur, vous devez modifier les propriétés de police de la fenêtre de ligne de commande. Pour modifier la police, procédez comme suit :
Certaines installations HP-UX 11i sont préconfigurées pour n'autoriser que 64 unités d'exécution par processus. Toutefois, certaines configurations Load Balancer en requièrent davantage. Pour les systèmes HP-UX, définissez les unités d'exécution par processus sur au moins 256. Pour augmenter cette valeur, utilisez l'utilitaire "sam" pour définir le paramètre de noyau max_thread_proc. Si vous pensez avoir besoin d'un nombre d'unités d'exécution plus important, vous pouvez affecter à ce paramètre une valeur supérieure à 256.
Pour augmenter la valeur du paramètre max_thread_proc, voir la procédure de la page ***.
Lorsque vous configurez votre adaptateur sur une machine Load Balancer, vous devez vérifier que les deux paramètres suivants sont corrects pour que le conseiller puisse fonctionner :
Pour des instructions sur la configuration des paramètres, voir page ***.
Sous Windows, lorsque vous configurez un adaptateur avec plusieurs adresses IP, configurez d'abord dans le registre l'adresse IP à affilier au nom d'hôte.
Load Balancer dépendant de InetAddress.getLocalHost() dans de nombreuses instances (par exemple, lbkeys create), l'attribution comme alias de plusieurs adresses IP à un même adaptateur peut être source d'incident. Pour éviter cela, entrez l'adresse IP à utiliser pour la résolution du nom d'hôte en premier dans le registre.
Pour connaître la procédure de configuration de nom d'hôte en premier dans le registre, voir ***.
Cet incident se produit lorsqu'une autre application utilise l'un des ports utilisés par Site Selector. Pour plus d'informations, voir Vérification des numéros de port Site Selector.
Symptôme : Le composant Site Selector n'effectue pas de demandes entrantes permutées de façon circulaire à partir des clients Solaris.
Cause possible : Les systèmes Solaris exécutent un démon de mémoire cache de service annuaire. Si ce démon est en cours d'exécution, la demande du programme de résolution suivante est traitée à partir de cette mémoire cache et non à partir du composant Site Selector ayant effectuée la demande.
Solution : Désactivez le démon de mémoire cache du service annuaire sur la machine Solaris.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Ceci peut être source de problèmes lorsqu'une des consoles d'administration s'exécute sur la même machine qu'un pare-feu ou passe par un pare-feu. Par exemple, lorsque Load Balancer s'exécute sur la même machine qu'un pare-feu alors que vous exécutez des commandes sscontrol, des erreurs de type Erreur : aucune réponse du serveur peuvent s'afficher.
Pour éviter ce type d'incident, modifiez le fichier script ssserver afin de définir le port qu'utilise RMI pour le pare-feu (ou autre application). Remplacez la ligne LB_RMISERVERPORT=10199 par LB_RMISERVERPORT= votrePort. Où votrePort est un autre port.
Lorsque vous avez terminé, réexécutez la commande ssserver et ouvrez le trafic des ports 12099, 10004, 12199 et 12100 ou du port d'adresse hôte choisi pour l'exécution de la console d'administration.
Site Selector doit pouvoir participer à un système DNS. Toutes les machines concernées par la configuration doivent également participer à ce système. Les systèmes Windows ne nécessitent pas toujours la présence du nom d'hôte configuré dans le système DNS. Avec Site Selector, un nom d'hôte doit être défini dans le système DNS pour que le démarrage s'effectue correctement.
Vérifiez que cet hôte est défini dans le système DNS. Modifiez le fichier ssserver.cmd et supprimez le "w" de "javaw". Vous devriez ainsi obtenir plus d'informations sur les erreurs.
Le serveur annuaire de Site Selector n'est associé à aucune adresse sur la machine. Il répond aux demandes destinées aux adresses IP valides de la machine. Site Selector fait confiance au système d'exploitation pour l'acheminement de la réponse au client. Si la machine Site Selector comporte plusieurs cartes et que certaines d'entre elles sont connectées au même sous-réseau, il est possible que le système d'exploitation envoie la réponse au client à partir d'une adresse différente de celle de réception. Certaines applications client n'acceptent pas de réponse provenant d'une adresse différente de celle de l'envoi. Par conséquent, la résolution de nom semble ne pas aboutir.
Sous Windows, l'interface graphique de Load Balancer peut se comporter de manière inattendue lorsque vous utilisez une carte vidéo Matrox AGP. Lorsque vous cliquez sur un bouton de la souris, un espace légèrement plus large que le pointeur de la souris peut être altéré avec inversion possible de la mise en évidence ou déplacement des images sur l'écran. Les anciennes cartes Matrox n'ont pas présenté ce type de comportement. Il n'existe pas de rectificatif pour les cartes Matrox AGP.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) du navigateur Netscape dans lequel s'affiche l'interface graphique de Load Balancer. En effet, étant donné que Netscape recharge une page à chaque redimensionnement de la fenêtre du navigateur, une déconnexion de l'hôte en découle. Vous devez donc vous reconnecter à l'hôte après chaque modification de la taille de la fenêtre. Si vous réalisez l'administration Web à distance basée sur une plateforme Windows, utilisez Internet Explorer.
Dans une fenêtre de ligne de commande du système d'exploitation Windows, certains caractères nationaux de la famille Latin-1 sont altérés. Par exemple, la lettre "a" avec tilde s'affiche sous la forme d'un symbole pi. Pour rectifier cette erreur, vous devez modifier les propriétés de police de la fenêtre de ligne de commande. Pour modifier la police, procédez comme suit :
Certaines installations HP-UX 11i sont préconfigurées pour n'autoriser que 64 unités d'exécution par processus. Toutefois, certaines configurations Load Balancer en requièrent davantage. Pour les systèmes HP-UX, définissez les unités d'exécution par processus sur au moins 256. Pour augmenter cette valeur, utilisez l'utilitaire "sam" pour définir le paramètre de noyau max_thread_proc. Si vous pensez avoir besoin d'un nombre d'unités d'exécution plus important, vous pouvez affecter à ce paramètre une valeur supérieure à 256.
Pour augmenter la valeur du paramètre max_thread_proc, voir la procédure de la page ***.
Lorsque vous configurez votre adaptateur sur une machine Load Balancer, vous devez vérifier que les deux paramètres suivants sont corrects pour que le conseiller puisse fonctionner :
Pour des instructions sur la configuration des paramètres, voir page ***.
Cet incident se produit lorsqu'une autre application utilise l'un des ports employés par le serveur ccoserver de Cisco CSS Controller. Pour plus d'informations, voir Vérification des numéros de port Cisco CSS Controller.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Ceci peut être source de problèmes lorsqu'une des consoles d'administration s'exécute sur la même machine qu'un pare-feu ou passe par un pare-feu. Par exemple, lorsque Load Balancer s'exécute sur la même machine qu'un pare-feu alors que vous exécutez des commandes ccocontrol, des erreurs de type Erreur : aucune réponse du serveur peuvent s'afficher.
Pour éviter ce type d'incident, modifiez le fichier script ccoserver afin de définir le port qu'utilise RMI pour le pare-feu (ou autre application). Remplacez la ligne CCO_RMISERVERPORT=14199 par CCO_RMISERVERPORT= votrePort. Où votrePort est un autre port.
Lorsque vous avez terminé, réexécutez la commande ccoserver et ouvrez le trafic des ports 13099, 10004, 13199 et 13100 ou du port d'adresse hôte choisi pour l'exécution de la console d'administration.
Cet incident se produit lorsqu'il manque une licence de produit valide. Lorsque vous tentez de lancer ccoserver, le message suivant s'affiche :
Votre licence a expiré ! Adressez-vous à votre ingénieur commercial ou à votre représentant IBM.
Pour résoudre le problème, procédez comme suit :
Sous Windows, l'interface graphique de Load Balancer peut se comporter de manière inattendue lorsque vous utilisez une carte vidéo Matrox AGP. Lorsque vous cliquez sur un bouton de la souris, un espace légèrement plus large que le pointeur de la souris peut être altéré avec inversion possible de la mise en évidence ou déplacement des images sur l'écran. Les anciennes cartes Matrox n'ont pas présenté ce type de comportement. Il n'existe pas de rectificatif pour les cartes Matrox AGP.
Vous pouvez être confronté à une erreur de connexion, due à des paramètres de configuration incorrects, lors de l'ajout d'un consultant. Pour résoudre l'incident :
Pour corriger ce problème :
Augmentez le niveau de consignation du journal du consultant, puis réexécutez la commande. Si elle échoue de nouveau, recherchez dans le journal les délais d'expirations SNMP ou autres erreurs de communication SNMP.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) du navigateur Netscape dans lequel s'affiche l'interface graphique de Load Balancer. En effet, étant donné que Netscape recharge une page à chaque redimensionnement de la fenêtre du navigateur, une déconnexion de l'hôte en découle. Vous devez donc vous reconnecter à l'hôte après chaque modification de la taille de la fenêtre. Si vous réalisez l'administration Web à distance basée sur une plateforme Windows, utilisez Internet Explorer.
Dans une fenêtre de ligne de commande du système d'exploitation Windows, certains caractères nationaux de la famille Latin-1 sont altérés. Par exemple, la lettre "a" avec tilde s'affiche sous la forme d'un symbole pi. Pour rectifier cette erreur, vous devez modifier les propriétés de police de la fenêtre de ligne de commande. Pour modifier la police, procédez comme suit :
Certaines installations HP-UX 11i sont préconfigurées pour n'autoriser que 64 unités d'exécution par processus. Toutefois, certaines configurations Load Balancer en requièrent davantage. Pour les systèmes HP-UX, définissez les unités d'exécution par processus sur au moins 256. Pour augmenter cette valeur, utilisez l'utilitaire "sam" pour définir le paramètre de noyau max_thread_proc. Si vous pensez avoir besoin d'un nombre d'unités d'exécution plus important, vous pouvez affecter à ce paramètre une valeur supérieure à 256.
Pour augmenter la valeur du paramètre max_thread_proc, voir la procédure de la page ***.
Cet incident se produit lorsqu'une autre application utilise l'un des ports utilisés par le serveur nalserver de Nortel Alteon Controller. Pour plus d'informations, voir Vérification des numéros de port Nortel Alteon Controller.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Ceci peut être source de problèmes lorsqu'une des consoles d'administration s'exécute sur la même machine qu'un pare-feu ou passe par un pare-feu. Par exemple, lorsque Load Balancer s'exécute sur la même machine qu'un pare-feu alors que vous exécutez des commandes nalcontrol, des erreurs de type Erreur : aucune réponse du serveur peuvent s'afficher.
Pour éviter ce type d'incident, modifiez le fichier script nalserver afin de définir le port qu'utilise RMI pour le pare-feu (ou autre application). Remplacez la ligne NAL_RMISERVERPORT=14199 par NAL_RMISERVERPORT= votrePort. Où votrePort est un autre port.
Lorsque vous avez terminé, réexécutez la commande nalserver et ouvrez le trafic des ports 14099, 10004, 14199 et 14100 ou du port d'adresse hôte choisi pour l'exécution de la console d'administration.
Cet incident se produit lorsqu'il manque une licence de produit valide. Lorsque vous tentez de lancer nalserver, le message suivant s'affiche :
Votre licence a expiré ! Adressez-vous à votre ingénieur commercial ou à votre représentant IBM.
Pour résoudre le problème, procédez comme suit :
Sous Windows, l'interface graphique de Load Balancer peut se comporter de manière inattendue lorsque vous utilisez une carte vidéo Matrox AGP. Lorsque vous cliquez sur un bouton de la souris, un espace légèrement plus large que le pointeur de la souris peut être altéré avec inversion possible de la mise en évidence ou déplacement des images sur l'écran. Les anciennes cartes Matrox n'ont pas présenté ce type de comportement. Il n'existe pas de rectificatif pour les cartes Matrox AGP.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) du navigateur Netscape dans lequel s'affiche l'interface graphique de Load Balancer. En effet, étant donné que Netscape recharge une page à chaque redimensionnement de la fenêtre du navigateur, une déconnexion de l'hôte en découle. Vous devez donc vous reconnecter à l'hôte après chaque modification de la taille de la fenêtre. Si vous réalisez l'administration Web à distance basée sur une plateforme Windows, utilisez Internet Explorer.
Vous pouvez être confronté à une erreur de connexion, due à des paramètres de configuration incorrects, lors de l'ajout d'un consultant. Pour résoudre l'incident :
Pour corriger ce problème :
Augmentez le niveau de consignation du journal du consultant, puis réexécutez la commande. Si elle échoue de nouveau, recherchez dans le journal les délais d'expirations SNMP ou autres erreurs de communication SNMP.
Dans une fenêtre de ligne de commande du système d'exploitation Windows, certains caractères nationaux de la famille Latin-1 sont altérés. Par exemple, la lettre "a" avec tilde s'affiche sous la forme d'un symbole pi. Pour rectifier cette erreur, vous devez modifier les propriétés de police de la fenêtre de ligne de commande. Pour modifier la police, procédez comme suit :
Certaines installations HP-UX 11i sont préconfigurées pour n'autoriser que 64 unités d'exécution par processus. Toutefois, certaines configurations Load Balancer en requièrent davantage. Pour les systèmes HP-UX, définissez les unités d'exécution par processus sur au moins 256. Pour augmenter cette valeur, utilisez l'utilitaire "sam" pour définir le paramètre de noyau max_thread_proc. Si vous pensez avoir besoin d'un nombre d'unités d'exécution plus important, vous pouvez affecter à ce paramètre une valeur supérieure à 256.
Pour augmenter la valeur du paramètre max_thread_proc, voir la procédure de la page ***.
Vous devez utiliser le nom complet des mesures enregistrées par l'utilisateur sur les postes Metric Server Windows. Par exemple, vous devez indiquer usermetric.bat, et non usermetric. Le nom usermetric est valide sur l'invite de commande, mais ne fonctionne pas lorsqu'il est exécuté à partir de l'environnement d'exécution. Si vous n'utilisez pas de nom complet pour les mesures, vous recevez une exception d'entrée-sortie Metric Server. Attribuez la valeur 3 à la variable LOG_LEVEL dans le fichier de commandes metricserver, puis consultez la sortie de journal. Dans cet exemple, l'exception se présente comme suit :
... java.io.IOException: CreateProcess: usermetric error=2
Plusieurs raisons peuvent expliquer le fait que Metric Server ne transmet pas les informations relatives à la charge à Load Balancer. Procédez aux vérifications suivantes pour en déterminer la cause :
Vous pouvez également résoudre cet incident en spécifiant le nom d'hôte dans la propriété Java java.rmi.server.hostname dans le script metricserver.
Le journal de la machine Metric Server présente ce message d'erreur suite au transfert de fichiers de clés sur le serveur.
Cette erreur est consignée lorsque le fichier de clés ne donne pas d'autorisation avec la clé de la paire en raison d'une altération dans cette dernière. Pour remédier à ce problème, procédez comme suit :
Lorsque Metric Server s'exécute dans des conditions difficiles sur une plateforme AIX multiprocesseur (4.3.3, 32 bits 5.1 ou 64 bits 5.1), il est possible que le résultat de la commande ps -vg soit altéré. Exemple :
55742 - A 88:19 42 18014398509449680 6396 32768 22 36 2.8 1.0 java -Xms
Les zones SIZE et/ou RSS de la commande ps peuvent indiquer une quantité de mémoire utilisée excessive.
Il s'agit d'un problème de noyau AIX connu. Le correctif APAR IY33804 rectifie ce problème. Ce correctif est disponible auprès du support AIX à l'adresse http://techsupport.services.ibm.com/server/fixes, ou auprès de votre responsable de l'assistance technique AIX.
Dans une configuration Load Balancer de second niveau, si Site Selector (premier niveau) équilibre la charge sur une paire de partenaires Dispatcher haute disponibilité (second niveau), vous devez effectuer certaines opérations pour configurer le composant Metric Server. Vous devez configurer le serveur de mesures pour qu'il écoute une nouvelle adresse IP qui lui soit réservée. Sur les deux machines Dispatcher haute disponibilité, le serveur de mesures n'est actif que sur la machine Dispatcher active.
Pour une configuration correcte, effectuez la procédure suivante :
Exemple :
ifconfig en0 delete 9.27.23.61 ifconfig lo0 alias 9.27.23.61 netmask 255.255.255.0 route add 9.27.23.61 127.0.0.1 metricserver stop # Mode veille pendant 60 secondes au maximum ou jusqu'à l'arrêt du serveur de mesures let loopcount=0 while [[ "$loopcount" -lt "60" && 'ps -ef | grep AgentStop| grep -c -v gr ep' -eq "1"]] do sleep 1 let loopcount=$loopcount+1 done route delete 9.27.23.61
Exemple :
call netsh interface ip delete address "Local Area Connection" addr=9.27.23.61 call netsh interface ip add address "Local Area Connection 2" addr=9.27.2.3.61 mask = 255.255.255.0 sleep 3 metricserver stop
Lors de leur exécution sur des machines Solaris dotées de plusieurs CPU, les scripts metricserver, cpuload et memload peuvent générer des messages de console non souhaités. Ce comportement est dû à l'utilisation de la commande système VMSTAT pour collecter des statistiques sur la CPU et la mémoire à partir du noyau. Certains messages renvoyés par VMSTAT indiquent que l'état du noyau a changé. Les scripts ne peuvent pas gérer ces messages, ce qui entraîne la génération de messages de console inutiles provenant du shell.
Exemples de ces messages de la console :
/opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=: erreur de syntaxe /opt/ibm/edge/lb/ms/script/memload[31]: LOAD=4*100/0: diviser par zéro /opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=659664+: plus de tokens attendus
Ces messages peuvent être ignorés.
Cet incident peut résulter de la perte d'intégrité des fichiers de clés pendant le transfert vers le client.
Si vous utilisez FTP pour transférer les fichiers de clés entre la machine Load Balancer et le serveur dorsal, assurez-vous que vous utilisez le mode binaire pour placer ou récupérer les fichiers de clés dans le serveur FTP.
Cette section contient des informations relatives aux commandes de tous les composants de Load Balancer. Elle se compose des chapitres suivants :
Le schéma de syntaxe explique comment indiquer une commande de sorte que le système d'exploitation puisse interpréter correctement les données que vous entrez. Lisez le schéma de syntaxe de gauche à droite et de haut en bas, suivant la ligne horizontale (chemin principal).
Les symboles suivants sont utilisés dans les schémas de syntaxe :
Vous devez inclure tous les signes de ponctuation tels que le deux-points, le point d'interrogation et le signe moins, qui sont indiqués dans le schéma de syntaxe.
Les types de paramètres suivants sont utilisés dans les schémas de syntaxe :
Les paramètres sont classés par mots clés ou par variables. Les mots clés s'affichent en minuscules et peuvent être entrés en minuscules. Par exemple, un nom de commande est un mot clé. Les variables apparaissent en italique et représentent des noms ou des valeurs que vous indiquez.
Dans l'exemple suivant, la commande de l'utilisateur correspond à un mot clé. La variable obligatoire est id_utilisateur et la variable facultative mot_de_passe. Remplacez les variables par vos propres valeurs.
>>-user--ID_utilisateur--+--------------+--------------------------------->< '-mot_de_passe-'
Mots clés obligatoires : les mots clés et les variables obligatoires apparaissent sur la ligne du chemin principal.
>>-required_keyword--------------------------------------------><
Vous devez codifier les mots clés et les valeurs obligatoires.
Choisissez un élément obligatoire dans une pile : Si vous devez effectuer votre choix parmi plusieurs mots clés ou variables obligatoires qui s'excluent, ceux-ci sont empilés verticalement dans l'ordre alphanumérique.
>>-+-required_parameter_1-+------------------------------------>< '-required_parameter_2-'
Valeurs facultatives : les mots clés et les variables facultatifs apparaissent sous la ligne du chemin principal.
>>-+---------+------------------------------------------------->< '-keyword-'
Vous pouvez choisir de ne pas codifier les mots clés et les variables facultatifs.
Choisissez un mot clé facultatif dans une pile : Si vous devez effectuer votre choix parmi plusieurs mots clés ou variables facultatifs qui s'excluent, ceux-ci sont empilés verticalement dans l'ordre alphanumérique sous la ligne du chemin principal.
>>-+-------------+--------------------------------------------->< +-parameter_1-+ '-parameter_2-'
Variables : Un mot apparaissant intégralement en italique correspond à une variable. Lorsque la syntaxe comporte une variable, celle-ci doit être remplacée par un nom ou une valeur admise, comme cela est défini dans le texte.
>>-variable----------------------------------------------------><
Caractères non alphanumériques : Si un schéma indique un caractère non alphanumérique (par exemple, deux-point, des guillemets ou le signe moins), ce dernier doit être codifié dans le cadre de la syntaxe. Dans cet exemple, vous devez codifier cluster:port.
>>-cluster:port------------------------------------------------><
Le présent chapitre décrit l'utilisation des commandes dscontrol de Dispatcher. Il traite également des commandes de CBR.
Dans les versions antérieures où le produit se nommait Network Dispatcher, la commande de contrôle de Dispatcher était ndcontrol. Elle s'intitule désormais dscontrol. Veillez à mettre à jour tous les fichiers script précédents pour utiliser la commande dscontrol (au lieu de ndcontrol) et configurer Dispatcher.
CBR utilise un sous-ensemble des commandes Dispatcher répertoriées dans ce guide des commandes. Lorsque vous utilisez ces diagrammes de syntaxe pour CBR, remplacez dscontrol par cbrcontrol. Pour plus d'informations, voir Différences de configuration entre CBR et Dispatcher.
La liste suivante contient les commandes relevées dans le présent chapitre :
Vous pouvez entrer une version abrégée des paramètres de commande dscontrol. Il suffit d'entrer les lettres spécifiques des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, vous pouvez entrer dscontrol he f au lieu de dscontrol help file.
Pour démarrer l'interface de ligne de commande, entrez dscontrol pour ouvrir une invite dscontrol.
Pour fermer l'interface de ligne de commande : exécutez exit ou quit.
Les valeurs des paramètres de commandes doivent être saisies à l'aide de caractères anglais. Les seules exceptions s'appliquent aux noms d'hôte (utilisés dans les commandes cluster, server et highavailability) et aux noms de fichiers (utilisés dans les commandes file).
L'interface de ligne de commande de CBR est un sous-ensemble de l'interface de ligne de commande de Dispatcher. Pour CBR, remplacez la commande dscontrol par la commande cbrcontrol pour configurer le composant.
Certaines des commandes inutilisées dans CBR sont répertoriées ci-dessous :
>>-dscontrol--advisor--+-connecttimeout--nom--+-port---------+--délai d'expiration en secondes-+->< | '-cluster:port-' | +-interval--nom--+-port---------+--secondes--------------+ | '-cluster:port-' | +-list---------------------------------------------------+ +-loglevel--nom--+-port---------+--niveau----------------+ | '-cluster:port-' | +-logsize--nom--+-port---------+--+-unlimited---------+-+ | '-cluster:port-' '-nombre d'enregistrements-' | +-receivetimeout--nom--+-port---------+--délai d'expiration en secondes-+ | '-cluster:port-' | +-report--nom--+-port---------+-------------------------+ | '-cluster:port-' | +-retries--nom--+-port---------+--nombre de tentatives------------+ | '-cluster:port-' | +-start--nom--+-port---------+--+----------+------------+ | '-cluster:port-' '-fichier journal-' | +-status--nom--+-port---------+-------------------------+ | '-cluster:port-' | +-stop--nom--+-port---------+---------------------------+ | '-cluster:port-' | +-timeout--nom--+-port---------+--+-unlimited-+---------+ | '-cluster:port-' '-secondes---' | '-version--nom--+-port---------+------------------------' '-cluster:port-'
Pour plus d'informations sur les conseillers proposés par Load Balancer, voir Liste des conseillers.
Les noms des conseillers personnalisés sont au format xxxx, ADV_xxxx étant le nom de la classe mettant en oeuvre le conseiller personnalisé. Pour plus d'informations, voir Création des conseillers (personnalisés).
Le cluster correspond à l'adresse IP ou au nom symbolique. Le port correspond au numéro du port que le conseiller surveille.
Nom du conseiller | Protocole | Port |
---|---|---|
cachingproxy | HTTP (via Caching Proxy) | 80 |
connect | ICMP | 12345 |
db2 | privé | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | privé | 12345 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | privé | 10,007 |
Le fichier par défaut est nom_conseiller_port.log, par exemple, http_80.log. Pour modifier le répertoire dans lequel sont enregistrés les fichiers journaux, voir Modification des chemins des fichiers journaux. Les fichiers journaux par défaut des conseillers spécifiques de clusters (ou de sites) sont créés avec l'adresse du cluster, comme http_127.40.50.1_80.log.
Exemples
dscontrol advisor start http 127.40.50.1:80
dscontrol advisor start http 88
dscontrol advisor stop http 127.40.50.1:80
dscontrol advisor connecttimeout http 80 30
dscontrol advisor connecttimeout http 127.40.50.1:80 20
dscontrol advisor interval ftp 21 6
dscontrol advisor listCette commande génère des résultats similaires à l'exemple suivant :
--------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------- | http |127.40.50.1:80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
dscontrol advisor loglevel http 80 0
dscontrol advisor logsize ftp 21 5000
dscontrol advisor receivetimeout http 80 60
dscontrol advisor report ftp 21Cette commande génère des résultats similaires à l'exemple suivant :
Advisor Report: --------------- Advisor name ............. Ftp Port number .............. 21 Cluster address .......... 9.67.131.18 Server address ........... 9.67.129.230 Load ..................... 8 Cluster address .......... 9.67.131.18 Server address ........... 9.67.131.215 Load ..................... -1
dscontrol advisor status http 80Cette commande génère des résultats similaires à l'exemple suivant :
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited Number of retries ............. 0
dscontrol advisor timeout ftp 21 5
dscontrol advisor version ssl 443Cette commande génère des résultats similaires à l'exemple suivant :
Version : 04.00.00.00 - 07/12/2001-10:09:56-EDT
>>-dscontrol--binlog--+-start----------------------+----------->< +-stop-----------------------+ +-set--+-retention--heures--+-+ | '-interval--secondes-' | '-status---------------------'
>>-dscontrol--cluster--+-add--cluster+c2+...--+----------------------------------------+-+->< | +-address--adresse-----------------------+ | | +-proportions--actives--nouvelles--port--système-+ | | +-maxports--taille-------------------------+ | | +-maxservers--taille-----------------------+ | | +-stickytime--délai-----------------------+ | | +-weightbound--pondération--------------------+ | | +-porttype--type-------------------------+ | | +-primaryhost--adresse-------------------+ | | +-staletimeout--délai d'attente-------------+ | | '-sharedbandwidth--taille------------------' | +-set--cluster+c2+...--+-proportions--actives--nouvelles--port--système-+-+ | +-maxports--taille-------------------------+ | | +-maxservers--taille-----------------------+ | | +-stickytime--délai-----------------------+ | | +-weightbound--pondération--------------------+ | | +-porttype--type-------------------------+ | | +-primaryhost--adresse-------------------+ | | +-staletimeout--délai d'attente-------------+ | | '-sharedbandwidth--taille------------------' | +-remove--cluster-------------------------------------------------+ +-report--cluster-------------------------------------------------+ '-status--cluster-------------------------------------------------'
Vous pouvez utiliser le signe deux-points (:) comme caractère générique sauf pour la commande dscontrol cluster add. Par exemple, la commande dscontrol cluster set : weightbound 80 permet de définir une pondération de 80 pour tous les clusters.
Si vous modifiez l'hôte principal d'un cluster alors que les machines principale et de secours sont lancées et exécutées en haute disponibilité réciproque, vous devez contraindre le nouvel hôte principal à prendre le relais. Vous devrez ensuite mettre à jour les scripts puis déconfigurer et reconfigurer le cluster correctement. Pour plus d'informations, voir Haute disponibilité réciproque.
Exemples
dscontrol cluster add 130.40.52.153
dscontrol cluster remove 130.40.52.153
dscontrol cluster set 9.6.54.12 proportions 60 35 5 0
dscontrol cluster add 0.0.0.0
dscontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
dscontrol cluster status 9.67.131.167Cette commande génère des résultats similaires à l'exemple suivant :
Cluster Status: ---------------- Cluster ................................. 9.67.131.167 Address ................................. 9.67.131.167 Number of target ports .................. 3 Default sticky time ..................... 0 Default stale timeout ................... 30 Default port weight bound ............... 20 Maximum number of ports ................. 8 Default port protocol ................... tcp/udp Default maximum number of servers ....... 32 Proportion given to active connections... 0.5 Proportion given to new connections...... 0.5 Proportion given specific to the port.... 0 Proportion given to system metrics....... 0 Shared bandwidth (KBytes) ............... 0 Primary Host Address .................... 9.67.131.167
>>-dscontrol--executor--+-report-----------------------------------------------------------+->< +-set--+-nfa--adresse IP------------+------------------------------+ | +-maxclusters--taille----------+ | | +-maxports--taille-------------+ | | +-fintimeout--délai avant fin-----+ | | +-hatimeout--délai------------+ | | +-hasynctimeout--délai--------+ | | +-maxservers--taille-----------+ | | +-mss--taille------------------+ | | +-staletimeout--délai d'attente-+ | | +-stickytime--délai-----------+ | | +-clientgateway--adresse-----+ | | +-weightbound--pondération--------+ | | +-porttype--type-------------+ | | +-wideportnumber--port-------+ | | '-sharedbandwidth--taille------' | +-configure--adresse_interface+i2+...--+-------------------------+-+ | '-nom_interface--masque de réseau-' | +-unconfigure--adresse_interface-----------------------------------+ +-start------------------------------------------------------------+ +-status-----------------------------------------------------------+ '-stop-------------------------------------------------------------'
Le temporisateur permet de garantir que les machines principale et de secours tentent de se synchroniser. Toutefois, en présence d'un trop grand nombre de connexions, et lorsque la machine active continue à gérer une charge de trafic entrant importante, la synchronisation risque de ne pas se terminer avant expiration du temporisateur. Par conséquent, Load Balancer tente sans arrêt la resynchronisation et les deux machines ne sont jamais synchronisées. Dans ce type de situation, donnez une valeur supérieure à la valeur par défaut de hasynctimeout pour donner aux deux machines suffisamment de temps pour échanger des informations sur les connexions existantes. Pour définir ce temporisateur, exécutez la commande hasynctimeout après la commande dscontrol executor start, mais avant les commandes de haute disponibilité (dscontrol highavailability).
Exemples
dscontrol executor status Executor Status: ---------------- Nonforwarding address ............... 9.67.131.151 Client gateway address .............. 0.0.0.0 Fin timeout ......................... 60 Wide area network port number ....... 0 Shared bandwidth (Kbytes) ........... 0 Default maximum ports per cluster ... 8 Maximum number of clusters .......... 100 Default maximum servers per port .... 32 Default stale timeout ............... 300 Default sticky time ................. 0 Default weight bound ................ 20 Default port type ................... tcp/udp
dscontrol executor set nfa 130.40.52.167
dscontrol executor set maxclusters 4096
dscontrol executor start
dscontrol executor stop
>>-dscontrol--file--+-delete--fichier[.ext]----------+------------>< +-appendload--fichier[.ext]------+ +-report----------------------+ +-save--fichier[.ext]--+-------+-+ | '-force-' | '-newload--fichier[.ext]---------'
Vous pouvez indiquer n'importe quelle extension de fichier (.ext) ou n'en indiquer aucune.
Exemples
dscontrol file delete file3 Le fichier (file3) est supprimé.
dscontrol file newload fichier1.sv Le fichier (file1.sv) a été chargé dans Dispatcher.
dscontrol file appendload fichier2.sv Le fichier (file2.sv) a été chargé et ajouté à la configuration actuelle.
dscontrol file report FILE REPORT: file1.save file2.sv file3
dscontrol file save file3 La configuration est sauvegardée dans file3.
>>-dscontrol--help--+-advisor----------+----------------------->< +-binlog-----------+ +-cluster----------+ +-executor---------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-host-------------+ +-logstatus--------+ +-manager----------+ +-metric-----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-set--------------+ +-status-----------+ '-subagent---------'
Exemples
dscontrol helpCette commande génère des résultats similaires à l'exemple suivant :
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help cluster help - print complete help text advisor - help on advisor command cluster - help on cluster command executor - help on executor command file - help on file command host - help on host command binlog - help on binary log command manager - help on manager command metric - help on metric command port - help on port command rule - help on rule command server - help on server command set - help on set command status - help on status command logstatus - help on server log status subagent - help on subagent command highavailability - help on high availability commandIl est à noter que les paramètres placés entre les signes <> sont des variables.
fintimeout <adresse de cluster>|all <délai> -Change FIN timeout (Utilisez "all" pour modifier tous les clusters)
>>-dscontrol--highavailability--+-status--------------------------------------+->< +-backup--+-add--+-primary-+--+-auto---+--p-+-+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete--------------------------' | +-reach--+-add----+--adresse--masque------------+ | '-delete-' | +-heartbeat--+-add--adresse source--adresse de destination-+--+ | '-delete--adresse-------------' | '-takeover--+---------+-----------------------' '-adresse-'
De plus, le mot clé status renvoie des informations relatives à divers sous-états :
Configuration de haute disponibilité réciproque (le rôle de chaque machine Dispatcher est double) :
Remarques :
Exemples
dscontrol highavailability status
Résultat :
High Availability Status: ------------------------- Role ........................primary Recovery Strategy ........... manual State ....................... Active Sub-state.............. Synchronized Primary host........... 9.67.131.151 Port .........................12345 Preferred Target....... 9.67.134.223 Heartbeat Status: ----------------- Count ......................... 1 Source/destination ............ 9.67.131.151/9.67.134.223 Reachability Status: -------------------- Count ................ 1 Address .............. 9.67.131.1 reachable
dscontrol highavailability backup add primary auto 80
dscontrol highavailability reach add 9.67.125.18
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3
dscontrol highavailability takeover
>>-dscontrol--host:--hôte_distant-------------------------------><
dscontrol host:hôte_distant
Après avoir exécuté cette commande dans l'invite, saisissez une commande dscontrol valide destinée à la machine Load Balancer distante.
>>-dscontrol--logstatus----------------------------------------><
Exemples
Pour afficher l'état du journal, entrez :
dscontrol logstatus
Cette commande génère des résultats similaires à l'exemple suivant :
Etat du journal du Dispatcher : ------------------------------ Nom du fichier journal ............... C:\PROGRA~1\IBM\edge\lb\servers\logs\dispatcher \server.log Niveau de consignation ............... 1 Taille maxi du journal (octets) ...... 1048576
>>-dscontrol--manager--+-interval--secondes----------------------+->< +-loglevel--niveau------------------------+ +-logsize--+-unlimited-+-----------------+ | '-octets-----' | +-metric set--+-loglevel--niveau--------+-+ | '-logsize--+-unlimited-+-' | | '-octets-----' | +-quiesce--serveur--+-----+---------------+ | '-now-' | +-reach set--+-interval--secondes------+--+ | +-loglevel--niveau--------+ | | '-logsize--+-unlimited-+-' | | '-octets-----' | +-refresh--cycle de mise à jour-----------------+ +-report--+----------------+-------------+ | '-cluster+c2+...-' | +-restart--message-----------------------+ +-sensitivity--pondération--------------------+ +-smoothing--indice de lissage-------------+ +-start--+-----------------------+-------+ | '-fichier journal--port_décompte-' | +-status---------------------------------+ +-stop-----------------------------------+ +-unquiesce--serveur----------------------+ '-version--------------------------------'
Ou, si vous utilisez le partitionnement du serveur, entrez le nom unique du serveur logique. Pour plus d'informations, voir Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
Le fichier par défaut se trouve dans le répertoire logs. Voir Annexe C, Exemples de fichiers de configuration. Pour modifier le répertoire dans lequel sont enregistrés les fichiers journaux, voir Modification des chemins des fichiers journaux.
Exemples
dscontrol manager interval 5
dscontrol manager loglevel 0
dscontrol manager logsize 1000000
dscontrol manager quiesce 130.40.52.153
dscontrol manager refresh 3
dscontrol manager reportCette commande génère des résultats similaires à l'exemple suivant :
-------------------------------------------------------------------- | SERVER | IP ADDRESS | STATUS | -------------------------------------------------------------------- | mach14.dmz.com | 10.6.21.14 | ACTIVE | | mach15.dmz.com | 10.6.21.15 | ACTIVE | -------------------------------------------------------------------- ----------------------------- | MANAGER REPORT LEGEND | ----------------------------- | ACTV | Active Connections | | NEWC | New Connections | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | | CONN | Connections | ----------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | WEIGHT | ACTV | NEWC | PORT | SYS | | PORT: 21 |NOW NEW| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | -1 | 0 | | mach15.dmz.com | 10 10 | 0 | 0 | -1 | 0 | ------------------------------------------------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | WEIGHT | ACTV | NEWC | PORT | SYS | | PORT: 80 |NOW NEW| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | 23 | 0 | | mach15.dmz.com | 9 9 | 0 | 0 | 30 | 0 | ------------------------------------------------------------------- --------------------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------------------
dscontrol manager restart Restarting the manager to update codeCette commande génère des résultats similaires à l'exemple suivant :
320-14:04:54 Restarting the manager to update code
dscontrol manager sensitivity 10
dscontrol manager smoothing 2.0
dscontrol manager start ndmgr.log
dscontrol manager statusCette commande génère des résultats similaires à l'exemple suivant :
Manager status: =============== Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 0.05 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7 Metric monitor log file name.................. MetricMonitor.log Metric monitor log level...................... 1 Maximum metric monitor log size............... 1048576
dscontrol manager stop
dscontrol manager quiesce 130.40.52.153 now
dscontrol manager quiesce 130.40.52.153
dscontrol manager unquiesce 130.40.52.153
dscontrol manager version
>>-dscontrol--metric--+-add--cluster+c2+...+cN:mesure+mesure1+...+mesureN--------------+->< +-remove--cluster+c2+...+cN:mesure+mesure1+...+mesureN-----------+ +-proportions--cluster+c2+...+cN proportion1 prop2 prop3...propN-+ '-status--cluster+c2+...+cN:mesure+mesure1+...+mesureN-----------'
Exemples
dscontrol metric add site1:metric1
dscontrol metric proportions site1 0 100
dscontrol metric status site1:metric1Cette commande génère des résultats similaires à l'exemple suivant :
Metric Status: ------------ Cluster ....................... 10.10.10.20 Metric name ................... metric1 Metric proportion ............. 50 Server .................... plm3 Metric data ............... -1
>>-dscontrol--port--+-add--cluster:port--+----------------------+-+->< | +-crossport--autre port-+ | | +-maxservers--taille-----+ | | +-stickymask--valeur----+ | | +-stickytime--délai-----+ | | +-method--type---------+ | | +-staletimeout--valeur--+ | | +-weightbound--pondération--+ | | +-porttype--type-------+ | | +-protocol--type-------+ | | '-reset--valeur---------' | +-set--cluster:port--+-crossport--autre port-+-+ | +-maxservers--taille-----+ | | +-stickymask--valeur----+ | | +-stickytime--délai-----+ | | +-staletimeout--valeur--+ | | +-weightbound--pondération--+ | | +-porttype--type-------+ | | +-maxhalfopen--valeur---+ | | '-reset--valeur---------' | +-remove--cluster:port------------------------+ +-report--cluster:port------------------------+ +-status--cluster:port------------------------+ '-halfopenaddressreport--cluster:port---------'
Pour supprimer la fonction trans ports, replacez la valeur trans ports sur son propre numéro de port. Pour plus d'informations sur la fonction d'affinité de ports croisés, voir Affinité de ports croisés.
Composant Dispatcher :
Composant CBR : lorsque vous définissez un délai de routage différent de zéro, le type d'affinité par défaut (none) doit être associé à la commande rule. L'affinité basée sur les règles (cookie passif, URI, cookie actif) ne peut pas être utilisée lorsqu'un délai de maintien de routage est défini pour le port.
Remarques :
Une valeur positive indique qu'une vérification est effectuée pour déterminer si le nombre de connexions partielles en cours dépasse la limite autorisée. Si tel est le cas, un script d'alerte est appelé. Pour plus d'informations, voir Détection d'attaque de refus de service.
Exemples
dscontrol port add 130.40.52.153:80+23
dscontrol port set 130.40.52.153:0
dscontrol port set 130.40.52.153:80 weightbound 10
dscontrol port set 130.40.52.153:80+23 stickytime 60
dscontrol port set 130.40.52.153:80 crossport 23
dscontrol port remove 130.40.52.153:23
dscontrol port status 9.67.131.153:80Cette commande génère des résultats similaires à l'exemple suivant :
Port Status: ------------ Port number .................... 80 Cluster ........................ 9.67.131.153 Stale timeout .................. 300 Weight bound ................... 20 Maximum number of servers ...... 32 Sticky time .................... 0 Port type ...................... tcp/udp Cross Port Affinity ............ 80 Sticky mask bits ............... 32 Max Half Open Connections ...... 0 Send TCP Resets ................ no
dscontrol port report 9.62.130.157:80Cette commande génère des résultats similaires à l'exemple suivant :
Port Report: ------------ Cluster address ................ 9.62.130.157 Port number .................... 80 Number of servers .............. 5 Maximum server weight .......... 10 Total active connections ....... 55 Connections per second ......... 12 KBytes per second .............. 298 Number half open ............... 0 TCP Resets sent ................ 0 Forwarding method .............. MAC Based Forwarding
dscontrol port halfopenaddressreport 9.67.127.121:80Cette commande génère des résultats similaires à l'exemple suivant :
Half open connection report successfully created: ------------ Half Open Address Report for cluster:port = 9.67.127.121:80 Total addresses with half open connections reported ... 0 Total number of half open connections reported ........ 0 Largest number of half open connections reported ...... 0 Average number of half open connections reported ...... 0 Average half open connection time (seconds) reported .. 0 Total half open connections received .................. 0
>>-dscontrol--rule--+-add--cluster:port:règle--type--type--| opts |-+->< +-dropserver--cluster:port:règle--serveur--------+ +-remove--cluster:port:règle--------------------+ +-report--cluster:port:règle--------------------+ +-set--cluster:port:règle--| opts |-------------+ +-status--cluster:port:règle--------------------+ '-useserver--cluster:port:règle--serveur+s2+...--' opts: |--+---------------------------------+--------------------------| +-beginrange--bas--endrange--élevé-+ +-priority--niveau-----------------+ +-pattern--modèle----------------+ +-tos--valeur----------------------+ +-stickytime--délai----------------+ +-affinity--type_affinité---------+ +-cookiename--valeur---------------+ +-evaluate--niveau-----------------+ '-sharelevel--niveau---------------'
Pour plus d'informations, voir Affinité de cookie actif.
Le type d'affinité "activecookie" permet l'équilibrage de charge du trafic Web et une affinité avec le même serveur en fonction des cookies générés par Load Balancer.
Le type d'affinité "passivecookie" permet l'équilibrage de la charge du trafic Web et une affinité avec le même serveur en fonction des cookies d'auto-identification générés par les serveurs. Vous devez utiliser le paramètre cookiename avec l'affinité de cookie passif.
Le type d'affinité "URI" permet l'équilibrage de la charge du trafic Web vers des serveurs Caching Proxy dans le but d'augmenter la mémoire cache.
Pour plus d'informations, voir Affinité de cookie actif, Affinité de cookie passif et Affinité URI.
Pour plus d'informations, voir Affinité de cookie passif.
Pour la règle type de connexion, vous pouvez également indiquer l'option d'évaluation : upserversonrule. Grâce à cette option, les serveurs restants ne seront pas surchargés si l'un ou plusieurs d'entre eux s'arrêtent.
Ou, si vous utilisez le partitionnement du serveur, entrez le nom unique du serveur logique. Pour plus d'informations, voir Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
Exemples
dscontrol rule add 9.37.67.100:80:trule type true priority 100
dscontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
dscontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 dscontrol rule useserver cluster1:80:timerule server05
dscontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
dscontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
dscontrol cluster set 9.67.131.153 sharedbandwidth 200 dscontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-dscontrol--server--+-add--cluster:port:serveur--+-------------------------+-+->< | +-address--adresse--------+ | | +-collocated--valeur-------+ | | +-sticky--valeur-----------+ | | +-weight--valeur-----------+ | | +-fixedweight--valeur------+ | | +-cookievalue--valeur------+ | | +-mapport--valeur du port------+ | | +-protocol--valeur---------+ | | +-router--adresse------------+ | | +-returnaddress--adresse-----+ | | +-advisorrequest--chaîne--+ | | '-advisorresponse--chaîne-' | +-set--cluster:port:serveur--+-collocated--valeur-------+-+ | +-sticky--valeur-----------+ | | +-weight--valeur-----------+ | | +-fixedweight--valeur------+ | | +-cookievalue--valeur------+ | | +-protocol--valeur---------+ | | +-router--adresse------------+ | | +-advisorrequest--chaîne--+ | | '-advisorresponse--chaîne-' | +-down--cluster:port:serveur-----------------------------+ +-remove--cluster:port:serveur---------------------------+ +-report--cluster:port:serveur---------------------------+ +-up--cluster:port:serveur-------------------------------+ '-status--cluster:port:serveur---------------------------'
Ou, si vous utilisez un nom unique qui ne se résout pas en adresse IP, vous devez fournir le paramètre address du serveur dans la commande dscontrol server add. Pour plus d'informations, voir Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
Lorsqu'un serveur est arrêté à l'aide de la commande server down, si le délai de maintien de routage a une valeur différente de zéro pour ce serveur, les clients existants continuent à être servis par ce serveur jusqu'à expiration du délai. Le serveur n'est arrêté qu'après expiration du délai de maintien de routage.
Exemples
dscontrol server add 130.40.52.153:80:27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 sticky no
dscontrol server down 130.40.52.153:80:27.65.89.42
dscontrol server remove ::27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
dscontrol server set 130.40.52.153:80:27.65.89.42 weight 10
dscontrol server up 130.40.52.153:80:27.65.89.42
dscontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
dscontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/1.0\""
dscontrol server status 9.67.131.167:80:9.67.143.154Cette commande génère des résultats similaires à l'exemple suivant :
Server Status: -------------- Server ......................... 9.67.143.154 Port number .................... 80 Cluster ........................ 9.67.131.167 Cluster address ................ 9.67.131.167 Quiesced ....................... N Server up ...................... Y Weight ......................... 10 Fixed weight ................... N Sticky for rule ................ Y Remote server .................. N Network Router address ......... 0.0.0.0 Collocated ..................... N Advisor request................. HEAD / HTTP/1.0 Advisor response................ Cookie value ................... n/a Clone ID ....................... n/a
>>-dscontrol--set--+-loglevel--niveau--------+------------------>< '-logsize--+-unlimited-+-' '-taille------'
>>-dscontrol--status-------------------------------------------><
Exemples
dscontrol statusCette commande génère des résultats similaires à l'exemple suivant :
Executor has been started. Manager has been started. ---------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | ---------------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | ----------------------------------------
>>-dscontrol--subagent--+-loglevel--niveau--------------------+->< +-logsize--+-octets-----+-------------+ | '-unlimited-' | +-report-----------------------------+ +-start--+-------------------------+-+ | '-nom_communauté--fichier journal-' | +-status-----------------------------+ +-stop-------------------------------+ '-version----------------------------'
Sous Windows : le nom de communauté du système d'exploitation est utilisé.
Exemples
dscontrol subagent start bigguy bigguy.log
Le présent chapitre décrit l'utilisation des commandes sscontrol de Site Selector :
Vous pouvez entrer une version abrégée des paramètres de commandes sscontrol. Il suffit d'entrer les lettres spécifiques des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, entrez sscontrol he f à la place de sscontrol help file.
>>-sscontrol--advisor--+-connecttimeout--nom--+-port----------+--secondes-------+->< | '-nom_site:port-' | +-interval--nom--+-port----------+--secondes-------------+ | '-nom_site:port-' | +-list---------------------------------------------------+ +-loglevel--nom--+-port----------+--niveau---------------+ | '-nom_site:port-' | +-logsize--nom--+-port----------+--+-size | unlimited-+-+ | '-nom_site:port-' '-octets------------' | +-receivetimeout--nom--+-port----------+--secondes-------+ | '-nom_site:port-' | +-report--nom--+-port----------+------------------------+ | '-nom_site:port-' | +-retries--nom--+-port----------+--nombre de tentatives-----------+ | '-nom_site:port-' | +-start--nom--+-port----------+--+----------+-----------+ | '-nom_site:port-' '-fichier journal-' | +-status--nom--+-port----------+------------------------+ | '-nom_site:port-' | +-stop--nom--+-port----------+--------------------------+ | '-nom_site:port-' | +-timeout--nom--+-port----------+-----------------------+ | '-nom_site:port-' | '-version--nom--+-port----------+--secondes--------------' '-nom_site:port-'
.
Nom du conseiller | Protocole | Port |
---|---|---|
Connect | n/a | Défini par l'utilisateur |
db2 | privé | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
PING | PING | N/A |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
Le fichier par défaut est nom_conseiller_port.log, par exemple, http_80.log. Pour modifier le répertoire dans lequel sont enregistrés les fichiers journaux, voir Modification des chemins des fichiers journaux.
Vous ne pouvez lancer qu'un conseiller par nom de site.
Exemples
sscontrol advisor connecttimeout http 80 30
sscontrol advisor interval ftp 21 6
sscontrol advisor listCette commande génère des résultats similaires à l'exemple suivant :
--------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | --------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
sscontrol advisor loglevel http monSite:80 0
sscontrol advisor logsize ftp monSite:21 5000
sscontrol advisor receivetimeout http 80 60
sscontrol advisor report ftp 21Cette commande génère des résultats similaires à l'exemple suivant :
Advisor Report: --------------- Advisor name ............. http Port number .............. 80 sitename ................. mySite Server address ........... 9.67.129.230 Load ..................... 8
sscontrol advisor start ftp 21 ftpadv.log
sscontrol advisor status http 80Cette commande génère des résultats similaires à l'exemple suivant :
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited Number of retries ............. 0
sscontrol advisor stop http 80
sscontrol advisor timeout ftp 21 5
sscontrol advisor version ssl 443
>>-sscontrol--file--+-delete--nomfichier.ext----------+---------->< +-appendload--nomfichier.ext------+ +-report------------------------+ +-save--nomfichier.ext--+-------+-+ | '-force-' | '-newload--nomfichier.ext---------'
Vous pouvez indiquer n'importe quelle extension de fichier (.ext) ou n'en indiquer aucune.
Exemples
sscontrol file delete file3 Le fichier (file3) est supprimé.
sscontrol file newload file1.sv Le fichier (file1.sv) a été chargé dans Dispatcher.
sscontrol file appendload file2.sv Le fichier (file2.sv) a été chargé et ajouté à la configuration actuelle.
sscontrol file report FILE REPORT: file1.save file2.sv file3
sscontrol file save file3 La configuration est sauvegardée dans file3.
>>-sscontrol--help--+-advisor----+----------------------------->< +-file-------+ +-help-------+ +-host-------+ +-logstatus--+ +-manager----+ +-metric-----+ +-nameserver-+ +-rule-------+ +-server-----+ +-set--------+ +-sitename---+ '-status-----'
Exemples
sscontrol helpCette commande génère des résultats similaires à l'exemple suivant :
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Exemple: help name help - print complete help text advisor - help on advisor command file - help on file command host - help on host command manager - help on manager command metric - help on metric command sitename - help on sitename command nameserver - help on nameserver command rule - help on rule command server - help on server command set - help on set command status - help on status command logstatus - help on logstatus commandLes paramètres entre caractères < > sont des variables.
logsize <nombre d'octets | unlimited> - Nombre maximal d'octets à consigner dans le journal
>>-sscontrol--logstatus----------------------------------------><
>>-sscontrol--manager--+-interval--secondes----------------------+->< +-loglevel--niveau------------------------+ +-logsize--+-unlimited-+-----------------+ | '-octets-----' | +-metric set--+-loglevel--niveau--------+-+ | '-logsize--+-unlimited-+-' | | '-octets-----' | +-reach set--+-interval--secondes------+--+ | +-loglevel--niveau--------+ | | '-logsize--+-unlimited-+-' | | '-octets-----' | +-report--nom_site+sn2+...+snN-----------+ +-restart--message-----------------------+ +-sensitivity--pondération--------------------+ +-smoothing--indice de lissage-------------+ +-start--+----------------------+--------+ | '-fichier journal--port_décompte-' | +-status---------------------------------+ +-stop-----------------------------------+ '-version--------------------------------'
Le fichier par défaut se trouve dans le répertoire logs. Voir Annexe C, Exemples de fichiers de configuration. Pour modifier le répertoire dans lequel sont enregistrés les fichiers journaux, voir Modification des chemins des fichiers journaux.
Exemples
sscontrol manager interval 5
sscontrol manager loglevel 0
sscontrol manager logsize 1000000
sscontrol manager reportCette commande génère des résultats similaires à l'exemple suivant :
---------------------------------- | SERVER | STATUS | ---------------------------------- | 9.67.129.221| ACTIVE| | 9.67.129.213| ACTIVE| | 9.67.134.223| ACTIVE| ---------------------------------- -------------------------- | MANAGER REPORT LEGEND | -------------------------- | CPU | CPU Load | | MEM | Memory Load | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | -------------------------- ------------------------------------------------------------------------ | mySite | WEIGHT | CPU 49% | MEM 50% | PORT 1% | SYS 0% | ------------------------------------------------------------------------ | |NOW NEW | WT LOAD | WT LOAD | WT LOAD | WT LOAD | ------------------------------------------------------------------------ | 9.37.56.180 | 10 10 |-99 -1|-99 -1|-99 -1| 0 0| ------------------------------------------------------------------------ | TOTALS:| 10 10 | -1| -1| -1| 0| ------------------------------------------------------------------------ ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ----------------------------------------- | http | 80 | unlimited | -----------------------------------------
sscontrol manager restart Relance du gestionnaire pour mettre à jourCette commande génère des résultats similaires à l'exemple suivant :
320-14:04:54 Restarting the manager to update code
sscontrol manager sensitivity 10
sscontrol manager smoothing 2.0
sscontrol manager start ndmgr.log
sscontrol manager statusCette commande génère des résultats similaires à l'exemple suivant :
Manager status: ============= Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 5 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7
sscontrol manager stop
sscontrol manager version
>>-sscontrol--metric--+-add--nom_site+ns2+...+nsN:mesure+mesure1+...+mesureN--------------+->< +-remove--nom_site+ns2+...+nsN:mesure+mesure1+...+mesureN-----------+ +-proportions--nom_site+ns2+...+nsnN:proportion1 prop2 prop3...propN-+ '-status--nom_site+ns2+...+nsN mesure+mesure1+...+mesureN-----------'
Exemples
sscontrol metric add site1:metric1
sscontrol metric proportions site1 0 100
sscontrol metric status site1:metric1Cette commande génère des résultats similaires à l'exemple suivant :
Metric Status: ------------ sitename ..................... site1 Metric name ................... metric1 Metric proportion ............. 50 Server ......... 9.37.56.100 Metric data .... -1
>>-sscontrol--nameserver--+-start--+----------------------+-+-->< | '-bindaddress--adresse-' | +-stop----------------------------+ '-status--------------------------'
>>-sscontrol--rule--+-add--nom_site+ns2+...+nsN:règle+r2+...+rN--type--valeur--| value |--| opts |-+->< +-dropserver--nom_site+ns2+...+nsN:règle+r2+...+rN--serveur+s2+...+nsN---------+ +-remove--nom_site+ns2+...+nsN:règle+r2+...+rN--------------------------------+ +-set--nom_site+ns2+...+nsN:règle+r2+...+rN--| value |--| opts |--------------+ +-status--nom_site+ns2+...+nsN:règle+r2+...+rN--------------------------------+ '-useserver--nom_site+ns2+...+nsN:règle+r2+...+rN--serveur+s2+...+nsN----------' opts : |--+---------------------------------+--------------------------| +-beginrange--bas--endrange--élevé-+ +-priority--valeur-----------------+ '-metricname--valeur---------------'
Exemples
sscontrol rule add sitename:rulename type true priority 100
sscontrol rule add sitename:rulename type ip b 9.0.0.0 e 9.255.255.255
sscontrol rule add sitename:rulename type time beginrange 11 endrange 14 sscontrol rule useserver sitename:rulename server05
>>-sscontrol--server--+-add--nom_site+ns2+...+nssnN:serveur+s2+...+sN--+------------------------+-+->< | +-metricaddress--adresse-+ | | '-weight--valeur----------' | +-down--nom_site+ns2+...+nsN:serveur+s2+...+sN----------------------------+ +-remove--nom_site+ns2+...+nsN:serveur+s2+...+sN--------------------------+ +-set--nom_site+ns2+...+nsN:serveur+s2+...+sN--+------------------------+-+ | +-metricaddress--adresse-+ | | '-weight--valeur----------' | +-status--nom_site+ns2+...+nsN:serveur+s2+...+sN--------------------------+ '-up--nom_site+ns2+...+nsN:serveur+s2+...+sN------------------------------'
Exemples
sscontrol server add site1:27.65.89.42
sscontrol server down site1:27.65.89.42
sscontrol server remove :27.65.89.42
sscontrol server up site1:27.65.89.42
>>-sscontrol--set--+-loglevel--niveau--------+------------------>< '-logsize--+-unlimited-+-' '-taille------'
>>-sscontrol--sitename--+-add--nom_site+ns2+...+nsN--+----------------------------------------+-+->< | +-cachelife--valeur-----------------------+ | | +-networkproximity--oui | non-------------+ | | +-proportions--unité centrale--mémoire--port--mesure-+ | | +-proximitypercentage--valeur-------------+ | | +-stickytime--délai-----------------------+ | | +-ttl--délai------------------------------+ | | +-waitforallresponses--oui | non----------+ | | '-weightbound--pondération--------------------' | +-remove--nom_site+ns2+...+nsN------------------------------------------+ +-set--nom_site+ns2+...+nsN--+----------------------------------------+-+ | +-cachelife--valeur-----------------------+ | | +-networkproximity--oui | non-------------+ | | +-proportions--unité centrale--mémoire--port--mesure-+ | | +-proximitypercentage--valeur-------------+ | | +-stickytime--délai-----------------------+ | | +-ttl--délai------------------------------+ | | +-waitforallresponses--oui | non----------+ | | '-weightbound--pondération--------------------' | '-status--nom_site+ns2+...+nsN------------------------------------------'
Exemples
sscontrol sitename add 130.40.52.153
sscontrol sitename set mySite networkproximity yes
sscontrol sitename set mySite cachelife 1900000
sscontrol sitename set mySite proximitypercentage 45
sscontrol sitename set mySite waitforallresponses no
sscontrol sitename set mySite ttl 7
sscontrol sitename set mySite proportions 50 48 1 1
sscontrol sitename remove 130.40.52.153
sscontrol sitename status mySiteCette commande génère des résultats similaires à l'exemple suivant :
SiteName Status: --------------- SiteName ........................... mySite WeightBound ........................ 20 TTL ................................ 5 StickyTime ......................... 0 Number of Servers .................. 1 Proportion given to CpuLoad ........ 49 Proportion given to MemLoad ........ 50 Proportion given to Port ........... 1 Proportion given to System metric .. 0 Advisor running on port ............ 80 Using Proximity .................... N
>>-sscontrol--status-------------------------------------------><
Exemples
sscontrol statusCette commande génère des résultats similaires à l'exemple suivant :
NameServer has been started. Manager has been started. ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ---------------------------------------- | http | 80 | unlimited | -----------------------------------------
Le présent chapitre décrit l'utilisation des commandes ccocontrol de Cisco CSS Controller :
Vous pouvez utiliser une version abrégée des paramètres de la commande ccocontrol en entrant simplement la ou les quelques lettres d'identification des paramètres. Ainsi, pour obtenir de l'aide sur la commande file save, vous pouvez entrer ccocontrol he f au lieu de ccocontrol help file.
Pour afficher l'invite de la commande de ccocontrol, entrez : ccocontrol.
Pour quitter l'interface de l'invite de commande , exécutez la commande exit ou quit.
>>-ccocontrol--consultant--+-add--IDcc--address--AdrIPCom--community--nom_communauté-+->< +-binarylog--IDcc+IDcc2...--+-report-------------+--+ | +-set--+-intervalle--+-+ | | | '-conservation-' | | | +-start--------------+ | | '-stop---------------' | +-remove--IDcc+IDcc2...-----------------------------+ +-report--IDcc+IDcc2...-----------------------------+ +-set--+-loglevel--niveau----------------+-----------+ | +-logsize--+-taille------+---------+ | | | '-illimité-' | | | +-sensitivity--pourcentage de pondération-+ | | '-sleeptime--sec-----------------' | +-start--IDcc+IDcc2...------------------------------+ '-stop--IDcc+IDcc2...-------------------------------'
0 = Aucun
1 = Minimal
2 = De base
3 = Modéré
4 = Avancé
5 = Prolixe
Exemples
ccocontrol consultant add cc1 address 9.37.50.17 community comm2
ccocontrol consultant binarylog cc1 start
ccocontrol consultant report cc1
Cette commande génère des résultats similaires à l'exemple suivant :
Consultant sc1 connected to switch at 9.37.50.1:cn1 Consultant has been started Sleep time = 7 Sensitivity = 5 Log level = 5 Log size = 1,048,576 ownerContent(s): ownerContent oc1
ccocontrol consultant set cc1 sleeptime 10
ccocontrol consultant start cc1
>>-ccocontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--niveau--------+ '-logsize--+-taille------+-' '-illimité-'
0 = Aucun
1 = Minimal
2 = De base
3 = Modéré
4 = Avancé
5 = Prolixe
Exemples
ccocontrol controller report
Cette commande génère des résultats similaires à l'exemple suivant :
Controller Report: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Logging level . . . . . . 1 Log size. . . . . . . . . 1048576 Configuration File. . . . config1.xml Consultants: Consultant consult1 -Started
ccocontrol set loglevel 0
ccocontrol controller set logsize 1000000
>>-ccocontrol--file--+-delete--nomfichier----------+------------->< +-load--nomfichier------------+ +-report--------------------+ '-save--nomfichier--+-------+-' '-force-'
Répertoire d'installation (par défaut) : C:\Program Files\ibm\edge\lb\servers\configurations\cco
Exemples
ccocontrol file delete file1
ccocontrol file load config2
ccocontrol file report
Cette commande génère des résultats similaires à l'exemple suivant :
FILE REPORT: ------------ file1.xml file2.xml file3.xml
ccocontrol file save config2
>>-ccocontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metriccollector--+ +-ownercontent-----+ '-service----------'
Exemples
ccocontrol help
Cette commande génère des résultats similaires à l'exemple suivant :
The following commands are available: controller - operate on the controller consultant - operate on switch consultants file - operate on configuration files help - operate on help highavailability - operate on high availability metriccollector - operate on metric collectors ownerContent - operate on ownerContents service - operate on services
>>-ccocontrol--highavailability--+-add--+-address--adresse---------------+-+->< | +-partneraddress--adresse_partenaire-+ | | +-port--port---------------------+ | | '-role--+-principal---+------------' | | '-secondaire-' | +-dropreach--adresse----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--délai-----+---------+ | +-takeoverinterval--délai-+ | | +-loglevel--niveau--------+ | | '-logsize--+-taille------+-' | | '-illimité-' | +-start--+-auto---+-----------------------+ | '-manuel-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--adresse-----------------------'
0 = Aucun
1 = Minimal
2 = De base
3 = Modéré
4 = Avancé
5 = Prolixe
ccocontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
ccocontrol highavailability usereach 9.37.50.9
ccocontrol highavailability dropreach 9.37.50.9
ccocontrol highavailability start manual
ccocontrol highavailability report
Cette commande génère des résultats similaires à l'exemple suivant :
High Availability Status: ------------------------- Node . . . . . . . . . . . primary Node Address . . . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Partner Address. . . . . . 9.37.50.14 Recovery Strategy. . . . . manual Heartbeat Interval . . . . 500 Takeover Interval. . . . . 2000 State. . . . . . . . . . . idle Sub-state. . . . . . . . . unsynchronized Reachability Status : Node/Partner --------------------------------------- Aucune cible configurée
>>-ccocontrol--metriccollector--+-report--IDcc+ID2cc+...:Nm+Nm2...--------------------------+->< '-set--IDcc+ID2cc+...:Nm+Nm2...--+-timeoutconnect--sec----+-' +-loglevel--niveau--------+ +-logsize--+-taille------+-+ | '-illimité-' | +-timeoutreceive--sec----+ '-sleeptime--sec---------'
0 = Aucun
1 = Minimal
2 = De base
3 = Modéré
4 = Avancé
5 = Prolixe
Exemples
ccocontrol metriccollector report cc1:http
Cette commande génère des résultats similaires à l'exemple suivant :
MetricCollector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
ccocontrol metriccollector set cc1:http timeoutconnect 15 logsize unlimited
>>-ccocontrol--ownerContent--+-add--IDcc:Nomcp--ownername--Np--contentrule--Nc------------------------------+->< +-metrics--IDcc+IDcc2...:Nomcp+Nomcp2...--Nm--importance--Nm2--i2----------------+ +-refresh--IDcc+IDcc2...:Nomcp+Nomcp2...-----------------------------------------+ +-remove--IDcc+IDcc2...:Nomcp+Nomcp2...------------------------------------------+ +-report--IDcc+IDcc2...:Nomcp+Nomcp2...------------------------------------------+ '-set--IDcc+IDcc2...:Nomcp+Nomcp2...----metric--Nm--+------------------------+---' +-requeststring--chaîne--+ +-responsestring--chaîne-+ '-retry--nombre de tentatives------'
Voici la liste des noms de mesure admis et des ports qui leur sont associés :
Nom du conseiller | Protocole | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | privé | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (via Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | privé | 10,007 |
activeconn | n/a | n/a |
connrate | n/a | n/a |
cpuload | n/a | n/a |
memload | n/a | n/a |
Exemples
ccocontrol ownerContent add cc1:cp1 ownername propriétaire1 contentrule contenu1
ccocontrol ownerContent metrics cc1:cp1 activeconn 50 http 50
ccocontrol ownerContent report cc1:cp1
Cette commande génère des résultats similaires à l'exemple suivant :
ownerContent sc1:oc1 Weightbound = 10 Metric activeconn has proportion 25 ResponseString... n/a RequestString.... n/a Metric http has proportion 50 ResponseString... n/a RequestString.... n/a Metric connrate has proportion 25 ResponseString... n/a RequestString.... n/a Contains Service t3 Contains Service t2 Contains Service t1
ccocontrol ownerContent set cc1:cp1 metric http requeststring getCookie
>>-ccocontrol--service--+-report--IDcc+IDcc2...:Nomcp+Nomcp2...:svc+svc2...---------------------------------+->< '---set--IDcc+IDcc2...:Nomcp+Nomcp2...:svc+svc2...--+---------------------------+---' +-fixedweight--+-entier-+--+ | '-off-----' | +-requestsourceip--AdrIP-----+ +-metricserveraddress--AdrIP-+ '-metricserverport--Nport---'
Exemples
ccocontrol service report sc1:oc1:t1
Cette commande génère des résultats similaires à l'exemple suivant :
Service sc1:oc1:ta has weight 10 Fixed weight is off Request Source Ip..... 9.27.24.156 Application port...... 80 MetricServer address.. 1.0.0.1 MetricServer port..... 10004 Metric activeconn has value -99 Metric http has value -99 Metric connrate has value -99
ccocontrol service set cc1:cp1:t2 metricserveraddress 9.37.50.17
Le présent chapitre décrit l'utilisation des commandes nalcontrol de Nortel Alteon Controller.
Vous pouvez utiliser une version abrégée des paramètres de la commande nalcontrol en entrant simplement la ou les quelques lettres d'identification des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, vous pouvez entrer nalcontrol he f au lieu de nalcontrol help file.
Pour afficher l'invite de la commande de nalcontrol, entrez : nalcontrol.
Pour quitter l'interface de l'invite de commande , exécutez la commande exit ou quit.
>>-nalcontrol--consultant--+-add--IDcc--address--AdrIPc--+---------------------------+-+->< | +-rcommunity--NomComlec--+ | | '-wcommunity--NomComéc-' | +-binarylog--IDcc+IDcc2...--+-report------------------------+-+ | +-set--+-interval--intervalle---+-+ | | | '-retention--conservation-' | | | +-start-------------------------+ | | '-stop--------------------------' | +-remove--IDcc+IDcc2...---------------------------------------+ +-report--IDcc+IDcc2...---------------------------------------+ +-set--+--------------------------------+---------------------+ | +-loglevel--niveau----------------+ | | +-logsize--+-taille------+---------+ | | | '-illimité-' | | | +-sensitivity--pourcentage de pondération-+ | | '-sleeptime--sec-----------------' | +-start--IDcc+IDcc2...----------------------------------------+ '-stop--IDcc+IDcc2...-----------------------------------------'
0 = Aucun
1 = Minimal
2 = De base
3 = Modéré
4 = Avancé
5 = Prolixe
Exemples
nalcontrol consultant add cc1 address 9.37.50.17
nalcontrol consultant binarylog cc1 start
nalcontrol consultant report cc1
Cette commande génère des résultats similaires à l'exemple suivant :
Consultant ID: sc1 Switch IP addr: 9.37.50.1 Read Community: public Write Community: private Consultant has been started Sleep time = 7 Sensitivity = 5 Log level = 5 log size = 1,048,576 Service(s): Service svc1
nalcontrol consultant set cc1 sleeptime 10
nalcontrol consultant start cc1
>>-nalcontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--niveau--------+ '-logsize--+-taille------+-' '-illimité-'
0 = Aucun
1 = Minimal
2 = De base
3 = Modéré
4 = Avancé
5 = Prolixe
Exemples
nalcontrol controller report
Cette commande génère des résultats similaires à l'exemple suivant :
Controller Report: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Logging level . . . . . . 1 Log size. . . . . . . . . 1048576 Configuration File. . . . config1.xml Consultants: Consultant consult1 -Started
nalcontrol set loglevel 0
nalcontrol controller set logsize 1000000
>>-nalcontrol--file--+-delete--nomfichier-+---------------------->< +-load--nomfichier---+ +-report-----------+ '-save--nomfichier---'
Chemin d'accès au répertoire d'installation -- C:\Program Files\ibm\edge\lb\servers\configurations\nal
Chemin d'accès au répertoire d'installation natif -- C:\Program Files\ibm\lb\servers\configurations\nal
Exemples
nalcontrol file delete file1
nalcontrol file load config2
nalcontrol file report
Cette commande génère des résultats similaires à l'exemple suivant :
FILE R EPORT: ------------ file1.xml file2.xml file3.xml
nalcontrol file save config2
>>-nalcontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metrinalllector--+ +-ownercontent-----+ '-service----------'
Exemples
nalcontrol help
Cette commande génère des résultats similaires à l'exemple suivant :
The f ollowing commands are available: controller - operate on the controller consultant - operate on switch consultants file - operate on configuration files help - operate on help highavailability - operate on high availability metriccollector - operate on metric collectors server - operate on servers service - operate on services
>>-nalcontrol--highavailability--+-add--+-address--adresse---------------+-+->< | +-partneraddress--adressepartenaire-+ | | +-port--port---------------------+ | | '-role--+-principal---+------------' | | '-secondaire-' | +-dropreach--adresse----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--délai-----+---------+ | +-takeoverinterval--délai-+ | | +-loglevel--niveau--------+ | | '-logsize--+-taille------+-' | | '-illimité-' | +-start--+-auto---+-----------------------+ | '-manuelle-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--adresse-----------------------'
0 = Aucun
1 = Minimal
2 = De base
3 = Modéré
4 = Avancé
5 = Prolixe
nalcontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
nalcontrol highavailability usereach 9.37.50.9
nalcontrol highavailability dropreach 9.37.50.9
nalcontrol highavailability start manual
nalcontrol highavailability report
Cette commande génère des résultats similaires à l'exemple suivant :
High Availability Status: ------------------------- Node . . . . . . . . . . . primary Node Address . . . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Partner Address. . . . . . 9.37.50.14 Recovery Strategy. . . . . manual Heartbeat Interval . . . . 500 Takeover Interval. . . . . 2000 Started. . . . . . . . . . N State. . . . . . . . . . . idle Sub-state. . . . . . . . . unsynchronized Reachability Status : Node/Partner ---------------------------------------
>>-nalcontrol--metricollector--+-report--IDcc+IDcc2+...:Nm+Nm2...--------------------------+->< '-set--IDcc+IDcc2+...:Nm+Nm2...--+-connecttimeout--sec----+-' +-loglevel--niveau--------+ +-logsize--+-taille------+-+ | '-illimité-' | +-receivetimeout--sec----+ '-sleeptime--sec---------'
0 = Aucun
1 = Minimal
2 = De base
3 = Modéré
4 = Avancé
5 = Prolixe
Exemples
nalcontrol metrinalllector report cc1:http
Cette commande génère des résultats similaires à l'exemple suivant :
Metrinalllector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
nalcontrol metrinalllector set cc1:http connecttimeout 15 logsize unlimited
>>-nalcontrol--serer--+-report--IDcc+IDcc2...:IDsvc+IDsvc2...:IDserveur+IDserveur2...-----------------------------------+->< '---set--IDcc+IDcc2...:IDsvc+IDsvc2...:IDserveur+IDserveur2...--+--------------------------------+---' +-fixedweight--+-entier-+-------+ | '-off-----' | +-requestsourceip--AdrIP-----+ +-metricserveraddress--AdrIP-+ '-metricserverport--Numport---'
Exemples
nalcontrol server report sc1:svc1:1
Cette commande génère des résultats similaires à l'exemple suivant :
Server sc1:svc1:1 has weight -99 Fixed weight is off Request Source Ip...... 9.27.24.156 Application port....... 99 MetricServer address... 9.99.99.98 MetricServer port...... 10004 Metric activeconn has value -99 Metric connrate has value -99
nalcontrol server set cc1:svc1:2 metricserveraddress 9.37.50.17
>>-nalcontrol--service--+-add--IDcc+IDcc2...:IDservice+IDservice2...--vsid--IDSvrvir--vport--NumPortvirt------+->< +-metrics--IDcc+IDcc2...:IDservice+IDservice2...--Nm--importance--mCN2--i2---------------+ +-refresh--IDcc+IDcc2...:IDservice+IDservice2...-----------------------------------------+ +-remove--IDcc+IDcc2...:IDservice+IDservice2...------------------------------------------+ +-report--IDcc+IDcc2...:IDservice+IDservice2...------------------------------------------+ '-set--IDcc+IDcc2...:IDservice+IDservice2...----metric--Nm----+-requeststring--chaîne--+-' +-responsestring--chaîne-+ '-retry--nombre de tentatives------'
Voici la liste des noms de mesure admis et des ports qui leur sont associés :
Nom du conseiller | Protocole | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | privé | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (via Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | privé | 10,007 |
activeconn | n/a | n/a |
connrate | n/a | n/a |
cpuload | n/a | n/a |
memload | n/a | n/a |
Exemples
nalcontrol service add cc1:svc1 vsid 1 vport 80
nalcontrol service metrics cc1:svc1 activeconn 50 http 50
nalcontrol service report cc1:svc1
Cette commande génère des résultats similaire à l'exemple suivant :
Service sc1:svc1 Weightbound = 48 Metric activeconn has proportion 50 Metric connrate has rpoportion 50 Contains Server 4 Contains Server 3 Contains Server 2 Contains Server 1
nalcontrol service set cc1:svc1 metric http requeststring getLastErrorCode
La partie gauche de l'interface graphique utilisateur de Load Balancer présente une arborescence dont le niveau supérieur comporte Load Balancer. Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller et Nortel Alteon Controller sont représentés en tant que composants.
Figure 41. Interface graphique affichant l'arborescence du composant Dispatcher
Figure 42. Interface graphique affichant l'arborescence du composant CBR
Figure 43. Interface graphique affichant l'arborescence du
composant Site Selector
Figure 44. Interface graphique affichant l'arborescence du composant Cisco CSS Controller
Figure 45. Interface graphique affichant l'arborescence du
composant Nortel Alteon Controller
Tous les composants peuvent être configurés à partir de l'interface graphique. Pour sélectionner des éléments dans l'arborescence, cliquez à l'aide du bouton un de la souris (normalement le bouton gauche) et pour afficher les menus en incrustation, cliquez à l'aide du bouton deux (normalement le bouton droit). Les menus en incrustation des éléments de l'arborescence sont également disponibles à partir de la barre de menus située dans la partie supérieure de la fenêtre.
Cliquez sur les signes plus ou moins pour développer ou réduire les éléments de l'arborescence.
Pour exécuter une commande à partir de l'interface graphique : mettez le noeud Hôte en surbrillance dans l'arborescence de l'interface graphique, puis sélectionnez Envoyer la commande... dans le menu en incrustation Hôte. Dans la zone d'entrée de commande, exécutez la commande à exécuter, par exemple executor report. Les résultats et l'historique des commandes exécutées lors de la session courante s'affichent dans la fenêtre ouverte.
La partie droite de la fenêtre contient deux listes d'indicateurs d'état relatifs à l'élément sélectionné.
Pour accéder à l'aide, cliquez sur le point d'interrogation (?) situé dans l'angle supérieur droit de la fenêtre Load Balancer.
La présente annexe décrit l'utilisation de la syntaxe de règle de contenu (modèle) pour le composant CBR et la méthode d'acheminement CBR de Dispatcher. Elle contient en outre des scénarios et des exemples de syntaxe.
Ne s'applique que si vous avez sélectionné le type de règle Contenu.
Entrez la syntaxe voulue en tenant compte des restrictions suivantes :
Les mots clés réservés sont toujours suivis d'un signe égal " = ".
Un navigateur demandant la page http://www.entreprise.com/path/webpage.htm peut obtenir des résultats du type suivant :
Method=GET URI=/path/webpage.htm Version=HTTP/1.1 Host=www.company.com Connection=Keep-Alive Referer=http://www.company.com/path/parentwebpage.htm
Par exemple, la commande suivante n'est valide qu'à partir de l'invite cbrcontrol>> ou d'un fichier de configuration :
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Pour que cette commande fonctionne dans l'invite du système d'exploitation lorsque vous utilisez des caractères spéciaux, vous devez placez des guillemets de part et d'autre de la commande :
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*"
Si vous omettez les guillemets, le motif peut être tronqué lors de la sauvegarde de la règle dans CBR.
Ci-dessous, se trouve un ensemble de scénarios et des exemples d'utilisation des syntaxes de modèle
Scénario 1 :
La configuration d'un cluster implique un ensemble de serveurs Web pour le contenu HTML standard, un ensemble de serveurs Web avec WebSphere Application Server pour les demandes de servlet et un autre ensemble de serveurs Lotus(R) Notes(R) pour les fichiers NSF, etc. Pour effectuer la différence entre les pages demandées, l'accès aux données du client est requis. Il est également nécessaire de les envoyer aux serveurs appropriés. Les règles de correspondance de modèle de contenu permettent d'effectuer une séparation, nécessaire à l'accomplissement de ces tâches. Plusieurs règles sont configurées afin que la séparation des demandes nécessaire se produise automatiquement. Par exemple, les commandes suivantes provoquent les trois divisions indiquées :
>>rule add cluster1:80:servlets type content pattern "uri=*/servlet/*" priority 1 >>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern "uri=*.nsf*" priority 2 >>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3 >>rule uses cluster1:80:regular server5+server6
Si une requête de fichier NSF est reçue par Load Balancer, la règle servlets est vérifiée mais ne correspond pas. La demande est ensuite vérifiée par la règle notes qui trouve une correspondance. L'équilibrage de charge du client est effectué entre le serveur 3 et le serveur 4.
Scénario 2
Le contrôle par le site Web principal de plusieurs groupes internes constitue un autre scénario classique. Par exemple, l'ensemble de serveurs et le contenu de www.company.com/software sont différents de ceux de www.company.com/hardware . Etant donné que les demandes dépendent toutes du cluster www.company.com racine, les règles de contenu sont requises pour trouver les différences d'URI et pour effectuer l'équilibrage de charge. La règle du scénario peut être du type suivant :
>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2 >>rule uses cluster1:80:div2 server3+server4
Scénario 3
Pour certaines associations, l'ordre de recherche des règles est important. Par exemple, dans le scénario 2, les clients ont été séparés en fonction d'un répertoire dans leur chemin de demande. Cependant, le répertoire cible peut apparaître à plusieurs niveaux du chemin et la signification est différente en fonction de l'emplacement. Par exemple, la cible de www.company.com/pcs/fixes/software est différente de celle de www.company.com/mainframe/fixes/software . Les règles doivent être définies pour prendre en compte cette possibilité et ne doivent pas inclure trop de scénarios en même temps. Par exemple, la recherche générique du test "uri=*/software/*" est trop large. D'autres règles peuvent être structurées de la manière suivante :
Vous pouvez associer plusieurs recherches afin de restreindre la recherche :
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)" >>rule uses cluster 1:80:pcs server1
Dans le cas où il n'est pas possible d'utiliser des combinaisons, l'ordre est important :
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*" >>rule uses cluster1:80:pc1 server2
La seconde règle détecte l'apparition de " pcs " dans les répertoires ultérieurs du chemin et non le premier.
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*" >>rule uses cluster1:80:pc2 server3
Dans la plupart des cas, vous pouvez compléter les règles par une règle par défaut toujours vraie afin de détecter tous les éléments non pris en compte par les autres règles. Un serveur peut également renvoyer un message du type " Désolé, ce site est actuellement indisponible, réessayez ultérieurement", dans les scénarios pour lesquels aucun autre serveur ne peut renvoyer de réponse pour ce client.
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5
La présente annexe contient des exemples de fichiers de configuration pour le composant Dispatcher de Load Balancer.
Les exemples de fichiers se trouvent dans le répertoire ...ibm/edge/lb/servers/samples/.
#!/bin/bash
#
# configuration.sample - Exemple de fichier de configuration pour
composant
Dispatcher
#
#
# Ce script doit être lancé par le superutilisateur.
#
# iam=`whoami`
# if [ "$iam" != "root" ]if [ "$iam" != "root" ]
# then
# echo "Vous devez vous connecter en tant que superutilisateur pour exécuter ce script"
# exit 2
# fi
#
# Démarrez d'abord le serveur
#
# dsserver start
# sleep 5
#
# Démarrez ensuite l'exécuteur
#
# dscontrol executor start
#
# Il est possible d'arrêter le répartiteur à tout moment à l'aide
# des commandes "dscontrol executor stop" et "dsserver stop"
# pour arrêter respectivement l'exécuteur et le serveur avant
# d'arrêter le logiciel Dispatcher.
#
# L'étape suivante dans la configuration de Dispatcher consiste à définir
# l'adresse NFA (adresse de non-réacheminement) et les adresses de clusters.
#
# L'adresse NFA permet l'accès à distance au répartiteur
# afin d'effectuer des opérations d'administration et de configuration.
# Cette adresse est obligatoire car le répartiteur doit acheminer
# des paquets vers les adresses de clusters.
#
# L'adresse cluster correspond au nom d'hôte (ou à l'adresse IP)
# auquel les clients distants se connectent.
#
# Vous pouvez indifféremment utiliser les noms d'hôte et les adresses IP
# dans ce fichier.
#
# NFA=hostname.domain.name
# CLUSTER=www.yourcompany.com
# echo "Chargement de l'adresse de non réacheminement"
# dscontrol executor set nfa $NFA
#
# L'étape suivante dans la configuration de Dispatcher consiste à définir
# un cluster. Le répartiteur acheminera les requêtes envoyées
# à l'adresse de cluster vers les serveurs associés
# définis dans ce cluster. Vous pouvez configurer plusieurs adresses de
# clusters et leur associer plusieurs serveurs à l'aide de Dispatcher.
# Utilisez une configuration similaire pour CLUSTER2, CLUSTER3, etc.
#
# echo "Chargement de la première adresse de cluster"
# dscontrol cluster add $CLUSTER
#
# L'étape suivante consiste à définir les ports utilisés par ce cluster.
# Toute requête reçue par le répartiteur sur un port défini
# est réacheminée vers le port correspondant de l'un
# des serveurs.
#
# echo "Création des ports pour le cluster : $CLUSTER"
# dscontrol port add $CLUSTER:20+21+80
#
# La dernière étape consiste à associer chaque serveur
# aux ports de ce cluster.
# Vous pouvez utiliser indifféremment le nom
# d'hôte ou l'adresse IP des serveurs.
#
# SERVER1=nomserveur1.domaine.nom
# SERVER2=nomserveur2.domaine.nom
# SERVER3=nomserveur3.domaine.nom
# echo "Ajout des serveurs"
# dscontrol server add $CLUSTER:20+21+80:
# $SERVER1+$SERVER2+$SERVER3
#
# Nous allons maintenant lancer les composants d'équilibrage de charge
# du répartiteur. Le composant principal s'appelle le gestionnaire.
# Les autres composants d'équilibrage de charge sont les
# conseillers. Si le gestionnaire et les conseillers ne fonctionnent pas
# le répartiteur envoie des requêtes au format de permutation circulaire.
# Une fois le gestionnaire lancé, les décisions de pondération
# basées sur le nombre de connexions nouvelles et actives
# sont utilisées et les requêtes entrantes sont envoyées au meilleur
# serveur. Les conseillers donnent un aperçu au gestionnaire de la
# capacité des serveurs à répondre aux requêtes et à détecter
# si un serveur est actif ou non. Si un conseiller détecte
# l'inactivité d'un serveur, ce dernier est arrêté.
# Aucune autre requête n'est acheminée vers le serveur.
# La dernière étape de configuration des composants d'équilibrage de charge
# est la définition des proportions du gestionnaire. Ce dernier met à
# jour la pondération de chaque serveur en fonction de quatre règles :
# 1. Nombre de connexions actives sur chaque serveur.
# 2. Nombre de nouvelles connexions sur chaque serveur.
# 3. Informations fournies par les conseillers.
# 4. Informations fournies par le conseiller au niveau système.
# La somme de ces proportion doit être égale à 100. Par exemple,
# si l'on définit les proportions du gestionnaire de la façon suivante :
# dscontrol manager proportions 48 48 0 0
# 48 % des informations proviennent des connexions nouvelles, 48%
# des connexions actives, 4 % des conseillers et aucune entrée
# système n'est prise en compte. #
#
# REMARQUE : par défaut, les proportions du gestionnaire sont définies à 50 50 0 0.
#
# echo "Démarrage du gestionnaire (manager)..."
# dscontrol manager start
# echo "Démarrage du conseiller (advisor) FTP sur le port 21..."
# dscontrol advisor start ftp 21 +
# echo "Démarrage du conseiller (advisor) HTTP sur le port 80..."
# dscontrol advisor start http 80
# echo "Démarrage du conseiller (advisor) Telnet sur le port 23..."
# dscontrol advisor start telnet 23
# echo "Démarrage du conseiller (advisor) SMTP sur le port 25..."
# dscontrol advisor start smtp 25
# echo "Démarrage du conseiller (advisor) POP3 sur le port 110..."
# dscontrol advisor start pop3 110
# echo "Démarrage du conseiller (advisor) NNTP sur le port 119..."
# dscontrol advisor start nntp 119
# echo "Démarrage du conseiller (advisor) SSL sur le port 443..."
# dscontrol advisor start ssl 443
#
# echo "Définition des proportions du gestionnaire..."
# dscontrol manager proportions 58 40 2 0
#
# La dernière étape dans la configuration du répartiteur est
# l'attribution d'un alias à la carte d'interface réseau (NIC).
#
# REMARQUE : n'utilisez pas cette commande dans un environnement
# haute disponibilité. Les scripts go* configurent les cartes NIC
# et le bouclage si nécessaire.
# dscontrol executor configure $CLUSTER
# Si votre adresse de cluster se trouve sur une carte NIC ou sur
# un sous-réseau différents de ceux de la NFA, utilisez le format
# suivant pour la commande de configuration de cluster :
# dscontrol executor configure $CLUSTER tr0 0xfffff800
# Soit tr0 votre carte NIC (tr1 la seconde carte réseau en anneau
# à jeton, en0 la première carte Ethernet) et 0xfffff800 un masque
# de sous-réseau valide pour votre site.
#
#
# Les commandes suivantes sont définies avec les valeurs par défaut.
# Utilisez ces commandes pour modifier les valeurs par défaut.
# dscontrol manager loglevel 1
# dscontrol manager logsize 1048576
# dscontrol manager sensitivity 5
# dscontrol manager interval 2
# dscontrol manager refresh 2
#
# dscontrol advisor interval ftp 21 5
# dscontrol advisor loglevel ftp 21 1
# dscontrol advisor logsize ftp 21 1048576
# dscontrol advisor timeout ftp 21 unlimited
# dscontrol advisor interval telnet 23 5
# dscontrol advisor loglevel telnet 23 1
# dscontrol advisor logsize telnet 23 1048576
# dscontrol advisor timeout telnet 23 unlimited
# dscontrol advisor interval smtp 25 5
# dscontrol advisor loglevel smtp 25 1
# dscontrol advisor logsize smtp 25 1048576
# dscontrol advisor timeout smtp 25 unlimited
# dscontrol advisor interval http 80 5
# dscontrol advisor loglevel http 80 1
# dscontrol advisor logsize http 80 1048576
# dscontrol advisor timeout http 80 unlimited
# dscontrol advisor interval pop3 110 5
# dscontrol advisor loglevel pop3 110 1
# dscontrol advisor logsize pop3 110 1048576
# dscontrol advisor timeout pop3 110 unlimited
# dscontrol advisor interval nntp 119 5
# dscontrol advisor loglevel nntp 119 1
# dscontrol advisor logsize nntp 119 1048576
# dscontrol advisor timeout nntp 119 unlimited
# dscontrol advisor interval ssl 443 5
# dscontrol advisor loglevel ssl 443 1
# dscontrol advisor logsize ssl 443 1048576
# dscontrol advisor timeout ssl 443 unlimited
#
Le fichier de configuration Load Balancer suivant s'intitule configuration.cmd.sample et s'utilise sous Windows.
@echo off rem configuration.cmd.sample - Exemple de fichier de configuration pour rem le composant Dispatcher. rem rem Démarrez dsserver à partir du panneau Services rem rem rem Démarrez ensuite l'exécuteur rem rem call dscontrol executor start rem rem L'étape suivante dans la configuration du répartiteur consiste à définir rem l'adresse NFA (adresse de non-réacheminement) et les rem adresses de clusters. rem rem L'adresse NFA permet l'accès à distance du répartiteur rem afin d'effectuer des opérations d'administration et de configuration. rem Cette adresse est obligatoire car le répartiteur achemine rem des paquets vers les adresses de clusters. rem rem L'adresse de cluster correspond au nom d'hôte (ou à l'adresse IP) rem à laquelle les clients distants se connectent. rem rem Vous pouvez indifféremment utiliser les noms d'hôte et les adresses IP rem dans ce fichier. rem NFA=[adresse de non-réacheminement] rem CLUSTER=[nom du cluster] rem rem set NFA=nom_hôte.domaine.nom rem set CLUSTER=www.votresociété.com rem echo "Chargement de l'adresse de non réacheminement" rem call dscontrol executor set nfa %NFA% rem rem Les commandes suivantes sont définies avec les valeurs par défaut. rem Utilisez ces commandes pour modifier les valeurs par défaut. rem call dscontrol executor set fintimeout 30 rem rem L'étape suivante dans la configuration de Dispatcher consiste à définir rem un cluster. Le répartiteur achemine les requêtes envoyées rem à l'adresse de cluster vers les serveurs correspondants rem à ce cluster. Vous pouvez configurer plusieurs adresses de rem clusters à l'aide du répartiteur. rem Utilisez une configuration similaire pour CLUSTER2, CLUSTER3, etc. rem rem echo "Chargement de la première adresse de cluster" rem call dscontrol cluster add %CLUSTER% rem rem L'étape suivante consiste à définir les ports utilisés par ce cluster. rem Toute requête reçue par le répartiteur sur un port défini rem est réacheminée vers le port correspondant rem de l'un des serveurs. rem rem echo "Création des ports de CLUSTER : %CLUSTER%" rem call dscontrol port add %CLUSTER%:20+21+80 rem rem La dernière étape consiste à associer chaque serveur rem aux ports du cluster. Vous pouvez utiliser indifféremment rem le nom d'hôte ou l'adresse IP des machines serveurs. rem rem set SERVER1=nomserveur1.domaine.nom rem set SERVER2=nomserveur2.domaine.nom rem set SERVER3=nomserveur3.domaine.nom rem echo "Ajout des serveurs" rem call dscontrol server add %CLUSTER%:20+21+80: rem %SERVER1%+%SERVER2%+%SERVER3% rem rem Nous allons maintenant lancer les composants d'équilibrage de charge rem du répartiteur. Le composant principal s'appelle le gestionnaire. rem Les autres composants d'équilibrage de charge sont les rem conseillers. Si le gestionnaire et les conseillers ne sont pas rem actifs, le répartiteur envoie des requêtes au format de permutation rem circulaire. Une fois le gestionnaire lancé, les décisions de rem pondération basées sur le nombre de connexions nouvelles et actives rem sont utilisées et les requêtes entrantes sont envoyées au meilleur rem serveur. Les conseillers donnent un aperçu au gestionnaire de la rem capacité des serveurs à répondre aux requêtes et à détecter rem si un serveur est actif ou non. Si un conseiller détecte rem l'inactivité d'un serveur, ce dernier est arrêté rem (des proportions du gestionnaire incluent des entrées du conseiller) rem Aucune autre requête n'est achemine vers le serveur. rem La dernière étape de configuration des composants d'équilibrage de charge rem est la définition des proportions du gestionnaire. Ce dernier met rem à jour la pondération de chaque serveur en fonction de quatre règles : rem 1. Nombre de connexions actives sur chaque serveur. rem 2. Nombre de nouvelles connexions pour chaque serveur. rem 3. Informations fournies par les conseillers. rem 4. Informations fournies par le conseiller au niveau système. rem rem La somme de ces proportion doit être égale à 100. Par exemple, rem si l'on définit les proportions avec rem dscontrol cluster set <cluster> proportions 48 48 4 0 rem 48 % des informations proviennent des connexions nouvelles, 48% rem des connexions actives, 4 % des conseillers et aucune entrée rem système n'est prise en compte. rem rem REMARQUE : par défaut, les proportions du gestionnaire sont définies à rem 50 50 0 0 rem echo "Démarrage du gestionnaire (manager)..." rem call dscontrol manager start rem echo "Démarrage du conseiller (advisor) FTP sur le port 21..." rem call dscontrol advisor start ftp 21 rem echo "Démarrage du conseiller (advisor) HTTP sur le port 80..." rem call dscontrol advisor start http 80 rem echo "Démarrage du conseiller Telnet sur le port 23 ..." rem call dscontrol advisor start telnet 23 rem echo "Démarrage du conseiller SMTP sur le port 25 ..." rem call dscontrol advisor start smtp 25 rem echo "Démarrage du conseiller POP3 sur le port 110 ..." rem call dscontrol advisor start pop3 110 rem echo "Démarrage du conseiller NNTP sur le port 119 ..." rem call dscontrol advisor start nntp 119 rem echo "Démarrage du conseiller SSL sur le port 443 ..." rem call dscontrol advisor start ssl 443 rem rem echo "Définition des proportions du cluster..." rem call dscontrol cluster set %CLUSTER% proportions 58 40 2 0 rem rem L'étape finale de configuration du répartiteur est rem l'affectation d'un alias à la carte d'interface réseau (NIC). rem rem rem REMARQUE : n'utilisez pas cette commande dans un environnement rem haute disponibilité. Les scripts go* configurent les cartes NIC rem et l'unité de bouclage si nécessaire. rem rem dscontrol executor configure %CLUSTER% rem Si votre adresse de cluster se trouve sur une carte NIC ou sur rem un sous-réseau différents de ceux de la NFA, utilisez le format rem commande de configuration de cluster suivante. rem dscontrol executor configure %CLUSTER% tr0 0xfffff800 rem Soit tr0 votre carte NIC (tr1 la seconde carte réseau en anneau rem en0 la première carte Ethernet) et 0xfffff800 rem un masque de sous-réseau valide de votre site. rem rem rem Les valeurs par défaut sont affectées aux commandes suivantes. rem Utilisez ces commandes pour modifier les valeurs par défaut. rem call dscontrol manager loglevel 1 rem call dscontrol manager logsize 1048576 rem call dscontrol manager sensitivity 5 rem call dscontrol manager interval 2 rem call dscontrol manager refresh 2 rem rem call dscontrol advisor interval ftp 21 5 rem call dscontrol advisor loglevel ftp 21 1 rem call dscontrol advisor logsize ftp 21 1048576 rem call dscontrol advisor timeout ftp 21 unlimited rem call dscontrol advisor interval telnet 23 5 rem call dscontrol advisor loglevel telnet 23 1 rem call dscontrol advisor logsize telnet 23 1048576 rem call dscontrol advisor timeout telnet 23 unlimited rem call dscontrol advisor interval smtp 25 5 rem call dscontrol advisor loglevel smtp 25 1 rem call dscontrol advisor logsize smtp 25 1048576 rem call dscontrol advisor timeout smtp 25 unlimited rem call dscontrol advisor interval http 80 5 rem call dscontrol advisor loglevel http 80 1 rem call dscontrol advisor logsize http 80 1048576 rem call dscontrol advisor timeout http 80 unlimited rem call dscontrol advisor interval pop3 110 5 rem call dscontrol advisor loglevel pop3 110 1 rem call dscontrol advisor logsize pop3 110 1048576 rem call dscontrol advisor timeout pop3 110 unlimited rem call dscontrol advisor interval nntp 119 5 rem call dscontrol advisor loglevel nntp 119 1 rem call dscontrol advisor logsize nntp 119 1048576 rem call dscontrol advisor timeout nntp 119 unlimited rem call dscontrol advisor interval ssl 443 5 rem call dscontrol advisor loglevel ssl 443 1 rem call dscontrol advisor logsize ssl 443 1048576 rem call dscontrol advisor timeout ssl 443 unlimited rem
Vous trouverez ci-dessous un exemple de fichier de conseiller intitulé ADV_type.
/**
* ADV_type : le conseiller HTTP Load Balancer
*
*
*Cette classe définit un exemple de conseiller personnalisé pour Load Balancer.
* Comme tous les conseillers, le conseiller personnalisé étend la fonction de
* la base du conseiller, appelée ADV_Base. Cette base réalise la plupart
* des fonctions du conseiller, telles que la communication des charges
* pour l'algorithme de pondération de Load Balancer. Elle réalise également
* des connexions et des fermetures de connexion et fournit des méthodes d'envoi et de
* réception qui sont utilisées par le conseiller. Le conseiller n'est
* 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 : en fonction d'une valeur définie dans le constructeur, la base
* du conseiller fournit la charge à l'algorithme de pondération à un intervalle donné.
* 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.
*
* ATTRIBUTION DU NOM
*
* La convention d'attribution de nom est la suivante :
*
* - Le fichier doit se trouver dans le répertoire Load Balancer suivant :
*
* lb/servers/lib/CustomAdvisors/ (lb\servers\lib\CustomAdvisors sous Windows)
*
* - Le nom du conseiller doit être précédé de "ADV_". Il ne peut
* cependant qu'être lancé à partir du nom. Par exemple, le
* conseiller peut être lancé avec "modèle".
*
* - Le nom du conseiller doit être en minuscules.
*
* En respectant ces règles, le chemin et le nom du conseiller
* donné en exemple sont les suivants :
*
* <répertoire de base>/lib/CustomAdvisors/ADV_sample.class
*
*
* Tous les éléments Load Balancer (conseillers compris), doivent être compilés
* avec une version prédéfinie de Java. Afin d'assurer l'accès aux classes Load Balancer,
* vérifiez que le fichier ibmlb.jar (situé dans le sous-répertoire lib du répertoire
* de base) figure dans la classe d'environnement CLASSPATH du système.
*
* Méthodes fournies par ADV_Base :
*
* - ADV_Base (Constructeur) :
*
* - Paramètres
* - String sName = Nom du conseiller
* - String sVersion = Version du conseiller
* - int iDefaultPort = Numéro de port par défaut utilisé par le conseiller
* - int iInterval = Intervalle que doivent utiliser les serveurs
* - String sDefaultName = Non utilisé. indiquer "".
* - boolean replace = True - remplacement de la valeur de la charge
* par la base du conseiller
* False - ajout à la valeur de la charge calculée
* par la base du conseiller
* - Return
* - Les constructeurs n'ont pas de valeurs de retour.
*
* la base de conseiller étant basée sur une arborescence,
* le conseiller a de nombreuses autres méthodes
* d'utilisation à sa disposition. Ces méthodes peuvent
* être référencées en utilisant le paramètre CALLER dans
* getLoad().
*
* Ces méthodes sont les suivantes :
*
* - send - Envoie un paquet de données concernant la connexion
* socket établie sur le port spécifié du serveur.
* - Paramètres
* - String sDataString - Les données à envoyer se présentent sous forme de chaîne
* - Return
* - int RC - Indique si les données ont été correctement envoyées ;
* un zéro indique que les données ont été envoyées ; un
* entier négatif indique une erreur.
*
* - receive - Reçoit des informations de la connexion socket.
* - Paramètres
* - StringBuffer sbDataBuffer - Données reçues pendant l'appel
* - Return
* - int RC - Indique si les données ont été correctement
* reçues ; un zéro indique que les données ont été
* envoyées ; un entier négatif indique une
* erreur.
*
* Si la fonction fournie par la base du conseiller n'est pas
* suffisante, vous pouvez créer la fonction appropriée dans le
* conseiller et les méthodes fournies par la base du conseiller sont ignorées.
*
* Il est essentiel de savoir si la charge renvoyée doit être
* appliquée à la charge générée dans la base du conseiller,
* ou être remplacée (les deux cas sont possibles).
*
* Cet exemple concerne principalement le conseiller HTTP de Load Balancer.
* Il fonctionne très simplement : une demande d'envoi (demande http
* principale) est émise. Dès que la réponse est reçue, la méthode getLoad
* se termine, indiquant à la base du conseiller d'arrêter de chronométrer.
* La méthode est alors terminée. Les informations renvoyées ne sont pas
* analysées, la charge est fonction du temps nécessaire pour effectuer
* les opérations d'envoi et de réception.
*/
package CustomAdvisors;
import com.ibm.internet.nd.advisors.*;
public class ADV_sample extends ADV_Base implements ADV_MethodInterface
{
String COPYRIGHT =
"(C) Copyright IBM Corporation 1997, Tous droits réservés.\n";
static final String ADV_NAME = "Type";
static final int ADV_DEF_ADV_ON_PORT = 80;
static final int ADV_DEF_INTERVAL = 7;
// Remarque : La plupart des protocoles de serveur
// requièrent un retour chariot ("\r") et un passage à
// la ligne ("\n") à la fin des messages. Si tel est le
// cas, incluez-les dans la chaîne ci-dessous.
static final String ADV_SEND_REQUEST =
"HEAD / HTTP/1.0\r\nAccept: */*\r\nUser-Agent: " +
"IBM_Load_Balancer_HTTP_Advisor\r\n\r\n";
/**
* Constructeur.
*
* Paramètres : aucun, mais le constructeur de ADV_Base
* comporte plusieurs paramètres qui doivent lui être transmis.
*
*/
public ADV_type()
{
super( ADV_NAME,
"2.0.0.0-03.27.98",
ADV_DEF_ADV_ON_PORT,
ADV_DEF_INTERVAL,
"", // not used
false);
super.setAdvisor( this );
}
/**
* ADV_AdvisorInitialize
*
* Toute initialisation spécifique au conseiller devant être mise
* en oeuvre une fois la base du conseiller démarrée.
* Cette méthode n'est appelée qu'une seule fois et n'est généralement
* pas utilisée.
*/
public void ADV_AdvisorInitialize()
{
return;
}
/**
* getLoad()
*
* Cette méthode est appelée par la base du conseiller pour terminer
* l'opération du conseillée, basée sur des détails propres au protocole.
* Dans cet exemple de conseiller, une seule opération d'envoi
* et de réception est nécessaire ; si une logique plus
* complexe est nécessaire, il est possible d'émettre des envois
* et réceptions multiples. Par exemple, une réponse peut être
* reçue et sa syntaxe peut être analysée. Sur la base
* des informations obtenues, un autre ordre d'envoi et de
* réception peut alors être émis.
*
* Paramètres :
*
* - iConnectTime - la charge actuelle car elle fait référence au temps
* nécessaire à l'établissement d'une connexion
* avec le serveur sur le port spécifié.
*
*
* - caller - Une référence à la classe de la base du conseiller
* dans laquelle les méthodes fournies par Load
* Balancer doivent répondre à de simples demandes
* TCP, principalement des demandes d'envoi et de
* réception.
*
* Résultats :
*
* - La charge - Valeur exprimée en millisecondes, pouvant être
* ajoutée à la charge existante, ou la remplacer, suivant la
* valeur de l'indicateur "replace" du constructeur.
*
* Plus la charge est importante, plus le serveur met de temps
* à répondre et donc plus la charge de Load BalancLoad Balance diminue.
*
* Si la valeur est négative, il s'agit d'une erreur. Une erreur
* du conseiller indique que le serveur auquel le conseiller tente
* d'accéder n'est pas accessible et qu'une défaillance a été
* identifiée. Load Balancer ne tente pas d'équilibrer un serveur
* à la réception d'une valeur positive.
*
*/
public int getLoad(int iConnectTime, ADV_Thread caller)
{
int iRc;
int iLoad = ADV_HOST_INACCESSIBLE; // -1
// Send tcp request
iRc = caller.send(ADV_SEND_REQUEST);
if (iRc >= 0)
{
// Réception
StringBuffer sbReceiveData = new StringBuffer("");
iRc = caller.receive(sbReceiveData);
/**
* En mode conseiller normal (l'indicateur "replace" a la valeur false),
* la valeur renvoyée est 0 ou 1 selon l'activité/inactivité du serveur.
* En cas de bonne réception, une charge de zéro est renvoyée pour
* indiquer que la charge élaborée dans la base du conseiller n'est pas utilisée.
*
* Sinon (l'indicateur "replace" a la valeur true), renvoie la valeur de charge souhaitée.
*/
if (iRc >= 0)
{
iLoad = 0;
}
}
return iLoad;
}
} // End - ADV_type
La présente annexe décrit la manière de définir une configuration haute disponibilité à deux niveaux, regroupant les capacités de deux composants Load Balancer (Dispatcher et CBR) et Caching Proxy.
La configuration du serveur pour la figure 46 est la suivante :
La Figure 46 représente un équilibrage de charge de plusieurs serveurs (EdgeServer1, EdgeServer2, EdgeServer3) sur différents serveurs Web d'arrière-plan. Le composant CBR utilise Caching Proxy pour acheminer les demandes vers les serveurs Web d'arrière-plan en fonction de l'URL. Le composant Dispatcher permet d'équilibrer la charge des composants CBR sur les serveurs EdgeServer. La fonction haute disponibilité de Dispatcher permet d'assurer l'acheminement des demandes vers les serveurs dorsaux même en cas de défaillance de la machine haute disponibilité principale (EdgeServer1).
Instructions de configuration de base :
Caching ON CacheMemory 128000 K ReversePass /* http://websrvA.company.com/* http://www.company.com/*
Fichiers de configuration :
Les exemples de fichiers de configuration suivants sont identiques à ceux créés lors de la définition de la configuration de Edge Components comme illustré dans la Figure 46. Ils correspondent aux fichiers des composants Dispatcher et CBR de Load Balancer. Dans ces fichiers, une seule carte de réseau Ethernet est utilisée pour chaque machine EdgeServer et toutes les adresses sont représentées dans un sous-réseau privé. Les fichiers de configuration exemple utilisent les adresses IP suivantes pour les machines spécifiées :
Fichier de configuration exemple du composant Dispatcher d'un serveur EdgeServer haute disponibilité principal :
dscontrol executor start dscontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 dscontrol port add 192.168.1.11:80 dscontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 dscontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 dscontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 dscontrol manager start manager.log 10004 dscontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 dscontrol highavailability backup add primary auto 4567
Fichier de configuration exemple du composant CBR des serveurs EdgeServer :
cbrcontrol set loglevel 1 cbrcontrol executor start cbrcontrol cluster add 192.168.1.11 cbrcontrol port add 192.168.1.11:80 cbrcontrol server add 192.168.1.11:80:webserverA address 192.168.1.71 cbrcontrol server add 192.168.1.11:80:webserverB address 192.168.1.72 cbrcontrol server add 192.168.1.11:80:webserverC address 192.168.1.73 cbrcontrol rule add 192.168.1.11:80:webA_rule type content pattern (URI=*WSA*)|(URI=*wsA*) priority 21 cbrcontrol rule useserver 192.168.1.11:80:webA_rule webserverA cbrcontrol rule add 192.168.1.11:80:webB_rule type content pattern (URI=/WS_B*) priority 22 cbrcontrol rule useserver 192.168.1.11:80:webB_rule webserverB cbrcontrol rule add 192.168.1.11:80:webC_rule type content pattern URI=*webC* priority 23 cbrcontrol rule useserver 192.168.1.21:80:webC_rule webserverC
Le présent document peut contenir des informations ou des références concernant certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus de détails, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial IBM. Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateur d'évaluer et de vérifier lui-même les installations et applications réalisées avec des produits, logiciels ou services non expressément référencés par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant
les produits mentionnés dans le présent document. La remise de ce document ne vous donne
aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez recevoir des informations
concernant l'acquisition de licences, veuillez en faire la demande
par écrit à l'adresse suivante :
IBM Director of
Licensing
IBM corporation
500 Columbus Avenue
Thornwood, NY 10594
U.S.A.
Les informations sur les licences concernant les produits
utilisant un jeu de caractères double octet peuvent être obtenues par
écrit à l'adresse suivante :
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun pays dans lequel il serait contraire aux lois locales.
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT. IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE VALEUR MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Il est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut, à tout moment et sans préavis, modifier les produits et logiciels décrits dans ce document.
Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils contiennent. Les éléments figurant sur ces sites Web ne font pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule responsabilité.
IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de sa part, tout ou partie des informations qui lui seront fournies.
Les licenciés souhaitant obtenir des informations permettant :
(i) l'échange des données entre des logiciels créés de façon
indépendante et d'autres logiciels (dont celui-ci), et (ii)
l'utilisation mutuelle des données ainsi échangées, doivent adresser
leur demande à :
IBM corporation
Attn.: G7IA./503.
P.O. Box 12195
3039 Cornwallis Rd.
Research Triangle Park, N.C. 27709-2195
U.S.A.
Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans le présent document et tous les éléments sous licence disponibles pour celui-ci sont fournis par IBM dans les conditions internationales d'utilisation des logiciels IBM ou autre contrat de clientèle IBM.
Les données de performance indiquées dans ce document ont été déterminées dans un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière significative selon l'environnement d'exploitation utilisé. Certaines mesures évaluées sur des systèmes en cours de développement ne sont pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont applicables à leur environnement d'exploitation.
Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.
Toute instruction relative aux intentions d'IBM pour ses opérations à venir est susceptible d'être modifiée ou annulée sans préavis, et doit être considérée uniquement comme un objectif.
Le présent document peut contenir des exemples de données et de rapports utilisés couramment dans l'environnement professionnel. Ces exemples mentionnent des noms fictifs de personnes, de sociétés, de marques ou de produits à des fins illustratives ou explicatives uniquement. Toute ressemblance avec des noms de personnes, de sociétés ou des données réelles serait purement fortuite.
Si vous visualisez ces informations en ligne, il se peut que les photographies et illustrations en couleur n'apparaissent pas à l'écran.
Les termes qui suivent sont des marques d'IBM Corporation aux Etats-Unis et/ou dans certains autres pays.
AFS
AIX
DFS
IBM
iSeries(TM)
NetView
OS/2
Redbooks(TM)
RS/6000(R)
SecureWay
ViaVoice
WebSphere
zSeries(R)
Java ainsi que tous les logos et toutes les marques incluant Java sont des marques de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
Microsoft, Windows, Windows NT et le logo Windows sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.
Intel(TM), Intel Inside (logos), MMX(TM) and Pentium(R) sont des marques d'Intel Corporation aux Etats-Unis et/ou dans certains autres pays.
UNIX est une marque enregistrée de The Open Group aux Etats-Unis et/ou dans certains autres pays.
Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres pays.
Les autres noms de sociétés, de produits et de services peuvent appartenir à des tiers.