Charge de travail non distribuée

Ces informations peuvent vous aider à diagnostiquer un incident lié à la distribution de la charge de travail.

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.
Si aucune de ces descriptions de solution ne parvient à résoudre votre incident :
  1. [AIX Solaris HP-UX Linux Windows][IBM i]Parcourez les fichiers journaux de la JVM du gestionnaire de déploiement et des serveurs d'applications :
    1. Recherchez les messages d'erreur en sélectionnant la vue Référence du centre de documentation et développez Messages dans l'arborescence de navigation.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]Utilisez l'outil Analyseur de trace et de journal pour parcourir et analyser les journaux de maintenance (activity.log) du gestionnaire de déploiement et tous les noeuds confrontés à des incidents. Consultez les fichiers activity.log dans les deux répertoires racine_serveur_app/logs et racine_serveur_app/logs.
    3. [IBM i]Analysez le journal de maintenance (activity.log) du gestionnaire de déploiement et tous les noeuds confrontés à des incidents. Affichez les fichiers activity.log du répertoire racine_profil/logs.
    4. Si les fichiers journaux contiennent des exceptions Java™, essayez de déterminer le sous-composant directement impliqué dans l'incident en recherchant en haut de la pile la pile de traces une classe liée au produit (dont le nom commence par com.ibm.websphere ou com.ibm.ws) qui a créé l'exception. Au besoin, consultez les étapes de la procédure d'identification des incidents pour le sous-composant en question dans la rubrique Identification et résolution des incidents des applications WebSphere du Centre de documentation.

      Par exemple, si l'exception semble avoir été envoyée par une classe du module com.ibm.websphere.naming, reportez-vous à la rubrique Conseils de résolution des incidents des services de nommage.

  2. [z/OS]Parcourez les fichiers journaux de la JVM du gestionnaire de déploiement et des serveurs d'applications :
    1. Recherchez les messages d'erreur en sélectionnant la vue Référence du centre de documentation et développez Messages dans l'arborescence de navigation.
    2. Si des exceptions Java apparaissent dans les fichiers journaux, essayez de déterminer le sous-composant directement impliqué dans l'incident en recherchant en haut de la pile de traces une classe liée au produit (dont le nom commence par com.ibm.websphere ou com.ibm.ws) qui a créé l'exception. Au besoin, consultez les étapes de la procédure d'identification des incidents pour le sous-composant en question sous la rubrique Identification et résolution des incidents des applications WebSphere du Centre de documentation.

      Par exemple, si l'exception semble avoir été envoyée par une classe du module com.ibm.websphere.naming, reportez-vous à la rubrique Conseils de résolution des incidents des services de nommage.

  3. Vérifiez que toutes les machines de votre configuration communiquent entre elles via TCP/IP en envoyant la commande ping :
    1. de chaque serveur physique au gestionnaire de déploiement
    2. du gestionnaire de déploiement à chaque serveur physique
  4. Même si l'incident se produit dans un environnement de clusters, la cause réelle peut n'être qu'indirectement liée, voire pas liée du tout, à l'utilisation de clusters. Etudiez toutes les possibilités :
    1. Si un bean enterprise d'un ou plusieurs serveurs ne sert pas des requêtes, reportez-vous aux rubriques Impossible d'accéder à un bean enterprise à partir d'un servlet, d'un fichier JSP, d'un programme autonome ou d'un autre client et Impossible d'accéder à un objet hébergé à partir d'un servlet, d'un fichier JSP ou d'un autre client.
    2. Si les incidents semblent se produire après l'activation de la sécurité, reportez-vous à la rubrique Erreurs ou incidents d'accès après l'activation de la sécurité.
    3. Si un serveur d'applications cesse de répondre aux demandes ou s'arrête spontanément (fermeture de son processus), reportez-vous à la rubrique Le module Web ou le serveur d'applications s'arrête ou se bloque.
    4. Si des demandes SOAP ne sont pas honorées par certains ou tous les serveurs, reportez-vous à la rubrique Erreurs renvoyées au client lors de la tentative d'envoi d'une demande SOAP.
    5. [AIX Solaris HP-UX Linux Windows][IBM i]En cas d'incidents lors de l'installation ou du déploiement d'une application sur des serveurs situés sur un ou plusieurs noeuds, reportez-vous à la rubrique Résolution des incidents de déploiement de code et d'installation.
  5. [AIX Solaris HP-UX Linux Windows][IBM i]Si votre topologie se compose d'un gestionnaire de déploiement Windows avec des serveurs UNIX pris en charge, parcourez à l'aide de vi les fichiers .xml et .policy récemment mis à jour sur les systèmes UNIX pris en charge pour vous assurer qu'ils ne contiennent aucun caractère Control-M. Modifiez ces fichiers à l'aide de vi sur les systèmes UNIX pris en charge pour éviter l'insertion de ces caractères.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Consultez les conseils d'identification et de résolution des incidents relatifs au composant WLM (workload management).
  7. Vérifiez dans le support disponible en ligne (conseils et astuces, notes techniques et correctifs) si votre incident est identifié et documenté.

Les demandes HTTP ne sont pas distribuées à tous les serveurs

Si les demandes Web (HTTP) ne sont pas distribuées à tous les serveurs, procédez comme suit :
  • Vérifiez votre liste de serveurs principaux. L'extension répartit la charge entre tous les serveurs de la liste de serveurs principaux si l'affinité n'a pas encore été établie. Si aucune liste de serveurs principaux n'est définie, l'extension 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, l'extension s'adresse directement au serveur concerné pour toutes les demandes d'une même session HTTP.
  • Si certains serveurs traitent les demandes alors qu'un ou plusieurs autres ne les traitent pas, essayez d'accéder directement à un serveur en erreur et vérifiez s'il fonctionne, en dehors des incidents liés à la gestion de la charge de travail. S'il ne fonctionne pas :
    • Vérifiez à l'aide de la console d'administration le serveur en erreur s'exécute.
    • Pour plus d'informations, consultez la rubrique Une ressource Web ne s'affiche pas.
  • Pour plus d'informations, reportez-vous à la rubrique Conseils de résolution des incidents du plug-in HTTP.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Revoyez la procédure de diagnostic des incidents de gestion de la charge de travail dans la rubrique Résolution des incidents du composant WLM (Workload Management).

Les demandes de bean enterprise ne sont pas distribuées à tous les serveurs

Si un client n'arrive pas à accéder à un serveur d'un cluster normalement accessible, il est possible que ce serveur soit marqué comme inutilisable ou arrêté. Pour le vérifier, procédez comme suit :
  • Utilisez la console d'administration pour vérifier si le serveur a été démarré. Essayez de le démarrer ou, s'il l'est déjà, redémarrez-le.
  • Parcourez la console d'administration et vérifiez que le noeud qui exécute le serveur posant problème s'affiche. S'il ne s'affiche pas, procédez comme suit :
    • Revoyez la procédure d'ajout d'un noeud dans un cluster.
    • Revoyez les étapes de la section Un ou plusieurs noeuds ne s'affichent pas dans la console d'administration.
  • Si possible, essayez d'accéder au bean enterprise directement sur le serveur en erreur pour vérifier s'il s'agit d'un incident de connectivité TCP/IP ou de santé du serveur d'applications, ou d'un autre incident sans rapport avec la gestion de la charge de travail. En cas d'échec, revoyez la rubrique Impossible d'accéder à un bean enterprise à partir d'un servlet, d'un fichier JSP, d'un programme autonome ou d'un autre client.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Revoyez la procédure de diagnostic des incidents de gestion de la charge de travail dans la rubrique Résolution des incidents du composant WLM (Workload Management).
[AIX Solaris HP-UX Linux Windows][IBM i]

Les demandes de bean enterprise ne sont pas équitablement distribuées

Cet incident peut avoir diverses causes, qui entrent généralement dans l'une ou plusieurs des catégories suivantes :
  • Configuration incorrecte
  • Problèmes d'environnement, tels que la disponibilité des serveurs et des applications.
  • Nombre de demandes élevé impliquant une affinité transactionnelle ou
  • Nombre limité de clients

[AIX Solaris HP-UX Linux Windows][IBM i]La gestion de la charge de travail dans le produit s'appuie sur une technique proportionnelle pondérée pour répartir des requêtes entre les serveurs. En conséquence, l'équilibrage dépend du nombre de requêtes et non d'une autre mesure. Un réel incident d'équilibrage se détermine par comparaison du nombre de requêtes traitées par chaque membre du cluster avec les pondérations définies pour chacun de ces membres. Pour ce faire, suivez la procédure décrite dans la rubrique Résolution des incidents du composant WLM (Workload Management).

[z/OS]La gestion de la charge de travail dans le produit s'appuie sur la technique de permutation circulaire pour la distribution des requêtes. En conséquence, l'équilibrage dépend du nombre de requêtes et non d'une autre mesure. Un réel incident d'équilibrage se détermine par comparaison du nombre de requêtes traitées par chaque membre du cluster avec les pondérations définies pour chacun de ces membres.

[z/OS]
  • Lorsque le pourcentage de demandes que reçoit chaque membre du cluster est cohérent avec les pondérations définies une analyse plus approfondie de l'application est requise pour déterminer pourquoi la charge de travail est déséquilibrée alors que le nombre de demandes est équilibré.
  • Lorsque le nombre de demandes d'objet non WLM entrantes (numIncomingNonWLMObjectRequests) n'est pas équilibré entre les membres du cluster et est élevé par rapport au nombre de demandes entrantes (numIncomingRequests), le déséquilibre provient des composants non distribuables installés sur le membres du cluster. Une modification de la configuration permettra d'obtenir un environnement plus équilibré.
  • Lorsque le nombre de demandes à forte affinité entrantes (numIncomingStrongAffinityRequests) n'est pas équilibré entre les membres du cluster et est élevé par rapport au nombre de demandes entrantes (numIncomingRequests), le déséquilibre provient des demandes impliquées dans une transaction. Vous pouvez réduire cet écart en installant dans le même cluster tous les objets impliqués dans une transaction.

Un serveur défectueux continue de recevoir des demandes de beans enterprise (la fonction de secours n'aboutit pas)

Les causes possibles de cet incident sont les suivantes :
  • [AIX Solaris HP-UX Linux Windows][IBM i]Le client effectuait une transaction avec un bean enterprise sur le serveur qui s'est arrêté. Vérifiez les journaux de la JVM du serveur d'applications hébergeant l'instance de bean enterprise posant problème. Si une demande est renvoyée avec l'exception CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE, il est possible que le fonctionnement prévu soit respecté, à savoir, laisser cette exception particulière retourner au client, car la transaction s'est achevée. La transmission de cette demande à un autre serveur peut entraîner que la demande soit traitée deux fois.
  • [z/OS]Le client effectuait une transaction avec un bean enterprise sur le serveur qui s'est arrêté. Vérifiez les journaux de la JVM du serveur d'applications hébergeant l'instance de bean enterprise posant problème. Si une demande est renvoyée avec l'exception CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE, il est possible que le fonctionnement prévu soit respecté, à savoir, laisser cette exception particulière retourner au client, car la transaction s'est achevée. La transmission de cette demande à un autre serveur peut entraîner que la demande soit traitée deux fois.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Si les demandes envoyées aux serveurs reviennent au client de manière répétée avec d'autres exceptions, il est possible qu'aucun serveur ne soit disponible. Dans ce cas, suivez la procédure décrite dans la rubrique Résolution des incidents du composant WLM (Workload Management).
  • [z/OS]Si les demandes envoyées aux serveurs reviennent au client de manière répétée avec d'autres exceptions, il est possible qu'aucun serveur ne soit disponible.
[z/OS]

Des serveurs arrêtés ou en attente ne se partagent pas la charge de travail une fois restaurés

Cette erreur se produit lorsque les serveurs précédemment indisponibles ne sont toujours pas reconnus par le composant WLM malgré leur restauration. Un intervalle pendant lequel le gestionnaire WLM attend avant toute transmission à un serveur marqué comme inutilisable est déterminé par la propriété com.ibm.websphere.wlm.unusable.interval. La valeur par défaut de cet intervalle est 5 minutes.

Vous pouvez confirmer que l'incident se situe à ce niveau en vérifiant que les serveurs précédemment arrêtés sont désormais actifs et capables de répondre aux requêtes. Attendez ensuite que l'intervalle pendant lequel le serveur est considéré inutilisable soit écoulé avant de vérifier si la restauration s'est effectuée.

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

Il n'existe pas de reprise par basculement sur le cluster de sauvegarde pour un cluster

Une erreur similaire à l'exemple suivant peut survenir :
[10/11/04 13:11:10:233 CDT] 00000036 SelectionMana A    WWLM0061W: An error was 
encountered sending a request to cluster member  {MEMBERNAME=FlorenceEJBServer1, 
NODENAME=fwwsaix1Node01} and that member has been  marked unusable for future 
requests to the cluster "", because of exception:  org.omg.CORBA.COMM_FAILURE: 
CONNECT_FAILURE_ON_SSL_CLIENT_SOCKET - JSSL0130E:  java.io.IOException: Signals 
that an I/O exception of some sort has occurred.   Reason:  Connection refused  
vmcid: 0x49421000  minor code: 70  completed: No" 
Procédez de la manière suivante pour résoudre la configuration :
  1. Vérifiez le nom d'hôte du gestionnaire de déploiement et le port d'amorçage pour chaque paramètre de cluster de sauvegarde.
  2. Consultez les ports homologues de la passerelle de groupe central afin de vous assurer que le nom d'hôte et le port DCS (Distribution and Consistency Services) sont appropriés.
  3. Vérifiez que les noms du cluster principal et du cluster de sauvegarde correspondent.
  4. Si votre application suit un processus de sécurité pour accéder au cluster de sauvegarde, consultez la configuration de sécurité. Il peut être nécessaire d'utiliser SSO et d'importer les clés LTPA (Lightweight Third Party Authentication) dans la cellule de sauvegarde.

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_wlmprobs
Nom du fichier : rtrb_wlmprobs.html