Erreurs d'environnement multiserveurs

Utilisez ces informations pour résoudre des incidents liés à la configuration des environnements multiserveurs.

Si aucune de ces descriptions de solution ne parvient à résoudre votre incident :
  1. Parcourez les fichiers journaux du gestionnaire de déploiement et des serveurs d'applications.

    [AIX Solaris HP-UX Linux Windows][IBM i]Affichez les journaux de la JVM.

    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 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 de traces une classe liée à WebSphere Application Server (dont le nom commence par com.ibm.websphere ou com.ibm.ws) qui a créé l'exception.

      Par exemple, si l'exception semble avoir été créé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. 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
  3. Même si l'incident se produit dans un environnement de clusters, la cause réelle peut être indirectement liée, voire pas liée du tout, à l'utilisation de clusters. Etudiez toutes les possibilités :
    1. Si un bean enterprise sur un ou plusieurs serveurs ne traite 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 Incidents liés à l'accès aux applications.
    2. Si les incidents semblent se produire après l'activation de la sécurité, reportez-vous à la rubrique Incidents d'accès après l'activation de la sécurité.
    3. Si un serveur d'applications cesse de répondre aux requêtes ou s'arrête spontanément (fermeture de son processus), reportez-vous à la rubrique Le module Web ou le serveur d'applications arrête de traiter les demandes.
    4. Si des demandes SOAP ne sont pas traitées par des serveurs, reportez-vous à la rubrique Conseils pour la résolution des incidents liés aux demandes SOAP du client d'application.
    5. 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 Incidents de déploiement d'application.
  4. Si votre topologie se compose d'un gestionnaire de déploiement Windows avec des serveurs UNIX, parcourez à l'aide de l'éditeur vi les fichiers .xml et .policy récemment mis à jour sur les plateformes UNIX pour vous assurer qu'aucun caractère Control-M ne se trouve dans ces fichiers. Modifiez ces fichiers à l'aide de l'éditeur vi sous UNIX pour que cet incident ne se reproduise plus.
  5. Consultez les étapes de la procédure de résolution des incidents du composant WLM (workload management).
  6. Vérifiez dans le support disponible en ligne (conseils et astuces, notes techniques et correctifs) si votre incident est identifié et documenté.
[AIX Solaris HP-UX Linux Windows]

Lorsque vous tentez de créer un nouveau profil dans un environnement de cellule mixte, une discordance de modèles peut se produire

Cet incident se produit quand les modèles du profil ne sont pas mis à jour lorsqu'un groupe de correctifs de version 6.0.x est appliqué à la version 6.0.x de WebSphere Application Server. Pour lever les restrictions en vigueur dans un environnement de cellule mixte, vous pouvez exécuter une commande dans le répertoire bin de la racine d'installation WebSphere Application Server afin de mettre à jour le profil.

Sous Windows, exécutez la commande suivante, laquelle utilise C:\Program Files\IBM\WebSphere\AppServer comme racine d'installation par défaut :
racine_serveur_app\bin\ws_ant.bat -buildfile updateNDProfileTemplates.xml
Sous UNIX et Linux, exécutez les commandes ci-dessous :
  • Pour les plateformes non AIX, la racine d'installation par défaut est /opt/IBM/WebSphere/AppServer.
  • Pour les plateformes AIX, la racine d'installation par défaut est /usr/IBM/WebSphere/AppServer.
    • Pour les plateformes non AIX, entrez la commandes suivante :
      USER_INSTALL_ROOT=racine_serveur_app/profiles/your_DM_profile_name/
    • Pour AIX, exécutez la commande suivante :
      USER_INSTALL_ROOT=racine_serveur_app/profiles/your_DM_profile_name/ 
  1. export USER_INSTALL_ROOT
  2. racine_serveur_app/bin/ws_ant -buildfile updateNDProfileTemplates.xml

Un cluster créé et démarré ne démarre pas et les journaux indiquent que les serveurs sont introuvables.

Cette erreur peut se produire lorsque la configuration n'est pas synchronisée sur un noeud à partir du gestionnaire de déploiement. Si l'auto synchronisation a été activée, attendez qu'elle s'effectue. Si vous utilisez la synchronisation manuelle, lancez-en une sur chaque noeud du cluster.

Pour déterminer si la synchronisation s'est produite, observez la configuration des machines du noeud à l'aide de la console d'administration et assurez-vous que les nouveaux membres du cluster sont définis sur chaque noeud.

Un ou plusieurs noeuds ne s'affichent dans la console d'administration.

Cet incident peut se produire en cas d'incident de connectivité de base entre le serveur du gestionnaire de déploiement et d'autres serveurs de la topologie. Recherchez le fichier serverindex.xml dans la structure du répertoire du gestionnaire de déploiement :
  • Si le noeud en erreur ne s'affiche pas dans la liste, revoyez la procédure d'ajout d'un noeud dans le cluster.
  • Si le noeud en erreur s'affiche dans la liste, procédez comme suit :
    • A partir du serveur du gestionnaire de déploiement, envoyez la commande ping au nom de serveur indiqué dans la liste. Si la commande ping échoue, vérifiez que le nom d'hôte indiqué dans la liste est correct, sinon rectifiez-le, puis redémarrez le gestionnaire de déploiement.
    • Si le nom indiqué dans la liste est un nom abrégé, envoyez la commande ping au nom de réseau complet. Si le nom fonctionne, mettez la liste à jour, puis redémarrez le gestionnaire de déploiement.
    • Si le serveur concerné utilise le protocole DHCP (Dynamic Host Configuration Protocol), essayez de remplacer le nom d'hôte logique par l'adresse IP, puis redémarrez le gestionnaire de déploiement. Si cette action résout l'incident, n'oubliez pas que vous devrez modifier le fichier serverindex.xml chaque fois que l'adresse du serveur change, c'est-à-dire à chaque redémarrage du système concerné. Pour éviter cet incident, attribuez une adresse IP statique au serveur.
  • Si vous ne pouvez toujours pas établir la communication entre les serveurs, prenez contact avec votre administrateur réseau, puis redémarrez le gestionnaire de déploiement une fois l'incident résolu.

Echec de la commande addNode

Cette erreur peut se produire lorsque la configuration DNS du gestionnaire de déploiement n'est pas correctement définie. L'installation par défaut sur des systèmes Linux utilise l'adresse de bouclage (127.0.0.1) comme adresse d'hôte par défaut. Pour vérifier cet incident, recherchez le nom d'hôte sur la machine en erreur. Si vous obtenez l'hôte local 127.0.0.1 ou si les traces du transfert de fichier sur le noeud montrent que le noeud tente de télécharger des fichiers sur une adresse Web qui contient 127.0.0.1, la configuration du DNS du noeud est incorrecte.

Pour corriger cette erreur, mettez à jour le fichier /etc/hosts ou le fichier de configuration du service de noms /etc/nsswitch.conf pour obtenir le DNS ou le NIS avant de rechercher les hôtes.

Les fichiers d'applications ne se trouvent pas sur tous les noeuds.

[AIX Solaris HP-UX Linux Windows][z/OS]Dans l'environnement WebSphere Application Server, Network Deployment, les fichiers binaires d'application sont transférés aux noeuds sur lesquels les applications sont prises en charge dans le cadre de l'opération de synchronisation de noeud. Lors de cette synchronisation, les fichiers d'application ne sont propagés que si leurs descripteurs de déploiement indiquent enableDistribution=true. Cet indicateur est spécifié lors de la procédure d'installation de l'application dans la console d'administration et stocké comme une propriété dans le fichier racine_serveur_app/config/cells/nom_cellule/applications/nom_application/deployment.xml.

[IBM i]Dans l'environnement WebSphere Application Server, Network Deployment, les fichiers binaires d'application sont transférés aux noeuds sur lesquels les applications sont prises en charge dans le cadre de l'opération de synchronisation de noeud. Lors de cette synchronisation, les fichiers d'application ne sont propagés que si leurs descripteurs de déploiement indiquent enableDistribution=true. Cet indicateur est spécifié lors de la procédure d'installation de l'application dans la console d'administration et stocké comme une propriété dans le fichier racine_profil/config/cells/nom_cellule/applications/nom_application/deployment.xml.

Pour confirmer cet incident, vérifiez si l'indicateur enableDistribution est défini. Si la valeur attribuée est déjà true, vérifiez que le noeud cible est configuré pour la synchronisation automatique des fichiers.

Si ces deux paramètres sont corrects et que l'incident persiste, effectuez une synchronisation manuelle. Si les fichiers d'application n'apparaissent toujours pas dans le répertoire d'installation, utilisez l'outil EARExpander situé dans le répertoire racine_serveur_app/bin pour développer le fichier EAR du référentiel dans le répertoire d'installation cible. Sur des noeuds éloignés, le référentiel s'affiche dans le répertoire config/cells/nom_cellule/applications/nom_application.ear/.

Dans un environnement à clusters, un serveur dont le mode de débogage est activé ne démarre pas.

Cette erreur survient lorsque les trois conditions suivantes sont réunies :
  • Plusieurs processus de serveur sont configurés pour s'exécuter sur le même noeud
  • Le mode débogage est activé sur plusieurs serveurs
  • The debug arguments for more than one of the servers remain at the default values, so that more than one server in the node is trying to use the same debug port (port number 7777).

Le serveur ne démarre pas car plusieurs processus de serveur s'exécutant sur la même machine hôte physique et ayant la fonction de débogage activée ne peuvent pas utiliser le même port de débogage.

Pour résoudre cet incident, procédez comme suit pour chaque serveur :
  1. Dans la console d'administration, cliquez sur Serveur > Serveurs d'applications > nom_serveur > Gestion des processus et Java > Définition des processus > Machine virtuelle Java.
  2. Mettez à jour l'argument de débogage, pour que l'adresse du port de débogage (adresse=numéro port) est unique pour chaque processus serveur.

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_multprobs
Nom du fichier : rtrb_multprobs.html