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
- Le travail échoue à l'étape de vérification.
Cela indique qu'une erreur de configuration a été détectée avant le commencement du processus de migration. L'erreur peut être due à la saisie de données incorrectes lorsque vous avez créé les travaux de migration ou à un problème de configuration. Pour plus d'informations sur l'erreur, consultez la sortie du journal, puis corrigez l'erreur et relancez l'exécution. Les journaux sont situés dans emplacement_répertoire_temporaire/nnnnn, où emplacement_répertoire_temporaire est la valeur que vous avez spécifiée lors de la création des travaux de migration (la valeur par défaut étant /tmp/migrate) et nnnnn est un numéro unique, généré et affiché durant la création de vos travaux de migration ; il est également affiché dans le JESOUT DDNAME des étapes WROUT et WRERR de votre flux de travaux par lots.
- Le travail échoue à l'étape de vérification.
En cas d'échec du travail de migration après l'étape de vérification, vous pouvez exécuter à nouveau ce travail ; toutefois, vous devez au préalable supprimer le répertoire de base créé pour la configuration WebSphere Application Server for z/OS au cours de l'étape CRHOME. Il s'agit du répertoire de base que vous avez indiqué lors de la création des travaux de migration et qui est également défini dans la variable d'environnement V6_HomeDir du JCL de migration. Etant donné que la procédure de migration crée un système de fichiers de configuration pour chaque noeud en cours de migration, la suppression de la configuration et sa recréation de toutes pièces est un processus simple.
- Des incidents liés à la migration d'un noeud fédéré se produisent.
Un noeud fédéré est le noeud le plus difficile à migrer car cela entraîne un double migration. Il convient de migrer les informations de configuration du noeud contenues dans le référentiel principal de déploiement, ainsi que celles contenues dans le noeud fédéré. La migration de noeud fédéré requiert une connexion active vers le gestionnaire de déploiement. Si la sécurité est activée, il est indispensable de suivre les instructions qui ont été générées lorsque vous avez créé les travaux de migration. Le travail de migration doit être soumis à l'aide d'un ID utilisateur d'administrateur WebSphere configuré en vue de l'obtention de connexions sécurisées.
- Le travail échoue à l'étape de l'installation d'application de migration.
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 des 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.
- Redémarrez le travail de migration dans l'étape FINISHUP pour que les fonctions de migration restantes soient effectuées.
Pour cela, ajoutez le paramètre RESTART=FINISHUP à la fiche de travail et en soumettant de nouveau le travail.
- 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.
- Redémarrez le travail de migration dans l'étape FINISHUP pour que les fonctions de migration restantes soient effectuées.
- Des erreurs d'espace insuffisant surviennent.
Les journaux de migration sont situés dans emplacement_répertoire_temporaire/nnnnn, où emplacement_répertoire_temporaire est la valeur que vous avez spécifiée lors de la création des travaux de migration (la valeur par défaut étant /tmp/migrate) et nnnnn est un numéro unique ayant été généré durant la création de vos travaux de migration. En temps normal, ces journaux requièrent peu d'espace disque. Toutefois, si vous activez le traçage, leur taille risque d'augmenter. Il est conseillé d'activer le traçage uniquement si des erreurs ont été détectées. Si le traçage est requis, activez cette fonction uniquement à l'étape du processus qui est en cours de débogage. Cela contribue à réduire l'espace disque requis.
Vous pouvez activer le traçage lorsque vous créez les travaux de Migration à l'aide de z/OS Migration Management Tool ou de la commande zmmt. Pour activer le traçage avec la commande zmmt, définissez une valeur possible pour les propriétés suivantes dans le fichier de réponses :
- zmbEnablePreUpgradeTrace
- zmbEnablePostUpgradeTrace
- zmbEnableProfileTrace
- zmbEnableScriptingTrace
Définissez une valeur entre 0 (aucun traçage) et 4 (traçage complet) pour zmbEnablePreUpgradeTrace et zmbEnablePostUpgradeTrace. Définissez la valeur 0 (désactivation du traçage) ou 1 (activation du traçage) pour zmbEnableProfileTrace et zmbEnableScriptingTrace.
Vous pouvez également modifier les variables du fichier JCL (Job Control Language) de la migration et leur affecter des valeurs appropriées dans le membre JCL BBOWMxEV, dans le jeu de données DATA qui est créé quand vous utilisez l'outil z/OS Migration Management Tool ou la commande zmmt pour générer une définition de migration. Lors de la modification du JCL, définissez disabled ou enabled pour TraceState et profileTrace ; définissez également une valeur comprise entre 0 (aucun traçage) et 4 (traçage complet) pour preUpgradeTrace et postUpgradeTrace.Remarque : Dans le cas d'un gestionnaire de déploiement, le nom du membre est BBOWMDEV ; dans le cas d'un noeud fédéré, le nom du membre est BBOWMMEV.Durant la migration, une copie de sauvegarde de votre configuration Version 7.0 ou ultérieures est créée. Cette copie constitue alors la source des informations en cours de migration. L'emplacement par défaut de la sauvegarde est /tmp/migrate/nnnnn. Vous pouvez indiquer un autre emplacement au moment où vous créez les travaux de migration. Selon la taille du noeud en cours de migration, cette copie de sauvegarde peut être assez importante. Si l'espace temporaire n'est pas adapté, vous devez déplacer la copie de sauvegarde.
- Des erreurs de saturation de mémoire surviennent.Pour améliorer l'utilisation de la mémoire, effectuez les opérations suivantes :
- Editez votre fichier de travail afin d'empêcher le partage de l'espace de l'application et augmentez les valeurs minimale et maximale du segment de mémoire de la machine virtuelle Java. Vous trouverez ci-après un exemple d'édition du travail BBOWM3D pour une migration de gestionnaire de déploiement en vue de l'utilisation d'un segment de mémoire de 768 Mo, dont la taille est supérieure à la taille par défaut de 256.
BPXBATCH SH + export _BPX_SHAREAS=NO; + export IBM_JAVA_OPTIONS="-Xms256M -Xmx768M"; + /wit/bigtmp/bbomigrt2.sh WASPreUpgrade + /wit/bigtmp/24173105/_ + 1>> /wit/bigtmp/24173105/BBOWMG3D.out + 2>> /wit/bigtmp/24173105/BBOWMG3D.err;
- Editez le script de migration approprié.
Si vous procédez à la migration à partir d'un système à partir duquel vous avez accès au système de fichiers du pilote en lecture seule, éditez les scripts WASPreUpgrade.sh et WASPostUpgrade.sh qui se trouvent dans le répertoire bin.
Si vous ne pouvez pas éditer le système du pilote en lecture seule, utilisez les trois travaux de migration (à la place du travail de migration unique) pour que la migration s'interrompe après la création du profil afin que vous puissiez éditer les scripts du profil. L'exécution du travail de migration BBOWMG3* équivaut à l'exécution des trois travaux suivants dans l'ordre indiqué :- BBOWMPRO
- BBOWMPRE
- BBOWMPOS
set PERFJAVAOPTION=-Xms256M -Xmx768M
A présent, vous pouvez poursuivre la migration. Si vous avez décidé d'exécuter les trois travaux individuels, lancez le travail BBOWMPRE et une fois qu'il a abouti (RC=0), exécutez le travail BBOWMPOS. Si vous avez édité la copie du système de fichiers en lecture seule des fichiers de script de migration, vous pouvez exécuter le travail BBOWMG3* approprié.
- Editez votre fichier de travail afin d'empêcher le partage de l'espace de l'application et augmentez les valeurs minimale et maximale du segment de mémoire de la machine virtuelle Java.
- Dépassement de délai des travaux par lots.
Les classes de travaux et les limitations de durée sont différentes pour chaque installation z/OS. Vérifiez que ces éléments sont correctement définis dans la carte du travail.
- La migration d'un gestionnaire de déploiement ou d'un serveur d'applications autonome se termine mais aucune application n'est installée.Le fichier journal peut afficher des messages tels que :
MIGR0339I: Application WISO_wisoadmin_war.ear is deploying using the wsadmin command. MIGR0241I: Output of wsadmin. Error: unable to allocate 268435456 bytes for GC in j9vmem_reserve_memory. JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap. 256M requested Could not create the Java virtual machine.
L'incident est lié au fait que le script WASPostUpgrade lancé à partir de bbomigrt2.sh ne dispose pas d'espace adresse restant suffisant pour initialiser la machine virtuelle Java (JVM). Cette situation indique généralement que le processus engendré s'exécute dans le même espace adresse que la machine JVM WASPostUpgrade.
Vous pouvez utiliser la variable d'environnement _BPX_SHAREAS pour indiquer au processus sous-jacent si les processus engendrés doivent partager ou non le même espace adresse que le processus parent. La valeur par défaut (null) est NO, mais les administrateurs peuvent la modifier par YES ou MUST pour obtenir des gains de performance car il n'est pas nécessaire de copier l'espace adresse lors de fourches ou d'actions relatives à l'engendrement.
Si le problème décrit ici survient sur votre système, exécutez la migration avec la variable d'environnement _BPX_SHAREAS définie explicitement sur NO. Vous pouvez la définir dans le profil (/etc/profile) ou dans le profil utilisateur exécutant la migration. Utilisez l'entrée suivante pour définir cette variable sur NO :export _BPX_SHAREAS = NO
Une fois la migration effectuée, vous pouvez mettre à jour le profil pour qu'il redéfinisse _BPX_SHAREAS à sa valeur d'origine.
- Des échecs se produisent lors du démarrage du serveur après la migration.
Passez en revue les instructions qui ont été générées lorsque vous avez créé les travaux de migration. Vérifiez que les procédures JCL ont été copiées correctement vers PROCLIB, que les définitions RACF ont été créées et que les bibliothèques Version 9.0 ont été autorisées. Vérifiez que le processus du démon associé à la cellule est au niveau approprié. Le processus du démon doit être au niveau de version de WebSphere Application Server for z/OS le plus élevé de tous les serveurs dont il assure la gestion dans la cellule.
Après la migration vers une cellule de la Version 9.0 contenant ou interagissant avec des noeuds de la Version 7.0 ou ultérieures qui ne sont pas au niveau de la version 6.0.2.11 ou ultérieure, la fonction de cluster risque d'échouer. Lorsque vous démarrez ces serveurs d'applications Version 7.0 ou ultérieures, vous risquez de rencontrer les problèmes suivants :- Il se peut que vous voyez le message d'erreur ClassNotFoundException dans un journal FFDC (First Failure Data Capture). Cette exception est lancée à partir de la méthode RuleEtiquette.runRules et ressemble sensiblement à l'exemple suivant :
Exception = java.lang.ClassNotFoundException Source = com.ibm.ws.cluster.selection.SelectionAdvisor.<init> probeid = 133 Stack Dump = java.lang.ClassNotFoundException: rule.local.server at java.net.URLClassLoader.findClass(URLClassLoader.java(Compiled Code)) at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:106) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at java.lang.Class.forName1(Native Method) at java.lang.Class.forName(Class.java(Compiled Code)) at com.ibm.ws.cluster.selection.rule.RuleEtiquette.runRules(RuleEtiquette.java:154) at com.ibm.ws.cluster.selection.SelectionAdvisor.handleNotification(SelectionAdvisor.java:153) at com.ibm.websphere.cluster.topography.DescriptionFactory$Notifier.run(DescriptionFactory.java:257) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1462)
- Il se peut que vous voyiez une exception java.io.IOException ressemblant sensiblement à l'exemple suivant :
Exception = java.io.IOException Source = com.ibm.ws.cluster.topography.DescriptionManagerA. update probeid = 362 Stack Dump = java.io.IOException at com.ibm.ws.cluster.topography.ClusterDescriptionImpl.importFromStream(ClusterDescriptionImpl.java:916) at com.ibm.ws.cluster.topography.DescriptionManagerA.update(DescriptionManagerA.java:360) Caused by: java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java(Compiled Code)) at java.io.DataInputStream.readUTF(DataInputStream.java(Compiled Code)) at com.ibm.ws.cluster.topography.KeyRepositoryImpl.importFromStream(KeyRepositoryImpl.java:193)
Eviter les incidents: Après la migration vers WebSphere Application Server Version 9.0, il se peut que le trafic JSR116 de proxy SIP (Session Initiation Protocol) échoue avec des dépassements de délai de retransmission et des messages d'erreur. Dans ce cas, le message d'erreur suivant est émis :
Pour résoudre cet incident, vous pouvez supprimer la chaîne de transport UDP_SIP_PROXY_CHAIN dans le fichier serverindex.xml au niveau du noeud du serveur sur lequel l'erreur s'est produite. gotchaTCP Channel initialization failed. The socket bind failed for host and port 5060.
- Il se peut que vous voyez le message d'erreur ClassNotFoundException dans un journal FFDC (First Failure Data Capture). Cette exception est lancée à partir de la méthode RuleEtiquette.runRules et ressemble sensiblement à l'exemple suivant :
Après la migration, recherchez des erreurs éventuelles dans la sortie du travail et les fichiers journaux.
Si vous faites migrer un noeud vers Version 9.0, puis réalisez que vous devez revenir à la Version 7.0 ou ultérieures, reportez-vous à la rubrique Rétromigration des environnements.
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.
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-zos&topic=tmig_troubleshoot
Nom du fichier : tmig_troubleshoot.html