Erreurs d'environnement multiserveurs
Utilisez ces informations pour résoudre des incidents liés à la configuration des environnements multiserveurs.
Lorsque vous tentez de créer un nouveau profil dans un environnement de cellule mixte, une discordance de modèles peut se produire
- Un cluster créé et démarré ne démarre pas et les journaux indiquent que les serveurs sont introuvables.
- Un ou plusieurs noeuds ne s'affichent dans la console d'administration.
- Echec de la commande addNode
- Les fichiers d'applications ne se trouvent pas sur tous les noeuds.
- Dans un environnement à clusters, un serveur dont le mode de débogage est activé ne démarre pas.
- Parcourez les fichiers journaux du gestionnaire de déploiement et des serveurs d'applications.
Affichez les journaux de la JVM.
- 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.
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.
- Vérifiez que toutes les machines de votre configuration communiquent entre
elles via TCP/IP en envoyant la commande ping :
- de chaque serveur physique au gestionnaire de déploiement
- du gestionnaire de déploiement à chaque serveur physique
- 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 :
- 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.
- 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é.
- 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.
- 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.
- 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.
- 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.
- Consultez les étapes de la procédure de résolution des incidents du composant WLM (workload management).
- 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]](../images/dist.gif)
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.
racine_serveur_app\bin\ws_ant.bat -buildfile updateNDProfileTemplates.xml
- 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/
- Pour les plateformes non AIX, entrez la commandes suivante :
- export USER_INSTALL_ROOT
- 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.
- 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.
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.
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.
- 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.
- Dans la console d'administration, cliquez sur .
- 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.