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.

Supported configurations Supported configurations:

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.

sptcfg

Consideraciones 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.
  • 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.
    Una vez que haya finalizado la migración o tras haber llevado a cabo la retrotracción a la versión anterior, podrá reiniciar los servidores que interaccionan con dichos repositorios de datos aislados.
  • 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.
      • 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.

    Para obtener más información, consulte la sección "Dominios de seguridad en un entorno de versiones mixtas" de Varios dominios de seguridad.

  • 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.

    • 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.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-iseries&topic=cmig_pre
File name: cmig_pre.html