Important |
---|
Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à l'Annexe E, Remarques. |
LE PRESENT DOCUMENT EST LIVRE "EN L'ETAT". IBM DECLINE TOUTE RESPONSABILITE, EXPRESSE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE QUALITE 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.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial.
Vous pouvez également consulter les serveurs Internet suivants :
Compagnie IBM France
(C) Copyright IBM France 2002. Tous droits réservés.
© Copyright International Business Machines Corporation 2002. All rights reserved.
Note to U.S. Government Users -- Documentation related to restricted rights -- Use, duplication or disclosure is subject to restrictions set forth in 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 a été traduit en France. Voici les principales différences et particularités dont vous devez tenir compte.
Illustrations
Les illustrations sont fournies à titre d'exemple. Certaines peuvent contenir des données propres à la France.
Terminologie
La terminologie des titres IBM peut différer d'un pays à
l'autre. Reportez-vous au tableau ci-dessous, au besoin.
IBM France | IBM Canada |
---|---|
ingénieur commercial | représentant |
agence commerciale | succursale |
ingénieur technico-commercial | informaticien |
inspecteur | technicien du matériel |
Claviers
Les lettres sont disposées différemment : le clavier français est de type AZERTY, et le clavier français-canadien de type QWERTY.
OS/2 et Windows - Paramètres canadiens
Au Canada, on utilise :
Nomenclature
Les touches présentées dans le tableau d'équivalence suivant sont libellées différemment selon qu'il s'agit du clavier de la France, du clavier du Canada ou du clavier des États-Unis. Reportez-vous à ce tableau pour faire correspondre les touches françaises figurant dans le présent document aux touches de votre clavier.
Brevets
Il est possible qu'IBM détienne des brevets ou qu'elle ait déposé des demandes de brevets portant sur certains sujets abordés dans ce document. Le fait qu'IBM vous fournisse le présent document ne signifie pas qu'elle vous accorde un permis d'utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos demandes de renseignements relatives aux permis d'utilisation au directeur général des relations commerciales d'IBM, 3600 Steeles Avenue East, Markham, Ontario, L3R 9Z7.
Assistance téléphonique
Si vous avez besoin d'assistance ou si vous voulez commander du matériel, des logiciels et des publications IBM, contactez IBM direct au 1 800 465-1234.
Le présent manuel explique comment installer, configurer, utiliser et dépanner IBM WebSphere Application Server Load Balancer pour AIX, Linux, Solaris et Windows 2000. Ce produit était connu sous le nom Edge Server Network Dispatcher, SecureWay Network Dispatcher, eNetwork Dispatcher et Interactive Network Dispatcher.
Remarque |
---|
Les captures d'écrans de cette brochure ne sont pas disponibles en français à la date d'impression. |
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'exploitationet les services Internet fournis. Aucune connaissance préalable de Load Balancer n'est requise.
Ce manuel n'assure pas le support des versions antérieurs de Load Balancer.
Visitez le site Web de l'InfoCenter Edge Components (ecinfocenter) pour obtenir des informations récentes sur l'utilisation de Load Balancer pour Edge Component afin d'optimiser les performances des serveurs. Ce site présente également des exemples et des scénarios de configuration.
Le site Web de l'InfoCenter Edge Components propose un lien vers la version courante du présent manuel aux formats HTML et PDF.
Pour obtenir les dernières mises à jour ainsi que des conseils sur Load Balancer, visitez la page Web d'assistance, puis cliquez sur Search for Load Balancer hints and tips. Vous pouvez accéder à ce site Web à partir de l'InfoCenter Edge Components.
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 :
Le 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 lesquelles 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 fonction CBR de 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.
Pour plus d'informations sur les composants Dispatcher, CBR, Site Selector, Cisco CSS Controller et Nortel Alteon Controller, reportez-vous à la section 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'échelle 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é. Certaines de ces méthodes permettent, par exemple, de 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 des demandes s'effectue à l'aveuglette, 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 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 serveur 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, reportez-vous à la section Haute disponibilité.
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 fonction CBR (content-based routing) pour HTTP (avec la règle de type de contenu) et HTTPS (avec l'affinité des ID de session).
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 (également appelée 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. Reportez-vous à la section Configuration de la haute disponibilité.
Lorsque vous utilisez une configuration à deux niveaux avec un poste Dispatcher répartissant la charge sur plusieurs serveurs dotés de CBR ou Site Selector, vous pouvez atteindre un niveau de haute disponibilité pour ces composants de Load Balancer.
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 de plus amples informations, reportez-vous à la section Haute disponibilité.
Load Balancer pour IBM WebSphere Application Server Version 5.0 contient un certain nombre de nouvelles fonctions. Les plus importantes sont présentées ci-après.
Cette fonction s'applique à tous les composants de Load Balancer.
Les nouvelles versions de Red Hat Linux et SuSE Linux sont supportées par cette version, ainsi que SuSE SLES Linux. Pour plus d'informations, reportez-vous à la section Configuration requise pour Red Hat Linux, SuSE Linux ou SuSE SLES Linux.
Cette fonction s'applique à tous les composants de Load Balancer.
Uniquement pour AIXrbl;5.1 et Solaris 8, le support a été étendu au mode 64 bits, en plus du mode noyau 32 bits. Pour plus d'informations, reportez-vous aux sections Configuration requise pour AIX et Configuration requise pour Solaris.
Cisco CSS Controller (appelé auparavant Consultant Cisco) est un composant de Load Balancer qui calcule les pondérations pour les serveurs dont la charge est équilibrée par le commutateur Cisco CSS. Le commutateur Cisco CSS est un matériel d'équilibrage des charges qui supporte SNMP. Le contrôleur améliore la fonction d'équilibrage des charges du serveur de Cisco CSS Switch en prêtant plus d'attention aux applications et au système.
Pour plus d'informations, reportez-vous aux Configuration de démarrage rapide, Planification du composant Cisco CSS Controller et Configuration du composant Cisco CSS Controller.
Cette fonction représente un nouveau composant de Load Balancer.
Nortel Alteon Controller calcule les pondérations pour les serveurs dont la charge est équilibrée par un commutateur Nortel Alteon Web Switch. Le commutateur Nortel Alteon Web Switch est un matériel d'équilibrage des charges doté d'une interface SNMP pour l'extraction des informations de connexion et l'établissement des pondérations. Nortel Alteon Controller est un nouveau composant de Load Balancer qui contrôle les serveurs dont la charge est équilibrée par le commutateur Alteon et qui fournit des pondérations adéquates pour assurer un équilibrage de charge approprié. Le contrôleur améliore la fonction d'équilibrage des charges du serveur de Nortel Alteon Switch en prêtant plus d'attention aux applications et au système.
Pour plus d'informations, reportez-vous aux Configuration de démarrage rapide, Planification du composant Nortel Alteon Controller et Configuration du composant Nortel Alteon Controller.
Cette fonction s'applique aux composants Cisco CSS Controller et Nortel Alteon Controller.
Load Balancer prend maintenant en charge la haute disponibilité à la fois pour le composant Cisco CSS Controller et pour le composant Nortel Alteon Controller. Le client peut désormais installer Cisco CSS Controller sur un serveur de secours pour assurer le relais en cas de défaillance du serveur principal.
Pour plus d'informations sur Cisco CSS Controller, reportez-vous à la section Haute disponibilité.
Pour plus d'informations sur Nortel Alteon Controller, reportez-vous à la section Haute disponibilité.
Cette fonction s'applique au composant CBR.
CBR prend désormais en charge l'équilibrage de la charge des demandes d'application Web aux serveurs WAS (version 5) à l'aide de la forme d'affinité WAS. CBR offre la capacité de mapper automatiquement le fichier de configuration du module d'extension HTTP WAS sur un fichier de configuration CBR afin d'effectuer l'équilibrage de la charge de vos configurations WAS.
Pour plus d'informations, reportez-vous à la section Equilibrage de la charge de WebSphere Application Servers (WAS).
Cette fonction s'applique aux composants Dispatcher et CBR.
L'amélioration de la règle de connexions par seconde permet au client d'indiquer l'option "upserversonrule". Grâce à cette option, les serveurs restants ne seront pas surchargés si l'un ou plusieurs d'entre eux s'arrêtent.
Pour de plus amples informations, reportez-vous à la section Utilisation de règles basées sur le nombre de connexions par seconde.
Cette fonction s'applique au composant CBR.
La précédente implémentation de l'affinité de cookie actif CBR établissait les connexions client à un serveur sur la grappe et le port de la demande. Ceci peut devenir problématique dans les configurations dotées de plusieurs règles avec différents ensembles de serveurs. L'amélioration autorise plusieurs affinités dans une seule grappe et un seul port, permettant à un client de maintenir l'affinité avec potentiellement plusieurs serveurs différents en fonction du contexte de la demande.
Pour plus d'informations, reportez-vous à la section Affinité de cookie actif.
Cette fonction s'applique au composant Dispatcher.
Load Balancer fournit désormais un support SNMP pour les plateformes Linux. Pour de plus amples informations, reportez-vous à la section Commandes et protocole SNMP.
Cette fonction s'applique à tous les composants de Load Balancer.
Outre l'administration RMI, Load Balancer prend désormais en charge l'administration à distance basée sur le Web. L'administration basée sur le Web une administration à distance sécurisée et authentifiée de Load Balancer, même en présence d'un pare-feu. Pour plus d'informations, reportez-vous à la section Administration basée sur le Web.
Cette fonction s'applique à tous les composants de Load Balancer.
Une ligne de commande, permettant l'envoi de commande, est désormais accessible à partir du noeud Hôte dans l'arborescence de l'interface graphique. Pour plus d'informations, reportez-vous à la page ***.
Cette fonction s'applique au composant Dispatcher.
Lors de l'identification des incidents dans Load Balancer, l'outil lbpd permet de collecter facilement et rapidement des informations que le client peut envoyer aux Services IBM. Pour plus d'informations, reportez-vous à la section Collecte des informations de résolution des incidents.
Cette fonction s'applique aux composants Dispatcher, CBR et Site Selector.
Outre le conseiller SSL "léger", Load Balancer fournit désormais un conseiller HTTPS "lourd". Le conseiller HTTPS ouvre des connexions SSL complètes qui établissent une connexion SSL complète avec le serveur. (Par opposition, le conseiller SSL léger n'établit pas de connexion SSL complète avec le serveur.)
Pour plus d'informations sur le conseiller HTTPS, reportez-vous à la section Liste des conseillers.
Cette fonction s'applique à tous les composants de Load Balancer.
Load Balancer fournit désormais un conseiller LDAP qui veille au bon fonctionnement des serveurs LDAP.
Pour plus d'informations, reportez-vous à la section Liste des conseillers.
Cette fonction s'applique à tous les composants de Load Balancer.
Les conseillers peuvent désormais tenter d'établir de nouveau des connexions avant de décréter qu'un serveur est arrêté.
Pour plus d'informations, reportez-vous aux sections Tentative du conseiller et Tentative du conseiller.
Cette fonction s'applique au composant Dispatcher.
Dispatcher peut désormais envoyer une réinitialisation TCP à un serveur arrêté. Une réinitialisation A TCP provoque la fermeture immédiate de la connexion.
Pour plus d'informations, reportez-vous à la section Envoie d'une réinitialisation TCP à un serveur arrêté (composant Dispatcher uniquement).
Les fonctions suivantes ont été supprimées de Load Balancer :
Ce chapitre contient une présentation générale des composants de Load Balanceret comporte les sections suivantes :
Le 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 lesquelles 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 composant.
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 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 grappes. 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 au poste 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 des 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 un Dispatcher "local" (Dispatcher 1) sert de point d'entrée pour l'ensemble des demandes. Il distribue ces demandes entre ses propres serveurs locaux (Serveur A, Serveur B, Serveur C) et au serveur Dispatcher éloigné (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 éloigné (où se trouvent les serveurs D, E et F). Pour plus d'informations, reportez-vous aux sections 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, 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'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 au poste 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 éloignés.
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 au poste 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 à des algorithmes de reconnaissance sophistiqués 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, 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 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 Switch, notamment :
Nortel Alteon Controller utilise SNMP pour communiquer avec le commutateur. Les informations de configuration, d'état et de connexion sont extraites du commutateur. Une fois que 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 éloignée 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 pouvez déterminer lesquelles sont les mieux adaptées à la gestion de votre réseau :
Pour plus de détails sur Load Balancer, reportez-vous à la section Présentation générale de Load Balancer.
Pour optimiser l'équilibrage de la charge sur les serveurs et garantir le choix du serveur approprié, reportez-vous aux sections :
Dispatcher assure l'équilibrage de charge sur vos serveurs pour les protocoles HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet et toute application de type TCP ou UDP sans état.
_ Pour configurer Load Balancer à partir d'un autre poste que celui où réside ce composant, reportez-vous à la section Administration à distance de Load Balancer.
_ Pour exécuter Dispatcher sur le même poste qu'un serveur Web dont vous équilibrez la charge, reportez-vous à la section 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, reportez-vous aux sections 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, reportez-vous à la section 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, reportez-vous à la section Affinité trans ports.
_ Pour vous assurer que le client utilise le même serveur pour plusieurs connexions, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous à la section Configuration de l'équilibrage basé sur des règles.
_ Pour diriger les clients vers différents groupes de serveurs en fonction de l'adresse IP source du client, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous à la section Utilisation de règles basées sur l'heure.
_ Pour diriger les clients des serveurs en fonction des bits TOS (Type Of Service, type de service) des paquets réseau, reportez-vous à la section 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, reportez-vous à la section Utilisation de règles basées sur le nombre de connexions par seconde,
_ à l'aide du nombre total de connexions actives, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous à la section 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é"), reportez-vous à la section 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, reportez-vous à la section Substitution d'affinité de port.
Pour vous assurer que les clients HTTPS (SSL) reviennent au même serveur, sur la base de l'ID SSL de la demande client
_ Reportez-vous à la page ***.
Pour diriger les clients HTTP vers différents groupes de serveurs à l'aide de règles basées sur la correspondance avec le contenu de l'URL de la demande client, reportez-vous aux sections Fonction CBR de Dispatcher (méthode d'acheminement cbr) et Utilisation de règles basées sur le contenu des demandes.
_ Pour différencier deux URL et leurs applications de service, reportez-vous à la section 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, reportez-vous à la section 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), reportez-vous à la section Affinité d'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/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/déchiffrement pour effectuer un réel routage par contenu sur l'URL de la requête client.
_ Pour équilibrer la charge sur des serveurs éloignés à l'aide de la fonction de réseau étendu de Dispatcher, reportez-vous aux sections 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, reportez-vous à la section 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, reportez-vous à la section 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), reportez-vous à la section Utilisation d'une configuration réseau privée.
_ Pour combiner plusieurs adresses Web en une seule configuration, reportez-vous à la section Utilisation d'une grappe générique pour combiner les configurations serveurs.
_ Pour équilibrer la charge de pare-feu, reportez-vous à la section Utilisation de la grappe générique pour équilibrer la charge des pare-feux.
_ Pour acheminer le trafic de tous les ports de destination, reportez-vous à la section 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", reportez-vous à la section Détection d'attaque de refus de service.
_ Pour analyser le trafic du serveur, reportez-vous à la section 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, reportez-vous à la section 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 requêtes 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, reportez-vous à la section 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 la section 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 la section 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 la section 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'un autre poste que celui où réside ce composant, reportez-vous à la section Administration à distance de Load Balancer.
_ CBR peut s'exécuter sur le même poste qu'un serveur dont vous équilibrez la charge. Pour de plus amples informations, reportez-vous à Utilisation de serveurs implantés au même endroit.
_ Pour optimiser l'utilisation de la CPU en exécutant plusieurs processus Caching Proxy, reportez-vous à la section 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), reportez-vous à la section Equilibrage de charge sur les connexions sécurisées (SSL).
_ Par le biais de connexions sécurisées côté client à proxy uniquement, reportez-vous à la section Equilibrage de charge client-proxy dans SSL et proxy-serveur dans HTTP.
_ Pour différencier deux URL et leurs applications de service, reportez-vous à la section 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, reportez-vous à la section Configuration de l'équilibrage basé sur des règles.
_ Pour diriger les clients vers différents groupes de serveurs en fonction du contenu de l'URL demandée, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous à la section Utilisation de règles basées sur le nombre de connexions par seconde,
à l'aide du nombre total de connexions actives, reportez-vous à la section 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é"), reportez-vous à la section 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, reportez-vous à la section Substitution d'affinité de port.
_ Pour vous assurer qu'un client revient au même serveur pour plusieurs connexions, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous à la section 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), reportez-vous à la section Affinité d'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, reportez-vous à la section Haute disponibilité.
_ Pour analyser le trafic du serveur, reportez-vous à la section 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, reportez-vous à la section 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'un autre poste que celui où réside ce composant, reportez-vous à la section Administration à distance de Load Balancer.
_ Site Selector peut s'exécuter sur le même poste 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, reportez-vous à la section Haute disponibilité.
_ Pour vous assurer que le client utilise le même serveur pour plusieurs demandes de serveur de noms, reportez-vous à la section 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), reportez-vous à la section Considérations relatives à la durée de vie (TTL).
Pour diriger les requêtes des clients vers différents groupes de serveurs pour la résolution des noms de domaines, vous pouvez ajouter des "règles" à la configuration de Site Selector. Pour plus d'informations, voir Configuration de l'équilibrage basé sur des règles.
_ Pour diriger les clients vers différents groupes de serveurs en fonction de l'adresse IP source du client, reportez-vous à la section 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, reportez-vous à la section 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, reportez-vous aux sections :
_ Pour diriger le trafic excédentaire vers un ensemble de serveurs par défaut (par exemple, des serveurs qui répondront "site occupé"), reportez-vous à la section 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-vos à 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, reportez-vous à la section 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é, reportez-vous aux sections :
_ 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'un autre poste que celui où réside ce composant, reportez-vous à la section 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é, reportez-vous à la section Haute disponibilité.
_ Pour analyser le trafic du serveur, reportez-vous à la section 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, reportez-vous à la section 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é, reportez-vous aux sections :
_ 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'un autre poste que celui où réside ce composant, reportez-vous à la section 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 permet la configuration en secours automatique de deux contrôleurs.
Pour plus d'informations sur la fonction de haute disponibilité, reportez-vous à la section Haute disponibilité.
_ Pour analyser le trafic du serveur, reportez-vous à la section 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, reportez-vous à la section 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 les conditions matérielles et logicielles requises ainsi que l'installation de Load Balancer sous AIX, Linux, Solaris et Windows 2000. Pour les instructions d'installation de Load Balancer à l'aide d'outils de mise en forme système, reportez-vous, dans l'ordre, aux sections :
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.
Remarques :
Certaines applications situées sur la machine Load Balancer pouvant nécessiter d'autres versions de Java, il est impératif que les versions Java adéquates soient installées au moment de la mise à niveau. Pour vérifier que les composants Load Balancer utilisent la version correcte de Java lorsque plusieurs versions sont installées, procédez comme suit :
Modifiez les fichiers script pour chaque composant de Load Balancer à mettre à jour. Les fichiers script sont les suivants pour chaque composant :
Par exemple, sous Windows 2000, si Java 1.3 est installé dans C:\Program Files\IBM\Java13\jre\bin, modifiez comme suit les fichiers script.
IBM AIX 4.3.3.10 plus les correctifs apar (afin de prendre en charge Java 1.3). Pour obtenir une liste des correctifs apar AIX requis, reportez-vous au fichier README. Support du mode 32 bits uniquement.
Une version Java prise en charge vous est fournie sur le CD-ROM WebSphere Application Server Edge Component.
Le Tableau 1 répertorie les images installp de Load
Balancer.
Tableau 1. Images installp AIX
Administration (avec messages) | ibmlb.admin.rte ibmlb.msg.<langue>.admin |
Base | ibmlb.base.rte |
Pilote de périphérique | ibmlb.lb.driver |
Licence | ibmlb.lb.license |
Composants Load Balancer (avec messages) | ibmlb.<composant>.rte ibmlb.msg.<langue>.lb |
Documentation (avec messages) | ibmlb.doc.rte ibmlb.msg.<langue>.doc |
Système Metric Server | ibmlb.ms.rte |
Où <composant> est 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> est l'une des suivantes :
Si une version antérieure est déjà installée sur votre système, supprimez-la avant d'installer la version actuelle. 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, "ibmnd"). 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 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 la ligne 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
Reportez-vous au tableau suivant pour déterminer la ou les commandes à
entrer pour installer les composants Load Balancer pour
AIX :
Tableau 2. Commande AIX relatives à l'installation
Administration (avec messages) | installp -acXgd périphérique ibmlb.admin.rte ibmlb.msg.<langue>.admin |
Base | installp -acXgd périphérique ibmlb.base.rte |
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.<langue>.lb |
Système Metric Server | 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 unité
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.admin.rte ibmlb.base.rte ibmlb.doc.rte ibmlb.ms.rte ibmlb.msg.<langue>.admin.rte ibmlb.msg.<langue>.doc ibmlb.msg.<langue>.lb.rte ibmlb.lb.driver ibmlb.lb.license ibmlb.<composant>.rte
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, reportez-vous à la section RMI (Remote Method Invocation).
Tableau 3. Tableau de prise en charge des versions de noyau Linux
Système d'exploitation | Version(s) du noyau |
Red Hat Advanced Server 2.1 | 2.4.9-e.3, 2.4.9-e.3smp, 2.4.9-e.3enterprise |
SuSE 7.3 Professional | 2.4.10-4GB, 2.4.10-64GB-SMP, 2.4.16-4GB, 2.4.16-64GB-SMP |
SuSE 7.0 SLES | 2.4.7-4GB, 2.4.7-64GB |
Une version Java prise en charge vous est fournie sur le CD-ROM WebSphere Application Server Edge Component.
Load Balancer prend en charge les versions de noyau nommées dans le Tableau 3. En conséquence, si vous utilisez une noyau avec correctif, son nom doit correspondre à l'un de ceux du tableau. Vous pouvez également créer un lien symbolique au module du noyau Load Balancer à l'aide du nom symbolique "ibmnd". Pour créer un nom symbolique, entrez la commande suivante à partir de l'invite :
ln -s /opt/ibm/edge/lb/servers/bin/ibmnd-a.b.c-xy /opt/ibm/edge/lb/servers/bin/ibmnd
Par exemple, si vous utilisez le noyau RedHat 2.4.7-10 auquel vous appliquez le correctif ARP, il est possible que le nom du noyau devienne 2.4.7-10-arpfix après compilation et activation du nouveau noyau rectifié. La commande "uname -r" renverra donc alors "2.4.7-10-arpfix.." Auquel cas, le chargement du module du noyau Balancer échoue car le nom a changé. En revanche, si vous créez le nom symbolique ibmnd de liaison à ibmnd-2.4.7-10, le chargement du module du noyau 2.4.7-10 s'effectue même si les noms ne correspondent pas. Attention, si vous passez à une nouvelle version du noyau en oubliant la présence du lien symbolique, vous risquez d'avoir des erreurs d'exécution.
Pour plus d'informations, reportez-vous à la section Installation du correctif du noyau Linux (pour supprimer les réponses ARP sur l'interface de bouclage).
La présente section explique comment installer Load Balancer sur Red Hat Linux ou SuSE 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 version actuelle. Assurez-vous, tout d'abord, que tous les exécuteurs et serveurs sont arrêtés. Puis, pour procéder à la désinstallation de l'ensemble du produit, entrez rpm -e pkgname. Procédez à la désinstallation dans l'ordre inverse des procédures du module d'installation, en vous assurant que les modules 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 modules RPM qui peuvent être installés.
Où version est le nom de la version du module du noyau extrait du Tableau 3. Par exemple, l'une des versions de SuSE 7.0 SLES se nomme 2.4.7-64GB-SMP
Où composant est disp (pour le composant Dispatcher), cbr (pour le composant CBR), ss (pour le composant Site Selector), cco (pour Cisco CSS Controller), nal (pour Nortel Alteon Controller). Vous pouvez sélectionner les composants Load Balancer à installer.
La commande d'installation des modules doit être émise à partir du répertoire où sont situés les fichiers RPM. Tapez la commande suivante pour installer tous les modules : rpm -i package.rpm.
rpm -i --nodeps package.rpm
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, reportez-vous à la section RMI (Remote Method Invocation).
Pour Solaris 8, lorsque l'assistant d'installation Edge Components est utilisé, l'éditeur de liens doit être au niveau 109147-16 ou supérieur et ls bibliothèques partagées pour C++ au niveau 108434-8 ou supérieur.
Pour un fonctionnement totatement cohérent, téléchargez et appliquez les derniers correctifs Solaris de Sun Microsystems disponibles à http://sunsolve.sun.com.
Une version Java prise en charge vous est fournie sur le CD-ROM WebSphere Application Server Edge Component.
La présente section explique comment installer Load Balancer sur Solaris à partir du CD-ROM du produit.
Avant de commencer la procédure d'installation, soyez certain de disposer de droits d'accès root 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, entrez pkgrm nom_module.
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 module ; par exemple, pkgadd -d /cdrom/cdrom0/.
Vous obtenez une liste de modules à installer.
Pour installer tous les modules, entrez "all" et appuyez sur la touche Entrée. Pour installer uniquement certains composants, entrez le ou les noms correspondants aux modules à 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 modules 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.
Tous les modules dépendent du module commun, ibmlbadm. Ce module commun doit être installé avec chacun des autres modules.
Par exemple, pour n'installer que le composant Dispatcher, la documentation et le système Metric Server, installez : ibmdisp, ibmlblic, ibmlbbase, ibmlbadm, 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, reportez-vous à la section RMI (Remote Method Invocation).
Les composants Load Balancer se trouvent dans le répertoire d'installation /opt/ibm/edge/lb/servers.
Avant d'exécuter le programme InstallShield, vous devez télécharger le module installable Developer Kit ou le module installable Runtime Environment. (Pour consulter les informations relatives à l'exécution de plusieurs versions Java, reportez-vous à la remarque 3.)
Une version Java prise en charge vous est fournie sur le CD-ROM WebSphere Application Server Edge Component.
La présente section explique comment installer Load Balancer sous Windows 2000 à partir du CD-ROM du produit.
Une liste de modules à installer vous est proposée :
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, reportez-vous à la section RMI (Remote Method Invocation).
La version Windows 2000 de Load Balancer est prise en charge par les produits suivants :
Restrictions : La version Windows 2000 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és 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 version actuelle. 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 :
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
L'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, reportez-vous à la section 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. L'un des postes de travail sera utilisé comme répartiteur (Dispatcher) et les deux autres comme 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 de la grasse (adresse dont la charge sera équilibrée), que vous fournissez aux clients pour accéder à votre site Web.
Poste de travail | Nom | Adresse IP |
---|---|---|
1 | server1.intersplash.com | 9.47.47.101 |
2 | server2.intersplash.com | 9.47.47.102 |
3 | server3.intersplash.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.
Nom= www.Intersplash.com IP=9.47.47.104
Ajoutez un alias pour www.Intersplash.com à l'interface de bouclage de server2.intersplash.com et server3.intersplash.com.
ifconfig lo0 alias www.Intersplash.com netmask 255.255.255.0
ifconfig lo0:1 www.Intersplash.com 127.0.0.1 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 la ligne de commande, de l'assistant de configuration ou de l'interface graphique.
Si vous utilisez la ligne de commande, suivez la procédure ci-dessous.
dscontrol executor start
dscontrol cluster add www.Intersplash.com
dscontrol port add www.Intersplash.com:80
dscontrol server add www.Intersplash.com:80:server2.intersplash.com
dscontrol server add www.Intersplash.com:80:server3.intersplash.com
dscontrol executor configure www.Intersplash.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, reportez-vous aux sections Interface graphique et Annexe A, Interface graphique utilisateur : Instructions générales.
Pour plus d'informations sur l'utilisation de l'assistant de configuration, reportez-vous à la section 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'une seule grappe de serveurs. Pour chaque serveur, configurez un port par l'intermédiaire duquel Load Balancer communique. Reportez-vous à la Figure 9.
Figure 9. Exemple de composant Dispatcher configuré avec une grappe et 2 ports
Dans cet exemple de composant Dispatcher, une grappe est définie sur www.productworks.com. Elle 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 dernier cas, il est souhaitable de définir une grappe pour chaque protocole, avec un seul port mais plusieurs serveurs, comme illustré à la Figure 10.
Figure 10. Exemple de composant Dispatcher configuré avec deux grappes, chacune associée à un port
Dans cet exemple de composant Dispatcher, deux grappes sont définies : 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 une grappe 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 11. Exemple de composant Dispatcher configuré avec 2 grappes, chacune associée à 2 ports
Dans cet exemple de composant Dispatcher, deux grappes sont définies 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.
Il contient les sections suivantes :
Conditions requises par la plate-forme :
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 qui indique l'état des serveurs DB2 et le conseiller Ping qui indique si le serveur répond à une commande ping. Pour connaître la liste complète des conseillers, reportez-vous à la section Liste des conseillers.
Vous avez également la possibilité de développer vos propres conseillers (reportez-vous à la section 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 retournent 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 grappe: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 de plus amples informations, reportez-vous à la section dscontrol port -- Configuration des ports.
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 :
Pour implémenter NAT/NAPT, procédez aux opérations ci-dessous (reportez-vous également à la section Etapes de configuration des méthodes d'acheminement nat ou cbr de Dispatcher):
dscontrol server add grappe: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 machine Dispatcher. 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 machine Dispatcher au lieu d'envoyer le paquet 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. L'adresse de retour ne peut pas être identique à l'adresse de grappe, de serveur ou NFA.
Adresse du routeur vers le serveur éloigné. S'il s'agit d'un serveur lié localement, entrez l'adresse du serveur.
Le composant Dispatcher permet d'exécuter la fonction fonction CBR (content-based routing) 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 CBR (content-based routing) plus rapide que le composant CBR qui nécessite le module Caching Proxy.
Pour HTTP : La sélection du serveur, pour fonction 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.
Pour implémenter fonction CBR de Dispatcher, procédez aux opérations ci-dessous (reportez-vous également à la section Etapes de configuration des méthodes d'acheminement nat ou cbr de Dispatcher):
dscontrol server add grappe:port:serveur mapport valeur returnaddress adresseretour router adresseretour
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern motif
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, reportez-vous à la section Utilisation de règles basées sur le contenu des demandes. Pour plus d'informations sur les expressions valides de masque, reportez-vous à 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
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 3. Définition de l'adresse de grappe dscontrol cluster add 1.2.3.44 4. Configuration de l'adresse de grappe 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) dscontrol executor configure 10.10.10.99 ou à l'aide de la commande ifconfig/dsconfig : sous AIX : ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0 sous Linux : ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up sous Solaris 7 : ifconfig hme0:1 10.10.10.99 netmask 255.255.255.0 up sous Solaris 8 : ifconfig hme0 addif 10.10.10.99 netmask 255.255.255.0 up sous Windows : dsconfig en0 alias 10.10.10.99 netmask 255.255.255.0 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. Router (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. L'adresse du routeur est celle configurée 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 une grappe 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 configurez 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 configurez le serveur trois fois (c.-à-d. 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ètres advisorrequest, reportez-vous à la section Configuration du conseiller HTTP à l'aide de l'option de demande/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 grappe:port:serveur. Le serveur peut être une adresse IP unique de la machine (serveur physique) sous la forme d'un nom symbolique ou au format décimal à point. Ou, si vous configurez 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, reportez-vous à la section 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 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 être sur le même sous-réseau.
Pour plus d'informations sur la fonction de haute disponibilité, reportez-vous à la section 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 grappe. Chaque grappe peut être configurée avec l'adresse de non-acheminement (NFA) de sa machine principale. La machine du Dispatcher principal effectue normalement l'équilibrage de charge pour cette grappe. En cas de panne, l'autre machine assume l'équilibrage de charge pour sa propre grappe et pour la grappe du dispatcher qui est en panne.
La Figure 14 illustre une configuration de haute disponibilité réciproque avec "grappe partagée A" et "grappe partagée B,". Chaque répartiteur peut acheminer activement des paquets pour sa grappe principale. Si l'un des répartiteurs venait à échouer et ne pouvait plus activement acheminer les paquets pour sa grappe principale, l'autre répartiteur pourrait le remplacer et acheminerait les paquets pour sa grappe de sauvegarde.
Pour plus d'informations sur la fonction de haute disponibilité, reportez-vous à la section Haute disponibilité.
Avant d'effectuer les opérations décrites dans le présent chapitre, reportez-vous à la section Planification du composant Dispatcher. Ce chapitre décrit comment créer une configuration de base pour le composant Dispatcher de Load Balancer.
Tableau 4. Tâches de configuration pour la fonction Dispatcher
Tâche | Description | Informations connexes |
---|---|---|
Configuration de la machine Dispatcher. |
Définition de la configuration pour 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 la plus directe pour la configuration de Dispatcher. Les valeurs des paramètres de commande doivent être saisies en 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 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 dscontrol he f au lieu de dscontrol help file.
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, entrez exit ou quit.
Les commandes permettant de configurer Dispatcher peuvent être entrées dans un fichier script de configuration, puis exécutées ensemble. Reportez-vous à la section 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 ex. scriptsauvegarde), exécutez la commande suivante :
dscontrol file save scriptsauvegarde
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, reportez-vous à la Figure 41.
Pour démarrer l'interface graphique, procédez comme suit :
dsserver
Pour pouvoir 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 grappes 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 une grappe à l'aide de la ligne de commande, vous devez entrer la commande dscontrol cluster add grappe. Pour définir une grappe à 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'une grappe à l'aide du bouton gauche de la souris. Entrez l'adresse de la grappe 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 de détails, reportez-vous à la section RMI (Remote Method Invocation).
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, entrez 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.
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 de détails sur l'utilisation de l'interface graphique, reportez-vous à 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'une grappe pour permettre à Dispatcher d'équilibrer le trafic dans un groupe de serveurs.
L'installation de la machine Dispatcher ne peut être effectuée que par le superutilisateur (pour AIX, Linux ou Solaris) ou l'administrateur pour Windows 2000.
AIX, Linux et Solaris uniquement : Load Balancer peut avoir un serveur co-implanté . Cela signifie simplement que Load Balancer peut être implanté physiquement sur le serveur dont il assure l'équilibrage de charge.
La machine Dispatcher requiert au moins deux 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 via 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 grappe 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 de la grappe en question. Dispatcher assure l'équilibrage de charge pour cette adresse.
Solaris uniquement :
Par exemple, pour utiliser deux cartes Ethernet 100 Mo/s, le fichier ibmnd.conf doit comporter une seule ligne indiquant l'unité hme. Pour utiliser une carte Ethernet 10 Mo/s, le fichier ibmnd.conf doit comporter deux lignes, l'une indiquant la carte le et l'autre la carte hme.
Le fichier ibmnd.conf fournit des données à la commande Solaris autopush et doit être compatible avec cette dernière.
Par exemple, si les grappes X et Y sont configurées pour être utilisées par le composant CBR sur les cartes répertoriées dans le fichier ibmnd.conf, elles sont déconfigurées lors du démarrage des commandes dscontrol executor start ou dscontrol executor stop. Ce résultat n'est peut-être pas souhaité. Lorsque les grappes X et Y sont configurées dans le script goAliases, elles sont automatiquement reconfigurées une fois Dispatcher Executor lancé ou arrêté.
Windows 2000 uniquement : Assurez-vous que la transmission Internet n'est pas activée pour le protocole TCP/IP. (Voir la configuration TCP/IP sous Windows 2000.)
La Figure 15 montre un exemple de Dispatcher configuré avec une seule grappe, 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, reportez-vous au Guide des commandes Dispatcher et CBR.
Pour plus d'informations sur le fichier de configuration type, reportez-vous à la section Exemples de fichiers de configuration Load Balancer.
AIX, Linux et Solaris : Pour démarrer la fonction serveur, entrez dsserver.
Windows 2000 : 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. Reportez-vous au 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, entrez 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 en notation décimale à point.
Dispatcher équilibrera les demandes envoyées à l'adresse de la grappe entre les serveurs configurés sur les ports associés à cette grappe.
La grappe 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 une grappe générique. Pour définir une grappe, tapez la commande dscontrol cluster add. Pour définir les options de grappe, tapez la commande dscontrol cluster set ou utilisez l'interface graphique pour lancer des commandes. Les grappes génériques peuvent être utilisées pour remplacer plusieurs adresses IP afin de permettre l'équilibrage de charge pour les paquets entrants. Pour plus de détails, reportez-vous aux sections Utilisation d'une grappe générique pour combiner les configurations serveurs, Utilisation de la grappe générique pour équilibrer la charge des pare-feux et Utilisation de grappe générique avec Caching Proxy pour le proxy transparent.
Une fois que la grappe est définie, 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_grappe. Cette commande recherche une carte avec une adresse existante et appartenant au même sous-réseau que l'adresse de la grappe. La commande de configuration de la carte système est ensuite lancée pour l'adresse de la grappe en utilisant la carte trouvée et le masque de réseau de l'adresse existante figurant sur cette carte. Par exemple :
dscontrol executor configure 204.67.172.72
Vous pouvez configurer des adresses de grappes ajoutées à un serveur en attente en mode haute disponibilité ou des adresses de grappes ajoutées à un répartiteur de réseau étendu jouant le rôle de serveur éloigné. 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 goldle, reportez-vous à la section 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 configureadresse_grappe nom_interface sous-masque.
Exemple :
dscontrol executor configure 204.67.172.72 en0 255.255.0.0 (AIX) dscontrol executor configure 204.67.172.72 eth0:1 255.255.0.0 (Linux) dscontrol executor configure 204.67.172.72 le0:1 255.255.0.0 (Solaris 7) dscontrol executor configure 204.67.172.72 le0 255.255.0.0 (Solaris 8) dscontrol executor configure 204.67.172.72 en1 255.255.0.0 (Windows 2000)
Pour vous servir de l'autre forme de la commande de configuration de l'exécuteur sous Windows 2000, vous devez déterminer le nom de l'interface à utiliser.
Si votre machine comporte une seule carte Ethernet, l'interface portera le nom en1. De même, si vous ne disposez que d'une seule carte en anneau à jeton (Token Ring), l'interface portera le nom tr1. 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 :
Les cartes d'interface réseau supportées apparaissent à l'écran. Cliquez sur chaque entrée de la liste pour déterminer s'il s'agit d'une interface Ethernet ou Token Ring (anneau à jeton). Le type d'interface est répertorié dans la colonne Description. Les noms attribués par dsconfig correspondent aux types d'interface. Par exemple, la commande dsconfig affecte la première interface Ethernet de la liste à en0, la deuxième à en1, et ainsi de suite ; la première interface en anneau à jeton (Token Ring) est affectée à tr0, la deuxième à tr1, et ainsi de suite.
Après avoir accédé à ces informations de mappage, vous pouvez créer un alias reliant l'interface réseau à l'adresse de la grappe.
La commande de configuration de l'exécuteur exécute principalement des commandes ifconfig (ou dsconfig sous Windows 2000). Vous pouvez donc continuer d'utiliser les commandes ifconfig (dsconfig) si vous le souhaitez.
La commande dsconfig est fournie avec le composant Dispatcher et permet de configurer les alias de grappes à partir de la ligne de commande. Cette commande a la même syntaxe que la commande UNIX ifconfig.
dsconfig en0 alias 204.67.172.72 netmask 255.255.0.0
Pour déterminer le nom de l'interface, utilisez la même technique que pour la seconde forme de la commande de configuration de l'exécuteur.
Lorsque vous utilisez des applications serveur 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 <grappe> <adresse MAC Load Balancer> pub
Pour définir un port, entrez la commande dscontrol port add grappe:port, éditez le fichier de configuration type ou utilisez l'interface graphique. La valeur de grappe peut être le nom symbolique ou l'adresse en notation décimale à point. 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. Reportez-vous au 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 la grappe. Le port générique sera utilisé pour configurer des règles et des serveurs pour n'importe quel port. Vous pouvez également utiliser cette fonction en cas de configuration serveur/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, reportez-vous à la section Utilisation du port générique pour acheminer le trafic destiné à un port non configuré.
Pour définir un serveur avec équilibrage de charge, tapez la commande dscontrol server add grappe:port:serveur, éditez le fichier de configuration type ou utilisez l'interface graphique. grappe et serveur peuvent correspondre à des noms symboliques ou à des adresses en notation décimale à point. 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'une grappe.
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 de la grappe. Etant donné que Dispatcher réachemine les paquets sans modifier l'adresse IP de destination, lorsque ceux-ci arrivent, l'adresse de grappe qu'ils contiennent indique la destination. Si un serveur a été configuré pour être lié à une adresse IP autre que l'adresse de grappe, il ne pourra pas accepter les paquets/demandes destinés à la grappe.
Co-implantation d'adresses multiples : 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, reportez-vous à la section Utilisation de serveurs implantés au même endroit.
Pour plus d'informations sur la syntaxe de la commande dscontrol server, reportez-vous à la section dscontrol server -- Configuration des serveurs.
La fonction gestionnaire permet d'améliorer l'équilibrage de charge. Pour démarrer le gestionnaire, entrez 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é des serveur bénéficiant de l'équilibrage de charge à répondre aux demandes. 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 correspondants, reportez-vous au Guide des commandes Dispatcher et CBR. Pour lire la description de chaque conseiller, reportez-vous à la section 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 de la grappe, entrez la commande dscontrol cluster set grappe proportions. Pour plus d'informations, reportez-vous à la section Proportion de l'importance accordée aux données d'état.
Si le serveur est co-implanté (Dispatcher est installé sur la machine dont il assure l'équilibrage de charge) ou si vous utilisez la méthode de réacheminement nat ou cbr, n'appliquez pas les procédures suivantes.
Si vous utilisez la méthode de réacheminement mac, Dispatcher travaillera uniquement avec des serveurs périphériques permettant de configurer l'adaptateur de bouclage avec une adresse IP supplémentaire. C'est pourquoi le serveur périphérique 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 grappe. 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 grappe comme alias, les serveurs avec équilibrage de charge accepteront les paquets envoyés à cette adresse de grappe.
Si votre système d'exploitation supporte l'attribution d'alias aux interfaces réseau (telles que AIX, Linux, Solaris, ou Windows 2000), vous devez affecter l'adresse de grappe comme alias à l'unité de bouclage. L'utilisation d'un système d'exploitation supportant les alias à pour avantage de permettre la configuration de serveurs avec équilibrage de charge desservant plusieurs adresses de grappe .
Pour les noyaux Linux version 2.2.14 ou suivante, émettez les commandes ci-après avant la commande ifconfig :
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden echo 1 > /proc/sys/net/ipv4/conf/all/hidden
Si le système d'exploitation de votre serveur ne supporte pas les alias, vous devez définir l'adresse de grappe 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 5.
Tableau 5. 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
netstat -nr
Exemple pour Windows 2000 :
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 6.
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 6. Commandes de suppression d'une route supplémentaire pour Dispatcher
Suivant 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 périphérique, effectuez les étapes suivantes à partir d'une autre machine du même sous-réseau lorsque Load Balancer n'est pas être en cours d'exécution et la grappe non configurée.
arp -d grappe
ping grappe
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 de la grappe à l'interface à l'aide de la commande ifconfig. Vérifiez qu'aucune machine n'a une entrée ARP publiée pour l'adresse de la grappe.
Pour les versions 2.2.14 et suivantes du noyau Linux, vérifiez que "1" est contenu dans /proc/sys/net/ipv4/conf/lo/hidden et /proc/sys/net/ipv4/conf/all/hidden.
arp -a
La sortie de la commande doit contenir l'adresse MAC de votre serveur. Emettez la commande :
arp -s grappe adresse_mac_serveur
arp -d grappe
Pour Linux exclusivement, un correctif spécifique (dépendant de la version du noyau Linux concernée) est parfois requis pour permettre l'affectation d'un alias à l'unité de bouclage.
Le correctif permet de s'assurer que les réponses ARP (Address Resolution Protocol) ne sont envoyées qu'à partir d'un port de carte réseau dont l'adresse IP est demandée dans la requête ARP. Sans ce correctif, Linux émet les réponses ARP sur le réseau pour les alias du dispositif de bouclage. Le correctif corrige également les conditions d'indétermination ARP qui se produisent lorsque plusieurs ports de carte réseau associés à des adresses IP différentes se trouvent sur le même réseau physique.
Les conditions d'installation du correctif sont les suivantes :
Les instructions concernant la compilation et les correctifs du noyau Linux sont disponibles sur le site suivant : http://www.tldp.org/HOWTO/Kernel-HOWTO.html.
Pour appliquer des correctifs kernel 2.4.4 (ou supérieur), procurez-vous le correctif de bouclage sur le site suivant http://www.linuxvirtualserver.org/~julian#hidden.
Load Balancer ne supportant que les noms de version de noyau répertoriés dans le Tableau 3, le nom du correctif du noyau compilé doit correspondre à l'un des noms répertoriés dans ce tableau. Pour plus d'informations sur les correctifs de noyau Linux, reportez-vous à la section Noms des versions de noyau Linux prises en charge.
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 sera utilisé comme répartiteur (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, reportez-vous à la section 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 la ligne 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 la ligne 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.monsiteweb.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, reportez-vous à l'Annexe B, Syntaxe des règles 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'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, reportez-vous à la section Interface graphique et à l'Annexe A, Interface graphique utilisateur : Instructions générales.
Pour plus d'informations sur l'utilisation de l'assistant de CBR, reportez-vous à la section 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'une seule grappe de serveurs. Pour chaque serveur, configurez un port par l'intermédiaire duquel CBR communique. Reportez-vous à la Figure 9.
Figure 17. Exemple de composant CBR configuré avec une grappe et 2 ports
Dans cet exemple de composant CBR, une grappe est définie sur www.productworks.com. Elle 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 dernier cas, il est souhaitable de définir une grappe pour chaque protocole, avec un seul port mais plusieurs serveurs, comme illustré à la Figure 10.
Figure 18. Exemple de composant CBR configuré avec deux grappes, chacune associée à un port
Dans cet exemple de composant CBR, deux grappes sont définies : 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 une grappe 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 grappes, chacune associée à 2 ports
Dans cet exemple de composant CBR, deux grappes sont définies 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 se compose des sections suivantes :
Conditions requises par la plate-forme :
Le composant CBR permet d'équilibrer la charge du trafic HTTP et SSL à l'aide de Caching Proxy qui permet de transmettre la requête par un serveur proxy.
CBR permet d'équilibrer la charge des serveurs configurés à partir de votre fichier de configuration CBR (à l'aide de commandes cbrcontrol) ou à partir d'un fichier de configuration WAS. Pour plus d'informations sur l'équilibrage de charge de serveurs à partir d'un fichier de configuration WAS, reportez-vous à la section Equilibrage de la charge de WebSphere Application Servers (WAS).
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 fera 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. Cette répartition sera transparente pour les clients qui accèdent au 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 plug-in. 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 destypes 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 une grappe pour la répartition de charge, assurez-vous que toutes les requêtes envoyées à cette grappe 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, reportez-vous à la section Configuration de l'équilibrage 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.
Vous devez insérer une instruction de configuration dans le fichier ibmproxy.conf pour que IBM Caching Proxy active le chiffrement SSL du proxy vers le serveur. Le format est le suivant :
proxy uri_structure url_structure 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 de la grappe (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 conseil 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 grappes sont configurées et que pour chacune d'entre elles, 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
CBR permet d'équilibrer la charge des demandes d'applications Web hébergées sur des serveurs WAS (version 5) en grappe. La Figure 20 présente une configuration dans laquelle une machine Dispatcher haute disponibilité équilibre la charge sur CBR (avec Caching Proxy) au premier niveau et sur des serveurs WAS (ainsi que sur des serveurs Web HTTP) au second niveau.
Figure 20. Configuration pour déploiement de Dispatcher, CBR et WAS
CBR permet d'acheminer aussi bien les requêtes avec état que les requêtes sans état vers le serveur WAS approprié avec la forme d'affinité WAS. La configuration est gérée par mappage automatique du fichier de configuration du module d'extension WAS HTTP (dont le nom par défaut est plugin-cfg.xml) sur la configuration CBR. Vous pouvez charger le fichier de configuration du module d'extension WAS HTTP à l'aide de la commande cbrcontrol file newload. Cette commande mappe le fichier de configuration WAS sur la configuration CBR. Pour sauvegarder le fichier de configuration, utilisez de la commande cbrcontrol file save.
Si, après avoir chargé et mappé le fichier de configuration sur la configuration CBR, vous devez modifier la configuration de la grappe WAS, nous vous conseillons de recharger une mise à jour du fichier de configuration du module d'extension WAS HTTP. Pour mettre à jour la configuration de la grappe WAS, il est préférable de faire appel à la commande newload, au lieu d'actualiser la configuration par ajout de serveurs aux règles WAS à l'aide de la ligne de commande ou de l'interface graphique.
Lors du mappage de la configuration de la grappe WAS sur la configuration CBR, toutes les règles et tous les serveurs associés aux règles créées à partir du fichier de configuration du module d'extension WAS contiennent les informations suivantes permettant d'identifier leur source :
WLMServlet, situé sur le serveur WAS d'arrière-plan, détecte les serveurs arrêtés et fournit des informations de pondération de serveur au conseiller WLMServlet de Load Balancer. Seul WLMServlet est autorisé à conseiller sur les serveurs configurés comme membres d'une grappe WAS. Il n'est pas nécessaire que ce conseiller réside sur la machine WAS. En l'absence de WLMServlet, la pondération de serveur correspond par défaut aux pondérations définies dans le fichier de configuration du module d'extension WAS.
Avant d'effectuer les opérations décrites dans le présent chapitre, reportez-vous à la section Planification du composant CBR (Content Based Routing). Ce chapitre décrit comment créer une configuration de base pour le composant CBR de Load Balancer.
Tableau 7. Tâches de configuration pour le composant CBR
Tâche | Description | Informations connexes |
---|---|---|
Configurer le poste CBR | Conditions requises | Configuration du poste 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 permetent 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 la ligne de commande, procédez aux opérations ci-dessous.
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
! 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 ne peut être valide qu'avec l'invite cbrcontrol>>.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern client=181.0.153.222&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 "client=181.0.153.222&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>>.
Les commandes de configuration CBR peuvent être entrées dans un fichier script de configuration et exécutées simultanément.
cbrcontrol file appendload mon_script
cbrcontrol file newload mon_script
Pour sauvegarder la configuration en cours dans un fichier script (par ex. scriptsauvegarde), exécutez la commande suivante :
cbrcontrol file save scriptsauvegarde
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, reportez-vous à la 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 grappes contenant des ports et des serveurs, puis lancer des conseillers pour le gestionnaire.
Vous pouvez utiliser l'interface graphique pour toute opération exécutée habituellement par la commande cbrcontrol. Par exemple, pour définir une grappe à l'aide de la ligne de commande, entrez la commande cbrcontrol cluster add cluster. Pour définir une grappe à partir de l'interface utilisateur graphique, cliquez à l'aide du bouton droit de la souris sur Exécuteur puis dans le menu en incrustation, sélectionnez Ajout d'une grappe. Entrez l'adresse de la grappe 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, entrez 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 de détails sur l'utilisation de l'interface graphique, reportez-vous à l'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.
AIX, Linux ou Solaris : pour lancer Caching Proxy, entrez ibmproxy.
Sous Windows 2000 : accédez comme suit au panneau Services : Démarrer > Paramètres > 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'une grappe permettant à CBR d'équilibrer la charge du trafic d'un groupe de serveurs.
L'installation de la machine CBR ne peut être effectuée que par le superutilisateur (pour AIX, Linux ou Solaris) ou l'administrateur sous Windows 2000.
Vous aurez besoin d'une adresse IP pour chaque grappe de serveurs configurée. Une adresse de grappe 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 de la grappe en question. Cette adresse se trouve dans la requête URL du client. Toutes les requêtes envoyées à la même adresse de grappe font l'objet d'un équilibrage de charge par CBR.
Sous 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 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 grappe 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 module d'extension CBR :
Les ajouts spécifiques au fichier de configuration d'AIX, Linux, Solaris et Windows 2000 sont répertoriés ci-dessous.
Figure 21. Fichier de configuration CBR pour AIX, Linux et Solaris
ServerInit /opt/ibm/edge/lb/servers/lib/libndcbr.so:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/libndcbr.so:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/libndcbr.so:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/libndcbr.so:ndServerTerm
Figure 22. Fichier de configuration CBR pour Windows 2000
ServerInit c:\Program Files\IBM\edge\lb\servers\lib\libndcbr.dll:ndServerInit PostAuth c:\Program Files\IBM\edge\lb\servers\lib\libndcbr.dll:ndPostAuth PostExit c:\Program Files\IBM\edge\lb\servers\lib\libndcbr.dll:ndPostExit ServerTerm c:\Program Files\IBM\edge\lb\servers\lib\libndcbr.dll:ndServerTerm
Pour démarrer la fonction serveur CBR, entrez cbrserver sur la ligne 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 seront automatiquement chargées au prochain démarrage de cbrserver.
Pour démarrer la fonction exécuteur, entrez 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 à la grappe entre les serveurs correspondants configurés sur les ports de cette grappe.
La grappe 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.
Pour définir une grappe, tapez la commande suivante :
cbrcontrol cluster add grappe
Pour définir les options de grappe, tapez la commande suivante :
cbrcontrol cluster set valeur d'option de grappe
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 grappe de chaque site Web à l'une au moins des cartes d'interface réseau du dispositif Load Balancer. Sinon, vous pouvez ignorer cette étape.
AIX, Linux ou Solaris : pour ajouter l'adresse de
grappe à l'interface réseau, servez-vous de la commande ifconfig.
Utilisez la commande adaptée au système d'exploitation (voir le Tableau 8).
Tableau 8. Commandes pour l'affectation d'un alias à la carte d'interface réseau
AIX | ifconfig nom_interface alias adresse_grappe netmask masque_réseau |
Linux | ifconfig nom_interface adresse_grappe netmask masque_réseau up |
Solaris 7 | ifconfig nom_interface adresse_grappe netmask masque_réseau up |
Solaris 8 | ifconfig addif nom_interface adresse_grappe netmask masque_réseau up |
Windows : pour ajouter l'adresse de grappe à 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 de la grappe définie à l'étape précédente, entrez la commande
cbrcontrol port add cluster:port
Pour définir les options de port, tapez la commande suivante :
cbrcontrol port set cluster:port option value
Pour plus d'informations, reportez-vous au 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 la grappe et le port, tapez la commande suivante :
cbrcontrol server add grappe:port:serveur
Vous devez définir un ou plusieurs serveurs par port sur une grappe 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 grappe:port:règle type content pattern motif
La valeur pattern est l'expression régulière qui sera comparée à l'URL de chaque requête client. Pour plus d'informations sur la configuration de la structure, voir l'Annexe B, Syntaxe des règles 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 de l'équilibrage 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, émettez la commande suivante :
cbrcontrol rule useserver cluster:port:rule server
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 le niveau d'importance des informations pour la grappe, entrez la commande cbrcontrol cluster set grappe NiveauImportance. Pour plus d'informations, reportez-vous à la section 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 aux opérations ci-dessous.
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. Etant donné que Site Selector équilibrera la charge sur plusieurs URL ou sites de ce domaine, vous devez définir un sous-domaine (apps.ma_boutique_web.com). Site Selector a autorité sur le sous-domaine apps.mon_service_web.com. La 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 la ligne 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 la ligne de commande.
A partir d'une invite, effectuez les opérations ci-dessous.
sscontrol sitename add marketing.apps.ma_boutique_web.com
sscontrol sitename add développeur.apps.ma_boutique_web.com
sscontrol server add marketing.apps.ma_boutique_web.com:serveur1+serveur2
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 développeur.apps.ma_boutique_web.com:21
Site Selector vérifie désormais que les demandes des clients ne sont pas envoyées vers un serveur arrêté.
sscontrol nameserver start
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, reportez-vous aux sections 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, reportez-vous à la section 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.
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, sous 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 du réseau. Le serveur de noms achemine la demande au poste Site Selector. Ce dernier 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.
Reportez-vous à 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 fera 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 de plus amples informations, reportez-vous à 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, reportez-vous à la section 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 sera 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 de plus amples informations, reportez-vous au Guide des commandes Site Selector.
Avant d'effectuer les opérations décrites dans le présent chapitre, reportez-vous à la section Planification du composant Site Selector. Ce chapitre décrit comment créer une configuration de base pour le composant Site Selector de Load Balancer.
Tableau 9. Tâches de configuration pour le composant Site Selector
Tâche | Description | Informations connexes |
---|---|---|
Configuration de la machine Site Selector. | Conditions requises | Installation 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 de serveurs avec équilibrage de charge |
Quatre méthodes permettent de créer une configuration de base pour composant Site Selector de Load Balancer :
C'est la méthode la plus directe pour la configuration de Site Selector. 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, puis exécutées ensemble.
sscontrol file appendload mon_script
sscontrol file newload mon_script
Pour sauvegarder la configuration en cours dans un fichier script (par ex. scriptsauvegarde), exécutez la commande suivante :
sscontrol file save scriptsauvegarde
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, reportez-vous à 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. Vous pouvez lancer le gestionnaire une fois que vous vous êtes connecté à un hôte. Vous pouvez également créer des noms de site 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 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 qui apparaît, cliquez avec le bouton gauche de la souris sur 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 votre configuration Site Selector 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.
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, entrez 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 de détails sur l'utilisation de l'interface graphique, reportez-vous à l'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 sélectionner l'assistant de configuration à partir du menu du composant Site Selector présenté dans l'interface graphique.
L'assistant 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.
L'installation de la machine Site Selector ne peut être effectuée que par le superutilisateur (pour AIX, Linux ou Solaris) ou l'administrateur pour Windows 2000.
Vous aurez besoin d'utiliser un nom d'hôte DNS 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é.
AIX, Linux et Solaris : Pour démarrer la fonction serveur, entrez ssserver.
Pour démarrer le serveur de noms, entrez 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 demandes envoyées pour le nom de site aux serveurs correspondants configurés pour cela.
Le nom de site est un nom d'hôte ne pouvant être résolu qui sera demandé par le client. Le nom de site doit être un nom de domaine complet (par exemple, www.dnsdownload.com). Lorsqu'un client demande ce nom de site, l'une des adresses IP de serveur associées au nom de site sera renvoyée.
Pour définir un nom de site, émettez la commande suivante :
sscontrol sitename add nom_site
Pour définir les options du nom de site, émettez la commande suivante :
sscontrol sitename set valeur_option_nom_site
Pour plus d'informations, reportez-vous au 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, émettez 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'améliorer l'é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, entrez 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, reportez-vous à la section 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 pour le nom de site, émettez la commande sscontrol sitename set nom_site proportions. Pour plus d'informations, reportez-vous à la section 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 Selecteur assure l'équilibrage de charge, reportez-vous à la section Metric Server.
Cette 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 la ligne 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é au Cisco CSS Switch 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 via 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 du contrôleur Cisco CSS, reportez-vous aux sections Interface graphique et à l'Annexe A, Interface graphique utilisateur : Instructions générales.
Le présent chapitre décrit les aspects qu'un 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 :
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 préférable 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 de plus amples informations, reportez-vous à 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, reportez-vous à la section Utilisation des journaux Load Balancer.
Avant d'effectuer les opérations décrites dans le présent chapitre, reportez-vous à la section Planification du composant 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 10. Tâches de configuration du composant Cisco CSS Controller
Tâche | Description | Informations connexes |
---|---|---|
Configuration de la machine Cisco CSS Controller | Conditions requises | Installation de la machine Contrôleur pour 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 la plus directe pour la configuration de Cisco CSS Controller. Les procédures décrites dans ce manuel reposent sur l'utilisation de la ligne de commande. Les valeurs des paramètres de commande doivent être saisies en anglais. Les seules exceptions s'appliquent aux noms d'hôte (utilisés, par exemple, dans la commande consultant add command) 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), procédez de l'une des manières ci-dessous.
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, reportez-vous à la 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. Par 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.
Pour accéder à l'aide, cliquez sur le point d'interrogation situé dans l'angle supérieur droit de la fenêtre Load Balancer.
Pour plus de détails sur l'utilisation de l'interface graphique, reportez-vous à l'Annexe A, Interface graphique utilisateur : Instructions générales.
L'installation de la machine Cisco CSS Controller ne peut être effectuée que par le superutilisateur (sous AIX, Linux ou Solaris) ou l'administrateur (sous Windows 2000).
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, reportez-vous au 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, reportez-vous à la section 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, reportez-vous à la section 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 des pondérations de serveur à 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 la ligne 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é au Nortel Alteon Web Switch 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 via 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, reportez-vous à la section Interface graphique et à l'Annexe A, Interface graphique utilisateur : Instructions générales.
Le présent chapitre décrit les aspects qu'un 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 :
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 disposent tous deux de fonctions de haute disponibilité.
Vous pouvez configurer deux contrôleurs pur 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 à tout moment 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, a 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 de plus amples informations, reportez-vous à la section Haute disponibilité.
Dans la Figure 33 :
Figure 33. Exemple de Nortel Alteon Controller et de Nortel Alteon Web Switch haute disponibilité
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 de plus amples informations, reportez-vous à 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, reportez-vous à la section 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, reportez-vous à la section Utilisation des journaux Load Balancer.
Avant d'effectuer les opérations décrites dans le présent chapitre, reportez-vous à la section Planification du composant Nortel Alteon Controller. Ce chapitre décrit 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 11. Tâches de configuration pour le composant Nortel Alteon Controller
Tâche | Description | Informations connexes |
---|---|---|
Configurer Nortel Alteon Web Switch et les serveurs | Configuration du commutateur. | Configuration du commutateur, page (SETSWITCH) |
Configurer 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 :
Il s'agit de la méthode la plus directe pour configurer Nortel Alteon Controller. Les procédures décrites dans ce manuel reposent sur l'utilisation de la ligne 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 XMLFilename
La commande de chargement (load) n'est utilisable qu'après exécution d'une commande file save.
nalcontrol file load XMLFileName
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, reportez-vous à la 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. Par 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.
Pour accéder à l'aide, cliquez sur le point d'interrogation situé dans l'angle supérieur droit de la fenêtre Load Balancer.
Pour plus de détails sur l'utilisation de l'interface graphique, reportez-vous à l'Annexe A, Interface graphique utilisateur : Instructions générales.
Pour obtenir une aide sur les commandes utilisées lors de cette procédure, reportez-vous au Guide des commandes Nortel Alteon Controller.
Avant d'installer 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. Les proportions doivent toujours égaler 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, reportez-vous aux 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, reportez-vous à la section Système Metric Server.
Modifier la configuration sur le 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 12. 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/réponse (URL) de conseiller HTTP | Définit une chaîne HTTP URL client unique propre à un service que vous voulez demander sur la machine | Configuration du conseiller HTTP à l'aide de l'option de demande/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ée à 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é (entrée à partir de l'agent Metric Server) sur chaque serveur d'équilibrage de charge. Pour Site Selector uniquement, cette proportion apparaît à la place de la colonne de la proportion des nouvelles connexions.
Outre la charge courante de chaque serveur et d'autres données nécessaires à ses calculs, le gestionnaire obtient les deux premières valeurs (nouvelles connexions et connexions actives) de la part de l'exécuteur. Ces valeurs dépendent de données générées et stockées en interne par l'exécuteur.
Vous pouvez modifier la proportion d'importance relative des quatre valeurs sur la base d'une grappe (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 sera faible. Si les connexions client sont lentes (comme dans le cas de requêtes de base de données), le nombre de connexions actives sera 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 grappe proportions. Pour de plus amples informations, reportez-vous à la section dscontrol cluster -- Configuration des grappes.
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, reportez-vous à la section Pondérations fixées par le gestionnaire.
Les pondérations définies s'appliquent à tous les serveurs connectés sur un même port. Pour chaque port, les demandes seront réparties entre les serveurs selon la pondération relative de chacun. Par exemple, si un serveur a une pondération (paramètre Weight) de 10 et un autre de 5, le premier recevra deux fois plus de demandes que le second.
Pour définir la limite de pondération maximale d'un serveur, entrez la commande dscontrol port set port weightbound weight. Cette commande intervient sur l'écart existant entre les serveurs au niveau du nombre de demandes reçues par chacun. Si la 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 pondération maximale de 2, un serveur donné pourra recevoir deux fois plus de demandes qu'un autre. Avec une pondération maximale de 10, un serveur donné pourra recevoir dix fois plus de demandes qu'un autre. La 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.
Sans le gestionnaire, les conseillers ne peuvent pas être lancés ni détecter les pannes de serveur. Si vous choisissez de lancer les conseillers mais ne voulez pas que le gestionnaire mette à jour la pondération que vous fixée pour un serveur particulier, utilisez l'option fixedweight de la commande dscontrol server. Par exemple :
dscontrol server set grappe: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 commande dscontrol en attribuant la valeur no à l'option fixedweight. Pour plus de détails, reportez-vous à la section 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ée 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 utilse à configurer. Cette fonction permet à un conseiller de renouveler une tentative de connexion avant de déclarer un serveur arrêté. Ainsi le conseiller ne déclarera prématurément pas un seveur arrêté aurisque de provoquer des incidents de réinitialisation de connexion. En clair, le fait que le conseille échoue à la première tentative ne signifie pas nécessairement que la connexion existante est coupée. Pour plus d'informations, reportez-vous à la section Tentative du conseiller.
Pour optimiser les performances générales du réseau, la fréquence des interactions entre le gestionnaire et l'exécuteur est limitée. Pour modifier cet intervalle d'interaction, entrez les commandes dscontrol manager interval et dscontrol manager refresh.
L'intervalle gestionnaire indique la fréquence selon laquelle le gestionnaire réactualise les pondérations des serveurs utilisés par l'exécuteur pour acheminer les connexions. Si l'intervalle gestionnaire est trop court, le gestionnaire interrompra l'exécuteur constamment et les performances déclineront. Dans le cas contraire, le routage des demandes assuré par l'exécuteur reposera sur des informations anciennes et incertaines.
Par exemple, pour définir un intervalle gestionnaire d'une seconde, entrez la commande suivante :
dscontrol manager interval 1
Le seuil de régénération du gestionnaire détermine la fréquence selon laquelle le gestionnaire demande des données d'état à l'exécuteur. Le seuil de régénération dépend de la durée de l'intervalle.
Par exemple, pour fixer à 3 intervalles le seuil de régénération du gestionnaire, entrez la commande suivante :
dscontrol manager refresh 3
Après cette commande, le gestionnaire devra patienter 3 intervalles avant de demander des données d'état à l'exécuteur.
D'autres méthodes d'optimisation de l'équilibrage de charge des serveurs sont disponibles. Pour fonctionner en vitesse maximale, les pondérations des serveurs ne sont actualisées que si les pondérations ont évolué de manière significative. La mise à jour constante des pondérations pour un écart mineur de l'état des serveurs induirait un surcroît d'activité injustifié. Lorsque, pour tous les serveurs d'un port donné, l'écart en pourcentage de la pondération totale dépasse le seuil de sensibilité, le gestionnaire réactualise les pondérations des serveurs utilisés par l'exécuteur pour répartir les connexions. Supposons par exemple que la pondération totale passe de 100 à 105. L'écart est de 5%. Avec un seuil de sensibilité par défaut de 5, le gestionnaire ne met pas à jour les pondérations utilisées par l'exécuteur, car l'écart en pourcentage n'est pas supérieur au seuil. Si, en revanche la pondération totale passe de 100 à 106, le gestionnaire met à jour les pondérations. Pour attribuer au seuil de sensibilité du gestionnaire une valeur autre que la valeur par défaut (par exemple, 6), entrez la commande suivante :
dscontrol manager sensitivity 6
Dans la plupart des cas, vous n'aurez pas besoin de modifier cette valeur.
Le gestionnaire calcule dynamiquement les pondérations des serveurs. Il en découle qu'une fois mise à jour, une nouvelle pondération peut être très différente de l'ancienne. Dans la plupart des cas, cela ne porte pas à conséquence. Cependant, cela peut parfois induire de fortes variations dans la manière dont l'équilibrage de charge est effectué pour les demandes. Par exemple, l'un des serveurs peut finir par réceptionner la plupart des demandes du fait d'une pondération élevée. Le gestionnaire s'apercevra alors que le serveur en question traite un nombre élevé de connexions et répond lentement. Il transposera alors la pondération sur des serveurs moins encombrés et le même phénomène se reproduira, induisant une exploitation improductive des ressources.
Pour corriger ce dysfonctionnement, le gestionnaire utilise un indice de lissage. L'indice de lissage limite l'écart de pondération d'un serveur, filtrant et uniformisant effectivement la variation dans la répartition des demandes. Plus l'indice de lissage sera élevé, moins les pondérations des serveurs varieront. Plus l'indice de lissage sera faible, plus les pondérations des serveurs changeront. La valeur par défaut de l'indice de lissage est de 1,5. Avec un index de 1,5, les pondérations des serveurs seront plutôt fluctuantes. Pour un index de 4 ou 5, ces pondérations seront plus constantes. Par exemple, pour fixer l'indice de lissage à 4, entrez la commande suivante :
dscontrol manager smoothing 4
Dans la plupart des cas, vous n'aurez pas besoin de modifier cette valeur.
Load Balancer fournit des exits utilisateur qui déclenchent des scripts que vous pouvez personnaliser. Vous pouvez créer des scripts afin d'effectuer des actions automatisées. Il est, par exemple, possible de prévenir un administrateur lorsque le gestionnaire indique qu'un serveur est inactif ou simplement d'enregistrer l'erreur. Le répertoire 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 :
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, vous ne pouvez pas utiliser 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 sous Linux d'utilisation de serveurs de liaison : Sous Linux, Load Balancer ne permet pas l'utilisation de conseillers lors de l'équilibrage de la charge des serveurs de liaison (autres composants Load Balancer tels que CBR Locator ou Site Selector compris) lorsqu'ils sont reliés à l'adresse IP de la grappe.
Restriction sous Solaris d'utilisation de serveurs de liaison : Si vous utilisez la commande arp publish au lieu de la commande ifconfig alias, Load Balancer accepte l'utilisation de conseillers lors de l'équilibrage de la charge des serveurs de liaison (autres composants Load Balancer tels que CBR Locator ou Site Selector compris) lorsqu'ils sont reliés à l'adresse IP de la grappe. 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.
-DND_ADV_SRC_ADDR=adresse-IP-notation-décimale
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 toutes les grappes (conseiller de groupe). Vous pouvez également choisir d'exécuter différents conseillers sur le même port mais sur des grappes différentes (conseiller spécifique grappe/site). Par exemple, si Load Balancer est défini avec trois grappes (grappe A, grappe B, grappe C), pour chaque grappe le port 80 a une fonction différente.
dscontrol advisor start http grappeA:80Cette commande lance le conseiller http sur le port 80 pour la grappe A. Le conseiller http fonctionne sur tous les serveurs connectés au port 80 pour la grappe A.
dscontrol advisor start ADV_personnalisé 80Cette commande lance le conseiller ADV_personnalisé sur le port 80 pour la grappe B et la grappe C. Le conseiller personnalisé fonctionne sur tous les serveurs connectés au port 80 pour la grappe B et la grappe C. (Pour obtenir plus d'informations sur les conseillers personnalisés, reportez-vous à la section Création de conseillers personnalisés.)
Lorsque vous utilisez la configuration exemple ci-dessus, vous pouvez choisir d'arrêter le conseiller personnalisé ADV_custom pour le port 80 sur une grappe uniquement ou pour les deux grappes (grappe B et grappe C).
dscontrol advisor stop ADV_personnalisé grappeB: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, entrez la commande suivante :
dscontrol advisor interval http 80 3
Notez qu'il n'est pas logique de spécifier un intervalle conseiller inférieur à l'intervalle gestionnaire. L'intervalle conseiller par défaut est sept secondes.
Pour s'assurer que le gestionnaire n'utilise pas d'informations périmées pour ses décisions d'équilibrage de charge, le gestionnaire n'utilisera pas les informations d'un conseiller dont l'horodatage sera antérieur à celui défini dans le délai de rapport du conseiller. Le délai de rapport du conseiller doit être supérieur à l'intervalle de sondage du conseiller. Si le délai est inférieur, le gestionnaire ignore les états qu'il est censé exploiter. Par défaut, les rapports des conseillers n'ont pas de délai d'expiration -- la valeur par défaut est Unlimited (illimité).
Par exemple, pour fixer à 30 secondes l'intervalle du conseiller HTTP sur le port 80, entrez la commande suivante :
dscontrol advisor timeout http 80 30
Pour obtenir plus d'informations sur la définition du délai de rapport du conseiller, reportez-vous à la section dscontrol advisor -- Contrôle du conseiller.
Pour Load Balancer, vous pouvez définir les valeurs de délai du conseiller lorsqu'une erreur au niveau d'un port particulier du serveur (service) est détectée. Les valeurs de délai d'erreur serveur (connecttimeout et receivetimeout) déterminent la durée attendue par un conseiller avant de signaler qu'une connexion ou une réception n'a pas abouti.
Pour obtenir une détection d'erreur serveur très rapide, attribuez la valeur la plus basse (une seconde) aux délais de connexion et de réception du conseiller et attribuez la valeur la plus basse (une seconde) à l'intervalle du gestionnaire et du conseiller.
Par exemple, pour attribuer la valeur 9 secondes à connecttimeout et à receivetimeout pour le conseiller HTTP sur le port 80, entrez la commande suivante :
dscontrol advisor connecttimeout http 80 9 dscontrol advisor receivetimeout http 80 9
La valeur par défaut de connexion et de réception est trois fois supérieure à la valeur indiquée pour l'intervalle du conseiller.
Les conseillers peuvent essayer de nouveau d'établir une connexion avant de marquer un serveur comme arrêté. Le serveur ne signale 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 est disponible pour les composants Dispatcher et CBR.
Après avoir lancé un conseiller HTTP, vous pouvez définir une chaîne HTTP URL client unique, propre au service que vous voulez demander sur le serveur. Ainsi, le conseiller HTTP peut 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 de plus amples informations, reportez-vous à la section 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 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 correspond à la réponse du conseiller HHTP recherche dans la réponse HTTP. Le conseiller HTTP utilise la chaîne advisorresponse pour comparer la véritable réponse reçue du serveur. La valeur par défaut est null.
Important : Si l'URL HTTP contient un espace :
server set grappe:port:serveur advisorrequest "head / http/2.0" server set grappe:port:serveur advisorresponse "HTTP 200 OK"
dscontrol server set grappe:port:serveur advisorrequest "\"head / http/2.0\"" dscontrol server set grappe:port:serveur advisorresponse "\"HTTP 200 OK\""
Lorsque vous rédigez la demande que le conseiller HTTP envoie aux serveur d'arrière-plan pour vérifier s'ils fonctionnent, vous tapez le début de la demande HTTP et Load Balancer complète la demande avec 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 de plus amples informations, reportez-vous à la section dscontrol server -- Configuration des serveurs.
Le conseiller self est disponible dans le composant Dispatcher.
Lorsque Load Balancer se trouve dans une configuration WAN (wide area network) à deux niveaux, un conseiller self est fourni qui rassemble des informations de statut de chargement sur les serveurs périphériques.
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 périphériques du système Dispatcher se trouvant au niveau de l'exécutant.
Le conseiller self inscrit les résultats dans le fichier dsloadstat. Load Balancer fournit également une mesure externe appelée dsload. L'agent du système Metric Server de chaque machine Dispatcher exécute son fichier de configuration qui appelle le script dsload de mesure externe. Le script dsload extrait une chaîne du fichier dsloadstat et le renvoie à l'agent du système Metric Server. Ensuite, chaque agent du système Metric Server (de chaque élément Dispatcher) renvoie la valeur de statut de chargement à l'élément Load Balancer se trouvant au niveau supérieure. 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 e ...ibm/edge/lb/ms/script pour Load Balancer.
Pour plus d'informations sur l'utilisation de Dispatcher dans des configurations WAN, reportez-vous à la section Configuration du support de réseau étendu pour Dispatcher. Pour plus d'informations sur le système Metric Server, reportez-vous à la section Metric Server.
Le conseiller personnalisé est un petit programme Java, que vous fournissez sous forme de fichier classe, appelé par le code de base. Le code de base fournit tous les services administratifs, tels que le démarrage et l'arrêt d'une instance du conseiller personnalisé, la génération d'états et de rapports et l'enregistrement des informations de l'historique dans un fichier journal. Il renvoie également les résultats au composant gestionnaire. Régulièrement, le code de base lance un cycle de conseiller au cours duquel il évalue individuellement tous les serveurs de sa configuration. Il commence par ouvrir une connexion avec la machine serveur. Si la connexion s'ouvre, le code de base appelle la méthode " getLoad" (fonction) dans le conseiller personnalisé. Ce dernier effectue la procédure nécessaire à l'évaluation du serveur. Généralement, il envoie au serveur un message défini par l'utilisateur et attend la réponse. L'accès à la connexion ouverte est fourni au conseiller personnalisé. Le code de base ferme ensuite la connexion au serveur et envoie au gestionnaire les informations relatives à la charge.
Le code de base et le conseiller personnalisé peuvent opérer en mode normal ou en mode replace. Le choix du mode de fonctionnement est indiqué dans le fichier du conseiller personnalisé en tant que paramètre dans la méthode du constructeur.
En mode normal, le conseiller personnalisé échange des données avec le serveur et le code du conseiller de base évalue la durée de l'échange et calcule la valeur de la charge. Le code de base renvoie cette valeur au gestionnaire. Le conseiller personnalisé doit simplement retourner un zéro (succès) ou une valeur négative (échec). Lorsque dans le ficher du constructeur, la valeur false est attribuée à l'indicateur replace, le mode normal est défini.
En mode replace, le code de base n'effectue aucune mesure de temps. Le code du conseiller personnalisé effectue toutes les opérations nécessaires, puis renvoie une valeur de charge. Le code de base accepte la valeur et la retourne au gestionnaire. Pour obtenir de meilleurs résultats, situez votre valeur de charge entre 10 et 1000, 10 représentant un serveur rapide et 1000 un serveur plus lent. Lorsque dans le fichier du constructeur, la valeur true est attribuée à l'indicateur replace, le mode replace est défini.
Avec cette fonctionnalité, vous pouvez développer vos propres conseillers qui fourniront les informations sur les serveurs dont vous avez besoin. Un exemple de conseiller personnalisé, ADV_exemple.java, est fourni avec le produit Load Balancer. Une fois Load Balancer installé, le code exemple se trouve dans le répertoire d'installation ...<répertoire installation>/servers/samples/CustomAdvisors.
Le répertoire d'installation par défaut est :
Le répertoire d'installation de Load Balancer contient des fichiers exemple de conseiller personnalisé spécifiques au conseiller WebSphere Application Server (WAS).
Les fichiers exemple de conseiller WebSphere Application Server se trouvent dans le même répertoire que le fichier ADV_exemple.java.
Le nom de fichier de votre conseiller personnalisé doit avoir le format "ADV_monconseiller.java." Il doit être précédé du préfixe "ADV_" en majuscules. Tous les caractères suivants doivent être en minuscules.
Conformément aux conventions Java, le nom de la classe définie dans le fichier doit correspondre au nom du fichier. Si vous copiez le code exemple, veillez àremplacer toutes les occurrences de "ADV_exemple" dans le fichier par le nom de votre nouvelle classe.
Les conseillers personnalisés sont écrits en langage Java. Vous devez obtenir et installer un compilateur Java 1.3 pour votre machine. 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 2000, une commande de compilation peut avoir l'aspect suivant :
javac -classpath <rep_install>\lb\servers\lib\ibmnd.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.
La syntaxe est similaire pour AIX, Linux et Sun.
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ù :
Comme tous les conseillers, un conseiller personnalisé étend la fonction de la base du conseiller, intitulée ADV_Base. En fait, c'est la base du conseiller qui effectue la plupart des fonctions du conseiller, telles que la communication des charges au gestionnaire afin que ces dernières soient utilisées dans l'algorithme de pondération du gestionnaire. La base du conseiller effectue également les opérations de connexion et de fermeture de la connexion et fournit des méthodes d'envoi et de réception qui seront utilisées par le conseiller. Le conseiller n'est lui-même utilisé que pour l'envoi de données vers le port du serveur conseillé et pour la réception de données sur ce dernier. Les méthodes TCP de la base du conseiller sont programmées pour calculer la charge. Un indicateur du constructeur de ADV_base remplace, si vous le souhaitez, la charge existante par la nouvelle charge renvoyée par le conseiller.
Ci-dessous, sont énumérées les méthodes de classe de base.
Load Balancer consulte tout d'abord la liste des conseillers en langage naturel. S'il ne trouve pas un conseiller donné, Load Balancer consulte la liste des conseillers personnalisés du clients.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
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 du serveur. 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 obtenir un exemple de configuration, reportez-vous à la Figure 5.
Comme le conseiller WLM, le rapport du Metric Server concerne l'ensemble des systèmes de serveurs et non chaque démon de serveur associé à un protocole. WLM et Metric Server placent leurs résultats dans la colonne relative au système du rapport du gestionnaire. Par conséquent, il n'est pas possible d'exécuter simultanément le conseiller WLM et Metric Server.
L'agent Metric Server doit être installé et en cours d'exécution sur tous les serveurs dont la charge est équilibrée.
La procédure ci-après permet de configurer Metric Server pour Network Dispatcher. Vous pouvez configurer Metric Server pour les autres composants de Load Balancer à l'aide d'une procédure similaire.
port correspond au port RMI sur lequel fonctionnent tous les agents du système Metric Server. La valeur par défaut du port RMI est 10004, cette valeur est définie dans le fichier metricserver.cmd.
systemMetric correspond au nom du script (se trouvant sur le serveur périphérique) qui doit s'exécuter sur chacun des serveurs de la configuration sous la grappe indiquée (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-100. Cette valeur numérique doit représenter une mesure de charge, et non un indicateur de disponibilité.
Restriction : Pour Windows 2000, si le nom du script System Metric comporte une extension autre que ".exe", vous devez indiquer le nom complet du fichier (par exemple, "monscriptsyst.bat"). Cette restriction est due à une limitation Java.
Les clients peuvent éventuellement écrire leurs propres fichiers scripts personnalisés qui définiront la commande passée par Metric Server sur les serveurs. Vérifiez que tous les scripts personnalisés sont exécutables et se trouvent dans le répertoire ...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.
Windows 2000 : Vous devez également affecter 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, 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. Ces chiffres représentent la capacité encore disponible et 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 (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 13. 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 machine Dispatcher 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 de l'équilibrage 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 grappe. | 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é trans ports 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é trans ports |
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 machine Dispatcher éloignée pour l'équilibrage de charge sur un réseau étendu. Ou effectue l'équilibrage de charge dans un réseau étendu (sans Dispatcher éloigné) à l'aide d'une plate-forme 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'une grappe générique pour combiner des configurations serveur communes | Les adresses non explicitement configurées utiliseront la grappe générique pour équilibrer le trafic. | Utilisation d'une grappe générique pour combiner les configurations serveurs |
Utilisation d'une grappe générique pour équilibrer la charge des pare-feux. | La totalité du trafic sera équilibré sur les pare-feux. | Utilisation de la grappe générique pour équilibrer la charge des pare-feux |
Utilisation d'une grappe générique avec Caching Proxy pour le proxy transparent | Permet d'utiliser Dispatcher pour activer un proxy transparent. | Utilisation de grappe 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 |
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.
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, vous devez installer un correctif de noyau Linux. Pour obtenir plus d'informations sur l'installation du correctif, reportez-vous à la section Installation du correctif du noyau Linux (pour supprimer les réponses ARP sur l'interface de bouclage). Cependant, lorsque vous suivez ces instructions, ignorez l'étape d'attribution d'un adaptateur de bouclage. Vous devez ajouter l'instruction ifconfig afin d'attribuer un alias à l'adaptateur de bouclage dans le fichier de script goStandby high-availability qui s'exécute lorsqu'un composant Dispatcher passe à l'état Attente.
Solaris : Dans cet environnement, vous ne pouvez pas configurer de conseillers WAN lorsque le point d'entrée est co-implanté. Reportez-vous à la section Utilisation de conseillers éloignés 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.
Vous pouvez configurer un serveur co-implanté de l'une des manières suivantes :
Pour plus d'informations sur la syntaxe de la commande dscontrol server, reportez-vous à la section dscontrol server -- Configuration des serveurs.
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 machine Dispatcher :
route add return_addr gw routeur
où routeur correspond au routeur du sous-réseau local.
arp -s nom_hôte 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 plate-formes 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 plate-formes 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 de la grappe. 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, reportez-vous à la section Configuration de la machine Dispatcher.
Windows 2000 uniquement : Configurez également chaque adresse NFA avec la commande dsconfig. Par exemple :
dsconfig en0 adr_nfa netmask masque_réseau
dscontrol cluster set grappeA hôte_principal NFAdispatcher1 dscontrol cluster set grappeB hôte_principal dispatcherNFA2
dscontrol cluster set grappeB hôte_principal NFAdispatcher2 dscontrol cluster set grappeA hôte_principal dispatcherNFA1
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 d'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 de la grappe. 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.
dscontrol highavailability reach add 9.67.125.18Les cibles à atteindre sont recommandées mais pas obligatoires. Reportez-vous à la section Détections des incidents en utilisant signal de présence et cible à atteindre, pour de plus amples informations.
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.
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.
Vous devez choisir au moins un hôte pour chaque sous-réseau que la machine Dispatcher 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. 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 Dispatcher de secours que par la machine Dispatcher 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 machine Dispatcher 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.
Pour une configuration de haute disponibilité réciproque , il n'existe pas de défaillance par grappe. Si l'une des machines est victime d'une défaillance, même si celle-ci ne concerne qu'une des grappes, l'autre machine prendra le relais pour chacune des deux grappes.
Pour que Dispatcher puisse acheminer les paquets de données, chaque adresse de grappe doit posséder un alias la reliant à une 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 exemples suivants peuvent être utilisés :
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. Par 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.
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 :
Il est recommandé de planifier 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, reportez-vous à l'Annexe B, Syntaxe des règles 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. Une fois la règle 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 de clients IBM. Dans le cas contraire, les demandes provenant des adresses 9.x.x.x ne seront 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 à HTTP cinq serveurs à plein temps, puis d'en ajouter cinq autres 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 devez 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, reportez-vous à la section 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, de la grappe 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 grappe-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 de la grappe à 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 de la grappe permet à la grappe d'utiliser une largeur de bande maximale indiquée. Tant que la largeur de bande utilisée par la grappe 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 grappe. 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 sera 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 dans 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 être mise en application.
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 dans 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 être mise en application.
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 modèle valide pour la règle de contenu, reportez-vous à l'Annexe B, Syntaxe des règles 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 porte 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, la prochaine fois que le client adresse une demande à la grappe, la charge de celle-ci est envoyée au serveur d'application le plus disponible, et non au serveur de débordement.
Pour plus d'informations sur la syntaxe de commande de la substitution d'affinité de port, en utilisant l'option de serveurmaintien de routage, reportez-vous à la section 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. Il connaît les adresses IP de chacune de ces divisions. Il doit créer 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
Il doit ensuite ajouter un serveur distinct à chaque règle, puis mesurer la charge de chaque serveur pour facturer correctement les divisions en fonction des services qu'elles utilisent. Par 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 sera 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 grappes soit conservé. Lorsque vous configurez un port de grappe 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, de la grappe ou du port. Lorsque vous attribuez la valeur zéro au délai de maintien de routage, cette fonction est désactivée.
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.
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ù la notion de "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é.
L'affinité trans ports s'applique uniquement aux méthodes d'acheminement MAC et NAT/NATP du composant Dispatcher.
L'affinité trans ports 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é trans ports 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é trans ports au port 10 :
dscontrol port set grappe:20 crossport 10 dscontrol port set grappe:30 crossport 10 dscontrol port set grappe:40 crossport 10
Après l'établissement de l'affinité trans ports, 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é trans ports, replacez la valeur trans ports sur son propre numéro de port. Reportez-vous à dscontrol port -- Configuration des ports, pour de plus amples informations sur la syntaxe de commande de l'optiontrans 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 32 bits. Si cette fonction est configurée lors de la première connexion d'un client à un port, alors 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é trans ports : Lors de l'activation de l'affinité trans ports, les valeurs du masque de maintien de routage des ports partagés doivent être identiques. Reportez-vous à la section Affinité trans ports, pour de plus amples informations.
Pour activer le masque d'adresse d'affinité, émettez une commande dscontrol port du type :
dscontrol port set grappe: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.
Reportez-vous à la section dscontrol port -- Configuration des ports, pour de plus amples 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, reportez-vous à la section dscontrol rule -- Configuration des règles.
Une fois la règle configuré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 grappe: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=grappe:port:règle+serveur-heure! Les informations grappe: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 grappe:port:règle stickytime 60 rule set grappe: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.
Sous AIX, Solaris et Linux, le fichier cbrserver se trouve dans le répertoire /usr/bin.
Sous Windows 2000, il se trouve dans \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, reportez-vous à la section Fonction 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é. Une fois que vous attribué la valeur "cookiepassif" à l'affinité d'une règle, l'affinité de cookie passif vous 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. Une fois la règle déclenchée, 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 envoie les nouvelles demandes entrantes aux serveurs en fonction des cookies qui ont été générés par les serveurs lors de connexions précédentes. S'il n'est possible de trouver la valeur du cookie dans la demande client ou si elle ne correspond à aucune des valeurs de cookie du serveur, le serveur sera choisi à l'aide 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é). Une fois que 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, reportez-vous à la section Fonction 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 serveur, 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é). Une fois que 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 (reportez-vous à la section Figure 35). Une demande client arrive à la machine Dispatcher 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
L'extension 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 vous n'utilisez pas la méthode d'acheminement NAT de Dispatcher, 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). Toutes les machines Dispatcher doivent exécuter le même système d'exploitation. Un paquet émanant d'un client peut alors être transmis d'Internet à une machine Dispatcher, puis à une machine Dispatcher éloignée géographiquement et enfin à l'un de ses serveurs locaux.
Figure 36. Exemple de configuration utilisant des serveurs locaux et éloignés
Cela permet à une adresse de grappe de supporter l'ensemble des demandes client du monde entier, tout en répartissant la charge entre l'ensemble des serveurs.
La machine Dispatcher qui reçoit le paquet en premier peut tout de même être connectée à des serveurs locaux et répartir la charge entre ses serveurs locaux et les serveurs éloignés.
Les commandes de réseau étendu ne sont pas complexes. Pour configurer un support de réseau étendu :
dscontrol server add grappe:port:serveur router adresse
Pour obtenir plus d'informations sur le mot clé router, reportez-vous à la section dscontrol server -- Configuration des serveurs.
Sur des répartiteurs de base : Les conseillers fonctionnent correctement sans configuration particulière pour la plupart des plateformes.
Linux
Solaris
arp -s <mon_adresse_grappe> <mon_adresse_mac> pub
Sur des répartiteurs éloignés : Exécutez les étapes de configuration suivantes pour chaque adresse de grappe éloignée. Pour une configuration de haute disponibilité à l'emplacement Load Balancer éloigné, vous devez effectuer cette configuration sur les deux machines.
AIX
ifconfig lo0 alias 9.67.34.123 netmask 255.255.255.255
Linux
ifconfig lo:1 9.67.34.123 netmask 255.255.255.255 up
Solaris
Windows 2000
dscontrol executor configure 9.55.30.45
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 grappe xebec sur le port 80. LB1 est défini comme "point d'entrée". 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 éloignés LB2 et LB3.
Sur la console de la première machine Dispatcher (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 LB1 configurez également xebec en tant que clusteraddr.
dscontrol executor configure xebec
Sur la console de la deuxième machine Dispatcher (LB2) :
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure LB2
Sur la console de la troisième machine Dispatcher (LB3) :
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure LB3
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 prend 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,e (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 grappe:port:serveur :
dscontrol server add grappe:port:ServeurD router Routeur1
Linux dispose en natif d'une possibilité d'excapsulation GRE permettant à Load Balancer d'équilibrer la charge d'images de serveur Linux/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 configure chaque serveur périphérique 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 sont conservée 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_grappe 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 une zone, cependant, 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, il est conseillé d'utiliser 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 High Performance Switch, si vous utilisez Dispatcher et les machines serveurs TCP comme noeuds sur une Frame 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 machine Dispatcher transmettra alors les demandes aux machines serveurs TCP par l'intermédiaire du réseau privé.
Windows 2000 : Exécutez la commande suivante :
dsconfig en1 10.0.0.x netmask 255.255.255.0en1 est le nom de la deuxième carte installée sur la machine Dispatcher, 10.0.0.x est l'adresse de réseau de la deuxième carte, et 255.255.255.0 est le masque de réseau du réseau privé.
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_grappe:80:10.0.0.1
et non
dscontrol server add adresse_grappe: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'une grappe 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 de la grappe à s'adapter à plusieurs adresses IP (c'est-à-dire à fonctionner comme un "joker"). L'adresse de grappe 0.0.0.0 est utilisé pour spécifier une grappe générique.
Si vous devez assurer l'équilibrage de plusieurs adresses de grappe ayant des configurations port/serveur identiques, vous pouvez combiner toutes les grappes dans une seule configuration de grappe générique.
Vous devez toujours configurer de manière explicite chaque adresse de grappe sur les cartes réseau de votre poste Dispatcher. Toutefois, vous ne devez ajouter aucune des adresses de grappe à la configuration de Dispatcher à l'aide de la commande dscontrol cluster add.
Ajoutez simplement la grappe 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 sera équilibré en utilisant la configuration de la grappe générique.
L'avantage de cette approche réside dans le fait que le trafic vers toutes les adresses de grappes est pris en compte lors du choix du meilleur serveur. Si une grappe est particulièrement chargée et qu'elle a créé de nombreuses connexions sur l'un des serveurs, le trafic vers les autres adresses de grappes sera équilibré en tenant compte de cette information.
Vous pouvez combiner la grappe générique avec des grappes réelles si certaines adresses de grappes 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 grappe réelle. Toutes les configurations communes peuvent être attribuée à la grappe générique.
L'utilisation de la grappe 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 une grappe générique.
Vous pouvez utiliser la grappe 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 le répartiteur configuré comme route par défaut, le trafic TCP ou UDP passant par le poste répartiteur est équilibré en utilisant la configuration de la grappe 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 postes répartiteurs doivent utiliser la grappe 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 de la grappe 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 une grappe générique.
La fonction de grappe 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 poste 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 une grappe générique (0.0.0.0). Dans la grappe générique, vous configurez le port 80. Dans le port 80, vous configurez l'adresse NFA de la machine Dispatcher en tant que serveur unique. Désormais, tout trafic client vers une adresse du port 80 sera acheminé vers le serveur Caching Proxy exécuté sur le poste de travail Dispatcher. La demande client est ensuite traitée par un proxy 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, vous garantissez que toutes les demandes en direction de ce port non configuré seront 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 grappe:0
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 exit 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 la grappe 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 appel d'un script d'alerte (halfOpenAlert) est effectué. 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 grappe: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 grappes et des ports génériques. En particulier, ajoutez sous chaque grappe configurée un port générique sans serveur. Ajoutez également une grappe générique dotée 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 à une grappe ni à un port non génériques. Pour obtenir des informations sur les grappes et les ports génériques, reportez-vous aux sections Utilisation d'une grappe générique pour combiner les configurations serveurs et Utilisation du port générique pour acheminer le trafic destiné à un port non configuré.
La fonction de consignation binaire permet de stocker les informations du serveur dans des fichiers binaires. Ces fichiers peuvent ensuite être traités pour analyser les informations relatives aux serveurs qui ont été rassemblées.
Les informations suivantes sont stockées dans le journal binaire pour chaque serveur défini dans la configuration.
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 seront é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 seront 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 seront 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 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) :
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.)
Le présent chapitre contient les sections suivantes :
Cisco CSS Controller ou Nortel Alteon Controller peut se trouver sur la même machine qu'un serveur pour lequel vous équilibrez la charge des demande. On parle alors de co-implantation d'un serveur. Aucune configuration supplémentaire n'est requise.
La fonction haute disponibilité est désormais disponible pour Cisco CSS Controller et pour Nortel Alteon Controller.
Pour une meilleure tolérance aux pannes du contrôleur, la haute disponibilité intègre les fonctions suivantes :
Pour la syntaxe complète de xxxcontrol highavailability, reportez-vous aux sections ccocontrol highavailability -- Contrôle de la haute disponibilité et nalcontrol highavailability -- Contrôle de la haute disponibilité.
Pour configurer la haute disponibilité du contrôleur, procédez comme suit :
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role 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 exemple de configuration haute disponibilité Cisco CSS Controller, reportez-vous à la section Exemples.
Pour des exemple de configuration haute disponibilité Nortel Alteon Controller, reportez-vous à la section Exemples.
La fonction contrôleur de Load Balancer effectue l'équilibrage de charge en fonction des paramètres suivants :
Tous ces paramètres peuvent être modifiés en vue d'optimiser l'équilibrage de la charge du réseau.
Le contrôleur peut utiliser certains ou l'ensembles de collecteurs de mesures suivants pour les décisions de pondération :
Les mesures par défaut sont activeconn (connexions actives) et connrate (débit de la connexion).
Vous pouvez modifier le niveau d'importance relatif des valeurs de mesure. Les proportions sont des pourcentages ; la somme des proportions est égale à 100%. Les valeurs relatives aux connexions actives et au débit de la connexion sont utilisées par défaut et leurs proportions fixées à 50/50. Dans votre environnement,vous serez amené à essayer différentes combinaisons de proportions pour déterminer celui qui offre les meilleures performances.
Pour définir les valeurs de niveau d'importance, procédez comme suit :
Les pondérations sont définies en fonction du temps de réponse et de la disponibilité de l'application, du retour d'informations des conseillers et du retour d'informations procuré par un programme de contrôle système, tel que Metric Server. Si vous voulez définir des pondérations manuellement, indiquez l'option fixedweight pour le serveur. Pour obtenir une description de l'option fixedweight, reportez-vous à la section 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 seront réparties entre les serveurs selon la pondération relative de chacun. Par exemple, si un serveur a une pondération (paramètre Weight) de 10 et un autre de 5, le premier recevra deux fois plus de demandes que le second.
Si un conseiller détecte la défaillance d'un serveur, il attribue au serveur une pondération de -1. Pour Cisco CSS Controller et Nortel Alteon Controller le commutateur est informé que le serveur n'est pas disponible et le commutateur n'affecte plus de connexions au serveur.
Sans le contrôleur, les conseillers ne peuvent s'exécuter ni détecter les pannes de serveur. Si vous choisissez de lancer les conseillers mais ne voulez pas que le contrôleur mette à jour la pondération que vous avez fixée pour un serveur particulier, utilisez l'option fixedweight de la commande ccocontrol service pour Cisco CSS Controller ou de la commande nalcontrol server pour Nortel Alteon Controller.
La commande fixedweight vous permet d'affecter à la pondération la valeur souhaitée. La valeur de pondération du serveur reste fixe tant que le contrôleur est en activité à moins que vous n'émettiez une autre commande en attribuant la valeur no à l'option fixedweight.
Pour optimiser les performances globales, vous pouvez réduire la fréquence de collecte des mesures.
Le délai d'inactivité du consultant indique à quelle fréquence le consultant met à jour les pondérations des serveurs. Si le délai d'inactivité du consultant est trop court, le consultant interrompra constamment le commutateur et les performances déclineront. En revanche, s'il est trop long, l'équilibrage de charge du commutateur reposera sur des informations anciennes et incertaines.
Pour fixer le délai d'inactivité du consultant à 1 seconde, par exemple, entrez la commande suivante :
xxxcontrol consultant set IDconsultant sleeptime intervalle
D'autres méthodes d'optimisation de l'équilibrage de charge des serveurs sont disponibles. Pour fonctionner en vitesse maximale, les pondérations des serveurs ne sont actualisées que si les pondérations ont évolué de manière significative. La mise à jour constante des pondérations pour un écart mineur de l'état des serveurs induirait un surcroît d'activité injustifié. Lorsque, pour tous les serveurs d'un service donné, l'écart en pourcentage de la pondération totale dépasse le seuil de sensibilité, les pondérations qu'utilise Load Balancer pour répartir les connexions sont réactualisées. Supposons par exemple que la pondération totale passe de 100 à 105. L'écart est de 5%. Avec un seuil de sensibilité par défaut de 5, les pondérations qu'utilise Load Balancer ne sont pas mises à jour, car l'écart en pourcentage n'est pas supérieur au seuil. Si, en revanche la pondération totale passe de 100 à 106, les pondérations sont mises à jour. Pour attribuer au seuil de sensibilité du consultant une valeur autre que la valeur par défaut, entrez la commande suivante :
xxxcontrol consultant set 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, entrez la commande suivante :
xxxcontrol metriccollector set IDconsultant:HTTP sleeptime 3
Vous pouvez définir le temps nécessaire à un conseiller pour détecter qu'un port particulier d'un serveur ou d'un service est défaillant. Les valeurs de délai d'erreur serveur (connecttimeout et receivetimeout) déterminent la durée attendue par un conseiller avant de signaler qu'une connexion ou une réception n'a pas abouti.
Pour obtenir une détection d'erreur serveur très rapide, attribuez la valeur la plus basse (une seconde) aux délais de connexion et de réception du conseiller et attribuez la valeur la plus basse (une seconde) au délai d'inactivité du conseiller et du consultant.
Pour attribuer, par exemple, la valeur 9 secondes à timeoutconnect pour le conseiller HTTP, entrez la commande suivante :
xxxcontrol metriccollector set IDconsultant:HTTP timeoutconnect 9
La valeur par défaut de connexion et de réception est trois fois supérieure à la valeur indiquée pour le délai d'inactivité du conseiller.
Les conseillers peuvent essayer de nouveau d'établir une connexion avant de marquer un serveur comme arrêté. Le serveur ne signale un serveur comme étant arrêté qu'après avoir effectué le nombre de tentatives de connexion fixé plus une. Si ce nombre n'a pas été défini, il est par défaut égal à zéro.
Pour le contrôleur CSS Cisco, fixez le nombre de tentatives à l'aide de la commande ccocontrol ownercontent set. Pour plus de détails, reportez-vous à la section 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 command nalcontrol service set. Pour plus de détails, reportez-vous à la section 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. Vous devez obtenir et installer un compilateur Java 1.3 pour votre machine. 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 2000, une commande de compilation peut avoir l'aspect suivant :
javac -classpath <rep_install>\lb\servers\lib\ibmnd.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.
La syntaxe est similaire pour AIX, Linux et Sun.
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 entrez la commande suivante pour démarrer le conseiller personnalisé :
où :
Comme tous les conseillers, un conseiller personnalisé étend la fonction de la base du conseiller, intitulée ADV_Base. En fait, c'est la base du conseiller qui effectue la plupart des fonctions du conseiller, telles que la communication des charges au consultant afin que ces dernières soient utilisées dans l'algorithme de pondération du consultant. La base du conseiller effectue également les opérations de connexion et de fermeture de la connexion et fournit des méthodes d'envoi et de réception qui seront utilisées par le conseiller. Le conseiller n'est lui-même utilisé que pour l'envoi de données vers le port du serveur conseillé et pour la réception de données sur ce dernier. Les méthodes TCP de la base du conseiller sont programmées pour calculer la charge. Un indicateur du constructeur de ADV_base remplace, si vous le souhaitez, la charge existante par la nouvelle charge renvoyée par le conseiller.
Ci-dessous, sont énumérées les méthodes de classe de base.
Les contrôleurs consultent d'abord la liste fournie de conseillers natifs. S'ils n'y trouvent pas le conseiller recherché, ils consultent la liste des conseillers personnalisés.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Program Files\IBM\edge\lb\servers\lib\CustomAdvisors
Un programme permettant de créer un conseiller de contrôleur type est présenté à la section Conseiller type. Après installation, ce conseiller exemple se trouve dans le répertoire ...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 du serveur. 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 périphérique 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 Windows 2000, 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 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 OTHER_ADDRESS .
Sous Windows 2000, 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. Ces chiffres représentent la capacité encore disponible et que le consultant attend des valeurs représentant la charge sur chaque machine, le conseiller inverse et normalise les chiffres relatifs à la capacité pour obtenir des valeurs de charge (ainsi, des chiffres de capacité élevés correspondent à des valeurs de charge faibles et représentent un serveur en bon état). Il existe plusieurs différences importantes entre le conseiller WLM et les autres conseillers contrôleur :
La fonction de consignation binaire permet de stocker les informations du serveur dans des fichiers binaires. Ces fichiers peuvent ensuite être traités pour analyser les informations relatives aux serveurs qui ont été rassemblées.
Les informations suivantes sont stockées dans le journal binaire pour chaque serveur défini dans la configuration.
Le consultant doit s'exécuter pour consigner des informations dans les journaux binaires.
Utilisez l'ensemble de commandes xxxcontrol consultant binarylog pour configurer la consignation binaire.
L'option start commencer à consigner les informations relatives au serveur dans les journaux binaires du répertoire logs. Un journal est créé au début de chaque heure, la date et l'heure constituant le nom du fichier.
L'option stop arrête la consignation des informations relatives au serveur dans les journaux binaires. Le service de consignation est arrêté par défaut.
L'option set interval contrôle la fréquence d'inscription des informations dans les journaux. Le consultant enverra les informations du serveur au serveur de consignation à chaque intervalle défini pour le consultant. Les informations sont écrites dans les journaux uniquement si l'intervalle de consignation indiqué a expiré depuis l'écriture du dernier enregistrement dans le journal. Par défaut, la valeur de l'intervalle de consignation est 60 secondes.
Il y a interaction entre les paramètres relatifs à l'intervalle défini pour le consultant et l'intervalle de consignation. Comme les informations ne sont pas fournies au serveur de consignation plus fréquemment que l'intervalle défini pour le consultant, l'indication d'un intervalle de consignation inférieur à l'intervalle du consultant, entraîne en réalité la définition d'un intervalle de consignation identique à l'intervalle du consultant.
Cette technique de consignation permet d'accéder aux informations du serveur quel que soit le niveau de granularité. Vous pouvez connaître toutes les modifications apportées au serveur qui sont vues par le consultant pour le calcul des pondérations du serveur. Cependant, ces informations peuvent ne pas être requises pour analyser l'utilisation et les tendances du serveur. La consignation des informations du serveur toutes les 60 secondes permet d'obtenir un aperçu de la progression des informations du serveur. La définition d'un intervalle de consignation très faible peut générer un nombre de données très important.
L'option set retention permet de contrôler la durée de conservation des fichiers journaux. Les journaux dont la durée de vie a dépassé la durée définie sont supprimés par le serveur de consignation. Ceci ne se produit que si le consultant appelle le serveur de consignation, de sorte que si vous arrêtez le consultant, les anciens fichiers journaux ne sont pas supprimés.
Un exemple de programme Java et un fichier de commandes sont fournis dans le répertoire ...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. la séquence d'authentification 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 éloignés 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 éloignée.
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 éloignés 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 éloigné 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 via 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 :
Systèmes d'exploitation basés sous 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/*
Windows 2000 --
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 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 éloigné à 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 éloigné :
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 éloignés, vous devez régénérer la configuration pour, par exemple, visualiser la grappe, 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. 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é.
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.
AIX, 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/
Windows 2000 : Le fichier dsserver se trouve dans le répertoire système de Windows 2000, généralement C:\WINNT\SYSTEM32. 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. Reportez-vous à la section 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.
AIX, 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/
Windows 2000 : Le fichier xxxserver se trouve dans le répertoire système de Windows 2000, 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. Reportez-vous à la section 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 sera 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, de la grappe et du port. Au niveau de l'exécuteur et de la grappe, 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 n'est pas 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 par le collecteur de données obsolètes intégré à l'exécuteur.
Vous pouvez utiliser le délai d'expiration et le décompte FIN pour définir la fréquence à laquelle l'exécuteur collectera les données obsolètes et l'étendue de cette opération. L'exécuteur contrôle périodiquement la liste des connexions accordées. Lorsque le nombre de connexions à l'état FIN devient supérieur ou égal au décompte FIN, l'exécuteur tente de libérer la mémoire ayant servi au stockage des informations de connexion. Vous pouvez modifier la valeur du décompte FIN en entrant la commande dscontrol executor set fincount.
Le collecteur de données obsolètes libère la mémoire utilisée par toute connexion affichant l'état FIN et dont la durée excède le nombre de secondes spécifié par le délai d'expiration FIN. Vous pouvez modifier la valeur du délai d'expiration FIN en entrant la commande dscontrol executor set fintimeout.
La valeur du délai d'attente correspond au nombre de secondes durant lesquelles il peut n'y avoir aucune activité sur une connexion avant que cette dernière ne soit retirée. Pour plus d'informations, reportez-vous à la section Utilisation de la valeur du délai d'attente. La valeur du décompte FIN détermine également la fréquence selon laquelle les connexions "bloquées" sont supprimées. Si votre machine Dispatcher dispose de peu de mémoire, spécifiez un décompte FIN raisonnable. Si votre site WEB connaît un trafic important, spécifiez une valeur plus élevée.
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 la ligne 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. Ceci vous permet d'utiliser un système de gestion de réseau tel que -- Tivoli NetView, Tivoli Distributed Monitoring ou HP OpenView -- afin de 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 (Distributed Program Interface). Il s'agit d'une interface entre un agent SNMP et les sous-agents de ce dernier. Windows 2000 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 AIX et Solaris
AIX fournit un agent SNMP qui utilise le protocole SNMP Multiplexer (SMUX) et fournit DPID2, qui est un exécutable supplémentaire fonctionnant comme traducteur entre DPI et SMUX.
Linux fournit un agent SNMP qui utilise SMUX. La plupart des versions Linux (par exemple, Red Hat) sont livrées avec un module UCD SNMP. UCD SNMP version 4.1 ou ultérieure dispose d'agents SMUX actifs. Load Balancer fournit DPID2 pour Linux.
Pour SuSE Linux, vous devez obtenir un agent SNMP fonctionnant avec SMUX car SuSE n'en fournit pas.
Pour Solaris, vous devez obtenir un agent SNMP fonctionnant avec SMUX car Solaris n'en fournit pas. Load Balancer fournit DPID2 pour 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 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 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 SuSE Linux :
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, procédez aux opérations ci-dessous.
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 de système d'exploitation Windows et l'agent SNMP.
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 csID (ID grappe), 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 de grappe) et psNum (numéro de 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 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, reportez-vous à la section dscontrol subagent -- Configuration du sous-agent SNMP.
Le pare-feu ipchains est intégré au noyau de Linux. Lors de l'exécution simultanée de Load Balancer et de ipchains, Load Balancer voit le paquets avant ipchains. Vous pouvez ainsi utiliser ipchains pour renforcer un dispositif Load Balancer Linux tel qu'un dispositif Load Balancer servant à 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 dispositifs Load Balancer consiste à refuser tout type de trafic, sauf celui à destination et provenant des serveurs périphériques, du 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 sur les versions de noyau Linux prises en charge, reportez-vous à la section Configuration requise pour Red Hat Linux, SuSE Linux ou SuSE SLES Linux.
La présente section explique comment utiliser le composant CBR de Load Balancer.
CBR et Caching Proxy gèrent conjointement les demandes HTTP et HTTPS (SSL) via l'interface API du module d'extension 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, reportez-vous à la section 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'information, reportez-vous à la section 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 employés par Cisco CSS Controller sont similaires à ceux utilisés dans Dispatcher. Pour plus d'information, reportez-vous à la section Utilisation des journaux Load Balancer.
Une fois Nortel Alteon Controller démarré, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux employés de Nortel Alteon Controller sont similaires à ceux de Dispatcher. Pour plus d'information, reportez-vous à la section 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.
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 plateformes Unix : /opt/ibm/edge/lb/servers/bin/
Sous Windows 2000 : 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 :
Sur les plateformes AIX, Linux et Solaris : /opt/ibm/edge/lb/ lbpmr.tar.Z
Sous Windows 2000 : C:\Program Files\IBM\edge\lb\lbpmr.zip
Avant d'appeler le service d'assistance IBM, regroupez les information 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
Sous AIX, Linux et Solaris : netstat -ni
Sous Windows 2000 : ipconfig /all
Commande requise à partir de tous les serveurs et de Load Balancer.
Sous AIX, Linux et Solaris : netstat -nr
Sous Windows 2000 : 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.
Plateformes AIX, Linux et Solaris : /opt/ibm/edge/lb/servers/bin
Windows 2000 : 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. Pour plus de détails, reportez-vous à la section 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 grappe:port niveau_journal
ou
nalcontrol metriccollector set IDconsultant:IDservice:NomSystemMetric niveau_journalvaleur
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, Linux et Solaris : /opt/ibm/edge/lb/servers/logs/ composant
Windows 2000 : 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
En cas d'incident lié au routage par contenu (CBR), regroupez les informations requises ci-après.
Plateformes AIX, Linux et Solaris : /etc/
Windows 2000 : C:\Program Files\IBM\edge\cp\etc\en_US\
Plateformes AIX, Linux et Solaris : /opt/ibm/edge/lb/servers/configurations/cbr
Windows 2000 : C:\Program Files\IBM\edge\lb\servers\configurations\cbr
Si vous n'arrivez pas à accéder à la grappe, il est possible que l'une des machines Load Balancer ou les deux ont attribué un alias à la grappe. Pour déterminer laquelle détient la grappe, procédez comme suit :
ping grappe arp -a
Sous AIX : netstat -ni
Sous Linux et Solaris : ifconfig -a
Sous Windows 2000 : ipconfig /all
Si vous n'obtenez pas de réponse à la commande ping, il est possible qu'aucune des machine n'ait attribué d'alias à l'adresse IP de la grappe 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é, émettez la commande suivante pour lancer une trace du trafic réseau :
iptrace -a -s adresse_IP_Client_EnEchec -d adresse_IP_grappe -b iptrace.trc
Exécutez la trace, recréez l'incident, puis tuez le processus.
snoop -v address_IP_client address_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, vérifiez les mises à jour :
ftp://ftp.software.ibm.com/ps/products/networkdispatcher/servicereleases
Pour mettre à niveau des versions Java pour Load Balancer reportez-vous au point 3.
Pour plus d'informations sur les sites Web du support, des notes techniques (conseils et astuces) et des pages Web de la bibliothèque, reportez-vous à la section Informations de référence.
Pour les opérations répertoriées, reportez-vous au tableau indiqué.
Tableau 14. Tableau de résolution des incidents de 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 est inopérante |
Impossible d'ajouter un signal de présence (Windows 2000) | L'adresse source n'est pas configurée sur un adaptateur | Incident : Impossible d'ajouter un signal de présence (Windows 2000) |
Le serveur ne livre pas les requêtes (Window) | 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 éloignées | 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 (Windows 2000) |
Connexion à une machine distante refusée | Une ancienne version des clés est encore utilisée | Incident : Connexion du répartiteur à une machine éloignée |
La commande dscontrol ou lbadmin n'a pas abouti, 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 trouver fichier...", lors de l'exécution de Netscape en tant que navigateur par défaut pour visualiser l'aide en ligne (Windows 2000) | Paramétrage incorrect pour l'association de fichier HTML | Incident : Affichage du message d'erreur "Fichier introuvable... lorsque vous tentez de visualiser l'aide en ligne (Windows 2000) |
"stty: : No such device or address" (aucun périphérique ou adresse de ce type) lors du lancement de dsserver sous Solaris 2.7. | Ignorez ce message d'erreur. Il ne s'agit pas d'un problème. dsserver s'exécute correctement | Incident : Message d'erreur incorrect lors du lancement de dsserver sous Solaris 2.7 |
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é | Dépendance de fichiers 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 s'affiche pas correctement |
Les panneaux d'aide apparaissent parfois sous d'autres fenêtres | Limite Java | Incident : Sous Windows 2000, les fenêtre d'aide disparaissent parfois sous d'autres fenêtres ouvertes |
Load Balancer ne peut pas traiter et transmettre de cadre | Une adresse MAC unique est nécessaire pour chaque carte NIC | Incident: Load Balancer ne peut pas traiter et transmettre un cadre |
Un écran bleu apparaît | Aucune carte réseau n'est installée et configurée | Incident : Un écran bleu s'affiche lors du démarrage de l'exécuteur Load Balancer |
La fonction Path MTU Discovery permet d'éviter le trafic retour | La grappe est associée à un alias sur le dispositif de bouclage | Incident : La fonction Path MTU Discovery permet d'éviter le trafic retour avec Load Balancer |
Les conseillers indiquent que tous les serveurs sont en panne | Calcul incorrect du total de contrôle TCP | Incident : Les conseillers indiquent que tous les serveurs sont en panne |
La fonction haute disponibilité de Load Balancer en mode réseau étendu est inopérante | La machine Dispatcher éloignée doit être définie en tant que serveur d'une grappe sur la machine Dispatcher 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 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 |
Sous Windows : écran bleu ou conseiller Load Balancer signalant par erreur des charges "-1" | Utilisation de la carte de réseau Ethernet 3Com 985B gigabit | Incident : Sous Windows, écran bleu ou conseiller signalant par erreur des charges -1 |
Dans les versions Solaris localisées, les boutons Oui et Non de l'interface graphique s'affichent en français | Incident connu pris en compte par Sun Microsystems | Incident : Sous Solaris NLV, les boutons Oui et Non s'affichent en français |
L'administration (lbadmin) de Load Balancer se déconnecte du serveur après mise à jour de la configuration | lbadmin ou dscontrol peuvent être d'une autre version que dsserver | Incident : lbadmin se déconnecte du serveur après mise à jour de la configuration |
Adresses IP non résolues correctement sur la connexion éloignée | Lors de l'utilisation d'un client éloigné sur une implémentation SSL, des noms d'hôtes ou des noms de domaines complets ne sont pas correctement convertis en adresses IP en notation décimale à point | Incident : Adresses IP non résolues correctement sur la connexion éloignée |
L'interface coréenne de Load Balancer affiche sous AIX et Linux des polices non souhaitées ou qui se chevauchent | Vous devez modifier les polices de caractères par défaut | Incident : L'interface coréenne de Load Balancer affiche sous AIX et Linux des polices non souhaitées ou qui se chevauchent |
Sous Windows, lorsqu'un alias a été attribué à l'adaptateur 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 2000 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 2000, 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 ibmnd" sous Linux | Incident lors du retrait manuel du noyau du module Load Balancer (ibmnd). | Incident : Comportement inattendu lors de l'exécution de rmmod ibmnd (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 machine Dispatcher |
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 de la grappe | Incident : Le conseiller SSL ou HTTPS n'enregistre pas les charges des serveurs (avec l'acheminement MAC) |
Incident lors du chargement de configurations volumineuses à l'aide de lbwebaccess (administration Web) ou de lbadmin | Cet incident peut être lié au fait que le nombre maximum de segments de mémoire dynamique Java doit être augmenté | Incident : Difficulté à charger les configurations importantes (à l'aide de lbadmin, administration Web) |
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 les 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 2000, 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 la ligne de commande |
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères | Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape | Incident : Sur les plateformes Unix utilisant InfoCenter, le navigateur Netscape affiche le texte de l'aide en ligne en petits caractères |
Tableau 15. Tableau de résolution des incidents de CBR
Symptôme | Cause possible | Reportez-vous à la section. |
CBR ne fonctionne pas correctement | Conflit de numéros de port | Vérification des numéros de port CBR |
La commande cbrcontrol ou lbadmin n'a pas abouti, 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 : La commande cbrcontrol ou lbadmin n'a pas abouti |
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 de démarrage de l'exécuteur affiche le message 'Erreur: l'exécuteur n'a pas été lancé' lorsqu'elle échoue. | La commande peut échouer lorsqu'une modification des valeurs IPC système par défaut est nécessaire | Incident : Sous Solaris, la commande cbrcontrol n'aboutit pas |
La règle d'URL ne fonctionne pas | Erreur de syntaxe ou de configuration | Incident : erreur de syntaxe ou de configuration |
Sous Windows : Ecran bleu (panne de protection générale) occasionnel ou conseiller Load Balancer signalant par erreur des charges "-1" | Utilisation de la carte de réseau Ethernet 3Com 985B gigabit | Incident : Sous Windows, écran bleu ou conseiller signalant par erreur des charges -1 |
Dans les versions Solaris localisées, les boutons Oui et Non de l'interface graphique s'affichent en français | Incident connu pris en compte par Sun Microsystems | Incident : Sous Solaris NLV, les boutons Oui et Non s'affichent en français |
Comportement inattendu de l'interface graphique lors de l'utilisation de Windows 2000 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 2000, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP |
Incident lors du chargement de configurations volumineuses à l'aide de lbwebaccess (administration Web) ou de lbadmin | Cet incident peut être lié au fait que le nombre maximum de segments de mémoire dynamique Java doit être augmenté | Incident : Difficulté à charger les configurations importantes (à l'aide de lbadmin, administration Web) |
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 2000, 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 la ligne de commande |
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères | Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape | Incident : Sur les plateformes Unix utilisant InfoCenter, le navigateur Netscape affiche le texte de l'aide en ligne en petits caractères |
Tableau 16. Tableau de résolution des incidents de 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 à permutation circulaire à partir des clients Solaris |
La commande sscontrol ou lbadmin n'a pas abouti, 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 : la commande sscontrol ou lbadmin n'a pas abouti |
Echec du démarrage de ssserver sous Windows 2000 | Windows ne nécessite pas la présence du nom d'hôte dans le système DNS. | Incident : Echec du démarrage de ssserver sous Windows 2000 |
Machine ayant des chemins en double pour lequel l'équilibrage de charge ne s'effectue pas correctement -- la résolution de noms semble ne pas aboutir | Machine Site Selector ayant plusieurs cartes associées au même sous-réseau | Incident : Site Selector ayant des chemins en double pour lequel l'équilibrage de charge ne s'effectue pas correctement |
Sous Windows : Ecran bleu (panne de protection générale) occasionnel ou conseiller Load Balancer signalant par erreur des charges "-1" | Utilisation de la carte de réseau Ethernet 3Com 985B gigabit | Incident : Sous Windows, écran bleu ou conseiller signalant par erreur des charges -1 |
Dans les versions Solaris localisées, les boutons Oui et Non de l'interface graphique s'affichent en français | Incident connu pris en compte par Sun Microsystems | Incident : Sous Solaris NLV, les boutons Oui et Non s'affichent en français |
Comportement inattendu de l'interface graphique lors de l'utilisation de Windows 2000 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 2000, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP |
Incident lors du chargement de configurations volumineuses à l'aide de lbwebaccess (administration Web) ou de lbadmin | Cet incident peut être lié au fait que le nombre maximum de segments de mémoire dynamique Java doit être augmenté | Incident : Difficulté à charger les configurations importantes (à l'aide de lbadmin, administration Web) |
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 2000, 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 la ligne de commande |
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères | Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape | Incident : Sur les plateformes Unix utilisant InfoCenter, le navigateur Netscape affiche le texte de l'aide en ligne en petits caractères |
Tableau 17. Tableau de résolution des incidents de Contrôleur pour commutateurs Cisco CSS
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 |
La commande ccocontrol ou lbadmin n'a pas abouti, 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 : La commande ccocontrol ou lbadmin n'a pas abouti |
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 |
Dans les versions Solaris localisées, les boutons Oui et Non de l'interface graphique s'affichent en français | Incident connu pris en compte par Sun Microsystems | Incident : Sous Solaris NLV, les boutons Oui et Non s'affichent en français |
Comportement inattendu de l'interface graphique lors de l'utilisation de Windows 2000 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 2000, 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 de régénération n'a pas actualisé la configuration du consultant |
Incident lors du chargement de configurations volumineuses à l'aide de lbwebaccess (administration Web) ou de lbadmin | Cet incident peut être lié au fait que le nombre maximum de segments de mémoire dynamique Java doit être augmenté | Incident : Difficulté à charger les configurations importantes (à l'aide de lbadmin, administration Web) |
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 2000, 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 la ligne de commande |
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères | Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape | Incident : Sur les plateformes Unix utilisant InfoCenter, le navigateur Netscape affiche le texte de l'aide en ligne en petits caractères |
Tableau 18. Tableau de résolution des incidents de 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 |
La commande nalcontrol ou lbadmin n'a pas abouti, 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 : la commande nalcontrol ou lbadmin n'a pas abouti |
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 2000 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 2000, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP |
Incident lors du chargement de configurations volumineuses à l'aide de lbwebaccess (administration Web) ou de lbadmin | Cet incident peut être lié au fait que le nombre maximum de segments de mémoire dynamique Java doit être augmenté | Incident : Difficulté à charger les configurations importantes (à l'aide de lbadmin, administration Web) |
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 de régénération n'a pas actualisé la configuration du consultant |
Sous Windows 2000, 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 la ligne de commande |
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères | Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape | Incident : Sur les plateformes Unix utilisant InfoCenter, le navigateur Netscape affiche le texte de l'aide en ligne en petits caractères |
Tableau 19. Tableau de dépannage du système Metric Server
Symptôme | Cause possible | Voir... |
---|---|---|
IOException Metric Server sous Windows 2000 lors de l'exécution de fichiers de mesures utilisateur de format BAT ou CMD | Le nom complet des mesures est obligatoire | Incident : IOException Metric Server sous Windows 2000 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 la charge à 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 la machine Metric Server indique qu'une signature est nécessaire pour accéder à l'agent |
Sous AIX, lorsque Metric Server s'exécute dans des conditions difficiles sur un système 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é | Le correctif APAR IY33804 rectifie ce problème AIX identifié | Incident : Sous 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é |
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. Notez 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 modifier les numéros de port de Dispatcher ou modifier le numéro de port de l'application.
Pour modifier les numéros de port 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 modifier les numéros de port de CBR ou modifier le numéro de port de l'application.
Pour modifier les numéros de port 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. Prenez en compte le fait 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 modifier les numéros de port de Site Selector ou 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 qu'une autre application utilise l'un des numéros de port utilisés par le serveur lbcserver de Cisco CSS Controller. Prenez en compte le fait 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 modifier les numéros de port de Cisco CSS Controller ou modifier le numéro de port de l'application.
Pour modifier les numéros de port 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 qu'une autre application utilise l'un des numéros de port utilisés par le serveur nalserver de Nortel Alteon Controller. Prenez en compte le fait 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 modifier les numéros de port de Nortel Alteon Controller ou 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 peut se produire lorsqu'une autre application utilise l'un des ports utilisés par Dispatcher. Pour plus de détails, reportez-vous à la section 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.
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 :
Pour Windows et les autres plateformes, reportez-vous également à la section Configuration des serveurs pour l'équilibrage de la charge.
Cet incident se produit lorsqu'un environnement de haute disponibilité de Dispatcher est configuré et que les connexions 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 :
Cette erreur Windows 2000 se produit lorsque l'adresse source n'est pas configuré sur un adaptateur. Effectuez les contrôles suivants pour corriger ou diagnostiquer l'incident :
dsconfig tr0 <adresse IP> netmask <masque réseau> ou 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 le fonctionnement de Dispatcher. Reportez-vous à la section Configuration des serveurs pour l'équilibrage de la charge pour les contrôler et les supprimer.
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 éloignés. Reportez-vous à la section Utilisation de conseillers éloignés 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 sur la configuration d'un répertoire pour SSL, reportez-vous au manuel Microsoft Information and Peer Web Services Information and Planning Guide fourni avec Windows 2000. L'URL locale du document que vous pouvez consulter à l'aide d'un navigateur Web est la suivante : file:///C:/WINNT/system32/inetsrv/iisadmin/htmldocs/inetdocs.htm .
Dispatcher utilise des clés pour vous permettre de vous connecter à une machine éloignée 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 éloignée et qu'elles indiquent des ports RMI différents, la ligne 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 vous émettez des commandes dscontrol alors que Load Balancer s'exécute sur la même machine qu'un pare-feu, des erreurs de type Erreur : Pas de 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é, relancez 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.
Sous Windows 2000, lorsque vous utilisez Netscape comme navigateur par défaut, le message d'erreur s'affiche si cet incident se produite : "Impossible trouver fichier '<nomfichier>.html' (ou 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 :
Lors du lancement de dsserver sous Solaris 2.7, le message d'erreur incorrect suivant s'affiche : "stty: : No such device or address." (aucun périphérique ou adresse de ce type). Ignorez ce message d'erreur. dsserver s'exécute correctement.
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 que vous obtenez une erreur lorsque vous tentez de lancer le composant Dispatcher, vérifiez si Caching Proxy est installé. Caching Proxy est lié à un des fichiers Dispatcher. Ce fichier sera désinstallé lors de la désinstallation de Caching Proxy.
Pour résoudre ce problème :
Si des incidents se produisent relatifs à l'apparence de l'interface graphique de Load Balancer, 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.
Lorsque vous ouvrez des fenêtres d'aide sous Windows 2000, elles peuvent 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 désignées pour Load Balancer, comme il est configuré dans le fichier ibmnd.conf et si la carte NIC qui n'est pas définie dans ibmnd.conf reçoit un cadre, Load Balancer ne peut pas traiter et 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 adrMac
Par exemple :
ifconfig hme0 ether 01:02:03:04:05:06
Sous Windows 2000, 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 de la grappe à un alias sur le dispositif de bouclage. Si l'adresse de la passerelle pour la route entre dans le sous-réseau de la grappe ou du masque réseau, AIX crée la route sur le dispositif 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, soient la grappe 9.37.54.69, le masque réseau 255.255.255.0 et la passerelle prévue 9.37.54.1. Dans ce cas, AIX utilise le dispositif 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 de la grappe, puis il ne reçoit plus rien lorsque la route est créée.
Deux solutions permettent de pallier cet incident :
Remarques :
Windows 2000 comporte une nouvelle fonction, Task Offload, qui permet le calcul du total de contrôle TCP par la carte adaptateur, plutôt que par le système d'exploitation. Cette fonction améliore les performances dans le système. Lorsque Task Offload est activé, les conseillers Load Balancer signalent que les serveurs sont en panne, alors qu'ils ne le sont pas.
La cause de l'incident est la suivante : le total de contrôle TCP n'est pas calculé correctement pour les paquets provenant de l'adresse de grappe. C'est le cas avec le trafic des conseillers.
Pour éviter cet incident, atteignez les paramètres de la carte et désactivez la fonction Task Offload.
Cet incident a été observé pour la première fois avec la carte Adaptec QuadPort ANA62044. Cette carte désigne la fonction comme option de déchargement Transmit Checksum. Désactivez cette option pour éviter l'incident.
Lorsque vous configurez un mode WAND (Wide Area Load Balancer), vous devez définir la machine Dispatcher locale en tant que serveur d'une grappe sur la machine Dispatcher locale. Habituellement, vous utilisez l'adresse de non-réacheminement (NFA) de la machine Dispatcher éloignée pour l'adresse de destination du serveur éloigné. Dans ce cas, si vous configurez ensuite sur la machine Dispatcher éloignée la fonction haute disponibilité, celle-ci reste inopérante. La cause en est la suivante : la machine Dispatcher locale désigne toujours la machine principale côté éloigné lorsque vous utilisez l'adresse NFA.
Pour éviter cet incident :
Lorsque la machine Dispatcher principale éloignée 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.
Lorsque vous tentez de 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 présenter 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 AIX, modifiez "java" en "java -Xmxn") :
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH% %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
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 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
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.
Vous pouvez être confronté à ce type d'incident lorsque vous utilisez une carte réseau Ethernet 3Com 985B gigabit sous Windows 2000 :
Pour éviter ce type d'incident, utilisez une carte réseau Ethernet gigabit d'un autre fabricant.
Les boutons Oui et Non de l'interface graphique de Load Balancer peuvent s'afficher en français dans les versions Solaris localisées. Cet incident connu pris en compte par Sun Microsystems.
Si l'administration (lbadmin) de Load Balancer se déconnecte du serveur après mise à jour de la configuration, vérifiez quelle version de dsserver vous essayez de configurer sur le serveur et vérifiez qu'il s'agit de la même version que celle de lbadmin ou dscontrol.
Lorsqu'un client éloigné 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 en notation décimale à point. 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 éloignée, nous vous suggérons d'indiquer l'adresse IP en notation décimale à point.
Pour rectifier les problèmes de chevauchement de polices ou de polices indésirables sur l'interface Load Balancer coréenne, procédez comme suit :
Sous AIX
-Monotype-TimesNewRomanWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
Sous 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'adaptateur 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 accédée avant l'alias de bouclage.
Pour consulter la liste des connexions réseau, procédez comme suit :
Sous Windows 2000, 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.
Sous Linux : Si dsserver est en cours d'exécution lors du retrait manuel du noyau du module Load Balancer, un comportement inattendu (un arrêt du système ou des noyaux Java, par exemple) 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. Par exemple :
ps-ef | grep SRV_KNDConfigServer
Une fois le processus Java terminé, vous pouvez en toute sécurité exécuter la commande "rmmod ibmnd" 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 de la grappe pour laquelle un alias a été défini sur le 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 de la grappe configurée sur le bouclage de façon à correspondre au contenu des paquets entrants. Si vous ne configurez pas l'application serveur avec l'adresse IP de la grappe, la demande client n'est pas correctement acheminée vers le serveur.
Si vous avez des difficultés à charger des configurations importantes à l'aide de lbadmin ou de l'administration à distance basée sur le Web, augmentez la taille maximale des segments Java. Par défaut, Java limite les segments de la machine virtuelle à 64 Mo. Certains programmes de configuration de Load Balancer (lbadmin, lbwebaccess) peuvent nécessiter plus de 64 Mo lorsqu'il s'agit d'administrer de très grosses configurations. pour régler ce problème, vous pouvez fixer la limite des segments Java au-delà de 64 Mo. Pour augmenter la taille des segments, utilisez l'option Java "-Xmx". Par exemple, dans le script lbadmin, modifiez "javaw" en "javaw -Xmx256m" pour passer la taille maximale des segments Java à 256 Mo. Si vous rencontrez ce problème avec l'administration Web, modifiez le script lbwebaccess comme indiqué ci-dessus.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) de la fenêtre du navigateur Netscape dans laquelle 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. Pour l'administration à distance basée sur le Web 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 2000, 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 une 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, émettez 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 disponible sur le site Web de Microsoft "Product Support Services". 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 2000, 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 :
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères. Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape.
Cet incident peut se produire lorsqu'une autre application utilise l'un des ports utilisés par CBR. Pour plus de détails, reportez-vous à la section 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 vous émettez des commandes cbrcontrol alors que Load Balancer s'exécute sur la même machine qu'un pare-feu, des erreurs de type Erreur : Pas de 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é, relancez 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.
Sous 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 de ce fichier, reportez-vous à la 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 :
Vous pouvez être confronté à ce type d'incident lorsque vous utilisez une carte réseau Ethernet 3Com 985B gigabit sous Windows 2000 :
Pour éviter ce type d'incident, utilisez une carte réseau Ethernet gigabit d'un autre fabricant.
Les boutons Oui et Non de l'interface graphique de Load Balancer peuvent s'afficher en français dans les versions Solaris localisées. Cet incident connu pris en compte par Sun Microsystems.
Sous Windows 2000, 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.
Si vous avez des difficultés à charger des configurations importantes à l'aide de lbadmin ou de l'administration à distance basée sur le Web, augmentez la taille maximale des segments Java. Par défaut, Java limite les segments de la machine virtuelle à 64 Mo. Certains programmes de configuration de Load Balancer (lbadmin, lbwebaccess) peuvent nécessiter plus de 64 Mo lorsqu'il s'agit d'administrer de très grosses configurations. pour régler ce problème, vous pouvez fixer la limite des segments Java au-delà de 64 Mo. Pour augmenter la taille des segments, utilisez l'option Java "-Xmx". Par exemple, dans le script lbadmin, modifiez "javaw" en "javaw -Xmx256m" pour passer la taille maximale des segments Java à 256 Mo. Si vous rencontrez ce problème avec l'administration Web, modifiez le script lbwebaccess comme indiqué ci-dessus.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) de la fenêtre du navigateur Netscape dans laquelle 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. Pour l'administration à distance basée sur le Web sur une plateforme Windows, utilisez Internet Explorer.
Dans une fenêtre de ligne de commande du système d'exploitation Windows 2000, 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 :
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères. Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape.
Cet incident peut se produire lorsqu'une autre application utilise un des ports utilisés par Site Selector. Pour plus de détails, reportez-vous à la section 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 sera 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 vous émettez des commandes sscontrol alors que Load Balancer s'exécute sur la même machine qu'un pare-feu, des erreurs de type Erreur : Pas de 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é, relancez 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. Windows ne nécessite 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.
Vous pouvez être confronté à ce type d'incident lorsque vous utilisez une carte réseau Ethernet 3Com 985B gigabit sous Windows 2000 :
Pour éviter ce type d'incident, utilisez une carte réseau Ethernet gigabit d'un autre fabricant.
Les boutons Oui et Non de l'interface graphique de Load Balancer peuvent s'afficher en français dans les versions Solaris localisées. Cet incident connu pris en compte par Sun Microsystems.
Sous Windows 2000, 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.
Si vous avez des difficultés à charger des configurations importantes à l'aide de lbadmin ou de l'administration à distance basée sur le Web, augmentez la taille maximale des segments Java. Par défaut, Java limite les segments de la machine virtuelle à 64 Mo. Certains programmes de configuration de Load Balancer (lbadmin, lbwebaccess) peuvent nécessiter plus de 64 Mo lorsqu'il s'agit d'administrer de très grosses configurations. pour régler ce problème, vous pouvez fixer la limite des segments Java au-delà de 64 Mo. Pour augmenter la taille des segments, utilisez l'option Java "-Xmx". Par exemple, dans le script lbadmin, modifiez "javaw" en "javaw -Xmx256m" pour passer la taille maximale des segments Java à 256 Mo. Si vous rencontrez ce problème avec l'administration Web, modifiez le script lbwebaccess comme indiqué ci-dessus.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) de la fenêtre du navigateur Netscape dans laquelle 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. Pour l'administration à distance basée sur le Web sur une plateforme Windows, utilisez Internet Explorer.
Dans une fenêtre de ligne de commande du système d'exploitation Windows 2000, 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 :
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères. Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape.
Cet incident peut se produire lorsqu'une autre application utilise un des ports employés par le serveur ccoserver de Cisco CSS Controller. Pour obtenir plus d'informations, reportez-vous à la section 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 vous émettez des commandes ccocontrol alors que Load Balancer s'exécute sur la même machine qu'un pare-feu, des erreurs de type Erreur : Pas de 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é, relancez 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 peut se produire 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 corriger ce problème :
Les boutons Oui et Non de l'interface graphique de Load Balancer peuvent s'afficher en français dans les versions Solaris localisées. Cet incident connu pris en compte par Sun Microsystems.
Sous Windows 2000, 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 corriger ce problème :
Pour corriger ce problème :
Augmentez le niveau de consignation du journal du consultant, puis relancez la commande. Si elle échoue de nouveau, recherchez dans le journal les délais d'expirations SNMP ou autres erreurs de communication SNMP.
Si vous avez des difficultés à charger des configurations importantes à l'aide de lbadmin ou de l'administration à distance basée sur le Web, augmentez la taille maximale des segments Java. Par défaut, Java limite les segments de la machine virtuelle à 64 Mo. Certains programmes de configuration de Load Balancer (lbadmin, lbwebaccess) peuvent nécessiter plus de 64 Mo lorsqu'il s'agit d'administrer de très grosses configurations. pour régler ce problème, vous pouvez fixer la limite des segments Java au-delà de 64 Mo. Pour augmenter la taille des segments, utilisez l'option Java "-Xmx". Par exemple, dans le script lbadmin, modifiez "javaw" en "javaw -Xmx256m" pour passer la taille maximale des segments Java à 256 Mo. Si vous rencontrez ce problème avec l'administration Web, modifiez le script lbwebaccess comme indiqué ci-dessus.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) de la fenêtre du navigateur Netscape dans laquelle 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. Pour l'administration à distance basée sur le Web sur une plateforme Windows, utilisez Internet Explorer.
Dans une fenêtre de ligne de commande du système d'exploitation Windows 2000, 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 :
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères. Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape.
Cet incident peut se produire lorsqu'une autre application utilise un des ports employés par le serveur nalserver de Nortel Alteon Controller. Pour plus d'informations, reportez-vous à la section 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 vous émettez des commandes nalcontrol alors que Load Balancer s'exécute sur la même machine qu'un pare-feu, des erreurs de type Erreur : Pas de 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é, relancez 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 peut se produire 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 corriger ce problème :
Sous Windows 2000, 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.
Si vous avez des difficultés à charger des configurations importantes à l'aide de lbadmin ou de l'administration à distance basée sur le Web, augmentez la taille maximale des segments Java. Par défaut, Java limite les segments de la machine virtuelle à 64 Mo. Certains programmes de configuration de Load Balancer (lbadmin, lbwebaccess) peuvent nécessiter plus de 64 Mo lorsqu'il s'agit d'administrer de très grosses configurations. pour régler ce problème, vous pouvez fixer la limite des segments Java au-delà de 64 Mo. Pour augmenter la taille des segments, utilisez l'option Java "-Xmx". Par exemple, dans le script lbadmin, modifiez "javaw" en "javaw -Xmx256m" pour passer la taille maximale des segments Java à 256 Mo. Si vous rencontrez ce problème avec l'administration Web, modifiez le script lbwebaccess comme indiqué ci-dessus.
Lorsque vous utilisez l'administration Web à distance pour configurer Load Balancer, ne modifiez pas la taille (Réduire, Agrandir, Restaurer en bas, etc.) de la fenêtre du navigateur Netscape dans laquelle 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. Pour l'administration à distance basée sur le Web 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 corriger ce problème :
Pour corriger ce problème :
Augmentez le niveau de consignation du journal du consultant, puis relancez 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 2000, 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 :
Sur les plateformes Unix qui utilisent le navigateur Netscape, le texte d'aide en ligne de l'InfoCenter s'affiche en petits caractères. Augmentez la taille de la police en modifiant les options de préférence du navigateur Netscape.
Vous devez utiliser le nom complet des mesures enregistrées par l'utilisateur sur les postes Metric Server Windows 2000. Par exemple, vous devez indiquer usermetric.bat, et non usermetric. Le nom usermetric est valide sur la ligne de commande, mais est inopérant lorsqu'il est employé à 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
Différentes raisons peuvent expliquer pourquoi le système Metric Server ne transmet pas les informations relatives à la charge à Load Balancer. Procédez aux vérifications suivantes pour en déterminer la cause :
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é. Par 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 ce correctif est disponible auprès du support AIX à l'adressehttp://techsupport.services.ibm.com/server/fixes ou auprès de votre revendeur AIX.
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_util et la variable facultative mot_de_passe. Remplacez les variables par vos propres valeurs.
>>-utilisateur--id_util--+--------------+---------------------->< '-mot_de_passe-'
Mots clés obligatoires : Les mots clés et les variables obligatoires apparaissent sur la ligne du chemin principal.
>>-mot_clé_obligatoire-----------------------------------------><
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.
>>-+-paramètre_1_obligatoire-+--------------------------------->< '-paramètre_2_obligatoire-'
Valeurs facultatives : Les mots clés et les variables facultatifs apparaissent sous la ligne du chemin principal.
>>-+---------+------------------------------------------------->< '-Mot clé-'
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.
>>-+-------------+--------------------------------------------->< +-paramètre_1-+ '-paramètre_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 grappe:port.
>>-grappe:port-------------------------------------------------><
La présente annexe décrit l'utilisation des commandes dscontrol de Dispatcher. Elle traite également les commandes pour CBR. CBR utilise un sous-ensemble de commandes Dispatcher. Pour de plus amples informations, reportez-vous à Différences de configuration entre CBR et Dispatcher.
Remarques :
Vous trouverez ci-dessous la liste des commandes décrites dans la présente annexe.
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, entrez exit ou quit.
L'interface de ligne de commande de CBR est en grande partie 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-+->< | '-grappe:port-' | +-interval--nom--+-port--------+--secondes-----------------------------+ | '-grappe:port-' | +-list-----------------------------------------------------------------+ +-loglevel--nom--+-port--------+--niveau-------------------------------+ | '-grappe:port-' | +-logsize--nom--+-port--------+--+-unlimited----------------+----------+ | '-grappe:port-' '-nombre d'enregistrements-' | +-receivetimeout--nom--+-port--------+--délai d'expiration en secondes-+ | '-grappe:port-' | +-report--nom--+-port--------+-----------------------------------------+ | '-grappe:port-' | +-tentatives--nom--+-port--------+--nbrtentatives----------------------+ | '-grappe:port-' | +-start--nom--+-port--------+--+-----------------+---------------------+ | '-grappe:port-' '-fichier journal-' | +-status--nom--+-port--------+-----------------------------------------+ | '-grappe:port-' | +-stop--nom--+-port--------+-------------------------------------------+ | '-grappe:port-' | +-timeout--nom--+-port--------+--+-unlimited-+-------------------------+ | '-grappe:port-' '-secondes--' | '-version--nom--+-port--------+----------------------------------------' '-grappe:port-'
Pour plus d'informations sur les conseillers que fournit Load Balancer, reportez-vous à la section 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, reportez-vous à la section Création de conseillers personnalisés.
La grappe correspond à l'adresse au format décimal à point 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 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | privé | 10,007 |
Le fichier par défaut se présente sous la forme nomconseiller_port.log, par exemple, http_80.log. Pour changer le répertoire dans lequel les fichiers journaux vont être stockés, reportez-vous à la section Modification des chemins des fichiers journaux. Les fichiers journaux par défaut des conseillers spécifiques de grappes (ou de sites) sont créés avec l'adresse de la grappe, 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 :
--------------------------------------- | CONSEILLER | GRAPPE:PORT | DELAI | --------------------------------------- | 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 :
Rapport du conseiller : --------------- Nom du conseiller ........ Ftp Numéro du port ........... 21 Adresse de grappe ........ 9.67.131.18 Adresse du serveur ....... 9.67.129.230 Charge ................... 8 Adresse de grappe ........ 9.67.131.18 Adresse du serveur ....... 9.67.131.215 Charge ................... -1
dscontrol advisor status http 80Cette commande génère des résultats similaires à l'exemple suivant :
Etat du conseiller (advisor) : --------------- Intervalle (secondes)........................ 7 Délai d'expiration (secondes) ............... Unlimited Délai d'expiration de connexion (secondes)... 21 Délai d'expiration de réception (secondes)... 21 Nom du fichier journal du conseiller ........ Http_80.log Niveau de consignation ...................... 1 Taille maximale du journal (octets) ......... Unlimited Nombre de tentatives ........................ 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--grappe--+-add--grappe+g2+...--+--------------------------------------------------------------------+-+->< | +-adresse--adresse---------------------------------------------------+ | | +-niveau d'importance des informations--activ.--nouv.--port--système-+ | | +-maxports--taille---------------------------------------------------+ | | +-maxservers--taille-------------------------------------------------+ | | +-stickytime--heure--------------------------------------------------+ | | +-weightbound--pondération-------------------------------------------+ | | +-porttype--type-----------------------------------------------------+ | | +-primaryhost--adresse-----------------------------------------------+ | | +-staletimeout--staletimeout (délai d'expiration)--------------------+ | | '-sharedbandwidth--taille--------------------------------------------' | +-set--grappe+g2+...--+-niveau d'importance des informations--activ.--nouv.--port--système-+-+ | +-maxports--taille---------------------------------------------------+ | | +-maxservers--taille-------------------------------------------------+ | | +-stickytime--heure--------------------------------------------------+ | | +-weightbound--pondération-------------------------------------------+ | | +-porttype--type-----------------------------------------------------+ | | +-primaryhost--adresse-----------------------------------------------+ | | +-staletimeout--staletimeout (délai d'expiration)--------------------+ | | '-sharedbandwidth--taille--------------------------------------------' | +-remove--grappe-----------------------------------------------------------------------------+ +-report--grappe-----------------------------------------------------------------------------+ '-status--grappe-----------------------------------------------------------------------------'
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 toutes les grappes.
Si vous modifiez l'hôte principal d'une grappe alors que les machines principale et de secours sont lancés et exécutés en haute disponibilité réciproque, vous devrez contraindre le nouvel hôte principal à prendre le relais. Vous devrez ensuite mettre à jour les scripts puis déconfigurer et reconfigurer la grappe correctement. Pour de plus amples informations, reportez-vous à 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 :
Etat de la grappe (cluster) : ---------------- Grappe ............................................... 9.67.131.167 Adresse .............................................. 9.67.131.167 Nombre de ports cibles ............................... 3 Délai de maintien de routage par défaut .............. 0 Délai d'expiration par défaut ........................ 30 Limite de pondération par défaut du port ............. 20 Nombre maximal de ports .............................. 8 Protocole du port par défaut ......................... tcp/udp Nombre maximal de serveurs par défaut ................ 32 Proportion accordée aux connexions actives ........... 0.5 Proportion accordée aux nouvelles connexions ........ 0.5 Proportion accordée aux connexions spécifiques du port 0 Proportion accordée aux mesures du système ........... 0 Largeur de bande partagée (Ko) ....................... 0 Adresse de l'hôte principal ........................... 9.67.131.167
>>-dscontrol--executor--+-report-----------------------------------------------------------------------+->< +-set--+-nfa--adresse IP---------------------------------+---------------------+ | +-maxclusters--taille-----------------------------+ | | +-maxports--taille--------------------------------+ | | +-décompte_fin--décompte_fin----------------------+ | | +-délai_fin--délai_fin----------------------------+ | | +-maxservers--taille------------------------------+ | | +-staletimeout--staletimeout (délai d'expiration)-+ | | +-stickytime--heure-------------------------------+ | | +-clientgateway--adresse--------------------------+ | | +-weightbound--pondération------------------------+ | | +-porttype--type----------------------------------+ | | +-wideportnumber--port----------------------------+ | | '-sharedbandwidth--taille-------------------------' | +-configuration--adresse_interface+i2+...--+---------------------------------+-+ | '-nom_interface--masque de réseau-' | +-unconfigure--adresse_interface-----------------------------------------------+ +-start------------------------------------------------------------------------+ +-status-----------------------------------------------------------------------+ '-stop-------------------------------------------------------------------------'
Exemples
dscontrol executor status Etat de l'exécuteur : ---------------- Adresse de non-réacheminement ................. 9.67.131.151 Adresse de la passerelle client ............... 0.0.0.0 Décompte FIN .................................. 4,000 Délai de maintien de l'état FIN ............... 60 Numéro de port du réseau étendu ............... 0 Largeur de bande partagée (Ko) ................ 0 Nombre maximal de ports par défaut par grappe . 8 Nombre maximal de grappes ..................... 100 Nombre maximal de serveurs par défaut par port 32 Délai d'attente par défaut ................... 300 Délai de maintien de routage par défaut ...... 0 Limite de pondération par défaut ............. 20 Type de port par défaut ...................... 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 fichier3 Le fichier (fichier3) est supprimé.
dscontrol file newload fichier1.sv Le fichier (fichier1.sv) a été chargé dans Dispatcher.
dscontrol file appendload fichier2.sv Le fichier (fichier2.sv) a été chargé et ajouté à la configuration actuelle.
dscontrol file report RAPPORT SUR LES FICHIERS : fichier1.sauv fichier2.sv fichier3
dscontrol file save fichier3 La configuration est sauvegardée dans fichier3.
>>-dscontrol--help--+-advisor----------+----------------------->< +-binlog-----------+ +-grappe-----------+ +-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 :
ARGUMENTS DE LA COMMANDE HELP : --------------------------------- Syntaxe : help <option> Exemple : help cluster help - Affichage des informations d'aide advisor - Aide sur la commande advisor cluster - Aide sur la commande cluster port - Aide sur la commande port executor - Aide sur la commande executor file - Aide sur la commande file host - Aide sur la commande host binlog - Aide sur la commande binary manager - Aide sur la commande manager metric - Aide sur la commande metric rule - Aide sur la commande rule server - Aide sur la commande server subagent - Aide sur la commande subagent set - Aide sur la commande set status - Aide sur la commande status logstatus - Aide sur la commande server log status highavailability - Aide sur la commande highavailabilityIl est à noter que les paramètres placés entre les signes <> sont des variables.
fintimeout <adresse de grappe>|all <heure> -Change FIN timeout (Utilisez "all" pour modifier toutes les grappes)
>>-dscontrol--highavailability--+-status--------------------------------------+->< +-backup--+-add--+-primary-+--+-auto---+--p-+-+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete--------------------------' | +-reach--+-add----+--adresse--masque----------+ | '-delete-' | +-heartbeat--+-add--adressesrc--adressedest-+-+ | '-delete--adresse--------------' | '-takeover--+---------+-----------------------' '-adresse-'
En outre, 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 :
Etat de la haute disponibilité : ------------------------- Rôle ........................principal Stratégie de récupération .. manuelle Etat ....................... Actif Sous-état.............. Synchronisé Hôte principal........... 9.67.131.151 Port .........................12345 Cible privilégiée....... 9.67.134.223 Etat du signal de présence : ----------------- Nombre ......................... 1 Source/destination ............. 9.67.131.151/9.67.134.223 Etat de l'accessibilité : -------------------- Nombre ................ 1 Adresse ............... 9.67.131.1 accessible
dscontrol highavailability backup add primary auto 80
dscontrol highavailability reach add 9.67.125.18
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.3
dscontrol highavailability takeover
>>-dscontrol--host:--hôte_éloigné------------------------------><
dscontrol host:remote_host
Après avoir tapé cette commande dans l'indicatif DOS, entrez toute commande dscontrol valide que vous désirez envoyer à la machine Load Balancer éloignée.
>>-dscontrol--logstatus----------------------------------------><
Exemples
Pour affichier 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--server--+-----+-----------------+ | '-now-' | +-reach set--+-interval--secondes-----+----+ | +-loglevel--niveau-------+ | | '-logsize--+-unlimited-+-' | | '-octets----' | +-refresh--cycle de mise à jour------------+ +-report--+---------------+----------------+ | '-grappe+g2+...-' | +-restart--message-------------------------+ +-sensitivity--pondération-----------------+ +-smoothing--indice de lissage-------------+ +-start--+-------------------------------+-+ | '-fichier journal--port_mesures-' | +-status-----------------------------------+ +-stop-------------------------------------+ +-unquiesce--server------------------------+ '-version----------------------------------'
Ou, si vous utilisez le partitionnement du serveur, entrez le nom unique du serveur logique. Pour de plus amples informations, reportez-vous à Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
Le fichier par défaut est installé dans le répertoire logs. Reportez-vous à l'Annexe C, Exemples de fichiers de configuration. Pour changer le répertoire dans lequel les fichiers journaux vont être stockés, reportez-vous à la section 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 :
-------------------------------------------------------------------- | SERVEUR | ADRESSE IP | ETAT | -------------------------------------------------------------------- | mach14.dmz.com | 10.6.21.14 | ACTIF | | mach15.dmz.com | 10.6.21.15 | ACTIF | -------------------------------------------------------------------- ----------------------------- | LEGENDE ETAT GESTIONNAIRE | ----------------------------- | ACTV | Connexions actives | | NEWC | Nouvelles connexions | | SYS | Mesure du système | | NOW | Pondération actuelle | | NEW | Nouvelle pondération | | WT | Pondération | | CONN | Connexions | ----------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | POND. | ACTV | NOUVC | PORT | SYS | | PORT: 21 |ACT NOUV| 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 | POND. | ACTV | NOUVC | PORT | SYS | | PORT: 80 |ACT NOUV| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | 23 | 0 | | mach15.dmz.com | 9 9 | 0 | 0 | 30 | 0 | ------------------------------------------------------------------- --------------------------------------------------- | CONSEILLER | GRAPPE:PORT | DELAI | --------------------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------------------
dscontrol manager restart Relance du gestionnaire pour mise à jour du codeCette commande génère des résultats similaires à l'exemple suivant :
320-14:04:54 Relance du gestionnaire pour mettre à jour le 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 :
Etat du gestionnaire : =============== Port de mesures.................................... 10004 Nom du fichier journal du gestionnaire............. manager.log Niveau de consignation du gestionnaire............. 1 Taille maxi du journal du gestionnaire (octets) ... unlimited Niveau de sensibilité.............................. 0.05 Indice de lissage.................................. 1.5 Intervalle de mise à jour (secondes)............... 2 Cycle de mise à jour des pondérations.............. 2 Niveau du journal de contacts...................... 1 Taille maximale du journal de contact (octets).... unlimited Intervalle de mise à jour des contacts (secondes). 7 Nom du fichier journal du contrôleur de mesures... MetricMonitor.log Niveau de consignation du contrôleur de mesures... 1 Taille maxi du journal du contr mesures (octets).. 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--grappe+c2+...+cN:mesure+mesure1+...+mesureN---------------------------------------+->< +-supprimer--grappe+c2+...+cN:mesure+mesure1+...+mesureN---------------------------------+ +-niveau d'importance des informations--grappe+c2+...+cN proportion1 prop2 prop3...propN-+ '-status--grappe+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 :
Etat des mesures : ------------ Grappe ........................ 10.10.10.20 Nom de la mesure .............. metric1 Proportion de la mesure ....... 50 Serveur ................... plm3 Données de mesure ......... -1
>>-dscontrol--port--+-add--grappe:port--+-------------------------------------------+-+->< | +-trans ports--autre port-------------------+ | | +-maxservers--taille------------------------+ | | +-stickymask--valeur------------------------+ | | +-stickytime--heure-------------------------+ | | +-method--type------------------------------+ | | +-staletimeout (délai d'expiration)--valeur-+ | | +-weightbound--pondération------------------+ | | +-porttype--type----------------------------+ | | +-protocole--type---------------------------+ | | '-reset--valeur-----------------------------' | +-set--grappe:port--+-trans ports--autre port--+------------------+ | +-maxservers--taille-------+ | | +-stickymask--valeur-------+ | | +-stickytime--heure--------+ | | +-staletimeout--valeur-----+ | | +-weightbound--pondération-+ | | +-porttype--type-----------+ | | +-maxhalfopen--valeur------+ | | '-reset--valeur------------' | +-remove--grappe:port---------------------------------------------+ +-report--grappe:port---------------------------------------------+ +-status--grappe:port---------------------------------------------+ '-halfopenaddressreport--grappe: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 de l'affinité trans ports, reportez-vous à Affinité trans ports.
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'il sera procédé à une vérification 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, reportez-vous à la section 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 :
Etat du port : ------------ Numéro du port ........................ 80 Grappe ................................ 9.67.131.153 Délai d'expiration .................... 300 Limite de pondération ................. 20 Nombre maximal de serveurs ............ 32 Délai de maintien de routage .......... 0 Type de port .......................... tcp/udp Affinité trans ports .................. 80 Bits du masque de rappel .............. 32 Nombre maximal de connexions partielles 0 Envoyer des réinitialisations TCP ..... no
dscontrol port report 9.62.130.157:80Cette commande génère des résultats similaires à l'exemple suivant :
Rapport du port : ------------ Adresse de grappe ..................... 9.62.130.157 Numéro du port ........................ 80 Nombre de serveurs .................... 5 Pondération maximale des serveurs ..... 10 Nombre total de connexions actives .... 55 Nombre de connexions par seconde ...... 12 Ko transférés par seconde ............. 298 Nombre de connexions partielles ....... 0 Réinitialisations TCP envoyées ........ 0 Méthode d'acheminement ................ acheminement MAC
dscontrol port halfopenaddressreport 9.67.127.121:80Cette commande génère des résultats similaires à l'exemple suivant :
Rapport - Connexions partielles créé : ------------ Rapport - Adresses avec connexions partielles pour grappe:port = 9.67.127.121:80 Rapport - Adresses avec connexions partielles pour grappe:port ... 0 Nombre total de connexions partielles consignées ................. 0 Plus grand nombre de connexions partielles consignées ............ 0 Nombre moyen de connexions partielles consignées ................. 0 Temps moyen de connexion partielle (en secondes) consignées ...... 0 Nombre total de connexions partielles reçues .................. 0
>>-dscontrol--rule--+-add--grappe:port:règle--type--type--| opts |-+->< +-dropserver--grappe:port:règle--serveur-------+ +-remove--grappe:port:règle--------------------+ +-report--grappe:port:règle--------------------+ +-set--grappe:port:règle--| opts |-------------+ +-status--grappe:port:règle--------------------+ '-useserver--grappe:port:règle--serveur+s2+...-' opts: |--+--------------------------------------+---------------------| +-beginrange--faible--endrange--élevée-+ +-priority--niveau---------------------+ +-motif--motif-------------------------+ +-tos--valeur--------------------------+ +-stickytime--heure--------------------+ +-affinity--type_affinité--------------+ +-cookiename--valeur-------------------+ +-evaluate--niveau---------------------+ '-sharelevel--niveau-------------------'
Pour de plus amples informations, reportez-vous à 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, reportez-vous aux sections Affinité de cookie actif, Affinité de cookie passif et Affinité d'URI.
Pour plus d'informations, reportez-vous à la section Affinité de cookie passif.
Pour la règle de type de connexion, vous pouvez également indiquer une 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 de plus amples informations, reportez-vous à 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--grappe:port:serveur--+-------------------------+-+->< | +-adresse--adresse--------+ | | +-collocated--valeur------+ | | +-sticky--valeur----------+ | | +-pondération--valeur-----+ | | +-fixedweight--valeur-----+ | | +-cookievalue--valeur-----+ | | +-mapport--valeur de port-+ | | +-router--adr-------------+ | | +-returnaddress--adr------+ | | +-advisorrequest--chaîne--+ | | '-advisorresponse--chaîne-' | +-set--grappe:port:serveur--+-collocated--valeur------+-+ | +-sticky--valeur----------+ | | +-pondération--valeur-----+ | | +-fixedweight--valeur-----+ | | +-cookievalue--valeur-----+ | | +-router--adr-------------+ | | +-advisorrequest--chaîne--+ | | '-advisorresponse--chaîne-' | +-down--grappe:port:serveur-----------------------------+ +-remove--grappe:port:serveur---------------------------+ +-report--grappe:port:serveur---------------------------+ +-up--grappe:port:serveur-------------------------------+ '-status--grappe: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 de plus amples informations, reportez-vous à Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
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/2.0\""
dscontrol server status 9.67.131.167:80:9.67.143.154Cette commande génère des résultats similaires à l'exemple suivant :
Etat du serveur : -------------- Serveur ........................ 9.67.143.154 Numéro du port ................. 80 Grappe ......................... 9.67.131.167 Adresse de grappe .............. 9.67.131.167 Mis au repos .................. N Serveur en fonction ............ Y Pondération .................... 10 Pondération fixe ............... N Rappel pour les règles ......... Y Serveur éloigné ................ N Adresse réseau du routeur ...... 0.0.0.0 Co-implanté .................... N Demande du conseiller .......... HEAD / HTTP/1.0 Réponse du conseiller .......... Valeur du cookie ............... n/a ID clone ....................... 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 :
L'exécuteur (executor) a été lancé. Le gestionnaire (manager) a été lancé ---------------------------------------- | CONSEILLER | GRAPPE:PORT | DELAI | ---------------------------------------- | 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------------------------------------'
Pour Windows 2000, le nom de communauté du système d'exploitation est utilisé.
Exemples
dscontrol subagent start bigguy bigguy.log
La présente annexe explique comment utiliser les commandes sscontrol Site Selector ci-après :
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-' | +-tentatives--nom--+-port----------+--nbrtentatives-----+ | '-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 | Non disp. | 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 | 0 |
pop3 | POP3 | 110 |
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 changer le répertoire dans lequel les fichiers journaux seront enregistrés, reportez-vous à la section 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 :
Rapport du conseiller : --------------- Nom du conseiller ............. http Numéro du port ................ 80 Nom du site ................... monSite Adresse du serveur ............ 9.67.129.230 Charge ........................ 8
sscontrol advisor start ftp 21 ftpadv.log
sscontrol advisor status http 80Cette commande génère des résultats similaires à l'exemple suivant :
Etat du conseiller : --------------- Intervalle (secondes)........................ 7 Délai d'expiration (secondes) ............... Unlimited Délai d'expiration de connexion (secondes)... 21 Délai d'expiration de réception (secondes)... 21 Nom du fichier journal du conseiller ........ Http_80.log Niveau de consignation ...................... 1 Taille maximale du journal (octets) ......... Unlimited Nombre de tentatives ........................ 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 fichier3 Le fichier (fichier3) est supprimé.
sscontrol file newload fichier1.sv Le fichier (fichier1.sv) a été chargé dans Dispatcher.
sscontrol file appendload fichier2.sv Le fichier (fichier2.sv) a été chargé et ajouté à la configuration actuelle.
sscontrol file report RAPPORT SUR LES FICHIERS : fichier1.sauv fichier2.sv fichier3
sscontrol file save fichier3 La configuration est sauvegardée dans fichier3.
>>-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 :
ARGUMENTS DE LA COMMANDE HELP : --------------------------------- Syntaxe : help <option> Exemple: help name help - Affichage des informations d'aide advisor - Aide sur la commande advisor file - Aide sur la commande file host - Aide sur la commande host manager - Aide sur la commande manager metric - Aide sur la commande metric sitename - Aide sur la commande sitename nameserver - Aide sur la commande nameserver server - Aide sur la commande server subagent - Aide sur la commande subagent set - Aide sur la commande set status - Aide sur la commande status logstatus - Aide sur la commande logstatusLes 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--nomsite+ns2+...+nsN--------------+ +-restart--message-------------------------+ +-sensitivity--weight----------------------+ +-smoothing--indice de lissage-------------+ +-start--+-------------------------------+-+ | '-fichier_journal--port_mesures-' | +-status-----------------------------------+ +-stop-------------------------------------+ '-version----------------------------------'
Le fichier par défaut se trouve dans le répertoire logs. Reportez-vous à l'Annexe C, Exemples de fichiers de configuration. Pour changer le répertoire dans lequel les fichiers journaux vont être enregistrés, reportez-vous à la section 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 :
---------------------------------- | SERVEUR | ETAT | ---------------------------------- | 9.67.129.221| ACTIF | | 9.67.129.213| ACTIF | | 9.67.134.223| ACTIF | ---------------------------------- -------------------------- | LEGENDE ETAT GESTIONNAIRE | -------------------------- | CPU | Charge de la CPU | | MEM | Charge de la mémoire | | SYS | Mesure du système | | NOW | Pondération actuelle| | NEW | Nouvelle pondération| | WT | Pondération | -------------------------- ------------------------------------------------------------------------ | monSite| 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| ------------------------------------------------------------------------ | TOTAUX : | 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 Relance du gestionnaire pour mettre à jour le 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 :
Etat du gestionnaire : ============= Port de mesures................................... 10004 Nom du fichier journal du gestionnaire ........... manager.log Niveau de consignation du gestionnaire ........... 1 Taille maxi du journal du gestionnaire (octets) .. unlimited Niveau de sensibilité............................. 5 Indice de lissage ................................ 1.5 Intervalle de mise à jour (secondes) ............. 2 Cycle de mise à jour des pondérations ............ 2 Niveau du journal de contacts .................... 1 Taille maximale du journal des contacts (octets) . unlimited Intervalle mise à jour des contacts (secondes) ... 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+...+nsN: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 :
Etat des mesures : ------------ Nom du site.................... site1 Nom de la mesure............... metric1 1Metric proportion ............ 50 Serveur ............. 9.37.56.100 Données de mesure... -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--faible--endrange--élevée-+ +-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+...+nsN: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--nomsite+ns2+...+nsN--+-----------------------------------------+-+->< | +-cachelife--valeur-----------------------+ | | +-networkproximity--oui | non-------------+ | | +-proportions--cpu--mémoire--port--mesure-+ | | +-proximitypercentage--valeur-------------+ | | +-stickytime--heure-----------------------+ | | +-ttl--heure------------------------------+ | | +-waitforallresponses--oui | non----------+ | | '-weightbound--weight---------------------' | +-remove--nomsite+ns2+...+nsN-------------------------------------------+ +-set--nomsite+ns2+...+nsN--+-----------------------------------------+-+ | +-cachelife--valeur-----------------------+ | | +-networkproximity--oui | non-------------+ | | +-proportions--cpu--mémoire--port--mesure-+ | | +-proximitypercentage--valeur-------------+ | | +-stickytime--heure-----------------------+ | | +-ttl--heure------------------------------+ | | +-waitforallresponses--oui | non----------+ | | '-weightbound--weight---------------------' | '-status--nomsite+ns2+...+nsN-------------------------------------------'
Exemples
sscontrol sitename add 130.40.52.153
sscontrol sitename set monSite networkproximity yes
sscontrol sitename set monSite cachelife 1900000
sscontrol sitename set monSite proximitypercentage 45
sscontrol sitename set monSite waitforallresponses no
sscontrol sitename set monSite ttl 7
sscontrol sitename set monSite proportions 50 48 1 1
sscontrol sitename remove 130.40.52.153
sscontrol sitename status monSiteCette commande génère des résultats similaires à l'exemple suivant :
Etat SiteName : --------------- SiteName .................................... monSite WeightBound ................................. 20 TTL ......................................... 5 StickyTime .................................. 0 Nombre de serveurs........................... 1 Proportion accordée à CpuLoad ............... 49 Proportion accordée à MemLoad................ 50 Proportion accordée au port.................. 1 Proportion accordée aux mesures du système... 0 Conseiller fonctionnant sur le port.......... 80 Utilisation de la fonction de proximité...... N
>>-sscontrol--status-------------------------------------------><
Exemples
sscontrol statusCette commande génère des résultats similaires à l'exemple suivant :
NameServer a été lancé. Le gestionnaire (manager) a été lancé ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ---------------------------------------- | http | 80 | unlimited | -----------------------------------------
La présente annexe explique comment utiliser les commandes ccocontrol pour 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 fermer l'interface de ligne de commande, entrez exit or quit.
>>-ccocontrol--consultant--+-add--IDcc--address--AdrIPcom--community--NomCommunauté-+->< +-binarylog--IDcc+IDcc2...--+-report-------------+-------+ | +-set--+-interval--+-+ | | | '-retention-' | | | +-start--------------+ | | '-stop---------------' | +-remove--IDcc+IDcc2...----------------------------------+ +-report--IDcc+IDcc2...----------------------------------+ +-set--+-loglevel--niveau---------------------+----------+ | +-logsize--+-taille----+---------------+ | | | '-unlimited-' | | | +-sensitivity--pourcentage pondération-+ | | '-délai d'inactivité--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 cc1 connecté au commutateur à l'adresse 9.37.50.1:cn1 Consultant démarré Délai d'inactivité = 7 Sensibilité = 5 Niveau consignation = 5 Taille du journal = 1 048 576 Contenu(s) de propriétaire : contenu de propriétaire cp1
ccocontrol consultant set cc1 sleeptime 10
ccocontrol consultant start cc1
>>-ccocontrol--contrôleur--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--niveau-------+ '-logsize--+-taille----+-' '-unlimited-'
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 :
Rapport du contrôleur : ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Niveau consignation . . . 1 Taille journal . . . . . 1048576 Fichier configuration . . config1.xml Consultants : Consultant consult1 -démarré
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 fichier1
ccocontrol file load config2
ccocontrol file report
Cette commande génère des résultats similaires à l'exemple suivant :
RAPPORT SUR LES FICHIERS : ------------ fichier1.xml fichier2.xml fichier3.xml
ccocontrol file save config2
>>-ccocontrol--help--+-contrôleur-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metriccollector--+ +-ownercontent-----+ '-service----------'
Exemples
ccocontrol help
Cette commande génère des résultats similaires à l'exemple suivant :
Les commandes suivantes sont disponibles : controller - s'applique au contrôleur consultant - s'applique aux consultants du commutateur file - s'applique aux fichiers de configuration help - s'applique à l'aide highavailability - s'applique à la haute disponibilité metriccollector - s'applique aux programmes de collecte de mesures ownerContent - s'applique au contenu des propriétaires service - s'applique aux services
>>-ccocontrol--highavailability--+-add--+-adresse--adresse-----------------------+-+->< | +-adresse_partenaire--adresse_partenaire-+ | | +-port--port-----------------------------+ | | '-role--+-principal--+-------------------' | | '-secondaire-' | +-dropreach--adresse------------------------------+ +-remove------------------------------------------+ +-report------------------------------------------+ +-set--+-beatinterval--heure-----+----------------+ | +-takeoverinterval--heure-+ | | +-loglevel--niveau--------+ | | '-logsize--+-taille----+--' | | '-unlimited-' | +-start--+-auto---+-------------------------------+ | '-manual-' | +-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 :
Etat de la haute disponibilité : ------------------------- Noeud . . . . . . . . . . principal Adresse du noeud . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Adresse du partenaire . . 9.37.50.14 Stratégie de reprise . . . manual Int. entre sig. prés. . . 500 Int. entre reprises . . . 2000 Etat . . . . . . . . . . . inactif Sous-état . . . . . . . . non synchronisé Etat d'accessibilité : Noeud/Partenaire --------------------------------------- Aucune cible configurée
>>-ccocontrol--metriccollector--+-report--IDcc+IDcc2+...:Nm+Nm2...---------------------------+->< '-set--IDcc+IDcc2+...:Nm+Nm2...--+-timeoutconnect--sec-----+-' +-loglevel--niveau--------+ +-logsize--+-taille----+--+ | '-unlimited-' | +-timeoutreceive--sec-----+ '-délai d'inactivité--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 :
Collecte de mesures cc1:http mesure(s) collectée(s).... http niveau consignation....... 5 taille journal............ 1048576 Nbr. sec. inactivité...... 7 délai expiration conn..... 21 délai expiration récep.... 21
ccocontrol metriccollector set cc1:http timeoutconnect 15 logsize unlimited
>>-ccocontrol--ownerContent--+-add--IDcc:Ncp--ownername--Np--contentrule--Nc--------------------------------+->< +-mesures--IDcc+IDcc2...:Ncp+Ncp2...--Nm--importance--Nm2--i2------------------+ +-refresh--IDcc+IDcc2...:Ncp+Ncp2...-------------------------------------------+ +-remove--IDcc+IDcc2...:Ncp+Ncp2...--------------------------------------------+ +-report--IDcc+IDcc2...:Ncp+Ncp2...--------------------------------------------+ '-set--IDcc+IDcc2...:Ncp+Ncp2...----mesure--Nm--+--------------------------+---' +-requeststring--chaîne----+ +-responsestring--chaîne---+ '-tentative--nbrtentatives-'
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 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | privé | 10,007 |
activeconn | Non disp. | Non disp. |
connrate | Non disp. | Non disp. |
cpuload | Non disp. | Non disp. |
memload | Non disp. | Non disp. |
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 cc1:cp1 Limite de pondération = 10 La mesure activeconn a la proportion 25 Chaîne de réponse... non disp. Chaîne de demande.... non disp. La mesure http a la proportion 50 Chaîne de réponse... non disp. Chaîne de demande.... non disp. La mesure connrate a la proportion 25 Chaîne de réponse... non disp. Chaîne de demande.... non disp. Contient le service t3 Contient le service t2 Contient le service t1
ccocontrol ownerContent set cc1:cp1 metric http requeststring getCookie
>>-ccocontrol--service--+-report--IDcc+IDcc2...:Ncp+Ncp2...:svc+svc2...----------------------------------+->< '---set--IDcc+IDcc2...:Ncp+Ncp2...:svc+svc2...--+----------------------------+---' +-fixedweight--+-entier-+----+ | '-off----' | +-requestsourceip--AdrIP-----+ +-metricserveraddress--AdrIP-+ '-metricserverport--Nport----'
Exemples
ccocontrol service report cc1:cp1:t1
Cette commande génère des résultats similaires à l'exemple suivant :
Service cc1:cp1:ta a la pondération 10 La pondération fixe est off IP source de la demande......... 9.27.24.156 Port d'application.............. 80 Adresse du serveur de mesures... 1.0.0.1 Port du serveur de mesures...... 10004 La mesure activeconn a la valeur -99 La mesure http a la valeur -99 La mesure connrate a la valeur -99
ccocontrol service set cc1:cp1:t2 metricserveraddress 9.37.50.17
La présente annexe explique comment utiliser les commandes nalcontrol pour 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 fermer l'interface de ligne de commande, entrez exit or quit.
>>-nalcontrol--consultant--+-add--IDcc--address--AdrIPcom--+--------------------------+--+->< | +-rcommunity--NomCommLect--+ | | '-wcommunity--NomCommEcrit-' | +-binarylog--IDcc+IDcc2...--+-report------------------------+-+ | +-set--+-interval--interval---+-+ | | | '-retention--retention-' | | | +-start-------------------------+ | | '-stop--------------------------' | +-remove--IDcc+IDcc2...---------------------------------------+ +-report--IDcc+IDcc2...---------------------------------------+ +-set--+--------------------------------------+---------------+ | +-loglevel--niveau---------------------+ | | +-logsize--+-taille----+---------------+ | | | '-unlimited-' | | | +-sensitivity--pourcentage pondération-+ | | '-délai d'inactivité--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 :
ID consultant : cc1 Adresse IP commutateur : 9.37.50.1 Communauté en lecture : publique Communauté en écriture : privée Consultant démarré Délai d'inactivité = 7 Sensibilité = 5 Niveau consignation = 5 Taille du journal = 1 048 576 Service(s) : Service svc1
nalcontrol consultant set cc1 sleeptime 10
nalcontrol consultant start cc1
>>-nalcontrol--contrôleur--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--niveau-------+ '-logsize--+-taille----+-' '-unlimited-'
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 :
Rapport du contrôleur : ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Niveau consignation . . . 1 Taille journal . . . . . 1048576 Fichier configuration . . config1.xml Consultants : Consultant consult1 -démarré
nalcontrol set loglevel 0
nalcontrol controller set logsize 1000000
>>-nalcontrol--file--+-delete--nomfichier-+-------------------->< +-load--nomfichier---+ +-report-------------+ '-save--nomfichier---'
Chemin d'accès courant 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 fichier1
nalcontrol file load config2
nalcontrol file report
Cette commande génère des résultats similaires à l'exemple suivant :
LISTE DES FICHIERS : ------------ fichier1.xml fichier2.xml fichier3.xml
nalcontrol file save config2
>>-nalcontrol--help--+-contrôleur-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metrinalllector--+ +-ownercontent-----+ '-service----------'
Exemples
nalcontrol help
Cette commande génère des résultats similaires à l'exemple suivant :
Les commandes suivantes sont disponibles : controller - s'applique au contrôleur consultant - s'applique aux consultants du commutateur file - s'applique aux fichiers de configuration help - s'applique à l'aide highavailability - s'applique à la haute disponibilité metriccollector - s'applique aux programmes de collecte de mesures server - s'applique aux serveurs service - s'applique aux services
>>-nalcontrol--highavailability--+-add--+-adresse--adresse-----------------------+-+->< | +-adresse_partenaire--adresse_partenaire-+ | | +-port--port-----------------------------+ | | '-role--+-principal--+-------------------' | | '-secondaire-' | +-dropreach--adresse------------------------------+ +-remove------------------------------------------+ +-report------------------------------------------+ +-set--+-beatinterval--heure-----+----------------+ | +-takeoverinterval--heure-+ | | +-loglevel--niveau--------+ | | '-logsize--+-taille----+--' | | '-unlimited-' | +-start--+-auto---+-------------------------------+ | '-manual-' | +-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 principal 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 :
Etat de la haute disponibilité : ------------------------- Noeud . . . . . . . . . . principal Adresse du noeud . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Adresse du partenaire . . 9.37.50.14 Stratégie de reprise . . . manual Int. entre sig. prés . . 500 Int. entre reprises . . . 2000 Lancé . . . . . . . . . . N Etat . . . . . . . . . . inactif Sous-état . . . . . . . .non synchronisé Etat d'accessibilité : Noeud/Partenaire ---------------------------------------
>>-nalcontrol--metricollector--+-report--IDcc+IDcc2+...:Nm+Nm2...---------------------------+->< '-set--IDcc+IDcc2+...:Nm+Nm2...--+-connecttimeout--sec-----+-' +-loglevel--niveau--------+ +-logsize--+-taille----+--+ | '-unlimited-' | +-receivetimeout--sec-----+ '-délai d'inactivité--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 cc1:http mesure(s) collectée(s).... http niveau consignation....... 5 taille journal............ 1048576 Nbr. sec. inactivité...... 7 délai expiration conn..... 21 délai expiration récep.... 21
nalcontrol metrinalllector set cc1:http connecttimeout 15 logsize unlimited
>>-nalcontrol--server--+-report--IDcc+IDcc2...:IDsvc+IDsvc2...:IDserveur+IDsvr2...-----------------------------------+->< '---set--IDcc+IDcc2...:IDsvc+IDsvc2...:IDserveur+IDsvr2--+--------------------------------+---' +-fixedweight--+-entier-+--------+ | '-off----' | +-requestsourceip--AdresseIP-----+ +-metricserveraddress--AdresseIP-+ '-metricserverport--NuméroPort---'
Exemples
nalcontrol server report cc1:svc1:1
Cette commande génère des résultats similaires à l'exemple suivant :
Le serveur cc1:svc1:1 a la pondération -99 La pondération fixe est off Ip source de la demande............. 9.27.24.156 Port de l'application............... 99 Adresse du serveur de mesures....... 9.99.99.98 Port du serveur de mesures.......... 10004 La mesure activeconn a la valeur -99 La mesure connrate a la valeur -99
nalcontrol server set cc1:svc1:2 metricserveraddress 9.37.50.17
>>-nalcontrol--service--+-add--IDcc+IDcc2...:IDservice+IDsvc2...--vsid--IDvirSvr--vport--NumPortvirt-------+->< +-mesures--IDcc+IDcc2...:IDsvc+IDsvc2...--Nm--importance--mCN2--i2-----------------+ +-refresh--IDcc+IDcc2...:IDsvc+IDsvc2...-------------------------------------------+ +-remove--IDcc+IDcc2...:IDsvc+IDsvc2...--------------------------------------------+ +-report--IDcc+IDcc2...:IDsvc+IDsvc2...--------------------------------------------+ '-set--IDcc+IDcc2...:IDsvc+IDsvc2...----mesure--Nm----+-requeststring--chaîne----+-' +-responsestring--chaîne---+ '-tentative--nbrtentatives-'
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 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | privé | 10,007 |
activeconn | Non disp. | Non disp. |
connrate | Non disp. | Non disp. |
cpuload | Non disp. | Non disp. |
memload | Non disp. | Non disp. |
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 cc1:svc1 Limite de pondération = 48 La mesure activeconn a la proportion 50 La mesure connrate a la proportion 50 Contient le serveur 4 Contient le serveur 3 Contient le serveur 2 Contient le serveur 1
nalcontrol service set cc1:svc1 metric http requeststring getLastErrorCode
Dans l'interface graphique de Load Balancer, la partie gauche du panneau affiche une arborescence comportant Load Balancer au niveau supérieur et Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller et Nortel Alteon Controller en tant que composants.
Les exemples d'affichage de l'interface graphique de Load Balancer illustrant les différents composants renvoient aux figures suivantes :
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, entrez 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 comment utiliser 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 :
Méthode=GET URI=/chemin/page Web.htm Version=HTTP/1.1 Hôte=www.entreprise.com Connexion=signal de présence Référenceur=http://www.entreprise.com/chemin/pagewebparente.htm
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 client=181.0.153.222&uri=/nipoek/*
Pour que cette commande fonctionne à partir de l'invite du système d'exploitation lorsque vous utilisez des caractères spéciaux, placez le motif entre guillemets (" ") comme suit :
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "client=181.0.153.222&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>>.
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'une grappe implique un ensemble de serveurs Web pour le contenu HTML standard, un autre ensemble de serveurs Web avec WebSphere Application Server pour les demandes de servlet, un autre ensemble de serveurs Lotus Notes 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ée afin que la séparation des demandes nécessaire se produise automatiquement. Par exemple, les commandes suivantes provoquent les trois division 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 demande 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 de la grappe 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 deuxième règle permet de détecter l'apparition de "pcs" dans des 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 vrai 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 "Ce site est actuellement indisponible, faites une nouvelle tentative 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 du répartiteur est de définir
# l'adresse NFA (adresse de non-réacheminement) et les adresses de grappes.
#
# L'adresse NFA permet d'accéder à 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 grappes.
#
# L'adresse de grappe (cluster) correspond au nom d'hôte (ou à l'adresse IP)
# auquel les clients éloignés se connecteront.
#
# Vous pouvez indifféremment utiliser les noms d'hôte et les adresses IP
# dans ce fichier.
#
# NFA=nomhôte.domaine.nom
# CLUSTER=www.votresociété.com
# echo "Chargement de l'adresse de non réacheminement"
# dscontrol executor set nfa $NFA
#
# L'étape suivante dans la configuration du répartiteur consiste à créer
# une grappe. Le répartiteur acheminera les requêtes envoyées
# à l'adresse de grappe vers les serveurs associés
# à cette grappe. Vous pouvez configurer plusieurs adresses de
# grappes et leur associer plusieurs serveurs à l'aide du répartiteur.
# Utilisez une configuration similaire pour CLUSTER2, CLUSTER3, etc.
#
# echo "Chargement de la première adresse de grappe"
# dscontrol cluster add $CLUSTER
#
# L'étape suivante consiste à définir les ports utilisés par cette grappe.
# Toute requête reçue par le répartiteur sur un port défini
# sera réacheminée vers le port correspondant de l'un
# des serveurs.
#
# echo "Création de ports pour la grappe : $CLUSTER"
# dscontrol port add $CLUSTER:20+21+80
#
# La dernière étape consiste à associer chaque serveur
# aux ports de cette grappe.
# Vous pouvez utiliser indifféremment le nom
# d'hôte ou l'adresse IP des serveurs.
#
# SERVER1=server1name.domain.name
# 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 premier composant 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
# (round-robin). 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
# fournissent au gestionnaire des informations supplémentaires sur la capacité
# du serveur à répondre aux requêtes, et à détecter si le serveur est actif
# ou non. Si un conseiller détecte qu'un serveur est arrêté, cela sera
# consigné (à condition que les proportions du gestionnaire soient définies
# pour inclure les entrées de conseiller) et aucune autre requête ne sera
# 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 proviendront des connexions nouvelles, 48%,
# des connexions actives, 4%, des conseillers et les entrées
# système ne seront pas prises 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
#
# L'étape finale dans la configuration du répartiteur est d'affecter
# un alias à la Carte d'interface réseau (NIC).
#
# REMARQUE : N'utilisez pas cette commande dans un environnement
# haute disponibilité. Les scripts go* configureront les cartes NIC et
# le bouclage si nécessaire.
# dscontrol executor configure $CLUSTER
# Si votre adresse de grappe se trouve sur une autre carte NIC
# ou sur un sous-réseau autre que ceux de la NFA, utilisez le format
# suivant comme commande de configuration de grappe.
# dscontrol executor configure $CLUSTER tr0 0xfffff800
# tr0 étant votre carte NIC (tr1, la seconde carte réseau en anneau à jeton,
# en0 la première carte ethernet) et 0xfffff800 étant un masque
# de sous-réseau valide pour votre site.
#
#
# Les commandes suivantes permettent de définir 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.000000
# 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
#
Voici un exemple de fichier de configuration de Load Balancer intitulé configuration.cmd.sample à utiliser 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 est de définir rem l'adresse NFA (adresse de non-réacheminement) et les rem adresses de grappes. rem rem L'adresse NFA permet d'accéder à distance au répartiteur rem afin d'effectuer des opérations d'administration de configuration. rem Cette adresse est obligatoire car le répartiteur doit réacheminer rem des paquets vers les adresses de grappes. rem rem L'adresse de grappe (CLUSTER) est le nom d'hôte (ou l'adresse IP) rem à laquelle les clients éloignés se connecteront. 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 de la grappe] 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 valeurs par défaut sont affectées aux commandes suivantes. rem Utilisez ces commandes pour modifier les valeurs par défaut. rem call dscontrol executor set fintimeout 30 rem call dscontrol executor set fincount 4000 rem rem rem L'étape suivante dans la configuration du répartiteur consiste à créer rem une grappe. Le répartiteur acheminera les requêtes envoyées rem à l'adresse de grappe vers les serveurs associés rem à cette grappe. Vous pouvez configurer plusieurs adresses de rem grappes à l'aide du répartiteur. rem Utilisez une configuration similaire pour CLUSTER2, CLUSTER3, etc. rem rem echo "Chargement de la première adresse de grappe" rem call dscontrol cluster add %CLUSTER% rem rem L'étape suivante consiste à définir les ports utilisés par cette rem grappe. rem Toute requête reçue par le répartiteur sur un port défini rem sera réacheminée vers le port correspondant rem de l'un des serveurs. rem rem echo "Création des ports de la GRAPPE : %CLUSTER%" rem call dscontrol port add %CLUSTER%:20+21+80 rem rem La dernière étape consiste à associer chaque serveur aux rem ports définis pour la grappe. 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 premier composant 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 (round-robin). Une fois le gestionnaire lancé, les décisions rem de 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 permettent au gestionnaire de disposer rem d'informations supplémentaires sur la capacité du serveur à répondre rem aux requêtes et à détecter si un serveur est actif ou non. Si un rem conseiller détecte qu'un serveur est arrêté, cela sera consigné rem (à condition que les proportions du gestionnaire aient été définies rem pour inclure les entrées du conseiller) et aucune requête ne sera rem acheminée 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 manager de chaque serveur sur la base 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 proportions doit être égale à 100. Par exemple, rem si l'on définit les proportions avec rem dscontrol cluster set <grappe> proportions 48 48 4 0 rem 48 % des informations proviendront des connexions nouvelles, rem des connexions actives, 4 % des conseillers et les entrées rem système ne seront pas prises en compte. rem rem REMARQUE : par défaut, les propriétés du gestionnaires sont définies comme suit : 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 de la grappe..." 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* configureront les cartes NIC rem et le bouclage si nécessaire. rem rem dscontrol executor configure %CLUSTER% rem Si votre adresse de grappe se trouve sur une autre carte NIC rem ou sur un sous-réseau autre que l'adresse NFA, utilisez la rem commande de configuration de grappe suivante. rem dscontrol executor configure %CLUSTER% tr0 0xfffff800 rem tr0 étant votre carte NIC (tr1 la seconde carte réseau en anneau rem à jeton, 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.000000 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 : Conseiller HTTP de 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. En fait,
* c'est cette base qui effectue la plupart des fonctions du conseiller,
* telles que la communication des charges à Load Balancer
* pour l'algorithme de pondération de Load Balancer.
* La base du conseiller effectue également les opérations de connexion
* et de fermeture de la connexion et fournit des méthodes d'envoi et de
* réception qui seront utilisées par le conseiller. Le conseiller n'est
* lui-même utilisé que pour l'envoi de données vers le port du serveur
* conseillé et pour la réception de données sur ce dernier. Les méthodes
* TCP de la base du conseiller sont programmées pour calculer la charge.
* Un indicateur du constructeur de ADV_base remplace, si vous le
* souhaitez, la charge existante par la nouvelle charge renvoyée
* par le conseiller.
*
* Remarque : 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 DE 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 peut
* cependant n'être lancé qu'à 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
*
*
* Les conseillers, tout comme les autres éléments de Load Balancer,
* doivent être compilés avec la version Java recommandée. Pour
* garantir l'accès aux classes Load Balancer, vérifiez que le fichier
* ibmnd.jar (situé dans le sous-répertoire lib du répertoire de
* 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 sDefaultLogFileName = 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
* seront alors 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
* ou la remplacer ; les deux situations 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
{
Chaîne 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 qui doit être mise
* en oeuvre après le démarrage de la base du conseiller.
* 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 Balancer 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 tentera pas d'équilibrer un serveur
* défaillant. Load Balancer recommencera à équilibrer la charge
* du serveur à la réception d'un 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 que le serveur est actif
* ou inactif.
* 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
Cette annexe décrit comment définir une configuration de haute disponibilité à deux niveaux regroupant les capacités de deux composants Load Balancer (Dispatcher et CBR) et Caching Proxy.
Le serveur suivant est configuré pour la Figure 46 :
La Figure 46 montre une représentation de base de l'équilibrage de la charge de plusieurs serveurs (EdgeServer1, EdgeServer2, EdgeServer3) sur plusieurs serveurs Web périphériques. Le composant CBR utilise Caching Proxy pour acheminer les demandes vers les serveurs Web périphériques 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 périphériques 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 exemple :
Les fichiers de configuration exemple suivants sont identiques à ceux créés lors de la définition de la configuration de Edge Component comme illustré à 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 sur certains sujets décrits 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 EMEA Director of LicensingPour le Canada, veuillez adresser votre courrier à :
IBM Director of Commercial RelationsLes 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 modifier sans préavis 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 CorporationCes 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'International Business Machines Corporation dans certains pays.
AFS
AIX
DFS
IBM
OS/2
NetView
RS/6000
SecureWay
ViaVoice
WebSphere
Lotus et WordPro sont des marques d'International Business Machines Corporation et Lotus Development Corporation dans certains pays.
Tivoli est une marque de Tivoli Systems, Inc dans certains pays.
Java et toutes les marques et logos incluant Java sont des marques de Sun Microsystems, Inc. dans certains pays.
Solaris est une marque de Sun Microsystems, Inc. dans certains pays.
Microsoft et Windows 2000 sont des marques de Microsoft Corporation dans certains pays.
UNIX est une marque enregistrée de The Open Group dans certains pays.
D'autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient apparaître dans ce document.
D'autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient apparaître dans ce document.