Contrôle du service de données

Un service de données doit fournir une méthode de Démarrage ou de Démarrage_avant_réseau pour activer le démon d'application du cluster, ainsi qu'une méthode d'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 œuvre des méthodes Démarrage et Arrêt. Reportez-vous à la rubrique Choix des méthodes Start et Stop à utiliser pour savoir dans quels cas il peut être préférable d'utiliser Prenet_start et Postnet_stop .

Fonctionnement de la méthode Start

Le RGM exécute la méthode de Démarrage 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 DNS in.named sur ce nœud.

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

Fonction de la méthode Start

Avant de tenter de démarrer le DNS, la méthode Start du service de données modèle s'assure que le répertoire de configuration et le fichier de configuration (named.conf) sont accessibles et disponibles. Les informations du fichier named.conf sont essentielles pour un bon fonctionnement du DNS.

Cette méthode de rappel utilise la fonction PMF (pmfadm) pour démarrer le démon DNS (in.named(). Si le DNS s'arrête brutalement ou ne parvient pas à démarrer, la fonction PMF tente de démarrer le démon DNS un certain nombre de fois (le nombre de tentatives étant paramétrable) pendant un intervalle spécifié. 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. La méthode Start effectue donc différents contrôles de validité pour vérifier que le répertoire et le fichier sont accessibles avant de tenter de démarrer 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. Cependant, l'administrateur du cluster spécifie l'emplacement réel lorsqu'il configure le 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 uniquement la valeur et place celle-ci dans une variable de shell, CONFIG_DIR .

# trouver la valeur de Confdir définie par l'administrateur du cluster lors
# de l'ajout de la ressource.
config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Confdir`

# Pour les propriétés d'extension, scha_resource_get renvoie le "type" 
# et la "valeur". Récupérer uniquement la valeur de la propriété d'extension
CONFIG_DIR=`echo $config_info | awk '{print $2}'`

La méthode Start utilise la valeur de CONFIG_DIR pour vérifier que le répertoire est accessible. S'il ne l'est pas, Start consigne un message d'erreur et se termine avec un état d'erreur. 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 le fichier n'est pas présent, Start consigne un message d'erreur et se termine avec un état d'erreur.

# Se placer dans le répertoire $CONFIG_DIR au cas où il y aurait
# des chemins 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 fait appel aux services du gestionnaire de processus (pmfadm) pour démarrer l'application. La commande pmfadm vous permet de définir le nombre de tentatives de redémarrage de l'application pendant un intervalle spécifié. Le fichier RTR contient les propriétés suivantes : Retry_count spécifie le nombre de tentatives de redémarrage d'une application, et Retry_interval l'intervalle pendant lequel les tentatives doivent être effectuées.

La méthode Start récupère les valeurs de Retry_count et de Retry_interval en utilisant la fonction scha_resource_get (), puis stocke leurs valeurs dans des variables de shell. La méthode Start passe ces valeurs à pmfadm en utilisant les options - n et -t.

# Récupère la valeur du nombre de tentatives dans le fichier RTR.
RETRY_CNT=`scha_resource_get -O Retry_count -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME`
# Récupère la valeur de l'intervalle de tentative dans le fichier RTR. Cette valeur est en secondes
# et doit être convertie en minutes pour être passée à pmfadm. Remarquez que la 
# conversion est arrondie à la valeur supérieure ; par ex., 50 secondes est arrondi à 1 minute.
((RETRY_INTRVAL=`scha_resource_get -O Retry_interval -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME` / 60))

# Démarrer le démon in.named sous le controle de PMF. Il peut s'arrêter et redémarrer
# jusqu'à $RETRY_COUNT fois dans l'intervalle $RETRY_INTERVAL. S'il s'interrompt
# plus souvent, PMF cessera d'essayer de le redémarrer.
# Si un processus est déjà enregistré sous la marque 
# <$PMF_TAG>, PMF envoie 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

# Consigne 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 terminer avec un code de succès tant que l'application correspondante n'est pas effectivement en cours d'exécution et disponible, particulièrement si d'autres services de données en dépendent. L'un des moyens à votre disposition pour vérifier le succès de la méthode consiste à sonder l'application afin de vous assurer qu'elle fonctionne avant de quitter la méthode Start. Pour une application complexe, telle qu'une base de données, veillez à définir la propriété Start_timeout dans le fichier RTR sur une valeur suffisamment élevée pour permettre à l'application de s'initialiser et le cas échéant de récupérer après une panne.

comme la ressource d'application (DNS) du service de données modèle démarre rapidement, la méthode de démarrage du service de données ne l'interroge pas pour vérifier son fonctionnement avant de se terminer avec succès.

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 qui a donc la valeur par défaut NONE (sauf si l'administrateur du cluster remplace la valeur par défaut par une autre valeur). Dans ce cas, le RGM ne prend pas de mesure autre que la définition de l'état du service de données. L'administrateur du cluster doit lancer un redémarrage sur le même nœud ou un basculement sur un autre nœud.

Fonctionnement de la méthode Stop

Le gestionnaire RGM exécute la méthode d'Arrêt 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 d'Arrêt 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 la liste complète du code de la méthode Stop, reportez-vous à la rubrique Listing de code de la méthode Stop.

Fonction 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 façon d'effectuer un arrêt correct est d'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 solution pour placer le service de données dans cet état est d'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 ce signal ne parvient pas à arrêter le service de données, elle envoie un signal SIGKILL .

Avant de tenter d'arrêter le DNS, cette méthode d'Arrêt vérifie si le processus tourne effectivement. Si le processus est en cours d'exécution, Stop utilise la fonction PMF (pmfadm) pour l'arrêter.

L'idempotence de cette méthode Stop est garantie. Bien que le gestionnaire RGM ne doive pas appeler deux fois une méthode Stop sans démarrer au préalable le service de données par un appel à sa méthode Start, le RGM pourrait appeler une méthode Stop sur une ressource alors que celle-ci n'a jamais été démarrée ou s'est déjà arrêtée d'elle-même. 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 Stop fournit une approche à deux niveaux d'arrêt du service de données : une approche ordonnée ou en douceur utilisant un signal SIGTERM par l'intermédiaire de pmfadm et une approche brutale utilisant un signal SIGKILL. La méthode Stop obtient la valeur Stop_timeout (le délai avant lequel la méthode Stop doit se terminer). Arrêt alloue alors 80 % de ce temps à un arrêt en douceur et 15 % à un arrêt abrupt (5 % sont réservés), de la manière indiquée dans l'exemple de code suivant.

STOP_TIMEOUT='scha_resource_get -O STOP_TIMEOUT -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME'
((SMOOTH_TIMEOUT=$STOP_TIMEOUT * 80/100))
((HARD_TIMEOUT=$STOP_TIMEOUT * 15/100))

La méthode d'Arrêt utilise pmfadm -q pour vérifier si le démon DNS fonctionne. Si le démon DNS est en cours d'exécution, Stop utilise d'abord pmfadm -s pour envoyer un signal TERM afin de terminer le processus DNS. Si ce signal ne parvient pas à terminer le processus après 80 % de la valeur de délai d'attente, Stop envoie un signal SIGKILL. Si ce signal ne parvient pas non plus à terminer le processus après 15 % de la valeur de délai d'attente, la méthode consigne un message d'erreur et se termine avec un état d'erreur.

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.

# Voir si in.named est en cours d'exécution, et si oui, le tuer. 
if pmfadm -q $PMF_TAG; then
   # Envoyer un signal SIGTERM au service de données et attendre 80% 
   # de la valeur de délai d'attente totale.
   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”
      
      # Comme le service de données ne s'est pas arrêté avec un signal SIGTERM, utiliser 
      # maintenant SIGKILL et attendre encore 15% de la valeur de délai d'attente totale.
      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 UNSUCCESSFUL”
         exit 1
      fi
fi
else 
   # Le service de données ne fonctionne pas pour l'instant. Consigner un message et 
   # quitter avec un code de succès.
   logger -p ${SYSLOG_FACILITY}.err \
           -t [$SYSLOG_TAG] \
           “HA-DNS is not started”

   # Même si HA-DNS ne fonctionne pas, quitter avec un code de succès afin d'éviter
  # de placer la ressource du service de données à l'état STOP_FAILED.
   exit 0
fi

# L'arrêt du DNS a réussi. Consigner un message et quitter avec un code de 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 Stop ne doit pas se terminer avec un code de succès tant que l'application correspondante n'est pas effectivement arrêtée, particulièrement 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é Failover_mode qui a donc la valeur par défaut NONE (sauf si l'administrateur du cluster remplace la valeur par défaut par une autre valeur). Dans ce cas, le gestionnaire RGM se contente de définir l'état du service de données sur Stop_failed. L'administrateur du cluster doit forcer l'arrêt de l'application et effacer l'état Stop_failed.