Conseils de résolution des incidents du composant WLM (Workload management)

Si le composant WLM (workload management) ne répartit pas correctement la charge de travail entre les serveurs d'une configuration à plusieurs noeuds, utilisez les options suivantes pour isoler l'incident.

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.

Suppression des incidents de configuration ou d'environnement

Déterminez si les serveurs sont capables de servir les applications pour lesquels ils ont été activés. Identifiez le cluster comportant un incident.
  • Décelez-vous des incidents au niveau des membres du cluster ou des serveurs d'administration, par exemple gestionnaire de déploiement ou agents de noeud ?
    • Auquel cas, testez la connectivité des machines (avec ping) pour vous assurer qu'elles sont correctement connectées au réseau.
  • Déterminez si une autre activité sur les machines où sont installés les serveurs porte atteinte à la capacité du serveur à servir une demande. Par exemple, vérifiez l'utilisation du processeur selon les critères du gestionnaire de tâches, de l'ID de processeur ou de tout autre outil externe pour savoir si cette utilisation :
    • n'est pas conforme aux attentes ou est irrégulière au lieu d'être constante,
    • montre qu'un nouveau membre ajouté, installé ou mis à niveau du cluster n'est pas utilisé.
  • Tous les serveurs d'applications démarrés sur chaque noeud s'exécutent-ils ou certains sont-ils arrêtés ?
  • Les applications sont-elles installées et en cours de fonctionnement ?
  • Si l'incident est lié à la répartition de la charge de travail entre beans enterprise ou persistants (CMP ou BMP), avez-vous configuré les fournisseurs JDBC et la source de données JDBC sur chaque serveur ?

En cas d'incidents de gestion de charge de travail liés à des demandes HTTP, par exemple des demandes HTTP non prises en charge par tous les membres du cluster, n'oubliez pas que le plug-in HTTP équilibre la charge entre les serveurs définis dans la liste des serveurs principaux si l'affinité n'a pas été établie. Si aucune liste de serveurs principaux n'est définie, le plug-in répartit la charge entre tous les serveurs du cluster si l'affinité n'a pas encore été établie. Si l'affinité a été établie, le plug-in s'adresse directement au serveur concerné pour toutes les demandes.

Pour les incidents de gestion de charge liés aux demandes de bean enterprise, telles que les demandes de bean enterprise non prises en charge par tous les membres d'un cluster :
  • Les pondérations sont-elles définies aux valeurs autorisées ?
    • Pour le cluster en question, connectez-vous à la console d'administration et :
      1. Sélectionnez Serveurs > Clusters > Clusters WebSphere Application Server.
      2. Sélectionnez un cluster dans la liste.
      3. Sélectionnez Membres du cluster.
      4. Pour chaque serveur du cluster, cliquez sur nom_serveur et notez la valeur de pondération affectée au serveur.
    • Vérifiez que les pondérations sont comprise dans la plage admise 0 à 20. Lorsqu'un serveur a une pondération de 0, aucune demande ne lui est transmise. Les pondérations supérieures à 20 sont traitées comme celles de 0.

La suite de cet article ne traite que de l'équilibrage de la charge des beans enterprise. Pour obtenir plus d'informations sur le diagnostic des incidents de distribution des demandes Web (HTTP), consultez les rubriques "Conseils de résolution des incidents liés au plug-in du serveur Web" et "Une ressource Web ne s'affiche pas".

[IBM i][AIX Solaris HP-UX Linux Windows]

Recherche dans les journaux d'erreurs d'erreur WLM et de codes mineurs CORBA

Si vous avez toujours des incidents avec la répartition de la charge des beans, l'étape suivante consiste à vérifier si le journal d'activité contient des entrées qui signalent :
  • Un serveur marqué comme inutilisable plusieurs fois et qui reste inutilisable.
  • Tous les serveurs d'un cluster maqués comme étant en erreur et qui restent inutilisables.
  • [z/OS]Un LSD (démon du service de localisation) marqué comme inutilisable plusieurs fois et qui reste inutilisable.

[IBM i][AIX Solaris HP-UX Linux Windows]Pour ce faire, utilisez l'analyseur de trace et de journal afin d'ouvrir le journal de maintenance (activity.log) sur les serveurs affectés et recherchez les entrées suivantes :

[z/OS]Pour ce faire, ouvrez le journal de services sur les serveurs affectés et recherchez les entrées suivantes :

  • WWLM0061W : Une erreur s'est produite lors de l'envoi d'une demande au membre de cluster membre et ce membre a été associé à la mention inutilisable pour les futures demandes au cluster cluster.
    Remarque : Il n'est pas fréquent qu'un serveur soit marqué comme inutilisable. La mention inutilisable peut être associée à un serveur pour des raisons opérationnelles, par exemple un démarrage par permutation exécuté alors que le serveur détient toujours une charge provenant d'un client. Il est également normal d'obtenir presque simultanément un grand nombre de messages d'avertissement WWLM0061W pour un membre. En général, il existe des demandes en cours de traitement sur plusieurs unités d'exécution et après le marquage du membre comme étant indisponible, et il est fort probable que les unités d'exécution qui ciblent ce membre reçoivent ce message d'avertissement.
  • WWLM0062W : Une erreur s'est produite lors de l'envoi d'une demande au membre de cluster membre et ce membre a été associé une ou plusieurs fois à la mention inutilisable pour les futures demandes au cluster cluster.
  • WWLM0063W : Une erreur s'est produite lors d'une tentative d'utilisation du LSD nom_LSD afin de résoudre une référence d'objet pour le cluster cluster et ce LSD a été associé à la mention inutilisable pour les futures demandes au cluster.
  • WWLM0064W : Des erreurs se sont produites lors de l'envoi d'une demande à tous les membre du cluster cluster et tous ces membres ont été associés à la mention inutilisable pour les futures demandes au cluster.
  • WWLM0065W: Une erreur s'est produite lors d'une tentative de mise à jour d'un membre de cluster serveur du cluster cluster, car il n'était pas accessible à partir du gestionnaire de déploiement.
  • WWLM0067W : Il a été signalé que le client a effectué une nouvelle tentative de demande. Une demande de serveur n'a pas pu être effectuée de nouveau de manière transparente par WLM, à cause de l'exception :{0}

    Lors de la tentative de service d'une demande, WLM a rencontré‚ une erreur qui ne permet pas une nouvelle transmission transparente de la demande. L'exception est interceptée et un nouvel élément CORBA.TRANSIENT avec un code mineur 0x49421042 (SERVER_SIGNAL_RETRY) est émis à destination du client.

Si vous êtes confronté à l'un de ces avertissements, intervenez comme indiquez dans le journal. Si, une fois l'intervention préconisée effectuée, les avertissements persistent, analysez les autres erreurs et avertissements à l'aide de l'analyseur de journaux et de trace pour savoir quels serveurs rechercher :
  • Une intervention possible de l'utilisateur, telle la modification d'un paramètre de configuration.
  • Des exceptions de classe de base pouvant indiquer une défaillance du produit.

Vous pouvez également trouver des exceptions dont le nom contient "CORBA", car WLM utilise l'architecture CORBA (Common Object Request Broker Architecture) pour la communication entre les processus. Recherchez dans la pile des exceptions une instruction spécifiant un "code mineur". Ces codes indiquent la raison précise de l'échec d'un appel ou d'une réponse CORBA. Les codes mineurs WLM sont compris entre 0x4921040 et 0x492104F. Pour une explication concernant les codes mineurs liés à WLM, reportez-vous à la rubrique "Références : documentation sur les API générées" relative au package et à la classe com.ibm.websphere.wlm.WsCorbaMinorCodes.

[IBM i][AIX Solaris HP-UX Linux Windows]

Analyse des données PMI

L'analyse des données MPI a pour but de connaître la charge de travail qui arrive à chaque membre d'un cluster. Les données concernant un membre du cluster ne présentent d'intérêt que dans le contexte des données de tous les membres du cluster.

Tivoli Performance Viewer permet de vérifier que, sur la base des pondérations affectées aux membres du cluster (pondérations de l'état d'attente), chaque serveur obtient la proportion de requêtes appropriée.

Pour capturer les mesures PMI, dans la zone de navigation de Tivoli Performance Viewer, effectuez les actions suivantes :
  1. Sélectionnez Collecte de données dans l'arborescence de navigation. Les serveurs pour lesquels PMI n'est pas activé apparaissent en grisé.
  2. Pour chaque serveur pour lequel vous souhaitez collecter des données, cliquez sur Spécifier...
  3. Vous pouvez maintenant activer les mesures. Dans la fenêtre des paramètres de contrôle des performances, affectez la valeur faible au niveau de contrôle.
  4. Cliquez sur OK
  5. Cliquez sur Valider pour sauvegarder les modifications apportées.

Les mesures PMI WLM peuvent être consultées sur un serveur, par serveur spécifique. Dans Tivoli Performance Viewer, sélectionnez Noeud > Serveur > WorkloadManagement > Serveur/Client. Par défaut, les données brutes, collectées toutes les 10 secondes, s'affichent dans un tableau sous forme de nombres. Vous pouvez également choisir de consulter les données sous forme de delta ou de taux, d'ajouter ou de supprimer des colonnes, d'effacer le tampon, de réinitialiser les mesures à zéro et de modifier la fréquence de la collecte et la taille du tampon.

Une fois les données PMI obtenues, vous devez calculer le pourcentage de numIncomingRequests (nombre de demandes entrantes) de chaque membre du cluster par rapport au total de numIncomingRequests de tous les membres du cluster. La comparaison de ce pourcentage avec le pourcentage des pondérations dirigées vers chaque membre du cluster donne un premier aperçu de l'équilibrage de la charge affectée à chaque membre d'un cluster.

Outre numIncomingRequests, deux autres mesures indique comment est équilibrée la charge entre les membres d'un cluster : numincomingStrongAffinityRequests et numIncomingNonWLMObjectRequests. Ces deux mesures indiquent le nombre de demandes orientées vers un membre spécifique d'un cluster qui ne peuvent être traitées que par ce membre.

Prenons, par exemple, un cluster de 3 serveurs. Les pondérations suivantes ont été affectées à ces trois serveurs :
  • Serveur1 = 5
  • Serveur2 = 3
  • Serveur3 = 2
Autorisons le cluster de serveurs à traiter les demandes et attendons que le système passe à l'état d'attente, c'est-à-dire l'état où le nombre de demandes entrantes est égal au nombre de réponses issues des serveurs. Dans une telle situation, nous prévoyons que le pourcentage de demandes acheminé vers chaque serveur soit le suivant :
  • % acheminé vers Serveur1 = pondération1 / (pondération1+pondération2+pondération3) = 5/10 ou 50%
  • % acheminé vers Serveur2 = pondération2 / (pondération1+pondération2+pondération3) = 3/10 ou 30%
  • % acheminé vers Serveur3 = pondération3 / (pondération1+pondération2+pondération3) = 2/10 ou 20%

Prenons maintenant le cas où il n'y a pas ni demandes entrantes avec forte affinité ni demandes d'objet non WLM.

Dans ce scénario, supposons que les mesures PMI collectées indiquant que le nombre de demandes entrantes pour chaque serveur est le suivant :
  • numIncomingRequestsServer1 = 390
  • numIncomingRequestsServer2 = 237
  • numIncomingRequestsServer3 = 157

En conséquence, le nombre total de demandes entrantes dans le cluster est : numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 784

numincomingStrongAffinityRequests = 0

numIncomingNonWLMObjectRequests = 0

Ces données permettent-elles de déterminer si WLM répartit correctement les demandes entrantes entre les serveurs du cluster ? En l'absence de demandes à forte affinité, nous devons déterminer si les demandes respectent les rapports escomptés d'après les pondérations affectées. Le calcul permettant de le déterminer est le suivant :
  • % (réel) acheminé vers Serveur1 = 390 / 784 = 49, 8%
  • % (réel) acheminé vers Serveur2 = 237 / 784 = 30, 2%
  • % (réel) acheminé vers Serveur3 = 157 / 784 = 20, 0%
WLM se comporte donc comme prévu puisque les données sont celles escomptées d'après les pondérations affectées aux serveurs.
Prenons maintenant un cluster de 3 serveurs. Les pondérations suivantes ont été affectées à ces trois serveurs :
  • Serveur1 = 5
  • Serveur2 = 3
  • Serveur3 = 2
Autorisons ce cluster de serveurs à traiter les demandes et attendons que le système passe à l'état d'attente, c'est-à-dire l'état où le nombre de demandes entrantes est égal au nombre de réponses issues des serveurs. Dans une telle situation, nous prévoyons que le pourcentage de demandes acheminé vers les serveurs 1 à 3 soit le suivant :
  • % acheminé vers Serveur1 = pondération1 / (pondération1+pondération2+pondération3) = 5/15 ou 1/3 des demandes.
  • % acheminé vers Serveur2 = pondération2 / (pondération1+pondération2+pondération3) = 5/15 ou 1/3 des demandes.
  • % acheminé vers Serveur3 = pondération3 / (pondération1+pondération2+pondération3) = 5/15 ou 1/3 des demandes.
Dans ce scénario, supposons que les mesures PMI collectées indiquant que le nombre de demandes entrantes pour chaque serveur est le suivant :
  • numIncomingRequestsServer1 = 1236
  • numIncomingRequestsServer2 = 1225
  • numIncomingRequestsServer3 = 1230
En conséquence, le nombre total de demandes entrantes dans le cluster est :
  • numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
  • numincomingStrongAffinityRequests = 445 et ces 445 demandes sont acheminées vers Serveur1.
  • numIncomingNonWLMObjectRequests = 0.
Nous voyons ici que les demandes ne sont pas, comme prévu, équitablement réparties entre les trois serveurs. Elles sont distribuées comme suit :
  • % (réel) acheminé vers Serveur1 = 1236 / 3691= 33, 49%
  • % (réel) acheminé vers Serveur2 = 1225 / 3691= 33, 19%
  • % (réel) acheminé vers Serveur3 = 1230 / 3691= 33, 32%

L'interprétation correcte de ces données permet de déterminer que l'acheminement des demandes n'est pas équitablement réparti compte tenu des centaines de demandes à forte affinité de Serveur1. WLM tente de compenser les demandes à forte affinité acheminées vers 1 ou plusieurs serveurs en distribuant les nouvelles demandes entrantes de préférence aux serveurs qui ne participent pas au processus d'affinité transactionnelle de façon à soulager les serveurs qui y participent. Dans le cas des demandes entrantes à forte affinité et des demandes d'objet non WLM, l'analyse est identique à cette situation.

Si, une fois les données PMI analysées et prises en compte pour l'affinité transactionnelle et les demandes d'objet non WLM, le pourcentage de demandes entrantes réelles transmises aux serveurs d'un cluster ne correspond pas aux pondérations affectées, nous pouvons en déduire que que les demandes ne sont pas correctement réparties. Si tel est le cas, reprenez la procédure de résolution des incidents d'environnement et de configuration et consultez les fichiers journaux avant de poursuivre.

Résolution de l'incident ou prise de contact avec le support IBM

[IBM i][AIX Solaris HP-UX Linux Windows]Si les données PMI ou les journaux du client signalent une erreur dans WLM, collectez les informations suivantes, puis prenez contact avec le support technique IBM.

Si les journaux du client signalent une erreur dans WLM, collectez les informations suivantes, puis prenez contact avec le support technique IBM.

  • Une description détaillée de votre environnement.
  • Une description des symptômes.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Les fichiers SystemOut.logs et SystemErr.logs pour tous les serveurs du cluster.
  • [z/OS]Les fichiers journaux du serveur pour tous les serveurs du cluster.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Le fichier activity.log.
  • [IBM i][AIX Solaris HP-UX Linux Windows]Les fichiers journaux FFDC (First Failure Data Capture).
  • [IBM i][AIX Solaris HP-UX Linux Windows]Les mesures PMI.
  • Une description de l'opération que tente d'effectuer le client et une description du client. Par exemple, 1 ou plusieurs unités d'exécution, servlet, client J2EE, etc.

Lorsqu'aucune de ces opérations ne résout l'incident, vérifiez s'il a été identifié et documenté en utilisant les liens de la rubrique "Diagnostics et résolution des incidents : Ressources d'apprentissage". Si vous ne trouvez pas d'incident similaire au vôtre, ou si les informations fournies ne permettent pas de le résoudre, prenez contact avec le support technique IBM pour une assistance complémentaire.

[AIX Solaris HP-UX Linux Windows][z/OS]Si vous n'y trouvez aucune information utile, prenez contact avec le Support technique IBM.

[AIX Solaris HP-UX Linux Windows]Pour les toutes dernières informations disponibles auprès du support technique IBM sur les incidents recensés et leur résolution, accédez à la page IBM Support. Reportez-vous à cette page avant d'ouvrir un PMR car elle contient des documents qui peuvent vous permettre de gagner du temps lors de la collecte des informations requises pour résoudre cet incident.

[IBM i]Pour obtenir des informations sur les incidents connus et leur résolution auprès du support IBM, reportez-vous à la page Logiciels IBM i. Référez-vous à cette page avant d'ouvrir un PMR car elle contient des informations relatives aux documents que vous devez rassembler et envoyer à IBM pour recevoir de l'aide sur un incident.


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_wlmcomp
Nom du fichier : rtrb_wlmcomp.html