Fonctionnement de la méthode Start (Guide du développeur de services de données Sun Cluster pour SE Solaris)

Guide du développeur de services de données Sun Cluster pour SE Solaris

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().

Remarque –

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.

Remarque –

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.