Diseño de un daemon del supervisor de fallos

Las implementaciones de tipos de recursos que utilizan DSDL disponen generalmente de un daemon del supervisor de fallos que lleva a cabo las siguientes acciones:

• Supervisa periódicamente el estado de la aplicación que se está administrando. La responsabilidad específica de un daemon del supervisor depende en gran medida de la aplicación y puede variar sustancialmente de un tipo de recurso a otro. DSDL contiene algunas funciones de utilidad integradas que realizan comprobaciones de estado de los servicios basados en TCP. Puede emplear estas utilidades para implementar aplicaciones que utilicen protocolos basados en ASCII como, por ejemplo, HTTP, NNTP, IMAP y POP3.

• Realiza un seguimiento de los problemas detectados por la aplicación mediante el uso de las propiedades de recursos Retry_interval y Retry_count . Si falla por completo la aplicación, el supervisor de fallos debe determinar si la secuencia de acción de PMF debe reiniciar el servicio o si los fallos de la aplicación se han acumulado de forma tan rápida que es necesario realizar una recuperación ante fallos. Las utilidades scds_fm_action() y scds_fm_sleep() de DSDL están diseñadas para ayudarle en la implementación de este mecanismo.

• Lleva a cabo acciones, normalmente el reinicio de una aplicación o una recuperación ante fallos del grupo de recursos. La utilidad scds_fm_action () de DSDL implementa este algoritmo. Esta utilidad calcula la acumulación actual de fallos de análisis durante los segundos indicados en Retry_interval para este fin.

• Actualiza el estado del recurso con el fin de que el estado de la aplicación esté disponible para el comando scstat, así como para la GUI de administración del clúster.

Las utilidades de DSDL están diseñadas para que el seudocódigo incluido al final de esta sección pueda representar al bucle principal del daemon del supervisor de fallos.

Tenga en cuenta los siguientes factores al implementar un supervisor de fallos con DSDL:

• scds_fm_sleep() detecta rápidamente la inactividad de un proceso de la aplicación porque la notificación sobre esta condición que se realiza mediante PMF es asíncrona. Por lo tanto, se reduce de forma significativa el tiempo de detección de fallos, aumentando de esta forma la disponibilidad del servicio. También es posible que se active un supervisor de fallos con la suficiente frecuencia como para comprobar el estado de un servicio y descubir que el proceso se encuentra inactivo.

• Si RGM rechaza el intento de realizar una recuperación ante fallos del servicio con la API de scha_control, scds_fm_action() restablecerá, o simplemente olvidará, el historial de fallos actual. Esta función restablece el historial de fallos actual porque éste supera el valor de Retry_count. Si, en la ocasión siguiente, el daemon del supervisor se activa y es incapaz de completar satisfactoriamente la comprobación de estado, intentará de nuevo llamar a la función scha_control(). Es muy probable que esta llamada sea rechazada una vez más, ya que la situación que provocaba el rechazo en la ocasión anterior aún está vigente. Al restablecer el historial, se garantiza que el supervisor de fallos intentará al menos corregir la situación de forma local (por ejemplo, mediante el restablecimiento de la aplicación) la próxima vez.

• scds_fm_action() no restablece el historial de fallos de la aplicación en caso de producirse fallos de reinicio, ya que, por lo general, es recomendable emitir rápidamente la función scha_control() si la situación no se soluciona automáticamente.

• La utilidad scds_fm_action() actualiza el estado del recurso a SCHA_RSSTATUS_OK, SCHA_RSSTATUS_DEGRADED o SCHA_RSSTATUS_FAULTED en función del historial de fallos. Por lo tanto, este estado está disponible para la administración del sistema de clúster.

En la mayoría de los casos, se puede implementar una comprobación de estado de la aplicación en una utilidad independiente (por ejemplo, svc_probe()). Puede integrarla en el siguiente bucle principal genérico.

for (;;) {
   /* sleep for a duration of thorough_probe_interval between
   *  successive probes.
   */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));
   /* Now probe all ipaddress we use. Loop over
   * 1. All net resources we use.
   * 2. All ipaddresses in a given resource.
   * For each of the ipaddress that is probed,
   * compute the failure history. 
   */
   probe_result = 0;
   /* Iterate through the all resources to get each
   * IP address to use for calling svc_probe()
   */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Grab the hostname and port on which the
   * health has to be monitored.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS supports only one port and
   * hence obtaint the port value from the
   * first entry in the array of ports.
   */
   ht1 = gethrtime();
   /* Latch probe start time */
   probe_result = svc_probe(scds_handle, hostname, port, timeout);
   /*
   * Update service probe history,
   * take action if necessary.
   * Latch probe end time.
   */
   ht2 = gethrtime();
   /* Convert to milliseconds */
   dt = (ulong_t)((ht2 - ht1) / 1e6);
   /*
   * Compute failure history and take
   * action if needed
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Each net resource */
   }       /* Keep probing forever */