Le présent chapitre explique comment exploiter et gérer Load Balancer et inclut les sections suivantes :
Load Balancer offre deux manières différentes d'exécuter ses programmes de configuration sur une machine autre que celle sur laquelle se trouve Load Balancer. La communication entre les programmes de configuration (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) et le serveur (dsserver, cbrserver, etc.) peut s'établir de l'une des manières suivantes :
L'administration à distance via RMI est plus rapide que l'administration basée sur le Web.
L'administration basée sur le Web, outre qu'elle s'effectue à distance, présente l'avantage d'être une méthode sécurisée et authentifiée, capable de communiquer avec la machine Load Balancer même en présence d'un pare-feu. De plus, cette méthode d'administration ne requiert pas d'installation particulière et utilise des clés d'authentification (lbkeys) sur la machine client éloignée qui communique avec la machine Load Balancer.
Pour RMI, la commande permettant de connecter une machine Load Balancer pour l'administration à distance est dscontrol host:hôte_éloigné.
Si l'appel RMI vient d'une machine autre que la machine locale, une séquence d'authentification clé publique/clé privée se produit avant l'acceptation de la commande de configuration. une séquence d'authentification doit se produire avant que la commande configuration soit acceptée.
Les communications entre les programmes de contrôle exécutés sur la même machine que les serveurs du composant ne sont pas authentifiées.
La commande suivante permet de générer des clés publiques et privées à utiliser pour l'authentification à distance :
lbkeys [create|delete]
Cette commande s'exécute uniquement sur la même machine que Load Balancer.
L'option create permet de créer une clé privée dans le répertoire key des serveurs :
Le script crée également les clés publiques dans le répertoire de clés d'administration pour chaque composant de Load Balancer :
Le nom de fichier de la clé publique est : composant-AdresseServeur-PortRMI. Ces clés publiques doivent ensuite être transmises aux clients éloignés et placés dans le répertoire keys d'administration.
Pour une machine Load Balancer avec une adresse de nom d'hôte 10.0.0.25 utilisant le port RMI par défaut pour chaque composant, la commande lbkeys create génère les fichiers suivants :
Le jeu de fichiers d'administration a été installé sur une autre machine. Les fichiers de clés publiques doivent être placés dans le répertoire suivant sur la machine client éloignée :
Le client éloigné sera désormais autorisé à configurer Load Balancer sur 10.0.0.25.
Ces mêmes clés doivent être utilisées sur tous les clients éloignés que vous souhaitez autoriser à configurer Load Balancer sur 10.0.0.25.
Si vous devez de nouveau exécuter la commande lbkeys create, un nouveau jeu de clés publiques/privées sera généré. Ceci signifie que tous les clients éloignés qui ont tenté de se connecter à l'aide des clés précédentes ne seront plus autorisés. La nouvelle clé doit être placée dans le répertoire adéquat sur les clients auxquels vous voulez attribuer des autorisations.
La commande lbkeys delete permet de supprimer les clés privées et publiques sur la machine serveur. Si ces clés sont supprimées, aucun client éloigné ne sera autorisé à se connecter aux serveurs.
L'option force peut être associée à la commande lbkeys et à la commande lbkeys delete. Elle permet de supprimer les invites demandant si vous voulez remplacer ou supprimer les clés existantes.
Après avoir établi la connexion RMI, vous pouvez naviguer entre les programmes de configuration à l'aide des commandes dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol, dswizard, cbrwizard et sswizard, émises à partir d'une invite de commande. Vous pouvez également configurer Load Balancer à l'aide de l'interface graphique en entrant la commande lbadmin à partir d'une invite de commande.
La machine client sur laquelle s'effectue l'administration à distance requiert les éléments suivants pour l'administration basée sur le Web :
La machine hôte à laquelle vous accédez pour l'administration à distance basée sur le Web requiert les éléments suivants :
Pour les systèmes Windows —
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\PROGRA~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\PROGRA~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\PROGRA~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\PROGRA~1\IBM\edge\lb\admin\* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\lang\*où lang désigne le sous-répertoire de votre langue de travail (par exemple, en_US)
Pour les systèmes d'exploitation AIX, HP-UX, Linux et Solaris —
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/lang/* /opt/ibm/edge/lb/documentation/lang/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Pour s'exécuter, l'administration basée sur le Web doit être lancée sur la machine hôte Load Balancer en émettant la commande lbwebaccess à partir de l'invite de commande de l'hôte.
Vous devez également indiquer l'ID utilisateur et le mot de passe d'accès distant à l'hôte. Cet ID utilisateur et ce mot de passe sont identiques à l'ID utilisateur et au mot de passe d'administration Caching Proxy.
Pour afficher l'administration basée sur le Web de Load Balancer, accédez à l'URL suivante du navigateur Web à partir de l'emplacement éloigné :
http:// nom_hôte/lb-admin/lbadmin.html
Où nom_hôte est le nom de la machine à laquelle vous accédez pour communiquer avec Load Balancer.
Une fois la page Web chargée, l'interface graphique Load Balancer, nécessaire à l'administration à distance basée sur le Web, s'affiche dans la fenêtre du navigateur.
A partir de l'interface graphique Load Balancer, vous pouvez également exécuter des commandes de contrôle de la configuration. Pour émettre une commande à partir de l'interface graphique, procédez comme suit :
Régénération à distance de la configuration
Avec l'administration à distance basée sur le Web, lorsque plusieurs administrateurs mettent à jour la configuration Load Balancer à partir de postes éloignés, vous devez régénérer la configuration pour, par exemple, visualiser le cluster, le port ou le serveur ajouté (ou supprimé) par un autre administrateur. L'interface graphique de l'administration à distance basée sur le Web propose les fonctions Régénérer la configuration et Régénérer toutes les configurations.
Pour régénérer la configuration à partir de l'interface graphique basée sur le Web :
Load Balancer enregistre les entrées dans un journal du serveur, un journal du gestionnaire, un journal du contrôleur de mesures (consignation des communications avec les agents Metric Server) et dans un journal pour chaque conseiller utilisé.
Vous pouvez définir le niveau de consignation pour déterminer le détail des messages consignés dans les journaux. Au niveau 0, les erreurs sont enregistrées dans un fichier journal et Load Balancer consigne également les en-têtes et les enregistrements des événements survenus une seule fois (par exemple, un message indiquant que le lancement d'un conseiller sera enregistré dans le journal du gestionnaire). Le niveau 1 inclut les données en circulation, et ainsi de suite jusqu'au niveau 5, qui inclut tous les messages émis susceptibles d'aider à résoudre un incident lorsque cela s'avère nécessaire. La valeur par défaut du journal du gestionnaire, du conseiller, du serveur ou du sous-agent est 1.
Vous pouvez également fixer la taille maximale d'un fichier journal. Lorsque vous attribuez une taille maximale au fichier journal, ce dernier fonctionne en boucle. Lorsque le fichier atteint la taille indiquée, les entrées suivantes sont écrites en haut du fichier et remplacent les entrées existantes. Lorsque vous spécifiez une nouvelle taille pour un fichier journal, elle ne doit pas être inférieure à sa taille courante. Les entrées de fichier journal sont horodatées, ce qui permet de déterminer l'ordre dans lequel elles ont été créées.
Plus le niveau de consignation choisi est élevé, plus la taille du fichier journal doit être définie judicieusement. Au niveau 0, il sera probablement sage de laisser la taille du fichier journal à sa valeur par défaut (1 Mo). Par contre, à partir du niveau 3, limitez la taille du fichier journal sans trop d'excès pour lui garder son utilité.
Par défaut, les journaux générés par Load Balancer sont stockés dans le répertoire des journaux de l'installation de Load Balancer. Pour modifier ce chemin, définissez la variable lb_logdir dans le script dsserver.
Systèmes AIX, HP-UX, Linux et Solaris : Le script dsserver se trouve dans le répertoire /usr/bin. Dans ce script, la variable lb_logdir indique le répertoire par défaut. Vous pouvez modifier cette variable pour indiquer le répertoire de fichiers journaux de votre choix. Exemple :
LB_LOGDIR=/chemin\de\mes\fichiers\journaux/
Systèmes Windows : Le fichier dsserver se trouve dans le répertoire <root_install>ibm\edge\lb\bin. Dans le fichier dsserver, la variable lb_logdir indique le répertoire par défaut. Vous pouvez modifier cette variable pour indiquer le répertoire de fichiers journaux de votre choix. Exemple :
set LB_LOGDIR=c:\chemin\de\mes\fichiers\journaux\
Quel que soit le système d'exploitation utilisé, assurez-vous qu'il n'y a pas d'espace avant ou après le signe égal et que le chemin se termine par une barre oblique ("/" ou "\" selon le cas).
La fonction de consignation binaire de Load Balancer utilise le répertoire contenant les autres fichiers journaux. Voir Utilisation de la consignation binaire pour analyser les statistiques des serveurs.
Vous pouvez définir le niveau de consignation pour déterminer le détail des messages consignés dans les journaux. Au niveau 0, les erreurs sont enregistrées dans un fichier journal et Load Balancer consigne également les en-têtes et les enregistrements des événements survenus une seule fois (par exemple, un message indiquant que le lancement d'un conseiller sera enregistré dans le journal du consultant). Le niveau 1 inclut les données en circulation, et ainsi de suite jusqu'au niveau 5, qui inclut tous les messages émis susceptibles d'aider à résoudre un incident lorsque cela s'avère nécessaire. Le niveau par défaut des journaux est 1.
Vous pouvez également fixer la taille maximale d'un fichier journal. Dans ce cas, le fichier se bouclera ; une fois sa taille maximale atteinte, les nouvelles entrées seront consignées au début du fichier, écrasant les entrées les plus anciennes. Lorsque vous spécifiez une nouvelle taille pour un fichier journal, elle ne doit pas être inférieure à sa taille courante. Les entrées de fichier journal sont horodatées, ce qui permet de déterminer l'ordre dans lequel elles ont été créées.
Plus le niveau de consignation choisi est élevé, plus la taille du fichier journal doit être définie judicieusement. Au niveau 0, il sera probablement sage de laisser la taille du fichier journal à sa valeur par défaut (1 Mo). Par contre, à partir du niveau 3, limitez la taille du fichier journal sans trop d'excès pour lui garder son utilité.
Cisco CSS Controller et Nortel Alteon Controller ont les journaux suivants :
Voici un exemple de configuration du niveau de consignation ou la taille maximale du journal du contrôleur de mesures qui consigne les événements de communication avec les agents Metric Server :
xxxcontrol metriccollector set IDconsultant:IDservice:NomSystemMetric loglevel x logsize y
Par défaut, les journaux générés par les contrôleurs sont stockés dans le répertoire des journaux de l'installation du contrôleur. Pour modifier ce chemin, définissez la variable xxx_logdir dans le script xxxserver.
Systèmes AIX, HP-UX, Linux et Solaris : Le script xxxserver se trouve dans le répertoire /usr/bin. Dans ce script, la variable xxx_logdir indique le répertoire par défaut. Vous pouvez modifier cette variable pour indiquer le répertoire de fichiers journaux de votre choix. Exemple :
xxx_LOGDIR=/chemin\de\mes\fichiers\journaux/
Systèmes Windows : Le fichier xxxserver se trouve dans le répertoire <root_install>ibm\edge\lb\bin. Dans le fichier xxxserver, la variable xxx_logdir indique le répertoire par défaut. Vous pouvez modifier cette variable pour indiquer le répertoire de fichiers journaux de votre choix. Exemple :
set xxx_LOGDIR=c:\chemin\de\mes\fichiers\journaux\
Quel que soit le système d'exploitation utilisé, assurez-vous qu'il n'y a pas d'espace avant ou après le signe égal et que le chemin se termine par une barre oblique ("/" ou "\" selon le cas).
La fonction de consignation binaire de Load Balancer utilise le répertoire contenant les autres fichiers journaux. Voir Utilisation de la consignation binaire pour analyser les statistiques des serveurs.
La présente section explique comment utiliser et gérer le composant Dispatcher.
Pour Load Balancer, les connexions sont considérées comme périmées lorsqu'aucune activité ne s'est produite sur cette connexion pendant le nombre de secondes indiquées dans le délai d'attente. Lorsque ce nombre de secondes est dépassé et qu'aucune activité n'a eu lieu, Load Balancer supprime cet enregistrement de connexion de ces tables et le trafic à venir pour cette connexion est ignoré.
Au niveau du port, par exemple, vous pouvez indiquer la valeur du délai d'attente à partir de la commande dscontrol port set staletimeout.
Le délai d'attente peut être défini au niveau de l'exécuteur, du cluster et du port. Au niveau de l'exécuteur et du cluster, la valeur par défaut est 300 secondes et le filtrage est effectué jusqu'au port. Au niveau du port, la valeur par défaut dépend du port. Certains ports bien définis ont des valeurs de délai d'attente différentes. Par exemple, le port telnet 23 a une valeur par défaut de 259,200 secondes.
Certains services ont également leurs propres valeurs de délai d'attente. Par exemple, LDAP (Lightweight Directory Access Protocol) dispose d'un paramètre de configuration appelé idletimeout. Lorsque le nombre de secondes indiqué à l'aide de ce paramètre est dépassé, la fermeture d'une connexion de client inactif est provoquée. Vous pouvez attribuer la valeur 0 à ce paramètre, ce qui signifie que la fermeture de la connexion ne sera jamais provoquée.
Des problèmes de connectivité peuvent se produire lorsque la valeur du délai d'attente de Load Balancer est inférieure à la valeur du délai du service. Dans le cas de LDAP, la valeur par défaut du paramètre staletimeout (délai d'attente) de Load Balancer est 300 secondes. Si aucune activité ne se produit sur la connexion pendant 300 secondes, Load Balancer supprime l'enregistrement de connexion de ses tables. Si la valeur idletimeout est supérieure à 300 secondes (ou si elle est égale à 0), le client peut encore croire qu'une connexion au serveur est établie. Lorsque le client transmet des paquets, ces derniers seront ignorés par Load Balancer. De cette façon, LDAP est bloqué lorsqu'une demande au serveur est effectuée. Pour éviter ce problème, attribuez une valeur différente de zéro au paramètre, identique ou inférieure à la valeur du paramètre staletimeout de Load Balancer.
Une fois tous les paquets de données transmis, un client envoie un paquet FIN pour informer le serveur que la transaction est terminée. Lorsque Dispatcher réceptionne le paquet FIN, il remplace l'état de la transaction, active, par FIN. Lorsqu'une transaction est à l'état FIN, la mémoire réservée à la connexion est libérée.
Pour améliorer les performances de l'affectation et de la réutilisation des enregistrements de connexions, utilisez la commande executor set fintimeout pour contrôler la période pendant laquelle Dispatcher doit conserver les connexions à l'état FIN, c'est-à-dire actives, dans les tables Dispatcher et en état d'accepter le trafic. Lorsqu'une connexion à l'état FIN dépasse la valeur fintimeout, elle est supprimée des tables Dispatcher et prête à être utilisée. Vous pouvez modifier la valeur du délai d'expiration FIN à l'aide de la commande dscontrol executor set fincount.
Utilisez la commande dscontrol executor set staletimeout pour contrôler la période pendant laquelle Dispatcher doit conserver les connexions à l'état Established lorsqu'aucun trafic n'a été détecté comme étant actif dans les tables Dispatcher, et en état d'accepter le trafic. Pour plus d'informations, voir Utilisation de la valeur du délai d'attente.
Divers diagrammes peuvent être affichés en fonction des informations visualisées par l'exécuteur et transmises au gestionnaire. (Le gestionnaire doit s'exécuter pour pouvoir utiliser l'option de menu Contrôler de l'interface graphique).
Un système de gestion de réseau est un programme qui s'exécute en continu et qui sert à surveiller et à refléter l'état d'un réseau et à contrôler ce dernier. SNMP (Simple Network Management Protocol), protocole courant permettant de communiquer avec des périphériques d'un réseau, est la norme de gestion de réseau en cours. Les périphériques de réseau sont généralement dotés d'un agent SNMP et d'un ou de plusieurs sous-agents. L'agent SNMP communique avec le poste de gestion de réseau ou répond aux requêtes SNMP de 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. Cela permet d'utiliser un système de gestion de réseau (tel que Tivoli NetView, Tivoli Distributed Monitoring ou HP OpenView) pour surveiller l'état, le débit et l'activité de Dispatcher. Les données MIB décrivent la gestion de Dispatcher et reflètent l'état en cours de ce dernier. Elles sont installées dans le sous-répertoire ..lb/admin/MIB.
Le système de gestion de réseau utilise des commandes SNMP GET pour consulter les valeurs MIB des autres machines. Il peut ensuite vous envoyer une notification en cas de dépassement des valeurs seuil indiquées. Vous pouvez ensuite changer les performances de Dispatcher en modifiant les données de configuration de Dispatcher, afin d'effectuer une mise au point proactive ou de résoudre les incidents liés à Dispatcher avant qu'ils se transforment en pannes de serveur Web ou Dispatcher.
Le système fournit généralement un agent SNMP pour chaque poste de gestion de réseau. L'utilisateur adresse une commande GET à l'agent SNMP. En retour, ce dernier émet une commande GET pour extraire les valeurs de variables MIB indiquées à partir d'un sous-agent responsable de ces dernières.
Dispatcher fournit un sous-agent qui permet la mise à jour et l'extraction de données MIB. Le sous-agent répond aux données MIB appropriées lorsque l'agent SNMP émet une commande GET. L'agent SNMP communique les données au poste de gestion de réseau. Celui-ci peut vous envoyer une notification en cas de dépassement des valeurs seuil indiquées.
Le support SNMP de Dispatcher comporte un sous-agent SNMP qui utilise la fonction DPI (Distributed Program Interface). Il s'agit d'une interface entre un agent SNMP et les sous-agents de ce dernier. Windows utilise l'agent d'extension Windows en tant qu'interface entre un agent SNMP et les sous-agents de ce dernier.
Les systèmes AIX fournissent un agent SNMP qui utilise le protocole SNMP Multiplexer (SMUX) et fournissent DPID2, qui est un exécutable supplémentaire fonctionnant comme traducteur entre DPI et SMUX.
Pour les systèmes HP-UX, vous devez obtenir un agent SNMP fonctionnant avec SMUX car HP-UX n'en fournit pas. Load Balancer fournit DPID2 pour les systèmes HP-UX.
Les systèmes Linux fournissent un agent SNMP qui utilise SMUX. La plupart des versions Linux (Red Hat, par exemple) sont livrées avec un package UCD SNMP. UCD SNMP version 4.1 ou ultérieure dispose d'agents SMUX actifs. Load Balancer fournit DPID2 pour les systèmes Linux.
Pour les systèmes Solaris, vous devez obtenir un agent SNMP fonctionnant avec SMUX car Solaris n'en fournit pas. Load Balancer fournit DPID2 pour les systèmes Solaris dans le répertoire /opt/ibm/edge/lb/servers/samples/SNMP.
L'agent DPI doit fonctionner comme un utilisateur root. Avant d'exécuter le démon DPID2, mettez à jour les fichiers /etc/snmpd.peers et /etc/snmpd.conf comme suit :
Pour les systèmes AIX et Solaris :
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "mot_de_passe_dpid"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 mot_de_passe_dpid #dpid
Pour les systèmes Linux :
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "mot_de_passe_dpid"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 mot_de_passe_dpidVous devez également associer un commentaire à toutes les lignes du fichier snmpd.conf qui commencent pas les mots suivants : com2sec, group, view ou access.
Pour installer le support SNMP de HP-UX, procédez comme suit :
Pour utiliser Load Balancer SNMP avec SuSE Linux, procédez comme suit :
Régénérez snmpd (s'il s'exécute déjà) de sorte qu'il relise le fichier snmpd.conf :
refresh -s snmpd
Démarrez l'homologue DPID SMUX :
dpid2
Les démons doivent être lancés dans l'ordre suivant :
Pour installer le support SNMP de Solaris, procédez aux opérations ci-dessous.
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Sur le site Web http://sunfreeware.com/, les noms portent l'extension .gz, aussi ne leur appliquez pas la commande de décompression gunzip ou untar. Utilisez plutôt la commande pkgadd NomModule.
Pour installer le support SNMP de Windows, procédez comme suit :
L'exécuteur étant en cours de fonctionnement, lancez la commande dscontrol subagent start [nom_communauté] pour définir le nom de communauté utilisé entre l'agent d'extension Windows et l'agent SNMP.
IMPORTANT : Sous Windows 2003, par défaut SNMP ne répond à aucun nom de communauté présenté. Dans ce cas, le sous-agent SNMP ne répond à aucune demande SNMP. Pour vous assurez que le sous-agent SNMP réponde au nom de communauté, vous devez affecter aux propriétés du service SNMP le nom de communauté et les hôtes de destination appropriés. Configurez les propriétés de la sécurité SNMP de la manière suivante :
SNMP communique en envoyant et en recevant des interruptions, messages envoyés par des périphériques gérés afin de signaler des conditions d'erreur ou la survenue d'événements importants, par exemple, le dépassement d'un seuil.
Le sous-agent utilise les interruptions suivantes :
L'interruption indHighAvailStatus annonce que la valeur de la variable (hasState) correspondant à l'état de la haute disponibilité a changé. Les valeurs possibles de hasState sont :
L'interruption indSrvrGoneDown annonce que la pondération du serveur spécifié par les segments csID (ID cluster), psNum (numéro port) et ssID (ID serveur) de l'identificateur d'objet est passée à zéro. Le dernier nombre total de connexions actives du serveur est envoyé avec l'interruption. Cette interruption indique que, pour le répartiteur, le serveur spécifié a été arrêté."
L'interruption indDOSAttack indique que numhalfopen (nombre de connexions partielles constituées uniquement de paquets SYN) a dépassé le seuil maxhhalfopen pour le port précisé par les segments csID (ID de cluster) et psNum (numéro de port) de l'identificateur d'objet. Le nombre de serveurs configurés sur le port est transmis dans l'interruption. Cette interruption indique que Load Balancer peut faire l'objet d'une attaque de refus de service.
L'interruption indDOSAttackDone indique que numhalfopen (nombre de connexions partielles constituées uniquement de paquets SYN) est en deçà du seuil maxhalfopen pour le port précisé par les segments csID et psNum de l'identificateur d'objet. Le nombre de serveurs configurés sur le port est transmis dans l'interruption. Lorsque Load Balancer détermine que l'attaque de refus de service est terminée, cette interruption est envoyée après l'interruption indDOSAttack.
Pour les systèmes d'exploitation AIX, HP-UX, Linux et Solaris, en raison d'une restriction au niveau de l'interface API SMUX, il se peut que l'ID entreprise signalé dans des interruptions provenant du sous-agent ibmNetDispatcher corresponde à l'ID entreprise de dpid2 et non à celui d'ibmNetDispatcher, 1.3.6.1.4.1.2.6.144. Cependant, les utilitaires de gestion SNMP peuvent déterminer la source de l'interruption car les données contiennent un ID objet provenant du MIB ibmNetDispatcher.
Le support SNMP est activé à l'aide de la commande dscontrol subagent start. Il est désactivé à l'aide de la commande dscontrol subagent stop.
Pour plus d'informations sur la commande dscontrol, voir dscontrol subagent — Configuration du sous-agent SNMP.
Le pare-feu ipchains est intégré au noyau Linux. Lors de l'exécution simultanée de Load Balancer et de ipchains, Load Balancer voit le paquets avant ipchains. Vous pouvez ainsi utiliser ipchains pour renforcer un système Load Balancer Linux, tel qu'un système Load Balancer permettant de charger des pare-feux d'équilibrage de charge.
Lorsque ipchains ou iptables est configuré pour une utilisation restreinte (aucun trafic entrant ou sortant autorisé), la partie dédiée à l'acheminement des paquets de Load Balancer continue de fonctionner normalement.
Notez que ipchains et iptables ne permettent pas le filtrage du trafic entrant avant l'équilibrage de la charge.
Le fonctionnement correct de l'ensemble de Load Balancer nécessite l'autorisation de trafic supplémentaire. Voici quelques exemples de communication :
En règle générale, la stratégie ipchains adaptée aux systèmes Load Balancer consiste à refuser tout type de trafic, sauf celui à destination et provenant des serveurs dorsaux, du Load Balancer haute disponibilité partenaire, des cibles à atteindre ou des hôtes de configuration.
N'activez pas iptables lorsque Load Balancer s'exécute avec le noyau Linux version 2.4.10.x. En effet, l'activation sous cette version de noyau Linux peut provoquer à terme une dégradation des performances.
Pour désactiver iptables, listez les modules (lsmod) pour savoir lesquels utilisent ip_tables et ip_conntrack, puis supprimez ceux-ci à l'aide des commandes rmmod ip_tables et rmmod ip_conntrack. Lorsque vous réamorcez la machine, ces modules sont de nouveau ajoutés de sorte que vous devez répéter cette procédure après chaque réamorçage.
Pour plus d'informations, voir Incident : Les iptables Linux peuvent interférer avec le routage de paquets.
La présente section explique comment utiliser le composant CBR de Load Balancer.
CBR et Caching Proxy gèrent conjointement les demandes HTTP et HTTPS (SSL) via l'interface API du plug-in de Caching Proxy. Caching Proxy doit être en cours d'exécution sur la même machine pour que CBR puisse commencer à effectuer l'équilibrage de charge des serveurs. Configurez CBR et Caching Proxy en respectant les instructions de la section Exemple de configuration CBR.
Après avoir lancé CBR, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux utilisés par CBR sont similaire à ceux de Dispatcher. Pour plus d'informations, voir Utilisation des journaux Load Balancer.
Dans les versions précédentes, pour CBR, il était possible de modifier le chemin d'accès au répertoire log dans le fichier de configuration Caching Proxy. Vous pouvez maintenant changer le chemin du répertoire dans lequel le journal est stocké dans le fichier cbrserver. Pour plus de détails, voir Modification des chemins des fichiers journaux.
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, voir Utilisation des journaux Load Balancer.
Après avoir lancé Cisco CSS Controller, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux employés par Cisco CSS Controller sont similaires à ceux utilisés dans Dispatcher. Pour plus d'information, voir Utilisation des journaux Load Balancer.
Une fois Nortel Alteon Controller démarré, vous pouvez le contrôler en utilisant une des méthodes suivantes :
Les journaux employés de Nortel Alteon Controller sont similaires à ceux de Dispatcher. Pour plus d'information, voir Utilisation des journaux Load Balancer.
Metric Server fournit à Load Balancer des informations relatives à la charge des serveurs. Il réside sur chaque serveur soumis à l'équilibrage de charge.
Systèmes Linux et UNIX :
Systèmes Windows :
Cliquez sur Démarrer > > Panneau de configuration > Outils d'administration > Services. Cliquez à l'aide du bouton droit de la souris sur IBM Metric Server, puis sélectionnez Démarrer. Pour arrêter le service, suivez la même procédure en sélectionnant Arrêter.
Modifiez le niveau de consignation dans le script de démarrage de Metric Server. Vous pouvez indiquer un niveau de consignation compris entre 0 et 5, à l'instar de la plage admise pour les journaux de Load Balancer. Cette action génère un journal des agents dans le répertoire ...ms/logs.