Important |
---|
Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à l'Annexe I, 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 2001. Tous droits réservés.
© Copyright International Business Machines Corporation 2001. All rights reserved.
Installation de Network Dispatcher
Présentation de Network Dispatcher
Planification du composant Dispatcher
Configuration du composant Dispatcher
Planification du composant CBR (Content Based Routing)
Configuration du composant CBR
Planification du composant Mailbox Locator
Configuration du composant Mailbox Locator
Planification du composant Site Selector
Configuration du composant Site Selector
Planification du composant Consultant for Cisco CSS Switches
Configuration du composant Consultant for Cisco CSS Switches
Fonctions Network Dispatcher avancées
Exploitation et gestion de Network Dispatcher
Annexe A. Lecture d'un schéma de syntaxe
Annexe B. Guide des commandes Dispatcher, CBR et Mailbox Locator
Annexe C. Syntaxe des règles de contenu (modèle)
Annexe D. Guide des commandes Site Selector
Annexe E. Guide des commandes Consultant for Cisco CSS Switches
Annexe F. Exemples de fichiers de configuration
Annexe H. Ressources supplémentaires
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 Edge Server Network Dispatcher pour AIX, Linux, Solaris et Windows 2000. Ce produit était connu sous le nom SecureWay Network Dispatcher, eNetwork Dispatcher et Interactive Network Dispatcher.
Une version actualisée du présent manuel est disponible aux formats HTML et PDF, sur le site WEB WebSphere Edge Server. Pour consulter la documentation en ligne, accédez à l'URL suivante :
http://www.ibm.com/software/webservers/edgeserver/library.html
Le site WebSphere Edge Server fournit des informations récentes sur l'utilisation de Network Dispatcher dans le cadre de l'optimisation des performances des serveurs. Ce site présente également des exemples et des scénarios de configuration. Pour y accéder, entrez l'URL suivante :
http://www.ibm.com/software/webservers/edgeserver
Pour obtenir les dernières mises à jour ainsi que des conseils sur Network Dispatcher, visitez la page Web d'assistance WebSphere Edge Server et cliquez sur Search for Network Dispatcher hints and tips. Pour accéder à ce site Web, entrez l'URL suivante :
http://www.ibm.com/software/webservers/edgeserver/support.html
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 WebSphere Edge Server :
En combien de temps pouvez-vous faire fonctionner Network Dispatcher ? Considérons l'exemple ci-après.
Supposons que vous soyez responsable du site Web de la société Intersplash. Vous gérez un site Web local avec deux serveurs HTTP. Vous avez utilisé la permutation circulaire pour gérer la charge de ces deux serveurs, mais l'activité de votre entreprise vient de s'accroître récemment et vous commencez à recevoir des plaintes de certains clients qui ne parviennent pas à accéder à votre site. Que faire ?
Accédez à http://www.ibm.com/software/webservers/edgeserver et téléchargez la dernière version de Network Dispatcher. Ce produit se compose de cinq composants : Dispatcher, Content Based Routing (CBR), Mailbox Locator, Site Selector et Consultant for Cisco CSS Switches (Cisco Consultant). Pour l'instant, nous nous contenterons d'aborder le composant Dispatcher.
Figure 1. Configuration Dispatcher locale simple
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 de 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.
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 Dispatcher requiert une adresse réelle et une adresse pour l'équilibrage de charge.
Poste de travail | Nom | Adresse IP |
---|---|---|
1 | server1.intersplash.com | 9.67.67.101 |
2 | server2.intersplash.com | 9.67.67.102 |
3 | server3.intersplash.com | 9.67.67.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.67.67.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.
ndcontrol executor start
ndcontrol cluster add www.intersplash.com
ndcontrol port add www.intersplash.com:80
ndcontrol server add www.intersplash.com:80:server2.intersplash.com
ndcontrol server add www.intersplash.com:80:server3.intersplash.com
ndcontrol cluster configure www.intersplash.com
ndcontrol manager start
Dispatcher procède maintenant à l'équilibrage de charge en fonction des performances des serveurs.
ndcontrol 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.
Si vous utilisez l'assistant de configuration, suivez la procédure ci-dessous.
ndserver
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.
Avec l'assistant de configuration, vous découvrirez les panneaux suivants :
Pour lancer l'interface graphique, procédez de la manière suivante :
ndserver
La partie gauche du panneau affiche une arborescence comportant Network Dispatcher au niveau supérieur et Dispatcher, Content Based Routing, Mailbox Locator, Site Selector et Cisco Consultant en tant que composants. Reportez-vous à la Figure 2.
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.
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 dans le coin supérieur droit de la fenêtre Network Dispatcher.
Vérifiez que la configuration fonctionne.
Il y a plusieurs manières de configurer Network Dispatcher 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 Network Dispatcher communique. Reportez-vous à la Figure 3.
Figure 3. 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é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, Network Dispatcher 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 4.
Figure 4. 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 Network Dispatcher 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 5.
Figure 5. 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 conditions matérielles requises ainsi que la procédure d'installation de Network Dispatcher sous AIX, Linux, Solaris et Windows 2000. Suivez les instructions ci-dessous en vous reportant aux sections suivantes :
Remarques :
Pour vérifier que les composants Network Dispatcher utilisent la version correcte de Java lorsque plusieurs versions sont installées, procédez comme suit :
Modifiez les fichiers script pour chaque composant de Network Dispatcher à 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, remplacez la ligne correspondante comme suit dans ndserver.cmd :
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.
Le tableau 1 répertorie les images installp de Network Dispatcher
pour AIX.
Tableau 1. Images installp AIX
Dispatcher (composant, administration, licence et messages) | intnd.nd.driver intnd.nd.rte intnd.msg.nd.<langue>.nd intnd.admin.rte intnd.msg.<langue>.admin |
Administration (uniquement) | intnd.admin.rte intnd.msg.<langue>.admin |
Documentation | intnd.doc.rte |
Licence | intnd.nd.license |
Système Metric Server | intnd.ms.rte |
où <langue> est l'une des suivantes :
Si vous téléchargez une copie d'évaluation du produit à partir du site Web, suivez les instructions d'installation sur le site (http://www.ibm.com/software/webservers/edgeserver/download.html).
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 Network Dispatcher 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 Network Dispatcher pour
AIX :
Tableau 2. Commande AIX relatives à l'installation
Network Dispatcher (avec messages). Inclut : Dispatcher, CBR, Mailbox Locator, Site Selector et Cisco Consultant | installp -acXgd unité intnd.nd.rte intnd.admin.rte intnd.nd.driver intnd.msg.<langue>.nd intnd.msg.<langue>.admin |
Documents | installp -acXgd unité intnd.doc.rte intnd.msg.<langue>.doc |
Administration (uniquement) | installp -acXgd unité intnd.admin.rte intnd.msg.<langue>.admin |
Licence | installp -acXgd unité intnd.nd.license |
Système Metric Server | installp -acXgd unité intnd.ms.rte intnd.msg.<langue>.admin |
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 Network Dispatcher 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 intnd
Si vous avez installé l'intégralité du produit, cette commande génère le résultat suivant :
intnd.admin.rte intnd.doc.rte intnd.ms.rte intnd.msg.en_US.admin.rte intnd.msg.en_US.doc intnd.msg.en_US.nd.rte intnd.nd.driver intnd.nd.license intnd.nd.rte
Les chemins d'installation de Network Dispatcher incluent les éléments suivants :
La présente section explique comment installer Network Dispatcher sous Red Hat Linux ou SuSE Linux à l'aide du CD du produit ou de sa version d'évaluation téléchargée à partir du site Web. Les instructions d'installation sont disponibles sur le site Web (http://www.ibm.com/software/webservers/edgeserver/download.html).
Avant de commencer la procédure d'installation, soyez certain de disposer de droits d'accès root pour installer le logiciel.
Pour installer Network Dispatcher :
L'image d'installation est un fichier de format ndlinux-version.tar.
Voici la liste des modules RPM qui peuvent être installés.
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 ibmnd
L'installation du produit complet génère une liste comme celle-ci :
For Solaris 8, Netscape Navigator 4.07 (ou version ultérieure) ou Netscape Communicator 4.61 (ou version ultérieure) pour l'affichage de l'aide en ligne
La présente section explique comment installer Network Dispatcher sur Solaris à partir du CD-ROM du produit. Si vous téléchargez une copie d'évaluation du produit à partir d'Internet, suivez les instructions d'installation sur le site Web (http://www.ibm.com/software/webservers/edgeserver/download.html).
Avant de commencer la procédure d'installation, soyez certain de disposer de droits d'accès root pour installer le logiciel.
Pour installer Network Dispatcher :
A l'invite, entrez pkgadd -d chemin d'accès où -d 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, ibmndadm. Ce module commun doit être installé avec chacun des autres modules.
Si vous voulez installer le produit Network Dispatcher dans son intégralité, vous devez installer cinq éléments : ibmdsp, ibmdsplic, ibmndadm, ibmnddoc et ibmndms. Si vous souhaitez installer l'administration à distance , seule l'installation d'ibmndadm est nécessaire.
Les composants Network Dispatcher se trouvent dans le répertoire d'installation /opt/nd/servers.
L'installation du produit complet génère une liste comme celle-ci :
Vous devez télécharger à la fois le module installable Developer Kit et le module installable Runtime Environment avant d'exécuter le programme InstallShield. (Pour consulter les informations relatives à l'exécution de plusieurs versions Java, reportez-vous à la remarque (JVER).)
La présente section explique comment installer Network Dispatcher sous Windows 2000 à partir du CD-ROM du produit. Si vous téléchargez une copie d'évaluation du produit à partir du site Web, suivez les instructions d'installation sur le site Web (http://www.ibm.com/software/webservers/edgeserver/download.html).
Une liste de modules à installer vous est proposée :
La version Windows 2000 de Network Dispatcher est prise en charge par les produits suivants :
Restrictions : La version Windows 2000 de Network Dispatcher 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 procéder à la désinstallation en utilisant la fonction Ajouter/Supprimer un programme, suivez la procédure suivante :
Pour installer Network Dispatcher :
E:\setup
Les chemins d'installation de Network Dispatcher incluent les éléments suivants :
Ce chapitre contient une présentation générale de Network Dispatcher et comporte les sections suivantes :
Network Dispatcher constitue une solution logicielle permettant l'équilibrage de charge des 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. Network Dispatcher 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, Network Dispatcher 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, Network Dispatcher 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.
Network Dispatcher comprend cinq composants pouvant être employés conjointement ou séparément pour vous permettre d'obtenir les meilleurs résultats en matière d'équilibrage de charge :
En ce qui concerne le protocole HTTP, le composant fonction CBR de Dispatcher peut être utilisé 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, Mailbox Locator, Site Selector et Consultant for Cisco CSS Switches, reportez-vous à la section Composants de Network Dispatcher.
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, Network Dispatcher 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.
Network Dispatcher 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.
Dispatcher dispose d'une fonction intégrée assurant une haute disponibilité ; à tout moment, une machine de secours peut assurer l'équilibrage de charge si la machine Dispatcher principale vient à défaillir. Dispatcher offre également la fonction de haute disponibilité réciproque qui permet à deux machines d'être simultanément en mode actif et attente l'une pour l'autre. Pour plus de détails, 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).
Network Dispatcher pour IBM WebSphere Edge Server Version 2.0 contient un certain nombre de fonctions nouvelles. Les plus importantes sont présentées ci-après.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Network Dispatcher prend désormais en charge une nouvelle version de AIX : AIX Version 5.1. Pour plus d'informations, reportez-vous à la section Configuration requise pour AIX.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Network Dispatcher prend désormais en charge SuSE Linux Version 7.1 (version de noyau 2.4.0-4 Go). Auparavant, Network Dispatcher ne prenait en charge que Red Hat Linux. Pour plus d'informations, reportez-vous à la section Configuration requise pour Red Hat Linux ou SuSE Linux.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Network Dispatcher prend désormais en charge une nouvelle version de Red Hat Linux : Red Hat Linux Version 7.1 (version de noyau 2.4.2-2). Pour plus d'informations, reportez-vous à la section Configuration requise pour Red Hat Linux ou SuSE Linux.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Sous les systèmes d'exploitation Linux et Solaris, Network Dispatcher comporte un support multilingue pour les pays du groupe 1.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Network Dispatcher comporte un support multilingue conforme à la nouvelle norme NLS chinoise GB 18030.
Cette fonction est un nouveau composant de Network Dispatcher.
La collaboration avec Cisco et son CDN (Content Distribution Network (CDN) a conduit au développement d'un nouveau composant de Network Dispatcher : Cisco Consultant. Ce composant (qui a d'abord été proposé en version autonome) permet à Network Dispatcher de générer des pondérations et de prendre des décisions en matière d'équilibrage de charge pour le composant CSS de Cisco.
Pour plus d'informations, reportez-vous aux sections Planification du composant Consultant for Cisco CSS Switches et Configuration du composant Consultant for Cisco CSS Switches.
Cette fonction est un nouveau composant de Network Dispatcher.
Le composant Site Selector équilibre la charge dans un groupe de serveurs en choisissant l'adresse IP de serveur correcte qui correspond à la demande du service annuaire. Le client peut ainsi se connecter directement au serveur pour sa communication. Site Selector remplace Interactive Session Support (ISS), composant de Network Dispatcher figurant dans les versions précédentes. Site Selector offre la même fonctionnalité que ISS mais minimise le nombre d'opérations nécessaires à la configuration de l'équilibrage de charge DNS traditionnel.
Pour plus d'informations, reportez-vous aux sections Planification du composant Site Selector et Configuration du composant Site Selector.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Metric Server fournit à Network Dispatcher des informations relatives à la charge des serveurs sous la forme de mesures système. L'agent Metric Server est un composant de Network Dispatcher qui peut être installé et exécuté sur les serveurs dont la charge est équilibrée par Network Dispatcher. Metric Server remplace l'agent SMA (System Monitoring Agent) qui était pris en charge sous Linux dans les versions précédentes. Metric Server est accepté sur toutes les plate-formes. Nous recommandons d'utiliser Metric Server avec le composant Site Selector.
Pour de plus amples informations, reportez-vous à Metric Server.
Cette fonction est un nouveau composant de Network Dispatcher.
Le composant Mailbox Locator était une fonction appartenant au composant CBR, qui assurait l'équilibrage de charge entre les serveurs IMAP et POP3 sur la base des ID utilisateur et des mots de passe. La séparation de CBR en deux composants permet d'exécuter Mailbox Locator (anciennement "CBR for IMAP/POP3") et CBR avec Caching Proxy sur le même poste.
Pour plus d'informations, reportez-vous aux sections Planification du composant Mailbox Locator et Configuration du composant Mailbox Locator.
La définition du fichier de configuration du proxy (ibmproxy.conf) pour utiliser CBR a été rationalisée et CBR permet désormais d'exécuter plusieurs instances de Caching Proxy simultanément sur le même poste, qui servent d'interface à CBR. Pour plus d'informations sur la configuration de CBR avec Caching Proxy, reportez-vous à la section Configuration du poste CBR.
Cette fonction s'applique au composant Dispatcher.
NAT/NAPT élimine la nécessité d'implanter les serveurs principaux sur un réseau local. Il permet aussi à Dispatcher de répartir la charge des demandes TCP du client sur différents démons de serveur exécutés sur le même poste physique. Vous pouvez configurer des serveurs à plusieurs démons de deux façons différentes. Avec NAT, vous pouvez configurer plusieurs démons de serveur pour qu'ils répondent aux demandes selon les adresses IP. En d'autres termes, il s'agit de lier un démon de serveur à une adresse IP. Avec NAPT, vous pouvez configurer plusieurs démons de serveur pour qu'ils écoutent sur différents numéros de port.
La méthode d'acheminement NAT de Dispatcher présente l'avantage d'être configurée au niveau du port et donc d'offrir une meilleure granularité.
Pour plus d'informations, reportez-vous à la section Réacheminement NAT/NAPT de Dispatcher (méthode d'acheminement nat).
Cette fonction s'applique au composant Dispatcher.
Dans les versions précédentes de Network Dispatcher, fonction CBR (content-based routing) était disponible uniquement lorsque le composant CBR était utilisé conjointement à Caching Proxy. Le composant Dispatcher permet désormais 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, le composant Dispatcher peut fournir une fonction fonction CBR (content-based routing) plus rapide que le composant CBR.
Pour plus d'informations sur l'utilisation de la règle de contenu et de l'affinité des ID de session SSL, reportez-vous à la section Fonction CBR de Dispatcher (méthode d'acheminement cbr).
Cette fonction s'applique à la méthode d'acheminement CBR (Content-Based Routing) de Dispatcher et au composant CBR.
Affinité de type cookie passif permet d'équilibrer la charge du trafic Web ayant une affinité avec le même serveur, en se basant sur des cookies générés par les serveurs et s'auto-identifiant. Pour plus d'informations, reportez-vous à la section Affinité de cookie passif.
Cette fonction s'applique à la méthode d'acheminement CBR (Content-Based Routing) de Dispatcher et au composant CBR.
Elle permet d'équilibrer la charge du trafic Web sur les serveurs proxy avec mémoire cache de telle façon que la taille de la mémoire cache augmente effectivement. Pour plus d'informations, reportez-vous à la section Affinité d'URI.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Dans les versions précédentes, l'importance (attribuée aux connexions actives, aux nouvelles connexions, au port et aux mesures système) pour déterminer les décisions d'équilibrage de charge était définie à partir de la fonction gestionnaire. Ces proportions (niveaux d'importance) étaient appliqués à chaque grappe présente dans la configuration du composant. Toutes les grappes étaient mesurées avec les mêmes proportions quel que soit le site dont la charge était équilibrée.
Avec cette nouvelle fonction, vous pouvez définir le niveau d'importance en prenant la grappe (ou le site) pour base. Pour plus d'informations, reportez-vous à la section Proportion de l'importance accordée aux données d'état.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Network Dispatcher permet désormais de partitionner un serveur physique en plusieurs serveurs logiques. Par exemple, vous pouvez ainsi interroger un service spécifique sur le poste pour détecter si un moteur de servlet ou une demande à la base de données est exécutée plus rapidement ou n'est pas exécutée du tout. Cette fonction permet de répartir la charge en se basant sur une charge plus granulaire, spécifique au service. Pour plus d'informations, reportez-vous à la section Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
Cette fonction s'applique aux composants Dispatcher et CBR.
Avec cette fonction pour conseiller HTTP, vous pouvez évaluer l'état des différents services présents sur un serveur. Pour chaque serveur logique sur port HTTP, vous pouvez indiquer une chaîne unique d'URL HTTP de client, spécifique au service à interroger sur le serveur. Pour plus d'informations, reportez-vous à la section Option de demande/réponse (URL) de conseiller HTTP.
Cette fonction s'applique à tous les composants de Network Dispatcher.
Network Dispatcher permet de démarrer différents conseillers fonctionnant sur le même port mais configurés sur différentes grappes (sites). Par exemple, cette fonction vous permettra d'utiliser un conseiller HTTP sur le port 80 pour une grappe (site) et un conseiller personnalisé sur le port 80 pour une autre grappe (site). Pour plus d'informations, reportez-vous à la section Lancement et arrêt d'un conseiller.
Cette fonction s'applique au composant Dispatcher.
Cette fonction permet à Dispatcher de détecter les attaques de "refus de service" possibles et d'en alerter l'administrateur. Pour cela, Dispatcher analyse les demandes entrantes d'un certain nombre de connexions partielles, point commun des attaques de refus de service.
Pour plus d'informations, reportez-vous à la section Détection d'attaque de refus de service.
Cette fonction s'applique à tous les composants, sauf Consultant for Cisco CSS Switches et Site Selector.
Network Dispatcher 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 consigner le changement d'un état de haute disponibilité ou de prévenir l'administrateur lorsque les serveurs sont marqués comme inactifs. Network Dispatcher fournit les nouveaux exemples de fichier script suivants :
Cette fonction s'applique au composant Dispatcher.
Dispatcher fournit un conseiller DB2 qui communique avec les serveurs DB2. Pour plus d'informations sur le conseiller DB2, reportez-vous à la section Liste des conseillers.
Les cinq composants de Network Dispatcher sont Dispatcher, Content Based Routing (CBR), Mailbox Locator, Site Selector et Consultant for Cisco CSS Switches. Network Dispatcher permet d'utiliser ces composants séparément ou ensemble, selon la configuration de votre site. La section qui suit présente ces composants.
Le composant Dispatcher assure l'équilibrage de 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 6 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 7. Exemple de site utilisant Dispatcher et Metric Server pour gérer les serveurs
La Figure 7 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 Network Dispatcher.
Figure 8. 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 8 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 groupe de serveurs qui doit prendre en charge une demande en fonction de son contenu. CBR permet également d'indiquer plusieurs serveurs pour chaque type de demande. Par conséquent, la charge des demandes peut être répartie 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 9. Exemple de site utilisant CBR pour gérer les serveurs locaux
La Figure 9 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.
Mailbox Locator peut fournir un point de présence unique à plusieurs serveurs IMAP ou POP3. Chacun des serveurs peut disposer d'un sous-réseau de toutes les boîtes aux lettres des utilisateurs desservis par le point de présence. Dans le cas des protocoles IMAP et POP3, Mailbox Locator est un proxy qui choisit un serveur approprié en se fondant sur l'ID utilisateur et le mot de passe donnés par le client. Mailbox Locator ne prend pas en charge l'équilibrage de charge à base de règles.
Figure 10. Exemple de site utilisant Mailbox Locator pour gérer les serveurs locaux
La Figure 10 montre la représentation logique d'un site utilisant Mailbox Locator pour relayer les demandes des clients (protocole IMAP ou POP3) vers le serveur approprié, en fonction de l'ID utilisateur et du mot de passe.
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 Network Dispatcher qui surveille le système et doit être installé sur chaque serveur dont la charge doit être équilibrée dans 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 11 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.
Lorsque le client reçoit l'adresse IP du serveur, il achemine les demandes suivantes directement au serveur sélectionné (chemin d'accès 2).
Consultant for Cisco CSS Switches constitue une solution complémentaire avec le relais Cisco CSS 11000 series. 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é des serveurs principaux, des applications et des bases de données ainsi que les informations de charge. La fonction Cisco Consultant fait appel au gestionnaire de Network Dispatcher, aux conseillers standard et personnalisés et à Metric Server pour déterminer les mesures, la santé et la charge des serveurs principaux, des applications et des bases de données. Cisco Consultant utilise ces informations pour générer les mesures de pondération, qu'il envoie au serveur Cisco CSS Switch pour la sélection du serveur optimal, l'optimisation de la charge et la tolérance aux pannes.
Le serveur Cisco CSS Switch prend les décisions d'équilibrage de charge en fonction des critères définis par l'utilisateur.
Cisco Consultant suit de nombreux critères, dont :
Lorsqu'un serveur Cisco CSS Switch, sans Cisco Consultant, détermine la santé d'un serveur de contenu, il utilise les temps de réponse aux demandes de contenu ou d'autres mesures de réseau. Avec Cisco Consultant, le serveur Cisco CSS Switch se décharge de ces activités sur le serveur Cisco Consultant. Cisco Consultant influence la pondération du serveur ou sa faculté à servir le contenu, et active ou suspend un serveur, selon le cas, lorsque le serveur devient disponible ou indisponible.
Cisco Consultant:
Les pondérations définies s'appliquent à tous les serveurs connectés sur un même port. Pour chaque port, les demandes sont réparties entre les serveurs selon la pondération relative de chacun. Par exemple, si un serveur a une pondération (paramètre Weight) de 10 et un autre de 5, le premier recevra deux fois plus de demandes que le second. Ces pondérations sont fournies au serveur Cisco CSS Switch avec SNMP. Lorsque la valeur de pondération d'un serveur est augmentée, le serveur Cisco CSS Switch dirige davantage de demandes vers ce serveur.
Cisco Consultant, 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 serveurs. Cisco Consultant appartient à une solution globale complémentaire située entre le serveur Cisco CSS Switch et IBM WebSphere Edge Server.
Pour la liste des éléments requis pour Cisco Consultant, reportez-vous à la section Installation de Network Dispatcher.
Dispatcher offre une fonctionnalité de haute disponibilité intégrée. Cette dernière implique l'utilisation d'une deuxième machine Dispatcher, chargée de contrôler la machine principale (également appelée machine primaire), 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 primaire 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 deux postes serveur ou plus dotés de CBR, Mailbox Locator ou Site Selector, vous pouvez atteindre un niveau de haute disponibilité pour ces composants de Network Dispatcher.
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 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.
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.
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 ce serait le cas 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 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 primaire. 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é.
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 ndcontrol 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 à ndcontrol 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.
ndcontrol server add grappe:port:serveur mapport valeur returnaddress adresseretour router adresserouteur
Cette commande permet de mapper le numéro de 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 à Network Dispatcher 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 renverra 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é.
Dans les versions précédentes de Network Dispatcher, la fonction CBR (content-based routing) était disponible uniquement lorsque le composant CBR était utilisé avec Caching Proxy. Le composant Dispatcher permet désormais d'exécuter la 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, le composant Dispatcher peut fournir une fonction CBR (content-based routing) plus rapide que le composant CBR.
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 port stickytime 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 la fonction CBR de Dispatcher (méthode d'acheminement cbr), procédez aux opérations ci-dessous.
ndcontrol server add grappe:port:serveur mapport valeur returnaddress adresseretour router adresserouteur
ndcontrol 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 C, Syntaxe des règles de contenu (modèle).
Pour HTTPS (SSL) : pour configurer l'affinité de l'ID de session SSL, attribuez une valeur différente de zéro au paramètre stickytime du port. Pour plus d'informations sur le paramètre stickytime de la commande port, reportez-vous à la section ndcontrol rule -- configuration des règles.
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 Network Dispatcher.
Tableau 3. 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 pour 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 |
Il existe quatre méthodes de base pour la configuration 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 lancer Dispatcher à partir de la ligne de commande :
Vous pouvez entrer une version abrégée des paramètres de commandes ndcontrol. Il suffit d'entrer les lettres uniques des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, entrez ndcontrol he f à la place de ndcontrol help file.
Pour démarrer l'interface de ligne de commande, entrez ndcontrol pour ouvrir une invite ndcontrol.
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 Network Dispatcher.
ndcontrol file appendload mon_script
ndcontrol file newload mon_script
Pour avoir un exemple de l'interface graphique, reportez-vous à la Figure 2.
Pour démarrer l'interface graphique, procédez de la manière suivante :
ndserver
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 ndcontrol. Par exemple, pour définir une grappe à l'aide de la ligne de commande, vous devez entrer la commande ndcontrol cluster add cluster. 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 Network Dispatcher.
Les commandes de configuration peuvent également être exécutées à distance. Pour plus de détails, reportez-vous à la section Administration authentifiée à distance.
Vous pouvez accéder à l'aide en cliquant sur le point d'interrogation situé dans le coin supérieur droit de la fenêtre Network Dispatcher.
Pour plus de détails sur l'utilisation de l'interface graphique, reportez-vous à la section Instructions générales d'utilisation de l'interface graphique.
Pour plus d'informations sur l'utilisation de l'assistant de configuration, reportez-vous à la section Configuration à l'aide de l'assistant de configuration.
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 : Network Dispatcher peut avoir un serveur co-implanté. Ceci signifie simplement que Network Dispatcher 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 Mailbox Locator sur les cartes répertoriées dans le fichier ibmnd.conf, elles sont déconfigurées lors du lancement des commandes ndcontrol executor start ou ndcontrol 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 à l'Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator.
Pour plus d'informations sur le fichier de configuration type, reportez-vous à la section Exemples de fichiers de configuration Network Dispatcher.
AIX, Linux et Solaris : Pour lancer la fonction serveur, entrez ndserver.
Windows 2000 : La fonction serveur démarre automatiquement en tant que service.
Pour lancer la fonction exécuteur, tapez la commande ndcontrol executor start. Notez que vous pouvez également modifier divers paramètres de l'exécuteur à cette occasion. Reportez-vous à l'Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator.
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 ndcontrol 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 ndcontrol cluster add . Pour définir les options de grappe, tapez la commande ndcontrol 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, lancez la commande ndcontrol cluster 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 :
ndcontrol cluster 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 la grappe si vous utilisez le modèle de script goIdle, en mode autonome script. 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 grappe et fournir de manière explicite le nom et le masque de réseau de l'interface. Entrez la commande ndcontrol cluster configure adresse_grappe nom_interface sous-masque.
Exemple :
ndcontrol cluster configure 204.67.172.72 en0 255.255.0.0 (AIX) ndcontrol cluster configure 204.67.172.72 eth0:1 255.255.0.0 (Linux) ndcontrol cluster configure 204.67.172.72 le0:1 255.255.0.0 (Solaris 7) ndcontrol cluster configure 204.67.172.72 le0 255.255.0.0 (Solaris 8) ndcontrol cluster configure 204.67.172.72 en0 255.255.0.0 (Windows 2000)
Pour vous servir de l'autre forme de la commande de configuration de grappe 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 en0. De même, si vous ne disposez que d'une seule carte en anneau à jeton, l'interface portera le nom tr0. Si la machine comporte plusieurs cartes de l'un ou l'autre type, il est nécessaire de déterminer le mappage des cartes. Procédez comme suit :
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 ndconfig correspondent aux types d'interface. Par exemple, la commande ndconfig affecte la première interface Ethernet de la liste à en0, la deuxième à en1, et ainsi de suite ; la première interface 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 grappe exécute principalement ifconfig (ou ndconfig sous Windows 2000). Vous pouvez donc continuer d'utiliser les commandes ifconfig (ndconfig) si vous le souhaitez.
La commande ndconfig 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.
ndconfig 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 grappe.
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 Network Dispatcher. Par exemple :
arp -s <cluster> <adresse MAC Network Dispatcher> pub
Pour définir un port, entrez la commande ndcontrol 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 à l'Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator.
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 ndcontrol 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 ndcontrol 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 ndcontrol server, reportez-vous à la section ndcontrol server -- Configuration des serveurs.
La fonction gestionnaire permet d'améliorer l'équilibrage de charge. Pour lancer le gestionnaire, entrez la commande ndcontrol 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 :
cbrcontrol advisor start http portPour consulter la liste des conseillers et des ports par défaut correspondants, reportez-vous à l'Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator. Pour lire la description de chaque conseiller, reportez-vous à la section Liste des conseillers.
Si vous lancez 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, lancez la commande ndcontrol cluster set grappe niveau_importance_informations. Pour plus d'informations, voir 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 les méthodes 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, lancez 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, tel que HP-UX et OS/2, 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 4.
Tableau 4. 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 5.
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 5. 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 Network Dispatcher 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. Lancez la commande :
arp -s grappe adresse_mac_serveur
arp -d grappe
Pour les serveurs Linux exclusivement, un correctif spécifique (dépendant de la version du noyau Linux concernée) est 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 décrites ci-après.
Si vous utilisez le noyau 2.2.12 ou 2.2.13 sur un serveur périphérique.
Remarques :
Le correctif du noyau n'est pas requis pour toutes les configurations. Vous devez installer un correctif pour les versions 2.4.x du noyau Linux dans les cas suivants :
Vous pouvez télécharger ce correctif à partir du site : http://oss.software.ibm.com/developerworks/opensource/cvs/naslib
Sélectionnez CVS Tree dans la liste Download.
Pour appliquer le correctif :
cd /usr/src/linux-2.4/net/ipv4 patch -p0 -l < arp.c.2.4.0.patch
make dep;make clean;make bzImage;make modules;make modules_install cd arch/i386/boot cat bzImage > /boot/vmlinuz-2.4.2-2-arppatch cd /usr/src/linux-2.4 cp System.map /boot/System.map-2.4.2-2-arppatch cd /etc
Un correctif des versions 2.2.12 et 2.2.13 du noyau Linux doit être installé sur tout serveur utilisant la méthode d'acheminement MAC. Vous pouvez télécharger ce correctif à partir du site suivant :http://www.ibm.com/developer/linux.
Pour appliquer le correctif :
patch -p0 < fichier_correctif
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_invisible
Cette commande restera active jusqu'au réamorçage de la machine. Une fois la machine réamorcée, vous devrez répéter ces étapes et les étapes ultérieures.
ifconfig lo:1 cluster netmask 255.255.255.255 up
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.
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 groupe de serveurs devant prendre en charge une requête en fonction de son contenu. Le composant CBR vous permet de compartimenter votre site en plusieurs parties afin que chaque partie puisse être traitée par des groupes de serveurs différents. Cette répartition sera transparente pour les clients qui accéderont au site. 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.
Vous pouvez répartir votre site en affectant à certains serveurs le traitement de requêtes cgi uniquement, et en affectant à un autre groupe 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 groupe 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 groupe 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.
Caching Proxy communique avec CBR via son interface de plug-in. Caching Proxy, doit être installé sur la même machine. Désormais, plusieurs instances de Caching Proxy exécutée sur la même machine peuvent communiquer avec CBR simultanément. Dans les versions précédentes, seule une instance de Caching Proxy pouvait communiquer avec CBR.
CBR et Caching Proxy examinent les requêtes HTTP à l'aide des types de règle indiqués. Pendant l'exécution, Caching Proxy accepte les demandes client et interroge le composant CBR pour savoir quel est le meilleur serveur. Lorsqu'il reçoit cette demande, CBR la compare à un ensemble de règles prioritaires. Dès qu'il en trouve une qui correspond, un serveur approprié est sélectionné dans un groupe 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 aisé de 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é. Assurez-vous 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.)
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
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 Network Dispatcher.
Tableau 6. Tâches de configuration pour le composant CBR
Tâche | Description | Informations connexes |
---|---|---|
Configurer le poste CBR | Conditions requises | Configuration du poste CBR |
Configurer 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 |
Il existe quatre méthodes pour créer une configuration de base du composant CBR de Network Dispatcher :
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 lancer 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 uniques 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=http://10.1.203.4/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=http://10.1.203.4/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 myscript
cbrcontrol file newload myscript
Pour avoir un exemple de l'interface graphique, reportez-vous à la section Figure 2.
Pour démarrer l'interface graphique, procédez aux opérations décrites ci-dessous.
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é dans la partie supérieure de l'interface graphique permet de sauvegarder les connexions à l'hôte en cours dans un fichier ou de restaurer des connexions dans des fichiers existants sur tous les composants Network Dispatcher.
Vous pouvez accéder à l'Aide en cliquant sur le point d'interrogation situé dans le coin supérieur droit de la fenêtre Network Dispatcher.
Pour plus de détails sur l'utilisation de l'interface graphique, reportez-vous à la section Instructions générales d'utilisation de l'interface graphique.
Si vous utilisez l'Assistant de configuration, suivez la procédure ci-dessous :
Pour ce faire, lancez 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.
Windows 2000 : pour lancer Caching Proxy, accédez au panneau Services en procédant comme suit : Démarrer-> Paramètres-> Panneau de configuration -> Outils administratifs -> 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 dans un groupe de serveurs.
L'Assistant de configuration CBR vous proposera les panneaux suivants :
L'installation de la machine CBR ne peut être effectuée que par l'utilisateur root (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) :
Modifiez l'instruction URL entrante CacheByIncomingUrl de telle sorte qu'elle indique "on".
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 16. Fichier de configuration CBR pour AIX
ServerInit /usr/lpp/nd/servers/lib/libndcbr.so:ndServerInit PreExit /usr/lpp/nd/servers/lib/libndcbr.so:ndPreExit PostExit /usr/lpp/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /usr/lpp/nd/servers/lib/libndcbr.so:ndServerTerm
Figure 17. Fichier de configuration CBR pour Linux
ServerInit /opt/nd/servers/lib/libndcbr.so:ndServerInit PreExit /opt/nd/servers/lib/libndcbr.so:ndPreExit PostExit /opt/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /opt/nd/servers/lib/libndcbr.so:ndServerTerm
Figure 18. Fichier de configuration CBR pour Solaris
ServerInit /opt/nd/servers/lib/libndcbr.so:ndServerInit PreExit /opt/nd/servers/lib/libndcbr.so:ndPreExit PostExit /opt/nd/servers/lib/libndcbr.so:ndPostExit ServerTerm /opt/nd/servers/lib/libndcbr.so:ndServerTerm
Figure 19. Fichier de configuration CBR pour Windows 2000
Chemin d'accès courant au répertoire d'installation :
ServerInit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndServerInit PreExit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndPreExit PostExit c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndPostExit ServerTerm c:\Progra~1\IBM\edge\nd\servers\lib\libndcbr.dll:ndServerTerm
Chemin d'accès au répertoire d'installation natif :
ServerInit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndServerInit PreExit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndPreExit PostExit c:\Progra~1\IBM\nd\servers\lib\libndcbr.dll:ndPostExit ServerTerm c:\Progra~1\IBM\nd\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 ndcontrol executor -- Contrôle de l'exécuteur.
CBR équilibrera les requêtes envoyées à l'adresse de la grappe entre les serveurs correspondants configurés sur les ports de cette grappe.
L'adresse de grappe correspond à un nom symbolique ou à une notation décimale. Elle se trouve dans la partie hôte de l'URL.
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 Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator.
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 Network Dispatcher. 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 Tableau 7).
Tableau 7. 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 nnom_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 à la section Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator.
Les serveurs sont les postes qui exécutent les applications dont vous souhaitez équilibrer les charges. 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 cluster:port:rule type content pattern=pattern
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 Annexe C, 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, lancez la commande suivante :
cbrcontrol rule useserver cluster:port:rule server
La fonction gestionnaire permet d'améliorer l'équilibrage de charge. Pour lancer le gestionnaire, tapez la commande suivante :
cbrcontrol manager start
Les conseillers transmettent au gestionnaire des informations complémentaires sur la capacité des serveurs ayant fait l'objet d'un équilibrage de charge à répondre aux requêtes. 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 lancez 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 cluster proportions. Pour plus d'informations, voir Proportion de l'importance accordée aux données d'état.
/usr/lpp/nd/servers/lib
/opt/nd/servers/lib
Chemin d'accès courant au répertoire d'installation :
c:\Program Files\IBM\edge\nd\servers\lib
Chemin d'accès au répertoire d'installation natif :
c:\Program Files\IBM\nd\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.
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 Mailbox Locator.
Le présent chapitre se compose des sections suivantes :
Le composant Mailbox Locator permet d'acheminer le trafic IMAP et POP3 par proxy en fonction de l'ID utilisateur et du mot de passe de la demande client.
La structure de Mailbox Locator ressemble beaucoup à celle de Dispatcher. Mailbox Locator 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.
Les trois fonctions clés de Mailbox Locator(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.
Pour démarrer Mailbox Locator, lancez la commande mlserver à partir de l'invite.
Mailbox Locator peut fournir un point de présence unique à plusieurs serveurs IMAP ou POP3. Chaque serveur peut avoir un sous-ensemble de toutes les boîtes aux lettres dont la maintenance est assurée par le point de présence. Dans le cas des protocoles IMAP et POP3, Mailbox Locator est un proxy qui choisit un serveur approprié en se fondant sur l'ID utilisateur et le mot de passe donnés par le client.
Vous trouverez ci-dessous un exemple d'une méthode de distribution des demandes en fonction de l'ID utilisateur. Si vous avez deux serveurs POP3 (ou plus), vous pouvez choisir de diviser les boîtes aux lettres alphabétiquement par ID utilisateur. Les demandes client dont les ID commencent par les lettres A à I peuvent être distribuées au serveur 1. Les demandes client dont les ID commencent par les lettres J à R peuvent être distribuées sur le serveur 2, etc.
Vous pouvez également choisir que chaque boîte aux lettres soit représentée sur plusieurs serveurs. Dans ce cas, le contenu de chaque boîte aux lettres doit être disponible à tous les serveurs de cette boîte aux lettres. En cas de panne d'un serveur, un autre serveur peut toujours accéder à la boîte aux lettres.
Afin qu'une seule adresse représente plusieurs serveurs de courrier POP3, Mailbox Locator peut être configuré avec une seule adresse de grappe qui devient l'adresse du serveur de courrier POP3 pour tous les clients. Les commandes de configuration sont les suivantes :
mlcontrol cluster add pop3MailServer mlcontrol port add pop3MailServer:110 protocol pop3 mlcontrol server add pop3MailServer:110:pop3Server1+pop3Server2+pop3Server3
Dans cet exemple, pop3MailServer représente l'adresse de la grappe. Le port 110 avec POP3 comme protocole de commande proxy est ajouté au pop3MailServer. Pop3Server1, pop3Server2 et pop3Server3 représentent les serveurs de courrier POP3 qui sont ajoutés au port. Avec cette configuration, vous pouvez configurer vos requêtes POP3 entrantes du courrier client avec l'adresse de grappe pop3MailServer.
Lorsqu'une requête POP3 ou IMAP arrive sur le proxy, ce dernier tente de contacter tous les serveurs configurés pour le port qui utilise l'ID utilisateur et le mot de passe du client. La requête du client est dirigée vers le premier serveur qui répond. Vous devez utiliser la fonction temps de maintien/affinité en conjonction avec le composant Mailbox Locator pour les serveurs IMAP ou POP3. La fonction d'affinité permet de diriger les requêtes ultérieures provenant de l'ID utilisateur du même client vers le même serveur.
Attribuez au paramètre stickytime associé au port une valeur supérieure à zéro pour activer la fonction d'affinité. Pour plus d'informations sur la fonction d'affinité, reportez-vous à la section Fonctionnement de la fonction d'affinité pour Network Dispatcher
L'horloge d'autologout en cas d'inactivité est, respectivement pour les protocoles POP3 et IMAP, de 10 minutes et 30 minutes. Cette temporisation 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 optimiser les performances, Mailbox Locator remplace la valeur du délai d'inactivité par 60 secondes. Pour modifier le délai d'inactivité, remplacez la valeur staletimeout à l'aide de la commande mlcontrol port. Pour plus d'informations sur cette commande, reportez-vous à la section ndcontrol port -- Configuration des ports.
Avant d'effectuer les opérations décrites dans le présent chapitre, reportez-vous à la section Planification du composant Mailbox Locator. Ce chapitre décrit comment créer une configuration de base pour le composant Mailbox Locator de Network Dispatcher.
Tableau 8. Tâches de configuration du composant Mailbox Locator
Tâche | Description | Informations connexes |
---|---|---|
Configurer la machine Mailbox Locator. | Conditions requises | Installation de la machine Mailbox Locator |
Configurer des machines en vue de l'équilibrage de charge | Définition de la configuration de l'équilibrage de charge. | Etape 4. Définition des serveurs avec équilibrage de charge |
Pour créer une configuration de base pour le composant Mailbox Locator de Network Dispatcher, il existe quatre méthodes :
Il s'agit de la méthode la plus directe pour la configuration de Mailbox Locator. 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 et server) et aux noms de fichiers.
Pour lancer Mailbox Locator à partir de la ligne de commande :
Vous pouvez entrer une version abrégée des paramètres de commande mlcontrol. Il suffit d'entrer les lettres uniques des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, vous pouvez entrer mlcontrol he f au lieu de mlcontrol help file.
Pour démarrer l'interface de ligne de commande, entrez mlcontrol pour obtenir une invite mlcontrol.
Pour fermer l'interface de ligne de commande, entrez exit ou quit.
Les commandes permettant de configurer Mailbox Locator peuvent être entrées dans un fichier script de configuration, puis exécutées ensemble.
mlcontrol file appendload monscript
mlcontrol file newload monscript
Reportez-vous à la section Figure 2 pour consulter un exemple de l'interface graphique.
Pour démarrer l'interface graphique, procédez de la manière suivante :
Pour pouvoir configurer le composant Mailbox Locator à partir de l'interface graphique, vous devez d'abord sélectionner Mailbox Locator 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 normalement exécutée par la commande mlcontrol. Par exemple, pour définir une grappe à l'aide de la ligne de commande, vous devez entrer la commande mlcontrol cluster add grappe. Pour définir une grappe à partir de l'interface graphique, cliquez avec le bouton droit de la souris sur Exécuteur, puis dans le menu en incrustation qui apparaît, cliquez sur le bouton Ajouter 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 Mailbox Locator existants peuvent être chargés à l'aide des options Charger la nouvelle configuration (pour remplacer intégralement la configuration en cours) et Ajouter à la configuration en cours (pour la mise à jour de la configuration en cours) du menu en incrustation Hôte. Vous devez sauvegarder votre configuration Mailbox Locator dans un fichier régulièrement en utilisant l'option Sauvegarder le fichier de configuration en dans le menu en incrustation Hôte. Le menu Fichier situé dans la partie supérieure de l'interface graphique permet de sauvegarder les connexions à l'hôte en cours dans un fichier ou de restaurer des connexions dans des fichiers existants sur tous les composants Network Dispatcher.
Vous pouvez accéder à l'Aide en cliquant sur le point d'interrogation situé dans le coin supérieur droit de la fenêtre Network Dispatcher.
Pour plus de détails sur l'utilisation de l'interface graphique, reportez-vous à la section Instructions générales d'utilisation de l'interface graphique.
Si vous utilisez l'Assistant de configuration, suivez la procédure ci-dessous :
Vous pouvez lancer cet assistant à partir de l'invite en entrant la commande mlwizard ou sélectionnez l'assistant de configuration à partir du menu du composant Mailbox Locator présenté dans l'interface graphique.
L'assistant Mailbox Locator vous guide pas à pas dans le processus de création d'une configuration de base pour le composant Mailbox Locator. Il vous demande des renseignements sur votre réseau et vous guide pour la configuration d'une grappe permettant à Mailbox Locator d'équilibrer le trafic entre un groupe de serveurs.
L'assistant de configuration Mailbox Locator propose les panneaux suivants :
L'installation de la machine Mailbox Locator ne peut être effectuée que par l'utilisateur root (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. Toutes les demandes envoyées à la même adresse de grappe font l'objet d'un équilibrage de charge par Mailbox Locator.
Pour démarrer la fonction serveur, entrez mlserver à partir de la ligne de commande.
Mailbox Locator équilibrera les demandes envoyées à l'adresse de la grappe entre les serveurs correspondants configuré sur les ports de la grappe.
L'adresse de grappe correspond à un nom symbolique ou à une notation décimale.
Pour définir une grappe, tapez la commande suivante :
mlcontrol cluster add grappe
Pour définir les options de grappe, tapez la commande suivante :
mlcontrol cluster set cluster option value
Pour plus d'informations, reportez-vous à la section Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator.
Le numéro de port est le port à partir duquel les applications serveur sont à l'écoute. Pour le trafic IMAP, il s'agit généralement du port 143 et pour le trafic POP3 du port 110.
Pour définir le port de la grappe définie à l'étape précédente, entrez la commande
mlcontrol port add grappe:port protocol [pop3|imap]
Pour définir les options de port, tapez la commande suivante :
mlcontrol port set grappe:port option valeur
Pour plus d'informations, reportez-vous à la section Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator.
Les serveurs de messagerie 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 de l'étape 3, tapez la commande suivante :
mlcontrol server add cluster:port:server
Vous devez définir un ou plusieurs serveurs par port sur une grappe pour pouvoir procéder à l'équilibrage des charges.
La fonction gestionnaire permet d'améliorer l'équilibrage de charge. Pour lancer le gestionnaire, tapez la commande suivante :
mlcontrol manager start
Les conseillers transmettent au gestionnaire des informations complémentaires sur la capacité des serveurs ayant fait l'objet d'un équilibrage de charge à répondre aux requêtes. Chaque conseiller est spécifique à un protocole. Le système Network Dispatcher fournit les conseillers IMAP et POP3. Par exemple, pour lancer le conseiller IMAP, entrez la commande suivante :
mlcontrol advisor start imap portPour consulter la liste des conseillers et des ports par défaut correspondants, reportez-vous à l'Annexe B, Guide des commandes Dispatcher, CBR et Mailbox Locator. Pour lire la description de chaque conseiller, reportez-vous à la section Liste des conseillers.
Si vous lancez 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 mlcontrol cluster set grappe proportions. Pour plus d'informations, reportez-vous à la section Proportion de l'importance accordée aux données d'état.
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 20. 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 20), 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 11 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 à Annexe D, 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 Network Dispatcher.
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 | Installation de la configuration de l'équilibrage de charge. | Etape 4. Définition de serveurs avec équilibrage de charge |
Il existe quatre méthodes pour créer une configuration de base du composant Site Selector de Network Dispatcher :
C'est la méthode la plus directe pour la configuration de Site Selector. 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 site name et server) et aux noms de fichiers.
Pour lancer 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
Reportez-vous à la section Figure 2 pour consulter un exemple de l'interface graphique.
Pour démarrer l'interface graphique, procédez de la manière suivante :
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 avec le 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é dans la partie supérieure de l'interface graphique permet de sauvegarder les connexions à l'hôte en cours dans un fichier ou de restaurer des connexions dans des fichiers existants sur tous les composants Network Dispatcher.
Vous pouvez accéder à l'Aide en cliquant sur le point d'interrogation situé dans le coin supérieur droit de la fenêtre Network Dispatcher.
Pour plus de détails sur l'utilisation de l'interface graphique, reportez-vous à la section Instructions générales d'utilisation de l'interface graphique.
Si vous utilisez l'Assistant de configuration, suivez la procédure ci-dessous :
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'assistant de configuration Site Selector vous proposera les panneaux suivants :
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 lancer 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, lancez la commande suivante :
sscontrol sitename add nom_site
Pour définir les options du nom de site, lancez la commande suivante :
sscontrol sitename set valeur_option_nom_site
Pour plus d'informations, reportez-vous à l'Annexe D, 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, lancez 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 lancer 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. La fonction Network Dispatcher 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 lancez 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, lancez 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.
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 Consultant for Cisco CSS Switches.
Le présent chapitre se compose des sections suivantes :
La configuration de Cisco Consultant dépend de la configuration de Cisco CSS Switch (voir Tableau 10). Une fois la planification et la configuration de Cisco CSS Switch terminée, vous pouvez configurer et utiliser Cisco Consultant. Consultez la documentation Cisco CSS Switch pour des instructions relatives à la planification et à la configuration.
Consultant se compose des fonctions suivantes :
Les conseillers interrogent les serveurs puis analysent les résultats par protocole avant de demander au gestionnaire de régler les capacités comme il convient. Actuellement, Cisco Consultant fournit entre autres les conseillers suivants : HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3. 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 recommandée, mais reste facultative.
Metric Server fournit à Consultant les informations de téléchargement sous la forme de mesures spécifiques du système, relatives à l'état du serveur. Le gestionnaire interroge les instances Metric Server qui résident sur chaque serveur, et utilise les mesures recueillies à partir des agents pour contribuer à l'attribution de pondérations au processus d'équilibrage de charge. Les résultats sont regroupés dans le rapport du gestionnaire.
Le gestionnaire recueille des informations provenant de Cisco CSS Switch, des conseillers et de Metric Server. Selon les informations qu'il reçoit, il ajuste la pondération des machines serveur sur chaque port et transmet ces nouvelles données à Cisco CSS Switch qui en tient compte pour l'équilibrage des nouvelles connexions. Lorsque le gestionnaire découvre qu'un serveur est arrêté, il lui associe la pondération zéro et le serveur est interrompu. Par conséquent, Cisco CSS Switch arrête d'acheminer le trafic vers ce serveur.
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.
Pour que la configuration de Consultant soit correcte, elle doit refléter celle de Cisco CSS Switch. Tout d'abord, reportez-vous au manuel Cisco Services Switch Getting Started Guide pour configurer Cisco CSS Switch. Vérifiez que Switch fonctionne correctement et configurez Consultant.
La configuration Cisco CSS Switch se compose de propriétaires, de règles de
contenu et de services qui correspondent à une configuration Consultant, comme
expliqué dans le tableau ci-dessous.
Tableau 10. Configuration de Consultant et de Cisco CSS Switch
Cisco CSS Switch | Consultant |
---|---|
Adresse IP virtuelle (VIP) d'une ou plusieurs règles de contenu du propriétaire | grappe |
port contenu dans la règle de contenu | port |
service | serveur |
L'arborescence de configuration de Consultant se compose des éléments suivants :
Dans la Figure 21 :
Lors de la configuration de l'exécuteur, vous devez définir une
adresse et un nom de communauté SNMP, qui doivent correspondre aux attributs
de Cisco CSS Switch. Reportez-vous à la section lbccontrol executor -- Contrôle de l'exécuteur pour des informations sur la configuration de
l'exécuteur.
Configuration Cisco CSS Switch | Configuration Consultant |
---|---|
username admin superuser snmp community community private read-write |
lbccontrol executor set address 10.10.20.1 lbccontrol executor set communityname community |
content rule1 port 80 balance weightedrr add service server1 add service server2 vip address 9.67.154.35 activ. |
lbccontrol cluster add 9.67.154.35 lbccontrol port add 9.67.154.35:80 |
content rule 2 protocol tcp port 443 balance weightedrr add service server3 add service server4 vip address 9.67.154.35 activ. |
lbccontrol port add 9.67.154.35:443 |
service server1 ip address 10.10.20.2 port 80 weight 4 activ. |
lbccontrol server add 9.67.154.35:80:server1 address 10.10.20.2 |
service server3 ip address 10.10.20.4 port 443 weight 4 activ. |
lbccontrol server add 9.67.154.35:443:server3 address 10.10.20.4 |
Avant d'effectuer les opérations décrites dans le présent chapitre, reportez-vous à la section Planification du composant Consultant for Cisco CSS Switches. Ce chapitre décrit comment créer une configuration de base pour le composant Consultant for Cisco CSS Switches d'Network Dispatcher.
Avant de suivre une des méthodes de configuration décrites dans ce chapitre :
Tableau 12. Tâches de configuration du composant Consultant for Cisco CSS Switches
Tâche | Description | Informations connexes |
---|---|---|
Configuration de la machine Consultant for Cisco CSS Switches | Conditions requises | Installation de la machine Consultant for Cisco CSS Switches |
Test de la configuration | Confirmation du bon fonctionnement de la configuration | Test de vérification de la configuration |
Pour créer une configuration de base pour le composant Consultant for Cisco CSS Switches de Network Dispatcher, il existe trois méthodes :
C'est la méthode la plus directe pour la configuration de Cisco Consultant. 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 dans les commandes cluster et server) et aux noms de fichiers.
Pour lancer Cisco Consultant à partir de la ligne de commande :
Vous pouvez entrer une version abrégée des paramètres de contrôle lbccontrol. Il suffit d'entrer les lettres spécifiques des paramètres. Par exemple, pour l'aide correspondant à la commande file save, entrez lbccontrol he f à la place de lbccontrol help file.
Pour démarrer l'interface de ligne de commande, entrez lbccontrol pour obtenir une invite lbccontrol.
Pour fermer l'interface de ligne de commande, entrez exit ou quit.
Les commandes permettant de configurer Consultant for Cisco CSS Switches peuvent être entrées dans un fichier script de configuration puis exécutées ensemble.
lbccontrol file appendload monscript
lbccontrol file newload monscript
Pour avoir un exemple de l'interface graphique, reportez-vous à la section Figure 2.
Pour démarrer l'interface graphique, procédez de la manière suivante :
lbcserver.
Pour configurer le composant Cisco Consultant à partir de l'interface graphique :
Vous pouvez utiliser l'interface graphique pour toute opération effectuée via la commande lbccontrol. Par exemple, pour définir une grappe à l'aide de la ligne de commande, vous devez entrer la commande lbccontrol cluster add cluster. Pour définir une grappe à partir de l'interface graphique, cliquez avec le bouton droit de la souris sur Exécuteur, puis cliquez sur Ajouter une grappe. Entrez l'adresse de la grappe dans la fenêtre en incrustation, puis cliquez sur OK.
Vous pouvez utiliser les options Charger la nouvelle configuration (pour le remplacement total de la configuration en cours) et Ajouter à la configuration en cours (pour la mise à jour de la configuration en cours) se trouvant dans le menu en incrustation Hôte afin de charger les fichiers de configuration Cisco Consultant pré-existants. Sélectionnez l'option Sauvegarder le fichier de configuration en pour sauvegarder de façon régulière la configuration Cisco Consultant dans un fichier. Cliquez sur Fichier dans la barre de menus afin 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 Network Dispatcher.
Pour accéder à l'aide, cliquez sur l'icône en forme de point d'interrogation située dans le coin supérieur droit de la fenêtre Network Dispatcher.
Pour plus de détails sur l'utilisation de l'interface graphique, reportez-vous à la section Instructions générales d'utilisation de l'interface graphique.
L'installation de la machine Consultant for Cisco CSS Switches ne peut être effectuée que par l'utilisateur root (pour 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 de l'exécuteur, vous devez configurer une adresse et un nom de communauté SNMP, qui doivent correspondre aux attributs sur Cisco CSS Switch.
Pour obtenir une aide sur les commandes utilisées lors de cette procédure, reportez-vous à l'Annexe E, Guide des commandes Consultant for Cisco CSS Switches.
Si lbcserver n'est pas déjà en cours d'exécution, lancez-le maintenant à l'aide de la commande indiquée ci-après. Pour effectuer cette opération, vous devez disposer des droits root.
lbcserver
Vous devez configurer une adresse et un nom de communauté SNMP. Ces valeurs doivent correspondre aux attributs équivalents sur Cisco CSS Switch.
Une grappe est un nom pouvant être résolu ou une adresse à notation décimale à point. La grappe correspond à l'adresse IP virtuelle de Cisco CSS Switch d'une règle de contenu de propriétaire.
Pour définir une grappe, entrez lbccontrol cluster add grappe. Pour définir les options de grappe, entrez lbccontrol cluster set.
Pour définir un port, entrez lbccontrol port add grappe:port. Le port correspond au port configuré dans la règle de contenu Cisco CSS Switch pour le propriétaire.
Port est le numéro du port que vous utilisez pour ce protocole comme il est indiqué dans la règle de contenu du propriétaire pour Cisco CSS Switch. Pour de plus amples informations, reportez-vous à la section lbccontrol port -- Configuration des ports.
Vous pouvez configurer plusieurs instances du même serveur dans une grappe et un port. (N'oubliez pas que l'adresse et le nom de la communauté SNMP doivent correspondre aux attributs équivalents de Cisco CSS Switch.) Lorsque vous configurez plusieurs instances sur le même serveur, vous pouvez faire la différence entre plusieurs serveurs d'applications qui se trouvent sur la même machine physique et répondent à la même adresse IP sur le même port.
Pour définir un serveur avec équilibrage de charge, entrez :
lbccontrol server add grappe:port:serveur address x.x.x.x | nomhôte
Le serveur correspond au nom du service Cisco CSS Switch.
Pour effectuer l'équilibrage de charge, vous devez définir plusieurs serveurs sur un port d'une grappe ou le trafic ne sera dirigé que vers un seul serveur. Reportez-vous à la rubrique Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
Pour plus d'informations sur la syntaxe de la commande lbccontrol, reportez-vous à la rubrique lbccontrol server -- Configuration des serveurs.
Pour lancer le gestionnaire, entrez la commande lbccontrol manager start. Pour de plus amples informations, reportez-vous à la section lbccontrol manager -- Contrôle du gestionnaire.
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 :
lbccontrol advisor start http portPour consulter la liste des conseillers et des ports par défaut correspondants, reportez-vous à la section lbccontrol advisor -- Contrôle du conseiller. Pour lire la description de chaque conseiller, reportez-vous à la section Liste des conseillers.
Si vous lancez un conseiller, vous devez modifier le niveau d'importances des informations de la grappe afin que ces dernières soient incluses dans les décisions d'équilibrage de charge. Utilisez la commande lbccontrol cluster proportions. Reportez-vous à la section Proportion de l'importance accordée aux données d'état.
Pour obtenir plus d'informations sur Metric Server, reportez-vous à la section Metric Server.
Vérifiez que la configuration fonctionne.
Le présent chapitre explique comment configurer les paramètres d'équilibrage de charge de Network Dispatcher et comment configurer les fonctions avancées de Network Dispatcher.
Tableau 13. Tâches de configuration avancées pour Network Dispatcher
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 Network Dispatcher |
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 | Network Dispatcher 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 et création de conseillers personnalisés | Décrit les conseillers ainsi que le mode de développement de vos propres conseillers pour reporter les états spécifiques des serveurs | Conseillers Création de conseillers personnalisés |
Utilisation du conseiller WLM (Workload Manager) | Le conseiller WLM fournit des informations de chargement à Network Dispatcher | Conseiller Workload Manager |
Utilisation de l'agent Metric Server | Le système Metric Server fournit des informations de chargement à Network Dispatcher | Metric Server |
Utilisation du partitionnement du serveur | Définit les serveurs logique devant distribuer la charge en fonction de services fournis | Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP) |
Utilisation de l'option demande/réponse (URL) | Définit une chaîne HTTP URL client unique propre à un service que vous voulez demander sur la machine | Option de demande/réponse (URL) de conseiller HTTP |
Placement de Network Dispatcher sur une machine d'équilibrage de charge | Configure une machine Network Dispatcher co-implanté. | Utilisation de serveurs implantés au même endroit |
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 |
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 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 fonction de maintien de routage 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 Network Dispatcher |
Utilisation de l'API SDA (Server Directed Affinity) | Fournit un API qui permet à un agent externe d'influencer le comportement de l'affinité Dispatcher. | API SDA pour le contrôle de l'affinité client/serveur |
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é |
Utilisation de la substitution d'affinité de règle 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 règle |
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 |
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 journalisation 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 journalisation binaire pour analyser les statistiques des serveurs |
Utilisation de Cisco Consultant (informations supplémentaires) | Interaction de Cisco Consultant avec Cisco CSS Switch et informations supplémentaires sur la configuration des pondérations. | Informations supplémentaires sur les fonctions Cisco Consultant avancées |
La fonction gestionnaire de Network Dispatcher 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 du Dispatcher.
Pour définir la proportion des valeurs d'importance, utilisez la commande ndcontrol cluster set grappe proportions. Pour de plus amples informations, reportez-vous à la section ndcontrol 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 ndcontrol 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 pondération maximale d'un serveur, entrez la commande ndcontrol port set weightbound. 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 de serveur ndcontrol. Par exemple :
ndcontrol server set grappe:port:serveur fixedweight yes
Une fois la valeur yes attribuée à l'option fixedweight, utilisez la commande ndcontrol 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 ndcontrol en attribuant la valeur no à l'option fixedweight. Pour obtenir plus d'informations, reportez-vous à la section ndcontrol server -- Configuration des serveurs.
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 ndcontrol manager interval et ndcontrol 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 :
ndcontrol 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 :
ndcontrol manager refresh 3
Après cette commande, le gestionnaire devra patienter 3 intervalles avant de demander des données d'état à l'exécuteur.
Network Dispatcher offre d'autres méthodes d'optimisation de l'équilibrage de charge des serveurs. 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 :
ndcontrol 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 index de filtrage. L'index de filtrage limite l'écart de pondération d'un serveur, filtrant et uniformisant effectivement la variation dans la répartition des demandes. Plus l'index de filtrage sera élevé, moins les pondérations des serveurs varieront. Plus l'index de filtrage sera faible, plus les pondérations des serveurs changeront. La valeur par défaut de l'index de filtrage 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'index de filtrage à 4, entrez la commande suivante :
ndcontrol manager smoothing 4
Dans la plupart des cas, vous n'aurez pas besoin de modifier cette valeur.
Network Dispatcher 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. Des scripts exemples, qu'il est possible de personnaliser, se trouvent dans le répertoire d'installation ...nd/servers/samples. Afin d'exécuter les fichiers, vous devez les déplacer dans le répertoire ...nd/servers/bin et supprimer l'extension de fichier ".sample". Les scripts exemples suivants sont fournis :
Les conseillers sont des agents de Network Dispatcher. 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 Network Dispatcher ne présente aucun intérêt. (Par exemple, vous ne pouvez pas utiliser le conseiller Telnet avec le composant CBR.) Network Dispatcher prend également en charge le concept de "conseiller personnalisé" permettant aux utilisateurs d'écrire leurs propres conseillers.
Restriction affectant les applications serveur de liaison sous Linux : Sous Linux, Network Dispatcher ne permet pas l'utilisation de conseillers lors de l'équilibrage de la charge des serveurs de liaison (autres composants Network Dispatcher tels que Mailbox Locator ou Site Selector compris) lorsqu'ils sont reliés à l'adresse IP de la grappe.
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.
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 Network Dispatcher est défini avec trois grappes (grappe A, grappe B, grappe C), pour chaque grappe le port 80 a une fonction différente.
ndcontrol 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.
ndcontrol 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).
ndcontrol advisor stop ADV_personnalisé grappeB:80
ndcontrol 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 :
ndcontrol 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 illimitée.
Par exemple, pour fixer à 30 secondes l'intervalle du conseiller HTTP sur le port 80, entrez la commande suivante :
ndcontrol 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 ndcontrol advisor -- Contrôle du conseiller.
Pour Network Dispatcher, vous pouvez définir les valeurs de délai du conseiller lorsqu'une erreur serveur 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 :
ndcontrol advisor connecttimeout http 80 9 ndcontrol 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.
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 lancement 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 Network Dispatcher. Une fois l'installation de Network Dispatcher effectuée, le code exemple se trouve dans le répertoire d'installation ...nd/servers/samples/CustomAdvisors.
Les répertoires d'installation par défaut sont :
Des fichiers exemple de conseiller personnalisé spécifiques au conseiller WebSphere Application Server sont fournis dans le répertoire d'installation de Network Dispatcher.
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, assurez-vous de 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>\nd\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 ...nd/servers/lib/CustomAdvisors dans lequel Network Dispatcher est installé.
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 sous-répertoire Network Dispatcher approprié :
.../nd/servers/lib/CustomAdvisors/ADV_fred.class
Configurez le composant, lancez la fonction gestionnaire, puis exécutez la commande permettant de lancer le conseiller personnalisé.
ndcontrol 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.
Network Dispatcher consulte tout d'abord la liste des conseillers en langage naturel. S'il ne trouve pas listeacheteurun conseiller donné, Network Dispatcher consulte la liste des conseillers personnalisés du client.
/usr/lpp/nd/servers/lib/CustomAdvisors/
/opt/nd/servers/lib/CustomAdvisors/
/opt/nd/servers/lib/CustomAdvisors/
Chemin d'accès au répertoire d'installation commun :
C:\Program Files\IBM\edge\nd\servers\lib\CustomAdvisors
Chemin d'accès au répertoire d'installation natif :
C:\Program Files\IBM\nd\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 ...nd/servers/samples/CustomAdvisors.
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.
Cette fonction est disponible pour tous les composants Network Dispatcher.
Metric Server fournit à Network Dispatcher les informations de téléchargement sous la forme de données numériques-système, relatives à l'état du serveur. Le gestionnaire Network Dispatcher 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 11.
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 de Metric Server doit être installé et en cours d'exécution sur les serveurs pour lesquels Network Dispatcher effectue l'équilibrage de charge.
La procédure ci-après permet de configurer Metric Server pour Network Dispatcher. Vous pouvez configurer Metric Server pour les autres composants de Network Dispatcher à 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 qu'ils se trouvent dans le répertoire ...nd/ms/script. Les scripts personnalisés doivent renvoyer une valeur de charge comprise entre 0-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 ***.
Lors de la définition d'un serveur dans la configuration Network Dispatcher, vous pouvez distribuer la charge en fonction de l'état du serveur dans son ensemble (à l'aide de l'agent du système Metric Server) et/ou de l'état de toute application spécifique du port (à l'aide de la fonction conseiller).
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 plusieurs pages JSP, pages HTML, requêtes de base de données, etc. Network Dispatcher 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 à Network Dispatcher 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.
Dans la configuration de Network 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 ndcontrol server add. Pour de plus amples informations, reportez-vous à la section ndcontrol server -- Configuration des serveurs.
Ci-dessous se trouve 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).
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 à 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"
ndcontrol server set grappe:port:serveur advisorrequest "\"head / http/2.0\"" ndcontrol server set grappe:port:serveur advisorresponse "\"HTTP 200 OK\""
Network Dispatcher peut se trouver sur la même machine qu'un serveur pour lequel il effectue des demandes d'équilibrage de charge. On parle alors de co-implantation d'un serveur. La co-implantation s'applique aux composants Dispatcher, Site Selector, Mailbox Locator et Cisco Consultant. 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.
Red Hat Linux v7.1 (Linux kernel version 2.4.2-2) ou SuSE Linux v7.1 (Linux kernel version 2.4.0-4Go) : 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 : Il existe une restriction. Il n'est pas possible de configurer de conseillers WAND lorsqu'un composant Dispatcher de point d'entrée est co-implanté. Reportez-vous à la section Utilisation de conseillers éloignés avec le support de réseau étendu.
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 ndcontrol 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 obtenir des informations plus détaillées sur la syntaxe de la commande ndcontrol server, reportez-vous à la section ndcontrol server -- Configuration des serveurs.
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.
Mailbox Locator prend en charge la co-implantation sur toutes les plate-formes. Cependant, le serveur doit être associé à une adresse différente que celle de Network Dispatcher. Afin de co-implanter un serveur POP3 ou IMAP sur la même machine, il doit être lié à une adresse IP différente de l'adresse de la grappe. Cela peut être effectué en utilisant une adresse de bouclage.
Site Selector prend en charge la co-implantation sur toutes les plate-formes sans qu'aucune configuration supplémentaire ne soit requise.
Cisco Consultant prend en charge la co-implantation sur toutes les plate-formes sans qu'aucune configuration supplémentaire ne soit requise.
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 22). Un paquet émis par un client est transmis au répartiteur, envoyé au serveur, puis renvoyé au client.
Figure 22. 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 23). 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 23. 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 :
ndcontrol server add grappe:port:serveur router adresse
Pour obtenir plus d'informations sur le mot clé router, reportez-vous à la section ndcontrol server -- Configuration des serveurs.
Sur les répartiteurs de base, les conseillers fonctionnent correctement sans configuration particulière pour la plupart des plate-formes.
Linux : Des restrictions affectent l'utilisation des conseillers éloignés avec des configurations de support de réseau étendu. Les conseillers de protocole, tels que le conseiller HTTP, qui s'exécutent sur la machine Dispatcher de point d'entrée ne peuvent évaluer correctement l'état des serveurs du site distant. Pour remédier à ce problème, effectuez l'une des opérations suivantes :
Ces deux options fournissent au conseiller qui s'exécute sur la machine Dispatcher de point d'entrée une évaluation de l'état de la machine Dispatcher éloignée.
Solaris : Dans les composants Network Dispatcher de point d'entrée, vous devez utiliser la méthode de configuration arp (au lieu des méthodes de configuration ifconfig ou cluster). Par exemple :
arp -s <mon_adresse_grappe> <mon_adresse_mac> pub
Sur les répartiteurs éloignés, vous devez exécuter les étapes de configuration suivantes pour chaque adresse de grappe éloignée. Pour une configuration de haute disponibilité à l'emplacement Network Dispatcher é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
ndconfig en0 alias 9.55.30.45 netmask 255.255.240.0
arp -a
arp -d 9.67.34.123
et recherchez l'adresse de votre machine.
route add 9.67.34.123 mask 255.255.255.255 9.55.30.45
Figure 24. Exemple de configuration en réseau étendu avec des composants Network Dispatcher éloignés
Cet exemple s'applique à la configuration illustrée à la Figure 24.
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. ND1 est défini comme "point d'entrée". Il est supposé qu'une connexion Ethernet est utilisée. ND1 comporte cinq serveurs définis : trois serveurs locaux (ServeurA, ServeurB, ServeurC) et deux serveurs éloignés (ND2 et ND3). Par ailleurs, trois serveurs locaux ont été définis pour chacun des serveurs éloignés ND2 et ND3.
Sur la console de la première machine Dispatcher (ND1), procédez comme suit :
ndcontrol executor start
ndcontrol executor set nfa ND1
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND1 Configurez également xebec en tant que clusteraddr.
ndcontrol cluster configure xebec
Sur la console de la deuxième machine Dispatcher (ND2) :
ndcontrol executor start
ndcontrol executor set nfa ND2
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND2
Sur la console de la troisième machine Dispatcher (ND3) :
ndcontrol executor start
ndcontrol executor set nfa ND3
ndcontrol cluster add xebec
ndcontrol port add xebec:80
ndcontrol cluster configure ND3
GRE (Generic Routing Encapsulation) est un protocole Internet défini dans RFC 1701 et RFC 1702. Lorsque vous utilisez GRE, Network Dispatcher peut encapsuler les paquets IP de clients dans des paquets IP/GRE et les transmettre aux plate-formes 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.
Network Dispatcher implémente GRE comme faisant partie de la fonction WAND (wide area Network Dispatcher). Ainsi, Network Dispatcher 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 Network Dispatcher soit installé sur le site éloigné si les serveurs éloignés prennent en charge les paquets GRE encapsulés. Network Dispatcher encapsule les paquets WAND, la valeur décimale 3735928559 étant attribuée à l'ensemble de zones de clés GRE.
Dans cet exemple,e (Figure 25), afin d'ajouter le serveurD éloigné, qui prend en charge GRE, définissez-le dans la configuration Network Dispatcher comme si vous définissiez un serveur WAND dans la hiérarchie grappe:port:serveur :
ndcontrol server add grappe:port:ServeurD routeur Routeur1
Le conseiller self est disponible dans le composant Dispatcher.
Lorsque Network Dispatcher se trouve dans une configuration WAND (wide area Network Dispatcher) à deux niveaux, un conseiller self est fourni qui rassemble des informations de statut de chargement sur les serveurs périphériques.
Figure 26. Exemple de configuration WAND à 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 Network Dispatcher se trouvant au 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 fichier self inscrit les résultats dans le fichier ndloadstat. Network Dispatcher fournit également une mesure externe appelée ndload. L'agent du système Metric Server de chaque machine Dispatcher exécute son fichier de configuration qui appelle le script ndload de mesure externe. Le script ndload extrait une chaîne du fichier ndloadstat 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 Network Dispatcher 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 ndload se trouve dans le répertoire .../nd/ms/script pour Network Dispatcher.
La fonction haute disponibilité est disponible uniquement pour le composant Dispatcher.
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 haute disponibilité ndcontrol se trouve dans ndcontrol 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 par la commande ndconfig. Par exemple :
ndconfig en0 adr_nfa netmask masqueréseau
ndcontrol cluster set clusterA primaryhost NFAdispatcher1 ndcontrol cluster set clusterB primaryhost NFAdispatcher2
ndcontrol cluster set clusterB primaryhost NFAdispatcher2 ndcontrol cluster set clusterA primaryhost NFAdispatcher1
ndcontrol 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.
ndcontrol highavailability reach add 9.67.125.18Les cibles à atteindre sont recommandées mais pas obligatoires. Reportez-vous à Détections des incidents en utilisant signal de présence et cible à atteindre, pour de plus amples informations.
ndcontrol highavailability backup add primary [auto | manual] port
ndcontrol highavailability backup add backup [auto | manual] port
ndcontrol highavailability backup add both [auto | manual] port
ndcontrol highavailability statusChacune des machines doit avoir le rôle (primaire, 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 lancement, 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. Des scripts exemple sont disponibles dans le répertoire ...nd/servers/samples et doivent être déplacés dans le répertoire ...nd/servers/bin afin de 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. Network Dispatcher 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 à la section Annexe C, 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 ndcontrol rule. Par exemple :
ndcontrol 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 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 dans le composant Dispatcher et CBR.
Vous pouvez souhaiter utiliser des règles basées sur le nombre de connexions par seconde d'un port 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.
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 ndcontrol rule ou cbrcontrol rule. Par exemple :
ndcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 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.
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 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 ndcontrol 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 :
ndcontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
L'utilisation de la capacité et les règles de largeur de bande sont disponibles uniquement dans le composant Dispatcher.
Via la fonction d'utilisation de la capacité, Dispatcher mesure le montant des données transmises à chaque serveur. 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 nouvelle contre-valeur d'octet : les kilo-octets transmis par seconde. La valeur (kilo-octets transférés par seconde) est calculée sur un intervalle de 60 secondes. Vous pouvez consulter ces valeurs de capacité dans l'interface ou dans la sortie d'un rapport de ligne de commande.
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. Lorsque le trafic dépasse le seuil de largeur de bande réservée, vous pouvez effectuer une des actions suivantes :
En utilisant la règle de largeur de bande partagée avec la règle de largeur de bande réservée, comme il est décrit ci-dessus, vous pouvez fournir aux clients préférés un accès au serveur plus rapide et ainsi améliorer les performances liées aux transactions. Par exemple, en utilisant la règle de largeur de bande partagée afin d'exploiter la largeur de bande non utilisée, vous pouvez permettre aux clients d'effectuer des affaires sur des grappes de serveurs. Ainsi l'accès est plus important que lorsque les clients utilisent d'autres grappes de serveurs pour la recherche d'investissements.
Prenez en compte les éléments suivants afin de déterminer si les règles de largeur de bande peuvent vous aider à gérer le volume du trafic de réponses des serveurs vers les clients :
Ce type de règle est disponible uniquement avec le composant Dispatcher.
La règle de largeur de bande réservée permet d'effectuer l'équilibrage de charge en fonction du 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. Ci-dessous, se trouve un exemple permettant d'ajouter une règle de largeur de bande réservée :
ndcontrol 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.
Ce type de règle est disponible uniquement avec le composant Dispatcher.
Si le montant de données transférées dépasse la limite de la règle de la largeur de bande réservée, la règle de largeur de bande partagée vous permet d'exploiter la largeur de bande non utilisée disponible sur le site. Vous pouvez configurer cette règle afin de partager la largeur de bande au niveau de la grappe ou au niveau de l'exécuteur. Le partage de la largeur de bande au niveau de la grappe permet à un port (ou à des ports) de partager une quantité maximale de largeur de bande entre plusieurs ports (applications/protocoles) d'une même grappe. Le partage de la largeur de bande au niveau de l'exécuteur permet à une grappe (ou à des grappes) de la configuration Dispatcher de partager une quantité maximale de largeur de bande.
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 ndcontrol executor ou ndcontrol cluster avec l'option sharedbandwidth. Ci-dessous, se trouvent des exemples de la syntaxe de la commande.
ndcontrol executor set sharedbandwidth taille ndcontrol 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. Vous devez indiquer une valeur sharedbandwidth maximale qui ne dépasse pas la largeur de bande totale (capacité de serveur totale) disponible.
Ci-dessous, se trouvent des exemples d'ajout ou de définition d'une règle sharedbandwidth.
ndcontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel valeur ndcontrol 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
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 ndcontrol rule, la règle suivante :
ndcontrol 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 Dispatcher ou CBR.
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 à la section Annexe C, Syntaxe des règles de contenu (modèle).
Vous pouvez ajouter des règles à l'aide de la commande ndcontrol 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 :
ndcontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 ndcontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 ndcontrol 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 :
ndcontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 ndcontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 ndcontrol rule use server 130.40.52.153:80:div3 207.72.33.47
L'option d'évaluation de serveur est disponible uniquement dans le composant Dispatcher.
Dans la commande ndcontrol rule, il existe 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 Network Dispatcher, il n'était possible de mesurer que la condition de chaque règle parmi tous les serveurs du port.)
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.
ndcontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate niveau ndcontrol rule set 9.22.21.3:80:rbweval evaluate niveau
Vous pouvez attribuer la valeur port ou règle 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.
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 :
ndconfig 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 ndcontrol server add doivent être ajoutés avec les adresses de réseau privé. Par exemple, reprenant le cas du serveur A de la Figure 27, la syntaxe de la commande sera la suivante :
ndcontrol server add adresse_grappe:80:10.0.0.1
et non
ndcontrol 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 27. Exemple de réseau privé utilisant Dispatcher
L'utilisation d'une configuration de réseau privé s'applique uniquement 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 "*".
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 ndcontrol 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 d'une grappe générique pour combiner les configurations serveurs s'applique uniquement au composant Dispatcher.
L'utilisation de la grappe générique pour équilibrer la charge des pare-feux s'applique uniquement 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 s'applique uniquement 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. 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 :
ndcontrol port add cluster:0
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 "port délai de maintien de routage". Lorsque vous attribuez la valeur zéro au délai de maintien de routage, cette fonction est désactivée.
Interaction avec l'affinité trans port : Lors de l'activation de l'affinité trans port, les valeurs de délai de maintien de routage des ports partagés doit avoir la même valeur (différente de zéro). Pour obtenir plus d'informations, reportez-vous à la section Affinité trans ports.
Lorsque cette fonction est désactivé, dès qu'une connexion TCP est reçue d'un client, Dispatcher utilise me serveur correct et lui transmet les paquets. Si une autre connexion arrive du même client, Dispatcher la traite comme si les deux connexions n'étaient pas liées et utilise à nouveau le serveur correct.
Lorsque cette fonction 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'API Affinité dirigée vers le serveur s'applique uniquement au composant Dispatcher.
La fonctionnalité SDA fournit une API qui permet à un agent externe d'influencer le comportement de l'affinité Dispatcher.
Fonctions SDA
Votre application a peut-être indiqué que ses systèmes de serveurs sont en mesure de diriger les demandes client vers des serveurs particuliers plus efficacement que Dispatcher. Vous pouvez souhaiter que le client soit "redirigé" vers le serveur de votre choix et non vers le serveur sélectionné par la fonction d'équilibrage de charge de Dispatcher. La fonction SDA offre cet API. Vous pouvez créer votre programme pour mettre en oeuvre un agent SDA qui communique avec un module d'écoute dans Dispatcher. Celui-ci est en mesure de manipuler les tables d'affinité de Dispatcher afin :
Les enregistrements insérés dans une table d'affinité par un agent SDA demeurent indéfiniment dans la table. Ils n'expirent jamais. Ils ne peuvent être supprimés que par l'agent SDA ou si un conseiller Dispatcher détecte que le serveur est arrêté.
Composant SDA de Dispatcher
Dispatcher met en oeuvre un nouveau module d'écoute de socket pouvant accepter et traiter des demandes provenant d'un agent SDA. Lorsqu'un agent SDA ouvre une connexion avec Dispatcher, le module d'écoute l'accepte et conserve la connexion. Plusieurs demandes et réponses peuvent utiliser cette connexion permanente. La socket ne sera fermée que par l'agent SDA ou si Dispatcher détecte une erreur irrémédiable. Dans Dispatcher, le module d'écoute prend chaque demande de l'agent SDA, communique avec la table d'affinité appropriée dans le noyau de l'exécuteur de Dispatcher et prépare une réponse destinée à l'agent SDA.
Pour obtenir plus d'informations, reportez-vous aux fichiers se trouvant dans le répertoire d'installation de Network Dispatcher :
L'affinité trans ports s'applique uniquement au 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 :
définition de port ndcontrol grappe : 20 trans ports 10 définition de port ndcontrol grappe : 30 trans ports 10 définition de port ndcontrol grappe : 40 trans ports 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 à ndcontrol 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é s'applique uniquement 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 port ndcontrol permet de masquer les bits communs à poids fort de l'adresse IP 32-bits. Si cette fonction est activé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é 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 Network Dispatcher. 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 à Affinité trans ports, pour de plus amples informations.
Pour activer le masque d'adresse d'affinité, utilisez une commande de port ndcontrol du type suivant :
définition de port ndcontrol grappe : port masque de maintien de routage 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 à ndcontrol 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 substitution d'affinité de règle 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 règle 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.
Reportez-vous à ndcontrol server -- Configuration des serveurs, pour de plus amples informations sur la syntaxe de commande de la substitution d'affinité de règle, utilisant l'option de serveurmaintien de routage .
La mise au repos de la gestion des connexions avec maintien de routage s'applique aux composants Dispatcher et CBR.
Pour retirer un serveur de la configuration Network Dispatcher quelle qu'en soit la raison (mises à jour, mises à niveau, service, etc.), vous pouvez utiliser la commande ndcontrol 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.
N'utilisez l'option quiesce "now" que 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. Ci-dessous, se trouve un exemple de l'utilisation de l'option now pour mettre le serveur 9.40.25.67 au repos :
ndcontrol 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 ndcontrol rule :
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. L'affinité de cookie passif et l'affinité URI s'appliquent au composant CBR et à la méthode d'acheminement CBR du composant Dispatcher.
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 ndcontrol 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 la règle adoptée pour la prise de décision, le serveur cible de l'équilibrage de charge et la date d'expiration de l'affinité. 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é. En cas de détection d'un cookie contenant l'identificateur de la règle déclenchée, le serveur cible de l'équilibrage de charge et la date d'expiration sont extraits du cookie. Si le serveur figure toujours dans l'ensemble utilisé par la règle, que son poids est supérieur à zéro et que la date d'expiration est ultérieure à la date du jour, le serveur indiqué dans le cookie est choisi comme serveur cible pour l'équilibrage de charge. Si l'une de ces trois conditions n'est pas remplie, le choix d'un serveur s'effectue avec un algorithme normal. Une fois le serveur choisi (à l'aide de l'une des deux méthodes), un nouveau cookie est constitué avec IBMCBR, grappe:port:serveur_choisi et un horodatage. Ce dernier est la date d'expiration de l'affinité. La valeur "grappe:port:serveur_choisi" est codée pour ne révéler aucune information sur la configuration CBR. Un paramètre d'"expiration" est également inclus dans le cookie. Ce paramètre est dans un format lisible par le navigateur et entraîne la non-validité du cookie deux heures après la date d'expiration. Ainsi, la base de cookies du client n'est pas encombrée.
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.
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.
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, Network Dispatcher choisit le serveur en fonction du nom du cookie se trouvant dans l'en-tête HTTP de la demande client. Network Dispatcher 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 taille 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, Network Dispatcher transmet les nouvelles demandes client entrantes ayant le même URI au même serveur.
Généralement, Network Dispatcher peut distribuer des demandes à plusieurs serveurs gérant un contenu identique. Lorsque vous utilisez Network Dispatcher 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 Network Dispatcher distribue la demande uniquement au serveur de mise en cache avec ce contenu.
Avec l'affinité d'URI, Network Dispatcher 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 servers 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.
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.
Network Dispatcher 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 ...nd/servers/samples.
Afin d'exécuter les fichiers, vous devez les déplacer dans le répertoire ...nd/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 ndcontrol port de la manière suivante :
ndcontrol 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 (ndcontrol 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 (..nd/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 journalisation 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 ndcontrol log pour configurer la journalisation 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 journalisation des informations relatives au serveur dans les journaux binaires. Le service de journalisation 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 journalisation à chaque intervalle défini pour le gestionnaire. Les informations seront écrites dans les journaux uniquement si l'intervalle de journalisation indiqué a expiré depuis l'écriture du dernier enregistrement dans le journal. Par défaut, la valeur de l'intervalle de journalisation est 60 secondes. Il y a interaction entre les paramètres relatifs à l'intervalle défini pour le gestionnaire et l'intervalle de journalisation. Comme les informations ne seront pas fournies au serveur de journalisation plus fréquemment que l'intervalle défini pour le gestionnaire, l'indication d'un intervalle de journalisation inférieur à l'intervalle du gestionnaire, entraîne en réalité la définition d'un intervalle de journalisation identique à l'intervalle du gestionnaire. Cette technique de journalisation 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 journalisation 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 journalisation 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 journalisation. Cela se produit uniquement si le serveur de journalisation 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 journalisation, 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 ...nd/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) :
ndlogreport 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. Pour Mailbox Locator, utilisez mllogreport. Pour Cisco Consultant, utilisez lbclogreport.)
Dans Cisco Consultant, Cisco CSS Switch effectue les mêmes tâches que l'exécuteur dans Dispatcher. Outre la charge en cours de chaque serveur et d'autres données nécessaires à ses calculs, le gestionnaire obtient les valeurs des nouvelles connexions et des connexions actives de Cisco CSS Switch. Ces valeurs dépendent des informations générées et stockées en interne dans Cisco CSS Switch.
Cisco Consultant interroge la base d'informations de gestion (MIB) de Cisco CSS Switch pour obtenir les informations relatives aux connexions actives et aux nouvelles connexion et il reçoit la réponse suivantes :
apSvcConnections OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of TCP connections to this service" DEFVAL { 0 } --DEFAULT ap-display-name Service Connections ::= {apSvcEntry 20}
L'identificateur d'objet apSvcConnections est :
1.3.6.1.4.1.2467.1.15.2.1.20
Le nombre de connexions actives dépend du nombre de clients de même 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 pages Web de petite taille obtenues par HTTP GET), le nombre de connexions actives est assez bas. Si les connexions client sont lentes (comme dans le cas de requêtes de base de données), le nombre de connexions actives est plus élevé.
L'index de cette variable est :
INDEX { apCntsvcOwnName, apCntsvcCntName, apCntsvcSvcName }Ci-dessous, se trouve l'entrée MIB.
apCntsvcHits OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of flows placed onto this service for this content rule." DEFVAL { 0 } --DEFAULT ap-display-name Hits --DEFAULT apjam-popup-ref apCntSvcInst, Statistics --DEFAULT apjam-chart-def cntSvcHitsChart, pie, apCntInst, "Hit Information Per Service: --DEFAULT apjam-chart-item cntSvcHitsChart, getnext, apCntsvcSvcName ::= {apSvcEntry 20}
L'identificateur d'objet apCntsvcHits est :
1.3.6.1.4.1.2467.1.18.2.1.4
Cisco CSS Switch doit être configuré de manière à pouvoir utiliser l'équilibrage de charge de technique de permutation circulaire pondérée. Pour obtenir plus d'informations sur cette opération, reportez-vous au chapitre "Configuring Weight" du manuel Content Services Switch Basic Configuration Guide.
Les pondérations sont définies par la fonction du gestionnaire en fonction des décomptes internes de Cisco CSS Switch et du retour des informations des conseillers et du Metric Server. Si vous voulez définir des pondérations manuellement lors de l'exécution du gestionnaire, indiquez l'option fixedweight dans la commande lbccontrol server.
Si tous les serveurs sont inactifs, toutes les pondérations sont égales à zéro. Dans ce cas, lorsqu'aucun serveur ne traite les demandes car toutes les charges sont égales à zéro, les charges sont définies à la moitié de la pondération afin que le traitement des demandes soit effectué par n'importe quel serveur. Le contrôler affiche les valeurs de charge égales à zéro alors que Cisco Consultant affiche une charge d'une demi-pondération à tous les autres emplacements.
Les pondérations sont envoyées à Cisco CSS Switch à l'aide de SNMP. Cisco Consultant définit apSvcWeight dans l'élément svcExt.mib. Ci-dessous, se trouve l'entrée apSvcWeight.
apSvcWeight OBJECT-TYPE SYNTAX Integer 32(1..10) MAX-ACCESS read-create STATUS current DESCRIPTION "The service weight which is used in conjunction with load metrics when making load allocation decisions. The weight may be used to bias flows towards the specified service." DEFVAL { 1 } --DEFAULT ap-display-name Service Weight --DEFAULT apjam-popup-ref apServicesGroupInst, Properties, Advanced --DEFAULT apjam-wizard-field 2, normal ::= {apSvcEntry 16}
L'identificateur d'objet apSvcWeight est :
1.3.6.1.4.1.2467.1.15.2.1.12
Les pondérations définies s'appliquent à tous les serveurs connectés sur un même port. Pour chaque port, les demandes sont réparties entre les serveurs selon la pondération relative de chacun. Par exemple, si un serveur a une pondération (paramètre Weight) de 10 et un autre de 5, le premier recevra deux fois plus de demandes que le second.
Pour définir la limite de pondération maximale d'un serveur, entrez la commande lbccontrol port set weightbound. Cette commande indique les différences entre le nombre de demandes obtenues par chaque serveur. Si la pondération maximale est de 1, tous les serveurs peuvent avoir une pondération égale à 1, 0 en attente 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é peut recevoir deux fois plus de demandes qu'un autre.
Si un conseiller détecte qu'un serveur est hors ligne, il en informe le gestionnaire qui affecte au serveur une pondération de zéro. Lorsque la pondération d'un serveur est supérieure à zéro, elle est envoyée à Cisco CSS Switch et le serveur devient actif. Cependant, si la pondération du serveur est inférieure ou égale à zéro, le serveur est interrompu. La définition de la variable MIB apSvcEnable dans svcExt.mib de Cisco CSS Switch permet d'activer ou d'interrompre un service. Ci-dessous, se trouve l'entrée MIB apSvcEnable.
apSvcEnable OBJECT-TYPE SYNTAX Integer disable(0) enable(1) MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the service, either enabled or disabled." DEFVAL { disable } --DEFAULT ap-display-name Status --DEFAULT apjam-popup-ref apServicesGroupInst, Properties --DEFAULT apjam-wizard-field 2, normal ::= {apSvcEntry 12}
L'identificateur d'objet apSvcEnable est :
1.3.6.1.4.1.2467.1.15.2.1.16
Le présent chapitre explique comment exploiter et gérer Network Dispatcher et inclut les sections suivantes :
Network Dispatcher offre une option permettant d'exécuter ses programmes de configuration sur une machine autre que celles sur lesquelles s'exécutent les serveurs Network Dispatcher.
Les communications entre les programmes de configuration ((ndcontrol, cbrcontrol, mlcontrol, sscontrol, lbccontrol, ndwizard, cbrwizard, mlwizard, sswizard, ndadmin) sont effectuée à l'aide de l'appel RMI (Remote Method Invocation) Java . La commande permettant de connecter un Network Dispatcher pour l'administration à distance est ndcontrol 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 éloignée :
Cette commande s'exécute uniquement sur la même machine que Network Dispatcher.
L'option create permet de créer une clé publique dans le répertoire key des serveurs (...nd/servers/key/) et de créer des clés privées dans le répertoire keys d'administration (...nd/admin/keys/) pour chacun des composants Network Dispatcher. Le nom de fichier de la clé privée est : composant-AdresseServeur-PortRMI. Ces clés privées doivent ensuite être transmises aux clients éloignés et placés dans la répertoire keys d'administration.
Pour une machine Network Dispatcher avec une adresse de nom d'hôte 10.0.0.25 utilisant le port RMI par défaut pour chaque composant, la commande ndkeys 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 privées doivent être placés dans le répertoire .../nd/admin/keys sur la machine client éloignée.
Le client éloigné sera désormais autorisé à configurer Network Dispatcher 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 Network Dispatcher sur 10.0.0.25.
Si vous devez de nouveau exécuter la commande ndkeys 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 ndkeys delete permet de supprimer les clés publiques et privées 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 ndkeys et à la commande ndkeys delete. Elle permet de supprimer les invites demandant si vous voulez remplacer ou supprimer les clés existantes.
Network Dispatcher enregistre les entrées dans un journal du serveur, un journal du gestionnaire, un journal du contrôleur de mesures (journalisation des communications avec les agents Metric Server) et dans un journal pour chaque conseiller utilisé.
Vous pouvez définir le niveau de journalisation 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 Network Dispatcher journalise é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 serveur est 0. La valeur par défaut pour les journaux du gestionnaire, du conseiller et 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 journalisation 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 Network Dispatcher seront stockés dans le répertoire logs de l'installation de Network Dispatcher. Pour modifier ce chemin, définissez la variable nd_logdir dans le script ndserver.
AIX, Linux et Solaris : Le script ndserver se trouve dans le répertoire /usr/bin. Dans ce script, la variable nd_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 :
ND_LOGDIR=/chemin/de/mes/fichiers/journaux/
Windows 2000 : Le fichier ndserver se trouve dans le répertoire système de Windows 2000, généralement C:\WINNT\SYSTEM32. Dans le fichier ndserver, la variable nd_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 ND_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 journalisation binaire de Network Dispatcher utilise le répertoire contenant les autres fichiers journaux. Reportez-vous à la section Utilisation de la journalisation binaire pour analyser les statistiques des serveurs.
La présente section explique comment utiliser et gérer le composant Dispatcher.
Pour Network Dispatcher, 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, Network Dispatcher 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 ndcontrol 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 32,000,000 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 Network Dispatcher est inférieure à la valeur du délai du service. Dans le cas de LDAP, la valeur par défaut du paramètre de Network est 300 secondes. Si aucune activité ne se produit sur la connexion pendant 300 secondes, Network Dispatcher 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 Network Dispatcher. 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 Network Dispatcher.
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 ndcontrol 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 ndcontrol 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 ..nd/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 Protocol Interface). Il s'agit d'une interface entre un agent SNMP et les sous-agents de ce dernier.
Figure 28. 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.
Pour Solaris, vous devez obtenir un agent SNMP fonctionnant avec SMUX car Solaris n'en fournit pas. Network Dispatcher fournit DPID2 pour Solaris dans le répertoire /opt/nd/servers/samples/SNMP.
L'agent DPI doit fonctionner comme un utilisateur root. Avant d'exécuter le démon DPID2, mettez à jour les fichiers /etc/snmpd.peers et /etc/snmpd.conf comme suit :
"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
Régénérez snmpd de sorte qu'il relise le fichier /etc/snmpd.conf :
refresh -s snmpd
Lancez l'homologue DPID SMUX :
dpid2
Les démons doivent être lancés dans l'ordre suivant :
Figure 29. Commandes SNMP pour Windows 2000
Pour accéder à un agent SNMP DPI pour Windows 2000, installez la version Windows NT du kit d'outils IBM SystemView Agent à partir de http://www.tivoli.com/support/sva.
Avant de lancer le processus SNMPD de SystemView SNMPD, désactivez le support SNMP de Microsoft Windows. Ce support prend en charge les sous-agents DPI et les agents compatibles Microsoft.
Pour désactiver le support SNMP de Windows, procédez aux opérations ci-dessous.
Pour configurer l'agent SystemView SNMP, suivez les instructions de la section Définition d'un nom de communauté pour SNMP.
Vous devez configurer le nom de communauté SNMP. Le mot de passe SNMP par défaut est public. Sous UNIX, il est défini dans un fichier appelé /etc/snmpd.conf.
Sur tous les systèmes, le nom de communauté doit être configuré et utilisé de manière cohérente. En d'autres termes, si le nom de communauté de Network Dispatcher est "OurCommunity" dans la configuration de l'agent SNMP, il doit aussi être défini par "OurCommunity" dans la configuration du sous-agent.
Sous Windows 2000, configurer l'agent SNMP IBM SystemView avant de créer le nom de communauté.
Cette opération permet à n'importe quel hôte d'un réseau d'accéder aux variables MIB SNMP. Après avoir vérifié que ces valeurs fonctionnent, vous pouvez les modifier en fonction de vos besoins.
L'exécuteur étant en cours de fonctionnement, lancez la commande ndcontrol subagent start [nom_communauté] pour définir le nom de communauté utilisé entre le sous-agent DPI de Dispatcher et l'agent SNMP. Le nom de communauté par défaut est public. Si vous modifiez cette valeur, vous devez aussi ajouter le nouveau nom de communauté à l'agent SystemView à l'aide de snmpcfg comme décrit plus haut.
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 csAddr, psNum, ssAddr 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 csAddr, psNum de l'identificateur d'objet. Le nombre de serveurs configurés sur le port est transmis dans l'interruption. Cette interruption indique que Network Dispatcher 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 csAddr, psNum de l'identificateur d'objet. Le nombre de serveurs configurés sur le port est transmis dans l'interruption. Lorsque Network Dispatcher détermine que l'attaque de refus de service est terminée, cette interruption est envoyée après l'interruption indDOSAttack.
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 ndcontrol subagent start. Il est désactivé à l'aide de la commande ndcontrol subagent stop.
Pour plus de détails sur la commande ndcontrol, reportez-vous à la section ndcontrol 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 Network Dispatcher et de ipchains, Network Dispatcher voit le paquets avant ipchains. Vous pouvez ainsi utiliser ipchains pour renforcer un dispositif Network Dispatcher Linux tel qu'un dispositif Network Dispatcher 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 Network Dispatcher 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 Network Dispatcher 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 Network Dispatcher consiste à refuser tout type de trafic, sauf celui à destination et provenant des serveurs périphériques, du Network Dispatcher haute disponibilité partenaire, des cibles à atteindre ou des hôtes de configuration.
La présente section explique comment utiliser le composant CBR de Network Dispatcher.
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 Network Dispatcher.
Après avoir lancé Mailbox Locator, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux utilisés par Mailbox Locator sont similaires à ceux utilisés dans Dispatcher. Pour plus d'information, reportez-vous à la section Utilisation des journaux Network Dispatcher.
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 Network Dispatcher.
Après avoir lancé Cisco Consultant, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux employés par Cisco Consultant sont similaires à ceux utilisés dans Dispatcher. Pour plus d'information, reportez-vous à la section Utilisation des journaux Network Dispatcher.
Metric Server fournit à Network Dispatcher des informations relatives à la charge des serveurs. Il réside sur chaque serveur soumis à l'équilibrage de charge.
Modifiez le niveau de journalisation dans le script de démarrage de Metric Server. Vous pouvez indiquer un niveau de journalisation compris entre 0 et 5, à l'instar de la plage admise pour les journaux de Network Dispatcher. 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 à Network Dispatcher. Recherchez le symptôme rencontré dans le Tableaux de résolution des incidents.
Ces tableaux de résolution des incidents concernent Dispatcher, CBR,
Mailbox Locator, Site Selector et Consultant for Cisco CSS
Switches.
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 de 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 |
SNMPD ne peut plus être lancé ou exécuté (Windows 2000) | Le nom de communauté entré dans les commandes SNMP n'est pas cohérent avec celui qui a servi à lancer le sous-agent | Incident : SNMPD ne semble pas fonctionner correctement (Windows 2000) |
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 ndcontrol ou ndadmin n'a pas abouti, le message 'Le serveur ne répond pas' ou 'Impossible d'accéder au serveur RMI' s'affiche. |
| Incident : échec de la commande ndcontrol ou ndadmin |
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 : le message d'erreur "Impossible trouver fichier |
"stty: : No such device or address" (aucun périphérique ou adresse de ce type) lors du lancement de ndserver sous Solaris 2.7. | Ignorez ce message d'erreur. Il ne s'agit pas d'un problème. Ndserver s'exécute correctement | Incident : Message d'erreur incorrect lors du lancement de ndserver 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 |
Network Dispatcher ne peut pas traiter et transmettre de cadre | Une adresse MAC unique est nécessaire pour chaque carte NIC | Incident: Network Dispatcher 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 lancement de l'exécuteur Network Dispatcher |
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 Network Dispatcher |
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 Network Dispatcher 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 Network Dispatcher 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 |
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 de CBR |
La commande cbrcontrol ou ndadmin 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 : les commandes cbrcontrol ou ndadmin n'ont 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 |
Tableau 16. Tableau de résolution des incidents Mailbox Locator
Symptôme | Cause possible | Reportez-vous à la section. |
Mailbox Locator ne s'exécute pas correctement | Conflit de numéros de port | Vérification des numéros de port de Mailbox Locator |
La commande mlserver renvoie une exception "java.rmi.RMI Security Exception: security.fd.read" | La limite système imposée pour les descripteurs de fichiers est trop petite pour le nombre de demandes que mlserver tente de traiter | Incident : la commande mlserver est arrêtée |
La commande mlcontrol ou ndadmin 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 mlserver n'a pas été lancé. | Incident : la commande mlcontrol ou ndadmin n'a pas abouti |
Impossible d'ajouter un port | Une autre application est déjà en mode écoute sur ce port | Incident : impossible d'ajouter un port |
Réception d'une erreur proxy lors d'une tentative d'ajout d'un port | L'adresse de grappe n'a pas été configurée sur un NIC avant le lancement de la commande sous proxy. Ou une autre application est en cours d'exécution sur ce port. | Incident : réception d'une erreur proxy lors d'une tentative d'ajout de port |
Tableau 17. 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 ndadmin 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 ndadmin 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 |
Tableau 18. Tableau de résolution des incidents de Consultant for Cisco CSS Switches
Symptôme | Cause possible | Voir... |
---|---|---|
Echec du lancement de lbcserver | Conflit de numéros de port | Vérification des numéros de port Cisco Consultant |
La commande lbccontrol ou ndadmin n'a pas abouti, le message 'Le serveur ne répond pas' or '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 lbcserver n'a pas été lancé. | Incident : la commande lbccontrol ou ndadmin 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 |
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 Network Dispatcher les informations relatives à la charge. | Causes possibles :
| Incident : Metric Server n'indique pas la charge à la machine Network Dispatcher |
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 |
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 le numéro de port de Dispatcher en procédant 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 de CBR, vous pouvez modifier le numéro de port de CBR en procédant comme suit :
En cas d'incidents lors de l'exécution de Mailbox Locator, il se peut que l'une des applications utilise un numéro de port généralement utilisé par Mailbox Locator. Prenez en compte le fait que Mailbox Locator utilise les numéros de port suivants :
Si une autre application utilise l'un des numéros de port Mailbox Locator, vous pouvez modifier le numéro de port de Mailbox Locator' en procédant 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 le numéro de port de Site Selector' en procédant comme suit :
En cas d'incidents lors de l'exécution du composant Cisco Consultant, il se peut qu'une autre application utilise l'un des numéros de port utilisés par le serveur lbcserver de Cisco Consultant. Prenez en compte le fait que Cisco Consultant utilise les numéros de port suivants :
14099 pour recevoir les commandes de lbccontrol
10004 pour envoyer des demandes de mesure au système Metric Server
Si une autre application utilise l'un des numéros de port Consultant, vous pouvez modifier le numéro de port de Consultant en procédant 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 de 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 :
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 :
ndconfig tr0 <adresse ip> netmask <masque_réseau> ou ndcontrol cluster configure
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.
Lors de l'utilisation de sous-agents SNMP, si le démon SystemViewAgent SNMP ne peut pas être lancé et rester actif, vérifiez que vous avez bien configuré votre communauté SNMP à l'aide du programme snmpcfg. Pour que vous puissiez accéder aux données SNMP à partir du sous-agent Dispatcher, le nom de communauté entré dans les commandes SNMP doit être cohérent avec celui avec lequel le sous-agent a été lancé.
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 obtenir 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 jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Le port aléatoire 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 la commande ndcontrol alors que Network Dispatcher s'exécute sur la même machine qu'un pare-feu, des erreurs de type Erreur : Pas de réponse du serveur peuvent apparaître.
Pour éviter ce type d'incident, modifiez le fichier script ndserver (situé dans PATH) afin de définir le port aléatoire utilisé par RMI. Insérez -DND_RMI_SERVER_PORT=votrePort dans la chaîne END_ACCESS, où votrePort correspond au port spécifié.
Par exemple :
END_ACCESS='-DND_CLIENT_KEYS_DIRECTORY=/usr/lpp/nd/admin/keys/dispatcher -DND_SERVER_KEYS_DIRECTORY=/usr/lpp/nd/dispatcher/key -DND_RMI_SERVER_PORT=10100' ND_RMIPORT=10099
Lorsque vous avez terminé, relancez la commande ndserver et ouvrez le trafic des ports 10099 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 ndserver 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. Ndserver s'exécute correctement.
Pour que l'interface graphique, ndadmin, 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 Network Dispatcher 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 Network Dispatcher, 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 Network Dispatcher, 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, Network Dispatcher 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 lancement 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.
Il existe deux solutions pour 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 Network Dispatcher 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 Network Dispatcher), 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 modification de l'interface graphique 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 de 64 Mo. La valeur maximale pouvant être associée aux plate-formes SPARC Solaris 7 et 8 est de 4000 Mo; celle pouvant être associée aux plate-formes Solaris 2.6 et x86 est de 2000 Mo.
Pour ajouter cette option, modifiez le fichier script ndadmin comme suit :
START jrew -mx64m %END_ACCESS% %CONFIG_DIR% -DEND_INSTALL_PATH=%IBMNDPATH% -cp %NDCLASSPATH% com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode1
$JREDIR/$JRE -mx64m $END_ACCESS $CONFIG_DIR -DEND_INSTALL_PATH=/opt/&BASEDIR -cp $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode &1
re -mx64m $END_ACCESS $CONFIG_DIR $NDLOCALE -DEND_INSTALL_PATH=/opt/nd -classpath $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode 1>/dev/null 2>&1 &1
ava -mx64m $END_ACCESS $CONFIG_DIR $NDLOCALE -DEND_INSTALL_PATH=/usr/lpp/&BASEDIR -classpath $NDCLASSPATH com.ibm.internet.nd.framework.FWK_Framework com.ibm.internet.nd.gui.GUI_eNDRootNode 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.
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 de CBR.
La commande cbrcontrol renvoie : "Erreur : Pas de réponse du serveur." Ou la commande ndadmin renvoie : "Erreur : impossible accéder au serveur RMI." Ces erreurs peuvent se manifester lorsque votre machine a une pile sur "sock". Pour corriger ce problème, éditez le fichier socks.cnf pour qu'il contienne les lignes suivantes :
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Ces erreurs peuvent également se produire si vous n'avez pas encore lancé cbrserver.
Caching Proxy et CBR ont été lancés, mais les requêtes ne sont pas équilibrées. Cette erreur peut se produire lorsque vous lancez 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, lancez 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 obtenir plus d'informations sur le mode de configuration de ce fichier, reportez-vous à la section ***.
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 :
Cet incident peut se produire lorsqu'une autre application utilise un des ports utilisés par Mailbox Locator. Pour plus de détails, reportez-vous à la section Vérification des numéros de port de Mailbox Locator.
Sur une plate-forme UNIX, cet incident survient lorsque mlserver est utilisé pour équilibrer la charge avec un nombre important de demandes client IMAP/POP3 et que la limite système imposée pour les descripteurs de fichiers est trop petites pour le nombre de demandes que mlserver tente de traiter. mlserver génère l'exception suivante puis est arrêté :
java.rmi.RMISecurityException: security.fd.read
Le fichier journal de commande sous proxy spécifique au protocole indique :
SocketException=java.net.SocketException: Socket fermée.
La solution consiste à modifier la limite nofiles (AIX, Linux) ou open files (Solaris) dans le shell où mlserver est lancé. Portez la limite nofiles à un nombre raisonnable supérieur à la limite nofiles actuelle. Utilisez ulimit -a pour afficher la limite nofiles et utilisez ulimit -n valeur pour augmenter la valeur.
La commande mlcontrol renvoie : "Erreur : Pas de réponse du serveur." Ou la commande ndadmin renvoie : "Erreur : impossible accéder au serveur RMI." Ces erreurs peuvent se manifester lorsque votre machine a une pile sur "sock". Pour corriger ce problème, éditez le fichier socks.cnf pour qu'il contienne les lignes suivantes :
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Ces erreurs peuvent également se produire si vous n'avez pas encore lancé mlserver.
Lors d'une tentative d'ajout d'un port à une configuration, vous pouvez recevoir le message d'erreur suivant : Erreur : impossible d'ajouter le port. Une autre application est peut-être déjà en mode écoute sur ce port. Mailbox Locator tente de lancer un proxy reliant à l'adresse IP de grappe sur le port indiqué dans la commande. Si une autre application relie à cette adresse IP ou est à l'écoute de toutes les adresses IP sur ce port, le démarrage du proxy échoue. Pour utiliser Mailbox Locator sur ce port, vous devez arrêter l'application en conflit.
Sur plate-forme Linux, le démon xinetd peut démarrer un programme d'écoute sans exécuter, par exemple, un programme POP3. Par conséquent, il est important de vérifier par la commande netstat -a si une application est en mode écoute sur le port voulu.
Pour Mailbox Locator, la commande mlcontrol port add génère le message d'erreur suivant : "Le proxy de la grappe <grappe>, port <port> n'a pas démarré." La solution est de configurer l'adresse de la grappe sur un NIC avant de pouvoir lancer le proxy. Vérifiez également qu'aucune autre application n'est en cours d'exécution sur le port à l'écoute de l'adresse de grappes (incluant une application générale d'écoute globale).
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.
La commande sscontrol renvoie : "Erreur : Pas de réponse du serveur." Ou la commande ndadmin renvoie : "Erreur : impossible accéder au serveur RMI." Ces erreurs peuvent se manifester lorsque votre machine a une pile sur "sock". Pour corriger ce problème, éditez le fichier socks.cnf pour qu'il contienne les lignes suivantes :
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Ces erreurs peuvent également se produire si vous n'avez pas encore lancé ssserver.
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". Il devrait en résulter des erreurs supplémentaires.
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.
Cet incident peut se produire lorsqu'une autre application utilise un des ports employés par le serveur lbcserver de Consultant. Pour obtenir plus d'informations, reportez-vous à la section Vérification des numéros de port Cisco Consultant.
La commande lbccontrol renvoie : "Erreur : Pas de réponse du serveur." Ou la commande ndadmin renvoie : "Erreur : impossible accéder au serveur RMI." Ces erreurs peuvent se manifester lorsque votre machine a une pile sur "sock". Pour corriger ce problème, éditez le fichier socks.cnf pour qu'il contienne les lignes suivantes :
EXCLUDE-MODULE java EXCLUDE-MODULE jre EXCLUDE-MODULE jrew EXCLUDE-MODULE javaw
Ces erreurs peuvent également se produire si vous n'avez pas encore lancé lbcserver.
Cet incident peut se produire lorsqu'il manque une licence de produit valide. Lorsque vous tentez de lancer lbcserver, vous recevez le message suivant :
Votre licence a expiré ! Adressez-vous à votre ingénieur commercial ou à votre représentant IBM.
Pour corriger ce problème :
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 à Network Dispatcher. 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 :
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 ndcontrol de Dispatcher. Elle traite également les commandes pour CBR et Mailbox Locator. CBR et Mailbox Locator utilisent un sous-ensemble de commandes Dispatcher. Pour de plus amples informations, reportez-vous à Différences de configuration entre CBR, Mailbox Locator et Dispatcher.
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 commandes ndcontrol. Il suffit d'entrer les lettres uniques des paramètres. Par exemple, pour obtenir l'aide correspondant à la commande file save, entrez ndcontrol he f à la place de ndcontrol help file.
Pour démarrer l'interface de ligne de commande, entrez ndcontrol pour ouvrir une invite ndcontrol.
Pour fermer l'interface de ligne de commande, entrez exit ou quit.
L'interface de ligne de commande de CBR et de Mailbox Locator est en grande partie un sous-ensemble de l'interface de ligne de commande de Dispatcher. Utilisez la commande cbrcontrol (pour le composant CBR) ou la commande mlcontrol (pour le composant Mailbox Locator) à la place de ndcontrol pour configurer le composant.
Certaines commandes inutilisées dans CBR figurent ci-dessous.
Certaines commandes inutilisées dans Mailbox Locator sont répertoriées ci-dessous.
>>-ndcontrol--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-' | +-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-'
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 de plus amples informations, reportez-vous à 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 |
---|---|---|
connect | ICMP | 12345 |
db2 | privé | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
ibmproxy | HTTP (via Caching Proxy) | 80 |
imap | IMAP | 143 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | privé | 12345 |
smtp | SMTP | 25 |
ssl | HTTP | 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
ndcontrol advisor start http 127.40.50.1:80
ndcontrol advisor start http 88
ndcontrol advisor stop http 127.40.50.1:80
ndcontrol advisor connecttimeout http 80 30
ndcontrol advisor connecttimeout http 127.40.50.1:80 20
ndcontrol advisor interval ftp 21 6
ndcontrol advisor listCette commande génère des résultats similaires à l'exemple suivant :
--------------------------------------- | CONSEILLER | GRAPPE:PORT | DELAI | --------------------------------------- | http | 127.40.50.1:80 | illimité | | ftp | 21 | illimité | ---------------------------------------
ndcontrol advisor loglevel http 80 0
ndcontrol advisor logsize ftp 21 5000
ndcontrol advisor receivetimeout http 80 60
ndcontrol 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
ndcontrol 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) ............... Illimité 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) ......... Illimité
ndcontrol advisor timeout ftp 21 5
ndcontrol 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
>>-ndcontrol--grappe--+-add--grappe+g2+...--+-------------------------------------------------+-+->< | +-proportions--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+...--+-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----------------------------------------------------------+ +-configuration--grappe--+-------------------------------+----------------+ | '-nom_interface - masque_réseau-' | '-unconfigure--grappe-----------------------------------------------------'
Vous pouvez utiliser le signe deux-points (:) comme caractère générique sauf pour la commande ndcontrol cluster add. Par exemple, la commande ndcontrol 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 primaire à 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
ndcontrol cluster add 130.40.52.153
ndcontrol cluster remove 130.40.52.153
ndcontrol cluster set 9.6.54.12 proportions 60 35 5 0
ndcontrol cluster add 0.0.0.0
ndcontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
ndcontrol cluster status 9.67.131.167Cette commande génère des résultats similaires à l'exemple suivant :
Etat de la grappe (cluster) : --------------- 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 primaire ........................... 9.67.131.167
>>-ndcontrol--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-------------------------' | +-start----------------------------------------------------+ +-status---------------------------------------------------+ '-stop-----------------------------------------------------'
Exemples
ndcontrol 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 ............... 2,001 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 du port ....................... 300 Délai de maintien de routage par défaut du port 0 Limite de pondération par défaut du port ...... 20 Nombre maximal de grappes ..................... 100
ndcontrol executor set nfa 130.40.52.167
ndcontrol executor set maxclusters 4096
ndcontrol executor start
ndcontrol executor stop
>>-ndcontrol--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.
Chemin d'accès courant au répertoire d'installation -- c:\Program Files\ibm\edge\nd\servers\configurations\composant
Chemin d'accès au répertoire d'installation natif -- c:\Program Files\ibm\nd\servers\configurations\composant
Exemples
ndcontrol file delete fichier3 Le fichier (fichier3) est supprimé.
ndcontrol file newload file1.sv Le fichier (file1.sv) a été chargé dans le Dispatcher.
ndcontrol file appendload file2.sv Le fichier (file2.sv) a été chargé et ajouté à la configuration actuelle.
ndcontrol file report RAPPORT SUR LES FICHIERS : fichier1.sauv fichier2.sv fichier3
ndcontrol file save fichier3 La configuration est sauvegardée dans fichier3.
>>-ndcontrol--help--+-help-------------+----------------------->< +-hôte-------------+ +-executor---------+ +-manager----------+ +-advisor----------+ +-cluster----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-subagent---------+ +-highavailability-+ +-file-------------+ +-set--------------+ +-status-----------+ '-log--------------'
Exemples
ndcontrol 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 log - Aide sur la commande log 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 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)
>>-ndcontrol--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
ndcontrol 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 primaire........... 9.67.131.151 Port .........................12,345 Cible privilégiée....... 9.67.134.223 Etat du signal de présence : ----------------- Nombre ................ 1 Etat de l'accessibilité : -------------------- Nombre ................ 1
ndcontrol highavailability backup add primary auto 80
ndcontrol 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
ndcontrol highavailability takeover
>>-ndcontrol--host:--remote_host-------------------------------><
ndcontrol host:remote_host
Après avoir tapé cette commande dans l'indicatif DOS, entrez toute commande ndcontrol valide que vous désirez envoyer à la machine Network Dispatcher éloignée.
>>-ndcontrol--log--+-start-----------------------------+------->< +-stop------------------------------+ +-set--+-rétention-heures---------+-+ | '---intervalles-secondes---' | '-status----------------------------'
>>-ndcontrol--manager--+-interval--secondes------------------------+->< +-loglevel--niveau--------------------------+ +-logsize--+-unlimited-+--------------------+ | '-octets----' | +-quiesce--serveur--+-----+-----------------+ | '-now-' | +-reach set--+-intervalles-secondes---+-----+ | '-+-loglevel-niveau----+-' | | '---logsize-taille---' | +-refresh--cycle de mise à jour-------------+ +-report--+---------------+-----------------+ | '-grappe+g2+...-' | +-restart--message--------------------------+ +-sensitivity--pondération------------------+ +-smoothing--Index de filtrage--------------+ +-start--+--------------------------------+-+ | '-fichier journal--port_décompte-' | +-status------------------------------------+ +-stop--------------------------------------+ +-unquiesce--serveur------------------------+ '-version-----------------------------------'
Ou, si vous utilisez le partitionnement du serveur, entrez le nom unique du serveur logique. Pour 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 à la section Annexe F, 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
ndcontrol manager interval 5
ndcontrol manager loglevel 0
ndcontrol manager logsize 1000000
ndcontrol manager quiesce 130.40.52.153
ndcontrol manager refresh 3
ndcontrol manager reportCette commande génère des résultats similaires à l'exemple suivant :
---------------------------------- | TABLE DES HOTES | ETAT | ---------------------------------- | 9.67.129.221 | ACTIF | | 9.67.129.213 | ACTIF | | 9.67.134.223 | ACTIF | ---------------------------------- ----------------------------------------------------------------------------------- | 9.67.131.18| POND | ACTIV. % 48| NOUV. % 48 | PORT % 4 | SYSTEM % 0 | ----------------------------------------------------------------------------------- | PORT: 80 | ACT.| NV. | PND | CONNEXION | PDS | CONNEXION | PND |CHARGE | PND |CHARGE | ----------------------------------------------------------------------------------- | 9.67.129.221| 8 | 8 | 10 | 0 | 10 | 0 | 7 | 29 | 0 | 0 | | 9.67.134.223| 11 | 11 | 10 | 0 | 10 | 0 | 12 | 17 | 0 | 0 | ----------------------------------------------------------------------------------- | TOTAUX : | 19 | 19 | | 0 | | 0 | | 46 | | 0 | ----------------------------------------------------------------------------------- ----------------------------------------------------------------------------------- | 9.67.131.18| POND | ACTIV. % 48| NOUV. % 48 | PORT % 4 | SYSTEM % 0 | ----------------------------------------------------------------------------------- | PORT: 23 |ACT | NV |PND | CONNEXION |PDS | CONNEXION | PND | CHARGE | PND | CHARGE | ----------------------------------------------------------------------------------- | 9.67.129.213| 10 | 10 | 10 | 0 | 10 | 0 | 10 | 71 | 0 | 0 | | 9.67.134.223| 0 | 0 | 10 | 0 | 10 | 0 |-9999 | -1 | 0 | 0 | ----------------------------------------------------------------------------------- | TOTAUX : | 10 | 10 | | 0 | | 0 | | 70 | | 0 | ----------------------------------------------------------------------------------- -------------------------------- | CONSEILLER | PORT | DELAI | -------------------------------- | reach | 0 | illimité | | http | 80 | illimité | | ftp | 21 | illimité | --------------------------------
ndcontrol manager restart Relance du gestionnaire pour mettre à jour le codeCette commande génère des résultats similaires à l'exemple suivant :
320-14:04:54 Relance du gestionnaire pour mettre à jour le code
ndcontrol manager sensitivity 10
ndcontrol manager smoothing 2.0
ndcontrol manager start ndmgr.log
ndcontrol manager statusCette commande génère des résultats similaires à l'exemple suivant :
Etat du gestionnaire (manager) : ============= Port du processus de décompte...................... 10,004 Nom de 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 des mises à jour des pondérations ........... 2 Niveau de journal à atteindre...................... 1 Taille maximale du journal des contacts octets).... unlimited Intervalle de mise à jour des contacts (secondes).. 7
ndcontrol manager stop
ndcontrol manager quiesce 130.40.52.153 now
ndcontrol manager quiesce 130.40.52.153
ndcontrol manager unquiesce 130.40.52.153
ndcontrol manager version
>>-ndcontrol--metric--+-add--grappe+c2+...+cN:metric+metric1+...+metricN--------------+->< +-remove--grappe+c2+...+cN:metric+metric1+...+metricN-----------+ +-proportions--grappe+c2+...+cN proportion1 prop2 prop3...propN-+ '-status--grappe+c2+...+cN:metric+metric1+...+metricN-----------'
Remarque : Pour Cisco Consultant, l'adresse de grappe correspond à l'adresse IP virtuelle (VIP) de la règle de contenu du propriétaire dans la configuration Cisco CSS Switch.
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 : ------------ Grappe ........................ 10.10.10.20 Nom de la mesure .............. metric1 Proportion de la mesure ....... 50 Serveur ................... plm3 Données de mesure ......... -1
>>-ndcontrol--port--+-add--grappe:port--+---------------------------------------+-+->< | +-trans ports--autre port---------------+ | | +-maxservers--taille--------------------+ | | +-masque de maintien de routage--valeur-+ | | +-stickytime--heure---------------------+ | | +-method--type--------------------------+ | | +-staletimeout--valeur------------------+ | | +-weightbound--pondération--------------+ | | +-porttype--type------------------------+ | | '-protocole--type-----------------------' | +-set--grappe:port--+-trans ports--autre port---------------+-+ | +-maxservers--taille--------------------+ | | +-masque de maintien de routage--valeur-+ | | +-stickytime--heure---------------------+ | | +-staletimeout--valeur------------------+ | | +-weightbound--pondération--------------+ | | +-porttype--type------------------------+ | | '-maxhalfopen--valeur-------------------' | +-remove--grappe:port-----------------------------------------+ +-report--grappe:port-----------------------------------------+ +-status--grappe:port-----------------------------------------+ '-halfopenaddressreport--grappe:port--------------------------'
Sous Windows, cela signifie qu'elle doit figurer dans la configuration des fonctions de gestion réseau. La commande cluster configure ne suffit pas, car elle ne simule que la définition d'adresse IP et le proxy ne peut pas établir un lien avec cette fausse adresse IP. Sous tous les autres systèmes d'exploitation, la commande cluster configure est appropriée, car elle utilise ifconfig pour l'alias de l'adresse IP.
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.
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 de plus amples informations, reportez-vous à Détection d'attaque de refus de service.
Exemples
ndcontrol port add 130.40.52.153:80+23
ndcontrol port set 130.40.52.153:0
mlcontrol port add 9.37.60.91:20 protocol pop3
ndcontrol port set 130.40.52.153:80 weightbound 10
ndcontrol port set 130.40.52.153:80+23 stickytime 60
ndcontrol port set 130.40.52.153:80 crossport 23
ndcontrol port remove 130.40.52.153:23
ndcontrol 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 Adresse de grappe ..................... 9.67.131.153 Nombre de serveurs .................... 2 Délai d'expiration .................... 30 Limite de pondération ................. 20 Nombre maximal de serveurs ............ 32 Délai de maintien de routage .......... 0 Type de port .......................... tcp/udp Méthode d'acheminement ................ acheminement MAC Bits du masque de rappel .............. 32 Affinité trans ports .................. 80 Nombre maximal de connexions partielles 0
ndcontrol 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
>>-ndcontrol--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---------------------+ +-pattern=--motif----------------------+ +-tos--valeur--------------------------+ +-stickytime--heure--------------------+ +-affinité--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 Network Dispatcher.
Le type d'affinité "passivecookie" permet l'équilibrage de 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 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 de plus amples informations, reportez-vous à Affinité de cookie passif.
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
ndcontrol rule add 9.37.67.100:80:trule type true priority 100
ndcontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
ndcontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 ndcontrol rule useserver cluster1:80:timerule server05
ndcontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
ndcontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
ndcontrol cluster set 9.67.131.153 sharedbandwidth 200 ndcontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-ndcontrol--server--+-add--grappe:port:serveur--+-------------------------+-+->< | +-address--adresse--------+ | | +-collocated--valeur------+ | | +-sticky--valeur----------+ | | +-weight--valeur----------+ | | +-fixedweight--valeur-----+ | | +-mapport--valeur de port-+ | | +-router--adr-------------+ | | +-cookievalue--valeur-----+ | | +-returnaddress--adr------+ | | +-advisorrequest--chaîne--+ | | '-advisorresponse--chaîne-' | +-set--grappe:port:serveur--+-collocated--valeur------+-+ | +-sticky--valeur----------+ | | +-weight--valeur----------+ | | +-fixedweight--valeur-----+ | | +-router--adr-------------+ | | +-cookievalue--valeur-----+ | | +-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 ndcontrol server add. Pour de plus amples informations, reportez-vous à Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP).
Exemples
ndcontrol server add 130.40.52.153:80:27.65.89.42
ndcontrol server set 130.40.52.153:80:27.65.89.42 sticky no
ndcontrol server down 130.40.52.153:80:27.65.89.42
ndcontrol server remove ::27.65.89.42
ndcontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
ndcontrol server set 130.40.52.153:80:27.65.89.42 weight 10
ndcontrol server up 130.40.52.153:80:27.65.89.42
ndcontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
ndcontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/2.0\""
>>-ndcontrol--set--+-loglevel--niveau-------+------------------>< +-logsize--+-unlimited-+-+ | '-taille----' | '-logstatus--------------'
>>-ndcontrol--status-------------------------------------------><
Exemples
ndcontrol 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 | PORT | DELAI | -------------------------------- | reach | 0 | illimité | | http | 80 | illimité | | ftp | 21 | illimité | --------------------------------
>>-ndcontrol--subagent--+-loglevel--niveau---------------------------+->< +-logsize--+-octets----+---------------------+ | '-unlimited-' | +-report-------------------------------------+ +-start--+---------------------------------+-+ | '-nom_communauté--fichier_journal-' | +-status-------------------------------------+ +-stop---------------------------------------+ '-version------------------------------------'
Exemples
ndcontrol subagent start bigguy bigguy.log
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=http://10.1.203.4/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=http://10.1.203.4/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 Network Dispatcher, 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 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-' | +-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 |
imap | IMAP | 143 |
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 (secondes) ............................ Illimité Délai de connexion (secondes)................ 21 Délai de réception (secondes)................ 21 Nom du fichier journal du conseiller ........ Http_80.log Niveau de consignation ...................... 1 Taille maximale du journal (octets) ......... Illimité
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.
Chemin d'accès courant au répertoire d'installation -- c:\Program Files\ibm\edge\nd\servers\configurations\ composant
Chemin d'accès au répertoire d'installation natif -- c:\Program Files\ibm\nd\servers\configurations\composant
Exemples
sscontrol file delete fichier3 Le fichier (fichier3) est supprimé.
sscontrol file newload fichier1.sv Le fichier (fichier1.sv) a été chargé dans le Dispatcher.
sscontrol file appendload fichier2.sv Le fichier (fichier2.sv) a été ajouté à la configuration actuelle et chargé.
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-------+ +-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 statusLes paramètres entre caractères < > sont des variables.
logsize <nombre d'octets | unlimited> - Nombre maximal d'octets à consigner dans le journal
>>-sscontrol--manager--+-interval--secondes-------------------------------------------+->< +-loglevel--niveau---------------------------------------------+ +-logsize--+-size | unlimited-+--------------------------------+ | '-octets-----------' | +-reach set--+-intervalles-secondes--------------------------+-+ | '-+-niveauconsignation-niveau-----------------+-' | | '---tailleconsignation-taille | unlimited---' | +-report--nomsite+sn2+...+snN----------------------------------+ +-restart--message---------------------------------------------+ +-sensitivity--pondération-------------------------------------+ +-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 à la section Annexe F, 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 de contact (octets).... unlimited Intervalle de mise à jour des contacts (secondes). 7
sscontrol manager stop
sscontrol manager version
>>-sscontrol--metric--+-add--nom_site+sn2+...+snN:mesure+mesure1+...+mesureN--------------+->< +-remove--nom_site+sn2+...+snN:mesure+mesure1+...+mesureN-----------+ +-proportions--nom_site+sn2+...+snN:proportion1 prop2 prop3...propN-+ '-status--nom_site+sn2+...+snN 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 Proportion de la mesure........ 50 Serveur ............. 9.37.56.100 Données de mesure... -1
>>-sscontrol--nameserver--+-start--+----------------------+-+-->< | '-bindaddress--adresse-' | +-stop----------------------------+ '-status--------------------------'
>>-sscontrol--rule--+-add--nom_site+sn2+...+snN:règle+r2+...+rN--type--valeur--| value |--| opts |-+->< +-dropserver--nom_site+sn2+...+snN:règle+r2+...+rN--serveur+s2+...+snN---------+ +-remove--nom_site+sn2+...+snN:règle+r2+...+rN---------------------------------+ +-set--nom_site+sn2+...+snN:règle+r2+...+rN--| value |--| opts |---------------+ +-status--nom_site+sn2+...+snN:règle+r2+...+rN---------------------------------+ '-useserver--nom_site+sn2+...+snN:règle+r2+...+rN--serveur+s2+...+snN----------' 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+sn2+...+snN:serveur+s2+...+sN--+------------------------+-+->< | +-metricaddress--adresse-+ | | '-weight--valeur---------' | +-down--nom_site+sn2+...+snN:serveur+s2+...+sN----------------------------+ +-remove--nom_site+sn2+...+snN:serveur+s2+...+sN--------------------------+ +-set--nom_site+sn2+...+snN:serveur+s2+...+sN--+------------------------+-+ | +-metricaddress--adresse-+ | | '-weight--valeur---------' | +-status--nom_site+sn2+...+snN:serveur+s2+...+sN--------------------------+ '-up--nom_site+sn2+...+snN: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----' | '-logstatus--------------'
>>-sscontrol--sitename--+-add--nomsite+sn2+...+snN--+-----------------------------------------+-+->< | +-cachelife--valeur-----------------------+ | | +-networkproximity--oui | non-------------+ | | +-proportions--cpu--mémoire--port--mesure-+ | | +-proximitypercentage--valeur-------------+ | | +-stickytime--heure-----------------------+ | | +-ttl--heure------------------------------+ | | +-waitforallresponses--oui | non----------+ | | '-weightbound--pondération----------------' | +-remove--nomsite+sn2+...+snN-------------------------------------------+ +-set--nomsite+sn2+...+snN--+-----------------------------------------+-+ | +-cachelife--valeur-----------------------+ | | +-networkproximity--oui | non-------------+ | | +-proportions--cpu--mémoire--port--mesure-+ | | +-proximitypercentage--valeur-------------+ | | +-stickytime--heure-----------------------+ | | +-ttl--heure------------------------------+ | | +-waitforallresponses--oui | non----------+ | | '-weightbound--pondération----------------' | '-status--nomsite+sn2+...+snN-------------------------------------------'
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 lbccontrol pour Consultant for Cisco CSS Switches :
Vous pouvez entrer une version abrégée des paramètres de commandes ndcontrol. Il suffit d'entrer les lettres uniques des paramètres. Par exemple, pour l'aide correspondant à la commande file save, entrez lbccontrol he f à la place de lbccontrol help file.
Le préfixe "lbc" signifie load-balancing consultant (consultant d'équilibrage de la charge).
>>-lbccontrol--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--+-port--------+--port--+-size | unlimited-+-----------------+ | '-grappe:port-' '-octets-----------' | +-receivetimeout--nom--+-port--------+--délai d'expiration en secondes-+ | '-grappe:port-' | +-report--nom--+-port--------+-----------------------------------------+ | '-grappe:port-' | +-start--nom--+-port--------+--+-----------------+---------------------+ | '-grappe:port-' '-fichier journal-' | +-status--nom--+-port--------+-----------------------------------------+ | '-grappe:port-' | +-stop--nom--+-port--------+-------------------------------------------+ | '-grappe:port-' | +-timeout--nom--+-port--------+--+-seconds | unlimited-+---------------+ | '-grappe:port-' '-secondes------------' | '-version--nom--+-port--------+----------------------------------------' '-grappe:port-'
Nom du conseiller | Protocole | Port |
---|---|---|
connect | ICMP | 12345 |
db2 | privé | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
ibmproxy | HTTP (via Caching Proxy) | 80 |
imap | IMAP | 143 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | privé | 10007 |
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.
Définissez les proportions du gestionnaire pour vous assurer que les informations du conseiller sont utilisées.
Exemples
lbccontrol advisor connecttimeout http 80 30
lbccontrol advisor interval ftp 21 6
lbccontrol advisor listCette commande génère des résultats similaires à l'exemple suivant :
------------------------------ | ADVISOR | PORT | TIMEOUT | ------------------------------ | http | 80 | unlimited | | ftp | 21 | unlimited | ------------------------------
lbccontrol advisor loglevel http 80 0
lbccontrol advisor logsize ftp 21 5000
lbccontrol advisor receivetimeout http 80 60
lbccontrol 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
lbccontrol advisor start ftp 21 ftpadv.log
lbccontrol advisor status http 80Cette commande génère des résultats similaires à l'exemple suivant :
Etat du conseiller (advisor) : --------------- Intervalle (secondes) ............ 15 Délai d'expiration (secondes) ............... Illimité 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) ......... Illimité
lbccontrol advisor stop http 80
lbccontrol advisor timeout ftp 21 5
lbccontrol advisor version ssl 443
>>-lbccontrol--cluster--+-add--grappe+g2+...--+-proportions--activ.--nouv.--port--système-+-+->< | '-weightbound--pondération------------------' | +-set--grappe+g2+...--+-proportions--activ.--nouv.--port--système-+-+ | '-weightbound--pondération------------------' | +-remove--grappe----------------------------------------------------+ '-status--grappe----------------------------------------------------'
Exemples
lbccontrol cluster add 130.40.52.153
lbccontrol cluster remove 130.40.52.153
lbccontrol cluster proportions 60 35 5 0
lbccontrol cluster status 9.67.131.167Cette commande génère des résultats similaire à l'exemple suivant :
Etat de la grappe (cluster) : --------------- Adresse .............................................. 9.67.131.167 Nombre de ports cibles ............................... 3 Limite de pondération par défaut du port ............... 10 Proportion accordée aux connexions actives .. 49 Proportion accordée aux nouvelles connexions ..... 49 Proportion accordée aux connexions spécifiques du port ... 2 Proportion accordée aux mesures du système ...... 0
>>-lbccontrol--exécuteur--+-set--+-address--valeur-------+-+--->< | +-communityname--valeur-+ | | +-timeout--valeur-------+ | | '-retries--valeur-------' | '-status-------------------------'
Exemples
lbccontrol executor status Etat de l'exécuteur : ---------------- adresse ............................. 9.67.131.151 nom de la communauté ...................... public délai ....................... 3 nombre de tentatives ....................... 2
lbccontrol executor set address 130.40.52.167
>>-lbccontrol--file--+-delete--nomfichier.ext-------------+---->< +-appendload--nomfichier.ext---------+ +-report-----------------------------+ +-save--nomfichier.ext--force--------+ '-newload--nomfichier.ext--+-------+-' '-force-'
Vous pouvez indiquer n'importe quelle extension de fichier (.ext) ou n'en indiquer aucune
Chemin d'accès courant au répertoire d'installation -- c:\Program Files\ibm\edge\nd\servers\configurations\ composant
Chemin d'accès au répertoire d'installation natif -- c:\Program Files\ibm\nd\servers\configurations\composant
Exemples
lbccontrol file delete fichier3 Le fichier (fichier3) est supprimé.
lbccontrol file newload fichier1.sv Le fichier (fichier1.sv) a été chargé dans Dispatcher.
lbccontrol file appendload fichier2.sv Le fichier (fichier2.sv) a été chargé et ajouté à la configuration actuelle.
lbccontrol file report RAPPORT SUR LES FICHIERS : fichier1.sauv fichier2.sv fichier3
lbccontrol file save fichier3 La configuration est sauvegardée dans fichier3.
>>-lbccontrol--help--+-advisor--+------------------------------>< +-cluster--+ +-executor-+ +-file-----+ +-help-----+ +-host-----+ +-log------+ +-manager--+ +-metric---+ +-port-----+ +-server---+ +-set------+ '-status---'
Exemples
lbccontrol helpCette commande génère des résultats similaires à l'exemple suivant :
ARGUMENTS DE LA COMMANDE HELP : --------------------------------- Syntaxe : help <option> Exemple : help cluster executor - Aide sur la commande executor cluster - Aide sur la commande cluster port - Aide sur la commande port rule - Aide sur la commande rule subagent - Aide sur la commande subagent manager - Aide sur la commande manager metric - Aide sur la commande metric advisor - Aide sur la commande advisor file - Aide sur la commande file host - Aide sur la commande host log - Aide sur la commande log set - Aide sur la commande set status - Aide sur la commande status help - Impression du texte d'aide dans son intégralitéLes paramètres entres les caractères < > sont des variables.
>>-lbccontrol--host:--hôte_éloigné-----------------------------><
lbccontrol host:hôte_éloigné
Exécutez cette commande à partir d'une invite, puis entrez une commande lbccontrol valide à appliquer à la machine Cisco Consultant éloignée.
>>-lbccontrol--log--+-start-----------------------+------------>< +-stop------------------------+ +-set--+-retention--heures--+-+ | '-interval--secondes-' | '-status----------------------'
>>-lbccontrol--manager--+-interval--secondes-----------------------+->< +-loglevel--niveau-------------------------+ +-logsize--+-size | unlimited-+------------+ | '-octets-----------' | +-quiesce--serveur--+-----+----------------+ | '-now-' | +-reach set--+-interval--secondes--------+-+ | +-loglevel--niveau----------+ | | '-logsize--size | unlimited-' | +-refresh--cycle de mise à jour------------+ +-report--+---------------+----------------+ | '-grappe+g2+...-' | +-restart--message-------------------------+ +-sensitivity--pondération-----------------+ +-smoothing--valeur------------------------+ +-start--+-------------------------------+-+ | '-nomfichierjournal--portmesure-' | +-status-----------------------------------+ +-stop-------------------------------------+ +-unquiesce--serveur-----------------------+ '-version----------------------------------'
Le fichier par défaut se trouve dans le répertoire logs. Reportez-vous à la section Annexe F, Exemples de fichiers de configuration. Pour obtenir des informations sur le mode de modification du répertoire dans lequel les fichiers journaux sont enregistrés, reportez-vous à la section Modification des chemins des fichiers journaux.
Exemples
lbccontrol manager interval 5
lbccontrol manager loglevel 0
lbccontrol manager logsize 1000000
lbccontrol manager quiesce 130.40.52.153
lbccontrol manager refresh 3
lbccontrol manager reportCette commande génère des résultats similaires à l'exemple suivant :
lbccontrol>>rapport du gestionnaire ---------------------------------------- | TABLE DES HOTES | ETAT | ---------------------------------------- | serveur6 | ACTIF | | serveur5 | ACTIF | | serveur4 | ACTIF | | serveur3 | ACTIF | | serveur2 | ACTIF | | serveur1 | ACTIF | ---------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.35 | POND. | ACTIV. % 49 | NOUV. % 50 | PORT % 1 | SYSTEME % 0 | ------------------------------------------------------------------------------------------------- | PORT : 80 | ACTU. | NV. | PND | CONNEXIONS | PND | CONNEXIONS | PND | CHARGE | PND | CHARGE | ------------------------------------------------------------------------------------------------- | serveur1 | 4 | 4 | 5 | 0 | 5 | 0 | 3| 301 |-9999| -1 | | serveur2 | 5 | 5 | 5 | 0 | 5 | 0 | 6| 160 |-9999| -1 | ------------------------------------------------------------------------------------------------- | TOTAUX : | 9 | 9 | | 0 | | 0 | | 461 | | -2 | ------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.35 | POND. | ACTIV. % 49 | NOUV. % 50 | PORT % 1 | SYSTEME % 0 | ------------------------------------------------------------------------------------------------- | PORT : 443 | ACTU. | NV. | PND | CONNEXIONS | PND | CONNEXIONS | PND | CHARGE | PND | CHARGE | ------------------------------------------------------------------------------------------------- | serveur3 | 4 | 4 | 5 | 0 | 5 | 0 | | 0 | -9999| -1 | | serveur4 | 5 | 5 | 5 | 0 | 5 | 0 | 0| 0 | -9999| -1 | ------------------------------------------------------------------------------------------------- | TOTAUX : | 9 | 9 | | 0 | | 0 | | 0 | | -2 | ------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------- | 9.67.154.34 | POND. | ACTIV. % 49 | NOUV. % 50 | PORT % 1 | SYSTEME % 0 | ------------------------------------------------------------------------------------------------- | PORT : 80 | ACTU. | NV. | PND | CONNEXIONS | PND | CONNEXIONS | PND | CHARGE | PND | CHARGE | ------------------------------------------------------------------------------------------------- | serveur5 | 5 | 5 | 5 | 0 | 5 | 0 | 5 | 160 | -9999| -1 | | serveur6 | 0 | 0 | 5 | 0 | 5 | 0 |-9999| -1 | -9999| -1 | ------------------------------------------------------------------------------------------------- | TOTAUX : | 5 | 5 | | 0 | | 0 | | 159 | | -2 | ------------------------------------------------------------------------------------------------- -------------------------------- | ADVISOR | PORT | TIMEOUT | -------------------------------- | http | 80 | unlimited | --------------------------------
lbccontrol manager restart Restarting the manager to update codeCette commande génère des résultats similaires à l'exemple suivant :
320-14:04:54 Relance du gestionnaire pour mettre à jour le code
lbccontrol manager sensitivity 10
lbccontrol manager smoothing 2.0
lbccontrol manager start ndmgr.log
lbccontrol manager statusCette commande génère des résultats similaires à l'exemple suivant :
Etat du gestionnaire (manager) : ============= Port de mesure .................................. 10004 Nom de fichier journal de 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 des mises à jour des pondérations ........................ 1 Niveau de journal des contacts .............................. 1 Taille maximale du journal des contacts (octets) ............... unlimited Intervalle de mise à jour des contacts (secondes) .............. 7
lbccontrol manager stop
lbccontrol manager version
>>-lbccontrol--metric--+-add--grappe+c2+...+cN:mesure+mesure1+...+mesureN--------------+->< +-remove--grappe+c2+...+cN:mesure+mesure1+...+mesureN-----------+ +-proportions--grappe+c2+...+cN:proportion1 prop2 prop3...propN-+ '-status--grappe+c2+...+cN:mesure+mesure1+...+mesureN-----------'
Remarque : Pour Cisco Consultant, l'adresse de grappe correspond à l'adresse IP virtuelle (VIP) de la règle de contenu du propriétaire dans la configuration Cisco CSS Switch.
Exemples
lbccontrol metric add 10.10.10.20:metric1
lbccontrol metric proportions 10.10.10.20 48 52
lbccontrol metric status 10.10.10.20: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........ 52 Serveur ............. 9.37.56.100 Données de mesure... -1
>>-lbccontrol--port--+-add--grappe:port--+--------------------------+-+->< | '-weightbound--pondération-' | +-set--grappe:port--+--------------------------+-+ | '-weightbound--pondération-' | +-remove--grappe:port----------------------------+ '-status--grappe:port----------------------------'
Exemples
lbccontrol port add 130.40.52.153:80+23
lbccontrol port set 130.40.52.153:80 weightbound 10
lbccontrol port remove 130.40.52.153:23
lbccontrol 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 Adresse de grappe ..................... 9.67.131.153 Nombre de serveurs .................... 2 Limite de pondération ................... 10
>>-lbccontrol--server--+-add--grappe:port:serveur--+---------------------+-+->< | +-weight--valeur------+ | | +-fixedweight--valeur-+ | | '-address--adresse----' | +-set--grappe:port:serveur--+-weight--valeur------+-+ | '-fixedweight--valeur-' | +-down--grappe:port:serveur-------------------------+ +-remove--grappe:port:serveur-----------------------+ +-report--grappe:port:serveur-----------------------+ +-up--grappe:port:serveur---------------------------+ '-status--grappe:port:serveur-----------------------'
Exemples
lbccontrol server add 130.40.52.153:80:27.65.89.42
lbccontrol server remove ::27.65.89.42
lbccontrol server set 130.40.52.153:80:27.65.89.42 weight 10
>>-lbccontrol--set--+-loglevel--niveau----+-------------------->< +-logsize--+-taille-+-+ | '-taille-' | '-logstatus-----------'
>>-lbccontrol--status------------------------------------------><
Exemples
lbccontrol statusCette commande génère des résultats similaires à l'exemple suivant :
Le gestionnaire (manager) a été lancé -------------------------------- | ADVISOR | PORT | TIMEOUT | -------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | --------------------------------
La présente annexe contient des exemples de fichiers de configuration pour le composant Dispatcher de Network Dispatcher.
Les exemples de fichiers se trouvent dans le répertoire .../nd/servers/samples/.
#!/bin/ksh
#
# configuration.sample - Exemple de fichier de configuration pour
le composant Dispatcher
#
#
# Ce script doit être lancé par l'utilisateur root.
#
# iam=`whoami`
# if [ "$iam" != "root" ]if [ "$iam" != "root" ]
# then
# echo "Vous devez vous connecter en tant qu'utilisateur root pour exécuter ce script"
# exit 2
# fi
#
# Démarrez d'abord le serveur
#
# ndserver start
# sleep 5
#
# Lancez ensuite l'exécuteur
#
# ndcontrol executor start
#
# Il est possible d'arrêter le répartiteur à tout moment à l'aide
# des commandes "ndcontrol executor stop" et "ndserver 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"
# ndcontrol 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"
# ndcontrol 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"
# ndcontrol 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"
# ndcontrol 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 proportions doit être égale à 100. Par exemple,
# si l'on définit les proportions du gestionnaire de la façon suivante :
# ndcontrol 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 "Lancement du gestionnaire (manager)..."
# ndcontrol manager start
# echo "Lancement du conseiller (advisor) FTP sur le port 21..."
# ndcontrol advisor start ftp 21
# echo "Lancement du conseiller (advisor) HTTP sur le port 80..."
# ndcontrol advisor start http 80
# echo "Lancement du conseiller (advisor) Telnet sur le port 23..."
#ndcontrol advisor start telnet 23
# echo "Lancement du conseiller (advisor) SMTP sur le port 25..."
# ndcontrol advisor start smtp 25
# echo "Lancement du conseiller (advisor) POP3 sur le port 110..."
# ndcontrol advisor start pop3 110
# echo "Lancement du conseiller (advisor) NNTP sur le port 119..."
# ndcontrol advisor start nntp 119
# echo "Lancement du conseiller (advisor) SSL sur le port 443..."
# ndcontrol advisor start ssl 443
#
# echo "Définition des proportions du gestionnaire..."
# ndcontrol 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.
# ndcontrol cluster 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.
# ndcontrol cluster 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.
# ndcontrol manager loglevel 1
# ndcontrol manager logsize 1048576
# ndcontrol manager sensitivity 5.000000
# ndcontrol manager interval 2
# ndcontrol manager refresh 2
#
# ndcontrol advisor interval ftp 21 5
# ndcontrol advisor loglevel ftp 21 1
# ndcontrol advisor logsize ftp 21 1048576
# ndcontrol advisor timeout ftp 21 unlimited
# ndcontrol advisor interval telnet 23 5
# ndcontrol advisor loglevel telnet 23 1
# ndcontrol advisor logsize telnet 23 1048576
# ndcontrol advisor timeout telnet 23 unlimited
# ndcontrol advisor interval smtp 25 5
# ndcontrol advisor loglevel smtp 25 1
# ndcontrol advisor logsize smtp 25 1048576
# ndcontrol advisor timeout smtp 25 unlimited
# ndcontrol advisor interval http 80 5
# ndcontrol advisor loglevel http 80 1
# ndcontrol advisor logsize http 80 1048576
# ndcontrol advisor timeout http 80 unlimited
# ndcontrol advisor interval pop3 110 5
# ndcontrol advisor loglevel pop3 110 1
# ndcontrol advisor logsize pop3 110 1048576
# ndcontrol advisor timeout pop3 110 unlimited
# ndcontrol advisor interval nntp 119 5
# ndcontrol advisor loglevel nntp 119 1
# ndcontrol advisor logsize nntp 119 1048576
# ndcontrol advisor timeout nntp 119 unlimited
# ndcontrol advisor interval ssl 443 5
# ndcontrol advisor loglevel ssl 443 1
# ndcontrol advisor logsize ssl 443 1048576
# ndcontrol advisor timeout ssl 443 unlimited
#
Voici un exemple de fichier de configuration de Network Dispatcher 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 ndserver à partir du panneau Services rem rem rem Lancez ensuite l'exécuteur rem rem call ndcontrol 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 ndcontrol 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 ndcontrol executor set fintimeout 30 rem call ndcontrol 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 ndcontrol cluster add %CLUSTER% rem rem L'étape suivante consiste à définir les ports utilisés par cette 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 ndcontrol 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 ndcontrol 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 circulaire rem (round-robin). Une fois le gestionnaire lancé, les décisions de rem pondération basées sur le nombre de connexions nouvelles et actives rem sont utilisées et les requêtes entrantes sont envoyées au meilleur rem serveur. Les conseillers permettent au gestionnaire de disposer d'informations rem supplémentaires sur la capacité du serveur à répondre aux requêtes rem et à détecter si un serveur est actif ou non. Si un conseiller rem détecte qu'un serveur est arrêté, cela sera consigné (à condition que rem les proportions du gestionnaire aient été définies pour inclure les rem entrées du conseiller) et aucune requête ne sera 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 ndcontrol cluster set <cluster> 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 "Lancement du gestionnaire (manager)..." rem call ndcontrol manager start rem echo "Lancement du conseiller (advisor) FTP sur le port 21..." rem call ndcontrol advisor start ftp 21 rem echo "Lancement du conseiller (advisor) HTTP sur le port 80..." rem call ndcontrol advisor start http 80 rem echo "Lancement du conseiller Telnet sur le port 23 ..." rem call ndcontrol advisor start telnet 23 rem echo "Lancement du conseiller SMTP sur le port 25 ..." rem call ndcontrol advisor start smtp 25 rem echo "Lancement du conseiller POP3 sur le port 110 ..." rem call ndcontrol advisor start pop3 110 rem echo "Lancement du conseiller NNTP sur le port 119 ..." rem call ndcontrol advisor start nntp 119 rem echo "Lancement du conseiller SSL sur le port 443 ..." rem call ndcontrol advisor start ssl 443 rem rem echo "Définition des proportions de la grappe..." rem call ndcontrol 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 rem ndcontrol cluster 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 ndcontrol cluster 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 ndcontrol manager loglevel 1 rem call ndcontrol manager logsize 1048576 rem call ndcontrol manager sensitivity 5.000000 rem call ndcontrol manager interval 2 rem call ndcontrol manager refresh 2 rem rem rem call ndcontrol advisor interval ftp 21 5 rem call ndcontrol advisor loglevel ftp 21 1 rem call ndcontrol advisor logsize ftp 21 1048576 rem call ndcontrol advisor timeout ftp 21 unlimited rem call ndcontrol advisor interval telnet 23 5 rem call ndcontrol advisor loglevel telnet 23 1 rem call ndcontrol advisor logsize telnet 23 1048576 rem call ndcontrol advisor timeout telnet 23 unlimited rem call ndcontrol advisor interval smtp 25 5 rem call ndcontrol advisor loglevel smtp 25 1 rem call ndcontrol advisor logsize smtp 25 1048576 rem call ndcontrol advisor timeout smtp 25 unlimited rem call ndcontrol advisor interval http 80 5 rem call ndcontrol advisor loglevel http 80 1 rem call ndcontrol advisor logsize http 80 1048576 rem call ndcontrol advisor timeout http 80 unlimited rem call ndcontrol advisor interval pop3 110 5 rem call ndcontrol advisor loglevel pop3 110 1 rem call ndcontrol advisor logsize pop3 110 1048576 rem call ndcontrol advisor timeout pop3 110 unlimited rem call ndcontrol advisor interval nntp 119 5 rem call ndcontrol advisor loglevel nntp 119 1 rem call ndcontrol advisor logsize nntp 119 1048576 rem call ndcontrol advisor timeout nntp 119 unlimited rem call ndcontrol advisor interval ssl 443 5 rem call ndcontrol advisor loglevel ssl 443 1 rem call ndcontrol advisor logsize ssl 443 1048576 rem call ndcontrol advisor timeout ssl 443 unlimited rem
Vous trouverez ci-dessous un exemple de fichier de conseiller intitulé ADV_type.
/**
* ADV_type : Conseiller HTTP de Network Dispatcher
*
*
* Cette classe définit un exemple de conseiller personnalisé pour Network Dispatcher.
* 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 à Network Dispatcher, qui seront utilisées dans l'algorithme
* de pondération de Network Dispatcher. La base du conseiller effectue également
* des opérations de connexion et de fermeture de socket, 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 et la réception
* de données vers/sur le port du serveur conseillé.
* Les méthodes TCP de la base du conseiller sont programmées pour calculer la charge.
* Un indicateur de constructeur de ADV_base
* remplace, si vous le souhaitez, la charge existante par la nouvelle charge
* renvoyée pour 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 les répertoires Network Dispatcher
* suivants :
*
* nd/servers/lib/CustomAdvisors/
* (nd\servers\lib\CustomAdvisors sous Windows 2000)
*
* - 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 Network
* Dispatcher, doivent être compilés avec la version recommandée
* de Java.
* Pour pouvoir accéder aux classes de Network Dispatcher, vérifiez
* que le fichier ibmnd.jar
(situé dans le sous-répertoire lib du
* répertoire de base) figure dans la classe d'environnement
* CLASSPATH du système.
*
*
* Méthodes fournies par ADV_Base :
*
* - ADV_Base (Constructeur) :
*
* - Paramètres
* - String sName = Nom du conseiller
* - String sVersion = Version du conseiller
* - int iDefaultPort = Numéro de port par défaut utilisé par le conseiller
* - int iInterval = Intervalle que doivent utiliser les serveurs
* - String sDefaultLogFileName = Non utilisé. indiquer "".
* - boolean replace = True - remplacement de la valeur de la charge
* calculée 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 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
* de réception
* - 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.
*
* Un point important est de savoir si
* la charge renvoyée doit être appliquée à la charge
* générée dans la base du conseiller, ou la remplacer ;
* il existe des exemples valides dans les deux cas.
*
* Cet exemple concerne principalement le conseiller HTTP
* Dispatcher. 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_Network_Dispatcher_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 Network
* Dispatcher 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. Par conséquent, la pondération de l'équilibrage
* de charge restera dans Network Dispatcher.
*
* Si la valeur est négative, il s'agit d'une erreur. Une erreur
* du conseiller indique le serveur auquel le conseiller tente
* d'accéder n'est pas accessible et qu'une défaillance a été
* identifiée.
Network Dispatcher ne tentera pas d'équilibrer
* la charge d'un serveur défaillant. Network Dispatcher
* reprendra l'équilibrage de charge sur le serveur lorsqu'une
* valeur positive sera reçue.
*
* La valeur zéro n'est généralement pas renvoyée ; Network
* Dispatcher traite une charge de zéro de manière spéciale.
* Zéro est censé indiquer un état inconnu. Network Dispatcher
* affecte donc une pondération élevée en retour.
*/
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 cas de bonne réception, une charge de zéro est renvoyée.
// Ceci s'explique par le fait que l'indicateur "replace" a la
// valeur false, qui indique que la charge élaborée dans le
// conseiller de base doit être utilisée.
// Etant donné que les données renvoyées n'ont pas été utilisées,
// aucune charge supplémentaire n'est requise.
// Remarque : La charge de la base du conseiller ne doit pas
// être égale à zéro. Par conséquent, aucune charge égale à zéro
// n'est renvoyée dans le but de calculer la pondération.
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 Network Dispatcher (Dispatcher et CBR) et Caching Proxy.
Le serveur suivant est configuré pour la Figure 30 :
La Figure 30 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 Edge Server. 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é primaire (EdgeServer1).
Instructions de configuration de base :
Lignes de l'exemple auxquelles font référence les remarques 1 à 4 ci-dessus :
Hostname www.entreprise.com SendRevProxyName yes Caching ON CacheMemory 128000 K Proxy /* http://www.entreprise.com/* www.entreprise.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 Server comme illustré à la Figure 30. Ils correspondent aux fichiers des composants Dispatcher et CBR de Network Dispatcher. Dans ces fichiers, une seule carte de réseau Ethernet est utilisée pour chaque machine Edge Server 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 Edge Server haute disponibilité primaire :
ndcontrol executor start ndcontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 ndcontrol port add 192.168.1.11:80 ndcontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 ndcontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 ndcontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 ndcontrol manager start manager.log 10004 ndcontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 ndcontrol highavailability backup add primary auto 4567
Fichier de configuration exemple du composant CBR des serveurs Edge Server :
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
Dans plusieurs circonstances, vous pouvez utiliser les touches du clavier ou une combinaison de touches au lieu de manier votre souris pour certaines opérations. De nombreuses options de menu peuvent être appelées par le clavier.
Consultez la documentation de votre système d'exploitation pour obtenir des instructions relative à l'utilisation du clavier.
Network Dispatcher comprend une aide en ligne qui décrit les tâches que vous effectuerez lors de l'installation, de la planification, de la configuration et de l'utilisation du produit.
Pour obtenir l'aide relative à la fenêtre affichée, cliquez sur le point d'interrogation ( ? ) dans le coin supérieur droit. Sélectionnez l'une des options suivantes :
Pour des informations supplémentaires sur l'utilisation de Network Dispatcher, consultez les sites suivants :
http://www.ibm.com/software/webservers/edgeserver
http://www.ibm.com/software/webservers/edgeserver/support.html
Cliquez sur Search for Network Dispatcher hints and tips.
La mention de produits, de logiciels ou de services IBM dans le présent document n'implique aucunement l'intention d'IBM de les introduire dans tous les pays dans lesquels il intervient. Toute référence à un produit, un programme ou un service IBM n'est pas sensée établir ou impliquer que les produits, programmes ou services IBM peuvent être utilisés. Tout produit, programme ou service équivalent sur le plan fonctionnel aux produits, programmes ou services IBM peut être utilisé à leur place s'il fait partie de la propriété intellectuelle d'IBM ou est soumis à tout autre droit protégé légalement. L'évaluation et la vérification du fonctionnement conjointement à d'autres produits, exceptés ceux désignés expressément par IBM, relève de la responsabilité de l'utilisateur.
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. Vous pouvez adresser des demandes de licence à IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785, U.S.A.
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 EMEA Director of Licensing
Pour le Canada, veuillez adresser votre courrier à :
IBM Director of Commercial RelationsLe 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 condition stipulées par le contrat de clientèle IBM.
Le présent document n'est pas destiné à une utilisation en environnement de production, il est fourni en l'état, sans garantie d'aucune sorte et toutes les garanties y sont dénoncées, y compris la garantie de qualité marchande et de bon fonctionnement dans un but donné.
Ce produit comprend le logiciel informatique créé et distribué par CERN. Ce texte doit figurer intégralement dans chaque produit comprenant le logiciel informatique CERN inclus ou en faisant partie.
Les termes qui suivent sont des marques d'International Business Machines Corporation dans certains pays.
AIX
IBM
IBMLink
LoadLeveler
NetView
OS/2
WebSphere
Lotus est une marque de Lotus Development Corporation dans certains pays.
Domino est une marque de 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.
Cisco est une marque de Cisco Systems, Inc. dans certains pays.
HP est une marque de Hewlett-Packard dans certains pays.
Linux est une marque de Linus Torvalds.
Red Hat est une marque enregistrée de Red Hat, Inc.
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.