Utilisez les informations fournies pour résoudre les incidents liés à Content Based Routing.
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 |
|
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 |
|
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. |
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.
Utilisez netstat
-ni pour vérifier.
Utilisez netstat
-nr pour vérifier.
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.
EXCLUDE-MODULE java
EXCLUDE-MODULE javaw
Ceci peut être source de problèmes lorsqu'une des consoles d'administration s'exécute sur la même machine qu'un pare-feu ou passe par un pare-feu. Par exemple, lorsque 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.
Par exemple : java -Djava.rmi.server.hostname="10.1.1.1"
LB_ADV_NO_PING="true"
java -DLB_ADV_NO_PING="true"
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.
Pour que l'interface graphique lbadmin fonctionne correctement, vous devez disposer d'une quantité d'espace de pagination suffisante. Dans le cas contraire, l'interface graphique peut ne pas démarrer complètement. Si cela se produit, vérifiez l'espace de pagination et augmentez-la si nécessaire.
Si 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.
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.
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 -Xmxn où n correspond à la taille maximale, en octets, de la mémoire. n doit être un multiple de 1024 et supérieur à 2 Mo. La valeur n peut être suivie du caractère k ou K pour indiquer qu'il s'agit de kilo-octets ou du caractère m ou M pour indiquer qu'il s'agit de méga-octets. Par exemple, -Xmx128M et -Xmx81920k sont valides. La valeur par défaut est 64M. Solaris 8 accepte une valeur maximale de 4000M.
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS
com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS
com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS
com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS
com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
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.
-Monotype-TimesNewRomanWT-medium-r-normal
--*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal
--*-%d-75-75-*-*-ksc5601.1987-0
-monotype-
timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
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.
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.
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.
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.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
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.
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.
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.
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.
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.
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.
dscontrol host@@<adresse_ip ou nom_hôte> <command>
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 :
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.
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.
Les iptables Linux peuvent interférer avec l'équilibrage de charge du trafic et doivent être désactivées sur la machine Dispatcher.
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
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.
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.
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.
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.
dscontrol manager quiesce serveur
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.