Correlación de las configuraciones durante la migración de configuraciones de producto

Durante la migración de las configuraciones del producto se correlacionan diferentes configuraciones.

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

La migración siempre implica migrar un perfil individual a otro perfil individual en el mismo servidor IBM i. Las herramientas de migración correlacionan objetos y atributos existentes en la versión o WebSphere Application Server desde donde está realizando la migración a los objetos y atributos correspondientes del entorno de la Versión 9.0.

Existen muchos escenarios de migración posibles. Las herramientas de migración correlacionan objetos y atributos existentes en la versión o en la versión desde la que está realizando la migración con los objetos y atributos correspondientes del entorno de la Versión 9.0.

Puerto de rutina de carga

Las herramientas de migración transportan el valor de release anterior al entorno de la Versión 9.0.

Sin embargo, si el parámetro -setPorts se establece en generateNew o un valor de puerto durante la llamada a WASPostUpgrade, el valor de puerto se asigna a cada servidor de aplicaciones que se migra a la Versión 9.0.

Parámetros de línea de mandatos

Las herramientas de migración convierten los parámetros de línea de mandatos apropiados en valores JVM (Java™ Virtual Machine) en la definición de proceso de servidor. La mayoría de valores se correlacionan directamente. Algunos valores no se migran porque sus roles en la configuración de WebSphere Application Server Versión 9.0 no existen, tienen significados diferentes o tienen ámbitos diferentes.

Para obtener información sobre cómo cambiar los valores de definición de proceso, consulte Valores de definición de proceso. Para obtener información sobre cómo cambiar los valores de JVM, consulte Valores de la máquina virtual Java.

Servidor genérico
En Versión 7.0 o posterior, un servidor genérico tiene su propio tipo, denominado GENERIC_SERVER. La migración realizará esta conversión, pero la migración no puede migrar con precisión los recursos externos a los que hace referencia el servidor genérico. Cuando la migración termine de migrar los valores del servidor genérico, es posible que deba realizar tareas adicionales. Si el recurso antiguo que estaba gestionando el servidor genérico está en la instalación anterior de WebSphere Application Server, realice las siguientes tareas:
  1. Copie cualquier archivo relacionado en la nueva instalación.
  2. Ejecute cualquier configuración necesaria para volver a poner la aplicación externa en un estado válido y operativo.

    Se recomienda que reinstale el recurso en el nuevo directorio deWebSphere Application Server. Sea cual sea la opción que elija, el último paso es restablecer la referencia a la nueva ubicación de la aplicación.

Si el recurso antiguo que el servidor genérico estaba gestionando no está instalado bajo la instalación antigua de WebSphere Application Server, no es necesario realizar nada más.

Migración de un nodo de la Versión 7.0 o posterior a un nodo de la Versión 9.0

Puede migrar un nodo de WebSphere Application Server Versión 7.0 o posterior que pertenece a una célula sin eliminar el nodo de la célula.

Migre primero el gestor de despliegue antes de migrar los nodos base de la célula.

Importante: Utilice el mismo nombre de célula cuando migre WebSphere Application Server, Network Deployment de Versión 7.0 o posterior a Versión 9.0. Si utiliza otro nombre de célula, los nodos federados no se migrarán correctamente a la célula de WebSphere Application Server, Network Deployment Versión 9.0.

Al hacer la migración de un nodo de WebSphere Application Server base que está dentro de una célula a la Versión 9.0 también se migrará el agente de nodo a la Versión 9.0. Una célula puede tener algunos nodos de la Versión 9.0 y otros nodos que estén en los niveles de la Versión 7.0 o posterior.

Archivos de políticas
WebSphere Application Server Versión 9.0 migra todos los archivos de políticas que se han instalado con Versión 7.0 o posterior fusionando los valores en los archivos de políticas de la Versión 9.0 con las características siguientes:
  • Los comentarios ubicados en los archivos de políticas de la Versión 9.0 se conservarán. Cualquier comentario contenido en los archivos de políticas de Versión 7.0 o posterior no se incluirá en el archivo de la Versión 9.0.
  • La migración no intentará fusionar los permisos o entradas grant; es estrictamente una migración de tipo adición. Si el permiso o la entrada grant no se encuentra en el archivo de la Versión 9.0, la migración lo mostrará.
  • La seguridad es un componente crítico; por este motivo, la migración realiza las adiciones al final de los archivos .policy originales justo después del comentario MIGR0372I: A continuación se indican los permisos concedidos migrados. Esto ayuda a los administradores a verificar los cambios de archivo de políticas que ha realizado la migración.
Directorios de propiedades y clases

La migración copia archivos de los directorios de versiones anteriores en la configuración de la Versión 9.0 de WebSphere Application Server.

Archivos de propiedades

La WebSphere Application Server Versión 9.0 migra todos los archivos de propiedades que se han instalado con Versión 7.0 o posterior fusionando los valores en los archivos de propiedades de la Versión 9.0.

Archivos RAR (Resource Adapter Archive) a los que se hace referencia en los recursos J2C

Los RAR a los que se hace referencia en los recursos J2C se migran si esos RAR están en la instalación antigua de WebSphere Application Server. En este caso, los RAR se copian en la ubicación correspondiente en la nueva instalación de WebSphere Application Server. Los RAR del adaptador de recursos relacional no se migrarán.

Migración de recursos a nivel de clúster:
La versión 6.0 de WebSphere Application Server introducía el concepto de recursos de nivel de clúster. Estos se configuran en los archivos recursoxxx.xml bajo los directorios de clúster. Por ejemplo:
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

Si tiene un recurso de nivel de clúster, este recurso debe estar en la misma ubicación de cada miembro de clúster (nodo). Por lo tanto, utilizando el ejemplo anterior, cada miembro de clúster debe tener el archivo RAR instalado en la ubicación ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} se resuelve en cada miembro del clúster para obtener la ubicación exacta.

En la migración de un gestor de despliegue, las herramientas migran los archivos de clúster del gestor de despliegue, incluidos los archivos recursoxxx.xml.

En la migración de un nodo federado, las herramientas procesan cada adaptador J2C.

Migración de los archivos RAR de una versión 7.0 a la Versión 9.0:

La migración de la versión 7.0 a la Versión 9.0 copia los archivos como RAR desde WAS_INSTALL_ROOT a WAS_INSTALL_ROOT y desde USER_INSTALL_ROOT a USER_INSTALL_ROOT.

Por ejemplo, si tiene un archivo RAR en la variable WAS_INSTALL_ROOT de la versión 7.0, las herramientas de migración no copian el archivo automáticamente de WAS_INSTALL_ROOT a USER_INSTALL_ROOT. Esto mantiene la integridad de los recursos J2C de nivel de clúster.

No obstante, si ha codificado una vía de acceso en un archivo RAR (por ejemplo, archivePath="C:/WAS/installedConnectors/x2.rar") de la versión 7.0, las herramientas de migración de la Versión 9.0 no pueden modificar el atributo archivePath para reflejarlo, ya que esto rompería todos los demás miembros de clúster que no se han migrado.
Ejemplos

No hay disponible ninguna migración de los ejemplos de versiones anteriores. Existen ejemplos equivalentes de la Versión 9.0 de WebSphere Application Server que se pueden instalar.

Seguridad

La seguridad de Java 2 se habilita de forma predeterminada cuando se habilita la seguridad en la Versión 9.0 de WebSphere Application Server. La seguridad de Java 2 requiere que los permisos se otorguen de manera explícita.

Existen varias técnicas que puede utilizar para definir diferentes niveles de seguridad de Java 2 en la Versión 9.0. Una consiste en crear una archivo was.policy como parte de la aplicación para habilitar todos los permisos de seguridad. Las herramientas de migración llaman al mandato wsadmin para añadir un archivo was.policy existente en el directorio properties de la Versión 9.0 a las aplicaciones de empresa a medida que se migran.

Al migrar a WebSphere Application Server Versión 9.0, la opción de si desea o no migrar para dar soporte a la compatibilidad de scripts da un resultado de los dos diferentes.
  • Si opta por migrar para dar soporte a la compatibilidad de scripts, la configuración de seguridad se migra a la Versión 9.0 sin cambios.

    Este es el valor predeterminado.

  • Si opta por no migrar para dar soporte a la compatibilidad de scripts, la configuración de seguridad se convierte a la configuración predeterminada de la Versión 9.0 de WebSphere Application Server. La configuración de seguridad por omisión para Versión 7.0 o posterior actúa casi del mismo modo que en las versiones anteriores, pero hay algunos cambios.

    Por ejemplo, los archivos de claves y de confianza existentes se extraen del repertorio SSLConfig y se crean nuevos objetos de almacén de claves y de almacén de confianza.

Para obtener más información sobre cómo migrar las configuraciones de seguridad a la Versión 9.0, lea el artículo "Migración, coexistencia e interoperatividad – Consideraciones sobre seguridad" en la documentación.

Directorios stdin, stdout, stderr, de desactivación y de trabajo

La ubicación de estos directorios es generalmente el directorio logs bajo el directorio de perfil de WebSphere Application Server. Para WebSphere Application Server Versión 9.0, la ubicación predeterminada para los archivos stdin, stdout y stderr es el directorio logs ubicado en el directorio de perfil de WebSphere Application Server; por ejemplo, el directorio logs para el perfil predeterminado es /QIBM/UserData/WebSphere/AppServer/V80/Base/profiles/default/logs.

Las herramientas de migración intentan migrar los directorios de desactivación y de trabajo existentes. De lo contrario, se utilizan los valores predeterminados correspondientes de la Versión 9.0.

Avoid trouble Avoid trouble: En un caso de ejemplo de coexistencia, la utilización de directorios comunes entre versiones puede ocasionar problemas.gotcha
Módulos web

El nivel de especificación de Java Platform, Enterprise Edition (Java EE) implementado en WebSphere Application Server Versión 7.0 requería cambios de comportamiento en el contenedor web para establecer el tipo de contenido. Si un grabador de servlets por omisión no establece el tipo de contenido, el contenedor web no sólo deja de tomar ese valor predeterminado, sino que devuelve la llamada como "nula". Esta situación puede hacer que algunos navegadores muestren incorrectamente los distintivos de contenedor web resultantes. Para evitar que se produzca este problema, la migración establece la extensión autoResponseEncoding de IBM® en "true" para los módulos web cuando migra aplicaciones de empresa.


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_configmap
File name: cmig_configmap.html