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.