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

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.