test

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

Définition d'un détecteur de pannes

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

Programme Probe

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

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

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

Présentation de Probe

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

Obtention des valeurs des propriétés

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

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

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

probe_timeout_info=`scha_resource_get -O Extension -R $RESOURCE_NAME
\
-G $RESOURCEGROUP_NAME Probe_timeout
PROBE_TIMEOUT=`echo $probe_timeout_info | awk ’{print $2}’`
HÔTE_DNS=`scha_resource_get -O NETWORK_RESOURCES_USED -R $RESOURCE_NAME
\
-G $RESOURCEGROUP_NAMÈ
RETRY_COUNT=`scha_resource_get -O RETRY_COUNT
-R $RESOURCE_NAME
-G\
$RESOURCEGROUP_NAMÈ
RETRY_INTERVAL=`scha_resource_get -O RETRY_INTERVAL
-R $RESOURCE_NAME
-G\
$RESOURCEGROUP_NAMÈ
RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G\
$RESOURCEGROUP_NAMÈ

Remarque –

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

Contrôle de la fiabilité du service

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


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

La boucle while elle-même :

Voici le code de la boucle while.


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

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

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

   # Vérifier que la réponse à nslookup provient du serveur HA-DNS
# et pas d’un autre nom de serveur mentionné dans le fichier
# /etc/resolv.conf.
   if [ $probefail -eq 0 ]; then
# Obtenir le nom du serveur ayant répondu à la requête de nslookup.
   SERVER=` awk ' $1=="Server:" { print $2 }' \
   $DNSPROBEFILE | awk -F. ' { print $1 } ' `
   if [ -z "$SERVER" ]; then
      probefail=1
      else
         if [ $SERVER != $DNS_HOST ]; then
            probefail=1
         fi
   fi
fi

Évaluation : redémarrage ou basculement

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


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

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

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

Redémarrage du service de données

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


function restart_service
{

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

                # Obtenir le nom de la méthode Arrêt et la valeur de STOP_TIMEOUT
# pour cette ressource.
                STOP_TIMEOUT=`scha_resource_get -O STOP_TIMEOUT \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                STOP_METHOD=`scha_resource_get -O STOP \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                hatimerun -t $STOP_TIMEOUT $RT_BASEDIR/$STOP_METHOD \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
                        -T $RESOURCETYPE_NAME

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

                # Obtenir le nom de la méthode START et la valeur
# de START_TIMEOUT pour cette ressource.
START_TIMEOUT=`scha_resource_get -O START_TIMEOUT \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                START_METHOD=`scha_resource_get -O START \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ
                hatimerun -t $START_TIMEOUT $RT_BASEDIR/$START_METHOD \
                        -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \
                        -T $RESOURCETYPE_NAME

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


        else
                # L’absence de la BALISE du service de données
# signifie que celui-ci a déjà dépassé le nombre
# maximum de nouvelles tentatives autorisé par le gestionnaire
# des processus. Ne pas essayer de le redémarrer
# mais tenter de le basculer
# sur un autre nœud du serveur.
                scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \
                        -R $RESOURCE_NAME
        fi

        return 0
}

État de Probe à la fermeture

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

Méthode Monitor_start

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

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

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

Présentation de la méthode Monitor_start

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

Démarrage de Probe

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


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

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

Méthode Monitor_stop

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

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

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

Présentation de la méthode Monitor_stop

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

Arrêt du détecteur

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


# Voir si le détecteur tourne et, le cas échéant, l'arrêter. 
if pmfadm -q $PMF_TAG; then 
   pmfadm -s $PMF_TAG KILL
   if [ $? -ne 0 ]; then 
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Could not stop monitor for resource " \
            $RESOURCE_NAME
           exit 1
   else
         # Arrêt du détecteur fructueux. Consigner un message.
         logger -p ${SYSLOG_FACILITY}.err \
            -t [$SYSLOG_TAG] \
            "${ARGV0} Monitor for resource " $RESOURCE_NAME \
            " successfully stopped"
   fi
fi
exit 0

Attention – Attention –

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

État de Monitor_stop à la fermeture

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

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

Méthode Monitor_check

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

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

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

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

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


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

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

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

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

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

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