Méthode de Démarrage

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

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

Présentation de Démarrage

Avant de tenter de lancer le DNS, la méthode de 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 des 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 de 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 de 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 de 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 des 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 de 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_NAMÈ
# 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 de 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 de 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.