Alta disponibilidad de transacciones

La alta disponibilidad del servicio de transacciones permite a cualquier servidor de un clúster recuperar la tarea de transacciones de otro servidor del mismo clúster. Este recurso forma parte de la estrategia general de alta disponibilidad (HA) de WebSphere Application Server.

[z/OS]Esta característica se suma al soporte de reinicio y recuperación iguales, que le permite reiniciar en un sistema igual del sysplex.

Como parte vital de la provisión de recuperación para transacciones, el servicio de transacciones anota cronológicamente información sobre el trabajo de transacciones activo en el archivo de registro de recuperación de transacciones. El archivo de registro de recuperación de transacciones almacena la información de forma persistente, lo que significa que cualquier tarea de transacciones en curso en el momento de una anomalía en el servidor puede resolverse cuando se reinicie el servidor. Esta actividad se conoce como proceso de recuperación de transacciones. Además de completar las transacciones pendientes, este proceso también garantiza que se liberen los bloqueos mantenidos en los gestores de recursos asociados.

Proceso de recuperación de igual

El proceso de recuperación estándar que se lleva a cabo cuando se reinicia un servidor de aplicaciones sirve para que el servidor recupere y procese la información de transacciones que ha anotado cronológicamente, recupere las tareas transaccionales y complete las transacciones dudosas. La finalización de las tareas de transacciones (y en consecuencia la liberación de los puntos muertos de la base de datos retenidos por las transacciones) se realiza una vez que el servidor se ha reiniciado satisfactoriamente y ha procesado el registro de transacciones. Si el servidor se recupera con lentitud o precisa intervención manual, las tareas de transacciones no pueden completarse y se interrumpe el acceso a las bases de datos asociadas.

Para minimizar esas interferencias en las tareas de transacciones y las bases de datos asociadas, WebSphere Application Server proporciona una estrategia de alta disponibilidad conocida como recuperación de igual de transacciones.

Se proporciona la recuperación de igual dentro de un clúster de servidores. Un servidor de igual (otro miembro del clúster) puede procesar los registros de recuperación de un servidor anómalo mientras el servidor de igual continúa gestionando su propia carga de trabajo de transacciones. No es necesario esperar a que se reinicie el servidor anómalo, ni iniciar un nuevo servidor de aplicaciones específicamente para que recupere el servidor que ha sufrido la anomalía.

Figura 1. Recuperación por igual
La recuperación por igual en un clúster de servidores. Se muestra el servidor 1 antes y después de iniciar el proceso de recuperación de los servidores con anomalía 2 y 3.

El proceso de recuperación de igual es el equivalente lógico del reinicio del servidor anómalo, pero no constituye un reinicio completo del servidor anómalo en el servidor igual. El proceso de recuperación de igual ofrece una oportunidad para completar el trabajo pendiente; no puede empezar un nuevo trabajo más allá del proceso de recuperación. No es posible ningún proceso de reenvío para el servidor anómalo.

La recuperación de igual aleja los requisitos de alta disponibilidad de los servidores individuales y los conduce al clúster de servidores. Después de este tipo de anomalías, el sistema de gestión del clúster asigna tareas nuevas a los restantes servidores; la única diferencia es la posible disminución en el rendimiento general del sistema. Si un servidor sufre una anomalía, lo único necesario es que se encargue de las tareas activas en el servidor anómalo y redirija las solicitudes a un servidor alternativo.

De forma predeterminada, la recuperación de igual está inhabilitada hasta que se habilita la migración tras error de la recuperación de registro de transacciones en la configuración del clúster y se reinician los miembros del clúster. Una vez que se ha habilitado la recuperación de registro de transacciones, WebSphere Application Server soporta dos estilos para la iniciación de la recuperación de igual de transacciones: automático y manual. Determine qué estilo es más adecuado, en función del de despliegue y especifique dicho estilo configurando la política de alta disponibilidad adecuada. En el resto de estos temas se hará referencia a esta política de alta disponibilidad como política del servicio de transacciones.
Recuperación de igual automática
Este estilo es el valor predeterminado para la iniciación de recuperación de igual. Si falla un servidor de aplicaciones, WebSphere Application Server selecciona automáticamente un servidor para que realice en su nombre el proceso de recuperación de igual y vuelve a pasar la recuperación al servidor anómalo cuando éste se reinicia. Para utilizar este modelo, habilite la recuperación de registro cronológico de transacciones y configure la ubicación de registro cronológico de recuperación para cada miembro de clúster.
Recuperación de igual manual
Este estilo de recuperación de igual se debe configurar explícitamente. Si un servidor de aplicaciones falla, utilice la consola de administración para seleccionar un servidor que realice el proceso de recuperación en su nombre.

En un entorno HA, debe configurar los registros cronológicos de compensación así como los registros cronológicos de transacción. Para cada servidor de clúster, utilice los valores de servicio de compensación para configurar una ubicación de registro cronológico de compensación exclusiva y asegúrese de que todos los miembros del clúster pueden acceder a esos registros cronológicos de compensación.

Ejemplo de recuperación de igual

Los siguientes diagramas ilustran el proceso de recuperación de igual que tiene lugar si un solo servidor sufre una anomalía. En la figura 2 se muestran tres servidores estables ejecutándose en un clúster de WebSphere Application Server. La carga de trabajo está equilibrada entre estos servidores y, como resultado, los bloqueos se retienen en la base de datos de programa de fondo en nombre de cada uno de ellos.

Figura 2. Clúster de servidores en ejecución, antes de la anomalía del servidor
Esta figura describe el clúster de servidores antes del error del servidor.

En la figura 3 se muestra el estado del sistema una vez que se ha producido una anomalía en el servidor 1 sin eliminar los bloqueos de la base de datos. Los servidores 2 y 3 consiguieron pueden sus transacciones existentes y liberar los bloqueos en la base de datos de programas de fondo, pero los accesos subsiguientes pueden deteriorarse a causa de los bloqueos que se mantienen en nombre del servidor 1. En la práctica, sigue siendo posible algún nivel de acceso entre los servidores 2 y 3, suponiendo que se cuenta con una granularidad de bloqueo adecuadamente configurada, pero en este ejemplo se considera que los servidores 2 y 3 intentan acceder a los registros bloqueados y se han bloqueado.

Figura 3. El servidor 1 falla. En consecuencia, los servidores 2 y 3 se bloquean
Esta figura muestra el bloqueo de los servidores 2 y 3 como resultado de que falla el servidor 1.

En la figura 4 se muestra un proceso de recuperación de igual para el servidor 1 que se ejecuta en el interior del servidor 3. La porción del servicio de transacciones del proceso de recuperación recupera la información que almacenado el servidor 1 y la utiliza para finalizar las transacciones dudosas. En esta figura, el proceso de recuperación de igual se ha completado parcialmente ya que algunos bloqueos siguen retenidos por la base de datos en nombre del servidor 1.

Figura 4. El proceso de recuperación de igual iniciado en el servidor 3
Esta figura muestra el proceso de recuperación de igual en el servidor 3

En la figura 5 se muestra el estado del clúster de servidores cuando se ha completado el proceso de recuperación de igual. El sistema se encuentra en un estado estable sólo con dos servidores, entre los que se equilibra la carga de trabajo. El servidor 1 puede reiniciarse y no tendrá que realizar ningún proceso de recuperación propio.

Figura 5. El clúster de servidores se estabiliza otra vez con sólo dos servidores: servidor 2 y servidor 3
Esta figura muestra la estabilidad del clúster de servidores de los servidores 2 y 3.

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