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.