test

Guide du développeur de services de données Sun Cluster pour SE Solaris

Chapitre 5 Service de données modèle

Ce chapitre présente un modèle de service de données Sun Cluster, HA-DNS, pour l'application in.named. Le démon in.named est la mise en œuvre 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.

Ce chapitre contient les rubriques 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 le nombre d'échecs d'applications dépasse le nombre d'échecs accepté dans l'intervalle considéré, 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 de panne sous forme d'une méthode PROBE qui utilise la commande nslookup pour s'assurer que l'application fonctionne correctement. Si la sonde détecte un service DNS bloqué, elle tente de corriger la situation en redémarrant localement l'application DNS. Si le redémarrage local de l'application DNS n'améliore pas la situation et que la sonde détecte régulièrement des problèmes au niveau du service, elle tente de basculer celui-ci vers un autre nœud du cluster.

Le service de données modèle inclut les éléments suivants :

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.

Le gestionnaire RGM (Resource Group Manager) lit les informations du fichier RTR 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 obtenir plus d'informations.

Les sections suivantes décrivent les propriétés spécifiques dans le fichier RTR modèle. Ces sections proposent des listes de programme de différentes parties du fichier. Pour obtenir une liste de programme complète du contenu du fichier RTR modèle, 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 :

Remarque –

les noms de propriété des groupes de ressources, des ressources et des types de ressources ne sont pas sensibles à la casse. Vous pouvez associer les majuscules et les minuscules dans le nom des propriétés. 

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

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

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

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

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

Start         =   dns_svc_start;
Stop          =   dns_svc_stop;

Validate      =   dns_validate;
Update        =   dns_update;

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

la propriété Type_ressource 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.

Les informations suivantes décrivent ces propriétés :

Les propriétés des types de ressource non spécifiées dans ce fichier RTR, telles que Single_instance, Init_nodes et Installed_nodes , sont définies à leurs valeurs par défaut. Propriétés des types de ressources contient une liste complète des propriétés des types de ressource, y compris leurs valeurs par défaut.

L'administrateur du cluster ne peut modifier les valeurs des propriétés des types 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 après les propriétés des types de ressource dans le fichier RTR. Les propriétés de ressource incluent les propriétés définies au niveau du système fournies par le logiciel Sun Cluster et les propriétés d'extension que vous définissez. Pour les deux types, vous pouvez spécifier différents attributs de propriété fournis par le logiciel Sun Cluster, tels que les valeurs minimum, maximum et par défaut.

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

La liste de programme suivante montre les propriétés définies au niveau du système dans un fichier RTR modèle. 

# Une liste de déclarations de propriétés de ressource entre accolades suit
# les déclarations des types de ressource. La déclaration du nom de propriété 
# doit être le premier attribut après l'accolade d'ouverture de chaque entrée.

# Les propriétés <method>_timeout définissent le délai en secondes avant 
# que le gestionnaire RGM ne considère que l'appel de la méthode a échoué.

# La valeur MIN de tous les délais d'attente de méthode est définie à 60 
# secondes. Cela empêche les administrateurs de définir des délais plus
# courts, qui n'améliorent pas la performance de commutation/basculement et
# peuvent conduire à des actions RGM indésirables (erreurs de basculement,
# réinitialisation de nœud, ou déplacement d'un groupe de ressources en mode 
# ERROR_STOP_FAILED, nécessitant l'intervention de l'opérateur). Définir des
# délais de méthode trop courts conduit à une *diminution* de la disponibilité 
# globale 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;
}

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

# Définissez Retry_interval sur un multiple de 60 puisque cette valeur en  
# secondes est convertie en minutes (arrondie à la valeur supérieure). Par  
# exemple une valeur de 50 (secondes) est convertie à 1 minute. Utilisez cette 
# propriété pour définir le nombre de tentatives dans le temps (Retry_count).
{
   PROPERTY = Retry_interval;
   MIN=60;
   MAX=3600;
   DEFAULT=300;
   TUNABLE = ANYTIME;
}

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

Bien que le logiciel Sun Cluster fournisse les propriétés définies au niveau du système, vous pouvez leur attribuer des valeurs par défaut différentes en utilisant les attributs des propriétés de ressource. Reportez-vous à la rubrique Attributs des propriétés de ressources pour obtenir une liste complète des attributs que vous pouvez appliquer aux propriétés de ressource.

Notez les points suivants sur les propriétés des ressources définies au niveau système dans le fichier RTR 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é pour pointer
# vers le répertoire contenant les fichiers de configuration utilisés par 
# l'application. Pour cette application, DNS, spécifiez le chemin d'accès du fichier 
# de configuration DNS sur PXFS (généralement named.conf).
{
   PROPERTY = Confdir;
   EXTENSION;
   STRING;
   TUNABLE = AT_CREATION;
   DESCRIPTION = “Chemin d'accès au répertoire de configuration”;
}

# Valeur de délai d'attente en secondes avant de déclarer un échec de la sonde
{
   PROPERTY = Probe_timeout;
   EXTENSION;
   INT;
   DEFAULT = 120;
   TUNABLE = ANYTIME;
   DESCRIPTION = “Valeur de délai d'attente de la sonde (secondes)”;
}

Le fichier RTR modèle définit deux propriétés d'extension, Confdir et Probe_timeout. La propriété Confdir spécifie le chemin d'accès au répertoire de configuration de 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 Sun Cluster mais une méthode définie par l'utilisateur. Par conséquent, Sun Cluster ne lui fournit pas de propriété Probe_timeout. Vous devez définir une propriété d'extension dans le fichier RTR pour permettre à un administrateur du 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. Chaque script de méthode dans le service de données modèle identifie l'interpréteur de commandes de la façon suivante : 

#!/bin/ksh

Tous les scripts de méthode de l'application modèle exportent le chemin d'accès vers les binaires et les bibliothèques Sun Cluster plutôt que de compter sur la définition de la variable d'environnement 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 démarrer ou arrêter le service de données ou le détecteur, en lui passant le nom de la ressource. Chaque script définit une variable, PMF_TAG, qui peut être passée à pmfadm pour identifier le service de données ou le détecteur.

De même, chaque script de méthode utilise la commande logger pour journaliser les messages dans le journal système. Chaque script définit une variable, SYSLOG_TAG, qui peut être passée à la commande logger avec l'option -t pour identifier le type, le nom et le groupe de ressource de la ressource pour laquelle le message est consigné.

Toutes les méthodes définissent SYSLOG_TAG de la même manière, comme cela est indiqué dans l'exemple de code suivant. Les méthodes dns_probe, dns_svc_start , dns_svc_stop, et dns_monitor_check définissent PMF_TAG comme suit (les commandes pmfadm et logger sont utilisées à partir de la méthode dns_svc_stop). 

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

PMF_TAG=$RESOURCE_NAME.named

SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME

   # Envoie un signal SIGTERM au service de données et attend pendant 80% de
   # la valeur de délai totale.
   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 dns_update définissent PMF_TAG de la façon suivante (la commande pmfadm est utilisée à partir 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 est en cours d'exécution et si oui, le tuer. 
if pmfadm -q $PMF_TAG.monitor; then
   pmfadm -s $PMF_TAG.monitor KILL

Analyse des arguments de la fonction

Le gestionnaire RGM exécute toutes les méthodes de rappel, à l'exception de Validate, de la façon suivante : 

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

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 dépendent du 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 comme suit : 

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

Tous les arguments des méthodes de rappel sont passées en tant que valeurs marquées. L'argument -R indique le nom de l'instance de ressource. L'argument -T indique le type de la ressource. L'argument -G indique le groupe dans lequel la ressource est configurée. Reportez-vous à la page de manuel rt_callbacks(1HA) pour obtenir plus d'informations sur les méthodes de rappel.

Remarque –

la méthode Validate est appelée avec des arguments supplémentaires, à savoir les valeurs de propriété de la ressource et du groupe de ressources pour lesquels elle est appelée. Reportez-vous à la rubrique Gestion des mises à jour des propriétés pour obtenir plus d'informations.

Chaque méthode de rappel a besoin d'une fonction pour analyser les arguments transmis à la fonction. 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 illustre le cas de la fonction parse_args(), utilisée pour les méthodes de rappel dans 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 lequel la ressource 
                  # est configurée.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
             T)
                  # Nom du type de ressource.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
             *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                  "ERROR: Option $OPTARG inconnue"
                  exit 1
                      ;;
             esac
    done
}
Remarque –

bien que la méthode de SONDE 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 qu'utilisent 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

Les méthodes de rappel doivent utiliser la fonction syslog() pour générer les messages d'erreur destinés aux utilisateurs finaux. Toutes les méthodes de rappel du service de données modèle utilisent la commande scha_cluster_get pour récupérer le numéro de la fonction syslog() utilisée pour le journal du cluster, comme cela est indiqué ci-après : 

SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`

La valeur est stockée dans une variable de shell, SYSLOG_FACILITY, et peut être utilisée par la commande logger pour journaliser les 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é démarré de la façon 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 de manuel scha_cluster_get(1HA) pour obtenir plus d'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.

Les propriétés définies au niveau système et les propriétés d’extension sont disponibles. Les premières sont prédéfinies et vous définissez les autres dans le fichier RTR.

Si vous utilisez scha_resource_get() pour obtenir la valeur d'une propriété définie au niveau système, spécifiez le nom de la propriété avec l'option -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 afin de pouvoir le démarrer. Le programme de sonde se trouve dans le répertoire de base du service de données, vers lequel pointe la propriété RT_basedir. La méthode Monitor_start récupère la valeur de 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 utiliser l'option -O pour indiquer que la propriété est une propriété d'extension. Vous devez également fournir le nom de la propriété comme dernier argument. Pour les propriétés d'extension, la commande renvoie à la fois le type et la valeur de la propriété. Par exemple, dans le service de données modèle, le programme de sonde récupère le type et la valeur de la propriété d'extension Probe_timeout, puis utilise la commande awk pour placer uniquement la valeur dans la variable de shell PROBE_TIMEOUT, comme suit : 

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 de Démarrage ou de Démarrage_avant_réseau pour activer le démon d'application du cluster, ainsi qu'une méthode d'Arrêt ou d'Arrêt_après_réseau pour arrêter le démon d'application du cluster. Le service de données modèle met en œuvre des méthodes Démarrage et Arrêt. Reportez-vous à la rubrique Choix des méthodes Start et Stop à utiliser pour savoir dans quels cas il peut être préférable d'utiliser Prenet_start et Postnet_stop .

Fonctionnement de la méthode Start

Le RGM exécute la méthode de Démarrage 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 DNS in.named sur ce nœud.

Cette rubrique décrit les principaux éléments de la méthode de Démarrage pour l'application modèle. Cette rubrique ne décrit pas les fonctionnalités communes à toutes les méthodes de rappel, comme par exemple la fonction parse_args(). Par ailleurs, elle ne décrit pas l'utilisation de la fonction syslog(). Les fonctionnalités communes sont décrites à la rubrique Fonctionnalité commune à toutes les méthodes.

Pour une liste complète du code de la méthode Start, reportez-vous à la rubrique Listing de code de la méthode Start.

Fonction de la méthode Start

Avant de tenter de démarrer le DNS, la méthode Start du service de données modèle s'assure que le répertoire de configuration et le fichier de configuration (named.conf) sont accessibles et disponibles. Les informations du fichier named.conf sont essentielles pour un bon fonctionnement du DNS.

Cette méthode de rappel utilise la fonction PMF (pmfadm) pour démarrer le démon DNS (in.named(). Si le DNS s'arrête brutalement ou ne parvient pas à démarrer, la fonction PMF tente de démarrer le démon DNS un certain nombre de fois (le nombre de tentatives étant paramétrable) pendant un intervalle spécifié. 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. La méthode Start effectue donc différents contrôles de validité pour vérifier que le répertoire et le fichier sont accessibles avant de tenter de démarrer le DNS.

La propriété d'extension Rép_conf fournit le chemin pointant vers le répertoire de configuration. La propriété elle-même est définie dans le fichier RTR. Cependant, l'administrateur du cluster spécifie l'emplacement réel lorsqu'il configure le 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 uniquement la valeur et place celle-ci dans une variable de shell, CONFIG_DIR . 

# trouver la valeur de Confdir définie par l'administrateur du cluster lors
# de l'ajout de la ressource.
config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Confdir`

# Pour les propriétés d'extension, scha_resource_get renvoie le "type" 
# et la "valeur". Récupérer uniquement la valeur de la propriété d'extension
CONFIG_DIR=`echo $config_info | awk '{print $2}'`

La méthode Start utilise la valeur de CONFIG_DIR pour vérifier que le répertoire est accessible. S'il ne l'est pas, Start consigne un message d'erreur et se termine avec un état d'erreur. 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 le fichier n'est pas présent, Start consigne un message d'erreur et se termine avec un état d'erreur. 

# Se placer dans le répertoire $CONFIG_DIR au cas où il y aurait
# des chemins 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 fait appel aux services du gestionnaire de processus (pmfadm) pour démarrer l'application. La commande pmfadm vous permet de définir le nombre de tentatives de redémarrage de l'application pendant un intervalle spécifié. Le fichier RTR contient les propriétés suivantes : Retry_count spécifie le nombre de tentatives de redémarrage d'une application, et Retry_interval l'intervalle pendant lequel les tentatives doivent être effectuées.

La méthode Start récupère les valeurs de Retry_count et de Retry_interval en utilisant la fonction scha_resource_get (), puis stocke leurs valeurs dans des variables de shell. La méthode Start passe ces valeurs à pmfadm en utilisant les options - n et -t. 

# Récupère la valeur du nombre de tentatives dans le fichier RTR.
RETRY_CNT=`scha_resource_get -O Retry_count -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`
# Récupère la valeur de l'intervalle de tentative dans le fichier RTR. Cette valeur est en secondes
# et doit être convertie en minutes pour être passée à pmfadm. Remarquez que la 
# conversion est arrondie à la valeur supérieure ; par ex., 50 secondes est arrondi à 1 minute.
((RETRY_INTRVAL=`scha_resource_get -O Retry_interval -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME` / 60))

# Démarrer le démon in.named sous le controle de PMF. Il peut s'arrêter et redémarrer
# jusqu'à $RETRY_COUNT fois dans l'intervalle $RETRY_INTERVAL. S'il s'interrompt
# plus souvent, PMF cessera d'essayer de le redémarrer.
# Si un processus est déjà enregistré sous la marque 
# <$PMF_TAG>, PMF envoie 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

# Consigne 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 terminer avec un code de succès tant que l'application correspondante n'est pas effectivement en cours d'exécution et disponible, particulièrement si d'autres services de données en dépendent. L'un des moyens à votre disposition pour vérifier le succès de la méthode consiste à sonder l'application afin de vous assurer qu'elle fonctionne avant de quitter la méthode Start. Pour une application complexe, telle qu'une base de données, veillez à définir la propriété Start_timeout dans le fichier RTR sur une valeur suffisamment élevée pour permettre à l'application de s'initialiser et le cas échéant de récupérer après une panne.

Remarque –

comme la ressource d'application (DNS) du service de données modèle démarre rapidement, la méthode de démarrage du service de données ne l'interroge pas pour vérifier son fonctionnement avant de se terminer avec succès.

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 qui a donc la valeur par défaut NONE (sauf si l'administrateur du cluster remplace la valeur par défaut par une autre valeur). Dans ce cas, le RGM ne prend pas de mesure autre que la définition de l'état du service de données. L'administrateur du cluster doit lancer un redémarrage sur le même nœud ou un basculement sur un autre nœud.

Fonctionnement de la méthode Stop

Le gestionnaire RGM exécute la méthode d'Arrêt 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 d'Arrêt pour l'application modèle. Cette rubrique ne décrit pas les fonctionnalités communes à toutes les méthodes de rappel, comme par exemple la fonction parse_args(). Par ailleurs, elle ne décrit pas l'utilisation de la fonction syslog(). Les fonctionnalités communes sont décrites à la rubrique Fonctionnalité commune à toutes les méthodes.

Pour la liste complète du code de la méthode Stop, reportez-vous à la rubrique Listing de code de la méthode Stop.

Fonction 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 façon d'effectuer un arrêt correct est d'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 Échec_arrêt. La meilleure solution pour placer le service de données dans cet état est d'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 ce signal ne parvient pas à arrêter le service de données, elle envoie un signal SIGKILL .

Avant de tenter d'arrêter le DNS, cette méthode d'Arrêt vérifie si le processus tourne effectivement. Si le processus est en cours d'exécution, Stop utilise la fonction PMF (pmfadm) pour l'arrêter.

L'idempotence de cette méthode Stop est garantie. Bien que le gestionnaire RGM ne doive pas appeler deux fois une méthode Stop sans démarrer au préalable le service de données par un appel à sa méthode Start, le RGM pourrait appeler une méthode Stop sur une ressource alors que celle-ci n'a jamais été démarrée ou s'est déjà arrêtée d'elle-même. C'est pourquoi cette méthode Arrêt 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 ordonnée ou en douceur utilisant un signal SIGTERM par l'intermédiaire de pmfadm et une approche brutale utilisant un signal SIGKILL. La méthode Stop obtient la valeur Stop_timeout (le délai avant lequel la méthode Stop doit se terminer). Arrêt alloue alors 80 % de ce temps à un arrêt en douceur et 15 % à un arrêt abrupt (5 % sont réservés), de la manière indiquée dans l'exemple de code suivant. 

STOP_TIMEOUT='scha_resource_get -O STOP_TIMEOUT -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME'
((SMOOTH_TIMEOUT=$STOP_TIMEOUT * 80/100))
((HARD_TIMEOUT=$STOP_TIMEOUT * 15/100))

La méthode d'Arrêt utilise pmfadm -q pour vérifier si le démon DNS fonctionne. Si le démon DNS est en cours d'exécution, Stop utilise d'abord pmfadm -s pour envoyer un signal TERM afin de terminer le processus DNS. Si ce signal ne parvient pas à terminer le processus après 80 % de la valeur de délai d'attente, Stop envoie un signal SIGKILL. Si ce signal ne parvient pas non plus à terminer le processus après 15 % de la valeur de délai d'attente, la méthode consigne un message d'erreur et se termine avec un état d'erreur.

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. 

# Voir si in.named est en cours d'exécution, et si oui, le tuer. 
if pmfadm -q $PMF_TAG; then
   # Envoyer un signal SIGTERM au service de données et attendre 80% 
   # de la valeur de délai d'attente totale.
   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”
      
      # Comme le service de données ne s'est pas arrêté avec un signal SIGTERM, utiliser 
      # maintenant SIGKILL et attendre encore 15% de la valeur de délai d'attente totale.
      pmfadm -s $PMF_TAG -w $HARD_TIMEOUT KILL
      if [ $? -ne 0 ]; then
          logger -p ${SYSLOG_FACILITY}.err \
          -t [$SYSLOG_TAG] \
          “${ARGV0} Failed to stop HA-DNS; Exiting UNSUCCESSFUL”
         exit 1
      fi
fi
else 
   # Le service de données ne fonctionne pas pour l'instant. Consigner un message et 
   # quitter avec un code de succès.
   logger -p ${SYSLOG_FACILITY}.err \
           -t [$SYSLOG_TAG] \
           “HA-DNS is not started”

   # Même si HA-DNS ne fonctionne pas, quitter avec un code de succès afin d'éviter
  # de placer la ressource du service de données à l'état STOP_FAILED.
   exit 0
fi

# L'arrêt du DNS a réussi. Consigner un message et quitter avec un code de succès.
logger -p ${SYSLOG_FACILITY}.err \
    -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
    “HA-DNS successfully stopped”
exit 0

État d'Arrêt à la fermeture

Une méthode Stop ne doit pas se terminer avec un code de succès tant que l'application correspondante n'est pas effectivement arrêtée, particulièrement 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é Délai_arrêt 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é Mode_basculement, qui détermine la réaction à adopter. Le service de données modèle ne définit pas explicitement la propriété Failover_mode qui a donc la valeur par défaut NONE (sauf si l'administrateur du cluster remplace la valeur par défaut par une autre valeur). Dans ce cas, le gestionnaire RGM se contente de définir l'état du service de données sur Stop_failed. L'administrateur du cluster doit 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 oeuvre 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 des éléments suivants :

Fonctionnement du programme de sonde

Le programme dns_probe met en oeuvre un processus qui vérifie en permanence que la ressource DNS contrôlée par le service de données modèle fonctionne. Le programme dns_probe est démarré par la méthode dns_monitor_start, elle-même automatiquement exécutée par le RGM lorsque le service de données modèle a été mis en ligne. Le service de données est arrêté par la méthode dns_monitor_stop, que le RGM exécute avant de mettre le service de données modèle hors ligne.

Cette rubrique décrit les principaux éléments de la méthode SONDE pour l'application modèle. Elle ne décrit pas les fonctionnalités communes à toutes les méthodes de rappel, comme par exemple la fonction parse_args(). Par ailleurs, elle ne décrit pas l'utilisation de la fonction syslog(). Les fonctionnalités communes sont décrites à la rubrique Fonctionnalité commune à toutes les méthodes.

Pour une liste complète du code de la méthode PROBE, reportez-vous à la rubrique Listing de code du programme PROBE.

Fonction du programme de sonde

Probe tourne en boucle infinie. Il utilise nslookup pour vérifier que la ressource DNS correcte fonctionne. Si le DNS fonctionne, la sonde passe en mode sommeil pendant un intervalle prédéfini (via la propriété système Thorough_probe_interval), puis vérifie à nouveau. 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 noeud.

Obtention des valeurs des propriétés

Ce programme requiert les valeurs des propriétés suivantes :

La fonction scha_resource_get() obtient les valeurs de ces propriétés et les stocke dans des variables de shell, comme cela est indiqué ci-après : 

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`
Remarque –

pour les propriétés définies au niveau système, comme par exemple Thorough_probe_interval , la fonction scha_resource_get() renvoie la valeur uniquement. Pour les propriétés d'extension, comme par exemple Probe_timeout, la fonction scha_resource_get() retourne le type et la valeur. Utilisez la commande awk pour obtenir la valeur seule.

Contrôle de la fiabilité du service

La sonde elle-même est une boucle while infinie de commandes nslookup. Un fichier temporaire est défini avant la boucle while pour recevoir les réponses de nslookup. Les variables probefail et retries sont initialisées à 0. 

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

La boucle while assure les tâches suivantes :

Voici le code de la boucle while. 

while :
do
   # L'intervalle d'exécution de la sonde est spécifié dans la propriété
   # THOROUGH_PROBE_INTERVAL. Par conséquent, configurer la sonde en mode sommeil
  # pour une durée de THOROUGH_PROBE_INTERVAL.
   sleep $PROBE_INTERVAL

   # Exécute une commande nslookup de l'adresse IP servie par le DNS.
   hatimerun -t $PROBE_TIMEOUT /usr/sbin/nslookup $DNS_HOST $DNS_HOST \
   > $DNSPROBEFILE 2>&1

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

   # S'assurer que la réponse à nslookup vienne du serveur HA-DNS
   # et non d'un autre serveur de noms mentionné dans le fichier 
   # /etc/resolv.conf.
   if [ $probefail -eq 0 ]; then
# Obtenir le nom du serveur qui a répondu à l'interrogation 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

Comparaison du redémarrage et du basculement

Si la variable probefail est différente de 0 (succès), le délai de la commande nslookup a expiré ou la réponse est venue d'un serveur autre que le serveur 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 noeud. Si la variable probefail est 0, un message est généré indiquant que la sonde a réussi. 

   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 une fenêtre temporelle (Retry_interval) et un compteur d'échecs (Retry_count) afin de déterminer s'il convient ou non de redémarrer le DNS localement ou de demander que le RGM déplace le service de données sur un autre noeud. Cette fonction met en oeuvre la logique conditionnelle suivante. La liste du code de decide_restart_or_failover() dans la rubrique Listing de code du programme PROBE contient le code utilisé.

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 noeud. 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 noeud. 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 redémarrer le service de données sur le même noeud. Cette fonction exécute la logique suivante :

function restart_service
{

        # Pour redémarrer le service de données, vérifiez d'abord que 
        # le service de données lui-même est toujours enregistré sous le PMF.
        pmfadm -q $PMF_TAG
        if [[ $? -eq 0 ]]; then
                # Comme le TAG pour le service de données est toujours enregistré
                # sous le PMF, arrêtez d'abord le service de données, puis redémarrez-le.

                # Récupérez le nom de la méthode d'arrêt et la valeur 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

                # Récupérez le nom de la méthode de démarrage et la valeur 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 du TAG pour le service de données 
                # implique le service de données a déjà dépassé
                # le nombre maximum de tentatives autorisées sous le PMF.
                # Par conséquent, ne tentez pas de redémarrer le
                # service de données, mais essayez de le basculer
                # sur un autre noeud dans le cluster.
                scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \
                        -R $RESOURCE_NAME
        fi

        return 0
}

État de la sonde à la fermeture

Le programme PROBE du service de données modèle se termine avec un code d'échec si toutes les tentatives de redémarrage local échouent et que la tentative de basculement sur un autre noeud échoue également. Ce programme consigne le message Failover attempt failed.

Fonctionnement de la méthode Monitor_start

Le RGM appelle la méthode de Démarrage_détecteur pour démarrer la méthode de 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. Cette rubrique ne décrit pas les fonctionnalités communes à toutes les méthodes de rappel, comme par exemple la fonction parse_args(). Par ailleurs, elle ne décrit pas l'utilisation de la fonction syslog(). Les fonctionnalités communes sont décrites à la rubrique Fonctionnalité commune à toutes les méthodes.

Pour obtenir une liste complète du code de la méthode Monitor_start, reportez-vous à la rubrique Listing de code de la méthode Monitor_start.

Action de la méthode Monitor_start

Cette méthode utilise le PMF (pmfadm) pour démarrer la sonde.

Démarrage de la sonde

La méthode Démarrage_détecteur obtient la valeur de la propriété Rép_base_TR pour construire le nom entier du chemin d’accès du programme de SONDE. Cette méthode démarre la sonde en utilisant l'option "essayer indéfiniment" de pmfadm (-n -1, -t -1), ce qui signifie que si le démarrage de la sonde échoue, le PMF essaiera de la démarrer un nombre infini de fois sans limites de temps. 

# 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émarre la sonde pour le service de données sous le PMF. Utilise l'option
# "essayer indéfiniment" pour démarrer la sonde. Passe le nom de la ressource,
# son type et son groupe au programme de sonde. 
pmfadm -c $RESOURCE_NAME.monitor -n -1 -t -1 \
   $RT_BASEDIR/dns_probe -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME

Fonctionnement de la méthode Monitor_stop

Le RGM appelle la méthode d'Arrêt_détecteur 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. Cette rubrique ne décrit pas les fonctionnalités communes à toutes les méthodes de rappel, comme par exemple la fonction parse_args(). Par ailleurs, elle ne décrit pas l'utilisation de la fonction syslog(). Les fonctionnalités communes sont décrites à la rubrique Fonctionnalité commune à toutes les méthodes.

Pour obtenir une liste complète du code de la méthode Monitor_stop, reportez-vous à la rubrique Listing de code de la méthode Monitor_stop.

Action de la méthode Monitor_stop

Cette méthode utilise le PMF (pmfadm) pour vérifier si la sonde fonctionne et, dans ce cas, l'arrête.

Arrêt du détecteur

La méthode Arrêt_détecteur 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.

Attention – Attention –

Veillez à utiliser le signal KILL avec pmfadm pour arrêter la sonde et non un signal susceptible d'être masqué, comme par exemple TERM. Sinon, la méthode Monitor_stop peut se bloquer indéfiniment et son délai d'attente expirer. En effet, la méthode PROBE appelle scha_control() lorsqu'il est nécessaire de redémarrer ou de basculer le service de données. Lorsque scha_control() appelle Monitor_stop pendant le processus de mise hors ligne du service de données, si Monitor_stop utilise un signal qui peut être masqué, Monitor_stop se bloque en attendant la fin de scha_control(), tandis que scha_control() se bloque en attendant la fin de Monitor_stop. 

# Voir si le détecteur fonctionne et si oui, le tuer.
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 réussi du détecteur. Consigner un message.
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Monitor for resource " $RESOURCE_NAME \
            " successfully stopped"
   fi
fi
exit 0

État d'Arrêt_détecteur à 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 place le service de données modèle en mode MONITOR_FAILED sur le noeud primaire, ce qui peut entraîner une erreur grave du noeud.

Arrêt_détecteur ne doit pas se fermer avant l'arrêt de la sonde.

Fonctionnement de la méthode Monitor_check

Le RGM appelle la méthode Monitor_check lorsque la méthode de SONDE tente de basculer le groupe de ressources contenant le service de données vers un autre noeud.

Cette rubrique décrit les principaux éléments de la méthode Monitor_check pour l'application modèle. Cette rubrique ne décrit pas les fonctionnalités communes à toutes les méthodes de rappel, comme par exemple la fonction parse_args(). Par ailleurs, elle ne décrit pas l'utilisation de la fonction syslog(). Les fonctionnalités communes sont décrites à la rubrique Fonctionnalité commune à toutes les méthodes.

Pour obtenir une liste complète du code de la méthode Monitor_check, reportez-vous à la rubrique Listing de code de la méthode Monitor_check.

La méthode Monitor_check doit être mise en oeuvre de manière à ne pas entraîner de conflits avec d'autres méthodes qui sont exécutées simultanément.

La méthode Monitor_check appelle la méthode Validate pour vérifier que le répertoire de configuration du DNS est disponible sur le nouveau noeud. La propriété d'extension Confdir pointe vers le répertoire de configuration du DNS. Par conséquent, Monitor_check obtient le chemin d'accès et le nom pour la méthode Validate, ainsi que la valeur de Confdir. Elle transmet cette valeur à Validation , comme le montre l'affichage suivant : 

# Obtenez le chemin d'accès complet pour 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È

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

# Obtenez la valeur de la propriété Confdir afin de démarrer le service
# de données. Utilisez le nom de ressource et le groupe de ressource 
# entrés pour obtenir la valeur de Confdir définie lors de l'ajout de la 
# ressource.
config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
 -G $RESOURCEGROUP_NAME Confdir`

# scha_resource_get retourne le type et la valeur pour les propriétés
# d'extension. Utilisez awk pour obtenir uniquement la valeur de la 
# propriété d'extension.
CONFIG_DIR=`echo $config_info | awk `{print $2}'`

# Appelez la méthode validate afin que le service de données puisse 
# être correctement basculé sur le nouveau noeud.
$RT_BASEDIR/$VALIDATE_METHOD -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME -x Confdir=$CONFIG_DIR

Reportez-vous à la rubrique Fonctionnement de la méthode Validate pour comprendre comment l'application modèle vérifie si un noeud peut convenir pour l'hébergement du service de données.

Gestion des mises à jour des propriétés

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

Fonctionnement de la méthode Validate

Le RGM appelle la méthode de Validation 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 Validation avant la création ou la mise à jour, et un code de sortie avec échec issu de la méthode sur un noeud entraîne l'annulation de la création ou de la mise à jour.

Le RGM n'appelle Validate que si l'administrateur du cluster modifie les propriétés de la ressource ou du groupe de ressources, et non lorsque le RGM définit des propriétés ou qu'un détecteur définit les propriétés de ressource Status ou Status_msg.

Remarque –

la méthode Monitor_check appelle aussi explicitement la méthode Validate à chaque fois que la méthode PROBE tente de basculer le service de données sur un nouveau noeud.

Actions de la méthode Validate

Le RGM appelle Validate avec des arguments supplémentaires par rapport à ceux passés à d'autres méthodes, et notamment avec les propriétés et valeurs qui sont mises à jour. Par conséquent, cette méthode du service de données modèle doit mettre en oeuvre une fonction parse_args() différente pour gérer les arguments supplémentaires.

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 fonctionne, la propriété Confdir est déclarée TUNABLE = AT_CREATION dans le fichier RTR. La méthode Validate n'est donc jamais appelée pour vérifier la propriété Confdir après une mise à jour, mais seulement lors de la création de la ressource du service de données.

Si Confdir est l'une des propriétés que le RGM passe à Validate, la fonction parse_args() récupère et enregistre sa valeur. Validate vérifie que le répertoire désigné par la nouvelle valeur de Confdir est accessible et qu'il existe bien dans ce répertoire un fichier named.conf qui contient des données.

Si la fonction parse_args() ne peut récupérer la valeur de Confdir à partir des arguments de ligne de commande que lui transmet le RGM, Validate essaie malgré tout de valider la propriété Confdir. Validate utilise scha_resource_get() pour obtenir la valeur de Confdir à partir de la configuration statique. Validate effectue les mêmes contrôles pour vérifier que le répertoire de configuration est accessible et contient un fichier named.conf non vide.

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 Validation

Le RGM passant à la méthode Validate une série d'arguments différente de celle transmise aux autres méthodes de rappel, Validate requiert une fonction d'analyse des arguments différente de celle des autres méthodes. Reportez-vous à la page de manuel rt_callbacks(1HA) pour obtenir plus d'informations sur les arguments passés à Validate et aux autres méthodes de rappel. L'exemple de code suivant illustre la fonction parse_args() de Validate . 

#########################################################################
# Analyse les arguments de Validate.
#
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 de ressources dans lequel la 
                  # ressource est configurée.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
         T)
                  # Nom du type de ressource.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
         r)
                  # La méthode n'accède à aucune propriété 
                  # définie au niveau système, d'où l'opération ineffective
                  ;;
         g)
                  # La méthode n'accède à aucune propriété de
                  # groupe de ressources, d'où l'opération ineffective
                  ;;
         c)
                  # Indique que la méthode Validate est appelée lors
                  # de la création de la ressource, l'indicateur est donc ineffectif.
                  ;;
         u)
                  # Indique la mise à jour d'une propriété lorsque la
                  # ressource existe déjà. Si la mise à jour concerne la 
                  # propriété Confdir, alors Confdir doit apparaître dans les
                  # arguments de ligne de commande. Sinon, la méthode doit
                  # spécifiquement le rechercher avec scha_resource_get.
                  UPDATE_PROPERTY=1
                  ;;
         x)
                  # Liste de propriétés d'extension. Séparer les paires 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 Confdir est trouvée sur la ligne
                  # de commande, enregistrer 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() pour d'autres méthodes, cette fonction fournit 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 la ressource qui est passée par le RGM.

L'indicateur r (qui indique une propriété définie par le système), l'indicateur g (qui indique une propriété de groupe de ressource) et l'indicateur c (qui indique que la validation est effectuée pendant la création de la ressource) sont ignorés, car cette méthode est appelée pour valider une propriété d'extension lorsque la ressource est mise à jour.

L'indicateur u définit la variable de shell UPDATE_PROPERTY à 1 (TRUE). L'indicateur x capture les noms et valeurs des propriétés qui sont 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 définie sur 1 (TRUE).

Validation de Confdir

Dans sa fonction MAIN, Validate définit d'abord la variable CONFDIR sur la chaîne vide et UPDATE_PROPERTY et CONFDIR_FOUND sur 0. 

CONFDIR=""
UPDATE_PROPERTY=0
CONFDIR_FOUND=0

Validate appelle parse_args() pour analyser les arguments passés par le RGM. 

parse_args “$@”

Validate vérifie si Validate est appelée en conséquence d'une mise à jour des propriétés. Validate vérifie également si la propriété d'extension Confdir était sur la ligne de commande. Validate s'assure que la propriété Confdir a une valeur et, dans le cas contraire, se termine avec un état d'échec et 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érifie que la propriété Confdir a une valeur. Sinon, c'est un échec
# et la fonction se termine 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 –

spécifiquement, le code précédent vérifie si Validate est appelée en conséquence d'une mise à jour ($UPDATE_PROPERTY == 1) et si la propriété n'a pas été trouvée sur la ligne de commande ( CONFDIR_FOUND == 0). Dans ce cas, le code récupère la valeur existante de Confdir en utilisant scha_resource_get(). Si Confdir est présent sur la ligne de commande (CONFDIR_FOUND == 1), la valeur de CONFDIR est obtenue par la fonction parse_args(), non par scha_resource_get().

La méthode Validate utilise la valeur de CONFDIR pour vérifier que le répertoire est accessible. Si le répertoire n'est pas accessible, Validate consigne un message d'erreur et se termine avec un état d'erreur. 

# 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é Rép_conf, Validation effectue un contrôle final pour vérifier si le fichier named.conf est présent. Si le fichier n'est pas présent, la méthode consigne un message d'erreur et se termine avec un état d'erreur. 

# 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 la vérification finale réussit, Validate consigne un message indiquant le succès et se termine avec un état de succès. 

# 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 Validation à la fermeture

Si Validate se termine avec succès (0), Confdir est créé avec la nouvelle valeur. Si Validate se termine avec un échec (1), Confdir et les autres propriétés éventuelles ne sont pas créées et un message en indiquant la cause est généré.

Fonctionnement de la méthode Update

Le RGM exécute la méthode de Mise_à_jour pour notifier à une ressource en cours d'exécution que ses propriétés ont changé. Le RGM exécute Update après que l'administrateur du cluster ait fini de définir les propriétés d'une ressource ou de son groupe. Cette méthode est appelée sur les noeuds sur lesquels la ressource est en ligne.

Action de la méthode Update

La méthode Update ne met pas à jour les propriétés. C'est le rôle du RGM. La méthode Update notifie certains processus en cours d'exécution qu'une mise à jour a été effectuée. Le seul processus, dans le service de données modèle, affecté par une mise à jour de propriété est le détecteur de pannes. Par conséquent, la méthode Update arrête et redémarre le processus du détecteur de pannes.

La méthode Update doit vérifier que le détecteur de pannes est en cours d'exécution, puis le tuer à l'aide de la commande pmfadm. La méthode obtient l'emplacement du programme de sonde qui met en oeuvre le détecteur de pannes, et le redémarre par l'intermédiaire de la commande pmfadm.

Arrêt du détecteur à l’aide de la méthode Update

La méthode Update utilise pmfadm -q pour vérifier que le détecteur fonctionne et, si tel est le cas, le tue avec pmfadm -s TERM. Si le détecteur se termine correctement, un message en ce sens est envoyé à l'administrateur du cluster. Si le détecteur ne peut être arrêté, Update se termine avec un code d'échec et envoie un message d'erreur à l'administrateur du cluster. 

if pmfadm -q $RESOURCE_NAME.monitor; then

# Tuer le détecteur déjà 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 détecteur réussi. 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 Mise_à_jour doit localiser le script mettant en oeuvre le programme de sonde. Le programme de sonde se trouve dans le répertoire de base du service de données, vers lequel pointe la propriété RT_basedir. Update récupère la valeur de RT_basedir et l'enregistre dans la variable RT_BASEDIR, de la manière suivante : 

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

Update utilise la valeur de RT_BASEDIR avec pmfadm pour redémarrer le programme dns_probe. En cas de succès, Update se termine avec un code de succès et envoie un message en ce sens à l'administrateur du cluster. Si pmfadm ne parvient pas à démarrer le programme de sonde, Update se termine avec un code 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 est sans effet sur la gestion de la ressource par le RGM, mais indique l'échec de l'action de mise à jour aux outils d'administration via la fonction syslog().