Consideraciones sobre la migración
Antes de empezar el proceso de migración a WebSphere Application Server Versión 9.0, hay algunas consideraciones que deberá tener en cuenta.

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.
sptcfgConsideraciones para los sistemas operativos AIX, HP-UX, IBM® i, Linux, Solaris y Windows
Tenga en cuenta la información siguiente antes de migrar el servidor de aplicaciones:- Antes de realizar la migración, evalúe los elementos en desuso en WebSphere Application Server
Versión 9.0.
Para obtener más información, consulte Características en desuso, estabilizadas, reemplazadas y eliminadas.
- El Gestor de alta disponibilidad (HAM) y las funciones del grupo principal se incluyen en WebSphere Application Server Versión 7.0 o posterior.
Consulte Consideraciones sobre la migración de grupos principales para ver las consideraciones sobre la topología y configuración de grupos principales que pueden afectar en la migración desde Versión 7.0 o posterior a la Versión 9.0.
Nota: En la mayoría de los casos, el número recomendado de servidores de un grupo principal no debe exceder de 50. Recibirá un mensaje de aviso cuando las herramientas de migración añadan un servidor que exceda el límite superior recomendado. - Las herramientas de migración de configuración no convierten las aplicaciones ni las hacen compatibles con un nuevo nivel de SDK de Java. Antes
de migrar a un nuevo SDK de Java, utilice el kit de herramientas de
migración de WebSphere Application Server para evaluar si es
necesario realizar algún cambio en las aplicaciones así como para
probarlas después de realizar las actualizaciones necesarias. Consulte Migration
Toolkit en WASdev.
Consulte Migración de las API y especificaciones para obtener más información.
- Las herramientas de migración crean un directorio de copia de
seguridad de migración que contiene una copia de seguridad de la
configuración de la versión anterior, que tiene el tamaño del
directorio de configuración y de las aplicaciones del perfil anterior
más los archivos de rastreo. Además, el sistema debe tener espacio
para el perfil de destino, que después de la migración tendrá el mismo tamaño que el perfil de origen.
La cantidad de almacenamiento que requiere el sistema para el directorio de copia de seguridad depende del entorno y también de la herramienta de migración que esté utilizando.
- Ubicación: Los directorios de copia de seguridad especificados como parámetros de los mandatos WASPreUpgrade y WASPostUpgrade commands
- Cantidad: Para obtener un cálculo estimado de los requisitos de almacenamiento cuando se utilizan estos mandatos, añada las cantidades siguientes.
- El tamaño de los elementos siguientes para todos los perfiles de la
configuración anterior:
- Directorio raíz_perfil/installableApps
- Directorio raíz_perfil/installedApps
- Directorio raíz_perfil/config
- Directorio raíz_perfil/properties
- Las bibliotecas compartidas a las que se hace referencia en los archivos de configuración libraries.xml
- Los archivos RAR (Resource adapter archive) referenciados en los archivos de configuración resources.xml
- Si el rastreo está habilitado, deje espacio suficiente para los archivos de rastreo, que depende del tamaño y de la complejidad de la configuración.
- El tamaño de los elementos siguientes para todos los perfiles de la
configuración anterior:
- Si utiliza repositorios de datos aislados, concretamente repositorios de datos no
compartidos tales como registros de transacciones para bases de datos SIB y Apache Derby,
y realiza la migración desde un release anterior, las bases de datos y registros de
transacción existentes se guardan cuando se ejecuta el mandato WASPreUpgrade. Los cambios que realice en la base de datos después de ejecutar el mandato
WASPreUpgrade no se verán reflejados en el entorno migrado.
- Si tiene información de vital importancia almacenada en estos repositorios de datos locales, debe apagar todos los servidores que interaccionen con los mismos antes de llevar a cabo la migración. Dichos servidores deben permanecer fuera de línea hasta que la migración haya finalizado por completo o se haya retrotraído correctamente.
- Si realiza varios intentos de migración, ya sea a causa de una retrotracción inesperada o de la aplicación de arreglos, ejecute de nuevo el mandato WASPreUpgrade de modo que los cambios realizados en los repositorios de datos aislados queden reflejados en el entorno migrado.
- No migre un nodo con servidores activos si SIB utiliza la opción de almacén de archivos para uno o todos los motores de mensajería.
El mandato WASPreUpgrade falla con una excepción de archivo bloqueado cuando se intentan copiar los almacenes de archivos en un servidor de aplicaciones activo.
El mandato WASPreUpgrade copia un archivo bloqueado que podría comprometer la coherencia de los datos.
Si intenta ejecutar el mandato WASPreUpgrade para realizar la migración desde la versión 6.1 con el nodo y el servidor de aplicaciones que tienen el almacén de archivos SIB en ejecución, es posible que obtenga un error parecido al siguiente:
Si luego apaga el servidor de aplicaciones y el nodo, el mandato WASPreUpgrade finaliza.C:\was80A\bin>WASPreUpgrade c:\bkupWAS6.1.0.17June30B C:\was61B MIGR0385I: Comenzando a guardar el perfil AppSrv01. MIGR0215W: La función de migración no puede copiar el archivo y abrir el archivo de destino c:\bkupWAS6.1.0.17June30B\migrated\C_\FSJune19\Log. MIGR0272E: La función de migración no ha podido completar el mandato.
- Antes de migrar una base de datos Apache Derby, asegúrese de que se han cerrado los servidores de aplicaciones que alojan aplicaciones que utilizan la base de datos Apache Derby. De lo contrario, es posible que la migración de Apache Derby dé errores.
- Debe tener en cuenta las reglas siguientes relacionadas con la migración
de dominios de seguridad:
- Si realiza la migración de un gestor de despliegue que tiene un
dominio de seguridad con un ámbito de nivel de célula, las
herramientas de migración llevan a cabo estas acciones:
- La migración crea un dominio en la nueva configuración denominado PassThroughToGlobalSecurity, si todavía no existe.
- La migración añade una correlación de clústeres a la nueva configuración para todos los
clústeres existentes en la configuración anterior.
- Las correlaciones con PassThroughToGlobalSecurity de los
clústeres que antes de la migración sólo existían en la configuración
del gestor de despliegue de la Versión 9.0 no presentan cambios.
- Si las correlaciones de los clústeres de la Versión 9.0 ya existían antes de la migración, seguirán existiendo después de ésta.
- Si antes de la migración no había ninguna correlación para los clústeres de la Versión 9.0, no habrá ninguna tras finalizar la migración.
- Si antes de llevar a cabo la migración un clúster existe tanto en la configuración anterior como en la configuración de la Versión 9.0, el clúster de la nueva configuración se añade al dominio PassThroughToGlobalSecurity y se comporta como el clúster del release anterior.
- Las correlaciones con PassThroughToGlobalSecurity de los
clústeres que antes de la migración sólo existían en la configuración
del gestor de despliegue de la Versión 9.0 no presentan cambios.
- La migración añade una correlación de buses para los buses
existentes en una configuración migrada de la versión 6.1.x.
Las correlaciones de buses se actualizan siguiendo las mismas reglas que se utilizan para las correlaciones de clústeres.
- Los servidores administrativos (gestor de despliegue) no se añaden al dominio PassThroughToGlobalSecurity.
- Si realiza la migración de un nodo federado que tiene un
dominio de seguridad con un ámbito de nivel de célula, las
herramientas de migración llevan a cabo estas acciones:
- La migración crea un dominio en la nueva configuración denominado PassThroughToGlobalSecurity, si todavía no existe.
- La migración añade una correlación de nivel de servidor al
dominio PassThroughToGlobalSecurity para todos los servidores que no
tienen clústeres de la configuración del nodo anterior.
- Los servidores del nodo que se migran que forman parte de un
clúster no reciben las entradas en el dominio
PassThroughToGlobalSecurity porque esto se lleva a cabo a través de
una correlación de clústeres durante la migración del gestor de
despliegue.
Si ha eliminado dicha correlación, la migración mantiene el comportamiento.
- Los servidores administrativos (agentes de nodo) no se añaden al dominio PassThroughToGlobalSecurity.
- Los servidores del nodo que se migran que forman parte de un
clúster no reciben las entradas en el dominio
PassThroughToGlobalSecurity porque esto se lleva a cabo a través de
una correlación de clústeres durante la migración del gestor de
despliegue.
Para obtener más información, consulte la sección "Dominios de seguridad en un entorno de versiones mixtas" de Varios dominios de seguridad.
- Si realiza la migración de un gestor de despliegue que tiene un
dominio de seguridad con un ámbito de nivel de célula, las
herramientas de migración llevan a cabo estas acciones:
- Ha cambiado el proceso para inhabilitar la solicitud de credenciales.
Para inhabilitar la solicitud de credenciales en la Versión 9.0, configure ipc.client.props para inhabilitar la solicitud de credenciales antes de migrar de la versión 6.1 a la Versión 9.0.
- Durante la migración, es posible restablecer algunos metadatos de aplicaciones por sus valores predeterminados y hacer que la aplicación funcione de forma distinta de lo previsto.
Si ha instalado una aplicación en su entorno antiguo con la opción Utilizar metadatos a partir de binarios establecida en true y durante esa instalación o una posterior actualización de la aplicación realiza algún cambio en los metadatos de la aplicación (como por ejemplo, referencias a recursos JNDI o entradas de base de datos, por ejemplo), el cambio podría perderse cuando realice la migración.
Cuando la opción Utilizar metadatos a partir de binarios se ha establecido en true, el código administrativo solamente actualiza los metadatos del archivo EAR binario. Esta opción no recibe soporte en una célula mixta; por lo tanto, automáticamente pasa a false como parte de la migración. Cuando se produce esta acción, los metadatos expandidos en los directorios de configuración tienen preferencia ante los valores del archivo EAR binario. Esto provoca que los valores de la instalación original del archivo EAR tenga preferencia sobre las actualizaciones que pudieran haberse llevado a cabo.
Realice una de las acciones siguientes para resolver este problema:- Antes de llevar a cabo una migración, actualice las aplicaciones del entorno antiguo y establezca la opción Utilizar metadatos a partir de binarios en false. Asegúrese de que las aplicaciones estén funcionando correctamente con este valor nuevo y, a continuación, ejecute la migración.
- Tras la migración, actualice las aplicaciones y corrija los metadatos según sea necesario para permitir que las aplicaciones funcionen correctamente.
- Después de utilizar las herramientas de migración para realizar la migración a la WebSphere Application Server
Versión 9.0, es posible que tenga que llevar a cabo algunas
acciones que las herramientas de migración no efectúan automáticamente.
- Examine los valores de seguridad LTPA (Lightweight Third-Party Authentication) que pueda haber utilizado en
WebSphere Application Server Versión 7.0 o posterior y asegúrese de que la seguridad de la
Versión 9.0 se haya establecido correctamente.
Consulte Lightweight Third Party Authentication para obtener más información.
- Consulte el archivo WASPostUpgrade.log en el directorio
logs para obtener detalles sobre los objetos JSP (JavaServer
Pages) que las herramientas de migración no han migrado.
Si la Versión 9.0 no soporta un nivel para el que se han configurado los objetos JSP, las herramientas de migración reconocen los objetos en la salida y los anotan cronológicamente.
- Revise los valores de la máquina virtual Java™ (JVM) para comprobar que
está utilizando un tamaño de almacenamiento dinámico de 50 como mínimo para mejorar el
rendimiento de arranque.
Para obtener más información, consulte Valores de la máquina virtual Java.
Si ha utilizado un tamaño de almacenamiento dinámico anteriormente, puede utilizar el tamaño de almacenamiento dinámico predeterminado, que es 50.
- Verifique el resultado de la migración de la base de datos Apache Derby y migrar manualmente todas las bases de datos Apache Derby que las herramientas no han migrado de forma automática.
Consulte Migración de bases de datos de Apache Derby para obtener más información.
- Examine los valores de seguridad LTPA (Lightweight Third-Party Authentication) que pueda haber utilizado en
WebSphere Application Server Versión 7.0 o posterior y asegúrese de que la seguridad de la
Versión 9.0 se haya establecido correctamente.


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