Contrôle du service de données

Un service de données doit fournir une méthode Start ou Prenet_start pour activer le démon d'application du cluster, ainsi qu'une méthode Stop ou Postnet_stop pour arrêter le démon d'application du cluster. Le service de données modèle met en œuvre des méthodes Start et Stop. Reportez-vous à la rubrique Choix des méthodes Start et Stop à utiliser pour de plus amples informations sur les usages alternatifs de Prenet_start et de Postnet_stop.

Méthode Start

Le RGM appelle la méthode Start sur un nœud de cluster lorsque le groupe de ressources contenant la ressource du service de données est mis en ligne sur ce nœud ou lorsque le groupe de ressources est déjà en ligne et la ressource activée. Dans l’application modèle, la méthode Start active le démon in.named sur ce nœud.

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

Présentation de Start

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

Confdir é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, CONFIG_DIR.

# trouver la valeur de Confdir 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.
CONFIG_DIR=`echo $config_info | awk ’{print $2}'`

La méthode Start utilise alors la valeur de CONFIG_DIR pour vérifier si le répertoire est accessible. Si ce n'est pas le cas, Start consigne un message d'erreur et se ferme en affichant un état d'échec. Reportez-vous à la rubrique État de Start à 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, Start 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, Retry_count, indiquant le nombre de tentatives de redémarrage d'une application, et Retry_interval, indiquant le délai de ces tentatives.

La méthode Start récupère les valeurs de Retry_count et de Retry_interval à 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.
((RETRY_INTERVAL=`scha_resource_get -O Retry_interval -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 Start à la fermeture

Une méthode Start 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 Start. Pour une application complexe telle qu'une base de données, dans le fichier RTR, veillez à définir pour la propriété Start_timeout 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é Failover_mode, qui détermine la réaction à adopter. Le service de données modèle ne définit pas explicitement la propriété Failover_mode. Par conséquent, cette propriété a la valeur par défaut NONE (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 nœud ou le basculement vers un autre nœud.

Méthode Stop

La méthode Stop est appelée sur un nœud du cluster lorsque le groupe de ressources contenant la ressource HA-DNS passe hors ligne sur ce nœud 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 nœud.

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

Présentation de la méthode Stop

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 Stop_failed. La meilleure manière pour y arriver consiste à envoyer un signal SIGKILL par l’intermédiaire de pmfadm.

La méthode Stop 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 Stop vérifie si le processus tourne effectivement. S'il est actif, la méthode Stop utilise la fonction PMF (pmfadm) pour l'arrêter.

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

Arrêt de l'application

La méthode Stop fournit une approche à deux niveaux d'arrêt du 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 Stop obtient la valeur Stop_timeout (le délai au cours duquel la méthode Stop doit avoir un retour). Stop 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.

STOP_TIMEOUT``scha_resource_get -O STOP_TIMEOUT -R $RESOURCE_NAME

-G $RESOURCEGROUP_NAMÈ
((SMOOTH_TIMEOUT=$STOP_TIMEOUT * 80/100))

((HARD_TIMEOUT=$STOP_TIMEOUT * 15/100))

La méthode Stop utilise pmfadm -q pour vérifier si le démon DNS fonctionne. Si c'est le cas, Stop 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, Stop 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 Stop 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 STOP_FAILED.

   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 de Stop à la fermeture

Une méthode Stop 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é Stop_timeout 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é Failover_mode, qui détermine la réaction à adopter. Le service de données modèle ne définit pas explicitement la propriété Failover_mode. Par conséquent, elle possède la valeur par défaut NONE (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 à Stop_failed. Une intervention de l’utilisateur est nécessaire pour forcer l’arrêt de l’application et effacer l’état Stop_failed.