Resolución de problemas de migración
Es posible que encuentre problemas al migrar de una versión anterior de WebSphere Application Server.
Antes de empezar

En este artículo se describe la migración de la configuración de perfil. Para migrar sus aplicaciones a la versión más reciente, utilice WebSphere Application Server Migration Toolkit. Para obtener más información, consulte Migration Toolkit en WASdev.
sptcfgProcedimiento
- El trabajo falla en el paso de verificación.
Esto indica que se ha detectado un error de configuración antes de comenzar el proceso de migración. Esto puede ser debido a que se han introducido datos incorrectos al crear los trabajos de migración o a un problema de configuración. Revise la salida de las anotaciones cronológicas para el error detectado, a continuación, corrija el error y vuelva a ejecutar. Las anotaciones cronológicas situadas en ubicación_directorio_temporal/nnnnn, donde ubicación_directorio_temporal es el valor que se ha especificado al crear los trabajos de migración (donde el valor predeterminado es /tmp/migrate) y nnnnn es un número exclusivo que se ha generado y visualizado durante la creación de los trabajos de migración, así como en JESOUT DDNAME de los pasos WROUT y WRERR de la corriente de trabajo por lotes.
- El trabajo falla después del paso de verificación.
En el caso de que se produzca una anomalía en el trabajo de migración después del paso de verificación, puede volver a ejecutar el trabajo de migración; pero, primero debe suprimir el directorio inicial de configuración de WebSphere Application Server para z/OS creado en el paso CRHOME. Éste corresponde al directorio inicial que han entrado al crear los trabajos de migración y también se puede encontrar en la variable de entorno de JCL (Lenguaje de control de trabajos) V6_HomeDir. Debido a que el procedimiento de migración crea un nuevo sistema de archivos de configuración para cada nodo que se migra, es muy sencillo suprimir la configuración y empezar de nuevo.
- Se producen problemas con una migración de nodo federado.
Un nodo federado es el nodo más complejo que migrar debido a que en la práctica son dos migraciones contenidas en una. Un nodo federado necesita una migración de la información de configuración del nodo contenida en el repositorio primario del gestor de despliegue así como de la información de configuración contenida en el nodo federado. La migración del nodo federado requiere una conexión activa con el gestor de despliegue. Si tiene habilitada la seguridad, es esencial que siga las instrucciones que se generaron al crear los trabajos de migración. El trabajo de migración se debe someter con un ID de usuario del administrador de WebSphere que se haya configurado adecuadamente para obtener conexiones seguras.
- El trabajo falla durante la fase de instalación de aplicaciones de la migración.
Si selecciona la opción para el proceso de migración para instalar las aplicaciones empresariales que existen en la configuración de la Versión 7.0 o posterior en la nueva configuración de la Versión 9.0, puede encontrar mensajes de error durante la fase de migración de la instalación de aplicación.
Las aplicaciones que existen en la configuración de la Versión 7.0 o posterior pueden tener información de despliegue incorrecta—normalmente, documentos XML no válidos que no se han validado suficientemente en entornos de ejecución anteriores de WebSphere Application Server. El tiempo de ejecución ahora tiene un proceso de validación de instalación de aplicaciones mejorado y no podrá instalar estos archivos EAR con formato incorrecto. Esto provoca una anomalía durante la fase de instalación de aplicaciones de WASPostUpgrade y genera un mensaje de error "E". Se considera un error de migración "muy grave".
Si la migración falla durante la instalación de aplicaciones, también puede llevar a cabo una de las siguientes acciones:- Corrija los problemas en las aplicaciones de la Versión 7.0 o posterior y, a continuación, vuelva a realizar la migración.
- Proceda con la migración e ignore estos errores.
- Reinicie el trabajo de migración en el paso FINISHUP para dejar que se lleven a cabo las funciones de migración que faltan.
Para hacerlo, añada el parámetro RESTART=FINISHUP a la tarjeta de trabajo y vuelva a emitir el trabajo.
- Más adelante, resuelva los problemas de las aplicaciones y, a continuación, instálelas manualmente en la nueva configuración de la Versión 9.0 mediante la consola administrativa o un script de instalación.
- Reinicie el trabajo de migración en el paso FINISHUP para dejar que se lleven a cabo las funciones de migración que faltan.
- Se producen errores de falta de espacio.
Las anotaciones cronológicas de migración se encuentran en ubicación_directorio_temporal/nnnnn, donde ubicación_directorio_temporal es el valor que se ha especificado al crear los trabajos de migración (donde el valor por omisión es /tmp/migrate) y nnnnn es un número exclusivo generado durante la creación de los trabajos de migración. Normalmente, las anotaciones cronológicas de migración requieren poco espacio. Sin embargo, si habilita el rastreo, los archivos de anotaciones cronológicas pueden ser bastante grandes. El procedimiento recomendado es que únicamente habilite el rastreo después de que se hayan encontrado problemas. Si es necesario el rastreo, intente habilitar únicamente el rastreo relacionado con el paso del proceso que se está depurando. Esto le ayudará a reducir los requisitos de espacio.
Puede habilitar el rastreo al crear los trabajos de migración utilizando la Herramienta de gestión de migración de z/OS o el mandato zmmt. Para habilitar el rastreo con el mandato zmmt, establezca las propiedades siguientes en un valor posible en el archivo de respuestas:
- zmbEnablePreUpgradeTrace
- zmbEnablePostUpgradeTrace
- zmbEnableProfileTrace
- zmbEnableScriptingTrace
Establezca zmbEnablePreUpgradeTrace y zmbEnablePostUpgradeTrace en un valor entre 0 para ningún rastreo y 4 para todo el rastreo. Establezca zmbEnableProfileTrace y zmbEnableScriptingTrace en 0 para ningún rastreo o 1 para habilitar el rastreo.
También puede cambiar las variables en el JCL (lenguaje de control de trabajos) de migración a valores adecuados en el miembro BBOWMxEV de JCL en el conjunto de datos DATA que se crea cuando se utiliza la Herramienta de gestión de migración de z/OS o el mandato zmmt para crear una definición de migración. Al modificar el JCL, establezca TraceState y profileTrace en disabled o enabled, y establezca preUpGradeTrace y postUpGradeTrace en un valor entre 0 para ningún rastreo y 4 para todo el rastreo.Nota: Para un gestor de despliegue, el nombre del miembro es BBOWMDEV; para un nodo federado, el nombre del miembro es BBOWMMEV.Durante la migración, se realiza una copia de seguridad de la configuración de la Versión 7.0 o posterior. Esta copia de seguridad pasa a ser el origen de la información que se está migrando. La ubicación de copia de seguridad por omisión es /tmp/migrate/nnnnn. Esta ubicación se puede cambiar cuando se crean los trabajos de migración. Dependiendo del tamaño del nodo que se está migrando, esta copia de seguridad puede ser bastante grande. Si el espacio temporal resulta insuficiente, tendrá que encontrar otra ubicación para esta copia de seguridad.
- Se producen errores de falta de memoria.Para mejorar el uso de la memoria, lleve a cabo las acciones siguientes:
- Edite el archivo de trabajos para evitar compartir el espacio de aplicaciones y aumentar el almacenamiento dinámico de JVM mínimo y máximo. A continuación encontrará un ejemplo de cómo editar el trabajo BBOWM3D para una migración del gestor de despliegue de forma que utilice hasta 768 MB de almacenamiento dinámico, que es más del valor predeterminado 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;
- Edite el script de migración adecuado.
Si está realizando la migración desde un sistema del que tiene acceso al sistema de archivos del controlador de solo lectura, edite los scripts WASPreUpgrade.sh y WASPostUpgrade.sh del directorio bin.
Si no puede editar el sistema del controlador de solo lectura, utilice los tres trabajos de migración en lugar del trabajo de migración único de forma que la migración se detenga después de crear el perfil y pueda editar los scripts del perfil. Si ejecuta el trabajo de migración BBOWMG3* equivale a ejecutar los tres trabajos siguientes en el orden listado:- BBOWMPRO
- BBOWMPRE
- BBOWMPOS
set PERFJAVAOPTION=-Xms256M -Xmx768M
Ahora puede continuar con la migración. Si ha decidido ejecutar los tres trabajos individuales, inicie el trabajo BBOWMPRE y, cuando se haya iniciado satisfactoriamente, (RC=0), ejecute el trabajo BBOWMPOS. Si ha editado la copia del sistema de archivos de solo lectura de los archivos script de migración, puede utilizar el trabajo BBOWMG3* correspondiente.
- Edite el archivo de trabajos para evitar compartir el espacio de aplicaciones y aumentar el almacenamiento dinámico de JVM mínimo y máximo.
- Se sobrepasa el intervalo de trabajo por lotes.
Cada instalación de z/OS es diferente respecto a las clases de trabajo y las limitaciones de tiempo. Asegúrese de que ha especificado las clases de trabajo y los valores de tiempo de espera excedido correctos en su tarjeta de trabajo.
- La migración de un gestor de despliegue o de un servidor de aplicaciones autónomo
se completa pero no se instala ninguna aplicación.Es posible que el archivo de anotaciones cronológicas muestre mensajes similares a los siguientes:
MIGR0339I: Se está desplegando la aplicación WISO_wisoadmin_war.ear utilizando el mandato wsadmin. MIGR0241I: Salida de wsadmin. Error: no se pueden asignar 268435456 bytes para GC en j9vmem_reserve_memory. JVMJ9VM015W Error de inicialización para la biblioteca j9gc23(2): No se ha podido crear instancia de almacenamiento dinámico. Se han solicitado 256 M No se ha podido crear Java virtual machine.
El problema es que el script WASPostUpgrade iniciado desde bbomigrt2.sh no tenga suficiente espacio de direcciones restantes para inicializar la Java Virtual Machine (JVM). Normalmente, esto indica que el proceso desplegado se está ejecutando en el mismo espacio de direcciones que la JVM WASPostUpgrade.
Puede utilizar la variable de entorno _BPX_SHAREAS para indicar al proceso subyacente si los procesos desplegados deben compartir el mismo espacio de direcciones que el proceso padre. El valor predeterminado (null) es NO, pero los administradores lo pueden cambiar a YES o MUST para obtener una ventaja de rendimiento porque el espacio de direcciones no necesita copiarse durante las acciones de bifurcación o despliegue.
Si el sistema tiene el problema descrito aquí, ejecute el trabajo de migración con la variable de entorno _BPX_SHAREAS establecida explícitamente en NO. Puede establecerla en el perfil de sistema (/etc/profile) o en el perfil del usuario que ejecuta el trabajo de migración. Utilice la entrada siguiente para establecer esta variable en NO:export _BPX_SHAREAS = NO
Cuando el trabajo de migración se ha completado, puede actualizar el perfil para restablecer _BPX_SHAREAS a su valor original.
- Se producen errores durante el arranque del servidor después de la migración.
Revise las instrucciones que se generaron al crear los trabajos de migración. Verifique que los procedimientos JCL se han copiado correctamente en su PROCLIB, se han creado las definiciones RACF y se han autorizado las bibliotecas de la Versión 9.0. Asegúrese de que el proceso del daemon asociado a su célula tenga el nivel adecuado. El proceso de daemon debe estar en el nivel de versión más alto de WebSphere Application Server para z/OS de todos los servidores que gestiona en la célula.
Después de la migración a una célula de la Versión 9.0 que contiene o funciona con nodos de la Versión 7.0 o posterior que no están en la versión 6.0.2.11 o posterior, la función del clúster podría fallar. Al iniciar estos servidores de aplicaciones de la Versión 7.0 o posterior, podría encontrar los siguientes problemas:- Podría ver un archivo de anotaciones cronológicas FFDC (first failure data capture) que muestra un mensaje de error de ClassNotFoundException. Esta excepción se lanza desde el método RuleEtiquette.runRules y se parece un poco al ejemplo siguiente:
Excepción = java.lang.ClassNotFoundException Source = com.ibm.ws.cluster.selection.SelectionAdvisor.<init> probeid = 133 Vuelco de pila = java.lang.ClassNotFoundException: rule.local.server en java.net.URLClassLoader.findClass(URLClassLoader.java(Compiled Code)) en com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:106) en java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) en java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) en java.lang.Class.forName1(Native Method) en java.lang.Class.forName(Class.java(Compiled Code)) en com.ibm.ws.cluster.selection.rule.RuleEtiquette.runRules(RuleEtiquette.java:154) en com.ibm.ws.cluster.selection.SelectionAdvisor.handleNotification(SelectionAdvisor.java:153) en com.ibm.websphere.cluster.topography.DescriptionFactory$Notifier.run(DescriptionFactory.java:257) en com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1462)
- Podría ver una excepción java.io.IOException con un aspecto parecido al siguiente ejemplo:
Excepción = java.io.IOException Origen= com.ibm.ws.cluster.topography.DescriptionManagerA. update probeid = 362 Vuelco de pila = java.io.IOException en com.ibm.ws.cluster.topography.ClusterDescriptionImpl.importFromStream(ClusterDescriptionImpl.java:916) en com.ibm.ws.cluster.topography.DescriptionManagerA.update(DescriptionManagerA.java:360) Causado por: java.io.EOFException en java.io.DataInputStream.readFully(DataInputStream.java(Compiled Code)) en java.io.DataInputStream.readUTF(DataInputStream.java(Compiled Code)) en com.ibm.ws.cluster.topography.KeyRepositoryImpl.importFromStream(KeyRepositoryImpl.java:193)
Avoid trouble: Después de la migración a WebSphere Application Server Versión 9.0, es posible que el tráfico JSR116 de proxy SIP (Session Initiation Protocol) falle con la retransmisión de tiempos de espera y mensajes de error. Cuando se produce este error, se emite el siguiente mensaje de error.
Para resolver este problema, puede suprimir la cadena de transporte, UDP_SIP_PROXY_CHAIN, en el archivo serverindex.xml en el nivel de nodo del servidor donde se ha producido el error. gotchaLa inicialización del canal TCP ha fallado. No se ha podido enlazar el socket para el host y el puerto 5060.
- Podría ver un archivo de anotaciones cronológicas FFDC (first failure data capture) que muestra un mensaje de error de ClassNotFoundException. Esta excepción se lanza desde el método RuleEtiquette.runRules y se parece un poco al ejemplo siguiente:
Después de la migración, revise detenidamente la salida del trabajo y los archivos de anotaciones cronológicas por si hay errores.
Si migra un nodo a la Versión 9.0 y después descubre que necesita volver a la Versión 7.0 o posterior, consulte Entornos de retrotracción.
Para obtener la información actual que está disponible en IBM® Support sobre los problemas conocidos y su resolución, lea la página IBM Support. El servicio de soporte de IBM también tiene documentos que pueden ahorrarle tiempo en la recopilación de la información necesaria para resolver este problema. Antes de abrir un PMR, consulte la página IBM Support.
Los puertos nuevos que se registran en un agente de nodo de la Versión 9.0 migrado son: 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. Estos puertos no los necesita el agente de nodos y se pueden suprimir con seguridad.
Qué hacer a continuación
Si el problema no aparece en la lista, póngase en contacto con el servicio de soporte IBM.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=tmig_troubleshoot
File name: tmig_troubleshoot.html