Diseño de un daemon del supervisor de fallos

Las implementaciones del tipo de recurso con DSDL suelen tener un daemon del supervisor de fallos con las responsabilidades siguientes.

• Supervisar periódicamente el estado de la aplicación gestionada. Este aspecto concreto de un daemon de supervisor depende enormemente de cada aplicación y puede variar mucho de un tipo de recurso a otro. DSDL tiene ciertas funciones útiles integradas para realizar comprobaciones de estado para servicios sencillos basados en TCP. Las aplicaciones que implementan protocolos basados en ASCII, como HTTP, NNTP, IMAP y POP3, pueden implementarse con estas utilidades.

• Mantener un seguimiento de los problemas que encuentra la aplicación al utilizar las propiedades de recurso Retry_interval y Retry_count. Cuando se producen fallos completos de la aplicación, decidir si la secuencia de acción de PMF debería reiniciar el servicio o si los fallos de la aplicación se han acumulado con tanta rapidez que se debería plantear la posibilidad de una recuperación de fallos. Las utilidades scds_fm_action() y scds_fm_sleep() de DSDL están diseñadas para ayudar a implementar este mecanismo.

• Tomar las medidas adecuadas (generalmente, reiniciar la aplicación o intentar una operación de recuperación de fallos del grupo de recursos que lo contiene). La utilidad scds_fm_action() de DSDL implementa este algoritmo. Para ello, calcula la acumulación actual de fallos de análisis en los últimos Retry_interval segundos.

• Actualizar el estado del recurso para que el estado de funcionamiento esté disponible para la orden scstat así como para la GUI de gestión del clúster.

Las utilidades de DSDL están diseñadas de modo que el bucle principal del daemon del supervisor de fallos se pueda representar con el siguiente pseudocódigo.

Para los supervisores de fallos implementados con DSDL:

• La detección de la terminación de los procesos de una aplicación con scds_fm_sleep() es bastante rápida, porque la notificación de la terminación del proceso a través de PFM es asíncrona. Contrasta esta situación con el caso en el que un supervisor de fallos se activa con una frecuencia determinada para comprobar el estado del servicio y se encuentra con que la aplicación se ha terminado. El tiempo de detección del fallo se reduce de manera notable y se aumenta, por tanto, la disponibilidad del servicio.

• Si RGM rechaza el intento de realizar una operación de recuperación de fallos del servicio con la API scha_control(3HA), scds_fm_action() pone a cero (olvida) el historial actual de fallos. La razón es que éste ya está por encima de Retry_count y si el daemon supervisor despierta en la siguiente iteración y no puede completar satisfactoriamente la comprobación del funcionamiento del daemon, intentaría invocar la llamada scha_control() de nuevo, lo que seguramente seguiría siendo rechazado ya que la situación que condujo a su rechazo en la última iteración sigue siendo válida. Al poner a cero el historial se garantiza que el supervisor de fallos intentará al menos corregir localmente la situación (por ejemplo, mediante un reinicio de la aplicación) en la próxima iteración.

• scds_fm_action() no pone a cero el historial de fallos de la aplicación cuando se producen fallos de reinicio, porque normalmente se intentaría utilizar scha_control() muy pronto si la situación no se corrigiera por sí sola sola.

• La utilidad scds_fm_action() actualiza el estado del recurso a SCHA_RSSTATUS_OK, SCHA_RSSTATUS_DEGRADED o SCHA_RSSTATUS_FAULTED, según el historial de fallos. Este estado queda disponible para la gestión del sistema de clúster.

En la mayoría de los casos, la acción de comprobación del estado específico de la aplicación se puede implementar en una utilidad autónoma separada (por ejemplo, svc_probe()) y se puede integrar con este bucle principal genérico.

for (;;) {

   / * reposo durante un intervalo thorough_probe_interval entre
   * análisis sucesivos. */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));

   /* Analizar ahora todas las direcciones ip que se usan.
   * Recorrer:
   * 1. Todos los recursos de red que usamos.
   * 2. Todas las direcciones ip de un recurso determinado.
   * Para cada una de las direcciones ip analizadas,
   * calcular el historial de fallos. */
   probe_result = 0;
   /* Iterar todos los recursos para obtener todas las
    * direcciones IP para invocar svc_probe() */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Anotar el nombre del sistema y puerto en los que
   * se debe supervisar el estado.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS sólo admite un puerto; por tanto,
   * obtener el valor de puerto de la primera
   * entrada de la matriz de puertos.
   */
   ht1 = gethrtime(); /* Bloquear tiempo de inicio de análisis */
   probe_result = svc_probe(scds_handle,

   hostname, port, timeout);
   /*
   * Actualizar historial de análisis,
   * tomar medidas si fuera necesario.
   * Bloquear tiempo de finalización de análisis.
   */
   ht2 = gethrtime();
   /* Convertir a milisegundos */
   dt = (ulong_t)((ht2 - ht1) / 1e6);

   /*
   * Calcular historial de fallos y tomar
   * medidas si fuera necesario
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Cada recurso de red */
   }       /* Seguir analizando para siempre */