test

Guide des développeurs pour les services de données Sun Cluster pour SE Solaris

Chapitre 5 Service de données modèle

Ce chapitre décrit un service de données Sun Cluster modèle, HA-DNS, pour l'application in.named. Le démon in.named constitue la mise en œuvre, sous Solaris, du service DNS (Domain Name Service). Ce service de données modèle montre comment rendre une application hautement disponible à l'aide de l'API de gestion des ressources.

Celle-ci prend en charge une interface de script Shell ainsi qu'une interface de programme C. L'application modèle présentée dans ce chapitre est rédigée à l'aide de l'interface de script Shell.

Les informations fournies par ce chapitre sont les suivantes :

Présentation du service de données modèle

Le service de données modèle lance, arrête, redémarre et bascule l'application DNS entre les nœuds du cluster en réponse à des événements de cluster, tels qu'une action de l'administrateur, un échec d'application ou une erreur de nœud.

Le redémarrage de l'application est géré par le gestionnaire de processus. Si les morts d'application dépassent le nombre d'échecs autorisés pour le délai de comptabilisation des erreurs, le détecteur de pannes bascule le groupe de ressources contenant la ressource d'application vers un autre nœud.

Le service de données modèle fournit une surveillance des pannes sous la forme d'une méthode PROBE. Celle-ci utilise la commande nslookup pour s'assurer que l'application est saine. Si la sonde détecte un service DNS bloqué, elle tente de rectifier la situation en redémarrant l'application DNS localement. Si cette opération ne résout pas le problème et si la sonde détecte à plusieurs reprises des blocages de ce service, elle tente de le basculer vers un autre nœud du cluster.

Plus particulièrement, le service de données modèle comprend :

Définition du fichier d'enregistrement du type de ressource

Le fichier d'enregistrement du type de ressource (RTR) de cet exemple définit la configuration statique du type de ressource DNS. Les ressources de ce type héritent des propriétés définies dans le fichier RTR.

Les informations contenues dans le fichier RTR sont lues par le RGM lorsque l'administrateur du cluster enregistre le service de données HA-DNS.

Présentation du fichier RTR

Le fichier RTR suit un format bien défini. Les propriétés du type de ressources sont définies en premier lieu dans le fichier, suivent les propriétés de ressource définies par le système, puis les propriétés d'extension. Reportez-vous à la page man rt_reg(4) et à la rubrique Paramétrage des propriétés de ressources et de types de ressources pour de plus amples informations.

Cette rubrique décrit les propriétés spécifiques du fichier RTR modèle. Elle fournit également une liste des différentes parties du fichier. Pour obtenir une liste complète du contenu de ce fichier, reportez-vous à la rubrique Liste de code du fichier RTR.

Propriétés du type de ressource dans le fichier RTR modèle

Le fichier RTR modèle commence par des commentaires, suivis des propriétés du type de ressource définissant la configuration de HA-DNS, comme vous pouvez le voir dans la liste suivante : 

#
# Copyright (c) 1998-2003 by Sun Microsystems, Inc.
# Tous droits réservés
#
# Informations relatives à l’enregistrement du service DNS (Domain Name Service)
#

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

RESOURCE_TYPE = “sample”;
VENDOR_ID = SUNW;
RT_DESCRIPTION = “Service DNS sur 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;
Astuce –

la propriété Resource_type doit être déclarée en tant que première entrée dans le fichier RTR. Dans le cas contraire, l'enregistrement du type de ressources échoue.

Remarque –

le RGM est insensible à la casse dans les noms de propriété. Les fichiers RTR fournis par Sun sont basés sur la convention suivante : la première lettre du nom est en majuscules tandis que toutes les autres sont en minuscules. Cette convention s'applique aux noms de propriété mais pas aux noms de méthode. Les noms de méthodes et les attributs de propriété sont en majuscules.

Vous trouverez présentées ci-dessous des informations sur ces propriétés :

Les propriétés du type de ressource non spécifiées dans ce fichier RTR, par exemple Single_instance, init_nodes et Installed_nodes, reçoivent leur valeur par défaut. La rubrique Propriétés des types de ressources présente la liste complète des propriétés de type de ressources avec leur valeur par défaut.

L'administrateur du cluster ne peut pas modifier les valeurs spécifiées pour les propriétés du type de ressource dans le fichier RTR.

Propriétés de ressource dans le fichier RTR modèle

Par convention, déclarez les propriétés de ressource selon les propriétés du type de ressource dans le fichier RTR. Les propriétés de ressource comprennent les propriétés définies par le système et fournies par Sun Cluster, ainsi que les propriétés d'extension définies par l'utilisateur. Pour chaque type, vous pouvez spécifier un nombre d'attributs de propriété fournis par Sun Cluster, telles que des valeurs minimum et maximum ainsi que des valeurs par défaut.

Propriétés définies par le système dans le fichier RTR

La liste énumérée ci-dessous présente les propriétés définies par le système dans le fichier RTR. 

# Une liste des déclarations de propriétés de ressources entre crochets suit les
# déclarations relatives au type de ressource. La déclaration du nom de la propriété doit
# être le premier attribut après le crochet ouvrant de chaque entrée.

# Les propriétés <méthode>_timeout définissent le délai (en secondes) après lequel
# le RGM conclut que l’appel de la méthode a échoué

# La valeur MIN de tous les délais impartis de la méthode est définie à 60 secondes. Ceci
# évite que les administrateurs définissent des délais plus courts qui non seulement
# n’améliorent pas les performances de basculement, mais peuvent générer des actions
# non souhaitées de la part du RGM (basculements erronés, réinitialisation de nœuds
# ou passage du groupe de ressources à l’état ERROR_STOP_FAILED, requérant une intervention
# de l’opérateur). La définition de délais trop courts pour la méthode entraîne une
# *diminution* de la disponibilité générale du service de données.
{  
   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;
}

# Le nombre de nouvelles tentatives à effectuer au cours d’une période donnée avant de conclure
# que l’application ne peut pas démarrer correctement sur ce nœud.
{
        PROPERTY = Retry_Count;
        MIN=0;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME; 
}

# Définissez une valeur multiple de 60 pour Retry_interval, étant donné que
# cette valeur est convertie de secondes en minutes, avec arrondissement au chiffre supérieur.
# Par exemple, une valeur de 50 (secondes) est convertie en 1 minute. Utilisez cette propriété
# pour établir le délai séparant les nouvelles tentatives (Retry_count).
{
        PROPERTY = Retry_Interval;
        MIN=60;
        MAX=3600;
        DEFAULT=300;
        TUNABLE = ANYTIME;
}

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

Bien que Sun Cluster fournisse les propriétés définies par le système, vous pouvez définir d'autres valeurs par défaut à l'aide des attributs de propriété de ressource. Reportez-vous à la rubrique Attributs des propriétés de ressources pour une liste complète des attributs disponibles pour une application aux propriétés de ressource.

Remarquez les points suivants sur les propriétés de ressource définies par le système dans le fichier RTE modèle :

Propriétés d'extension dans le fichier RTR

Les propriétés d'extension se trouvent à la fin du fichier RTR modèle, comme le montre la liste suivante : 

# Propriétés d’extension

# L’administrateur du cluster doit définir la valeur de cette propriété afin qu’elle pointe vers
# le répertoire contenant les fichiers de configuration utilisés par l’application.
# Pour cette application, DNS, spécifiez le chemin du fichier de configuration DNS sur
# PXFS (généralement named.conf).
{
   PROPERTY = Confdir;
   EXTENSION;
   STRING;
   TUNABLE = AT_CREATION;
   DESCRIPTION = “Chemin du répertoire de configuration”;
}

# Délai en secondes avant la déclaration d’un échec de la sonde.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Délai imparti pour la sonde (secondes)”;
}

Le fichier RTR modèle définit deux propriétés d'extension, Confdir et Probe_timeout. Confdir spécifie le chemin vers le répertoire de configuration DNS. Ce répertoire contient le fichier in.named requis par le DNS pour fonctionner correctement. Les méthodes Start et Validate du service de données modèle utilisent cette propriété pour vérifier que le répertoire de configuration et le fichier in.named sont accessibles avant de démarrer le DNS.

Lorsque le service de données est configuré, la méthode Start vérifie que le nouveau répertoire est accessible.

La méthode PROBE du service de données modèle n'est pas une méthode de rappel de Sun Cluster, mais une méthode définie par l'utilisateur. C'est la raison pour laquelle Sun Cluster ne propose aucune propriété Probe_timeout pour celle-ci. Le développeur a défini une propriété d'extension dans le fichier RTR afin de permettre à un administrateur de cluster de configurer une valeur Probe_timeout.

Fonctionnalité commune à toutes les méthodes

Cette rubrique décrit la fonctionnalité suivante, utilisée dans toutes les méthodes de rappel du service de données modèle :

Identification de l'interpréteur de commandes et exportation du chemin

La première ligne d'un script Shell doit identifier l'interpréteur de commandes. Chacun des scripts de méthode du service de données modèle identifie l'interpréteur de commandes de la manière suivante :


#!/bin/ksh

Tous les scripts de méthode de l’application modèle exportent le chemin vers les binaires et les bibliothèques de Sun Cluster au lieu de se fier aux paramètres PATH de l’utilisateur. 


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

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

Déclaration des variables PMF_TAG et SYSLOG_TAG

Tous les scripts de méthode (à l’exception de Validate) utilisent pmfadm pour lancer (ou arrêter) le service de données ou le détecteur, en transmettant le nom de la ressource. Chaque script définit une variable PMF_TAG pouvant être transmise à pmfadm pour identifier le service de données ou le détecteur.

De la même manière, chaque script de méthode a recours à la commande logger pour consigner des messages dans le journal système. Chaque script définit une variable SYSLOG_TAG pouvant être transmise à logger avec l'option -t pour identifier le type de ressource, le groupe de ressources ainsi que le nom de la ressource pour laquelle est consigné le message.

Toutes les méthodes définissent SYSLOG_TAG de la même manière, comme l'indique l'exemple suivant. Les méthodes dns_probe, dns_svc_start, dns_svc_stop et dns_monitor_check définissent PMF_TAG comme suit (l'usage de pmfadm et logger provient de la méthode dns_svc_stop) : 


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

PMF_TAG=$RESOURCE_NAME.named

SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME

   # Envoi d’un signal SIGTERM au service de données et attente pendant 80 % du
# délai total imparti.
   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”

Les méthodes dns_monitor_start, dns_monitor_stop et de dns_update définissent PMF_TAG comme suit (l'usage de pmfadm provient de la méthode dns_monitor_stop) : 


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

PMF_TAG=$RESOURCE_NAME.monitor
SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME
...

# Voir si le détecteur tourne et, le cas échéant, l'arrêter. 
if pmfadm -q $PMF_TAG.monitor; then 
   pmfadm -s $PMF_TAG.monitor KILL

Analyse des arguments de la fonction

Le RGM appelle toutes les méthodes de rappel, à l'exception de Validate, de la manière suivante : 


 nom_méthode -R nom_ressource -T nom_type_ressource -G  nom_groupe_ressources

Le nom de la méthode correspond au nom de chemin d'accès du programme mettant en œuvre la méthode de rappel. Un service de données spécifie le nom de chemin d’accès de chaque méthode du fichier RTR. Ces noms de chemin correspondent au répertoire spécifié par la propriété RT_basedir, également dans le fichier RTR. Par exemple, dans le fichier RTR du service de données modèle, le répertoire de base et les noms des méthodes sont spécifiés de la manière suivante : 


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

Tous les arguments des méthodes de rappel sont transmis comme des valeurs marquées, avec -R indiquant le nom de l'instance de la ressource, -T indiquant le type de la ressource et -G indiquant le groupe dans lequel est configurée la ressource. Reportez-vous à la page man rt_callbacks (1HA) pour de plus amples informations sur les méthodes de rappel.

Remarque –

La méthode Validate est appelée avec des arguments supplémentaires (les valeurs des propriétés de la ressource et du groupe de ressources ciblées par l'appel). Reportez-vous à la rubriqueGestion des mises à jour des propriétés pour de plus amples informations.

Chaque méthode de rappel a besoin d'une fonction pour analyser les arguments transmis. Tous les rappels étant transmis avec les mêmes arguments, le service de données fournit une seule fonction d'analyse employée dans tous les rappels de l'application.

L'exemple suivant montre l'utilisation de la fonction parse_args() pour les méthodes de rappel de l'application modèle. 


#########################################################################
# Analyse des arguments du programme.
#
function parse_args # [args ...]
{
      typeset opt

      while getopts 'R:G:T:' opt
      do
             case "$opt" in
             R)
                  # Nom de la ressource DNS.
                  RESOURCE_NAME=$OPTARG
                  ;;
             G)
                  # Nom du groupe de ressources dans laquelle est
# configurée la ressource.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
             T)
                  # Nom du type de ressources.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
             *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                  "ERROR: Option $OPTARG unknown"
                  exit 1
                      ;;
             esac
    done
}

Remarque –

bien que la méthode PROBE de l'application modèle soit définie par l'utilisateur (et qu'il ne s'agisse pas d'une méthode de rappel de Sun Cluster), elle est appelée avec les mêmes arguments que les méthodes de rappel. Par conséquent, cette méthode contient une fonction d'analyse identique à celle employée par les autres méthodes de rappel.

La fonction d'analyse est appelée dans MAIN sous la forme : 


parse_args “$@”

Génération de messages d'erreur

Il est recommandé que les méthodes de rappel utilisent la fonction syslog pour émettre des messages d'erreur à l'adresse des utilisateurs finaux. Toutes les méthodes de rappel du service de données modèle utilisent la fonction scha_cluster_get() pour récupérer le numéro de la fonction syslog employée pour le journal du cluster, de la manière suivante : 


SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`

La valeur est enregistrée dans une variable de shell, SYSLOG_FACILITY, et peut être utilisée comme fonction de la commande logger pour consigner des messages dans le journal du cluster. Par exemple, la méthode Start du service de données modèle récupère la fonction syslog et consigne un message indiquant que le service de données a été lancé, de la manière suivante : 


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

Reportez-vous à la page man scha_cluster_get(1HA) pour de plus amples informations.

Obtention des informations des propriétés

La plupart des méthodes de rappel doivent obtenir des informations sur les propriétés des ressources et des types de ressource du service de données. L'API fournit la fonction scha_resource_get() à cette fin.

Deux types de propriétés de ressources, les propriétés définies par le système et les propriétés d'extension, sont disponibles. Les propriétés définies par le système sont prédéfinies alors que les propriétés d'extension du fichier RTR doivent être configurées par l'utilisateur.

Lorsque vous utilisez scha_resource_get() pour obtenir la valeur d'une propriété définie par le système, vous spécifiez le nom de celle-ci à l'aide du paramètre -O. La commande ne renvoie que la valeur de la propriété. Par exemple, dans le service de données modèle, la méthode Monitor_start doit localiser le programme de sonde de manière à pouvoir le lancer. Le programme d'analyse réside dans le répertoire de base du service de données, vers lequel pointe la propriété RT_basedir. Ainsi, la méthode Monitor_start récupère la valeur de la propriété RT_basedir et la place dans la variable RT_basedir comme suit :


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

Pour les propriétés d'extension, vous devez spécifier, à l'aide du paramètre -O, qu'il s'agit d'une propriété d'extension et fournir le nom de la propriété comme dernier paramètre. La commande renvoie à la fois le type et la valeur de ce type de propriété. Par exemple, dans le service de données modèle, le programme de sonde récupère le type et la valeur dans la propriété d'extension probe_timeout, puis utilise awk pour ne placer la variable que dans la variable de shell PROBE_TIMEOUT, de la manière suivante : 


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}'`

Contrôle du service de données

Un service de données doit fournir une méthode Start ou Prenet_start pour activer le démon d'application du cluster, ainsi qu'une méthode Stop ou Postnet_stop pour arrêter le démon d'application du cluster. Le service de données modèle met en œuvre des méthodes Start et Stop. Reportez-vous à la rubrique Choix des méthodes Start et Stop à utiliser pour de plus amples informations sur les usages alternatifs de Prenet_start et de Postnet_stop.

Méthode Start

Le RGM appelle la méthode Start sur un nœud de cluster lorsque le groupe de ressources contenant la ressource du service de données est mis en ligne sur ce nœud ou lorsque le groupe de ressources est déjà en ligne et la ressource activée. Dans l’application modèle, la méthode Start active le démon in.named sur ce nœud.

Cette rubrique décrit les principaux éléments de la méthode Start pour l'application modèle. Elle ne décrit pas la fonctionnalité commune à toutes les méthodes de rappel, telles que la fonction parse_args() et l'obtention de la fonction syslog décrites dans la rubrique Fonctionnalité commune à toutes les méthodes.

Pour obtenir une liste complète de la méthode Start, reportez-vous à la rubrique Méthode Start.

Présentation de Start

Avant de tenter de lancer le DNS, la méthode Start du service de données modèle vérifie que le répertoire et le fichier de configuration (named.conf) sont accessibles et disponibles. Les informations de named.conf sont essentielles à un bon fonctionnement du DNS.

Cette méthode de rappel utilise la fonction PMF (pmfadm) pour lancer le démon DNS (in.named). Si DNS se bloque ou n'arrive pas à démarrer, le gestionnaire de processus tente de le lancer un nombre prédéfini de fois pendant un intervalle donné. Le nombre de tentatives et l'intervalle sont spécifiés par les propriétés du fichier RTR du service de données.

Vérification de la configuration

Pour fonctionner, le DNS a besoin des informations du fichier named.conf situé dans le répertoire de configuration. C'est la raison pour laquelle la méthode Start effectue des contrôles d'intégrité afin de s'assurer que le répertoire et le fichier sont accessibles avant de tenter de lancer le DNS.

La propriété d'extension Confdir fournit le chemin pointant vers le répertoire de configuration. La propriété elle-même est définie dans le fichier RTR. Toutefois, l'administrateur du cluster spécifie l'emplacement exact lors de la configuration du service de données.

Dans le service de données modèle, la méthode Start récupère l'emplacement du répertoire de configuration à l'aide de la fonction scha_resource_get ().

Remarque –

Confdir étant une propriété d'extension, scha_resource_get() renvoie à la fois le type et la valeur. La commande awk récupère simplement la valeur et la place dans une variable de shell, CONFIG_DIR. 


# trouver la valeur de Confdir définie par l’administrateur du cluster au moment de
# l’ajout de la ressource.
config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Confdir`
# scha_resource_get renvoie le "type" et la "valeur" des
# propriétés d’extension. Obtention uniquement de la valeur de la propriété d’extension.
CONFIG_DIR=`echo $config_info | awk ’{print $2}'`

La méthode Start utilise alors la valeur de CONFIG_DIR pour vérifier si le répertoire est accessible. Si ce n'est pas le cas, Start consigne un message d'erreur et se ferme en affichant un état d'échec. Reportez-vous à la rubrique État de Start à la fermeture. 


# Vérifier si $CONFIG_DIR est 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

Avant de démarrer le démon de l'application, cette méthode effectue un dernier contrôle afin de vérifier la présence du fichier named.conf. Si ce n'est pas le cas, Start consigne un message d'erreur et se ferme en affichant un état d'échec. 


# Passer au répertoire $CONFIG_DIR s’il y a des
# noms de chemin d’accès relatifs dans les fichiers de données.
cd $CONFIG_DIR
# Vérifier que le fichier named.conf est présent dans le répertoire $CONFIG_DIR
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

Démarrage de l'application

Cette méthode utilise le gestionnaire de processus (pmfadm) pour lancer l'application. La commande pmfadm vous permet de définir le nombre de fois où l'application est redémarrée pendant un délai donné. Le fichier RTR contient deux propriétés, Retry_count, indiquant le nombre de tentatives de redémarrage d'une application, et Retry_interval, indiquant le délai de ces tentatives.

La méthode Start récupère les valeurs de Retry_count et de Retry_interval à l'aide de la fonction scha_resource_get() et enregistre leurs valeurs dans des variables de shell. Ensuite, elle transmet ces valeurs à pmfadm à l'aide des options - n et -t. 


# Obtenir la valeur du nombre de nouvelles tentatives du fichier RTR.
RETRY_CNT=`scha_resource_get -O Retry_Count -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`
# Obtenir la valeur de l’intervalle entre les tentatives du fichier RTR. Cette valeur est
# exprimée en secondes et doit être convertie en minutes avant d’être transmise à pmfadm.
# Remarquez que la conversion arrondit au chiffre supérieur ; par exemple, 50 secondes sont
# arrondies à 1 minute.
((RETRY_INTERVAL=`scha_resource_get -O Retry_interval -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAMÈ / 60))

# Démarrer le démon in.named sous le contrôle du gestionnaire des processus. Le laisser se
# bloquer et redémarrer autant de fois qu’indiqué dans $RETRY_COUNT pendant le délai de
# $RETRY_INTERVAL; s’il se bloque plus souvent que cela, le gestionnaire de processus cesse
# d’essayer de le redémarrer.
# Si un processus est déjà enregistré sous la balise
# <$PMF_TAG>, le gestionnaire de processus émet un message d’alerte
# indiquant que le processus est déjà en cours d’exécution.
pmfadm -c $PMF_TAAG -n $RETRY_CNT -t $RETRY_INTRVAL \
    /usr/sbin/in.named -c named.conf

# Consigner un message indiquant que HA-DNS a été démarré.
if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS successfully started"
fi
exit 0

État de Start à la fermeture

Une méthode Start ne doit pas se fermer correctement avant que l'application sous-jacente soit en cours d'exécution et disponible, surtout si d'autres services de données en dépendent. L'une des manières permettant de vérifier la réussite consiste à sonder l'application afin de contrôler qu'elle tourne avant de quitter la méthode Start. Pour une application complexe telle qu'une base de données, dans le fichier RTR, veillez à définir pour la propriété Start_timeout une valeur suffisamment élevée pour que l'application s'initialise et exécute une reprise sur incident.

Remarque –

étant donné que la ressource de l'application DNS du service de données modèle se lance rapidement, le service de données modèle n'effectue pas d'interrogation pour vérifier son bon fonctionnement avec de se fermer.

Si cette méthode n'arrive pas à démarrer le DNS et se ferme en affichant un état d'échec, le RGM contrôle la propriété Failover_mode, qui détermine la réaction à adopter. Le service de données modèle ne définit pas explicitement la propriété Failover_mode. Par conséquent, cette propriété a la valeur par défaut NONE (sauf si l'administrateur du cluster a contourné cette valeur et en a spécifié une autre). Dans ce cas, le RGM ne prend pas de mesure autre que la définition de l'état du service de données. Une intervention de l'utilisateur est nécessaire pour le redémarrage sur le même nœud ou le basculement vers un autre nœud.

Méthode Stop

La méthode Stop est appelée sur un nœud du cluster lorsque le groupe de ressources contenant la ressource HA-DNS passe hors ligne sur ce nœud ou si le groupe de ressources est en ligne et la ressource désactivée. Cette méthode arrête le démon in.named (DNS) sur ce nœud.

Cette rubrique décrit les principaux éléments de la méthode Stop pour l'application modèle. Elle ne décrit pas la fonctionnalité commune à toutes les méthodes de rappel, telles que la fonction parse_args() et l'obtention de la fonction syslog décrites dans la rubrique Fonctionnalité commune à toutes les méthodes.

Pour obtenir une liste complète de la méthode Stop, reportez-vous à la rubrique Méthode Stop.

Présentation de la méthode Stop

Il existe deux points principaux à prendre en compte lors d'une tentative d'arrêt du service de données. D'une part, il convient de le fermer correctement. La meilleure manière pour y arriver consiste à envoyer un signal SIGTERM par l'intermédiaire de pmfadm.

D'autre part, il faut veiller à ce que le service de données soit effectivement arrêté afin d'éviter de le faire passer à l'état Stop_failed. La meilleure manière pour y arriver consiste à envoyer un signal SIGKILL par l’intermédiaire de pmfadm.

La méthode Stop du service de données modèle tient compte de ces deux considérations. Elle envoie d'abord un signal SIGTERM. Si celui-ci ne peut pas arrêter le service de données, la méthode envoie un signal SIGKILL.

Avant de tenter d'arrêter le DNS, cette méthode Stop vérifie si le processus tourne effectivement. S'il est actif, la méthode Stop utilise la fonction PMF (pmfadm) pour l'arrêter.

L'idempotence de cette méthode Stop est garantie. Bien que le RGM ne doive pas appeler une méthode Stop deux fois sans d'abord avoir démarré le service de données avec un appel à sa méthode Start, il peut appeler une méthode Stop sur une ressource même si celle-ci n'a jamais été démarrée ou si celle-ci est morte. C'est pourquoi cette méthode Stop se ferme correctement même si le DNS ne tourne pas.

Arrêt de l'application

La méthode Stop fournit une approche à deux niveaux d'arrêt du service de données : une approche sans heurt utilisant un signal SIGTERM par le biais de pmfadm et une approche abrupte utilisant un signal SIGKILL. La méthode Stop obtient la valeur Stop_timeout (le délai au cours duquel la méthode Stop doit avoir un retour). Stop alloue alors 80% de ce temps à un arrêt sans heurt et 15% à un arrêt abrupt (5% sont réservés), de la manière indiquée dans l’exemple suivant. 

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

La méthode Stop utilise pmfadm -q pour vérifier si le démon DNS fonctionne. Si c'est le cas, Stop utilise d'abord pmfadm -s pour envoyer un signal TERM afin de mettre un terme au processus DNS. Si ce signal ne peut pas arrêter le processus après l'expiration de 80 % du délai imparti, Stop envoie un signal SIGKILL. Si ce signal ne parvient pas non plus à ses fins en 15 % du délai imparti, la méthode consigne un message d'erreur et se ferme en affichant un état d'échec.

Si la commande pmfadm met un terme au processus, la méthode consigne un message indiquant l'arrêt du processus et se ferme correctement.

Si le processus DNS ne tourne pas, la méthode consigne un message l'indiquant et se ferme correctement. L'exemple de code suivant montre comment Stop utilise pmfadm pour arrêter le processus DNS. 

# Regardez si in.named fonctionne et si c’est le cas, arrêtez-le. 
if pmfadm -q $PMF_TAG; then 
   # Envoyez un signal SIGTERM au service de données et attendez 80 % de la
# valeur totale du délai imparti.
   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”
      
      # Le service de données ne s’étant pas arrêté avec un signal SIGTERM, utilisez à présent
# SIGKILL et attendez 15 % de la valeur totale du délai imparti.
      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 UNSUCCESFUL”
          
          exit 1
      fi   
fi
else 
   # Le service de données ne fonctionne pas actuellement. Consignez un message et
# un code de sortie avec succès.
   logger -p ${SYSLOG_FACILITY}.err \
           -t [$SYSLOG_TAG] \
           “HA-DNS is not started”

   # Même si HA-DNS ne tourne pas, quittez avec succès pour éviter de faire passer
# la ressource du service de données à un état STOP_FAILED.

   exit 0

fi

# Arrêt du DNS fructueux. Consignez un message et un code de sortie avec succès.
logger -p ${SYSLOG_FACILITY}.err \
    -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME]
\
    “HA-DNS successfully stopped”
exit 0

État de Stop à la fermeture

Une méthode Stop ne doit pas se fermer correctement avant que l'application sous-jacente soit réellement arrêtée, surtout si d'autres services de données en dépendent. Dans le cas contraire, vous pourriez rencontrer une corruption de données.

Pour une application complexe telle qu'une base de données, dans le fichier RTR, veillez à définir pour la propriété Stop_timeout une valeur suffisamment élevée pour que l'application se nettoie à l'arrêt.

Si cette méthode n'arrive pas à arrêter le DNS et se ferme en affichant un état d'échec, le RGM contrôle la propriété Failover_mode, qui détermine la réaction à adopter. Le service de données modèle ne définit pas explicitement la propriété Failover_mode. Par conséquent, elle possède la valeur par défaut NONE (sauf si l'administrateur du cluster a contourné cette valeur et en a spécifié une autre). Dans ce cas, le RGM ne prend pas de mesure autre que la définition de l'état du service de données à Stop_failed. Une intervention de l’utilisateur est nécessaire pour forcer l’arrêt de l’application et effacer l’état Stop_failed.

Définition d'un détecteur de pannes

L'application modèle met en œuvre un détecteur de pannes de base afin de surveiller la fiabilité de la ressource DNS (in.named). Le détecteur de pannes se compose de :

Programme Probe

Le programme dns_probe met en œuvre un processus vérifiant en permanence si la ressource DNS contrôlée par le service de données modèle fonctionne. La commande dns_probe est lancée par la méthode dns_monitor_start, appelée automatiquement par le RGM une fois le service de données en ligne. Le service de données est arrêté par la méthode dns_monitor_stop, appelée par le RGM avant de mettre le service de données modèle hors ligne.

Cette rubrique décrit les principaux éléments de la méthode PROBE pour l'application modèle. Elle ne décrit pas la fonctionnalité commune à toutes les méthodes de rappel, telles que la fonction parse_args() et l'obtention de la fonction syslog décrites dans la rubrique Fonctionnalité commune à toutes les méthodes.

Pour une liste complète de la méthode de PROBE, reportez-vous à la rubrique Programme PROBE.

Présentation de Probe

Probe tourne en boucle infinie. Elle utilise la commande nslookup afin de vérifier si la bonne ressource DNS tourne. Si le DNS tourne, la sonde passe en mode de sommeil pour un délai donné (établi par la propriété définie par le système Thorough_probe_interval), puis procède à un nouveau contrôle. Dans le cas contraire, ce programme tente de le redémarrer localement ou, en fonction du nombre de tentatives de démarrage, demande au RGM de déplacer le service de données sur un autre nœud.

Obtention des valeurs des propriétés

Ce programme a besoin des valeurs des propriétés suivantes :

La fonction scha_resource_get() obtient les valeurs de ces propriétés et les enregistre dans des variables de shell, de la manière décrite ci-dessous : 

PROBE_INTERVAL=`scha_resource_get -O THOROUGH_PROBE_INTERVAL \
-R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ

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}’`
HÔTE_DNS=`scha_resource_get -O NETWORK_RESOURCES_USED -R $RESOURCE_NAME
\
-G $RESOURCEGROUP_NAMÈ
RETRY_COUNT=`scha_resource_get -O RETRY_COUNT
-R $RESOURCE_NAME
-G\
$RESOURCEGROUP_NAMÈ
RETRY_INTERVAL=`scha_resource_get -O RETRY_INTERVAL
-R $RESOURCE_NAME
-G\
$RESOURCEGROUP_NAMÈ
RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G\
$RESOURCEGROUP_NAMÈ

Remarque –

pour les propriétés définies par le système, telles que >Thorough_probe_interval, scha_resource_get() ne retourne que la valeur. Pour les propriétés d'extension, telles que Probe_timeout, scha_resource_get() retourne le type et la valeur. Utilisez la commande awk pour n'obtenir que la valeur.

Contrôle de la fiabilité du service

La sonde elle-même est une boucle while infinie de commandes nslookup. Avant cette boucle, un fichier temporaire est créé. Son but consiste à collecter les réponses à nslookup. Les variables probefail et retries sont remises à 0. 


# Configurer un fichier temporaire pour les réponses de nslookup.
DNSPROBEFILE=/tmp/.$RESOURCE_NAME.probe
probefail=0
retries=0

La boucle while elle-même :

Voici le code de la boucle while.


while :
do
   # L’intervalle auquel la sonde doit s’exécuter est spécifié dans la
# propriété THOROUGH_PROBE_INTERVAL. Par conséquent, définir le sommeil de la sonde
# à une durée de THOROUGH_PROBE_INTERVAL.
   sleep $PROBE_INTERVAL

   # Exécuter une commande nslookup de l’adresse IP sur laquelle le DNS fonctionne.
   hatimerun -t $PROBE_TIMEOUT /usr/sbin/nslookup $DNS_HOST $DNS_HOST \
          > $DNSPROBEFILE 2>&1

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

   # Vérifier que la réponse à nslookup provient du serveur HA-DNS
# et pas d’un autre nom de serveur mentionné dans le fichier
# /etc/resolv.conf.
   if [ $probefail -eq 0 ]; then
# Obtenir le nom du serveur ayant répondu à la requête 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

Évaluation : redémarrage ou basculement

Si la variable probefail est différente de 0 (réussite), cela signifie que la commande nslookup a dépassé le délai imparti ou que la réponse provient d'un serveur autre que le DNS du service modèle. Dans un cas comme dans l'autre, le serveur DNS ne fonctionne pas de la manière attendue et le détecteur appelle la fonction decide_restart_or_failover() afin de déterminer s'il convient ou non de redémarrer le service de données localement ou de demander que le RGM déplace le service de données sur un autre nœud. Si la variable probefail a la valeur 0, alors un message indiquant que la sonde a réussi est généré. 


   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 fonction decide_restart_or_failover() utilise un délai (Retry_interval) et un compteur d'échecs (Retry_count) afin de déterminer s'il convient de redémarrer le DNS localement ou de demander à ce que le RGM déplace le service de données sur un autre nœud. Elle met en œuvre le code conditionnel suivant (voir l'affichage du code pour decide_restart_or_failover () dans la rubrique Programme PROBE).

Si le nombre de redémarrages atteint la limite pendant le délai, la fonction demande au RGM de déplacer le service de données vers un autre nœud. Si le nombre de redémarrages se situe sous la limite ou si l'intervalle a été dépassé, entraînant une réinitialisation du compteur, la fonction tente de redémarrer le DNS sur le même nœud. Remarquez les points suivants concernant cette fonction :

Redémarrage du service de données

La fonction restart_service() est appelée par decide_restart_or_failover() pour tenter de rédemarrer le service de données sur le même nœud. Cette fonction effectue les opérations suivantes : 


function restart_service
{

        # Pour redémarrer le service de données, d’abord vérifier que le
# service de données lui-même est toujours enregistré auprès du gestionnaire
# de processus.
        pmfadm -q $PMF_TAG
        if [[ $? -eq 0 ]]; then
                # La BALISE du service de données étant toujours enregistrée
# auprès du gestionnaire de processus, arrêter le service de données
# et le redémarrer.

                # Obtenir le nom de la méthode Arrêt et la valeur de STOP_TIMEOUT
# pour cette ressource.
                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

                # Obtenir le nom de la méthode START et la valeur
# de START_TIMEOUT pour cette ressource.
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
                # L’absence de la BALISE du service de données
# signifie que celui-ci a déjà dépassé le nombre
# maximum de nouvelles tentatives autorisé par le gestionnaire
# des processus. Ne pas essayer de le redémarrer
# mais tenter de le basculer
# sur un autre nœud du serveur.
                scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \
                        -R $RESOURCE_NAME
        fi

        return 0
}

État de Probe à la fermeture

Le programme PROBE du service de données modèle se ferme en affichant un état d'échec si les tentatives de redémarrage local ont échoué et si la tentative de basculement vers un autre nœud a également échoué. Il consigne le message, “Failover attempt failed” ("Échec de la tentative de basculement").

Méthode Monitor_start

Le RGM appelle la méthode Monitor_start pour lancer la méthode dns_probe une fois le service de données modèle en ligne.

Cette rubrique décrit les principaux éléments de la méthode Monitor_start pour l'application modèle. Elle ne décrit pas la fonctionnalité commune à toutes les méthodes de rappel, telles que la fonction parse_args () et l'obtention de la fonction syslog, décrites dans la rubrique Fonctionnalité commune à toutes les méthodes.

Pour un affichage complet de la méthode Monitor_start, reportez-vous à la rubrique Méthode Monitor_start.

Présentation de la méthode Monitor_start

Elle utilise la fonction PMF (pmfadm) pour lancer l'analyse.

Démarrage de Probe

La méthode Monitor_start obtient la valeur de la propriété RT_basedir pour construire le nom complet du chemin d'accès au programme d'analyse. Cette méthode lance la sonde à l'aide de l'option de nouvelles tentatives infinies de pmfadm (-n -1, -t -1), ce qui signifie que si le démarrage de la sonde échoue, le gestionnaire de processus tente de la démarrer un nombre infini de fois sur une période infinie. 


# Trouver où réside le programme de sonde en obtenant la valeur de la propriété
# RT_BASEDIR de la ressource.
RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAME`

# Démarrer la sonde pour le service de données sous le gestionnaire de processus.
# Utiliser l’option permettant un nombre infini de nouvelles tentatives pour démarrer
# la sonde, Transmettre le nom, le type et le groupe de la ressource au programme
# probe. 
pmfadm -c $RESOURCE_NAME.monitor -n -1 -t -1 \
   $RT_BASEDIR/dns_probe -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME

Méthode Monitor_stop

Le RGM appelle la méthode Monitor_stop afin d'arrêter l'exécution de dns_probe lorsque le service de données modèle est mis hors ligne.

Cette rubrique décrit les principaux éléments de la méthode Monitor_stop pour l'application modèle. Elle ne décrit pas la fonctionnalité commune à toutes les méthodes de rappel, telles que la fonction parse_args () et l'obtention de la fonction syslog, décrites dans la rubrique Fonctionnalité commune à toutes les méthodes.

Pour l'affichage complet de la méthode Monitor_stop, reportez-vous à la rubrique Méthode Monitor_stop.

Présentation de la méthode Monitor_stop

Elle utilise la fonction PMF (pmfadm) pour voir si l'analyse est en cours et, le cas échéant, pour l'arrêter.

Arrêt du détecteur

La méthode Monitor_stop utilise pmfadm -q pour déterminer si la sonde fonctionne et, le cas échéant, pmfadm -s pour l'arrêter. Si la sonde est déjà arrêtée, la méthode se ferme correctement, ce qui garantit l'idempotence de la méthode. 


# Voir si le détecteur tourne et, le cas échéant, l'arrêter. 
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
         # Arrêt du détecteur fructueux. Consigner un message.
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Monitor for resource " $RESOURCE_NAME \
            " successfully stopped"
   fi
fi
exit 0

Attention – Attention –

veillez à utiliser le signal KILL avec pmfadm pour arrêter la sonde et non pas un signal masquable tel que TERM. Sinon la méthode Monitor_stop peut se bloquer indéfiniment et finit par dépasser le délai imparti. Le problème réside dans l'appel par la méthode Probe de la fonction scha_control() lorsqu'il est nécessaire de redémarrer ou de basculer le service de données. Lorsque scha_control() appelle Monitor_stop dans le cadre du processus de mise du service de données hors ligne, si Monitor_stop utilise un signal masquable, il se bloque en attendant que la fonction scha_control() s'arrête et scha_control() se bloque en attendant que Monitor_stop s'arrête.

État de Monitor_stop à la fermeture

La méthode Monitor_stop consigne un message d'erreur si elle ne peut pas arrêter la méthode PROBE. Le RGM fait passer le service de données modèle à l'état MONITOR_FAILED sur le nœud primaire, ce qui peut créer une panique au niveau du nœud.

Monitor_stop ne doit pas se fermer avant l'arrêt de la sonde.

Méthode Monitor_check

Le RGM appelle la méthode Monitor_check lorsque la méthode PROBE tente de basculer le groupe de ressources contenant le service de données vers un autre nœud.

Cette rubrique décrit les principaux éléments de la méthode Monitor_check pour l'application modèle. Elle ne décrit pas la fonctionnalité commune à toutes les méthodes de rappel, telles que la fonction parse_args () et l'obtention de la fonction syslog, décrites dans la rubrique Fonctionnalité commune à toutes les méthodes.

Pour un affichage complet de la méthode Monitor_check, reportez-vous à la rubrique Méthode Monitor_check.

La méthode Monitor_check doit être mise en œuvre de manière à ne pas entrer en conflit avec d'autres méthodes exécutées simultanément.

La méthode Monitor_check appelle la méthode de Validate afin qu'elle vérifie que le répertoire de configuration DNS est disponible sur le nouveau nœud. La propriété d'extension Confdir pointe vers le répertoire de configuration DNS. C'est pourquoi Monitor_check obtient le chemin et le nom de la méthode Validate ainsi que la valeur de Confdir. Elle transmet cette valeur à Validate, comme le montre l'affichage suivant : 


# Obtenir le chemin complet de la méthode Validate à partir de la propriété
# RT_BASEDIR du type de ressource.
RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME \
   -G $RESOURCEGROUP_NAMÈ

# Obtenir le nom de la méthode Validate pour cette ressource.
VALIDATE_METHOD=`scha_resource_get -O VALIDATE \
   -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ

# Obtenir la valeur de la propriété Confdir pour démarrer le
# service de données. Utiliser le nom de la ressource et le groupe entré pour
# obtenir la valeur Confdir définie au moment de l’ajout de la ressource.
config_info =`scha_resource_get -O Extension -R $RESOURCE_NAME \
 -G $RESOURCEGROUP_NAME Confdir`

# scha_resource_get renvoie le type ainsi que la valeur des
# propriétés d’extension. Utiliser awk pour n’obtenir que la valeur de la propriété d’extension.
CONFIG_DIR=`echo $config_info | awk `{print $2}'`

# Appeler la méthode Validate de manière que le service de données
# puisse être basculé sur un nouveau nœud.
$RT_BASEDIR/$VALIDATE_METHOD -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME -x Confdir=$CONFIG_DIR

Reportez-vous à la rubrique Méthode Validate pour voir comment l'application modèle vérifie l'aptitude du nœud à héberger le service de données.

Gestion des mises à jour des propriétés

Le service de données modèle met en œuvre les méthodes Validate et Update afin de gérer la mise à jour des propriétés par l'administrateur du cluster.

Méthode Validate

Le RGM appelle la méthode Validate lorsqu'un groupe est créé et lorsqu'une opération de l'administrateur met à jour les propriétés de la ressource ou du groupe qui la contient. Le RGM appelle Validate avant la création ou la mise à jour, et un code de sortie avec échec issu de la méthode sur un nœud entraîne l'annulation de la création ou de la mise à jour.

Il n'appelle Validate que lorsque les propriétés de la ressource ou du groupe sont modifiées par une opération de l'administrateur, et non lorsque le RGM définit des propriétés, ou lorsqu'un détecteur définit les propriétés Status et Status_msg de la ressource.

Remarque –

la méthode Monitor_check appelle aussi explicitement la méthode Validate lorsque la méthode PROBE tente de basculer le service de données sur un autre nœud.

Présentation de Validate

Le RGM appelle Validate avec des arguments différents de ceux transmis aux autres méthodes, y compris les propriétés et valeurs mises à jour. C'est la raison pour laquelle cette méthode du service de données modèle doit mettre en œuvre une fonction parse_args() pour gérer les autres arguments.

La méthode Validate vérifie une seule propriété, la propriété d'extension Confdir. Cette propriété pointe vers le répertoire de configuration DNS, essentiel pour un bon fonctionnement du DNS.

Remarque –

le répertoire de configuration ne pouvant pas être modifié lorsque le DNS tourne, la propriété Confdir est déclarée TUNABLE = AT_CREATION dans le fichier RTR. C'est pourquoi la méthode Validate n'est jamais appelée pour vérifier la propriété Confdir à la suite d'une mise à jour, mais uniquement à la création de la ressource du service de données.

Si Confdir est l'une des propriétés transmises par le RGM à Validate, la fonction parse_args() récupère et enregistre sa valeur. Validate vérifie alors si le répertoire vers lequel pointe la nouvelle valeur de Confdir est accessible et si le fichier named.conf existe dans ce répertoire et contient certaines données.

Si la fonction parse_args() ne peut pas récupérer la valeur de Confdir à partir des arguments de ligne de commande transmis par le RGM, Validate tente néanmoins de valider la propriété Confdir. Validate utilise scha_resource_get () pour obtenir la valeur de Confdir à partir de la configuration statique. Ensuite, elle effectue les mêmes contrôles afin de s'assurer que le répertoire de configuration est accessible et contient un fichier named.conf qui ne soit pas vierge.

Si Validate se ferme en affichant un état d'échec, la mise à jour ou la création de toutes les propriétés, et pas seulement de Confdir, échoue.

Fonction d'analyse de la méthode Validate

Le RGM transmet à la méthode de Validate un ensemble de paramètres différent de celui des autres méthodes de rappel, de telle manière que Validate a besoin d'une autre fonction d'analyse des arguments que les autres méthodes. Reportez-vous à la page man rt_callbacks(1HA) pour de plus amples informations sur les paramètres transmis à Validate et aux autres méthodes de rappel. L'exemple suivant montre la fonction parse_args() de Validate. 


#########################################################################
#Analyser les arguments Validation.
#
function parse_args # [args...]
{

   typeset opt
   while getopts 'cur:x:g:R:T:G:' opt
   do
         case "$opt" in
         R)
                  # Nom de la ressource DNS
	   RESOURCE_NAME=$OPTARG
                  ;;
         G)
                  # Nom du groupe dans lequel est configurée
# la ressource.
RESOURCEGROUP_NAME=$OPTARG
                  ;;
         T)
                  # Nom du type de ressource.
RESOURCETYPE_NAME=$OPTARG
                  ;;
         r)
                  # La méthode n’accède pas à des propriétés définies
# par le système. Aucune action.
                  ;;
         g)
                  # La méthode n’accède pas à des propriétés du groupe de
# ressources. Aucune action.
                  ;;
         c)
                  # Indique que la méthode Validate est appelée lors
# de la création de la ressource. Indicateur sans action.
                  ;;
         u)
                  #Indique la mise à jour d’une propriété quand la
# ressource existe déjà. Si la mise à jour est adressée
# à la propriété Confdir, alors Confdir doit apparaître dans
# les arguments de ligne de commande. Dans le cas contraire,
# la méthode doit le rechercher à l’aide de scha_resource_get.
                  UPDATE_PROPERTY=1
                  ;;
         x)
                  # Liste des propriétés d’extension. Séparer les couples propriété et
# valeur en utilisant "=" comme séparateur.
                  PROPERTY=`echo $OPTARG | awk -F= '{print $1}'`
                  VAL=`echo $OPTARG | awk -F= '{print $2}'`
                  # Si la propriété d’extension se trouve sur la ligne de
# commande, noter sa valeur. 
                  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
}

Comme la fonction parse_args() des autres méthodes, cette fonction propose un indicateur (R) pour capturer le nom de la ressource, (G) pour capturer le nom du groupe de ressources et (T) pour capturer le type de ressource transmis par le RGM.

Les indicateurs r (propriété définie par le système), g (propriété du groupe de ressources) et c (validation à la création de la ressource) sont ignorés parce que cette méthode est appelée pour valider une propriété d'extension lors de la mise à jour de la ressource.

L'indicateur u définit la variable de shell UPDATE_PROPERTY à 1 (TRUE). Le témoin x capture les noms et les valeurs des propriétés mises à jour. Si Confdir est l'une des propriétés mises à jour, sa valeur est placée dans la variable de shell CONFDIR et la variable CONFDIR_FOUND est réglée sur 1 (TRUE).

Validation de Confdir

Dans sa fonction MAIN, Validate attribue d'abord une chaîne vide à la variable CONFDIR et une valeur 0 à UPDATE_PROPERTY et CONFDIR_FOUND. 


CONFDIR=""
UPDATE_PROPERTY=0
CONFDIR_FOUND=0

Validate appelle ensuite parse_args() pour analyser les arguments transmis par le RGM. 


parse_args “$@”

Validate vérifie alors si Validate est appelée à la suite d'une mise à jour des propriétés et si la propriété d'extension Confdir se trouvait sur la ligne de commande. Validate vérifie alors si la propriété Confdir a une valeur et, si ce n'est pas le cas, elle se ferme en affichant un état d'échec et émet un message d'erreur. 


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

# Vérifier que la propriété Rép_conf possède une valeur. Dans le cas contraire, il y a échec
# et sortie avec l’état 1
if [[ -z $CONFDIR ]]; then
         logger -p ${SYSLOG_FACILITY}.err \
            "${ARGV0} Validate method for resource "$RESOURCE_NAME " failed"
         exit 1
fi

Remarque –

le code précédent vérifie tout spécialement si Validate est appelée à la suite d'une mise à jour ($UPDATE_PROPERTY == 1) et si la propriété n'a pas été trouvée dans la ligne de commande (CONFDIR_FOUND == 0), auquel cas il récupère la valeur existante de Confdir à l'aide de scha_resource_get (). Si Confdir a été trouvé dans la ligne de commande (CONFDIR_FOUND == 1), la valeur de CONFDIR provient de la fonction parse_args(), et non de scha_resource_get ().

La méthode Validate utilise alors la valeur de CONFDIR pour vérifier si le répertoire est accessible. Si ce n'est pas le cas, Validate consigne un message d'erreur et se ferme en affichant un état d'échec. 


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

Avant de valider la mise à jour de la propriété Confdir, Validate effectue un contrôle final pour vérifier si le fichier named.conf est présent. Si ce n'est pas le cas, la méthode enregistre un message d'erreur et se ferme en affichant un état d'échec. 


# Vérifier si le fichier named.conf est présent dans le répertoire Confdir
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 le dernier contrôle réussit, Validate consigne un message indiquant une réussite et se ferme avec un état de réussite. 


# Consigner un message indiquant que la méthode Validate a réussi.
logger -p ${SYSLOG_FACILITY}.err \
   -t [$SYSLOG_TAG] \
   "${ARGV0} Validate method for resource "$RESOURCE_NAME \
   " completed successfully"

exit 0

État de Validate à la fermeture

Si Validate se ferme avec succès (0) Confdir est créé avec la nouvelle valeur. Si Validate se ferme avec un échec (1), Confdir et les autres propriétés ne sont pas créées et un message indiquant la raison de cet échec est envoyé à l'administrateur du cluster.

Méthode Update

Le RGM appelle la méthode Update pour notifier à une ressource en cours d'exécution que ses propriétés ont changé. Le RGM appelle Update après la réussite d'une action de l'administrateur visant à définir les propriétés d'une ressource ou de son groupe. Cette méthode est appelée sur les nœuds lorsque la ressource est en ligne.

Présentation de la méthode Update

La méthode Update ne met pas les propriétés à jour, cette opération est effectuée par le RGM. Par contre, elle notifie la mise à jour aux processus. Le seul processus du service de données modèle affecté par une mise à jour des propriétés est le détecteur de pannes. C'est donc ce processus qu'arrête et que démarre la méthode Update.

La méthode Update doit vérifier que le détecteur de pannes tourne, puis le tuer à l'aide de la commande pmfadm. La méthode obtient l'emplacement du programme probe mettant en œuvre le détecteur de pannes, puis le redémarre à l'aide de pmfadm.

Arrêt du détecteur à l'aide de Update

La méthode Update utilise pmfadm -q pour vérifier que le détecteur tourne et, si c'est le cas, le tue à l'aide de la commande pmfadm -s TERM. Si le détecteur se ferme correctement, un message le signalant est envoyé à l'administrateur. Dans le cas contraire, Update se ferme en affichant un état d'échec et envoie un message d'erreur à l'administrateur. 


if pmfadm -q $RESOURCE_NAME.monitor; then

# Arrêter le détecteur en cours d’exécution
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
    # Arrêt du DNS fructueux. Consigner un message.
       logger -p ${SYSLOG_FACILITY}.err \
              -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                 "Monitor for HA-DNS successfully stopped"
    fi

Redémarrage du détecteur

Pour redémarrer le détecteur, la méthode Update doit localiser le script mettant en œuvre le programme probe. Le programme d'analyse réside dans le répertoire de base du service de données, vers lequel pointe la propriété RT_basedir. La méthode de mise à jour récupère la valeur de la propriété RT_basedir et la stocke dans la variable RT_BASEDIR comme suit :


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

La méthode utilise ensuite la valeur de la variable avec la commande pmfadm afin de redémarrer le programme dns_probe. S'il y réussit, Update se ferme avec succès et envoie un message le signalant à l'administrateur. Si pmfadm ne peut pas lancer le programme de sonde, Update se ferme en affichant un état d'échec et consigne un message d'erreur.

État de Update à la fermeture

L'échec de la méthode Update entraîne le passage de son état à “update failed” (“échec de la mise à jour”). Cet état n'affecte en rien la gestion RGM de la ressource, mais indique l'échec de l'opération de mise à jour aux outils d'administration par le biais de la fonction syslog.