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 Selección de los métodos Start y Stop que deben utilizarse para obtener información sobre cuándo debe utilizarse en su lugar Prenet_start y Postnet_stop .

Funcionamiento del método Start

RGM llama al 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, aunque no se describen las funciones comunes a todos los métodos de rellamada como, por ejemplo, la función parse_args(). Esta sección tampoco describe el uso de la función syslog(). Las funciones comunes se describen en Funciones comunes para todos los métodos.

Para obtener una lista completa del método Start, consulte Listado de código del método Start .

Comportamiento del método Start

Antes de intentar iniciar DNS, el método Start del servicio de datos de ejemplo comprueba que el directorio y el archivo de configuración (named.conf) están accesibles y disponibles. La información incluida en named.conf es fundamental para el correcto funcionamiento de DNS.

Este metodo de rellamada usa PMF (pmfadm) para iniciar el daemon de DNS (in.named). Si DNS se bloquea o no puede iniciarse, PMF intenta iniciar el daemon de DNS un número prestablecido de veces durante un intervalo especificado. Las propiedades del archivo RTR del servicio de datos especifican el número de reintentos y el intervalo.

Comprobación de la configuración

Para funcionar, el DNS necesita información del archivo named.conf, en el directorio de configuración. Por lo tanto, el método Start realiza algunas compobaciones de integridad para verificar que se puede acceder al directorio y el archivo antes de iniciar 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 actual al configurar el servicio de datos.

En el servicio de datos de ejemplo, el método Start recupera la ubicación del directorio de configuración mediante 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. El comando awk recupera sólo el valor y lo incluye en la variable de shell, CONFIG_DIR .

# find the value of Confdir set by the cluster administrator at the time of
# adding the resource.
config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Confdir`

# scha_resource_get returns the "type" as well as the "value" for the
# extension properties. Get only the value of the extension property 
CONFIG_DIR=`echo $config_info | awk '{print $2}'`

El método Start utiliza el valor de CONFIG_DIRpara comprobar que se puede acceder al directorio. De lo contrario, Start registra un mensaje de error y sale con un estado de error. Consulte Estado de salida de Start.

# Check if $CONFIG_DIR is accessible.
if [ ! -d $CONFIG_DIR ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} Directory $CONFIG_DIR is missing or not mounted"
   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 está, Start registra un mensaje de error y sale con un estado de error.

# Change to the $CONFIG_DIR directory in case there are relative
# pathnames in the data files.
cd $CONFIG_DIR

# Check that the named.conf file is present in the $CONFIG_DIR directory
if [ ! -s named.conf ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} File $CONFIG_DIR/named.conf is missing or empty"
   exit 1
fi

Inicio de la aplicación

Este método emplea la utilidad del administrador de procesos (pmfadm) para iniciar la aplicación. El comando pmfadm permite establecer el número de intentos que se pueden realizar para reiniciar la aplicación durante un intervalo de tiempo especificado. El archivo RTR contiene dos propiedades: Retry_count especifica el número de veces que se puede intentar iniciar una aplicación y Retry_interval especifica el intervalo de tiempo durante el que puede realizarse esta acción.

El Start recupera los valores de Retry_count y Retry_interval mediante la función scha_resource_get () y los almacena en las variables de shell. El método Start pasa estos valores a pmfadm mediante las opciones - n y -t.

# Get the value for retry count from the RTR file.
RETRY_CNT=`scha_resource_get -O Retry_count -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`
# Get the value for retry interval from the RTR file. This value is in seconds
# and must be converted to minutes for passing to pmfadm. Note that the 
# conversion rounds up; for example, 50 seconds rounds up to 1 minute.
((RETRY_INTRVAL=`scha_resource_get -O Retry_interval -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME` / 60))

# Start the in.named daemon under the control of PMF. Let it crash and restart
# up to $RETRY_COUNT times in a period of $RETRY_INTERVAL; if it crashes
# more often than that, PMF will cease trying to restart it.
# If there is a process already registered under the tag
# <$PMF_TAG>, then PMF sends out an alert message that the
# process is already running.
pmfadm -c $PMF_TAAG -n $RETRY_CNT -t $RETRY_INTRVAL \
    /usr/sbin/in.named -c named.conf

# Log a message indicating that HA-DNS has been started.
if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS successfully started"
fi
exit 0

Estado de salida de Start

El método Start no debería salir con éxito hasta que la aplicación subyacente esté realmente en ejecución y disponible, sobre todo, si otros servicios de datos dependen de ella. Una forma de comprobar que esta acción se ha realizado satisfactoriamente consiste en analizar la aplicación para garantizar que se está ejecutando antes de salir del método Start. En caso de una aplicación compleja, como una base de datos, debe asegurarse de que la propiedad Start_timeout del archivo RTR se ha establecido con un valor lo suficientemente alto para permitir que la aplicación tenga tiempo de reinicializarse y recuperarse de un bloqueo.

Como el recurso (DNS) de la aplicación del servicio de datos de ejemplo se inicia rápidamente, el servicio no realiza una consulta para comprobar que se está ejecutando antes de salir satisfactoriamente.

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 establece de forma explícita la propiedad Failover_mode, por lo que esta propiedad presenta el valor predeterminado NONE (a menos que el administrador del clúster anule el valor predeterminado y especifique uno diferente). En este caso, RGM no realiza ninguna acción, salvo fijar el estado del servicio de datos. El administrador del clúster debe realizar un reinicio en el mismo nodo o una recuperación ante fallos en un nodo distinto.

Funcionamiento del 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, aunque no se describen las funciones comunes a todos los métodos de rellamada como, por ejemplo, la función parse_args(). Esta sección tampoco describe el uso de la función syslog(). Las funciones comunes se describen en Funciones comunes para todos los métodos.

Para obtener una lista completa del método Stop, consulte Listado de código del método Stop .

Comportamiento del método 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. Es recomendable enviar una señal SIGTERM a través de pmfadm para realizar un apagado ordenado.

La segunda consideración es garantizar que el servicio de datos se haya detenido realmente para evitar ponerlo en el estado Stop_failed. Para ello, es recomendable enviar la señal SIGKILL a través de pmfadm.

El método Stop del servicio de datos de ejemplo tiene en cuenta estas dos consideraciones. En primer lugar, envía la señal SIGTERM. Si esta señal no puede detener el servicio de datos, el método envía la señal SIGKILL .

Antes de intentar detener el DNS, este método Stop verifica que el proceso esté realmente en ejecución. Si es así, Stop utiliza PMF (pmfadm) para detener el proceso.

Está garantizado que el método Stop sea idempotente. Aunque RGM no debería llamar dos veces al método Stop sin iniciar primero el servicio de datos con una llamada al método Start, puede llamar a este método en un recurso, aunque éste nunca se haya iniciado o detenido espontáneamente. 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 mediante el envío de la señal SIGTERM a través de pmfadm, o uno abrupto o brusco mediante el envío de la señal SIGKILL. El método Stop obtiene el valor de Stop_timeout (la cantidad de tiempo en el método Stop debe devolver un resultado satisfactorio). Stop asigna 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_NAME'
((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 el daemon de DNS se está ejecutando, el método Stop utiliza en primer lugar pmfadm -s para enviar una señal TERM que permita finalizar el proceso de DNS. Si la señal no puede finalizar el proceso una vez agotado el 80 % del valor de tiempo de espera, el método Stop envía una señal SIGKILL. Si esta señal también es incapaz de finalizar el proceso en el 15 % del valor de tiempo de espera, el método registra un mensaje de error y sale con un 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 código de ejemplo Stop utiliza pmfadm para detener el proceso de DNS.

# See if in.named is running, and if so, kill it. 
if pmfadm -q $PMF_TAG; then
   # Send a SIGTERM signal to the data service and wait for 80% of the
   # total timeout value.
   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} Failed to stop HA-DNS with SIGTERM; Retry with \
           SIGKILL”
      
      # Since the data service did not stop with a SIGTERM signal, use 
      # SIGKILL now and wait for another 15% of the total timeout value.
      pmfadm -s $PMF_TAG -w $HARD_TIMEOUT KILL
      if [ $? -ne 0 ]; then
          logger -p ${SYSLOG_FACILITY}.err \
          -t [$SYSLOG_TAG] \
          “${ARGV0} Failed to stop HA-DNS; Exiting UNSUCCESSFUL”
         exit 1
      fi
fi
else 
   # The data service is not running as of now. Log a message and 
   # exit success.
   logger -p ${SYSLOG_FACILITY}.err \
           -t [$SYSLOG_TAG] \
           “HA-DNS is not started”

   # Even if HA-DNS is not running, exit success to avoid putting
   # the data service resource in STOP_FAILED State.
   exit 0
fi

# Could successfully stop DNS. Log a message and exit success.
logger -p ${SYSLOG_FACILITY}.err \
    -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
    “HA-DNS successfully stopped”
exit 0

Estado de salida de Stop

El método Stop no debería salir con éxito hasta que se haya detenido realmente la aplicación subyacente, sobre todo, si otros servicios de datos dependen de ella. De lo contrario se podrían dañar 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 establece de forma explícita la propiedad Failover_mode, por lo que esta propiedad presenta el valor predeterminado NONE (a menos que el administrador del clúster anule el valor predeterminado y especifique uno diferente). En este caso, RGM no realiza ninguna acción, excepto establecer el estado del servicio de datos en Stop_failed. El administrador del clúster debe detener obligatoriamente la aplicación y borrar el estado Stop_failed.