Guide des développeurs pour les services de données Sun Cluster 3.1 10/03

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 oeuvre, 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 noeuds 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 noeud.

Le redémarrage de l'application est géré par le gestionnaire des 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 noeud.

Le service de données modèle fournit une surveillance des pannes sous la forme d'une méthode de SONDE. 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 noeud du cluster.

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

Un fichier d'enregistrement du type de ressource identifiant les propriétés statiques du service de données.
Une méthode de rappel de Démarrage appelée par le RGM de manière à démarrer le démon in.named lorsque le groupe de ressources contenant le service de données HA-DNS est mis en ligne.
Une méthode de rappel d'Arrêt appelée par le RGM pour arrêter le démon in.named lorsque le groupe de ressources contenant HA-DNS passe hors ligne.
Un détecteur de pannes permettant de vérifier la disponibilité du service en s'assurant que le serveur DNS tourne. Le détecteur de pannes est mis en oeuvre par une méthode de SONDE définie par l'utilisateur. Il est lancé et arrêté par les méthodes de rappel de Démarrage_détecteur et d'Arrêt_détecteur.
Une méthode de rappel de Validation appelée par le RGM afin de valider l'accessibilité du répertoire de configuration du service.
Une méthode de rappel de Mise_à_jour appelée par le RGM afin de redémarrer le détecteur de pannes quand l'administrateur système modifie la valeur d'une propriété de ressource.

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 de manuel 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”

TYPE_RESSOURCE = “modèle”;
ID_FOURNISSEUR = SUNW;
DESCRIPTION_TR = “service DNS sur Sun Cluster”;

VERSION_TR =”1.0”;
VERSION_API = 2;
BASCULEMENT = VRAI;

RÉP_BASE_TR=/opt/SUNWsample/bin;
LISTE_PACKAGES = SUNWsample;

DÉMARRAGE           =   dns_svc_start;
ARRÊT               =   dns_svc_stop;

VALIDATION          =   dns_validate;
MISE_À_JOUR         =   dns_update;

DÉMARRAGE_DÉTECTEUR =   dns_monitor_start;
ARRÊT_DÉTECTEUR     =   dns_monitor_stop;
CONTRÔLE_DÉTECTEUR  =   dns_monitor_check;

Astuce :

vous devez déclarer la propriété Type_ressource comme première entrée du fichier RTR. Dans le cas contraire, l'enregistrement du type de ressource échoue.

Remarque :

dans les noms de propriété, le RGM établit une différence entre les majuscules et les minuscules. La convention applicable aux propriétés dans les fichiers RTR fournis par Sun, à l'exception des noms de méthode, est la majuscule à l'initiale du nom, et des minuscules partout ailleurs. Les noms de méthodes, de même que les attributs de propriété, contiennent uniquement des lettres majuscules.

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

Le nom du type de ressource peut être spécifié par la propriété Type_ressource seule (sample) ou en utilisant l'Id_fournisseur comme préfixe avec un “.” le séparant du type de ressource (SUNW.sample).

Si vous utilisez l'Id_fournisseur, choisissez le symbole de l'entreprise pour la définition du type de ressource. Le nom du type de ressource doit être unique dans le cluster.
La propriété Version_TR identifie la version du service de données modèle telle que spécifiée par le fournisseur.
La propriété Version_API identifie la version de Sun Cluster. Par exemple, Version_API = 2 indique que le service de données tourne sous Sun Cluster version 3.0.
Basculement = VRAI indique que le service de données ne peut pas tourner dans un groupe de ressources susceptible d'être en ligne sur plusieurs noeuds à la fois.
rép_base_TR pointe vers /opt/SUNWsample/bin comme le chemin de répertoire permettant de compléter les chemins relatifs, tels que les chemins de méthode de rappel.
Démarrage, Arrêt, Validation, etc. proposent les chemins pointant vers les programmes de méthode rappel respectifs appelés par le RGM. Ces chemins sont fonction du répertoire spécifié par rép_base_TR.
Liste_packages identifie SUNWsample comme le package contenant l'installation du service de données modèle.

Les propriétés du type de ressource non spécifiées dans ce fichier RTR, par exemple Instance_unique, noeuds_init et Noeuds_installés , reçoivent leur valeur par défaut. Reportez-vous au Tableau A–1 pour obtenir une liste complète des propriétés du type de ressource, avec leurs valeurs 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 <Délai_exécution_[méthode] 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 noeuds
# ou passage du groupe de ressources à l'état ERREUR_ÉCHEC_ARRÊT, 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.
{
   PROPRIÉTÉ = Délai_démarrage;
   MIN=60;
   PAR DÉFAUT=300;
}

{
   PROPRIÉTÉ = Délai_arrêt;
   MIN=60;
   PAR DÉFAUT=300;
}
{
        PROPRIÉTÉ = Délai_validation;
        MIN=60;
        PAR DÉFAUT=300;
}
{
        PROPRIÉTÉ = Délai_mise_à_jour;
        MIN=60;
        PAR DÉFAUT=300;
}
{
        PROPRIÉTÉ = Délai_démarrage_détecteur;
        MIN=60;
        PAR DÉFAUT=300;
}
{
        PROPRIÉTÉ = Délai_arrêt_détecteur;
        MIN=60;
        PAR DÉFAUT=300;
}
{
        PROPRIÉTÉ = Intervalle_sonde_complet;
        MIN=1;
        MAX=3600;
        PAR DÉFAUT=60;
        RÉGLABLE = À_TOUT_MOMENT;
}

# 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 noeud.
{
        PROPRIÉTÉ = Nombre_nouvelles_tentatives;
        MIN=0;
        MAX=10;
        PAR DÉFAUT=2;
        RÉGLABLE = À_TOUT_MOMENT;
}

# Définissez une valeur multiple de 60 pour Intervalle_nouvelles_tentatives, é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 (Nombre_nouvelles_tentatives).
{
        PROPRIÉTÉ = Intervalle_nouvelles_tentatives;
        MIN=60;
        MAX=3600;
        PAR DÉFAUT=300;
        RÉGLABLE = À_TOUT_MOMENT;
}

{
        PROPRIÉTÉ = Ressources_réseau_utilisées;
        RÉGLABLE = À_LA_CRÉATION;
        PAR DÉFAUT = ““;
}

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 ressource 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 :

Sun Cluster fournit une valeur minimale (1 seconde) et une valeur par défaut (3600 secondes) pour tous les dépassements de délais impartis. Le fichier RTR modèle modifie le minimum à 60 et fait passer la valeur par défaut à 300 secondes. Un administrateur de clusters peut accepter cette valeur par défaut ou modifier la valeur du délai imparti (à 60 ou plus). Sun Cluster n'impose pas de valeur maximale autorisée.
Les propriétés Intervalle_sonde_complet, Nombre_nouvelles_tentatives et Intervalle_nouvelles_tentatives ont la valeur À_TOUT_MOMENT pour l'attribut RÉGLABLE. Ce paramètre signifie que l'administrateur du cluster peut modifier la valeur de ces propriétés, même lorsque le service de données tourne. Celles-ci sont utilisées par le détecteur de pannes mis en oeuvre par le service de données modèle. Le service de données modèle met en oeuvre une méthode de Mise_à_jour pour arrêter et redémarrer le détecteur de pannes lors de la modification de ces propriétés de ressource ou d'autres par l'administrateur. Reportez-vous à la rubrique Méthode de Mise_à_jour.
Les propriétés de ressource sont classifiées comme :
- requises : l'administrateur du cluster doit spécifier une valeur à la création d'une ressource.
- optionnelles : si l'administrateur ne spécifie pas de valeur, le système en renseigne une par défaut.
- conditionnelles : le RGM ne crée la propriété que si elle est déclarée dans le fichier RTR.
Le détecteur de pannes du service de données modèle utilise les propriétés conditionnelles Intervalle_sonde_complet, Nombre_nouvelles_tentatives, Intervalle_nouvelles_tentatives et Ressources_réseau_utilisées, de telle manière que le développeur a dû les déclarer dans le fichier RTR. Reportez-vous à la page du manuel r_properties(5) ou à la rubrique Propriétés des ressources pour obtenir des informations sur la manière dont les propriétés sont classifiées.

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).
{
   PROPRIÉTÉ = Rép_conf;
   EXTENSION;
   CHAÎNE;
   RÉGLABLE = À_LA_CRÉATION;
   DESCRIPTION = “Chemin du répertoire de configuration”;
}

# Délai en secondes avant la déclaration d'un échec de la sonde.
{
        PROPRIÉTÉ = Délai_sonde;
        EXTENSION;
        INT;
        PAR DÉFAUT = 120;
        RÉGLABLE = À_TOUT_MOMENT;
        DESCRIPTION = “Délai imparti pour la sonde (secondes)”;
}

Le fichier RTR modèle définit deux propriétés d'extension, Rép_conf et Délai_sonde. Rép_conf 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 de Démarrage et de Validation 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 de Démarrage vérifie que le nouveau répertoire est accessible.

La méthode de SONDE 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é Délai_sonde 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 Délai_sonde.

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 Validation) 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 de sonde_dns, de démarrage_svc_dns, d'arrêt_svc_dns et de contrôle_détecteur_dns définissent PMF_TAG comme suit (l'usage de pmfadm et de logger provient de la méthode arrêt_svc_dns ) :

#########################################################################
# 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 de démarrage_détecteur_dns, d'arrêt_détecteur_dns et de mise_à_jour_dns définissent PMF_TAG comme suit (l'usage de pmfadm provient de la méthode arrêt_détecteur_dns) :

#########################################################################
# 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, le tuer.
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 Validation, 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 oeuvre 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é rép_base_TR, é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 :

RÉP_BASE_TR=/opt/SUNWsample/bin;
DÉMARRAGE = démarrage_svc_dns;
ARRÊT = arrêt_svc_dns;
...

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 de manuel rt_callbacks(1HA) pour de plus amples informations sur les méthodes de rappel.

Remarque :

la méthode de Validation est appelée avec des arguments supplémentaires (les valeurs des propriétés de la ressource et du groupe de ressources sources de 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. Étant donné que tous les rappels sont 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.
                  NOM_RESSOURCE=$OPTARG
                  ;;
             G)
                  # Nom du groupe de ressources dans laquelle est
                  # configurée la ressource.
                  NOM_GROUPE_RESSOURCE=$OPTARG
                  ;;
             T)
                  # Nom du type de ressource.
                  NOM_TYPE_RESSOURCE=$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 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 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 finals. 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 de Démarrage 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 de manuel 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 Démarrage_détecteur doit localiser le programme de sonde de manière à pouvoir le lancer. Le programme de sonde réside dans le répertoire de base du service de données, vers lequel pointe la propriété REP_BASE_TR. Ainsi, la méthode Démarrage_détecteur récupère la valeur de REP_BASE_TR et la place dans la variable REP_BASE_TR, de la manière suivante :

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

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 délai_sonde, puis utilise awk pour ne placer la variable que dans la variable de shell DÉLAI_SONDE, de la manière suivante :

info_délai_sonde=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Probe_timeout`
DÉLAI_SONDE=`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 oeuvre des méthodes de Démarrage et d'Arrêt. Reportez-vous à la rubrique Choix des méthodes de Démarrage et d'Arrêt à utiliser pour de plus amples informations sur les usages alternatifs de Démarrage_avant_réseau et de Arrêt_après_réseau.

Méthode de `Démarrage`

Le RGM appelle la méthode de Démarrage sur un noeud de cluster lorsque le groupe de ressources contenant la ressource du service de données est mis en ligne sur ce noeud ou lorsque le groupe de ressources est déjà en ligne et la ressource activée. Dans l'application modèle, la méthode de Démarrage active le démon in.named (DNS) sur ce noeud.

Cette rubrique décrit les principaux éléments de la méthode de Démarrage 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 Démarrage, reportez-vous à la rubrique Méthode de Démarrage.

Présentation de `Démarrage`

Avant de tenter de lancer le DNS, la méthode de Démarrage 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 le gestionnaire des processus (pmfadm ) pour lancer le démon DNS (in.named). Si DNS se bloque ou n'arrive pas à démarrer, le gestionnaire des 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 de Démarrage 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 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. 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 de Démarrage récupère l'emplacement du répertoire de configuration à l'aide de la fonction scha_resource_get().

Remarque :

rép_conf é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, RÉP_CONFIG.

# trouver la valeur de Rép_dir 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.
RÉP_CONFIG=`echo $config_info | awk '{print $2}'`

La méthode de Démarrage utilise alors la valeur de RÉP_CONFIG pour vérifier si le répertoire est accessible. Si ce n'est pas le cas, Démarrage consigne un message d'erreur et se ferme en affichant un état d'échec. Reportez-vous à la rubrique État de Démarrage à 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, Démarrage 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 des 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, Nombre_nouvelles_tentatives, indiquant le nombre de tentatives de redémarrage d'une application, et Intervalle_nouvelles_tentatives, indiquant le délai de ces tentatives.

La méthode de Démarrage récupère les valeurs de Nombre_nouvelles_tentatives et de Intervalle_nouvelles_tentatives à 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_NAMÈ
# 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.
((INTRVAL_NOUVELLES_TENTATIVES=`scha_resource_get -O Intervalle_nouvelles_tentatives -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 `Démarrage` à la fermeture

Une méthode de Démarrage 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 de Démarrage. Pour une application complexe telle qu'une base de données, dans le fichier RTR, veillez à définir pour la propriété Délai_démarrage 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é Mode_basculement, qui détermine la réaction à adopter. Le service de données modèle ne définit pas explicitement la propriété Mode_basculement. Par conséquent, cette propriété a la valeur par défaut AUCUN (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 noeud ou le basculement vers un autre noeud.

Méthode d'`Arrêt`

La méthode d'Arrêt est appelée sur un noeud du cluster lorsque le groupe de ressources contenant la ressource HA-DNS passe hors ligne sur ce noeud 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 noeud.

Cette rubrique décrit les principaux éléments de la méthode d'Arrêt 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 d'Arrêt, reportez-vous à la rubrique Méthode d'Arrêt.

Présentation d'`Arrêt`

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 Échec_arrêt. La meilleure manière pour y arriver consiste à envoyer un signal SIGKILL par l'intermédiaire de pmfadm.

La méthode d'Arrêt 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 d'Arrêt vérifie si le processus tourne effectivement. Si c'est le cas, Arrêt utilise le détecteur de processus (pmfadm) pour l'arrêter.

L'idempotence de cette méthode d'Arrêt est garantie. Bien que le RGM ne doive pas appeler une méthode d'Arrêt deux fois sans d'abord avoir démarré le service de données avec un appel à sa méthode de Démarrage, il peut appeler une méthode d'Arrêt 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 d'Arrêt se ferme correctement même si le DNS ne tourne pas.

Arrêt de l'application

La méthode d'Arrêt fournit une approche à deux niveaux pour arrêter le 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 d'Arrêt obtient la valeur Délai_arrêt (le délai au cours duquel la méthode d'Arrêt doit avoir un retour). Arrêt 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 :

DÉLAI_ARRÊT=`scha_resource_get -O DÉLAI_ARRÊT -R $RESOURCE_NAME
\

-G $RESOURCEGROUP_NAMÈ
((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 c'est le cas, Arrêt 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, Arrêt 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 Arrêt utilise pmfadm pour arrêter le processus DNS.

# Regardez si in.named fonctionne et si c'est le cas, tuez-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 ÉCHEC_ARRÊT.

   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 d'`Arrêt` à la fermeture

Une méthode d'Arrêt 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é 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é Mode_basculement. Par conséquent, elle possède la valeur par défaut AUCUN (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 à Échec_arrêt. Une intervention de l'utilisateur est nécessaire pour forcer l'arrêt de l'application et effacer l'état Échec_arrêt.

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 de :

Sonde_dns, un programme défini par l'utilisateur employant la commande nslookup pour vérifier si la ressource DNS contrôlée par le service de données modèle fonctionne. Si le DNS ne fonctionne pas, cette méthode tente de le redémarrer localement ou, en fonction du nombre de tentatives de redémarrage, demande que le RGM déplace le service de données sur un autre noeud.
Démarrage_détecteur_dns, une méthode de rappel lançant sonde_dns. Le RGM appelle automatiquement Démarrage_détecteur_dns une fois le service de données modèle mis en ligne si la surveillance est activée.
Arrêt_détecteur_dns, une méthode de rappel arrêtant sonde_dns. Le RGM appelle automatiquement arrêt_détecteur_dns avant de mettre le service de données modèle hors ligne.
Contrôle_détecteur_dns, une méthode de rappel appelant la méthode de Validation afin de vérifier si le répertoire de configuration est disponible lorsque le programme de SONDE bascule le service de données vers un nouveau noeud.

Programme de sonde

Le programme sonde_dns met en oeuvre un processus vérifiant en permanence si la ressource DNS contrôlée par le service de données modèle fonctionne. La commande sonde_dns est lancée par la méthode de démarrage_détecteur_dns , 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 d' arrêt_détecteur_dns, 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 de SONDE 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 SONDE, reportez-vous à la rubrique Programme de SONDE.

Présentation de la Sonde

La sonde 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 Intervalle_sonde_complet ), 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 noeud.

Obtention des valeurs des propriétés

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

Intervalle_sonde_complet : pour définir le délai pendant lequel la sonde passe en mode de sommeil.
Délai_sonde : pour appliquer le délai imparti relatif à la sonde à la commande nslookup effectuant la sonde.
Ressources_réseau_utilisées : pour obtenir l'adresse IP sur laquelle tourne le DNS.
Nombre_nouvelles_tentatives et Intervalle_nouvelles_tentatives : pour déterminer le nombre de tentatives de redémarrage ainsi que la période sur laquelle elles se répartissent.
Rép_base_TR : pour obtenir le répertoire contenant le programme de SONDE ainsi que l'utilitaire gettime .

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 :

INTERVALLE_SONDE=`scha_resource_get -O INTERVALLE_SONDE_COMPLET \
-R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ

Info_délai_sonde=`scha_resource_get -O Extension -R $RESOURCE_NAME
\
-G $RESOURCEGROUP_NAME Délai_sondè
DÉLAI_SONDE=`echo $probe_timeout_info | awk '{print $2}'`

HÔTE_DNS=`scha_resource_get -O RESSOURCES_RÉSEAU_UTILISÉES -R $RESOURCE_NAME
\
-G $RESOURCEGROUP_NAMÈ

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

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

RÉP_BASE_TR=`scha_resource_get -O RÉP_BASE_TR -R $RESOURCE_NAME -G\
 $RESOURCEGROUP_NAMÈ

Remarque :

pour les propriétés définies par le système, telles que Intervalle_sonde_complet , scha_resource_get() ne retourne que la valeur. Pour les propriétés d'extension, telles que Délai_sonde, 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 :

Définit l'intervalle de sommeil de la sonde.
Utilise hatimerun pour lancer la commande nslookup afin que celle-ci transmette la valeur Délai_sonde et identifie l'hôte cible.
Définit la variable probefail sur la base de la réussite ou de l'échec du code de retour de nslookup.
Vérifie si la réponse nslookup provient du service de données modèle ou d'un autre serveur DNS si probefail a la valeur 1 (échec).

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é INTERVALLE_SONDE_COMPLET. Par conséquent, définir le sommeil de la sonde
   # à une durée de INTERVALLE_SONDE_COMPLET.
   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 noeud. 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 (Intervalle_nouvelles_tentatives) et un compteur d'échecs (Nombre_nouvelles_tentatives) 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 noeud. Elle met en oeuvre le code conditionnel suivant (voir l'affichage du code pour decide_restart_or_failover () dans la rubrique Programme de SONDE).

S'il s'agit du premier échec, redémarrez le service de données. Consignez un message d'erreur et augmentez le compteur dans la variable retries.
Si ce n'est pas le premier échec, mais si le délai a été dépassé, redémarrez le service de données. Consignez un message d'erreur et réinitialisez le compteur ainsi que le délai.
Si le délai n'est pas dépassé et si le compteur des nouvelles tentatives a été dépassé, basculez vers un autre noeud. Si le basculement échoue, consignez une erreur et quittez le programme de sonde avec un état 1 (échec).
Si ni le délai ni le compteur n'ont été dépassés, redémarrez le service de données. Consignez un message d'erreur et augmentez le compteur dans la variable retries.

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 :

L'utilitaire gettime sert à mesurer le délai entre les redémarrages. Il s'agit d'un programme C résidant dans le répertoire ( Rép_base_TR).
Les propriétés de ressource définies par le système Nombre_nouvelles_tentatives et Intervalle_nouvelles_tentatives déterminent le nombre de tentatives de redémarrage et le délai pendant lequel compter. Par défaut, elles définissent 2 tentatives sur une période de 5 minutes (300 secondes) dans le fichier RTR. Toutefois, l'administrateur du cluster peut modifier ces valeurs.
La fonction restart_service() est appelée afin de tenter de redémarrer le service de données sur le même noeud. Reportez-vous à la rubrique suivante, Redémarrage du service de données, pour obtenir de plus amples informations sur cette fonction.
La fonction API scha_control(), avec l'option GIVEOVER, met le groupe de ressources contenant le service de données modèle hors ligne, puis de nouveau en ligne, sur un autre noeud.

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 effectue les opérations suivantes :

Elle détermine si le service de données est toujours enregistré dans le gestionnaire de processus. Si c'est le cas, la fonction :
- Obtient le nom de la méthode d'Arrêt ainsi que la valeur Délai_arrêt du service de données.
- Utilise hatimerun pour lancer la méthode d' Arrêt pour le service de données, avec transmission de la valeur Délai_arrêt .
- Obtient le nom de la méthode de Démarrage ainsi que la valeur Délai_démarrage pour le service de données (si celui-ci s'arrête correctement).
- Utilise hatimerun pour lancer la méthode de Démarrage pour le service de données, avec transmission de la valeur Délai_démarrage.
Si le service de données n'est plus enregistré dans le gestionnaire de processus, cela signifie qu'il a dépassé le nombre maximum de nouvelles tentatives autorisées par le gestionnaire et que la fonction scha_control() est appelée avec l'option GIVEOVER afin de basculer le service de données vers un autre noeud.

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 d'Arrêt et la valeur de DÉLAI_ARRÊT
                # pour cette ressource.
                DÉLAI_ARRÊT=`scha_resource_get -O STOP_TIMEOUT \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                MÉTHODE_ARRÊT=`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 de DÉMARRAGE et la valeur
                # de DÉLAI_DÉMARRAGE pour cette ressource.
                DÉLAI_DÉMARRAGE=`scha_resource_get -O START_TIMEOUT \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                MÉTHODE_DÉMARRAGE=`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 noeud du serveur.
                scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \
                        -R $RESOURCE_NAME
        fi

        return 0
}

État de la sonde à la fermeture

Le programme de SONDE 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 noeud a également échoué. Il consigne le message, “Failover attempt failed” ("Échec de la tentative de basculement").

Méthode de `Démarrage_détecteur`

Le RGM appelle la méthode de Démarrage_détecteur pour lancer la méthode de sonde_dns une fois le service de données modèle en ligne.

Cette rubrique décrit les principaux éléments de la méthode de Démarrage_détecteur 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 de Démarrage_détecteur, reportez-vous à la rubrique Méthode de Démarrage_détecteur.

Présentation de `Démarrage_détecteur`

Cette méthode utilise le gestionnaire de processus (pmfadm) pour lancer 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 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_NAMÈ

# 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 
# de sonde.
pmfadm -c $RESOURCE_NAME.monitor -n -1 -t -1 \
   $RT_BASEDIR/dns_probe -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
   -T $RESOURCETYPE_NAME

Méthode d'`Arrêt_détecteur`

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

Cette rubrique décrit les principaux éléments de la méthode d'Arrêt_détecteur pour l'application modèle. Cette rubrique 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 rubriqueFonctionnalité commune à toutes les méthodes.

Pour l'affichage complet de la méthode d'Arrêt_détecteur, reportez-vous à la rubrique Méthode d'Arrêt_détecteur.

Présentation d'`Arrêt_détecteur`

Cette méthode utilise le gestionnaire de processus (pmfadm) pour vérifier si la sonde tourne et, le cas échéant, pour l'arrêter.

Arrêt du détecteur

La méthode d'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.

# Voir si le détecteur tourne et, le cas échéant, 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 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 :

veillez à utiliser le signal KILL avec pmfadm pour arrêter la sonde et pas un signal masquable tel que TERM. Dans le cas contraire, la méthode d'Arrêt_détecteur peut se bloquer indéfiniment et finit par dépasser le délai imparti. Le motif de ce problème réside dans l'appel par la méthode de SONDE 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 Arrêt_détecteur dans le cadre du processus de mise du service de données hors ligne, si Arrêt_détecteur utilise un signal masquable, il se bloque en attendant que la fonction scha_control() s'arrête et scha_control() se bloque en attendant qu' Arrêt_détecteur s'arrête.

État d'`Arrêt_détecteur` à la fermeture

La méthode d'Arrêt_détecteur consigne un message d'erreur si elle ne peut pas arrêter la méthode de SONDE. Le RGM fait passer le service de données modèle à l'état ÉCHEC_CONTRÔLE sur le noeud primaire, ce qui peut créer une panique au niveau du noeud.

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

Méthode de `Contrôle_détecteur`

Le RGM appelle la méthode Contrôle_détecteur 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 de Contrôle_détecteur pour l'application modèle. Cette rubrique 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 de Contrôle_détecteur, reportez-vous à la rubrique Méthode de Contrôle_détecteur.

La méthode de Contrôle_détecteur doit être mise en oeuvre de manière à ne pas entrer en conflit avec d'autres méthodes exécutées simultanément.

La méthode de Contrôle_détecteur appelle la méthode de Validation afin qu'elle vérifie que le répertoire de configuration DNS est disponible sur le nouveau noeud. La propriété d'extension Rép_conf pointe vers le répertoire de configuration DNS. C'est pourquoi Contrôle_détecteur obtient le chemin et le nom de la méthode de Validation ainsi que la valeur de Rép_conf. Elle transmet cette valeur à Validation, comme le montre l'affichage suivant :

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

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

# Obtenir la valeur de la propriété Rép_conf pour démarrer le
# service de données. Utiliser le nom de la ressource et le groupe entré pour
# obtenir la valeur Rép_conf définie au moment de l'ajout de la ressource.
info_config =`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.
REP_CONFIG=`echo $config_info | awk `{print $2}'`

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

Reportez-vous à la rubrique Méthode de Validation pour voir comment l'application modèle vérifie l'aptitude du noeud à héberger le 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.

Méthode de `Validation`

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.

Il n'appelle Validation 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 de ressource Statut et msg_statut.

Remarque :

la méthode de Contrôle_détecteur appelle aussi explicitement la méthode de Validation lorsque la méthode de SONDE tente de basculer le service de données sur un autre noeud.

Présentation de `Validation`

Le RGM appelle Validation 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 oeuvre une fonction parse_args() pour gérer les autres arguments.

La méthode de Validation vérifie une seule propriété, la propriété d'extension Rép_conf. 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é Rép_conf est déclarée RÉGLABLE = À_LA_CRÉATION dans le fichier RTR. C'est pourquoi la méthode de Validation n'est jamais appelée pour vérifier la propriété Rép_conf à la suite d'une mise à jour, mais uniquement à la création de la ressource du service de données.

Si Rép_conf est l'une des propriétés transmises par le RGM à Validation, la fonction parse_args() récupère et enregistre sa valeur. Validation 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 Rép_conf à partir des arguments de ligne de commande transmis par le RGM, Validation tente néanmoins de valider la propriété Rép_conf. Validation 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 Validation 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 Rép_conf, échoue.

Fonction d'analyse de la méthode de `Validation`

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

#########################################################################
# 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
                  NOM_RESSOURCE=$OPTARG
                  ;;
         G)
                  # Nom du groupe dans lequel est configurée
                  # la ressource.
                  NOM_GROUPE_RESSOURCE=$OPTARG
                  ;;
         T)
                  # Nom du type de ressource.
                  NOM_TYPE_RESSOURCE=$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 de Validation 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é Rép_conf, alors Rép_conf 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.
                  PROPRIÉTÉ=`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
                           RÉP_CONF=$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 Rép_conf 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 `Rép_conf`

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

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

parse_args “$@”

Validation vérifie alors si Validation est appelée à la suite d'une mise à jour des propriétés et si la propriété d'extension Rép_conf se trouvait sur la ligne de commande. Validation vérifie alors si la propriété Rép_conf 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
         info_config=`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 Validation 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 Rép_conf à l'aide de scha_resource_get (). Si Rép_conf a été trouvé dans la ligne de commande (CONFDIR_FOUND == 1), la valeur de RÉP_CONF provient de la fonction parse_args(), et non de scha_resource_get().

La méthode de Validation utilise alors la valeur de RÉP_CONF pour vérifier si le répertoire est accessible. Si ce n'est pas le cas, Validation 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é Rép_conf, Validation 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 Rép_conf
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, Validation consigne un message indiquant une réussite et se ferme avec un état de réussite.

# Consigner un message indiquant que la méthode de Validation 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 Validation se ferme avec succès (0) Rép_conf est créé avec la nouvelle valeur. Si Validation se ferme avec un échec (1), Rép_conf 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 de `Mise_à_jour`

Le RGM appelle la méthode de Mise_à_jour pour notifier à une ressource en cours d'exécution que ses propriétés ont changé. Le RGM appelle Mise_à_jour 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 noeuds lorsque la ressource est en ligne.

Présentation de `Mise_à_jour`

La méthode de Mise_à_jour 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 de Mise_à_jour.

La méthode de Mise_à_jour 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 de sonde mettant en oeuvre le détecteur de pannes, puis le redémarre à l'aide de pmfadm.

Arrêt du détecteur à l'aide de `Mise_à_jour`

La méthode de Mise_à_jour 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, Mise_à_jour se ferme en affichant un état d'échec et envoie un message d'erreur à l'administrateur.

if pmfadm -q $RESOURCE_NAME.monitor; then

# Tuer 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 de Mise_à_jour doit localiser le script mettant en oeuvre le programme de sonde. Le programme de sonde réside dans le répertoire de base du service de données, vers lequel pointe la propriété Rép_base_TR. Mise_à_jour récupère la valeur de Rép_base_TR et l'enregistre dans la variable RÉP_BASE_TR , de la manière suivante :

RÉP_BASE_TR=`scha_resource_get -O RÉP_BASE_TR -R $RESOURCE_NAME -G \
$RESOURCEGROUP_NAMÈ

Mise_à_jour utilise alors la valeur de RÉP_BASE_TR avec la commande pmfadm pour redémarrer le programme de sonde_dns. S'il y réussit, Mise_à_jour se ferme avec succès et envoie un message le signalant à l'administrateur. Si pmfadm ne peut pas lancer le programme de sonde, Mise_à_jour se ferme en affichant un état d'échec et consigne un message d'erreur.

État de `Mise_à_jour` à la fermeture

L'échec de la méthode de Mise_à_jour 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.

Chapitre 5 Service de données modèle

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

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

Présentation du fichier RTR

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

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

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

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

Fonctionnalité commune à toutes les méthodes

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

Déclaration des variables PMF_TAG et SYSLOG_TAG

Analyse des arguments de la fonction

Génération de messages d'erreur

Obtention des informations des propriétés

Contrôle du service de données

Méthode de Démarrage

Présentation de Démarrage

Vérification de la configuration

Démarrage de l'application

État de Démarrage à la fermeture

Méthode d'Arrêt

Présentation d'Arrêt

Arrêt de l'application

État d'Arrêt à la fermeture

Définition d'un détecteur de pannes

Programme de sonde

Présentation de la Sonde

Obtention des valeurs des propriétés

Contrôle de la fiabilité du service

Évaluation : redémarrage ou basculement

Redémarrage du service de données

État de la sonde à la fermeture

Méthode de Démarrage_détecteur

Présentation de Démarrage_détecteur

Démarrage de la sonde

Méthode d'Arrêt_détecteur

Présentation d'Arrêt_détecteur

Arrêt du détecteur

État d'Arrêt_détecteur à la fermeture

Méthode de Contrôle_détecteur

Gestion des mises à jour des propriétés

Méthode de Validation

Présentation de Validation

Fonction d'analyse de la méthode de Validation

Validation de Rép_conf

État de Validation à la fermeture

Méthode de Mise_à_jour

Présentation de Mise_à_jour

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

Redémarrage du détecteur

État de Mise_à_jour à la fermeture

Déclaration des variables `PMF_TAG` et `SYSLOG_TAG`

Méthode de `Démarrage`

Présentation de `Démarrage`

État de `Démarrage` à la fermeture

Méthode d'`Arrêt`

Présentation d'`Arrêt`

État d'`Arrêt` à la fermeture

Méthode de `Démarrage_détecteur`

Présentation de `Démarrage_détecteur`

Méthode d'`Arrêt_détecteur`

Présentation d'`Arrêt_détecteur`

État d'`Arrêt_détecteur` à la fermeture

Méthode de `Contrôle_détecteur`

Méthode de `Validation`

Présentation de `Validation`

Fonction d'analyse de la méthode de `Validation`

Validation de `Rép_conf`

État de `Validation` à la fermeture

Méthode de `Mise_à_jour`

Présentation de `Mise_à_jour`

Arrêt du détecteur à l'aide de `Mise_à_jour`

État de `Mise_à_jour` à la fermeture