Capítulo 5 Servicio de datos de ejemplo
Este capítulo describe un ejemplo del servicio de datos de Sun Cluster, HA-DNS, para la aplicación in.named. El daemon in.named es la implementación de Solaris del servicio de nombres de dominio (DNS). 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 órdenes del shell y una de programa C. La aplicación de ejemplo de este capítulo se escribe con aquélla.
La información de este capítulo incluye:
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 gestiona la Prestación del supervisor de procesos (PMF). Si las terminaciones de la aplicación superan el recuento de fallos de la ventana de tiempo de fallos, el supervisor de fallos realiza una operación de recuperación de fallos del grupo de recursos que contiene el recurso de la aplicación a otro nodo.
El servicio de datos de ejemplo proporciona una supervisión de fallos en forma de un método PROBE que utiliza la orden nslookup para garantizar que la aplicación esté en buen estado. Si el análisis detecta un servicio de DNS colgado, intentará corregir la situación reiniciando localmente la aplicación de DNS. Si esto no mejora la situación y el análisis sigue detectando problemas en el servicio, intentará realizar una operación de recuperación de fallos del servicio a otro nodo del clúster.
El servicio de datos de ejemplo incluye, concretamente:
-
Un archivo de registro del tipo de recurso que define las propiedades estáticas del servicio de datos.
-
Un método de rellamada Start invocado por RGM para que inicie el daemon in.named cuando el grupo de recursos que contiene el servicio de datos HA-DNS se ponga en línea.
-
Un método de rellamada Stop que invoca RGM para detener el daemon in.named cuando el grupo de recursos que contiene el HA-DNS pase a estar fuera de línea.
-
Un supervisor de fallos para comprobar la disponibilidad del servicio, verificando que el servidor de DNS esté en ejecución. Un método PROBE definido por el usuario implementa el supervisor; los métodos de rellamada Monitor_start y Monitor_stop lo inician y detienen.
-
Un método de rellamada Validate que invoca RGM para confirmar que el directorio de configuración del servicio está accesible.
-
Un método de rellamada Update invocado por RGM para reiniciar el supervisor de fallos cuando el administrador del sistema cambie el valor de una propiedad del recurso.
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.
RGM lee la información del archivo RTR cuando el administrador del clúster registra el servicio de datos de HA-DNS.
Información general del 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 drt_reg(4) y Establecimiento del recurso y las propiedades del tipo de recurso para obtener más información.
Esta sección describe las propiedades específicas del archivo RTR de ejemplo. Proporciona listados de partes diferentes del archivo. Para un listado completo 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.
# # Copyright (c) 1998-2004 by Sun Microsystems, Inc. # Reservados todos los derechos. # # Información de registro del servicio de nombres de dominio (DNS) # #pragma ident “@(#)SUNW.sample 1.1 00/05/24 SMI” RESOURCE_TYPE = “sample”; VENDOR_ID = SUNW; RT_DESCRIPTION = “Servicio de nombres de dominio en 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, el registro del tipo de recurso no será satisfactorio.
Nota –
RGM no diferencia entre mayúsculas y minúsculas en los nombres de las propiedades. La convención para las propiedades en los archivos RTR suministrados por Sun, salvo los nombres de métodos, es la utilización de mayúscula en el inicio del nombre y minúscula en el resto. Los nombres de métodos (y los atributos de las propiedades) contienen sólo mayúsculas.
A continuación se incluye alguna información sobre estas propiedades.
-
El nombre del tipo de recurso se puede especificar sólo con la propiedad Resource_type (sample) o con Vendor_id como un prefijo con “.” que lo separe del tipo de recurso (SUNW.sample).
Si utiliza Vendor_id, use el símbolo bursátil de la empresa que define el tipo de recurso. El nombre de éste debe ser exclusivo, dentro del clúster.
-
La propiedad Rt_version identifica la versión del servicio de datos de ejemplo según especifique el fabricante.
-
La propiedad API_version identifica la versión de Sun Cluster. Por ejemplo, API_version = 2, indica que el servicio de datos se ejecuta en Sun Cluster, versión 3.0.
-
Failover = TRUE indica que el servicio de datos no se puede ejecutar en un grupo de recursos que pueda estar en línea en varios nodos simultáneamente.
-
RT_basedir apunta a /opt/SUNWsample/bin como la ruta del directorio para completar las rutas relativas, como las rutas de los métodos de rellamada.
-
Start, Stop, Validate, etc. proporcionan las rutas a los programas de método de rellamada respectivos, invocados por RGM. Estas rutas son relativas al directorio que especifica RT_basedir.
-
Pkglist identifica SUNWsample como el paquete que contiene la instalación del servicio de datos de ejemplo.
Las propiedades del tipo de recurso que no se especifican en este archivo RTR, como Single_instance, Init_nodes y Installed_nodes tienen su valor predeterminado. Consulte la Tabla A–1 para ver una lista completa de las propiedades del tipo de recurso, incluidos sus valores predeterminados.
El administrador del clúster no puede cambiar los valores especificados para las propiedades del tipo de recurso en el 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; incluyen las propiedades definidas por el sistema, proporcionadas por Sun Cluster, y las propiedades de extensión definidas por el usuario. Para ambos tipo se pueden especificar varios atributos de propiedad proporcionados por Sun Cluster, como valores mínimo, máximo y predeterminado.
Propiedades definidas por el sistema en el archivo RTR
La lista siguiente muestra las propiedades definidas por el sistema en el archivo RTR de ejemplo.
# Una lista de declaraciones de propiedades del recurso entre llaves
# sigue a las declaraciones del tipo de recurso. La declaración del nombre de propiedad
# debe ser el primer atributo tras la llave abierta de cada entrada.
# Las propiedades <método>_timeout establecen el valor en segundos tras el cual
# RGM determina que la llamada del método no ha sido satisfactoria.
# El valor MIN para todos los tiempos de espera de los métodos es de 60 segundos.
# Así se impide que los administradores definan tiempos de espera menores, que no mejoran
# el rendimiento de las operaciones de conmutación/recuperación de fallos y pueden provocar
# acciones indeseadas de RGM (recuperaciones de fallos falsas, rearranque de nodo o
# desplazamiento del grupo de recursos a un estado ERROR_STOP_FAILED que requiera la
# intervención de un operador). Definir tiempos de espera demasiado cortos provoca una
# *disminución* en la disponibilidad global del servicio de datos.
{
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;
}
# El número de reintentos que se va a realizar en un determinado periodo antes de
# determinar que la aplicación no se puede iniciar satisfactoriamente en este nodo.
{
PROPERTY = Retry_Count;
MIN=0;
MAX=10;
DEFAULT=2;
TUNABLE = ANYTIME;
}
# Definir Retry_Interval como múltiplo de 60, porque se convierte de segundos
# a minutos, en un redondeo. Por ejemplo, un valor de 50 (segundos)
# se convierte en 1 minuto. Utilizar esta propiedad para cronometrar el número
# de reintentos (Retry_Count).
{
PROPERTY = Retry_Interval;
MIN=60;
MAX=3600;
DEFAULT=300;
TUNABLE = ANYTIME;
}
{
PROPERTY = Network_resources_used;
TUNABLE = AT_CREATION;
DEFAULT = ““;
}
Aunque Sun Cluster proporciona las propiedades definidas por el sistema, es posible definir diferentes valores predeterminados con los atributos de propiedades del recurso. Consulte Atributos de las propiedades de recursos para ver una lista completa de los atributos disponibles para aplicarlos a las propiedades del recurso.
Tenga presente lo siguiente sobre las propiedades de los recursos definidas por el sistema en el archivo RTR de ejemplo:
-
Sun Cluster proporciona un valor mínimo (1 segundo) y un valor predeterminado (3600 segundos) para todos los tiempos de espera. El archivo RTR de ejemplo cambia el mínimo a 60 y establece el valor predeterminado en 300 segundos. Un administrador del clúster puede aceptar este valor predeterminado o cambiar el valor del tiempo de espera (60 o superior). Sun Cluster no tiene un valor máximo permitido.
-
Las propiedades Thorough_Probe_Interval, Retry_count y Retry_interval tienen el atributo TUNABLE definido en ANYTIME. Esto significa que el administrador del clúster puede cambiar el valor de estas propiedades, aunque el servicio de datos esté en ejecución. Estas propiedades las utiliza el supervisor de fallos implementado por el servicio de datos de ejemplo que implementa un método Update para detener y reiniciar el supervisor de fallos cuando éstas u otras propiedades de recurso se modifican mediante una acción administrativa. Consulte Método Update.
-
Las propiedades de recurso se clasifican como
-
necesarias: el administrador del clúster debe especificar un valor cuando cree un recurso
-
opcionales: si el administrador no especifica ningún valor, el sistema proporciona un valor predeterminado
-
condicionales: RGM crea la propiedad sólo si está declarada en el archivo RTR
El supervisor de fallos del servicio de datos de ejemplo utiliza las propiedades condicionales Thorough_probe_interval, Retry_count, Retry_interval y Network_resources_used por lo que el desarrollador debe declararlas en el archivo RTR. Consulte la página de comando man r_properties(5) o Propiedades de recurso para obtener información sobre cómo se clasifican las propiedades.
-
Propiedades de extensión en el archivo RTR
Al final del archivo RTR de ejemplo se encuentran las propiedades de extensión:
# Propiedades de extensión
# El administrador del clúster debe definir el valor de esta propiedad para que apunte al
# directorio que contiene los archivos de configuración que utiliza la aplicación.
# Para esta aplicación, DNS, la ruta del archivo de configuración de DNS se especifica en
# PXFS (normalmente, named.conf).
{
PROPERTY = Confdir;
EXTENSION;
STRING;
TUNABLE = AT_CREATION;
DESCRIPTION = “La ruta al directorio de configuración”;
}
# Valor de tiempo de espera en segundos, antes de declarar que el análisis no ha sido
# satisfactorio.
{
PROPERTY = Probe_timeout;
EXTENSION;
INT;
DEFAULT = 120;
TUNABLE = ANYTIME;
DESCRIPTION = “Valor de tiempo de espera del análisis (segundos)”;
}
El archivo RTR de ejemplo define dos propiedades de extensión, Confdir y Probe_timeout. La primera especifica la ruta al directorio de configuración de DNS que contiene el archivo in.named necesario para que el DNS funcione satisfactoriamente. Los métodos Start y Validate del servicio de datos de ejemplo utilizan esta propiedad para verificar que el directorio de configuración y el archivo in.named sean accesibles antes de iniciar el 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 tanto, Sun Cluster no proporciona una propiedad Probe_timeout para él. El desarrollador ha definido una propiedad de extensión en el archivo RTR para permitir que un administrador del clúster configure un valor 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 órdenes y exportación de la ruta
La primera línea de una secuencia de órdenes del shell debe identificar el intérprete de éstas. Cada una de las secuencias de órdenes de los métodos del servicio de datos de ejemplo identifica el intérprete de órdenes como se indica a continuación:
#!/bin/ksh |
Todas las secuencias de órdenes del método de la aplicación de ejemplo exportan la ruta a los binarios y bibliotecas de Sun Cluster, en lugar de tener en cuenta 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 órdenes del método (salvo Validate) utilizan pmfadm para iniciar (o detener) el servicio de datos o el supervisor, pasando el nombre del recurso. Cada secuencia de órdenes 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 órdenes del método utiliza la orden logger para guardar los mensajes en el registro del sistema. Cada secuencia de órdenes define una variable, SYSLOG_TAG, que se puede pasar a logger con la opción -t para identificar el tipo de recurso, el grupo de recursos y el nombre de recurso del recurso para el que se está registrando el mensaje.
Todos los métodos definen SYSLOG_TAG del mismo modo, como muestra el ejemplo siguiente. Los métodos dns_probe, dns_svc_start, dns_svc_stop y dns_monitor_check definen PMF_TAG como se indica a continuación (la utilización de pmfadm y logger se produce desde el método dns_svc_stop):
#########################################################################
# MAIN
#########################################################################
PMF_TAG=$RESOURCE_NAME.named
SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME
# Enviar una señal SIGTERM al servicio de datos y esperar el 80% del
# valor total del tiempo de espera.
pmfadm -s $PMF_TAG.named -w $SMOOTH_TIMEOUT TERM
if [ $? -ne 0 ]; then
logger -p ${SYSLOG_FACILITY}.info \
-t [$SYSLOG_TAG] \
“${ARGV0} No se ha podido detener HA-DNS con SIGTERM; \
Reitentar con SIGKILL”
|
Los métodos dns_monitor_start, dns_monitor_stop y dns_update definen PMF_TAG como se indica a continuación (la utilización de pmfadm se realiza desde el método dns_monitor_stop):
######################################################################### # MAIN ######################################################################### PMF_TAG=$RESOURCE_NAME.monitor SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME ... # Verificar si el supervisor está en ejecución; si así fuera, detenerlo. if pmfadm -q $PMF_TAG.monitor; then pmfadm -s $PMF_TAG.monitor KILL |
Análisis de los argumentos de función
RGM invoca todos los métodos de rellamada, salvo Validate, como se indica a continuación.
nombre_método -R nombre_recurso -T nombre_tipo_recurso -G nombre_grupo_recurso |
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 al 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, los nombres del directorio básico y del método se especifican como se indica a continuación.
RT_BASEDIR=/opt/SUNWsample/bin; START = dns_svc_start; STOP = dns_svc_stop; ... |
Todos los argumentos del método de rellamada se pasan como valores con indicadores, donde -R indica el nombre de la instancia de recursos, -T, el tipo del recurso y -G, el grupo en el que se configura 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 –
El método Validate se invoca con argumentos adicionales (los valores de la propiedad del recurso y del grupo de recursos en el que se invoca). Consulte Manejo 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 se le pasan. 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.
A continuación se muestra la función parse_args() empleada para los métodos de rellamada en la aplicación de ejemplo.
#########################################################################
# Analizar argumentos del programa.
#
function parse_args # [args ...]
{
typeset opt
while getopts 'R:G:T:' opt
do
case "$opt" in
R)
# Nombre del recurso de DNS.
RESOURCE_NAME=$OPTARG
;;
G)
# Nombre del grupo de recursos en el que se ha configurado
# el recurso.
RESOURCEGROUP_NAME=$OPTARG
;;
T)
# Nombre del tipo de recurso.
RESOURCETYPE_NAME=$OPTARG
;;
*)
logger -p ${SYSLOG_FACILITY}.err \
-t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
"ERROR: Opción $OPTARG desconocida"
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 tanto, este método contiene una función de análisis idéntica a la que utilizan otros métodos de rellamada.
La función de análisis se invoca en MAIN como:
parse_args “$@” |
Generación de mensajes de error
Se recomienda que los métodos de rellamada utilicen la función syslog para enviar mensajes de error a los usuarios finales. Todos los métodos de rellamada del servicio de datos de ejemplo utilizan la función scha_cluster_get() para recuperar el número del recurso syslog utilizado para el registro del clúster, como se indica a continuación:
SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY` |
El valor se almacena en una variable del shell, SYSLOG_FACILITY, y se puede utilizar como el recurso de la orden logger para guardar mensajes en un registro del clúster. Por ejemplo, el método Start del servicio de datos de ejemplo recupera el recurso 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 iniciado satisfactoriamente"
fi
|
Consulte la página de comando man scha_cluster_get(1HA) para obtener más información.
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.
Hay dos tipos disponibles de propiedades de recurso: propiedades definidas por el sistema y propiedades de extensión; aquellas están predefinidas; éstas se definen en el archivo RTR.
Cuando se usa scha_resource_get() para obtener el valor de una propiedad definida por el sistema, se especifica el nombre de ésta con el parámetro -O. La orden sólo devuelve el valor de la propiedad. Por ejemplo, en el servicio de datos de ejemplo, el método Monitor_start necesita ubicar el programa de análisis para poder ejecutarlo; éste reside en el directorio básico del servicio de datos, señalado por la propiedad RT_BASEDIR. De esta manera el método Monitor_start recupera el valor de RT_BASEDIR y lo sitúa 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` |
Las propiedades de extension se deben especificar con la opción -O e indicar el nombre de la propiedad como el último parámetro. Para estas propiedades, la orden devuelve el tipo y el valor de la propiedad. Por ejemplo, en el servicio de datos de ejemplo, el programa de análisis recupera el tipo y el valor de la propiedad de extensión probe_timeout y después usa awk para poner el valor sólo en la variable del shell PROBE_TIMEOUT como se muestra 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 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().
Nota –
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.
Nota –
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.
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 se compone de:
-
dns_probe, un programa definido por el usuario que utiliza nslookup para comprobar que el recurso de DNS controlado por el servicio de datos de ejemplo esté en ejecución. Si no lo está, este método intenta reiniciarlo localmente o, dependiendo del número de intentos de reinicio, solicita que RGM reubique el servicio de datos en otro nodo.
-
dns_monitor_start, un método de rellamada que ejecuta dns_probe. RGM lo invoca automáticamente después de que el servicio de datos de ejemplo se ponga en línea, cuando la supervisión está habilitada.
-
dns_monitor_stop, un método de rellamada que detiene dns_probe. RGM lo invoca automáticamente antes de poner fuera de línea el servicio de datos de ejemplo.
-
dns_monitor_check, un método de rellamada que invoca el método Validate para verificar que el directorio de configuración esté disponible cuando el programa PROBE no pueda realizar una operación de recuperación de fallos del servicio de datos a otro nodo.
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 lo ejecuta el método dns_monitor_start, invocado automáticamente por RGM una vez el servicio de datos de ejemplo se ha puesto en línea. El servicio de datos lo detiene el método dns_monitor_stop, invocado por RGM antes de que el servicio de datos de ejemplo esté fuera de línea.
Esta sección describe los principales fragmentos del método PROBE 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 PROBE, consulte Programa PROBE.
Información general 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 éste está en ejecución, el análisis reposa durante un intervalo establecido (que fija la propiedad definida por el sistema Thorough_probe_interval) y luego realiza otra 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 necesita los valores de las propiedades siguientes:
-
Thorough_probe_interval, para fijar el periodo de reposo del análisis
-
Probe_timeout, para aplicar el valor de tiempo de espera del análisis en la orden nslookup que realiza el análisis
-
Network_resources_used, para obtener la dirección IP en la que se está ejecutando DNS
-
Retry_count y Retry_interval, para determinar el número de intentos de reinicio y el periodo durante el cual se deben contar
-
Rt_basedir, para obtener el directorio que contiene el programa PROBE y la utilidad gettime
La función scha_resource_get() obtiene los valores de estas propiedades y los guarda en variables del shell, como se indica 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 –
En el caso de propiedades definidas por el sistema, como Thorough_probe_interval, scha_resource_get() sólo devuelve el valor. En el caso de propiedades de extensión, como Probe_timeout, scha_resource_get() devuelve tanto el tipo como el valor. Utilice la orden awk para obtener sólo el valor.
Comprobación de la fiabilidad del servicio
El análisis en sí es un bucle while infinito de órdenes nslookup. Antes del bucle while, se configura un archivo temporal para contener las respuestas de nslookup. Las variables probefail y retries se inicializan a 0.
# Configurar un archivo temporal para las respuestas de nslookup. DNSPROBEFILE=/tmp/.$RESOURCE_NAME.probe probefail=0 retries=0 |
-
Establece el intervalo de reposo para el análisis
-
Utiliza hatimerun para ejecutar nslookup, pasando el valor Probe_timeout e identificando el sistema de destino
-
Establece la variable probefail en función del éxito o fracaso del código de retorno de nslookup
-
Si se establece probefail en 1 (fallo), verifica que la respuesta a nslookup haya provenido del servicio de datos de ejemplo y no de algún otro servidor de DNS
Éste es el código bucle while.
while :
do
# El intervalo al que se debe ejecutar el análisis se especifica en la
# propiedad THOROUGH_PROBE_INTERVAL. Por tanto, establecer el análisis en
# reposo durante el tiempo que indica THOROUGH_PROBE_INTERVAL.
sleep $PROBE_INTERVAL
# Ejecutar una orden nslookup de la dirección IP en la que sirve DNS.
hatimerun -t $PROBE_TIMEOUT /usr/sbin/nslookup $DNS_HOST $DNS_HOST \
> $DNSPROBEFILE 2>&1
retcode=$?
if [ $retcode -ne 0 ]; then
probefail=1
fi
# Asegurarse de que la respuesta a nslookup provenga del servidor
# de HA-DNS y no de otro servidor de nombres mencionado en el
# archivo /etc/resolv.conf.
if [ $probefail -eq 0 ]; then
# Obtener el nombre del servidor que ha respondido a la consulta de nslookup.
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
|
Evaluación de reinicio frente a recuperación de fallos
Si la variable probefail es distinta de 0 (satisfactorio), significa que la orden nslookup agotó el tiempo de espera o que la respuesta ha provenido de un servidor diferente 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 que indica que el análisis ha sido satisfactorio.
if [ $probefail -ne 0 ]; then
decide_restart_or_failover
else
logger -p ${SYSLOG_FACILITY}.err\
-t [$SYSLOG_TAG]\
"${ARGV0} Análisis del recurso HA-DNS satisfactorio"
fi
|
La función decide_restart_or_failover() utiliza una ventana de tiempo (Retry_interval) y un recuento de fallos (Retry_count) para determinar si debe reiniciar el DNS localmente o solicitar que RGM reubique el servicio de datos en otro nodo. Implementa el siguiente código condicional (consulte la lista de códigos para decide_restart_or_failover() en Programa PROBE).
-
Si es el primer fallo, se reinicia el servicio de datos. Se registra un mensaje de error y se detiene el contador de la variable retries.
-
Si no es el primer fallo, pero se ha superado la ventana de tiempo, se reinicia el servicio de datos. Se registra un mensaje de error, se pone a cero el contador y se desliza la ventana.
-
Si el tiempo sigue dentro de la ventana y el contador de reintentos se ha superado, se produce una recuperación de fallos a otro nodo. Si la operación de recuperación de fallos no es satisfactoria, se registra un error y se sale del programa de análisis con el estado 1 (fallo).
-
Si el tiempo sigue dentro de la ventana, pero no se ha superado el contador de reintentos, se reinicia el servicio de datos. Se registra un mensaje de error y se detiene el contador de la variable retries.
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:
-
La utilidad gettime se utiliza para realizar un seguimiento del tiempo entre los reinicios. Se trata de un programa de C que reside en el directorio (Rt_basedir).
-
Las propiedades definidas por el sistema Retry_count y Retry_interval determinan el número de intentos de reinicio y el intervalo en el que se deben realizar. Estas propiedades toman el valor predeterminado de 2 intentos en un periodo de 5 minutos (300 segundos) en el archivo RTR, aunque el administrador del clúster puede cambiarlo.
-
La función restart_service() se invoca para reiniciar el servicio de datos en el mismo nodo. Consulte la sección siguiente, Reinicio del servicio de datos, para obtener información sobre esta función.
-
La función de API scha_control(), con la opción GIVEOVER, pone el grupo de recursos que contiene el servicio de datos de ejemplo fuera de línea y lo vuelve a poner en línea en otro nodo.
Reinicio del servicio de datos
La función restart_service() la invoca decide_restart_or_failover() para intentar reiniciar el servicio de datos en el mismo nodo. Esta función realiza lo siguiente:
-
Determina si el servicio de datos sigue registrado bajo PMF. Si el servicio sigue registrado, la función:
-
Obtiene el nombre del método Stop y el valor Stop_timeout del servicio de datos.
-
Utiliza hatimerun para ejecutar el método Stop para el servicio de datos, pasando el valor Stop_timeout.
-
(Si el servicio de datos se detiene satisfactoriamente) obtiene el nombre del método Start y el valor Start_timeout para el servicio de datos.
-
Utiliza hatimerun para ejecutar el método Start para el servicio de datos, pasando el valor Start_timeout.
-
-
Si el servicio de datos ya no está registrado bajo PMF, ello quiere decir que el servicio de datos ha superado el número máximo de reintentos permitidos según PMF, por lo que la función scha_control() se invoca con la opción GIVEOVER para realizar una operación de recuperación de fallos del servicio de datos a otro nodo.
function restart_service
{
# Para reiniciar el servicio de datos, comprobar primero que
# éste siga registrado en PMF.
pmfadm -q $PMF_TAG
if [[ $? -eq 0 ]]; then
# Dado que TAG para el servicio de datos sigue registrado
# en PMF, detener el servicio de datos y volver a iniciarlo.
# Obtener el nombre del método Stop y el valor de STOP_TIMEOUT
# para este recurso.
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
# Obtener el nombre del método START y el valor
# de START_TIMEOUT para este recurso.
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} Método de inicio no satisfactorio.”
return 1
fi
else
# La ausencia de TAG para el servicio de datos
# implica que el servicio de datos ya ha superado el
# número máximo de reintentos permitidos en PMF.
# No intentar reiniciar el servicio de datos otra vez;
# intentar realizar una operación de recuperación de
# fallos a otro nodo del clúster.
scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \
-R $RESOURCE_NAME
fi
return 0
}
|
Consultar el estado de salida
El programa PROBE del servicio de datos de ejemplo sale con un fallo si los intentos de reinicio local han fallado y el intento de realizar una recuperación de fallos a otro nodo también. Registra el mensaje “Intento de recuperación de fallos no satisfactorio”.
Método Monitor_start
RGM invoca el método Monitor_start para ejecutar el método dns_probe después de que el servicio de datos de ejemplo se ponga en línea.
Esta sección describe los principales fragmentos del método Monitor_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 describen en Funciones comunes para todos los métodos.
Para una lista completa del método Monitor_start, consulte Método Monitor_start.
Información general de Monitor_start
Este método utiliza el recurso del supervisor de procesos (pmfadm) para ejecutar 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 ejecuta el análisis con la opción de reintentos infinitos de pmfadm (-n -1, -t -1), lo que significa que si el análisis no se inicia, PMF intenta iniciarlo un número infinito de veces durante un periodo de tiempo infinito.
# Buscar dónde reside el programa de análisis mediante la obtención # del valor de la propiedad RT_BASEDIR del recurso. RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G \ $RESOURCEGROUP_NAME` # Iniciar el análisis del servicio de datos en PMF. Utilizar la opción de reintentos # infinitos para iniciar el análisis. Pasar el nombre de recurso, tipo y grupo al # programa de análisis. pmfadm -c $RESOURCE_NAME.monitor -n -1 -t -1 \ $RT_BASEDIR/dns_probe -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME |
Método Monitor_stop
RGM invoca el 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.
Esta sección describe los principales fragmentos del método Monitor_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 describen en Funciones comunes para todos los métodos.
Para una lista completa del método Monitor_stop, consulte Método Monitor_stop.
Información general de Monitor_stop
Este método utiliza el recurso del supervisor de procesos (pmfadm) para ver si el análisis está en ejecución y, en caso de que lo esté, 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.
# Consultar si el supervisor está en ejecución. Si es así, terminarlo.
if pmfadm -q $PMF_TAG; then
pmfadm -s $PMF_TAG KILL
if [ $? -ne 0 ]; then
logger -p ${SYSLOG_FACILITY}.err \
-t [$SYSLOG_TAG] \
"${ARGV0} No se puede detener el supervisor del recurso " \
$RESOURCE_NAME
exit 1
else
# se ha detenido satisfactoriamente el supervisor. Registrar un mensaje.
logger -p ${SYSLOG_FACILITY}.err \
-t [$SYSLOG_TAG] \
"${ARGV0} "${ARGV0} Supervisor del recurso " $RESOURCE_NAME \
" detenido satisfactoriamente"
fi
fi
exit 0
|
Precaución – Asegúrese de usar la señal de KILL con pmfadm para detener el análisis y no una señal enmascarable, como TERM. En caso contrario, el método Monitor_stop puede quedar indefinidamente bloqueado hasta agotar el tiempo de espera. El motivo de este problema es que el método PROBE invoca scha_control() cuando hay que reiniciar o realizar una operación de recuperación de fallos del servicio de datos. Cuando scha_control() invoca Monitor_stop dentro del proceso de poner el servicio de datos fuera de línea, si Monitor_stop utiliza una señal enmascarable, se queda bloqueado esperando que scha_control() finalice y scha_control() se bloquea, esperando que Monitor_stop termine.
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 pone el servicio de datos de ejemplo en el estado MONITOR_FAILED en el nodo primario, lo que puede enviar un aviso grave al nodo.
Monitor_stop no debería salir antes de que se haya detenido el análisis.
Método Monitor_check
RGM invoca el método Monitor_check cuando el método PROBE intenta realizar una recuperación de fallos del grupo de recursos que contiene el servicio de datos a otro nodo.
Esta sección describe los fragmentos principales del método Monitor_check 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 describen en Funciones comunes para todos los métodos.
Para una lista completa del método Monitor_check, consulte Método Monitor_check.
El método Monitor_check se debe implementar de forma que no entre en conflicto con la ejecución simultánea de otros métodos.
El método Monitor_check invoca el 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 apunta al directorio de configuración de DNS. Por tanto, Monitor_check obtiene la ruta y el nombre del método Validate y el valor de Confdir. Pasa este valor a Validate, como muestra la lista siguiente.
# Obtener la ruta completa del método Validate desde
# la propiedad RT_BASEDIR del tipo de recurso.
RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAMÈ
# Obtener el nombre del método Validate para este recurso.
VALIDATE_METHOD=`scha_resource_get -O VALIDATE \
-R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
# Obtener el valor de la propiedad Confdir para iniciar el servicio
# de datos. Utilizar el nombre de recurso y grupo de recursos introducidos
# para obtener el valor Confdir establecido 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 para las propiedades de
# extensión. Utilizar awk para obtener sólo el valor de la propiedad de extensión.
CONFIG_DIR=`echo $config_info | awk `{print $2}'`
# Invocar el método validate para que el servicio de datos se pueda
# recuperar de un fallo a otro nodo satisfactoriamente.
$RT_BASEDIR/$VALIDATE_METHOD -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
-T $RESOURCETYPE_NAME -x Confdir=$CONFIG_DIR
|
Consulte Método Validate para ver cómo verifica la aplicación de ejemplo la adecuación de un nodo para alojar el servicio de datos.
Manejo 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 maneje la actualización de las propiedades.
Método Validate
RGM invoca el 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 invoca Validate sólo cuando se cambian las propiedades del recurso o del grupo mediante una acción administrativa, no cuando RGM establece propiedades ni cuando un supervisor establece las propiedades de recurso Status y Status_msg.
Nota –
El método Monitor_check invoca también explícitamente el método Validate cuando el método PROBE intenta realizar una operación de recuperación de fallos del servicio de datos a otro nodo.
Información general de Validate
RGM invoca Validate con argumentos adicionales a los que se pasan a otros métodos, incluidos las propiedades y los valores que se están actualizando. Por tanto, este método en el servicio de datos de ejemplo debe implementar una función parse_args() diferente para manejar argumentos adicionales.
El método Validate del servicio de datos de ejemplo verifica una única propiedad, la propiedad de extensión Confdir. Esta propiedad apunta 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 tanto, el método Validate no se invoca nunca para verificar la propiedad Confdir tras una actualización; sólo se invoca durante la creación del recurso de 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. Después, Validate verifica que el directorio al que señala el nuevo valor de Confdir esté accesible y que el archivo named.conf exista en el directorio y contenga datos.
Si la función parse_args() no puede recuperar el valor de Confdir desde los argumentos de línea de órdenes que pasa RGM, Validate seguirá intentando validar la propiedad Confdir. Validate utiliza scha_resource_get() para obtener el valor de Confdir desde la configuración estática. Después realiza las mismas comprobaciones para comprobar que el directorio de configuración esté accesible y contenga un archivo named.conf que no esté 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
RGM pasa al método Validate un conjunto diferente de parámetros que los otros métodos de rellamada, por lo que Validate necesita una función para analizar argumentos diferente de la de los demás métodos. Consulte la página de comando man rt_callbacks(1HA) para obtener más información sobre los parámetros que se pasan a Validate y los demás métodos de rellamada. A continuación se muestra la función parse_args() de Validate.
#########################################################################
# Analizar argumentos de Validate.
#
function parse_args # [args...]
{
typeset opt
while getopts 'cur:x:g:R:T:G:' opt
do
case "$opt" in
R)
# Nombre del recurso de DNS.
RESOURCE_NAME=$OPTARG
;;
G)
# Nombre del grupo de recursos en el que se ha configurado
# el recurso.
RESOURCEGROUP_NAME=$OPTARG
;;
T)
# Nombre del tipo de recurso.
RESOURCETYPE_NAME=$OPTARG
;;
r)
# El método no está accediendo a ninguna propiedad
# definida por el sistema, por lo que no tiene ninguna
# operación
;;
g)
# El método no está accediendo a ninguna propiedad de
# grupo de recursos, por lo que no tiene ninguna operación
;;
c)
# Indica que se está invocando el método Validate mientras
# se crea el recurso, por lo que el indicador no tiene ninguna
# operación
;;
u)
# Indica la actualización de una propiedad cuando el recurso
# ya existe. Si la actualización es de la propiedad Confdir,
# ésta debería aparecer en los argumentos de la línea de
# órdenes. En caso contrario, el método debe buscarlo
# específicamente con scha_resource_get.
UPDATE_PROPERTY=1
;;
x)
# Lista de propiedades de extensión. Separar los pares de
# propiedad y valor con "=" como separador.
PROPERTY=`echo $OPTARG | awk -F= '{print $1}'`
VAL=`echo $OPTARG | awk -F= '{print $2}'`
# Si la propiedad de extensión Confdir se encuentra en la
# línea de órdenes, anotar su valor.
if [ $PROPERTY == "Confdir" ]; then
CONFDIR=$VAL
CONFDIR_FOUND=1
fi
;;
*)
logger -p ${SYSLOG_FACILITY}.err \
-t [$SYSLOG_TAG] \
"ERROR: Option $OPTARG desconocida"
exit 1
;;
esac
done
}
|
Al igual que con la función parse_args() para otros métodos, esta función proporciona un indicador (R) para capturar el nombre de recurso, (G) para capturar el nombre de grupo de recurso y (T) para capturar el tipo de recurso que ha pasado RGM.
Los indicadores r (que indica una propiedad definida por el sistema), g (que indica una propiedad de grupo de recursos) y c (que indica que la validación se produce durante la creación del recurso) se ignoran porque este método se invoca para validar una propiedad de extensión cuando el recurso se está actualizando.
El indicador u establece el valor de la variable del shell UPDATE_PROPERTY en 1 (TRUE). El indicador x captura los nombres y valores de las propiedades que se están actualizando. Si Confdir es una de las propiedades que se está actualizando, su valor se sitúa en la variable del shell CONFDIR y CONFDIR_FOUND se establece en 1 (TRUE).
Validación de Confdir
En su función MAIN, Validate establece primero la variable CONFDIR en la secuencia vacía y UPDATE_PROPERTY y CONFDIR_FOUND en 0.
CONFDIR="" UPDATE_PROPERTY=0 CONFDIR_FOUND=0 |
Después, Validate invoca parse_args() para analizar los argumentos que pasa RGM.
parse_args “$@” |
Validate comprueba entonces si se está invocando Validate por una actualización de propiedades y si la propiedad de extensión Confdir estaba en la línea de órdenes Validate verifica si la propiedad Confdir tiene un valor y, en caso contrario, 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
# Verificar que la propiedad Confdir tiene un valor. En caso contrario,
# hay un fallo y sale con estado 1
if [[ -z $CONFDIR ]]; then
logger -p ${SYSLOG_FACILITY}.err \
"${ARGV0} Método de validar el recurso "$RESOURCE_NAME " no satisfactorio"
exit 1
fi
|
Nota –
Específicamente, el código anterior comprueba si una actualización ($UPDATE_PROPERTY == 1) está invocando Validate y si la propiedad no se ha encontrado en la línea de órdenes (CONFDIR_FOUND == 0), en cuyo caso recupera el valor existente de Confdir con scha_resource_get(). Si se encontró Confdir en la línea de órdenes (CONFDIR_FOUND == 1), el valor de CONFDIR proviene de la función parse_args(), no de scha_resource_get().
El método Validate usa el valor de CONFDIR para verificar que el directorio es accesible. Si no lo fuera, Validate registraría un mensaje de error y cerraría con un estado de error.
# Comprobar si $CONFDIR es accesible.
if [ ! -d $CONFDIR ]; then
logger -p ${SYSLOG_FACILITY}.err \
-t [$SYSLOG_TAG] \
"${ARGV0} Directorio $CONFDIR falta o no está montado"
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. En caso de que no se encuentre, el método registra un mensaje de error y sale con un estado de error.
# Comprobar que el archivo named.conf esté presente en el directorio Confdir
if [ ! -s $CONFDIR/named.conf ]; then
logger -p ${SYSLOG_FACILITY}.err \
-t [$SYSLOG_TAG] \
"${ARGV0} El archivo $CONFDIR/named.conf falta o está vacío"
exit 1
fi
|
Si se supera la comprobación final, Validate registra un mensaje que indica que la operación ha sido satisfactoria y sale con estado satisfactorio.
# Registrar un mensaje que indique que el método Validate ha sido satisfactorio.
logger -p ${SYSLOG_FACILITY}.err \
-t [$SYSLOG_TAG] \
"${ARGV0} Método de validar para el recurso "$RESOURCE_NAME \
" se ha completado satisfactoriamente"
exit 0
|
Estado de salida de Validate
Si Validate sale con éxito (0), se crea Confdir con el nuevo valor. Si Validate sale con fallo (1), no se crea Confdir ni ninguna otra propiedad y se envía un mensaje al administrador del clúster.
Método Update
RGM invoca el método Update para notificar a un recurso en ejecución que se han modificado sus propiedades. RGM invoca Update después de que una acción administrativa establezca satisfactoriamente las propiedades de un recurso o del grupo al que pertenece. Este método se invoca en los nodos en los que el recurso está en línea.
Información general de Update
El método Update no actualiza las propiedades, de eso se encarga RGM. En su lugar, notifica a los procesos en ejecución que se ha producido una actualización. El único proceso del servicio de datos de ejemplo que está afectado por una actualización de una propiedad es el supervisor de fallos, por lo que es este proceso el que detiene y reinicia el método Update.
El método Update debe comprobar que el supervisor de fallos esté en ejecución y terminarlo con pmfadm. El método obtiene la ubicación del programa de análisis que implementa el supervisor de fallos y lo reinicia otra vez con pmfadm.
Parada del supervisor con Update
El método Update utiliza pmfadm -q para verificar que el supervisor se esté ejecutando y, en caso de que sea así, lo termina con pmfadm -s TERM. Si el supervisor se termina satisfactoriamente, se envía un mensaje para indicárselo al usuario administrativo. Si el supervisor no se puede detener, Update sale con un estado de fallo y envía un mensaje de error al usuario administrativo.
if pmfadm -q $RESOURCE_NAME.monitor; then
# Terminar el supervisor que se está ejecutando
pmfadm -s $PMF_TAG TERM
if [ $? -ne 0 ]; then
logger -p ${SYSLOG_FACILITY}.err \
-t [$SYSLOG_TAG] \
"${ARGV0} No se puede detener el supervisor"
exit 1
else
# se ha podido detener satisfactoriamente el DNS. Registrar un
# mensaje.
logger -p ${SYSLOG_FACILITY}.err \
-t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
"Supervisor para HA-DNS detenido satisfactoriamente"
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 usa el valor de RT_BASEDIR con pmfadm para reiniciar el programa dns_probe. Si la operación es satisfactoria, Update sale con éxito y envía un mensaje para indicárselo al usuario administrativo. Si pmfadm no puede ejecutar el programa de análisis, Update sale con 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 gestión de RGM del recurso, pero indica el fallo de la acción de actualización a las herramientas de administración, a través del recurso syslog.
- © 2010, Oracle Corporation and/or its affiliates