Visión general de la migración, la coexistencia y la interoperatividad

La migración a una nueva versión de WebSphere Application Server requiere considerar cuidadosamente factores tales como la edición del producto, los tipos de perfiles, la configuración del servidor y el despliegue de aplicaciones. Esta descripción general introduce los conceptos, la terminología, las herramientas y las estrategias que le ayudarán a migrar satisfactoriamente el producto.

Terminología común sobre migración

Los términos siguientes se utilizan frecuentemente para describir la migración:
  • Versión o release: una actualización del producto que incluye nuevas funciones importantes.
  • Edition: dentro de una versión, el empaquetado del producto que incluye determinados conjuntos de características. Por ejemplo, Network Deployment.
  • Perfil: un conjunto de archivos que definen el entorno de ejecución para un proceso del servidor de aplicaciones, como por ejemplo un gestor de despliegue o un servidor de aplicaciones. Los perfiles contienen la configuración para la forma cómo se comporta el servidor de aplicaciones o dónde se despliegan las aplicaciones.
  • Origen: el origen de los datos y de los objetos para la migración, como por ejemplo perfil de origen o máquina de origen.
  • Destino: el destino de los datos y de los objetos para la migración, como por ejemplo perfil de destino o máquina de destino.
  • Nodo: una agrupación de servidores gestionados o no gestionados o de clústeres de servidores. Cada nodo que está gestionado por una célula puede tener una configuración exclusiva.
  • Célula: un grupo que contiene un gestor de despliegue que gestiona uno o más nodos o configuraciones. Los nodos de la célula están federados con el gestor de despliegue. La configuración a nivel de célula es común en todos los nodos.
  • Entorno de célula de entorno: cuando el release de al menos un nodo federado sea más antiguo que el release del gestor de despliegue que gestiona la célula. Los nodos no pueden ser más de tres releases anteriores al gestor de despliegue.

Conceptos básicos sobre migración

Migración es el proceso de mover la configuración desde un release más antiguo a un release nuevo, de modo que la nueva configuración se comporte de la forma más parecida posible a la configuración antigua. La unidad principal para una migración es el perfil, que se migra en 3 pasos básicos:
  1. Tome una instantánea del perfil de origen de la instalación antigua.
  2. Cree un perfil de destino compatible en la instalación nueva.
  3. Fusione los datos de la instantánea en el perfil de destino.

La migración de una célula, que contiene el gestor de despliegue y los nodos federados, requiere una atención especial. Dado que el gestor de despliegue controla la configuración en la célula, cada nodo debe sincronizarse con el gestor de despliegue nuevo mientras se migra.

Entornos de células mixtas

Una célula puede contener nodos de distintas versiones de WebSphere Application Server. Una célula mixta de WebSphere Application Server Versión 9.0 puede contener nodos que den soporte a WebSphere Application Server Versión 9.0 y Versión 7.0 o posterior. En un entorno de células mixtas, si un miembro de una célula es de una versión anterior a la 7.0, las herramientas no podrán migrar el gestor de despliegue. El administrador deberá migrar los nodos como mínimo a la Versión 7.0 o bien deberá eliminarlos de la célula.

Un entorno de células mixtas puede darse de dos modos:
  1. Realiza la migración incremental de los nodos del sistema existente.
    1. Migra el gestor de despliegue a la Versión 9.0. El gestor de despliegue debe estar en el nivel de la versión de nodos más reciente. Si tiene nodos de la versión anterior, esta migración del gestor de despliegue crea una célula mixta en la versión más reciente de WebSphere Application Server.
    2. A continuación, cuando se migra un nodo de forma individual a esta nueva versión más reciente, la celda se convierte en una célula de la versión más reciente de WebSphere Application Server.
      Nota: Esta célula no puede estar en una versión superior a la del gestor de despliegue.
  2. Migra el gestor de despliegue a la Versión 9.0 y, a continuación, federa los nodos de las versiones más antiguas con el gestor de despliegue de la versión nueva. Esta forma de migración sólo está soportada para los nodos de la Versión 7.0 o posterior.
    1. En primer lugar, se migra el gestor de despliegue a la Versión 9.0. El gestor de despliegue debe estar en el nivel de la versión de nodos más reciente.
    2. A continuación, puede federar los nodos de la Versión 7.0 o posterior a la nueva versión del gestor de despliegue más reciente.
    Avoid trouble Avoid trouble: Este método de migración incremental deja su sistema en un entorno de células mixto con nodos administrados por un gestor de despliegue de la Versión 9.0. La planificación de la migración finalmente debe incluir las migraciones de todos los nodos al nivel de la Versión 9.0 para garantizar la administración coherente de los nodos. gotcha

Las funciones existentes seguirán funcionando en un entorno de células mixtas. Debe poder realizar operaciones razonables como, por ejemplo, ejecutar aplicaciones existentes, realizar operaciones de gestión como, por ejemplo, addNode, crear clústeres mixtos, configurar el sistema, llamar a Mbeans y desplegar aplicaciones. El soporte de la nueva función en un entorno de células mixto se puede decidir en función de cada caso, de cada función, de la prioridad y de los recursos disponibles.

Avoid trouble Avoid trouble: Cuando se ejecuta en un entorno de células mixtas, los clientes pueden encontrarse de repente en una situación en que la información de puerto sobre los miembros del clúster de destino haya quedado obsoleta. Esta situación se suele producir cuando todos los miembros del clúster tienen puertos dinámicos y se reinician durante un periodo de tiempo en el que no se han enviado solicitudes. El proceso de cliente de este estado finalmente intentará direccionar al agente de nodo para recibir los datos de puerto nuevos para los miembros del clúster, y después utilizar esos datos de puerto nuevos para volver a direccionar a los miembros del clúster.

Si se producen problemas que impidan que el cliente se comunique con el agente de nodo, o que los datos de puerto nuevos se propaguen entre los miembros del clúster y el agente de nodo, es posible que se produzcan errores de solicitud en el cliente. En algunos casos, estos errores son temporales. En otros casos, tendrá que reiniciar uno o más procesos para resolver una anomalía.

Para evitar problemas que pudieran surgir en estos casos en el direccionamiento del cliente, puede configurar puertos estáticos en miembros del clúster. Con puertos estáticos, los datos del puerto no cambian cuando un proceso de cliente obtiene información sobre los miembros de clúster. Incluso si se reinician los miembros del clúster o si se producen problemas de comunicación o propagación de datos entre procesos, los datos del puerto que conserva el cliente siguen siendo válidos. Esta solución no resuelve necesariamente la propagación de datos o los problemas de comunicación subyacentes, pero elimina los síntomas de decisiones de direccionamiento de clientes inesperadas o desiguales.

gotcha

Si no se hace una migración ni coexiste con una versión anterior de WebSphere Application Server, se ignora la instalación anterior y sólo puede ejecutar una versión cada vez, debido al conflicto en las asignaciones predeterminadas de los puertos. Puede que ambas versiones se ejecuten a la vez sin conflictos, si utiliza puertos que no sean los puertos predeterminados en una versión.

Preguntas frecuentes

¿Puedo simplemente señalar los nuevos conjuntos de datos de la Versión 9.0 de WebSphere Application Server para z/OS y reiniciar los servidores?

No. WebSphere Application Server para z/OS Versión 9.0 requiere que se migre la configuración de la Versión 7.0 o posterior al nivel de la Versión 9.0.

Tenga cuidado con los siguientes problemas al migrar a la Versión 9.0:
  • Las variables que pertenecen a aplicaciones o productos distintos de WebSphere Application Server no se migran sino que se trasladan al nuevo entorno tal cual. Por consiguiente, compruebe las actualizaciones de otros productos antes de migrar para asegurarse de que todas estas variables siguen siendo precisas después de la migración.
  • Antes de realizar la migración de la Versión 7.0 o posterior a la Versión 9.0, compruebe que no haya en vigor ninguna restricción de región (por ejemplo, límites de IEFUSI). Estas restricciones pueden producir errores de Java™ Virtual Machine (JVM) imprevisibles.
¿Cuál es el proceso básico de migración?
  1. Instale el código SMP/E para la Versión 9.0 de WebSphere Application Server para z/OS.
    • El código SMP/E contiene Installation Manager. La instalación del código SMP/E proporciona autorización para recuperar el repositorio de WebSphere y construir el código del producto WebSphere en el sistema.
  2. Utilice la Herramienta de gestión de migración de z/OS o el mandato zmmt para crear los programas de utilidad de migración que necesita para realizar la migración.
  3. Ejecute estos trabajos.

    Se crea una nueva configuración de la Versión 9.0 independiente de la configuración de la Versión 7.0 o posterior existente, que se basa en la información de configuración de la Versión 7.0 o posterior.

¿La migración es una actividad nodo por nodo?

Sí. El proceso de migración de la configuración implica la ejecución de los programas de utilidad proporcionados con cada nodo de la configuración.

Gráfico que ilustra la ejecución de los programas de utilidad proporcionados con cada nodo de la configuración.

Aunque un servidor de aplicaciones autónomo sólo tiene un nodo, es necesario migrar ese nodo. Los pasos son esencialmente los mismos que se realizan para migrar cualquier otro nodo, excepto que no tiene ningún gestor de despliegue en ejecución. Lea Migración de un servidor de aplicaciones autónomo z/OS: lista de comprobación para obtener una lista de comprobación de las actividades para migrar un nodo de servidor de aplicaciones autónomo.

¿Qué hacen los programas de utilidad de migración?

Los programas de utilidad de migración tienen las finalidades siguientes:

Tabla 1. Programas de utilidad de migración y sus objetivos . La tabla lista los diversos programas de utilidad de migración y sus objetivos.
Programa de utilidad Finalidad
BBOWMG1B (migraciones del servidor de aplicaciones autónomo)

BBOWMG1F (migraciones de nodo federado)

Permite que todos los servidores del nodo que se está migrando se configuren para iniciarse en modalidad PRR (Peer Restart and Recovery - Reinicio y recuperación por igual)

Cuando se haya completado este trabajo, deberá iniciar todos los servidores del nodo que se está migrando y esperar a que se detengan. La modalidad de proceso PRR resuelve las transacciones pendientes, borra las anotaciones cronológicas de transacción y detiene el servidor. Este trabajo no es necesario para una migración de gestor de despliegue y es opcional para configuraciones que no utilizan conectores de transacción distribuida (XA).

Este trabajo sólo es necesario si está utilizando adaptadores XA y necesita migrar las anotaciones cronológicas XA. Compruebe los proveedores de recursos en la consola de administración de la Versión 7.0 o posterior yendo a Recursos > Proveedores JDBC y comprobando si ha elegido algún proveedor XA como, por ejemplo, DB2, Apache Derby, etc.

BBOWMG2B (migraciones del servidor de aplicaciones autónomo)

BBOWMG2F (migraciones de nodo federado)

Inhabilita la modalidad PRR y devuelve todos los servidores al estado operativo normal.

No es necesario que inicie todos los servidores después de que se haya completado este trabajo. Este trabajo no es necesario para hacer una migración del gestor de despliegue y es opcional para configuraciones que no utilizan conectores XA.

Este trabajo sólo es necesario si está utilizando adaptadores XA y necesita migrar las anotaciones cronológicas XA. Compruebe los proveedores de recursos en la consola de administración de la Versión 7.0 o posterior yendo a Recursos > Proveedores JDBC y comprobando si ha elegido algún proveedor XA como, por ejemplo, DB2, Apache Derby, etc.

BBOMBHFS o BBOMBZFS (migraciones del servidor de aplicaciones autónomo)

BBOMDHFS o BBOMDZFS (migraciones del gestor de despliegue)

BBOMMHFS o BBOMMZFS (migraciones de nodo federado)

Opcional: crea un sistema de archivos y punto de montaje para la raíz de configuración de la Versión 9.0 y monta el sistema de archivos

Si desea utilizar un sistema de archivos existente para que contenga la configuración de la Versión 9.0, debe crear manualmente el punto de montaje especificado al crear la definición de migración y verificar que el sistema de archivos está montado en lugar de ejecutar este trabajo. En cualquier caso, se debe crear el sistema de archivos de configuración y el punto de montaje y montar sistema de archivos antes de continuar con la migración.

Para migraciones de servidor de aplicaciones autónomo, los siguientes programas de utilidad:
  • BBOWMG3B
  • BBOWBPRO
  • BBOWBPRE
  • BBOWBPOS
Para migraciones de gestor de despliegue, los siguientes programas de utilidad:
  • BBOWMG3D
  • BBOWDPRO
  • BBOWDPRE
  • BBOWDPOS
Para migraciones de nodo federado, los siguientes programas de utilidad:
  • BBOWMG3F
  • BBOWMPRO
  • BBOWMPRE
  • BBOWMPOS

BBOWMG3x ejecuta la migración completa del nodo de la Versión 7.0 o posterior a la Versión 9.0.

BBOWxPRO sólo crea el perfil predeterminado e inicial de WebSphere Application Server.

BBOWxPRE sólo ejecuta el proceso previo a la actualización de la migración.

BBOWxPOS sólo ejecuta los procesos posteriores a la actualización y de finalización (cambiar permiso de archivo) de la migración.

BBOMBCP (servidor de aplicaciones autónomo las migraciones)

BBOMDCP (migraciones del gestor de despliegue)

BBOMMCP (migraciones de nodo federado)

Copia los procedimientos JCL (Lenguaje de control de trabajos) generados para iniciar los servidores en la biblioteca de procedimientos especifica

Si elige que la configuración de la Versión 9.0 utilice diferentes nombres de procedimiento de inicio de JCL, este programa de utilidad actualiza la nueva configuración de la Versión 9.0, sustituyendo los nombres de JCL nuevos por los nombres que existían en la configuración original de la Versión 7.0 o posterior.

¿Dónde se deben ejecutar los trabajos de migración?

Ejecute los trabajos en el mismo sistema en el que reside el nodo que se va a migrar.

¿Qué sucede cuando se migra un nodo?

Los programas de utilidad de migración transforman el contenido del sistema de archivos de configuración de WebSphere Application Server Versión 7.0 o posterior actual y lo fusionan en un nuevo sistema de archivos de configuración de la Versión 9.0 separado.

¿Se perderá la configuración existente durante la migración?

Durante la migración, el árbol de configuración original de WebSphere Application Server Versión 7.0 o posterior no se ve afectado. Si, por algún motivo, la migración falla antes de finalizar, la configuración anterior continuará existiendo.

¿Si el nodo tiene varios servidores de aplicaciones, se migran todos ellos?

Sí. El programa de utilidad detecta todos los servidores y lo migra todo, incluido el agente de nodo. Una invocación de los programas de utilidad de migración en el nodo migra todos los servidores del nodo.

¿Se deben detener los servidores de un nodo para realizar la migración?

Sí. En una configuración de varios nodos, es posible tener otros nodos aún en ejecución. No obstante, cualquier nodo que desee migrar debe tener los servidores detenidos.

Cuando se está migrando un nodo del servidor de aplicaciones que forma parte de una configuración de WebSphere Application Server, Network Deployment, el gestor de despliegue de la Versión 9.0 migrado anteriormente para dicha célula debe estar en ejecución. Esto se debe a que parte de la migración implica el uso de la función de scripts de wsadmin para sincronizar el nodo de servidor de aplicaciones recién migrado con el gestor de despliegue. El gestor de despliegue debe estar en ejecución a fin de realizar esa sincronización.

¿Es posible tener una célula funcionando sólo con algunos de los nodos migrados y otros no?

Sí, eso es posible. WebSphere Application Server Versión 7.0 o posterior puede coexistir con la Versión 9.0 en la misma célula y en la misma partición lógica (LPAR).

¿Puede el gestor de despliegue de WebSphere Application Server para z/OS Versión 9.0 seguir comunicándose con los nodos de la Versión 7.0 o posterior?

Sí. Un gestor de despliegue que se migra al nivel de código de la Versión 9.0 puede gestionar un nodo de la Versión 7.0 o posterior. Los cambios realizados mediante la consola de administración se aplican al nodo. Recuerde los puntos siguientes:
  • Cuando se migra un gestor de despliegue a la Versión 9.0, se crea una nueva configuración primaria de laVersión 9.0. La configuración primaria de la Versión 7.0 o posterior todavía existe. No obstante, cuando el gestor de despliegue de la Versión 9.0 realiza cambios en la configuración, los cambios se efectúan en la nueva configuración primaria de la Versión 9.0 . Por lo tanto, puesto que aún es posible utilizar el código de la Versión 7.0 o posterior, los cambios realizados en la Versión 9.0 no se ven cuando se restaura el código anterior.
  • Un gestor de despliegue de la Versión 7.0 o posterior no puede gestionar un nodo de la Versión 9.0.

¿Existe alguna secuencia para realizar una migración de varios nodos?

Sí. Migre de acuerdo con la secuencia siguiente:
  1. Siempre haga la migración del gestor de despliegue primero.
  2. Entonces se pueden migrar los nodos de servidor de aplicaciones del mismo sistema que el gestor de despliegue o de otras imágenes MVS (Multiple Virtual Storage).

¿Es posible tener células de WebSphere Application Server para z/OS Versión 9.0 que coexistan con otras células de la Versión 7.0 o posterior?

Sí. Se pueden tener células de WebSphere Application Server para z/OS Versión 9.0 que coexistan con otras células de la Versión 7.0 o posterior para un sysplex o cualquier imagen de MVS proporcionada. Existen las siguientes restricciones:
  • Una célula puede contener servidores en los niveles de la Versión 7.0 o posterior.
  • Una célula puede contener nodos z/OS y no z/OS; sin embargo, el gestor de despliegue debe estar en el nivel de versión más alto de la célula y los nodos en plataformas distintas a la plataforma en que se encuentra el gestor de despliegue deben estar en la Versión 7.0 o posterior.
  • Un servidor de un nodo z/OS no se puede agrupar en clúster con un servidor de un nodo no z/OS.
  • Un LPAR puede contener más de un nodo de la misma célula.
  • Cada LPAR tiene como máximo un daemon por célula con servidores en dicho LPAR independientemente del número de nodos de dicha célula que están configurados para dicho LPAR.
  • Para un LPAR determinado, un daemon debe estar en o por encima del nivel de versión de todos los servidores de dicho LPAR que estén en la célula del daemon, independientemente del nodo.
  • Todos los servidores del mismo nodo deben estar en el mismo nivel de versión.
  • El gestor de despliegue debe estar en o por encima del nivel de versión de cualquier servidor de la célula.
  • El controlador y sus servants deben estar en el mismo nivel de versión.
  • No puede haber dos células con el mismo nombre abreviado de célula.
  • Existen otras consideraciones para células independientes, sin tener en cuenta si están en diferentes versiones del código. Por ejemplo, debe tener un punto de montaje de sistema de archivos de configuración independiente y procedimientos JCL independientes.

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-zos&topic=cmig_overview
File name: cmig_overview.html