Para permitir que el producto se reinicie en un
sistema alternativo, los siguientes requisitos previos deben estar instalados en cada
sistema (en el sistema original y en todos los sistemas que vayan a participar en la
recuperación) antes de reconfigurar las políticas de ARM para habilitar el reinicio y la
recuperación por iguales.
Antes de empezar
Deprecated feature: La función de reinicio y
recuperación por igual (PRR) está en desuso. Deberá utilizar el soporte de alta
disponibilidad integrado para el subcomponente de servicio de transacciones, en lugar del
Reinicio y recuperación por igual para la recuperación de transacciones. Consulte el tema
Soporte de transacciones en
WebSphere Application Server para obtener más información sobre
el soporte de alta disponibilidad integrado del subcomponente de
servicio de transacciones y sobre cómo configurarlo para la recuperación de igual de las transacciones que se estén procesando en un servidor de
aplicaciones que falla.
depfeat
Asimismo debe asegurarse de que todos los sistemas, en los que deba llevar a cabo el
reinicio, sean parte del mismo grupo de registro de RRS.
- z/OS Versión
1.2 o posterior
- BCP APAR OA01584
- RRS APAR OA02556 y OA2556
- WebSphere Application Server Versión 5 o posterior
La instalación de las actualizaciones del servicio de requisito previo en todos
estos sistemas no supondrá el sacrificio del entorno actualmente en ejecución si desea
continuar y sólo reiniciar cada uno en su lugar. Sin embargo, si no instala este servicio, existe la posibilidad de que el controlador no
pueda retroceder. OTS intentará reiniciarse en sistema alternativo y no lo conseguirá. Si cuando esto sucede hay algún UR no resuelto con RRS, el controlador no podrá
reiniciarse en el sistema inicial hasta que RRS se cancele en el sistema alternativo. Si desea más información sobre OTS y RRS, consulte z/OS MVS Programming: Resource
Recovery.
Si no piensa utilizar el reinicio y la recuperación por igual, no
necesita cumplir con estos requisitos previos funcionales.
Por el contrario, el sistema
utilizará la función de reinicio en su lugar.
Todos los siguientes productos
soportan RRS. Individualmente, también soportan el reinicio y la recuperación por igual, siempre que estén adecuadamente instalados todos los requisitos
previos indicados anteriormente:
- DB2 Versión
7 o posterior
- IMS Versión
8 o posterior
- CICS Versión
1.3 o posterior
- MQSeries Versión 5.2 o posterior
Además de los productos anteriores, muchos JTA XAResource Managers pueden
utilizarse para ofrecer asistencia en operaciones de reinicio y recuperación por igual del producto.
Consulte la documentación de JTA XAResource Manager para determinar si soporta el
reinicio en un sistema alternativo.
Avoid trouble: Cuando configure la
política de ARM para un sysplex, asegúrese de que ambos sistemas tengan el
mismo nivel de servidor de aplicaciones instalado. Por ejemplo, no puede utilizar un servidor de aplicaciones que esté
ejecutando
WebSphere Application Server Versión 5.1 para
realizar un reinicio y recuperación por igual para un servidor de
aplicaciones que esté ejecutando
WebSphere Application Server Versión 6.0.1.
gotcha
Antes de utilizar las funciones de reinicio y recuperación por igual:
- Debe asegurarse de que el daemon de servicio de ubicación y el agente de nodo ya se
encuentran en ejecución en todos los sistemas que pueden utilizarse para la recuperación.
De lo contrario, el sistema en recuperación puede intentar recuperarse en un sistema que
no está ejecutando el daemon de servicio de ubicación y el agente de nodo. Si eso sucede, el servidor no conseguirá iniciarse y no se completará la recuperación.
Los clientes notarán el impacto en el rendimiento si los sistemas están
ejecutándose a toda su capacidad. En un intento de minimizar el impacto en la memoria y la CPU del sistema alternativo, los
contenedores de enterprise bean y web no se reinician para los servidores que se ejecutan en
modalidad de reinicio por iguales. Esto significa que los servidores de aplicaciones que se encuentran en el proceso de
recuperación no podrán aceptar ningún trabajo entrante.
Acerca de esta tarea
Después de
instalar los requisitos previos, al iniciar un servidor en un sistema en el que no se ha
configurado, el servidor se pone implícitamente en modalidad de reinicio y recuperación
por igual. Si ha configurado el archivo de registro
XA Partner para que se escriba en un HFS no compartido, o si está utilizando un gestor de recursos JTA
XA, tendrá que realizar los pasos siguientes antes de iniciar un servidor:
Procedimiento
- (Necesario sólo si está utilizando un HFS no compartido.) Habilitar el soporte
de HFS no compartido. Si utiliza un HFS no compartido, los valores de configuración deben
replicarse en los distintos sistemas del sysplex. Esta operación la
realizan automáticamente los agentes de nodo y de gestor de despliegue. Para habilitar este soporte, cada agente de nodo de la configuración debe establecerse
como nodo de recuperación. Este cambio se realiza en la consola de administración:
- En la navegación de la consola administrativa, seleccione .
- Seleccione un agente de nodo de la lista.
- En la sección Propiedades adicionales, seleccione Servicio de sincronización de archivos.
- En la sección Propiedades adicionales, seleccione .
- Seleccione .
- Especifique recoveryNode como Nombre y true como
Valor. El campo Descripción puede permanecer en
blanco.
- Repita los pasos 3-7 para cada agente de nodo de su configuración.
- Guarde la configuración.
- (Necesario sólo si está utilizando gestores JTA XAResource.)
Asegúrese de que
las clases y los archivos de registro pertinentes estén disponibles en el
sistema alternativo Si tiene intención de utilizar las funciones de reinicio y
recuperación por igual y las aplicaciones tienen acceso
a gestores JTA XAResource, debe garantizar que las clases y los archivos de registro pertinentes estén disponibles en el sistema alternativo.
- Dirija la variable del producto TRANLOG_ROOT a un HFS compartido. La variable TRANLOG_ROOT debe apuntar a un HFS compartido, en el que todos los
sistemas de la célula pueden grabar. El registro de socios XA se almacenan aquí, y el sistema alternativo
debe ser capaz de leer y actualizar estas anotaciones cronológicas.
- En la consola administrativa, pulse nombre_servidor.
- En Servicios de contenedor, pulse Servicio de transacciones.
- Especifique el directorio del HFS compartido en el campo Directorio de archivo de registro de transacciones.
- Almacene el controlador (por ejemplo, un controlador JDBC, un proveedor de
JMS o un adaptador de recursos JCA, etc.) para cada gestor JTA XAResource de un HFS
con acceso de lectura para todos los sistemas de la célula. Por ejemplo, si el conector es un controlador JDBC para una base de
datos, es posible que el controlador se almacene en un HFS de sólo lectura accesible para
todos los sistemas del sysplex. Esto permite al sistema alternativo leer la classpath guardada para el recurso y
reconstruirla durante un reinicio.
Si el conector utilizado para acceder a un gestor JTA XAResource no se almacena en un
HFS al que tengan acceso de lectura todos los sistemas que pueden utilizarse en la
recuperación, cuando se reinicia un servidor de aplicaciones en un sistema alternativo,
parecerá que no hay ningún trabajo de recuperación de XA que realizar, o bien, que es
imposible cargar las clases necesarias para comunicarse con el gestor JTA XAResource.
- Resuelva las unidades InDoubt.
Durante una recuperación,
habrá instancias en las que sea necesaria la intervención manual para resolver
unidades InDoubt. Necesitará utilizar paneles de RRS para esta
intervención manual.