test

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

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.