Servidores de alta disponibilidad

Los servidores de alta disponibilidad se ejecutan de forma ligeramente distinta a los servidores individuales.

Todos los servidores utilizan la misma base de datos y una compartición de archivos común. La compartición de archivo se utiliza para los registros y algunos otros directorios, específicamente: logs, var/email, var/plugins y var/repository. Cada servidor también mantiene de forma independiente cierta información de configuración, como puertos y hosts. La base de datos se utiliza para la información de configuración, datos de tiempo de ejecución, etc.

Dado que los servidores comparten la base de datos, todos los servidores se ejecutan en el mismo intervalo.

Algunas propiedades de configuración permanecen en el servidor, como la información de conexión JMS y de base de datos. La configuración de base de datos se gestiona durante la instalación del producto; no se necesita configuración adicional posterior a la instalación.

Importación de archivos (CodeStation)

Todos los servidores realizan un sondeo en busca de cambios de versión de componente. Los intervalos de sondeo se especifican mediante un parámetro configurado por el usuario (15 minutos de forma predeterminada). La base de datos gestiona la sincronización del servidor: antes de que escriba en el repositorio, un servidor adquiere un bloqueo en la base de datos. Los tiempos de sondeo se restablecen cuando finaliza un trabajo.

Sucesos

Los sucesos los gestiona el servidor que desencadena el suceso.

Motor de flujo de trabajo

Los flujos de trabajo constan de actividades. Las actividades se pueden ejecutar de forma secuencial, en paralelo unas con otras, o una combinación de las dos. Un flujo de trabajo típico consta de varias actividades secuenciales, como:

En comunicaciones basadas en JMS, los agentes se pueden configurar de varias formas:

Todos los servidores realizan sondeos de forma constante en busca de flujos de trabajo pendientes, por lo que cualquier servidor podría iniciar el flujo de trabajo. El servidor que adquiera este flujo de trabajo ejecuta las tareas siguientes:

  1. Crear una instancia de tiempo de ejecución de la actividad A y adquirir un bloqueo de base de datos.
  2. Registrar el mandato que tiene intención de enviar en la base de datos.
  3. Enviar el mandato al agente sobre JMS.
  4. Liberar el bloqueo de base de datos.

Después de que finalice el trabajo, el agente envía un mensaje de respuesta sobre JMS. El mensaje se escribirá en la base de datos (por medio de uno de los servidores) y se iniciará la siguiente actividad (por medio de uno de los servidores). El servidor que ha iniciado la actividad B, ejecuta los mismos pasos descritos anteriormente.

En el flujo de trabajo simple que se describe aquí, es posible que el mismo servidor gestione todas las actividades o que lo hagan servidores distintos (o alguna combinación). Por supuesto, esto se aplicaría también si el flujo de trabajo constase de tres actividades paralelas.

Un único registro en la base de datos mantiene un flujo de trabajo de aplicación (sólo una hebra puede gestionar un flujo de trabajo al mismo tiempo).

Error en la gestión

Durante el proceso de la aplicación, los errores del mandato se marcan en el flujo de trabajo. La gestión de errores es responsabilidad del autor de la aplicación. La retrotracción de componentes puede gestionarse con pasos o con el mandato de retrotracción. La retrotracción, según se usa aquí, implica reinstalar una versión anterior del componente.

Si el servidor se cuelga mientras un agente está ejecutando un mandato, la maya JMS asigna el flujo de trabajo a otro servidor.

Si un agente se cuelga o, en otro caso, desaparece mientras se está ejecutando un mandato (recuerde que los pasos erróneos no hacen que fallen los agentes propiamente dichos), el servidor supone que el mandato todavía se está ejecutando; no existe ningún tiempo de espera automático. Normalmente, no es posible ni es factible asignar un intervalo de tiempo de espera.


Comentarios