Control del servicio de datos

Un servicio de datos debe proporcionar un método Start o Prenet_start para activar el daemon de la aplicación en el clúster y un método Stop o Postnet_stop para detener el daemon de la aplicación en el clúster. El servicio de datos de ejemplo implementa los métodos Start y Stop. Consulte Elección de los métodos Start y Stop que se van a utilizar para obtener información sobre cuándo puede ser recomendable utilizar Prenet_start y Postnet_stop en su lugar.

Método Start

RGM invoca el método Start en un nodo de clúster cuando el grupo de recursos que contiene el recurso de servicio de datos se pone en línea en ese nodo o cuando el grupo de recursos ya está en línea y se activa el recurso. En la aplicación de ejemplo, el método Start activa el daemon in.named (DNS) en ese nodo.

En esta sección se describe los principales fragmentos del método Start para la aplicación de ejemplo, pero no las funciones comunes a todos los métodos de rellamada, como la función parse_args() ni la obtención del recurso syslog; éstos se describen en Funciones comunes para todos los métodos.

Para obtener una lista completa del método Start, consulte Método Start.

Información general sobre Start

Antes de intentar ejecutar el DNS, el método Start del servicio de datos de ejemplo comprueba si el directorio y el archivo de configuración (named.conf) están accesibles y disponibles. La información que contiene named.conf es esencial para que el DNS funcione correctamente.

Este método de rellamada utiliza la función de supervisión de procesos (pmfadm) para iniciar el daemon de DNS (in.named). Si éste sufriera una caída o no pudiera iniciarse, PMF intentaría iniciarlo un número de veces predeterminado durante un intervalo de tiempo definido, ambos especificados por las propiedades del archivo RTR del servicio de datos.

Comprobación de la configuración

Para funcionar, el DNS necesita información del archivo named.conf, en el directorio de configuración. En consecuencia, el método Start realiza varias comprobaciones de estado para verificar que el directorio y el archivo estén accesibles antes de intentar ejecutar el DNS.

La propiedad de extensión Confdir proporciona la ruta al directorio de configuración. La propiedad en sí se define en el archivo RTR. Sin embargo, el administrador del clúster especifica la ubicación real al configurar el servicio de datos.

En el servicio de datos del ejemplo, el método Start recupera la ubicación del directorio de configuración con la función scha_resource_get().

Dado que Confdir es una propiedad de extensión, scha_resource_get() devuelve tanto el tipo como el valor. La orden awk recupera sólo el valor y lo pone en una variable del shell, CONFIG_DIR.

# Buscar el valor de Confdir definido por el administrador del sistema al
# agregar el recurso.
config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Confdir`

# scha_resource_get devuelve el "tipo" y el "valor" de las
# propiedades de extensión. Obtener sólo el valor de la propiedad de extensión
CONFIG_DIR=`echo $config_info | awk '{print $2}'`

El método Start utiliza a continuación el valor de CONFIG_DIR para verificar que el directorio esté accesible. Si no lo está, Start registra un mensaje de error y cierra con un estado de error. Consulte Estado de salida de Start.

# Comprobar si $CONFIG_DIR está accesible.
if [ ! -d $CONFIG_DIR ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} El directorio $CONFIG_DIR falta o no está montado"
   exit 1
fi

Antes de iniciar el daemon de la aplicación, este método realiza una comprobación final para verificar que el archivo named.conf esté presente. Si no lo esta, Start registra un mensaje de error y sale con un estado de error.

# Cambiar al directorio $CONFIG_DIR si hay nombres
# de ruta relativas en los archivos de datos.
cd $CONFIG_DIR

# Comprobar que el archivo named.conf esté presente en el directorio $CONFIG_DIR
if [ ! -s named.conf ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} El archivo $CONFIG_DIR/named.conf falta o está vacío"
   exit 1
fi

Inicio de la aplicación

Este método utiliza el recurso de gestor de procesos (pmfadm) para ejecutar la aplicación, ya que permite fijar el número de veces que se reiniciará la aplicación durante un marco temporal definido. El archivo RTR contiene dos propiedades, Retry_count, que especifica el número de veces que se intentará reiniciar una aplicación, y Retry_interval, que especifica el periodo de tiempo durante el cual se harán los intentos.

El método Start recupera los valores de Retry_count y Retry_interval con la función scha_resource_get() y guarda sus valores en variables del shell y después los pasa a pmfadm con las opciones -n y -t.

# Obtener el valor para el recuento de reintentos del archivo RTR.
RETRY_CNT=`scha_resource_get -O Retry_Count -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`
# Obtener el valor para el intervalo de reintentos del archivo RTR. Este valor se
# indica en segundos y se debe convertir a minutos para pasarlos a pmfadm. Observe
# que la conversión se redondea hacia arriba: 50 segundos se convierte en 1 minuto.
((RETRY_INTRVAL=`scha_resource_get -O Retry_Interval -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME` / 60))

# Iniciar el daemon in.named bajo el control de PMF. Deje que se produzca una caída
# y que se reinicie $RETRY_COUNT veces en un periodo de $RETRY_INTERVAL; si se cae
# más a menudo, PMF dejará de intentar reiniciarlo. Si hay algún proceso ya
# registrado con la etiqueta <$PMF_TAG>, PMF enviará un mensaje de alerta
# indicando que el proceso ya está en ejecución.
pmfadm -c $PMF_TAAG -n $RETRY_CNT -t $RETRY_INTRVAL \
    /usr/sbin/in.named -c named.conf

# Registrar un mensaje que indique que se ha iniciado HA-DNS.
if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS iniciado satisfactoriamente"
fi
exit 0

Estado de salida de Start

Un método Start no debería salir satisfactoriamente hasta que la aplicación subyacente estuviera en ejecución y disponible, especialmente si hay otros servicios de datos que dependen de él. Una forma de comprobar si la salida será la correcta es consultar la aplicación para verificar que esté en ejecución antes de salir del método Start. En el caso de una aplicación compleja, como una base de datos, fije una valor suficientemente alto para la propiedad Start_timeout en el archivo RTR para permitir que la aplicación tenga tiempo de inicializarse y realizar una recuperación de una caída.

Dado que el recurso de aplicación, DNS, en el servicio de datos de ejemplo se ejecuta con rapidez, el servicio de datos de ejemplo no lo interroga para verificar que se esté ejecutando antes de salir de forma satisfactoria.

Si este método no logra iniciar el DNS y sale con un estado de fallo, RGM comprueba la propiedad Failover_mode, que determina el modo de reaccionar. El servicio de datos de ejemplo no fija explícitamente la propiedad Failover_mode, por lo que esta propiedad tiene el valor predeterminado NONE (salvo que el administrador del sistema haya anulado el valor predeterminado y haya especificado otro). En este caso, RGM no realiza ninguna acción, salvo fijar el estado del servicio de datos. La intervención del usuario es necesaria para que se produzca un reinicio en el mismo nodo o una operación de recuperación de fallos en un nodo diferente.

Método Stop

El método Stop se invoca en un nodo del clúster cuando el grupo de recursos que contiene el recurso HA-DNS se pone fuera de línea en ese nodo o si el grupo de recursos está en línea y se inhabilita el recurso. Este método detiene el daemon in.named (DNS) en ese nodo.

Esta sección describe los principales fragmentos del método Stop para la aplicación de ejemplo, pero no las funciones comunes a todos los métodos de rellamada, como la función parse_args() ni la obtención del recurso syslog; éstos se describen en Funciones comunes para todos los métodos.

Para obtener una lista completa del método Stop, consulte Método Stop.

Información general sobre Stop

Hay que tener presentes dos consideraciones fundamentales a la hora de intentar detener el servicio de datos. La primera es proporcionar un apagado ordenado. Enviar una señal de SIGTERM mediante pmfadm es la mejor forma de lograrlo.

La segunda consideración es garantizar que el servicio de datos se haya detenido realmente para evitar ponerlo en el estado Stop_failed. La mejor forma de hacerlo es enviar una señal de SIGKILL mediante pmfadm.

El método Stop del servicio de datos de ejemplo tiene presentes ambas consideraciones. Primero envía una señal de SIGTERM. Si ésta no logra detener el servicio de datos, envía una señal SIGKILL signal.

Antes de intentar detener el DNS, este método Stop verifica que el proceso esté realmente en ejecución. Si el proceso está en ejecución, Stop utiliza el recurso del supervisor de procesos (pmfadm) para detenerlo.

Está garantizado que el método Stop sea idempotente. Aunque RGM no debería invocar un método Stop por segunda vez sin haber iniciado antes el servicio de datos mediante una llamada a su método Start, sí puede invocar un método Stop en un recurso aunque éste no se haya iniciado nunca o se haya terminado solo. Por tanto, el método Stop sale de forma satisfactoria aunque el DNS no esté en ejecución.

Parada de la aplicación

El método Stop proporciona un enfoque en dos hileras para detener el servicio de datos: un enfoque ordenado, o suave, que utiliza una señal de SIGTERM a través de pmfadm, y un enfoque duro o brusco, con la señal de SIGKILL. El método Stop obtiene el valor Stop_timeout (la cantidad de tiempo en el que el método Stop debe volver). Stop asigna entonces el 80 % de este tiempo a una parada suave y el 15 % a una parada brusca (el 5 % queda reservado), como se muestra a continuación.

STOP_TIMEOUT=`scha_resource_get -O STOP_TIMEOUT -R $RESOURCE_NAME
\

-G $RESOURCEGROUP_NAMÈ
((SMOOTH_TIMEOUT=$STOP_TIMEOUT * 80/100))

((HARD_TIMEOUT=$STOP_TIMEOUT * 15/100))

El método Stop utiliza pmfadm -q para verificar que el daemon de DNS esté en ejecución. Si es así, Stop utiliza primero pmfadm -s para enviar una señal TERM para terminar el proceso de DNS. Si esta señal no logra terminar el proceso pasado un 80 % del valor de tiempo de espera, Stop envía una señal SIGKILL. Si esta señal tampoco puede finalizar el proceso en un 15 % del valor de tiempo de espera, el método registra un mensaje de error y sale con estado de error.

Si pmfadm termina el proceso, el método registra un mensaje que indica que el proceso se ha detenido y sale de forma satisfactoria.

Si el proceso de DNS no está en ejecución, el método registra un mensaje de que no está en ejecución y sale de forma satisfactoria de todas formas. El siguiente ejemplo de código muestra cómo Stop utiliza pmfadm para detener el proceso de DNS.

# Ver si in.named está en ejecución y, en caso afirmativo, terminarlo.
if pmfadm -q $PMF_TAG; then
   # Enviar una señal SIGTERM al servicio de datos y esperar un 80 %
   # del valor total del tiempo de espera.
   pmfadm -s $RESOURCE_NAME.named -w $SMOOTH_TIMEOUT TERM
   if [ $? -ne 0 ]; then
      logger -p ${SYSLOG_FACILITY}.err \
          -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
          “${ARGV0} No se ha podido detener HA-DNS con SIGTERM; \
           Reintentarlo con SIGKILL”

      # Dado que el servicio de datos no se ha detenido con una señal SIGTERM
      # usar SIGKILL ahora y esperar otro 15 % del valor de tiempo de espera total.
      pmfadm -s $PMF_TAG -w $HARD_TIMEOUT KILL
      if [ $? -ne 0 ]; then
          logger -p ${SYSLOG_FACILITY}.err \
          -t [$SYSLOG_TAG]
          “${ARGV0} No se ha podido detener HA-DNS; salida NO SATISFACTORIA”

          exit 1
      fi
fi
else
   # El servicio de datos no se está ejecutando actualmente. Registrar un mensaje y
   # salir con resultado satisfactorio.
   logger -p ${SYSLOG_FACILITY}.err \
           -t [$SYSLOG_TAG] \
           “No se ha podido iniciar HA-DNS”

   # Aunque HA-DNS no esté en ejecución, salir con resultado satisfactorio para
   # no poner el recurso del servicio de datos en el estado STOP_FAILED.
   exit 0

fi

# Se ha podido detener satisfactoriamente DNS. Registrar un mensaje y salir con
# resultado satisfactorio.
logger -p ${SYSLOG_FACILITY}.err \
    -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME]
\
    “HA-DNS se ha detenido satisfactoriamente”
exit 0

Estado de salida de Stop

Un método Stop no debería salir satisfactoriamente hasta que la aplicación subyacente se hubiera detenido realmente, en especial cuando otros servicios de datos dependan de ella. De lo contrario se podrían corromper los datos.

En el caso de una aplicación compleja, como una base de datos, establezca un valor suficientemente alto para la propiedad Stop_timeout en el archivo RTR para permitir que la aplicación tenga tiempo de reorganizarse mientras se detiene.

Si este método no logra detener el DNS y sale con estado de fallo, RGM comprueba la propiedad Failover_mode, que determina el modo de reaccionar. El servicio de datos de ejemplo no fija explícitamente la propiedad Failover_mode, por lo que tiene el valor predeterminado NONE (salvo que el administrador del sistema haya anulado el valor predeterminado y haya especificado otro). En este caso, RGM no realiza ninguna acción, salvo fijar el estado del servicio de datos en Stop_failed. Se requiere la intervención del usuario para forzar la parada de la aplicación y borrar el estado Stop_failed.