Contrôle du service de données

Un service de données doit fournir une méthode Démarrage ou de Démarrage_avant_réseau pour activer le démon d'application du cluster, ainsi qu'une méthode 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 Démarrage et d'Arrêt. Reportez-vous à la rubrique Choix des méthodes Démarrage et 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 Démarrage

Le RGM appelle la méthode 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 Démarrage active le démon in.named sur ce noeud.

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

Présentation de la méthode Démarrage

Avant de tenter de lancer le DNS, la méthode 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 de 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 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 Démarrage récupère l'emplacement du répertoire de configuration à l'aide de la fonction scha_resource_get ().

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 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 de 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 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_NAME`
# 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 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 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.

é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 Arrêt

La méthode 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 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 obtenir une liste complète de la méthode Arrêt, reportez-vous à la rubrique Méthode Arrêt.

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

Arrêt de l'application

La méthode 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 Arrêt obtient la valeur Délai_arrêt (le délai au cours duquel la méthode 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 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, arrêtez-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 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.