test

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

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.