Exploitation et gestion de Load Balancer

Remarque :
Lors de la lecture de ce chapitre, dans les sections générales qui ne concernent pas particulièrement un composant, si vous n'utilisez pas le composant Dispatcher, remplacez "dscontrol" et "dsserver" par les éléments suivants :

Le présent chapitre explique comment exploiter et gérer Load Balancer et inclut les sections suivantes :

Administration à distance de Load Balancer

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.

RMI (Remote Method Invocation)

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.

Remarque :
En raison des modifications apportées aux packages de sécurité de la versionJava, les clés Load Balancer générées pour les éditions antérieures à 5.1.1 risquent de ne pas être compatibles avec celles de l'édition actuelle ; vous devez donc régénérer vos clés lorsque vous installez une nouvelle édition.

Administration basée sur le Web

Conditions requises

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 :

Configuration de Caching Proxy

Exécution et accès à l'administration basée sur le Web

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

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 :

  1. Sélectionnez le noeud Hôte dans l'arborescence de l'interface graphique.
  2. Sélectionnez Envoyer la commande... dans le menu en incrustation Hôte.
  3. Dans la zone d'entrée de commande, entrez la commande à exécuter. Par exemple : executor report. Les résultats et l'historique des commandes exécutées lors de la session courante s'affichent dans la fenêtre ouverte.

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 :

Utilisation des journaux Load Balancer

Pour Dispatcher, CBR et Site Selector

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é.

Remarque :
De plus, pour le composant Dispatcher uniquement, les entrées peuvent être ajoutées dans un journal de sous-agent (SNMP).
Remarque :
Le composant Content Based Routing (CBR) n'est pas disponible sur les plateformes qui exécutent la machine virtuelle Java 64 bits, à l'exception de HP-UX ia64. Sous HP-UX ia64, le composant CBR exécute une application de 32 bits. Vous pouvez utiliser la méthode de réacheminement CBR du composant Load Balancer's Dispatcher afin de fournir un routage basé sur le contenu sans l'utilisation de Caching Proxy. Pour plus de détails, voir Fonction CBR de Dispatcher (méthode d'acheminement cbr).

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é.

Modification des chemins des fichiers journaux

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).

Consignation binaire

Remarque :
La fonction de consignation binaire ne s'applique pas au composant Site Selector.

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.

Pour Cisco CSS Controller et Nortel Alteon Controller

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é.

Journaux des contrôleurs

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

Modification des chemins des fichiers journaux

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).

Consignation binaire

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.

Utilisation du composant Dispatcher

La présente section explique comment utiliser et gérer le composant Dispatcher.

Démarrage et arrêt de Dispatcher

Utilisation de la valeur du délai d'attente

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.

Contrôle du nettoyage des enregistrements de connexions à l'aide des paramètres fintimeout et staletimeout

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.

Interface graphique — option de menu Contrôler

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).

Utilisation du protocole SNMP (Simple Network Management Protocol, protocole simplifié de gestion de réseau) avec le composant Dispatcher

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.

Remarque :
Les données MIB, ibmNetDispatcherMIB.02, ne seront pas chargées à l'aide du programme xnmloadmib2 de Tivoli NetView. Pour résoudre ce problème, mettez en commentaire la section NOTIFICATION-GROUP des données MIB. En d'autres termes, insérez "- -" au début de la ligne "indMibNotifications Group NOTIFICATION-GROUP" et au début des 6 lignes suivantes.

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.

Commandes et protocole SNMP

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.

Activation de SNMP sur les systèmes AIX, HP-UX, Linux et Solaris

Figure 37. Commandes SNMP pour les systèmes d'exploitation AIX, HP-UX, Linux et Solaris
Commandes SNMP et système serveur pour les AIX, HP-UX, Linux et Solaris

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.

Remarque :
Pour les systèmes SuSE Linux, vous devez obtenir un agent SNMP configuré pour prendre en charge SMUX car SuSE n'en fournit pas.

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 :

Pour les systèmes Linux :

Activation de SNMP sur les systèmes HP-UX

Pour installer le support SNMP de HP-UX, procédez comme suit :

  1. Si aucune version de GNU SED n'est installée, procurez-la vous à partir du site Web suivant : http://www.hp.com.
  2. Récupérez le fichier ucd-snmp-4.2.4.tar.gz de la page Web suivante : http://sourceforge.net/project/showfiles.php?group_id=12694.
  3. Vérifiez que "gcc" et "gmake ou make" sont installés sur votre machine. Si ce n'est pas le cas, installez-les.
  4. Décompressez le fichier ucd-snmp-4.2.4.tar.gz ainsi que tous les fichiers source du répertoire.
  5. Allez dans le répertoire où se trouvent les fichiers source, puis exécutez les commandes suivantes :
    1. run ./configure --with-mib-modules=smux
    2. make
    3. Exécutez les deux commandes suivantes en tant que superutilisateur :
      1. umask 022
      2. make install
    4. export SNMPCONFPATH=/etc/snmp
    5. start /usr/local/sbin/snmpd -s (Démarre l'agent SNMP)
    6. start dpid2 (Démarre le convertisseur DPI)
    7. dscontrol subagent start (Démarre le sous-agent Dispatcher)

Activation de SNMP sur les systèmes SuSE Linux

Pour utiliser Load Balancer SNMP avec SuSE Linux, procédez comme suit :

  1. Supprimez le module ucd-snmp rpm installé du système SuSE.
  2. Extrayez ucd-snmp-4.2.4.tar.gz de http://sourceforge.net/project/showfiles.php?group_id=12694.
  3. Vérifiez que "gcc" et "gmake ou make" sont installés sur le système SuSE (s'ils ne sont pas installés, effectuez l'opération).
  4. Décompressez le fichier ucd-snmp-4.2.4.tar.gz ainsi que tous les fichiers source du répertoire.
  5. Allez dans le répertoire où se trouvent les fichiers source, puis exécutez les commandes suivantes :
    1. run ./configure ––with–mib–modules=smux
    2. make
    3. Exécutez les deux commandes suivantes en tant que superutilisateur :
      1. umask 022 #
      2. make install
    4. export SNMPCONFPATH=/etc/snmp
    5. start /usr/local/sbin/snmpd –s
    6. start dpid2

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 :

  1. Agent SNMP
  2. Programme de traduction DPI
  3. Sous-agent Dispatcher

Activation de SNMP sur les systèmes Solaris

Pour installer le support SNMP de Solaris, procédez aux opérations ci-dessous.

  1. Tuez le démon SNMP de Solaris qui s'exécute (snmpdx et snmpXdmid).
  2. Renommez les fichiers comme suit :
  3. Téléchargez les modules suivants à partir de http://www.sunfreeware.com/ :
  4. Installez les modules téléchargés à l'aide de la commande pkgadd.
  5. Téléchargez ucd-snmp-4.2.3-solaris8.tar.gz à partir de http://sourceforge.net/project/showfiles.php?group_id=12694
  6. Décompressez ucd-snmp-4.2.3-solaris8.tar.gz (avec gunzip ou untar) sur le répertoire racine (/)
  7. Exécutez les commandes suivantes :
  8. S'il n'existe pas, créez /etc/snmpd.peers. Insérez dans snmpd.peers les éléments suivants :
    "dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2     "dpid_password"
  9. S'il n'existe pas, créez /etc/snmp/snmpd.conf. Insérez dans snmpd.conf les éléments suivants :
    smuxpeer        1.3.6.1.4.1.2.3.1.2.2.1.1.2     dpid_password
  10. Démarrez /usr/local/sbin/snmpd.
  11. Démarrez /usr/local/sbin/dpid2.
Remarques :
  1. Les modules suivants sont au format de module.

    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.

  2. Lorsque vous ajoutez smuxpeer à /etc/snmp/snmpd.conf, assurez-vous qu'aucun espace n'est entré dans la chaîne mot_de_passe_dpid.
  3. La fonction SNMP de Load Balancer est testée avec ucd-snmp version 4.2.3 et prise en charge de smux. Les futures éditions de ucd-snmp avec smux devraient fonctionner avec une configuration similaire.

Activation de SNMP sous Windows

Pour installer le support SNMP de Windows, procédez comme suit :

  1. Cliquez sur Démarrer > Panneau de configuration > Ajout/Suppression de programmes.
  2. Cliquez sur Ajouter/Supprimer des composants Windows.
  3. Dans l'assistant Composants de Windows, cliquez sur Outils de gestion et d'analyse (sans activer ou désactiver la case à cocher correspondante), puis cliquez sur Détails
  4. Cochez la case SNMP (Protocole simplifié de gestion de réseau), puis cliquez sur OK.
  5. Cliquez sur Suivant.

Définition d'un nom de communauté pour SNMP

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 :

  1. Ouvrez Gestion de l'ordinateur
  2. Dans l'arborescence de la console, cliquez sur Services
  3. Dans la sous-fenêtre des détails, cliquez sur Service SNMP
  4. Dans le menu d'action, cliquez sur Propriétés
  5. Dans la page Sécurité, sous les noms de communauté acceptés, cliquez sur Ajouter
  6. Sous Droits de communauté, sélectionnez le niveau d'autorisation de cet hôte pour le traitement des demandes à partir de la communauté sélectionnée (droit de lecture au minimum)
  7. Dans la zone Nom de la communauté, entrez le nom fourni au sous-agent Load Balancer, en respectant la casse (nom de communauté par défaut : public), puis cliquez sur Ajouter
  8. Spécifiez si les paquets d'un hôte SNMP doivent être acceptés. Choisissez l'une des options suivantes :
  9. Redémarrez le service SNMP pour que la modification soit appliquée

Interruptions

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 :

-idle
cette machine effectue un équilibrage de charge et n'essaie pas d'établir un contact avec son répartiteur associé.
-listen
La haute disponibilité vient de démarrer et Dispatcher est à l'écoute de son partenaire.
-active
cette machine effectue l'équilibrage de charge.
-standby
cette machine contrôle la machine active.
-preempt
cette machine est dans un état transitoire pendant le passage de la machine principale à la machine de secours.
-elect
Le répartiteur choisit, avec son partenaire, la machine principale et la machine de secours.
-no_exec
L'exécuteur n'est pas lancé.

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.

Activation et désactivation du support SNMP à partir de la commande dscontrol

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.

Rejet de l'ensemble du trafic vers Load Balancer avec la fonction ipchains ou iptables (systèmes Linux)

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.

Utilisation du composant CBR (Content Based Routing)

La présente section explique comment utiliser le composant CBR de Load Balancer.

Remarque :
Le composant Content Based Routing (CBR) n'est pas disponible sur les plateformes qui exécutent la machine virtuelle Java 64 bits, à l'exception de HP-UX ia64. Sous HP-UX ia64, le composant CBR exécute une application de 32 bits. Vous pouvez utiliser la méthode de réacheminement CBR du composant Load Balancer's Dispatcher afin de fournir un routage basé sur le contenu sans l'utilisation de Caching Proxy. Pour plus de détails, voir Fonction CBR de Dispatcher (méthode d'acheminement cbr).

Démarrage et arrêt de CBR

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.

Contrôle de CBR

Après avoir lancé CBR, vous pouvez le contrôler en utilisant une des méthodes suivantes :

Utilisation des journaux de CBR

Les journaux utilisés par CBR sont similaire à ceux de Dispatcher. Pour plus d'informations, voir Utilisation des journaux Load Balancer.

Remarque :

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.

Utilisation du composant Site Selector

Démarrage et arrêt de Site Selector

Contrôle de Site Selector

Après avoir lancé Site Selector, vous pouvez le contrôler en utilisant une des méthodes suivantes :

Utilisation des journaux Site Selector

Les journaux employés par Site Selector sont similaires à ceux utilisés dans Dispatcher. Pour plus d'information, voir Utilisation des journaux Load Balancer.

Utilisation du composant Cisco CSS Controller

Démarrage et arrêt de Cisco CSS Controller

  1. A partir d'une ligne de commande, entrez ccoserver pour lancer Cisco CSS Controller.
  2. A partir d'une ligne de commande, entrez ccoserver stop pour arrêter Cisco CSS Controller.

Contrôle de Cisco CSS Controller

Après avoir lancé Cisco CSS Controller, vous pouvez le contrôler en utilisant une des méthodes suivantes :

Utilisation des journaux Cisco CSS Controller

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.

Utilisation du composant Nortel Alteon Controller

Démarrage et arrêt de Nortel Alteon Controller

  1. A partir d'une ligne de commande, entrez nalserver pour démarrer Nortel Alteon Controller.
  2. A partir d'une ligne de commande, entrez nalserver stop pour arrêter Nortel Alteon Controller.

Contrôle de Nortel Alteon Controller

Une fois Nortel Alteon Controller démarré, vous pouvez le contrôler en utilisant une des méthodes suivantes :

Utilisation des journaux Nortel Alteon Controller

Les journaux employés de Nortel Alteon Controller sont similaires à ceux de Dispatcher. Pour plus d'information, voir Utilisation des journaux Load Balancer.

Utilisation du composant Metric Server

Démarrage et arrêt de Metric Server

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.

Utilisation des journaux Metric Server

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.