test

Sun Cluster: Guía del desarrollador de los servicios de datos del sistema operativo Solaris

Capítulo 5 Servicio de datos de ejemplo

Este capítulo describe un servicio de datos de ejemplo de Sun Cluster, HA-DNS, para la aplicación in.named. El daemon in.named es la implementación del Servicio de nombres de dominio (DNS) de Solaris. El servicio de datos de ejemplo demuestra cómo hacer que una aplicación tenga una alta disponibilidad, con la API de gestión de recursos.

Ésta admite una interfaz de secuencias de comandos del shell y una de programa C. La aplicación de ejemplo de este capítulo se escribe con aquélla.

En este capítulo se tratan los temas siguientes:

Información general del servicio de datos de ejemplo

El servicio de datos de ejemplo inicia, detiene, reinicia y conmuta la aplicación de DNS entre los nodos del clúster, en respuesta a eventos del clúster, como una acción administrativa o fallos de la aplicación o del nodo.

El reinicio de la aplicación lo administra la Utilidad del supervisor de procesos (PMF). Si el número de aplicaciones que se desactivan supera el recuento de fallos en el intervalo de tiempo especificado, el supervisor de fallos realiza una recuperación ante fallos del grupo de recursos que contiene el recurso de la aplicación en otro nodo.

El servicio de datos de ejemplo proporciona funciones de supervisión de fallos mediante el método PROBE, que utiliza el comando nslookup para garantizar el buen estado de la aplicación. Si el análisis detecta un servicio de DNS bloqueado, reiniciará localmente la aplicación DNS para intentar corregir la situación. Si el reinicio local de la aplicación DNS no mejora la situación y el análisis continúa detectando problemas en el servicio, intentará realizar una recuperación ante fallos del servicio en otro nodo del clúster.

El servicio de datos incluye específicamente los siguientes elementos:

Definición del archivo de registro del tipo de recurso

El archivo de registro del tipo de recurso (RTR) de este ejemplo define la configuración estática del tipo de recurso de DNS. Los recursos de este tipo heredan las propiedades definidas en el archivo RTR.

El Gestor de grupos de recursos (RGM) lee la información del archivo RTR cuando el administrador del clúster registra el servicio HA-DNS.

Información general sobre el archivo RTR

El archivo RTR sigue un formato bien definido. Las propiedades del recurso se definen primero en el archivo; después se definen las propiedades del recurso definidas por el sistema; finalmente, se definen las propiedades de extensión. Consulte la página de comando man rt_reg(4) y Establecimiento del recurso y las propiedades del tipo de recurso para obtener más información.

Las siguientes secciones describen las propiedades específicas del archivo RTR de ejemplo. Estas secciones proporcionan listados de las diferentes partes del archivo. Para obtener una lista completa del contenido del archivo RTR de ejemplo, consulte Listado del archivo de registro del tipo de recurso.

Propiedades de tipo en el archivo RTR de ejemplo

El archivo RTR de ejemplo empieza con comentarios, seguidos de las propiedades del tipo de recurso que definen la configuración de HA-DNS, como se muestra en la lista siguiente.

Nota –

Los nombres de los tipos de recursos, los recursos y los grupos de recursos no distinguen entre mayúsculas y minúsculas. Puede utilizar cualquier combinación de mayúsculas y minúsculas al especificar los nombres de las propiedades. 

#
# Copyright (c) 1998-2005 by Sun Microsystems, Inc.
# All rights reserved.
#
# Registration information for Domain Name Service (DNS)
#

#pragma ident   “@(#)SUNW.sample   1.1   00/05/24 SMI”

Resource_type = “sample”;
Vendor_id = SUNW;
RT_description = “Domain Name Service on Sun Cluster”;

RT_version =”1.0”; 
API_version = 2;    
Failover = TRUE;

RT_basedir=/opt/SUNWsample/bin;
Pkglist = SUNWsample;

Start         =   dns_svc_start;
Stop          =   dns_svc_stop;

Validate      =   dns_validate;
Update        =   dns_update;

Monitor_start =   dns_monitor_start;
Monitor_stop  =   dns_monitor_stop;
Monitor_check =   dns_monitor_check;
Consejo –

Debe declarar la propiedad Resource_type como la primera entrada del archivo RTR, De lo contrario, fallará el registro del tipo de recurso.

La siguiente información describe estas propiedades:

Las propiedades del tipo de recurso que no se especifiquen en el archivo RTR como, por ejemplo, Single_instance, Init_nodes y Installed_nodes , se establecerán en sus valores predeterminados. Propiedades del tipo de recurso contiene una lista completa de las propiedades de tipos de recursos, incluidos sus valores predeterminados.

El administrador del clúster no puede cambiar los valores de las propiedades de tipos de recursos del archivo RTR.

Propiedades del recurso en el archivo RTR de ejemplo

Por convención, las propiedades del recurso se declaran de acuerdo con las del tipo de recurso del archivo RTR. Entre las propiedades del recurso, se incluyen las propiedades definidas por el sistema que proporciona Sun Cluster y las propiedades de extensión que defina. Para cada tipo, puede especificar una serie de atributos de propiedades proporcionadas por el software de Sun Cluster, como los valores mínimos, máximos y predeterminados

Propiedades definidas por el sistema en el archivo RTR

La siguiente lista muestra las propiedades definidas por el sistema en el archivo RTR de ejemplo. 

# A list of bracketed resource property declarations follows the
# resource type declarations. The property-name declaration must be
# the first attribute after the open curly bracket of each entry.

# The <method>_timeout properties set the value in seconds after which
# the RGM concludes invocation of the method has failed.

# The MIN value for all method timeouts is set to 60 seconds. This
# prevents administrators from setting shorter timeouts, which do not
# improve switchover/failover performance, and can lead to undesired
# RGM actions (false failovers, node reboot, or moving the resource group
# to ERROR_STOP_FAILED state, requiring operator intervention). Setting
# too-short method timeouts leads to a *decrease* in overall availability
# of the data service.
{  
   PROPERTY = Start_timeout; 
   MIN=60; 
   DEFAULT=300;
}

{
   PROPERTY = Stop_timeout; 
   MIN=60; 
   DEFAULT=300;
}
{
   PROPERTY = Validate_timeout;
   MIN=60;
   DEFAULT=300;
}
{
   PROPERTY = Update_timeout;
   MIN=60;
   DEFAULT=300;
}
{
   PROPERTY = Monitor_Start_timeout;
   MIN=60;
   DEFAULT=300;
}
{
   PROPERTY = Monitor_Stop_timeout;
   MIN=60;
   DEFAULT=300;
}
{
   PROPERTY = Thorough_Probe_Interval;
   MIN=1;
   MAX=3600;
   DEFAULT=60;
   TUNABLE = ANYTIME;
}

# The number of retries to be done within a certain period before concluding 
# that the application cannot be successfully started on this node.
{
   PROPERTY = Retry_count;
   MIN=0;
   MAX=10;
   DEFAULT=2;
   TUNABLE = ANYTIME; 
}

# Set Retry_interval as a multiple of 60 since it is converted from seconds
# to minutes, rounding up. For example, a value of 50 (seconds)
# is converted to 1 minute. Use this property to time the number of 
# retries (Retry_count).
{
   PROPERTY = Retry_interval;
   MIN=60;
   MAX=3600;
   DEFAULT=300;
   TUNABLE = ANYTIME;
}

{
   PROPERTY = Network_resources_used;
   TUNABLE = AT_CREATION;
   DEFAULT = ““;
}

Aunque el software de Sun Cluster proporciona las propiedades definidas por el sistema, puede establecer diferentes valores predeterminados mediante el uso de los atributos de propiedades del recurso. Consulte Atributos de las propiedades de recursos para obtener una lista completa de los atributos disponibles que se pueden aplicar a las propiedades del recurso.

Tenga en cuenta los siguientes puntos sobre las propiedades de recursos definidas por el sistema en el archivo RTR de ejemplo:

Propiedades de extensión en el archivo RTR

Al final del archivo RTR de ejemplo, se encuentran las propiedades de extensión: 

# Extension Properties

# The cluster administrator must set the value of this property to point to the
# directory that contains the configuration files used by the application.
# For this application, DNS, specify the path of the DNS configuration file on
# PXFS (typically named.conf).
{
   PROPERTY = Confdir;
   EXTENSION;
   STRING;
   TUNABLE = AT_CREATION;
   DESCRIPTION = “The Configuration Directory Path”;
}

# Time out value in seconds before declaring the probe as failed.
{
   PROPERTY = Probe_timeout;
   EXTENSION;
   INT;
   DEFAULT = 120;
   TUNABLE = ANYTIME;
   DESCRIPTION = “Time out value for the probe (seconds)”;
}

El archivo RTR de ejemplo define dos propiedades de extensión, Confdir y Probe_timeout. La propiedad Confdir especifica la ruta al directorio de configuración de DNS, que contiene el archivo in.named, necesario para que DNS funcione satisfactoriamente. Los métodos Start y Validate del servicio de datos de ejemplo utilizan esta propiedad para comprobar que se puede acceder al directorio de configuración y el archivo in.named antes de iniciar DNS.

Cuando el servicio de datos está configurado, el método Validate verifica si el nuevo directorio es accesible.

El método PROBE del servicio de datos de ejemplo no es un método de rellamada de Sun Cluster, sino un método definido por el usuario. Por lo tanto, Sun Cluster no proporciona una propiedad Probe_timeout para éste. Debe definir una propiedad de extensión en el archivo RTR para permitir que el administrador del clúster configure el valor de Probe_timeout.

Funciones comunes para todos los métodos

Esta sección describe las siguientes funciones que se emplean en todos los métodos de rellamada del servicio de datos de ejemplo:

Identificación del intérprete de comandos y exportación de la ruta

La primera línea de una secuencia de comandos del shell debe identificar el intérprete de éstas. Cada secuencia de comandos del método del servicio de datos de ejemplo identifica el intérprete de comandos de la siguiente forma: 

#!/bin/ksh

Todas las secuencias de comandos de la aplicación de ejemplo exportan la ruta a los binarios y las bibliotecas de Sun Cluster en lugar de utilizar la configuración de PATH del usuario. 

#######################################################################
# MAIN
#######################################################################

export PATH=/bin:/usr/bin:/usr/cluster/bin:/usr/sbin:/usr/proc/bin:$PATH

Declaración de las variables PMF_TAG y SYSLOG_TAG

Todas las secuencias de comandos del método, excepto Validate, utilizan pmfadm para iniciar o detener el servicio de datos o el supervisor, pasando el nombre del recurso. Cada secuencia de comandos define una variable, PMF_TAG, que puede pasarse a pmfadm para identificar el servicio de datos o el supervisor.

Del mismo modo, cada secuencia de comandos del método utiliza el comando logger para almacenar mensajes en el registro del sistema. Cada secuencia de comandos define una variable, SYSLOG_TAG, que puede pasarse a logger con la opción -t para identificar el tipo, el nombre y el grupo de recursos del recurso para el que se está registrando el mensaje.

Todos los métodos definen SYSLOG_TAG del mismo modo, como se muestra en el siguiente código de ejemplo. Los métodos dns_probe, dns_svc_start , dns_svc_stop y dns_monitor_check definen PMF_TAG de la siguiente forma (pmfadm y logger se utilizan con el método dns_svc_stop). 

#########################################################################
# MAIN
#########################################################################

PMF_TAG=$RESOURCE_NAME.named

SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME

   # Send a SIGTERM signal to the data service and wait for 80% of the
   # total timeout value.
   pmfadm -s $PMF_TAG.named -w $SMOOTH_TIMEOUT TERM
   if [ $? -ne 0 ]; then
      logger -p ${SYSLOG_FACILITY}.info \
          -t [$SYSLOG_TAG] \
          “${ARGV0} Failed to stop HA-DNS with SIGTERM; Retry with \
           SIGKILL”

Los métodos dns_monitor_start, dns_monitor_stop y dns_update definen PMF_TAG de la siguiente forma (tpmfadm se utiliza con el método dns_monitor_stop): 

#####################################################################
# MAIN
#####################################################################

PMF_TAG=$RESOURCE_NAME.monitor
SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME
...
# See if the monitor is running, and if so, kill it. 
if pmfadm -q $PMF_TAG.monitor; then
   pmfadm -s $PMF_TAG.monitor KILL

Análisis de los argumentos de función

RGM ejecuta todos los métodos de rellamada, excepto Validate, como se indica a continuación: 

method-name -R resource-name -T resource-type-name -G resource-group-name

El nombre del método es el de la ruta del programa que implementa el método de rellamada. Un servicio de datos especifica el nombre de la ruta de cada método en el archivo RTR. Estos nombres de ruta son relativos en relación con el directorio especificado por la propiedad Rt_basedir, también en el archivo RTR. Por ejemplo, en el archivo RTR del servicio de datos de ejemplo, el directorio básico y los nombres de métodos se especifican de la siguiente forma: 

RT_basedir=/opt/SUNWsample/bin;
Start = dns_svc_start;
Stop =  dns_svc_stop;
...

Todos los argumentos de los métodos de rellamada se pasan como valores marcados. El argumento -R indica el nombre de la instancia del recurso. El argumento -T indica el tipo de recurso. El argumento -G indica el grupo en el que se ha configurado el recurso. Consulte la página de comando man rt_callbacks(1HA) para obtener más información sobre los métodos de rellamada.

Nota –

Se llama al método Validate con argumentos adicionales, es decir, los valores de propiedades del recurso y el grupo de recursos. Consulte Administración de las actualizaciones de propiedades para obtener más información.

Cada método de rellamada necesita una función para analizar los argumentos que ésta transfiere. Dado que las rellamadas pasan siempre por los mismos argumentos, el servicio de datos proporciona una única función de análisis para todas las rellamadas de la aplicación.

El siguiente ejemplo muestra la función parse_args() utilizada para los métodos de rellamada en la aplicación de ejemplo. 

#########################################################################
# Parse program arguments.
#
function parse_args # [args ...]
{
      typeset opt

      while getopts 'R:G:T:' opt
      do
             case "$opt" in
             R)
                  # Name of the DNS resource.
                  RESOURCE_NAME=$OPTARG
                  ;;
             G)
                  # Name of the resource group in which the resource is
                  # configured.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
             T)
                  # Name of the resource type.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
             *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                  "ERROR: Option $OPTARG unknown"
                  exit 1
                      ;;
             esac
    done
}
Nota –

Aunque el método PROBE de la aplicación de ejemplo está definido por el usuario (no es un método de rellamada de Sun Cluster), se invoca con los mismos argumentos que los métodos de rellamada. Por lo tanto, este método contiene una función de análisis idéntica a la utilizada por los otros métodos de rellamada.

La función de análisis se invoca en MAIN como: 

parse_args “$@”

Generación de mensajes de error

Los métodos de rellamada deberían utilizar la función syslog() para proporcionar los mensajes de error a los usuarios finales. Todos los métodos de rellamada del servicio de datos de ejemplo utilizan el comando scha_cluster_get para recuperar el número de la función syslog() utilizado por el registro del sistema, como se indica a continuación: 

SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`

El valor se almacena en la variable del shell, SYSLOG_FACILITY, y puede emplearse como utilidad del comando logger para incluir mensajes en el registro del clúster. Por ejemplo, el método Start del servicio de datos de ejemplo recupera la función syslog() y registra un mensaje que indica que el servicio de datos se ha iniciado, como se muestra a continuación: 

SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`
...
if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS successfully started"
fi

Para obtener más información, consulte la página de comando man scha_cluster_get(1HA).

Obtención de la información de la propiedad

La mayoría de los métodos de rellamada necesitan obtener información sobre las propiedades de recurso y el tipo de recurso del servicio de datos. La API proporciona la función scha_resource_get() con este fin.

Están disponibles tanto las propiedades definidas por el sistema como las propiedades de extensión. Las propiedades definidas por el sistema son predefinidas, mientras que las propiedades de extensión se definen en el archivo RTR.

Al utilizar la funcion scha_resource_get() para obtener el valor de una propiedad definida por el sistema, se debe especificar el nombre de la propiedad con la opción -O. El comando sólo devuelve el valor de la propiedad. Por ejemplo, en el servicio de datos de ejemplo, el método Monitor_start debe encontrar el programa de análisis para poder iniciarlo. Éste reside en el directorio básico del servicio de datos, al que señala la propiedad Rt_basedir. El método Monitor_start recupera el valor de RT_basedir y lo ubica en la variable RT_BASEDIR, como se muestra a continuación: 

RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

Debe utilizar la opción -O para especificar que una propiedad es de extensión. Además, debe proporcionar el nombre de la propiedad como último argumento. Para las propiedades de extensión, el comando devuelve el tipo y el valor de la propiedad. Por ejemplo, en el servicio de datos, el programa de análisis recupera el tipo y el valor de la propiedad de extensión Probe_timeout y utiliza el comando awk para incluir sólo el valor en la variable de shell PROBE_TIMEOUT, como se indica a continuación: 

probe_timeout_info=`scha_resource_get -O Extension \
-R $RESOURCE_NAME -G $RESOURCEGROUP_NAME Probe_timeout`
PROBE_TIMEOUT=`echo $probe_timeout_info | awk '{print $2}'`

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().

Nota –

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.

Nota –

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.

Definición de un supervisor de fallos

La aplicación de ejemplo implementa un supervisor básico de fallos para supervisar la fiabilidad del recurso de DNS (in.named). El supervisor de fallos está compuesto por los siguientes elementos:

Funcionamiento del programa de análisis

El programa dns_probe implementa un proceso en ejecución permanente que comprueba que el recurso de DNS controlado por el servicio de datos de ejemplo esté en ejecución. dns_probe se inicia mediante el método dns_monitor_start, ejecutado automáticamente por RGM una vez establecido en línea el servicio de datos de ejemplo. El método dns_monitor_stop, que se ejecuta antes de que RGM ponga fuera de línea el servicio de datos de ejemplo, detiene este servicio.

Esta sección describe los principales fragmentos del método PROBE 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 conocer la lista completa del método PROBE, consulte Listado de código del programa PROBE .

Comportamiento del programa de análisis

El análisis se ejecuta en un bucle infinito. Utiliza nslookup para comprobar que se está ejecutando el recurso de DNS correcto. Si no se está ejecutando, el análisis permanece inactivo durante un intervalo preestablecido (mediante la propiedad definida por el sistema Thorough_probe_interval) y realiza de nuevo la comprobación. Si DNS no está en ejecución, este programa intenta reiniciarlo localmente o, dependiendo del número de intentos de reinicio, solicita que RGM reubique el servicio de datos en otro nodo.

Obtención de los valores de propiedad

Este programa requiere los valores de las siguientes propiedades:

La función scha_resource_get() obtiene los valores de estas propiedades y los almacena en variables de shell, como se muestra a continuación: 

PROBE_INTERVAL=`scha_resource_get -O Thorough_probe_interval \
-R $RESOURCE_NAME -G $RESOURCEGROUP_NAME`

PROBE_TIMEOUT_INFO=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Probe_timeout` 
Probe_timeout=`echo $probe_timeout_info | awk '{print $2}'`

DNS_HOST=`scha_resource_get -O Network_resources_used -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`

RETRY_COUNT=`scha_resource_get -O Retry_count -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

RETRY_INTERVAL=`scha_resource_get -O Retry_interval -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME -G \
 $RESOURCEGROUP_NAME`
Nota –

Para las propiedades definidas por el sistema, como Thorough_probe_interval , la función scha_resource_get() devuelve sólo el valor. Para las propiedades de extensión, como Probe_timeout, la función scha_resource_get() devuelve el valor y el tipo. Utilice el comando awk para obtener únicamente el valor.

Comprobación de la fiabilidad del servicio

El análisis es en sí mismo un bucle while de los comandos nslookup. Antes del bucle while, se configura un archivo temporal para contener las respuestas de nslookup. Las variables probefail y retries se inicializan en 0. 

# Set up a temporary file for the nslookup replies.
DNSPROBEFILE=/tmp/.$RESOURCE_NAME.probe
probefail=0
retries=0

El bucle while realiza las siguientes tareas:

Éste es el código bucle while. 

while :
do
   # The interval at which the probe needs to run is specified in the
   # property THOROUGH_PROBE_INTERVAL. Therefore, set the probe to sleep
   # for a duration of THOROUGH_PROBE_INTERVAL.
   sleep $PROBE_INTERVAL

   # Run an nslookup command of the IP address on which DNS is serving.
   hatimerun -t $PROBE_TIMEOUT /usr/sbin/nslookup $DNS_HOST $DNS_HOST \
   > $DNSPROBEFILE 2>&1

      retcode=$?
      if [ $retcode -ne 0 ]; then
            probefail=1
      fi

   # Make sure that the reply to nslookup comes from the HA-DNS
   # server and not from another nameserver mentioned in the 
   # /etc/resolv.conf file.
   if [ $probefail -eq 0 ]; then
# Get the name of the server that replied to the nslookup query.
   SERVER=` awk ' $1=="Server:" { print $2 }' \
   $DNSPROBEFILE | awk -F. ' { print $1 } ' `
   if [ -z "$SERVER" ]; then
      probefail=1
      else
         if [ $SERVER != $DNS_HOST ]; then
            probefail=1
         fi
   fi
fi

Comparación del reinicio y la recuperación ante fallos

Si la variable probefail tiene un valor diferente a 0 (éxito), se agota el tiempo de espera del comando nslookup o la respuesta proviene de un servidor diferente al servidor de DNS del servicio de ejemplo. En ambos casos, el servidor de DNS no funciona como debería y el supervisor de fallos invoca la función decide_restart_or_failover() para determinar si se debe reiniciar el servicio de datos localmente o solicitar que RGM reubique el servicio de datos en otro nodo. Si la variable probefail es 0, se genera un mensaje en el que se indica que el análisis se ha realizado satisfactoriamente. 

   if [ $probefail -ne 0 ]; then
         decide_restart_or_failover
   else
         logger -p ${SYSLOG_FACILITY}.err\
         -t [$SYSLOG_TAG]\
         "${ARGV0} Probe for resource HA-DNS successful"
   fi

La función decide_restart_or_failover() utiliza un intervalo de tiempo (Retry_interval) y un recuento de fallos (Retry_count) para determinar si se debe reiniciar localmente DNS o solicitar que RGM reubique el servicio de datos en un nodo diferente. Esta función implementa la siguiente lógica condicional. El código se incluye en el listado de decide_restart_or_failover() en Listado de código del programa PROBE .

Si el número de reinicios alcanza el límite durante el intervalo de tiempo, la función solicita que RGM reubique el servicio de datos en otro nodo. Si el número de reinicios está dentro del límite o se ha superado el intervalo, por lo que el recuento vuelve a empezar, la función intenta reiniciar DNS en el mismo nodo. Sobre esta función debe tener en cuenta lo siguiente:

Reinicio del servicio de datos

decide_restart_or_failover() llama a la función restart_service() para intentar reiniciar el servicio de datos en el mismo nodo. Esta función ejecuta la siguiente lógica:

function restart_service
{

        # To restart the data service, first verify that the 
        # data service itself is still registered under PMF.
        pmfadm -q $PMF_TAG
        if [[ $? -eq 0 ]]; then
                # Since the TAG for the data service is still registered under
                # PMF, first stop the data service and start it back up again.

                # Obtain the Stop method name and the STOP_TIMEOUT value for
                # this resource.
                STOP_TIMEOUT=`scha_resource_get -O STOP_TIMEOUT \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                STOP_METHOD=`scha_resource_get -O STOP \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                hatimerun -t $STOP_TIMEOUT $RT_BASEDIR/$STOP_METHOD \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
                        -T $RESOURCETYPE_NAME

                if [[ $? -ne 0 ]]; then
                        logger-p ${SYSLOG_FACILITY}.err -t [$SYSLOG_TAG] \
                                “${ARGV0} Stop method failed.”
                        return 1
                fi

                # Obtain the START method name and the START_TIMEOUT value for
                # this resource.
                START_TIMEOUT=`scha_resource_get -O START_TIMEOUT \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                START_METHOD=`scha_resource_get -O START \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                hatimerun -t $START_TIMEOUT $RT_BASEDIR/$START_METHOD \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
                        -T $RESOURCETYPE_NAME

                if [[ $? -ne 0 ]]; then
                        logger-p ${SYSLOG_FACILITY}.err -t [$SYSLOG_TAG] \
                                “${ARGV0} Start method failed.”
                        return 1
                fi


        else
                # The absence of the TAG for the dataservice 
                # implies that the data service has already
                # exceeded the maximum retries allowed under PMF.
                # Therefore, do not attempt to restart the
                # data service again, but try to failover
                # to another node in the cluster.
                scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \
                        -R $RESOURCE_NAME
        fi

        return 0
}

Estado de salida del análisis

El programa PROBE del servicio de datos sale con errores si fallan los intentos de reinicio local y de recuperación ante fallos en un nodo diferente. Este programa registra un mensaje sobre el fallo del intento de recuperación: Failover attempt failed.

Funcionamiento del método Monitor_start

RGM invoca el método Monitor_start para iniciar el método dns_probe después de que el servicio de datos de ejemplo se ponga en línea.

En esta sección, se describen las partes más importantes del método Monitor_start de 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 un listado completo del método Monitor_start, consulte Listado de código del método Monitor_start .

Comportamiento del método Monitor_start

Este método utiliza PMF (pmfadm) para iniciar el análisis.

Inicio del análisis

El método Monitor_start obtiene el valor de la propiedad RT_basedir para construir el nombre completo de la ruta del programa PROBE. Este método inicia el análisis mediante la opción de pmfadm (-n -1, -t -1), que implica que si el análisis no puede iniciarse, PMF intenta iniciarlo un número infinito de veces durante un periodo ilimitado de tiempo. 

# Find where the probe program resides by obtaining the value of the
# RT_basedir property of the resource.
RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

# Start the probe for the data service under PMF. Use the infinite retries
# option to start the probe. Pass the resource name, type, and group to the
# probe program. 
pmfadm -c $RESOURCE_NAME.monitor -n -1 -t -1 \
   $RT_BASEDIR/dns_probe -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME

Funcionamiento del método Monitor_stop

RGM llama al método Monitor_stop para detener la ejecución de dns_probe cuando el servicio de datos de ejemplo se pone fuera de línea.

En esta sección, se describen las partes más importantes del método Monitor_start de 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 un listado completo del método Monitor_stop, consulte Listado de código del método Monitor_stop.

Comportamiento del método Monitor_stop

Este método utiliza PMF (pmfadm) para comprobar si el análisis se está ejecutando y, si es así, detenerlo.

Parada del supervisor

El método Monitor_stop utiliza pmfadm -q para ver si el análisis está en ejecución y, si así fuera, utiliza pmfadm -s para detenerlo. Si el análisis ya está detenido, el método sigue saliendo de forma satisfactoria, lo que garantiza la idempotencia del método.

Precaución – Precaución –

Asegúrese de utilizar la señal KILL con pmfadm para detener el análisis y no una señal que pueda ocultarse, como TERM. De lo contrario, el método Monitor_stop puede bloquearse indefinidamente y, al final, se puede agotar el tiempo de espera. El motivo es que el método PROBE llama a scha_control() cuando es necesario reiniciar el servicio de datos o realizar una recuperación ante fallos. Cuando scha_control() llama a Monitor_stop como parte del proceso de establecimiento en línea del servicio de datos, si Monitor_stop utiliza una señal que pueda ocultarse, este método Monitor_stop se bloquea mientras espera que se complete scha_control() y scha_control() se bloquea también a la espera de que se complete Monitor_stop. 

# See if the monitor is running, and if so, kill it.
if pmfadm -q $PMF_TAG; then
   pmfadm -s $PMF_TAG KILL
   if [ $? -ne 0 ]; then
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Could not stop monitor for resource " \
            $RESOURCE_NAME
           exit 1
   else
         # could successfully stop the monitor. Log a message.
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Monitor for resource " $RESOURCE_NAME \
            " successfully stopped"
   fi
fi
exit 0

Estado de salida de Monitor_stop

El método Monitor_stop registra un mensaje de error si no puede detener el método PROBE. RGM cambia el estado del servicio de datos a MONITOR_FAILED en el nodo principal, lo que puede provocar una situación de emergencia en el nodo.

Monitor_stop no debería salir antes de que se haya detenido el análisis.

Funcionamiento del método Monitor_check

RGM llama al método Monitor_check cuando el método PROBE intenta realizar una recuperación ante fallos del grupo de recursos que contiene el servicio de datos en otro nodo.

En esta sección, se describen las partes más importantes del método Monitor_start de 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 un listado completo del método Monitor_check, consulte Listado de código del método Monitor_check .

Debe implementarse el método Monitor_check de tal forma que no entre en conflicto con otros métodos que se estén ejecutando simultáneamente.

El método Monitor_check llama al método Validate para verificar que el directorio de configuración de DNS esté disponible en el nuevo nodo. La propiedad de extensión Confdir señala al directorio de configuración de DNS. Por lo tanto, Monitor_check obtiene el nombre y la ruta del método Validate y el valor de Confdir. Pasa este valor a Validate, como muestra la lista siguiente. 

# Obtain the full path for the Validate method from
# the RT_basedir property of the resource type.
RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME \
   -G $RESOURCEGROUP_NAMÈ

# Obtain the name of the Validate method for this resource.
VALIDATE_METHOD=`scha_resource_get -O Validate \
   -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ

# Obtain the value of the Confdir property in order to start the
# data service. Use the resource name and the resource group entered to
# obtain the Confdir value set 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 extension
# properties. Use awk to get only the value of the extension property.
CONFIG_DIR=`echo $config_info | awk `{print $2}'`

# Call the validate method so that the dataservice can be failed over
# successfully to the new node.
$RT_BASEDIR/$VALIDATE_METHOD -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME -x Confdir=$CONFIG_DIR

Consulte Funcionamiento del método Validate para comprobar cómo la aplicación de ejemplo comprueba si un nodo es apto para alojar el servicio de datos.

Administración de las actualizaciones de propiedades

El servicio de datos de ejemplo implementa los métodos Validate y Update para permitir que un administrador del clúster administre la actualización de las propiedades.

Funcionamiento del método Validate

RGM llama al método Validate cuando se crea un recurso y cuando una acción administrativa actualiza las propiedades del recurso o el grupo que lo contiene. RGM invoca Validate antes de que se apliquen la creación o la actualización y un código de salida fallido del método en cualquier nodo provoque la cancelación de la creación o actualización.

RGM sólo llama a Validate cuando el administrador del clúster modifica las propiedades del recurso o grupo de recurso, y no cuando RGM establece las propiedades o el supervisor configura las propiedades de recursos Status y Status_msg.

Nota –

El método Monitor_check también llama de forma explícita a Validate cada vez que el método PROBE intenta realizar una recuperación ante fallos del servicio de datos en un nuevo nodo.

Comportamiento del método Validate

RGM llama a Validate con argumentos adicionales a aquéllos transferidos a otros métodos, incluidos los valores y las propiedades que se están actualizando. Por lo tanto, este método del servicio de datos de ejemplo debe implementar una función parse_args() diferente para administrar los argumentos adicionales.

El método Validate del servicio de datos de ejemplo verifica una única propiedad, la propiedad de extensión Confdir. Esta propiedad señala al directorio de configuración de DNS, que es fundamental para una operación satisfactoria del DNS.

Nota –

Dado que no se puede modificar el directorio de configuración mientras DNS está en ejecución, la propiedad Confdir se declara en el archivo RTR como TUNABLE = AT_CREATION . Por lo tanto, el método Validate nunca se invoca para verificar la propiedad Confdir como resultado de una actualización, sino sólo cuando se crea el recurso del servicio de datos.

Si Confdir es una de las propiedades que RGM pasa a Validate, la función parse_args() recupera y guarda su valor. Validate comprueba que el directorio al que Confdir señala está accesible y que el archivo named.conf existe en ese directorio y contiene datos.

Si la función parse_args() no puede recuperar el valor de Confdir desde los argumentos de línea de comandos transferidos por RGM, Validate intentará aún validar la propiedad Confdir. Validate utiliza scha_resource_get() para obtener el valor de Confdir desde la configuración estática. Validate realiza las mismas comprobaciones para verificar que el directorio de configuración está accesible y contiene un archivo named.conf no vacío.

Si Validate sale con un fallo, fallarán la actualización o la creación de todas las propiedades, no sólo de Confdir.

Función de análisis del método Validate

Como el método pasa al método Validate un conjunto de argumentos diferentes al de los otros métodos de rellamada, Validate require una función distinta para analizar los argumentos. Consulte la página de comando man rt_callbacks(1HA) para obtener más información sobre los argumentos que se pasan a Validate y a los otros métodos de rellamada. El siguiente código de ejemplo muestra la función parse_args() de Validate . 

#########################################################################
# Parse Validate arguments.
#
function parse_args # [args...]
{

   typeset opt
   while getopts 'cur:x:g:R:T:G:' opt
   do
         case "$opt" in
         R)
                  # Name of the DNS resource.
                  RESOURCE_NAME=$OPTARG
                  ;;
         G)
                  # Name of the resource group in which the resource is
                  # configured.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
         T)
                  # Name of the resource type.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
         r)
                  # The method is not accessing any system defined
                  # properties so this is a no-op
                  ;;
         g)
                  # The method is not accessing any resource group
                  # properties, so this is a no-op
                  ;;
         c)
                  # Indicates the Validate method is being called while
                  # creating the resource, so this flag is a no-op.
                  ;;
         u)
                  # Indicates the updating of a property when the
                  # resource already exists. If the update is to the
                  # Confdir property then Confdir should appear in the
                  # command-line arguments. If it does not, the method must
                  # look for it specifically using scha_resource_get.
                  UPDATE_PROPERTY=1
                  ;;
         x)
                  # Extension property list. Separate the property and
                  # value pairs using "=" as the separator.
                  PROPERTY=`echo $OPTARG | awk -F= '{print $1}'`
                  VAL=`echo $OPTARG | awk -F= '{print $2}'`
                  # If the Confdir extension property is found on the
                  # command line, note its value.
                  if [ $PROPERTY == "Confdir" ]; then
                           CONFDIR=$VAL
                           CONFDIR_FOUND=1
                  fi
                  ;;
         *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$SYSLOG_TAG] \
                  "ERROR: Option $OPTARG unknown"
                  exit 1
                  ;;
         esac
   done
}

Al igual que la función parse_args() de los otros métodos, esta función proporciona los indicadores (R) para capturar el nombre del recurso, ( G) para capturar el nombre del grupo de recursos y (T) para capturar el tipo de recurso transferido por RGM.

Se omitirán los indicadores r (que distingue una propiedad definida por el sistema), g (que distingue una propiedad del grupo de recursos) y c (que señala que se está produciendo la validación durante la creación del recurso). Se omiten porque se está llamando a este método para validar la propiedad de extensión durante la actualización del recurso.

El indicador u establece el valor de la variable del shell UPDATE_PROPERTY en 1 (TRUE). El indicador x captura el nombre y los valores de las propiedades que se están actualizando. Si Confdir es una de las propiedades que se están actualizando, su valor se incluye en la variables de shell CONFDIR y la variable CONFDIR_FOUND se establece en 1 (TRUE).

Validación de Confdir

En la función MAIN, Validate establece en primer lugar la variable CONFDIR en una cadena vacía, y UPDATE_PROPERTY y CONFDIR_FOUND en 0. 

CONFDIR=""
UPDATE_PROPERTY=0
CONFDIR_FOUND=0

Validate llama a parse_args() para analizar los argumentos transferidos por RGM. 

parse_args “$@”

Validate comprueba si se está llamando al método Validate como resultado de la actualización de las propiedades. Validate también comprueba si la propiedad de extensión Confdir se encuentra en la línea de comandos. Validate verifica que la propiedad Confdir tiene un valor y, en caso de no ser así, sale con un estado de fallo y un mensaje de error. 

if ( (( $UPDATE_PROPERTY == 1 )) &&  (( CONFDIR_FOUND == 0 )) ); then
         config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
            -G $RESOURCEGROUP_NAME Confdir`
         CONFDIR=`echo $config_info | awk '{print $2}'`
fi

# Verify that the Confdir property has a value. If not there is a failure
# and exit with status 1
if [[ -z $CONFDIR ]]; then
         logger -p ${SYSLOG_FACILITY}.err \
            "${ARGV0} Validate method for resource "$RESOURCE_NAME " failed"
         exit 1
fi
Nota –

En concreto, el código anterior comprueba si se está llamando a Validate como resultado de la actualización ($UPDATE_PROPERTY == 1) y si la propiedad no se encuentra en la línea de comandos ( CONFDIR_FOUND == 0). En ese caso, el código recupera el valor existente de Confdir mediante scha_resource_get(). Si Confdir se encuentra en la línea de comandos (CONFDIR_FOUND == 1), el valor de CONFDIR proviene de la función parse_args() y no de scha_resource_get().

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

# Check if $CONFDIR is accessible.
if [ ! -d $CONFDIR ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} Directory $CONFDIR missing or not mounted"
   exit 1
fi

Antes de validar la actualización de la propiedad Confdir, Validate realiza una comprobación final para verificar si se encuentra el archivo named.conf. Si no lo está, el método registra un mensaje de error y sale con un estado de error. 

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

Si se supera la comprobación final, Validate registra un mensaje satisfactorio y sale con un estado de éxito. 

# Log a message indicating that the Validate method was successful.
logger -p ${SYSLOG_FACILITY}.err \
   -t [$SYSLOG_TAG] \
   "${ARGV0} Validate method for resource "$RESOURCE_NAME \
   " completed successfully"

exit 0

Estado de salida de Validate

Si Validate sale con éxito (0), se crea Confdir con el valor nuevo. Si, por el contrario, Validate sale con fallos (1), no se crean Confdir ni las demás propiedades y se genera un mensaje en el que se indica el motivo.

Funcionamiento del método Update

RGM ejecuta el método Update para notificar a un recurso en ejecución que se han modificado sus propiedades. RGM ejecuta Update después de que el administrador del clúster consiga configurar las propiedades de un recurso o su grupo. Este método se invoca en los nodos en los que el recurso esté en línea.

Comportamiento del método Update

El método Update no actualiza las propiedades, sino RGM. El método Update notifica a los procesos que se están ejecutando que se ha realizado una actualización. El único proceso del servicio de datos de ejemplo que se ve afectado por la actualización de propiedades es el supervisor de fallos. Por lo tanto, el único proceso que detiene y reinicia el método Update es el del supervisor.

El método Update debe comprobar que el supervisor de fallos se está ejecutando y, a continuación, desactivarlo con el comando pmfadm. El método obtiene la ubicación del programa de análisis que implementa el supervisor de fallos y lo reinicia con el comando pmfadm.

Parada del supervisor con Update

El método Update utiliza pmfadm -q para comprobar que el supervisor se está ejecutando y, si es así, lo desactiva con el comando pmfadm -s TERM. Si se finaliza con éxito el supervisor, se envía un mensaje en relación con esta acción al administrador del clúster. Si el supervisor no se puede detener, Update sale con un estado de fallo y envía un mensaje de error al administrador del clúster. 

if pmfadm -q $RESOURCE_NAME.monitor; then

# Kill the monitor that is running already
pmfadm -s $PMF_TAG TERM
    if [ $? -ne 0 ]; then
       logger -p ${SYSLOG_FACILITY}.err \
              -t [$SYSLOG_TAG] \
                 "${ARGV0} Could not stop the monitor"
       exit 1
    else
    # could successfully stop DNS. Log a message.
       logger -p ${SYSLOG_FACILITY}.err \
              -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                 "Monitor for HA-DNS successfully stopped"
    fi

Reinicio del supervisor

Para reiniciar el supervisor, el método Update debe encontrar la secuencia que implementa el programa de análisis. Éste reside en el directorio básico del servicio de datos, al que señala la propiedad Rt_basedir. Update recupera el valor de RT_basedir y lo guarda en la variable RT_BASEDIR, como se muestra a continuación. 

RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

Update utiliza el programa RT_BASEDIR con pmfadm para reiniciar el programa dns_probe. Si esta acción se realiza satisfactoriamente, Update sale con éxito y envía un mensaje en relación a esto al administrador del clúster. Si pmfadm no puede iniciar el programa de análisis, Update sale con un estado de fallo y registra un mensaje de error.

Estado de salida de Update

Un fallo del método Update hace que el recurso se ponga en estado de “actualización no satisfactoria”. Este estado no afecta a la administración del recurso por parte de RGM, pero indica el fallo de la actualización a las herramientas de administración mediante la función syslog().