Identification et résolution des incidents liés à Dispatcher

Utilisez les informations fournies pour résoudre les incidents liés à Content Based Routing.

Utilisez le tableau pour afficher une description complète et une solution possible de l'incident auquel vous êtes confronté.
Tableau 1. Tableau d'identification et de résolution des incidents de Load Balancer
Symptôme Cause possible
Dispatcher ne fonctionne pas correctement Conflit de numéros de port
Absence de prise en charge des connexions des machines client ou dépassement de délai des connexions
  • Mauvaise configuration de réacheminement
  • Le serveur n'a pas d'unité de bouclage ayant un alias pour l'adresse de cluster
  • Le chemin supplémentaire n'est pas supprimé
  • Le port n'est pas défini pour chaque cluster
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
La commande dscontrol ou lbadmin n'a pas abouti, le message 'Le serveur ne répond pas' ou 'Impossible d'accéder au serveur RMI' s'affiche
  1. Echec des commandes en raison d'une pile mise sur "sock". Ou les commandes n'ont pas abouti car dsserver n'a pas été lancé.
  2. La définition des ports RMI est incorrecte.
  3. Un hôte local est incorrect dans le fichier hôte
Les conseillers ne fonctionnent pas correctement Les conseillers ne fonctionnent pas
Le message Fichier introuvable... s'affiche lors de l'utilisation de Netscape comme navigateur par défaut pour afficher l'aide en ligne (plateforme Windows) Paramétrage incorrect pour l'association de fichier HTML
L'interface graphique ne démarre pas correctement Espace de pagination insuffisant
L'interface utilisateur graphique ne s'affiche pas correctement. La résolution est incorrecte.
Les panneaux d'aide apparaissent parfois sous d'autres fenêtres Limitation Java™
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
L'interface coréenne de Load Balancer affiche sous AIX et Linux des polices indésirables ou qui se chevauchent. Vous devez modifier les polices de caractères par défaut
Comportement inattendu de l'interface graphique lors de l'utilisation de Windows avec une carte vidéo Matrox AGP Incident lors de l'utilisation de cartes Matrox AGP en cours d'exécution de l'interface graphique de Load Balancer
Temps de réponse important lors de l'exécution de commandes sur la machine Dispatcher Un temps de réponse important peut être dû à une surcharge de la machine liée à un volume élevé de trafic client
Le conseiller SSL ou HTTPS n'enregistre pas les charges des serveurs Incident lié au fait que l'application serveur SSL n'est pas configurée avec l'adresse IP du cluster
Sous Windows, des caractères nationaux Latin-1 altérés apparaissent sur la ligne de commande Modifiez les propriétés des polices de la fenêtre d'invite de commande
Sur la plateforme Windows, les conseillers et les cibles à contacter marquent tous les serveurs comme étant arrêtés Le déchargement des tâches n'est pas désactivé ou il doit activer ICMP.
Sur la plateforme Windows, les conseillers ne fonctionnent pas dans une configuration en haute disponibilité après une panne réseau Lorsque le système détecte une panne réseau, il efface sa mémoire cache ARP (Address Resolution Protocol)
Sur les systèmes Linux, la commande "IP address add" et plusieurs alias de bouclage de cluster sont incompatibles Lorsque vous attribuez des alias à plusieurs adresses sur l'unité de bouclage, vous devez utiliser la commande ifconfig et non la commande ip address add
Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de session de terminal à partir de laquelle ils ont été lancés Utilisez la commande nohup afin que les processus lancés ne reçoivent pas un signal d'arrêt lorsque vous quittez la session de terminal.
Un ralentissement se produit lors du chargement des configurations Load Balancer Ce délai peut provenir des appels DNS effectués pour résoudre et vérifier l'adresse du serveur.
Sur les systèmes Windows, un message d'erreur s'affiche pour indiquer qu'il existe un conflit d'adresses IP avec un autre système du réseau Si la fonction de haute disponibilité est configurée, il est possible que des adresses de cluster soient définies sur les deux systèmes pendant une courte période et qu'elles génèrent ce message d'erreur.
Sur les systèmes Windows, l'erreur "Le serveur ne répond pas" se produit lors de l'exécution de la commande dscontrol ou lbadmin Lorsqu'il existe plusieurs adresses IP sur un système Windows et que le fichier hôte ne spécifie pas l'adresse à associer au nom d'hôte.
Limitations de la configuration de l'acheminement MAC pour Dispatcher avec les plateformes zSeries et S/390 Sous Linux, il existe des limitations lorsque vous utilisez des serveurs zSeries ou S/390 dotés de cartes OSA (Open System Adapter). Des solutions alternatives sont fournies.
Sur les systèmes Linux, les iptables peuvent interférer avec le routage des paquets. Les iptables Linux peuvent interférer avec l'équilibrage de charge du trafic et doivent être désactivées sur la machine Load Balancer.
Sous Solaris, lorsque vous tentez de configurer un serveur IPv6 sur la machine Dispatcher, le message Impossible d'ajouter le serveur s'affiche Cette erreur peut provenir de la gestion de la requête ping sur une adresse IPv6 par le système d'exploitation Solaris.
Mise à niveau de l'ensemble de fichiers Java fourni avec les installations Load Balancer En cas d'incident au niveau de l'ensemble de fichiers Java, contactez le service d'assistance IBM® pour recevoir une mise à niveau de l'ensemble de fichiers Java qui a été fourni avec l'installation Load Balancer.
Les demandes du client échouent lors du transfert vers des serveurs dorsaux HP-UX Suite à la configuration de Load Balancer pour IPv6 sous HP-UX, les demandes du clients adressées au cluster échouent. Cette erreur est le résultat de l'interaction entre la fonction de reconnaissance dans le voisinage pour le système d'exploitation et Load Balancer.
Load Balancer pour IPv4 et IPv6 entre en conflit avec la sécurité IP (IPsec)

Si vous utilisez Load Balancer et que la sécurité IP (IPsec) est activée, les paquets de sortie peuvent être incorrects et les informations de configuration du Dispatcher peuvent ne pas s'afficher correctement dans l'interface de ligne de commande et la console d'administration de WebSphere Application Server.

Load Balancer signale qu'il transfère les connexions, mais que les clients ne reçoivent pas les réponses.

Le script serverUp risque de s'exécuter lors de l'émission des commandes de Load Balancer ayant un impact sur l'état des serveurs Des problèmes peuvent apparaître si vous exécutez une commande ayant un impact sur l'état d'un serveur, tel que dscontrol manager unquiesce et dscontrol manager quiesce, après qu'un cycle du gestionnaire a déjà extrait les pondérations des serveurs. L'exécution de ces commandes peut écraser les valeurs sauvegardées lors du cycle de gestionnaire et provoquer l'exécution impromptue du script serverUp.

Dispatcher ne fonctionne pas correctement

Cet incident peut se produire lorsqu'une autre application utilise l'un des ports utilisés par Load Balancer. Pour plus d'informations, consultez la rubrique Configuration de la machine Load Balancer.

Les requêtes de Load Balancer ne sont pas équilibrées

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 :
  1. Avez-vous configuré l'adresse de non-réacheminement, les clusters, les ports et les serveurs pour l'acheminement ? Vérifiez le fichier de configuration.
  2. L'alias de l'unité de bouclage de chaque serveur est-il associé à l'adresse de cluster ?

    [AIX][HP-UX][Linux][Solaris] Utilisez netstat -ni pour vérifier.

  3. La voie d'acheminement supplémentaire est-elle supprimée ?

    [AIX][HP-UX][Linux][Solaris] Utilisez netstat -nr pour vérifier.

  4. Utilisez la commande dscontrol cluster status pour vérifier les informations relatives à chacun des clusters que vous avez définis. Assurez-vous qu'un port est défini pour chaque cluster.
  5. Utilisez la commande dscontrol server report :: pour vérifier que vos serveurs ne sont pas hors service ou qu'ils n'ont pas pour valeur une pondération égale à zéro.
[Windows]

Dispatcher, Microsoft IIS et SSL ne fonctionnent pas (plateforme Windows)

Lorsque vous utilisez Dispatcher, Microsoft IIS et SSL, s'ils ne fonctionnent pas ensemble, il se peut qu'un incident lié à la sécurité SSL se soit produit. Pour plus d'informations sur la génération d'une paire de clés, l'acquisition d'un certificat, l'installation d'un certificat avec une paire de clés et la configuration d'un répertoire pour SSL, reportez-vous à la documentation Microsoft Information and Peer Web Services.

[Solaris]

échec de la commande dscontrol ou lbadmin

  1. La commande dscontrol renvoie : Erreur : Pas de réponse du serveur. Sinon, la commande lbadmin renvoie : Erreur : impossible d'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 javaw
  2. Les consoles d'administration des interfaces Load Balancer (ligne de commande, interface graphique et assistants) communiquent avec dsserver par appels RMI (remote method invocation). Par défaut, la communication utilise trois ports : chacun étant défini dans le script de démarrage de dsserver :
    • 10099 pour recevoir des commandes de dscontrol
    • 10004 pour envoyer des demandes de mesure au système Metric Server
    • 10199 pour le port du serveur RMI

    Ceci peut être source de problèmes lorsqu'une des consoles d'administration s'exécute sur la même machine qu'un pare-feu ou passe par un pare-feu. Par exemple, lorsque Load Balancer s'exécute sur la même machine qu'un pare-feu alors que vous exécutez des commandes dscontrol, des erreurs de type Erreur : aucune réponse du serveur peuvent s'afficher.

    Pour éviter ce type d'incident, modifiez le fichier script ndserver afin de définir le port qu'utilise RMI pour le pare-feu (ou autre application). Remplacez la ligne LB_RMISERVERPORT=10199 par LB_RMISERVERPORT=votrePort. Où votrePort est un autre port.

    Lorsque vous avez terminé, relancez la commande dsserver et ouvrez le trafic des ports 10099, 10004, 10199 et 10100 ou du port d'adresse hôte choisi pour l'exécution de la console d'administration.

  3. Ces erreurs peuvent également se produire si vous n'avez pas encore lancé dsserver.
  4. S'il existe plusieurs adaptateurs sur la machine, vous devez désigner celui à utiliser par dsserver en ajoutant la ligne suivante dans le script dsserver :java.rmi.server.hostname=<nom_hôte ou adresseIP>

    Par exemple : java -Djava.rmi.server.hostname="10.1.1.1"

Les conseillers ne fonctionnent pas correctement

Une commande ping ICMP est envoyée aux serveurs avant la demande du conseiller. S'il existe un pare-feu entre Load Balancer et les serveurs, vérifiez qu'il autorise les commandes ping. Si cette configuration pose un problème de sécurité pour votre réseau, modifiez l'instruction java dans dsserver pour désactiver toutes les commandes ping vers les serveurs en ajoutant la propriété java suivante :
LB_ADV_NO_PING="true"      
java  -DLB_ADV_NO_PING="true"
[Windows]

“Impossible de trouver le fichier..." lors de la tentative de visualisation de l'aide en ligne (plateforme Windows)

Sur les plateformes Windows, lorsque vous utilisez Netscape comme navigateur par défaut, le message d'erreur suivant peut s'afficher : “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 :
  1. Cliquez sur Poste de travail, puis sur Outils, sélectionnez Options des dossiers et cliquez sur l'onglet Types de fichiers
  2. Voir Document hypertexte Netscape
  3. Cliquez sur le bouton Avancé, sélectionnez ouvrir, cliquez sur le bouton Editer
  4. Entrez NSShell dans la zone Application (et non dans la zone Application utilisée pour réaliser l'action) et cliquez sur OK

L'interface graphique ne démarre pas correctement

Pour que l'interface graphique lbadmin fonctionne correctement, vous devez disposer d'une quantité d'espace de pagination suffisante. Dans le cas contraire, l'interface graphique peut ne pas démarrer complètement. Si cela se produit, vérifiez l'espace de pagination et augmentez-la si nécessaire.

L'interface graphique ne s'affiche pas correctement

Si des incidents relatifs à l'apparence de l'interface graphique de Load Balancer se produisent, vérifiez la configuration de la résolution du bureau du système d'exploitation. Pour un affichage de l'interface graphique optimal, nous vous recommandons d'utiliser une résolution de 1024x768 pixels.

[Windows]

Sur la plateforme Windows, les fenêtres d'aide disparaissent parfois sous d'autres fenêtres ouvertes.

Sur la plateforme Windows, lorsque vous ouvrez des fenêtres d'aide, elles peuvent disparaître sous les fenêtres existantes. Si cela se produit, cliquez sur la fenêtre pour qu'elle s'affiche à nouveau en premier plan.

Arrêt (ou comportement imprévu) de l'interface graphique lors du chargement d'un fichier de configuration volumineux.

Lors de l'utilisation d'une administration lbadmin ou Web (lbwebaccess) pour charger un fichier de configuration volumineux (200 commandes add ou même plus), l'interface graphique peut s'arrêter ou avoir un comportement imprévu, comme présenter un temps de réponse excessif lorsque vous apportez des modifications à l'écran.

Cela vient du fait que la mémoire est insuffisante pour permettre à Java de traiter une configuration de cette ampleur.

L'environnement d'exécution dispose d'une option qui permet d'augmenter le pool d'allocation de mémoire disponible pour Java.

Il s'agit de l'option -Xmxnn correspond à la taille maximale, en octets, de la mémoire. n doit être un multiple de 1024 et supérieur à 2 Mo. La valeur n peut être suivie du caractère k ou K pour indiquer qu'il s'agit de kilo-octets ou du caractère m ou M pour indiquer qu'il s'agit de méga-octets. Par exemple, -Xmx128M et -Xmx81920k sont valides. La valeur par défaut est 64M. Solaris 8 accepte une valeur maximale de 4000M.

Par exemple, pour ajouter cette option, ouvrez le fichier script lbadmin, modifiez "javaw" to "javaw -Xmxn" comme suit. Pour les systèmes AIX, remplacez "java" par "java -Xmxn".
  • [AIX] Systèmes AIX
    java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS 
    com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
  • [HP-UX] Systèmes HP-UX
    java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS 
    com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
  • [Linux] Systèmes Linux
    javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS 
    com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
  • [Solaris] Systèmes Solaris
    java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS 
    com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
  • [Windows] Systèmes Windows
    START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH%
     %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main

Aucune valeur n particulière n'est recommandée, mais elle doit être supérieure à l'option par défaut. Pour commencer, vous pouvez doubler cette dernière.

L'interface coréenne de Load Balancer affiche sous AIX et Linux des polices indésirables ou qui se chevauchent.

Pour rectifier les problèmes de chevauchement de polices ou de polices indésirables sur l'interface coréenne de Load Balancer, procédez comme suit :
  • [AIX] Sur les systèmes AIX
    1. Arrêtez tous les processus Java sur le système AIX.
    2. Ouvrez le fichier font.properties.ko dans un éditeur. Ce fichier se trouve dans home/jre/lib, où home est le répertoire local Java.
    3. Recherchez la chaîne suivante :
      -Monotype-TimesNewRomanWT-medium-r-normal
      --*-%d-75-75-*-*-ksc5601.1987-0
    4. Remplacez toutes les instances de cette chaîne par :
      -Monotype-SansMonoWT-medium-r-normal
      --*-%d-75-75-*-*-ksc5601.1987-0
    5. Enregistrez le fichier.
  • [Linux] Sur les systèmes Linux
    1. Arrêtez tous les processus Java sur le système.
    2. Ouvrez le fichier font.properties.ko dans un éditeur. Ce fichier se trouve dans home/jre/lib, où home est le répertoire local Java.
    3. Recherchez la chaîne suivante (sans espace) :
      -monotype-
      timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
    4. Remplacez toutes les instances de cette chaîne par :
      -monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
    5. Enregistrez le fichier.
[Windows]

Sur la plateforme Windows, comportement inattendu de l'interface graphique lors de l'utilisation de cartes vidéo Matrox AGP

Sur la plateforme Windows, l'interface graphique de Load Balancer peut se comporter de manière inattendue lorsque vous utilisez une carte vidéo Matrox AGP. Lorsque vous cliquez sur un bouton de la souris, un espace légèrement plus large que le pointeur de la souris peut être altéré avec inversion possible de la mise en évidence ou déplacement des images sur l'écran. Les anciennes cartes Matrox n'ont pas présenté ce type de comportement. Il n'existe pas de rectificatif pour les cartes Matrox AGP.

Temps de réponse important lors de l'exécution de commandes sur la machine Dispatcher

Si vous exécutez le composant Dispatcher pour l'équilibrage de charge, le trafic client peut surcharger l'ordinateur. Le module Load Balancer du noyau est hautement prioritaire, et s'il gère constamment des paquets de clients, il est possible que le reste du système ne réponde plus. L'exécution de commandes dans l'espace utilisateur peut être très longue ou ne jamais se terminer.

Dans ce cas, vous devez restructurer votre configuration de sorte que le trafic ne surcharge pas la machine Load Balancer. Vous pouvez également répartir la charge sur plusieurs machines Load Balancer ou remplacer votre machine par un ordinateur plus performant et plus rapide.

Lorsque vous essayez de déterminer si la longueur des temps de réponse provient d'un volume important de trafic client, vérifiez si cela se produit aux heures de pointe. Une mauvaise configuration des systèmes entraînant des boucles de routage peut provoquer le même incident. Mais avant de modifier la configuration de Load Balancer, vérifiez si les symptômes ne sont pas liés à une charge trop importante au niveau du client.

Le conseiller SSL ou HTTPS n'enregistre pas les charges des serveurs

Load Balancer envoie des paquets aux serveurs en utilisant l'adresse du cluster pour laquelle un alias a été défini sur l'unité de bouclage. Certaines applications serveurs (SSL, par exemple) exigent que les informations de configuration (les certificats, par exemple) soient définies en fonction de l'adresse IP. L'adresse IP doit être l'adresse du cluster configurée sur l'unité de bouclage de façon à correspondre au contenu des paquets entrants. Si vous ne configurez pas l'application serveur avec l'adresse IP du cluster, la demande client n'est pas correctement acheminée vers le serveur.

[Windows]

Sur les systèmes Windows, des caractères nationaux Latin-1 altérés apparaissent dans la fenêtre d'invite de commande.

Dans une fenêtre de ligne de commande du système d'exploitation Windows, certains caractères nationaux de la famille Latin-1 sont altérés. Par exemple, la lettre "a" avec tilde s'affiche sous la forme d'un symbole pi. Pour rectifier cette erreur, vous devez modifier les propriétés de police de la fenêtre d'invite de commande. Modifiez la police comme suit :
  1. Cliquez sur l'icône située dans l'angle supérieur gauche de la fenêtre d'invite de commande.
  2. Sélectionnez Propriétés, puis cliquez sur l'onglet Police.
  3. La police par défaut est Raster ; remplacez-la par Lucida Console, puis cliquez sur OK.

Sur les systèmes Windows, les conseillers et les cibles à contacter marquent tous les serveurs comme étant arrêtés

Lorsque vous configurez votre adaptateur sur une machine Load Balancer, vous devez vérifier que les deux paramètres suivants sont corrects pour que le conseiller puisse fonctionner :
  • Désactiver Task Offloading.
    • Pour désactiver Task Offloading : Cliquez sur Démarrer > Paramètres > Panneau de configuration > Connexion réseau et accès à distance, puis sélectionnez l'adaptateur.
    • Dans la fenêtre en incrustation, cliquez sur Propriétés.
    • Cliquez sur Configurer, puis sélectionnez l'onglet Paramètres avancés.
    • Dans la sous-fenêtre des propriétés, cliquez sur la propriété Task Offload, puis sélectionnez désactiver dans la zone de valeur.
  • Activez Protocole 1 (ICMP) pour les protocoles IP si vous activez le filtrage TCP/IP. Si ICMP n'est pas activé, le test de connexion (ping) au serveur dorsal échoue. Pour vérifier si ICMP est activé, procédez comme suit :
    • Cliquez sur Démarrer > Paramètres > Panneau de configuration > Connexions réseau et accès à distance, puis sélectionnez l'adaptateur.
    • Dans la fenêtre en incrustation, cliquez sur Propriétés.
    • Dans la sous-fenêtre des composants, sélectionnez Internet Protocol (TCP/IP), puis cliquez sur Propriétés.
    • Cliquez sur Paramètres avancés, puis sélectionnez l'onglet Options.
    • Sélectionnez le filtrage TCP/IP dans la sous-fenêtre des options, puis cliquez sur Propriétés.
    • Si vous avez sélectionné Activer le filtrage TCP/IP et Autoriser seulement pour les protocoles IP, vous devez ajouter Protocole IP 1. Ce protocole doit être ajouté en plus des ports TCP et UDP existants que vous avez activés.
[Windows]

Sur les systèmes Windows, les conseillers ne fonctionnent pas dans une configuration haute disponibilité après une indisponibilité du réseau.

Par défaut, lorsque le système d'exploitation Windows détecte une panne réseau, il efface sa mémoire cache ARP (protocole de résolution d'adresse) et toutes les entrées statiques. Lorsque le réseau est à nouveau disponible, la mémoire cache ARP est de nouveau alimentée par les demandes ARP envoyées sur le réseau.

Dans une configuration en haute disponibilité, les deux serveurs assurent les opérations principales lorsqu'une perte de la connectivité réseau affecte l'un d'eux. Lorsque la demande ARP est envoyée pour alimenter la mémoire cache ARP, les deux serveurs répondent et la mémoire cache ARP marque alors l'entrée comme non valide. Par conséquent, les conseillers ne peuvent pas créer de socket vers les serveurs de secours.

Vous pouvez résoudre cet incident en empêchant Windows d'effacer la mémoire cache ARP lors d'une perte de connectivité. Microsoft a publié un article expliquant comment effectuer cette tâche. Cet article se trouve sur le site Web Microsoft dans la base de connaissances Microsoft sous la référence 239924: http://support.microsoft.com/default.aspx?scid=kb;en-us;239924.

Vous trouverez ci-après un récapitulatif des étapes, décrites dans l'article Microsoft, permettant d'empêcher le système d'effacer la mémoire cache ARP.
  1. Utilisez l'éditeur de registre (regedit ou regedit32) pour ouvrir le registre.
  2. Affichez la clé suivante du registre :
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
  3. Ajoutez la valeur de registre suivante : Nom de la valeur : DisableDHCPMediaSense Type de valeur : REG_DWORD.
  4. Une fois que vous avez ajouté cette clé, éditez-la et affectez-lui la valeur 1.
  5. Réinitialisez la machine pour que la modification soit appliquée.
Avertissement : Cette opération affecte la mémoire cache ARP, quelle que soit la valeur du paramètre DHCP.
[Linux]

Sur les systèmes Linux, n'utilisez pas la commande "IP address add" lors de l'affectation d'alias à plusieurs clusters sur l'unité de bouclage.

Vous devez tenir compte de certains points concernant l'utilisation des serveurs Linux kernel 2.4.x. Si une adresse de cluster a été configurée pour le serveur sur l'unité de bouclage à l'aide de la commande ip address add , vous ne pouvez attribuez un alias qu'à une seule adresse de cluster.

Lorsque vous affectez un alias à plusieurs clusters sur l'unité de bouclage, utilisez la commande ifconfig (par exemple,
ifconfig lo:num clusterAddress netmask 255.255.255.255 up 

En outre, les méthodes de configuration d'interface ifconfig et ip sont incompatibles. La meilleure pratique consiste, pour un site, à choisir une méthode et à ne pas en changer.

[Solaris]

Sur les systèmes Solaris, les processus Load Balancer s'arrêtent lorsque vous quittez la fenêtre de terminal à partir de laquelle ils ont été lancés

Sur les systèmes Solaris, si vous démarrez les scripts Load Balancer (tels que dsserver ou lbadmin) à partir d'une fenêtre de terminal et que vous quittez cette dernière, le processus Load Balancer s'arrête.

Pour résoudre cet incident, démarrez les scripts Load Balancer à l'aide de la commande nohup. Par exemple : nohup dsserver. Cette commande permet d'éviter que les processus lancés à partir de la session de terminal ne reçoive un signal d'arrêt du terminal lorsque ce dernier est fermé. L'exécution du processus peut ainsi se poursuivre même après la fermeture de la session de terminal. Spécifiez la commande nohup avant les scripts Load Balancer dont le traitement doit continuer après la fermeture d'une session de terminal.

Délai lors du chargement d'une configuration Load Balancer

Le chargement d'une configuration Load Balancer peut prendre un certain temps en raison des appels DNS effectués pour résoudre et vérifier l'adresse du serveur.

Si le système DNS de la machine Load Balancer n'est pas correctement configuré ou s'il prend du temps, le chargement de la configuration en est ralenti à cause de l'envoi des demandes DNS sur le réseau par les processus Java.

Une solution consiste à ajouter les adresses et les noms d'hôte du serveur au fichier local /etc/hosts.

[Windows]

Sur les systèmes Windows, un message d'erreur lié à un conflit d'adresses IP apparaît à l'écran

Si la fonction de haute disponibilité est configurée, il est possible que des adresses de cluster soient définies sur les deux systèmes pendant une courte période et que le système génère l'affichage d'un message d'erreur pour indiquer un conflit d'adresses IP avec un autre système du réseau. Dans ce cas, vous pouvez ignorer ce message. Il est possible qu'une adresse de cluster soit configurée en même temps sur les deux systèmes de haute disponibilité, notamment lors du démarrage de chaque système ou lors de l'initiation d'une procédure de reprise.

[Windows]

Sur les systèmes Windows, l'erreur "Le serveur ne répond pas" se produit lors de l'exécution de la commande dscontrol ou lbadmin

Pour résoudre cet incident, remplacez le fichier c:\Windows\system32\drivers\etc\hosts par le nom d'hôte de votre machine et l'adresse IP à lui associer.

Si vous utilisez la commande dscontrol, vous pouvez indiquer l'adresse de connexion grâce à la commande suivante :
dscontrol host@@<adresse_ip ou nom_hôte> <command>
Avoid trouble Avoid trouble : ²L'adresse IP ne peut pas correspondre à une adresse de cluster.gotcha
[Linux]

Sous Linux, il existe des limitations Dispatcher lorsque vous utilisez des serveurs zSeries ou S/390 dotés de cartes OSA (Open System Adapter)

En règle générale, quelle que soit la plateforme, les serveurs présents dans la configuration de Load Balancer doivent tous se trouver sur le même segment de réseau. Les périphériques de réseau actifs comme le routeur, les passerelles et les pare-feux interfèrent avec Load Balancer. En effet, Load Balancer fonctionne comme un routeur spécialisé, modifiant uniquement les en-têtes de couche liaison de données pour son tronçon suivant et final. Toute topologie de réseau dans laquelle le tronçon suivant n'est pas final n'est pas valide pour Load Balancer.
Remarque : Les tunnels, de type CTC (canal à canal) ou IUCV (inter-user communication vehicle), sont souvent pris en charge. Toutefois, Load Balancer doit utiliser directement le tunnel jusqu'à la destination finale pour son acheminement (il ne peut pas s'agir d'un tunnel réseau à réseau).

Il existe une limitation pour les serveurs zSeries et S/390 qui partagent la carte OSA car cette dernière a un fonctionnement différent de la plupart des cartes réseau. La carte OSA possède sa propre implémentation de couche réseau, (sans aucun rapport avec Ethernet), qui est présentée aux hôtes Linux et z/OS se trouvant derrière elle. En réalité, les cartes OSA ressemblent à des hôtes Ethernet-Ethernet (et non à des hôtes OSA) et les hôtes qui l'utilisent y répondent comme s'il s'agissait d'Ethernet.

La carte OSA exécute également certaines fonctions directement relatives à la couche IP (la réponse aux demandes de protocole de résolution d'adresses, par exemple) Ou encore, la carte OSA partagée achemine les paquets IP en fonction d'une adresse IP de destination, et non d'une adresse Ethernet comme un commutateur de couche 2. En pratique, la carte OSA est un segment de réseau avec une passerelle vers elle-même.

Load Balancer s'exécutant sur un hôte S/390 Linux ou zSeries Linux peut acheminer le trafic vers des hôtes se trouvant sur la même carte OSA ou sur des hôtes Ethernet. Tous les hôtes se trouvant sur la même carte OSA partagée se trouvent effectivement sur le même segment.

Load Balancer peut effectuer un acheminement à partir d'une carte OSA partagée en raison de la nature de la passerelle OSA. Cette dernière reconnaît le port OSA qui possède l'IP de cluster. Le pont reconnaît l'adresse MAC des hôtes directement connectés au segment Ethernet. Par conséquent, Load Balancer peut effectuer un acheminement par méthode MAC sur une passerelle OSA.

Toutefois, Load Balancer ne peut pas effectuer d'acheminement vers une carte OSA partagée, notamment lorsqu'il se trouve sur une machine S/390 Linux et que le serveur dorsal se trouve sur une carte OSA différente de celle de Load Balancer. La carte OSA du serveur dorsal diffuse l'adresse MAC OSA de l'IP de serveur, mais à l'arrivée d'un paquet avec l'adresse de destination Ethernet de la carte OSA du serveur et l'IP du cluster, la carte OSA du serveur ne sait pas lequel de ses hôtes, le cas échéant, doit recevoir ce paquet. Les principes qui gouvernent l'acheminement MAC OSA-Ethernet à partir d'une carte OSA partagée ne fonctionnent pas lors des tentatives d'acheminement vers une carte OSA partagée.

Solution :

Dans les configurations de Load Balancer qui utilisent les serveurs zSeries ou S/390 dotés de cartes OSA, vous disposez de deux moyens pour remédier à l'incident décrit.
  1. Utilisation des fonctionnalités de plateforme

    Si les serveurs de la configuration Load Balancer se trouvent sur le même type de plateforme zSeries ou S/390, vous pouvez définir des connexions point à point (CTC ou IUCV) entre Load Balancer et chaque serveur. Configurez les noeuds finaux avec les adresses IP privées. La connexion point à point est réservée au trafic Load Balancer-serveur. Ajoutez ensuite les serveurs avec l'adresse IP du noeud final du serveur du tunnel. Dans cette configuration, le trafic du cluster passe par la carte OSA de Load Balancer et est acheminé via la connexion point à point, là où le serveur répond par sa propre route par défaut. La réponse utilise la carte OSA du serveur pour son émission, et il peut s'agir ou non de la même carte.

  2. Utilisation des fonctionnalités d'encapsulation de Load Balancer.

    Si les serveurs de la configuration Load Balancer ne se trouvent pas sur le même type de plateforme zSeries ou S/390, ou s'il n'est pas possible de définir une connexion point à point entre Load Balancer et chaque serveur, il est préférable d'utiliser la fonctionnalité d'encapsulation de Load Balancer, protocole permettant à Load Balancer d'effectuer un acheminement via des routeurs.

    Lors de l'utilisation de la fonction d'encapsulation, le paquet client->IP cluster est reçu par Load Balancer, encapsulé et envoyé au serveur. Au niveau du serveur, le paquet client->IP cluster d'origine est excapsulé et le serveur répond directement au client. L'avantage que présente l'utilisation de GRE est que Load Balancer visualise uniquement le trafic client-serveur, et non le trafic serveur-client. L'inconvénient est qu'elle réduit la taille de segment maximal de la connexion TCP à cause de la surcharge d'encapsulation.

    Voir la rubrique Utilisation du transfert d'encapsulation pour acheminer le trafic sur les segments de réseau pour plus d'informations sur la manière de configurer Load Balancer pour réacheminer le trafic avec l'encapsulation.

[Linux]

Les iptables Linux peuvent interférer avec le routage des paquets

Les iptables Linux peuvent interférer avec l'équilibrage de charge du trafic et doivent être désactivées sur la machine Dispatcher.

Exécutez la commande suivante pour déterminer si les iptables sont chargés :
lsmod | grep ip_tables
Le résultat de la commande précédente peut être analogue à celui présenté ci-dessous :
ip_tables         22400   3
iptable_mangle,iptable_nat,iptable_filter
Lancez la commande suivante pour chaque iptable répertorié dans la sortie afin d'afficher les règles pour les tables :
iptables -t <short_name> -L
Par exemple :
iptables -t mangle -L 
iptables -t nat    -L
iptables -t filter -L    
Si iptable_nat est chargé, il doit être déchargé. Comme iptable_nat est dépendant de iptable_conntrack, supprimez également iptable_conntrack. Pour décharger ces deux iptables, lancez la commande suivante :
rmmod iptable_nat iptable_conntrack
[Solaris]

Impossible d'ajouter un serveur IPv6 à la configuration de Load Balancer sous Solaris

Sur les systèmes Solaris, lorsque vous essayez de configurer un serveur IPv6 sur une installation Websphere Load Balancer for IPv4 and IPv6, un message indiquant qu'il est impossible d'ajouter le serveur peut s'afficher. Cette erreur peut provenir de la gestion de la requête ping sur une adresse IPv6 par le système d'exploitation Solaris.

Lors de l'ajout d'un serveur à la configuration sur un système Solaris, Load Balancer envoie une commande ping au serveur afin d'obtenir son adresse MAC. La machine Solaris peut choisir une adresse de cluster configurée comme adresse source de la requête ping au lieu d'utiliser l'adresse NFA de la machine. Si l'adresse de cluster est configurée sur l'unité de bouclage du serveur, la réponse ping n'est pas reçue sur la machine Load Balancer ; le serveur n'est alors pas ajouté dans la configuration.

La solution consiste à configurer une autre adresse IPv6 sur la machine Load Balancer avant ou après configuré l'adresse de cluster IPv6. Cette adresse doit être une adresse sans alias sur l'unité de bouclage du serveur dorsal sur lequel vous essayez d'ajouter la configuration Load Balancer. Ajoutez ensuite le serveur à la configuration Load Balancer.

Mise à niveau de l'ensemble de fichiers Java fourni avec l'installation Load Balancer

Pendant le processus d'installation de Load Balancer, un ensemble de fichiers Java est également installé. Load Balancer est la seule application utilisant la version Java qui s'installe avec le produit. Ne procédez pas tout seul à la mise à niveau de cette version de l'ensemble de fichiers Java. En cas d'incident nécessitant une mise à niveau de l'ensemble de fichiers Java, contactez le service d'assistance IBM pour recevoir une mise à niveau officielle de l'ensemble de fichiers Java qui a été fourni avec l'installation Load Balancer.

[HP-UX]

Incident : Les demandes client échouent lors de l'utilisation du réacheminement IPv6 MAC avec les serveurs dorsaux HP-UX

Suite à la configuration de Load Balancer pour IPv6 sous HP-UX, les demandes du clients adressées au cluster échouent. Cette erreur est provoquée par l'interaction entre la fonction de découverte de voisinage du système d'exploitation et Load Balancer.

Lorsqu'un serveur dorsal est ajouté à la configuration, Load Balancer tente de lancer une commande PING vers le nouveau serveur pour obtenir l'adresse MAC. Le serveur HP-UX peut choisir une adresse de cluster configurée comme adresse source de la requête PING au lieu d'utiliser l'adresse de non-réacheminement (NFA) de la machine. Dans ce cas, une nouvelle entrée est créée pour l'adresse de cluster dans la table de routage du serveur dorsal HP-UX en plus de l'entrée de bouclage local. La nouvelle entrée a une priorité de routage plus élevée que le bouclage local. Par conséquent, les demandes du client qui atteignent le serveur dorsal sont réacheminées vers le serveur Load Balancer, lequel ne répond pas.

Pour corriger cet incident, à l'issue de la configuration de Load Balancer, configurez l'alias de bouclage sur le serveur dorsal en dernier lieu. Si un alias a été attribué à l'adresse de cluster sur le bouclage lors du chargement de la configuration de Load Balancer, supprimer l'alias de bouclage du cluster sur le serveur dorsal, puis attribuez-lui un autre alias. Pour supprimer l'alias de bouclage, utilisez la commande ifconfig lo0:1 inet6 à partir de la fenêtre du terminal. Définissez un nouvel alias de bouclage.

[AIX]

Sur les systèmes AIX, Load Balancer entre en conflit avec la sécurité IP (IPsec)

Si vous utilisez Load Balancer et que la sécurité IP (IPsec) est activée, les paquets de sortie peuvent être incorrects et les informations de configuration du Dispatcher peuvent ne pas s'afficher correctement dans l'interface de ligne de commande et la console d'administration de WebSphere Application Server. Load Balancer signale qu'il transfère les connexions, mais que les clients ne reçoivent pas les réponses.

Si vous utilisez Load Balancer et la sécurité IP sur le même hôte, des incidents de communication peuvent avoir lieu entre Load Balancer et le serveur d'applications. Le composant Load Balancer n'est pas totalement compatible avec les fonctions IPsec, et transmet les données des deux côtés de la couche de sécurité. Load Balancer reçoit les paquets sous IPsec. Par conséquent, il reçoit des paquets chiffrés qu'il ne peut déchiffrer. Lors de l'envoi des données, Load Balancer les transmet au-dessus d'IPsec. Il envoie au serveur d'applications des paquets non chiffrés qui le sont par IPsec. Le serveur d'applications reçoit donc des données chiffrées qu'il ne peut pas utiliser.

Le script serverUp risque de s'exécuter lors de l'émission des commandes de Load Balancer ayant un impact sur l'état des serveurs

Les pondérations sont établies par le gestionnaire lors d'un cycle de gestionnaire. Au début de ce cycle, le gestionnaire extrait les pondérations en cours de la fonction exécuteur. Il utilise ces valeurs comme les dernières pondérations connues afin de déterminer si l'état du serveur a été modifié :
  • Si vous exécutez une commande quiesce, la fonction exécuteur enregistre la pondération en cours du serveur et associe une nouvelle pondération au serveur avec la valeur -1. Voici un exemple de commande quiesce :
    dscontrol manager quiesce serveur
  • Si vous exécutez une commande unquiesce, un appel est envoyé à la fonction exécuteur afin d'utiliser la valeur enregistrée comme valeur de pondération. Le système définit un indicateur afin de préciser que le serveur n'est plus marqué comme étant arrêté par l'utilisateur. Voici un exemple de commande quiesce :
    dscontrol manager unquiesce serveur
    Si la commande unquiesce est émise après que le gestionnaire a extrait les pondérations, la fonction exécuteur remplace la pondération utilisée pour déterminer si l'état du serveur a été modifié. Ce processus ne provoque aucun effet secondaire, sauf si le serveur est mis au repos.

Les chances d'occurrence de cet incident augmentent avec les configurations plus importantes car un cycle du gestionnaire dure plus longtemps. En outre, les probabilités d'un cycle du gestionnaire en cours sont plus élevées lorsque la commande unquiesce est exécutée.

Concept topic    

Terms and conditions for information centers | Feedback

Last updated: May 23, 2013 04:24 PM EDT
File name: ctrb_dispatcher.html