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
- 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
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.
- Realiza la migración incremental de los nodos del sistema existente.
- 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.
- 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.
- 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.
- 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.
- 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: 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.

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.
gotchaSi 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.
¿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.
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:
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:
Para migraciones de gestor de despliegue,
los siguientes programas de utilidad:
Para migraciones de nodo federado,
los siguientes programas de utilidad:
|
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?
¿Existe alguna secuencia para realizar una migración de varios nodos?
¿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?