Résolution des incidents de migration
Des incidents peuvent se produire lors d'une migration à partir d'une version plus ancienne de WebSphere Application Server.
Avant de commencer

Cet article traite de la migration de configuration de profil. Pour faire migrer vos applications vers la dernière version, utilisez le kit d'outils de migration de WebSphere Application Server. Pour plus d'informations, voir Migration Toolkit on WASdev.
sptcfgProcédure
- Lors de l'utilisation de l'assistant de migration de
Version 9.0 afin de créer un profil avant de migrer une
configuration, vous pouvez rencontrer les messages d'erreur de création de profil suivants.
profileName: profileName cannot be empty profilePath: Insufficient disk space
Ces messages d'erreur peuvent s'afficher si vous entrez un nom de profil qui contient des caractères incorrects comme un espace. Exécutez une nouvelle fois l'assistant de migration, puis vérifiez que le nom de profil ne contient aucun caractère incorrect tel qu'un espace, des guillemets ou tout autre caractère spécial.
- Si un incident se produit pendant la migration d'une version antérieure de
WebSphere
Application Server vers la Version 9.0, inspectez vos fichiers journaux et les autres informations disponibles.
- Cherchez les fichiers journaux et parcourez-les pour trouver des explications.
- répertoire_sauvegarde_migration/logs/WASPreUpgrade.horodatage.log
- répertoire_sauvegarde_migration/logs/WASPostUpgrade.horodatage.log
- racine_serveur_app/logs/clientupgrade.horodatage.log
- Recherchez le message MIGR0259I: La migration a abouti
ou MIGR0271W: La migration a abouti, avec un ou plusieurs avertissements dans l'un des fichiers journaux.
- répertoire_sauvegarde_migration/logs/WASPreUpgrade.horodatage.log
- répertoire_sauvegarde_migration/logs/WASPostUpgrade.horodatage.log
- racine_serveur_app/logs/clientupgrade.horodatage.log
Si le message MIGR0286E: La migration n'a pas abouti est affiché, essayez de corriger les problèmes en fonction des messages d'erreur consignés dans le fichier journal. Une fois toutes les erreurs rectifiées, relancez la commande à partir du répertoire bin de la racine d'installation du produit.
- Ouvrez le journal de service du serveur qui héberge la ressource à laquelle vous tentez d'accéder et parcourez les messages d'erreur et d'avertissement.
- Lorsque WebSphere
Application Server est en cours d'exécution, exécutez la commande dumpNameSpace, puis pipe, redirect ou "more" sur le résultat pour le visualiser aisément.
Cette commande a pour effet d'afficher tous les objets de l'espace nom de WebSphere Application Server, y compris le chemin de répertoire et le nom de l'objet.
- Si l'objet auquel un client doit accéder ne s'affiche pas,
utilisez la console d'administration pour vérifier que les conditions suivantes sont remplies :
- le serveur qui héberge la ressource cible est actif.
- Le module Web ou le conteneur d'EJB (Enterprise Java™ Bean) qui héberge la ressource cible est en opération.
- le nom JNDI de la ressource cible est correctement indiqué.
- Analysez les données de trace des outils de migration ou transmettez-les aux personnes appropriées qui sauront les analyser. Lorsque vous utilisez la commande WASPreUpgrade ou WASPostUpgrade, vous pouvez spécifier les paramètres suivants pour le traçage :
- -traceString
- Ce paramètre est facultatif. La valeur spéc_trace spécifie
les informations de trace que vous voulez collecter.
- Spécifiez "*=all=enabled" (entre guillemets) afin de collecter toutes les informations de trace.
Le fichier de trace généré est très gros ; il peut dépasser 1 Go pour la commande WASPostUpgrade par exemple.
- Spécifiez "Migration.*=all" afin de collecter toutes les informations de migration.
- Spécifiez "Migration.Flow=all:Migration.*=finer" afin de collecter la plupart des informations de migration.
- Spécifiez "Migration.Flow=finer:Migration.*=fine" afin de collecter le minimum de données de migration requises par les équipes de support technique.
Valeur par défaut.
- Spécifiez "*=all=enabled" (entre guillemets) afin de collecter toutes les informations de trace.
- -traceFile
- Ce paramètre est facultatif. La valeur nom_fichier spécifie le nom du fichier de sortie pour les informations de trace.
Si vous n'indiquez pas les paramètres -traceString ou -traceFile, la commande crée un fichier de trace par défaut et le place dans le répertoire répertoire_sauvegarde/logs.
Pour consulter les informations récentes disponibles sur la page de support IBM® relatives aux incidents recensés et à leurs solutions, accédez à la page IBM Support. La page IBM Support contient des documents permettant de gagner du temps lors de la collecte des informations requises pour résoudre cet incident. Avant d'ouvrir un rapport PMR, reportez-vous à la page IBM Support.
- Cherchez les fichiers journaux et parcourez-les pour trouver des explications.
- Au cours de la migration, des incidents peuvent se produire lorsque vous utilisez l'outil WASPreUpgrade ou l'outil
WASPostUpgrade.
- Des incidents peuvent se produire lors de l'utilisation de l'outil WASPreUpgrade.
- Le message Introuvable ou Fichier ou répertoire introuvable est retourné.
Cet incident peut se produire lorsque vous tentez de lancer l'outil WASPreUpgrade à partir d'un répertoire autre que Version 9.0 racine_serveur_app\bin. Vérifiez que le script WASPreUpgrade réside dans le répertoire Version 9.0 racine_serveur_app\bin et lancez le fichier à partir de cet emplacement.
- Le pilote JDBC DB2 et pilote DB2 JDBC (XA) introuvables dans la liste
déroulante des fournisseurs JDBC pris en charge, dans la console d'administration.
La console d'administration n'affiche plus les noms des fournisseurs JDBC déconseillés. Les nouveaux noms de fournisseur JDBC utilisés dans la console d'administration sont plus descriptifs et conviviaux. Les nouveaux fournisseurs ne diffèrent des anciens que par leur nom.
Les noms dépréciés sont conservés dans le fichier jdbc-resource-provider-templates.xml pour les besoins de la migration (par exemple, pour les scripts JACL existants), mais il est préférable d'utiliser les nouveaux noms de fournisseur JDBC dans vos scripts JACL.
- Le message suivant s'affiche :
MIGR0108E: The specified WebSphere directory does not contain a WebSphere version that can be upgraded.
Il existe plusieurs causes possibles :- Si WebSphere
Application Server Version 7.0 ou ultérieures est installé, vous n'avez peut être pas lancé l'outil WASPreUpgrade
à partir du répertoire bin de la racine d'installation de la Version 9.0.
- Après l'exécution de l'outil WASPreUpgrade, recherchez un message similaire au suivant : IBM WebSphere
Application Server, Edition 6.x.
Ce message indique que vous êtes en train d'exécuter l'utilitaire de migration de WebSphere Application Server Version 7.0 ou ultérieures et non celui de la Version 9.0.
- Modifiez votre variable d'environnement PATH ou changez de répertoire pour pouvoir lancer l'outil Version 9.0 WASPreUpgrade.
- Après l'exécution de l'outil WASPreUpgrade, recherchez un message similaire au suivant : IBM WebSphere
Application Server, Edition 6.x.
- Un répertoire incorrect a peut-être été indiqué au lancement de l'outil WASPreUpgrade.
- Si WebSphere
Application Server Version 7.0 ou ultérieures est installé, vous n'avez peut être pas lancé l'outil WASPreUpgrade
à partir du répertoire bin de la racine d'installation de la Version 9.0.
- Il se peut que l'outil WASPreUpgrade se ferme sans sauvegarder l'environnement précédent.
Il peut sembler s'exécuter correctement conformément à l'exemple suivant :
Un message similaire à celui de l'exemple suivant peut également figurer dans le fichier de trace de la migration :MIGR0201I: The migration function initialized log file WASPreUpgrade.log. MIGR0300I: The migration function is starting to save the existing Application Server environment. MIGR0302I: The existing files are being saved. MIGR0303I: The existing Application Server environment is saved. MIGR0420I: The first step of migration completed successfully.
[10/9/08 18:26:40:363 CDT] 00000000 Save 1 Skipped instance dmgr01 because user root /opt/migration_backup/profiles/dmgr01 does not exist.
L'outil WASPreUpgrade copie un fichier profileList.ser contenant des pointeurs désignant le répertoire de sauvegarde que l'outil WASPostUpgrade doit utiliser. Si ce fichier n'est pas ensuite supprimé par la migration, les anciens chemins d'accès sont utilisés au lieu des chemins d'accès réels lorsque vous exécutez l'outil WASPreUpgrade dans les migrations suivantes. Pour résoudre cet incident, vous pouvez supprimer le fichier profileList.ser en toute sécurité et exécuter à nouveau l'outil WASPreUpgrade.
Pour plus d'informations, voir Commande WASPreUpgrade.
Eviter les incidents: Lors de la migration d'un noeud fédéré version 6.1 vers la Version 9.0, la commande WASPreUpgrade peut échouer. Un message similaire à l'exemple suivant peut être généré :
Vous pouvez rencontrer ce problème sur un noeud WebSphere version 6.1 lorsqu'une base de données DB2 utilisant le pilote du fournisseur IBM JCC à été créée et lorsque le noeud WebSphere version 6.1 est synchronisé avec le gestionnaire de déploiement Version 9.0. La version 6.1 ne prend pas en charge la Version 7.0 ou ultérieures ou le dernier niveau de pilote. Le processus de synchronisation du noeud ne parvient pas à supprimer toutes les définitions de pilote.[07/16/2011 11:07:10:357 CDT] MIGR0344I: Processing configuration file /opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBCluster /resources.xml. [07/16/2011 11:07:10:436 CDT] org.eclipse.emf.ecore.resource.Resource$IOWrappedExcept ion: Unresolved reference 'DataSource_1310769433958'. (file:/opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBC luster/resources.xml, 9, 323) java.lang.Exception: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved reference 'DataSource_1310769433958'. (file:/opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBC luster/resources.xml, 9, 323) at com.ibm.wsspi.migration.document.wccm.WCCMDocument.setInputStream(WCCMDocument.ja va:162)
Pour résoudre ce problème, sauvegardez les fichiers resources.xml qui doivent être modifiés. Arrêtez le processus agent de noeud version 6.1. Editez les fichiers resources.xml du noeud WebSphere version 6.1 et supprimez les entrées resources.jdbc:CMPConnectorFactory orphelines avant d'exécuter la commande WASPreUpgrade. N'éditez pas la copie du gestionnaire de déploiement.
gotcha - Le message Introuvable ou Fichier ou répertoire introuvable est retourné.
- Des incidents peuvent se produire lors de l'utilisation de l'outil WASPostUpgrade.
- Après la migration d'un noeud fédéré, les journaux WASPostUpgrade peuvent contenir une exception similaire à l'exception suivante :
Cette exception est émise lors de l'opération syncNode. Elle est considérée comme une erreur alors qu'en réalité, elle n'entraîne aucun échec. L'opération aboutit et le message ne réapparaît pas. Une fois que le serveur sur le noeud fédéré est démarré, le fichier en question est régénéré. Vous pouvez ignorer ce message.MIGR0304I: The previous WebSphere environment is being restored. MIGR0367I: Backing up the current Application Server environment. CEIMI0006I Starting the migration of Common Event Infrastructure. MIGR0486I: The Transports setting in file server.xml is deprecated. MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated. MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated. MIGR0404W: Do not use the node agent in the old configuration. It has been disabled. MIGR0351I: The migration function is attempting to synchronize with the deployment manager using the SOAP protocol. MIGR0241I: Output of syncNode. ADMU0116I: Tool information is being logged in file /usr/WAS80/profiles/AppSrv01/logs/syncNode.log ADMU0128I: Starting tool with the AppSrv01 profile ADMU0401I: Begin syncNode operation for node aaixae15aNode01 with Deployment Manager packppc.rtp.raleigh.ibm.com: 8879 ADMU0016I: Synchronizing configuration between node and cell. AWXJR0006E The file, /usr/WAS80/java/jre/PdPerm.properties, was not found. ArchiveUtil.toLocalURLs ArchiveUtil.toLocalURLs ArchiveUtil.toLocalURLs ADMU0402I: The configuration for node aaixae15aNode01 has been synchronized with Deployment Manager packppc.rtp.raleigh.ibm.com: 8879 MIGR0352I: The synchronization with the deployment manager is successful. CEIMI0007I The Common Event Infrastructure migration is complete. MIGR0307I: The restoration of the previous Application Server environment is complete. MIGR0271W: Migration completed successfully, with one or more warnings.
- Le message "Introuvable" ou "Fichier ou répertoire introuvable" est retourné.
Cet incident peut se produire lorsque vous tentez de lancer l'outil WASPostUpgrade à partir d'un répertoire autre que Version 9.0 racine_serveur_app\bin. Vérifiez que le script WASPostUpgrade réside dans le répertoire Version 9.0 racine_serveur_app\bin et lancez le fichier à partir de cet emplacement.
- Le message suivant s'affiche :
MIGR0102E: Invalid Command Line. MIGR0105E: You must specify the primary node name.
La cause la plus probable de cette erreur est que WebSphere Application Server Version 7.0 ou ultérieures est installé et que l'outil WASPostUpgrade n'a pas été exécuté à partir du répertoire bin de la racine d'installation de la Version 9.0.
Pour remédier au problème, exécutez la commande WASPostUpgrade à partir du répertoire bin de la racine d'installation de la Version 9.0.
- Lorsque vous faites migrer les noeuds fédérés d'une cellule, les messages d'erreur suivants s'affichent :
MIGR0304I: The previous WebSphere environment is being restored. com.ibm.websphere.management.exception.RepositoryException: com.ibm.websphere.management.exception.ConnectorException: ADMC0009E: The system failed to make the SOAP RPC call: invoke MIGR0286E: The migration failed to complete.
Un dépassement de délai de connexion se produit lorsque le noeud fédéré tente de récupérer les mises à jour de configuration à partir du gestionnaire de déploiement pendant l'étape de migration WASPostUpgrade du noeud fédéré. La copie de la configuration complète pourrait dépasser le délai d'expiration de la connexion si la configuration que vous migrez vers la Version 9.0 contient l'un des éléments suivants :- De nombreuses applications de petite taille.
- Quelques applications de grande taille.
- Une application de très grande taille.
Ce que nous vous conseillons de faire, c'est de modifier la valeur du délai d'attente avant d'exécuter la commande WASPostUpgrade pour faire migrer un noeud fédéré.- Accédez à l'emplacement suivant dans le répertoire de la Version 9.0 correspondant au profil vers lequel vous migrez votre noeud fédéré :
profile_root/properties
- Ouvrez le fichier soap.client.props dans ce répertoire, puis trouvez la valeur de la propriété com.ibm.SOAP.requestTimeout. Il s'agit de la valeur de délai d'attente en secondes. La valeur par défaut est 180 secondes.
- Modifiez la valeur de com.ibm.SOAP.requestTimeout pour la rendre suffisamment grande pour faire migrer la configuration. Par exemple, l'entrée suivante vous donne une valeur de délai d'attente d'une demi-heure :
com.ibm.SOAP.requestTimeout=1800
Remarque : Sélectionnez la valeur de délai d'attente la plus petite qui réponde à vos besoins. Préparez-vous à attendre au moins trois fois le délai d'attente que vous avez sélectionné (une fois pour télécharger les fichiers vers le répertoire de sauvegarde, une fois pour télécharger les fichiers migrés vers le gestionnaire de déploiement et une fois pour synchroniser le gestionnaire de déploiement avec l'agent de noeud migré. - Accédez à l'endroit suivant du répertoire de sauvegarde qui a été créé par la commande WASPreUpgrade :
backupDirectory/profiles/profile_name/properties
- Ouvrez le fichier soap.client.props dans ce répertoire, puis trouvez la valeur de la propriété com.ibm.SOAP.requestTimeout.
- Modifiez la valeur de com.ibm.SOAP.requestTimeout en lui attribuant la même valeur que celle utilisée dans le fichier Version 9.0.
Une autre solution consiste à spécifier -includeApps script dans la commande WASPostUpgrade lorsque vous faites migrer le gestionnaire de déploiement vers la Version 9.0 si vous êtes dans l'une des situations suivantes (ou les deux) :- Vous voulez faire migrer rapidement tous les noeuds de la cellule. Cependant, une fois que toute la cellule sera migrée, vous voulez exécuter manuellement le script d'installation de l'application de chaque application contenue dans le répertoire de sauvegarde du gestionnaire de déploiement et synchroniser la configuration avec tous les noeuds migrés.
- Vous pouvez lancer l'exécution sans qu'aucune application ne soit installée.
Procédez comme suit pour utiliser cette autre solution :- Spécifiez -includeApps script dans la commande WASPostUpgrade lorsque vous migrez le gestionnaire de déploiement vers Version 9.0.
- Faites migrer toute la cellule vers la Version 9.0 avant d'installer une application quelconque.
- Exécutez la commande wsadmin pour installer chaque application.
- Installez les applications dans la configuration de la Version 9.0 pendant l'exploitation normale ou au cours des créneaux de maintenance appropriés.
- Indiquez -conntype NONE. Exemple :
wsadmin -f application_script -conntype NONE
- Synchronisez la configuration avec tous les noeuds migrés.
- Le message d'erreur "Impossible de copier le document dans le fichier temporaire" s'affiche. Par exemple :
MIGR0304I: The previous WebSphere environment is being restored. com.ibm.websphere.management.exception.DocumentIOException: Unable to copy document to temp file: cells/sunblade1Network/applications/LARGEApp.ear/LARGEApp.ear
Votre systèmes de fichiers est peut-être saturé. Si votre système de fichiers est saturé, faites de la place et exécutez de nouveau la commande WASPostUpgrade.
- Le message suivant s'affiche :
MIGR0108E: The specified WebSphere directory does not contain WebSphere version that can be upgraded.
Il existe plusieurs causes possibles :- Si WebSphere
Application Server version
6.1 est installé, vous n'avez peut être pas lancé l'outil WASPostUpgrade
à partir du répertoire bin de la racine d'installation de la Version 9.0.
- Après exécution de l'outil WASPostUpgrade, recherchez un message similaire au suivant : IBM WebSphere
Application Server, Edition 6.1.
Ce message indique que vous êtes en train d'exécuter l'utilitaire de migration d'une édition précédente et non celui de la Version 9.0.
- Modifiez votre variable d'environnement PATH ou changez de répertoire pour pouvoir lancer l'outil Version 9.0 WASPostUpgrade.
- Après exécution de l'outil WASPostUpgrade, recherchez un message similaire au suivant : IBM WebSphere
Application Server, Edition 6.1.
- Un répertoire incorrect a peut-être été indiqué au lancement de l'outil WASPreUpgrade ou de l'outil WASPostUpgrade.
- L'outil WASPreUpgrade n'a pas été exécuté.
- Si WebSphere
Application Server version
6.1 est installé, vous n'avez peut être pas lancé l'outil WASPostUpgrade
à partir du répertoire bin de la racine d'installation de la Version 9.0.
- Le message d'erreur suivant s'affiche :
MIGR0253E: The backup directory migration_backup_directory does not exist.
Il existe plusieurs causes possibles :- L'outil WASPreUpgrade n'a pas été exécuté avant l'outil WASPostUpgrade.
- Vérifiez si le répertoire de sauvegarde désigné dans le message d'erreur existe.
- Sinon, exécutez l'outil WASPreUpgrade.
Pour plus d'informations, voir Commande WASPreUpgrade.
- Relancez l'outil WASPostUpgrade.
- Le répertoire de sauvegarde indiqué est peut-être incorrect.
Par exemple, il est possible que le répertoire soit un sous-répertoire de l'arborescence Version 7.0 ou ultérieures, supprimé après exécution de l'outil WASPreUpgrade et désinstallation de l'ancienne version du produit, mais avant exécution de l'outil WASPostUpgrade.
- Vérifiez si la structure de répertoires complète désignée dans le message d'erreur existe ou non.
- Si possible, exécutez de nouveau l'outil WASPreUpgrade en indiquant le répertoire complet correct de sauvegarde de la migration.
- Si le répertoire de sauvegarde n'existe pas et que l'ancienne version dont il est issu n'existe plus, reconstituez l'ancienne version à partir d'un référentiel de sauvegarde ou du fichier de configuration XML.
- Relancez l'outil WASPreUpgrade.
- L'outil WASPreUpgrade n'a pas été exécuté avant l'outil WASPostUpgrade.
- Vous souhaitez exécuter de nouveau l'outil WASPreUpgrade après exécution de
la commande WASPostUpgrade.
Au cours de la migration d'un gestionnaire de déploiement ou d'un noeud fédéré, WASPostUpgrade désactive l'ancien environnement. Si, après exécution de WASPostUpgrade, vous voulez de nouveau lancer WASPreUpgrade sur l'ancienne installation, vous devez exécuter le script migrationDisablementReversal.jacl, qui se trouve dans l'ancien répertoire racine_serveur_app/bin. Une fois le script JACL exécuté, votre environnement Version 7.0 ou ultérieures sera à nouveau dans un état valide, vous permettant d'exécuter WASPreUpgrade afin de générer des résultats corrects.
- Echec d'une migration fédérée avec message MIGR0405E.La migration qui s'est effectuée sur le gestionnaire de déploiement dans le cadre de la migration fédérée a échoué. Pour des explications plus détaillées sur la cause de cet échec, ouvrez le dossier votre_nom_noeud_migration_temp situé sur le noeud du gestionnaire de déploiement dans le répertoire ...DeploymentManagerProfile/temp. Exemple :
/websphere80/appserver/profiles/dm_profile/temp/nodeX_migration_temp
Les journaux et tous les autres éléments impliqués dans le processus de migration de ce noeud sur le noeud du gestionnaire de déploiement se trouvent dans ce dossier. Ce dossier est également requis pour le support IBM relatif à ce scénario.
- Des applications de la Version 9.0 sont perdues lors de la migration.
Si l'installation d'une application de la Version 9.0 échoue lors d'une migration fédérée, cette application sera perdue lors de la synchronisation des configurations. Cette erreur se produit car l'une des dernières étapes du processus WASPostUpgrade consiste à exécuter une commande syncNode. Cette commande entraîne le téléchargement de la configuration qui se trouve sur le noeud du gestionnaire de déploiement en remplacement de celle qui se trouve sur le noeud fédéré. Si l'installation des applications échoue, ces dernières ne figurent pas dans la configuration située sur le noeud du gestionnaire de déploiement. Pour pallier cette erreur, installez manuellement les applications requises après migration. S'il s'agit d'applications Version 9.0 standard, elles seront situées dans le répertoire racine_serveur_app/installableApps.
Pour installer manuellement une application perdue pendant la migration, utilisez la commande wsadmin pour exécuter le script install_nom_application.jacl que les outils de migration ont créés dans le répertoire de sauvegarde.
Dans un environnement Linux, par exemple, utilisez les paramètres suivants :./wsadmin.sh -f migration_backup_directory/install_application_name.jacl -conntype NONE
- Les applications de la Version 9.0 ne sont pas installées.
Installez manuellement les applications à l'aide de la commande wsadmin une fois l'opération WASPostUpgrade terminée.
Pour installer manuellement une application dont l'installation a échoué lors de la migration, utilisez la commande wsadmin pour exécuter le script install_nom_application.jacl que les outils de migration ont créés dans le répertoire de sauvegarde.
Dans un environnement Linux, par exemple, utilisez les paramètres suivants :./wsadmin.sh -f migration_backup_directory/install_application_name.jacl -conntype NONE
Pour plus d'informations, voir WASPostUpgrade command.
- Après la migration d'un noeud fédéré, les journaux WASPostUpgrade peuvent contenir une exception similaire à l'exception suivante :
- Le fichier de trace dépasse l'allocation de 400 mégaoctets, mais WASPostUpgrade
est toujours en cours d'exécution. Si l'espace disque disponible est insuffisant, la migration
échoue.Si vous pensez que ce problème risque de se produire lors de la migration, procédez comme suit :
- Arrêtez l'assistant Migration avant d'émettre la commande WASPostUpgrade.
- Exécutez la commande WASPostUpgrade à partir de la ligne de commande pour chaque
profil que vous migrez.
Lorsque vous exécutez la commande WASPostUpgrade à partir de la ligne de commande :
- Ajoutez les paramètres -oldProfile et -profileName pour indiquer le profil que vous souhaitez migrer.
- Ajoutez le paramètre com.ibm.ejs.ras.TraceNLS*
à la chaîne de trace pour réduire la taille de votre journal de trace. Par exemple,
vous souhaiterez peut-être définir le paramètre de trace suivant :
com.ibm.ejs.ras.TraceNLS*=info
- Des incidents peuvent se produire lors de l'utilisation de l'outil WASPreUpgrade.
Lorsque vous utilisez l'assistant de migration pour faire migrer un profil WebSphere Application Server version 6.0.2 vers la Version 9.0 sur un système Solaris avec processeur x64, la migration peut échouer lors de l'étape WASPostUpgrade.
Des messages similaires aux messages suivants peuvent être consignés dans le fichier rép_sauvegarde_migration/logs/WASPostUpgrade.horodatage.log :MIGR0327E: A failure occurred with stopNode. MIGR0272E: The migration function cannot complete the command.
WebSphere Application Server version 6.0.2 utilise une machine virtuelle Java en mode 32 bits. L'assistant de migration de Version 9.0 appelle le script WASPostUpgrade.sh, qui tente d'exécuter la machine virtuelle Java pour la version 6.0.2 en mode 64 bits lorsque le serveur arrête le noeud de la version 6.0.2.
Exécutez les actions suivantes pour supprimer le profil incomplet et permettre à WebSphere Application Server de migrer correctement le profil de la version 6.0.2 :- A partir d'une ligne de commande, accédez au répertoire racine_serveur_app/bin. Par exemple, entrez la commande suivante :
cd /opt/IBM/WebSphere/AppServer/bin
- Localisez le script WASPostUpgrade.sh dans le répertoire racine_serveur_app/bin et faites-en une copie de sauvegarde.
- Ouvrez le script WASPostUpgrade.sh dans un éditeur et procédez
comme suit :
- Localisez la ligne de code suivante :
. "$binDir" /setupCmdLine.sh
- Insérez la ligne suivante juste après la ligne identifiée à l'étape précédente :
JVM_EXTRA_CMD_ARGS=""
- Sauvegardez les modifications.
- Localisez la ligne de code suivante :
- Utilisez la commande suivante pour supprimer le profil de la Version 9.0 incomplet créé au cours du processus de migration :
app_server_root/bin/manageprofiles.sh -delete -profileName profile_name
- Supprimez le répertoire racine_profil du profil de la Version 9.0 supprimé à l'étape précédente.
- Relancez l'assistant de migration.
- A partir d'une ligne de commande, accédez au répertoire racine_serveur_app/bin.
- Si vous choisissez d'installer les applications d'entreprise existant dans la configuration Version 7.0 ou ultérieures dans la nouvelle configuration Version 9.0, vous pouvez rencontrer certains messages d'erreur
lors de la phase d'installation d'applications de la migration.
Les applications existant dans la configuration de la Version 7.0 ou ultérieures peuvent comporter des informations de déploiement incorrectes—généralement, des documents XML non valides vu que leur validité n'a pas été suffisamment vérifiée dans les environnements d'exécution précédents de WebSphere Application Server). L'environnement d'exécution possède désormais un processus de validation d'installation d'application amélioré et ne parviendra pas à installer ces fichiers EAR syntaxiquement incorrect. Une erreur est alors générée pendant la phase d'installation d'application de WASPostUpgrade et le message d'erreur "E" s'affiche. Il s'agit d'une erreur de migration "fatale".
Si la migration échoue de cette façon dans l'installation d'application, vous pouvez effectuer l'une des actions suivantes :- Corrigez les problèmes dans les applications Version 7.0 ou ultérieures, puis effectuez de nouveau la migration.
- Poursuivez la migration et ignorez ces erreurs.
Dans ce cas, la migration n'installe pas les applications défectueuses mais effectue toutes les autres étapes de migration.
Par la suite, vous pourrez corriger les problèmes dans les applications, puis installer manuellement ces applications dans la nouvelle configuration de la Version 9.0 à l'aide de la console d'administration ou d'un script d'installation.
- Après la migration d'un noeud fédéré vers la Version 9.0, il se peut que le serveur d'applications ne démarre pas. Lorsque vous tentez de démarrer le serveur d'applications, des erreurs similaires à celles présentées dans l'exemple suivant risquent de se produire :
[5/11/06 15:41:23:190 CDT] 0000000a SystemErr R com.ibm.ws.exception.RuntimeError: com.ibm.ws.exception.RuntimeError: org.omg.CORBA.INTERNAL: CREATE_LISTENER_FAILED_4 vmcid: 0x49421000 minor code: 56 completed: No [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:198) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:139) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:460) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServer.main(WsServer.java:59) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) [5/11/06 15:41:23:197 CDT] 0000000a SystemErr R at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Modifiez le numéro de port que le serveur d'applications du noeud fédéré écoute. Si, par exemple, le gestionnaire de déploiement écoute ORB_LISTENER_ADDRESS sur le port 9101, le serveur d'applications du noeud fédéré ne doit pas écouter ORB_LISTENER_ADDRESS sur le même port. Pour résoudre le problème de cet exemple, procédez comme suit :- Dans la console d'administration, cliquez sur Serveurs d'applications > nom_serveur > Ports > ORB_LISTENER_ADDRESS .
- Changez le numéro de port ORB_LISTENER_ADDRESS en en choisissant un qui ne soit pas utilisé.
- Si la synchronisation échoue lorsque vous migrez un noeud fédéré vers la Version 9.0, il se peut que le serveur d'applications ne démarre pas. Vous pouvez rencontrer des messages similaires à ceci lors de la migration d'un noeud fédéré vers Version 9.0 :
Ces messages indiquent ceci :ADMU0016I: Synchronizing configuration between node and cell. ADMU0111E: Program exiting with error: com.ibm.websphere.management.exception.AdminException: ADMU0005E: Error synchronizing repositories ADMU0211I: Error details may be seen in the file: /opt/WebSphere/80AppServer/profiles/AppSrv02/logs/syncNode.log MIGR0350W: Synchronization with the deployment manager using the SOAP protocol failed. MIGR0307I: The restoration of the previous WebSphere Application Server environment is complete. MIGR0271W: Migration completed successfully, with one or more warnings.
- Votre gestionnaire de déploiement est à un niveau de configuration de Version 9.0.
- Le noeud fédéré que vous tentez de migrer est à un niveau de configuration de Version 9.0 dans le référentiel du gestionnaire de déploiement (y compris les applications).
- Le noeud fédéré lui-même n'est pas tout à fait complet étant donné que vous n'avez pas terminé l'opération syncNode.
- Exécutez à nouveau la commande syncNode sur le noeud pour le synchroniser avec le gestionnaire de déploiement.
Pour plus d'informations, voir Commande syncNode.
- Exécutez la commande GenPluginCfg.
Pour plus d'informations, voir Commande GenPluginCfg.
- Si vous faites migrer un gestionnaire de déploiement
vers IBM Version 9.0 à partir d'une configuration version 6.1 ayant
migré à partir d'un gestionnaire de déploiement version 5.1, il se peut que la commande syncNode
échoue sur des noeuds fédérés version 5.1 dans le cellule. Par exemple, des messages similaires aux messages suivants peuvent apparaître lorsque vous exécutez la commande syncNode sur un noeud de version 5.1 :
bash-3.00# ./syncNode.sh dmgrhostname 8879 -username MyAdminUser -password MyAdminPassword
ADMU0116I: Tool information is being logged in file /usr/WebSphere/AppServer/logs/syncNode.log ADMU0401I: Begin syncNode operation for node My511Node with Deployment Manager dmgrhostname: 8879 ADMU0111E: Program exiting with error: com.ibm.websphere.management.exception. AdminException: ADMU2092E: The node and Deployment Manager must have the same product extensions, but they do not match. The node product extension is BASE and the Deployment Manager product extension is PME. ADMU0211I: Error details may be seen in the file: /usr/WebSphere/AppServer/logs/syncNode.log ADMU1211I: To obtain a full trace of the failure, use the -trace option.
- En raison de l'ajout de l'annotation
javax.ejb.Remote dans la spécification EJB 3.0, il se peut que la compilation de certains beans
EJB 2.1 échoue si les EJB (Enterprise Java Beans) ont été conçus en vue de l'importation des packages
javax.ejb et java.rmi entiers. Des erreurs de compilation similaires
aux erreurs de l'exemple suivant peuvent survenir :
ejbModule/com/ibm/websphere/samples/trade/ejb/QuoteHome.java(17): The type Remote is ambiguous
- Lorsque vous installez WebSphere
Application Server version
6.1 et fédérez un noeud à un gestionnaire de déploiement de la Version 9.0, des messages d'exception de sécurité
inattendus et répétitifs risquent d'être émis. Les journaux system.out de l'agent de noeud contiennent les exceptions suivantes :
[7/8/08 16:41:31:416 EDT] 0000001c DefaultTokenP E HMGR0149E: An attempt to open a connection to core group DefaultCoreGroup has been rejected. The sending process has a name of wasinst101Cell01\ndrack104Node08\server1 and an IP address of /9.42.92.86. Global security in the local process is Enabled. Global security in the sending process is Enabled. The received token starts with x2>W 9 Sv?. The exception is com.ibm.websphere.security.auth.WSLoginFailedException: Validation of LTPA token failed due to invalid keys or token type. at com.ibm.ws.security.ltpa.LTPAServerObject. validateToken(LTPAServerObject.java:876) at com.ibm.ws.security.token.WSCredentialTokenMapper. validateLTPAToken(WSCredentialTokenMapper.java:1178) at com.ibm.ws.hamanager.runtime.DefaultTokenProvider. authenticateMember(DefaultTokenProvider.java:214) at com.ibm.ws.hamanager.coordinator.impl.DCSPluginImpl. authenticateMember(DCSPluginImpl.java:723) at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.ptpDiscovery. DiscoveryRcv.acceptStream(DiscoveryRcv.java:266) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor. fetchStream(PacketProcessor.java:470) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor. run(PacketProcessor.java:917)
Le gestionnaire de déploiement utilise la Version 9.0 tandis que toues les noeuds et noeuds d'alias utilisent la version 6.1. Pour résoudre cet incident, mettez à niveau tous les noeuds de la version 6.1 vers la version 6.1.0.17 ou une version ultérieure.
Les nouveaux ports enregistrés sur un agent de noeud de Version 9.0 migré sont les suivants : WC_defaulthost, WC_defaulthost_secure, WC_adminhost, WC_adminhost_secure SIB_ENDPOINT_ADDRESS, SIB_ENDPOINT_SECURE_ADDRESS ,SIB_MQ_ENDPOINT_ADDRESS, SIB_MQ_ENDPOINT_SECURE_ADDRESS. Ils ne sont pas requis par l'agent de noeud et vous pouvez les supprimer en toute sécurité.
Que faire ensuite
Si l'incident n'est pas répertorié, contactez le support technique IBM.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=tmig_troubleshoot
Nom du fichier : tmig_troubleshoot.html