L'application modèle met en oeuvre un détecteur de pannes de base afin de surveiller la fiabilité de la ressource DNS (in.named). Le détecteur de pannes se compose des éléments suivants :
dns_probe, un programme défini par l'utilisateur qui utilise nslookup pour vérifier que la ressource DNS contrôlée par le service de données modèle fonctionne. Si le DNS ne fonctionne pas, cette méthode tente de le redémarrer localement ou, en fonction du nombre de tentatives de redémarrage, demande que le RGM déplace le service de données sur un autre noeud.
dns_monitor_start, une méthode de rappel que démarre dns_probe. Une fois le service de données modèle en ligne et si la surveillance est activée, le gestionnaire RGM appelle automatiquement dns_monitor_start.
dns_monitor_stop, une méthode de rappel qui arrête dns_probe. Le gestionnaire RGM appelle automatiquement dns_monitor_stop avant de placer le service de données modèle hors ligne.
dns_monitor_check, une méthode de rappel qui appelle la méthode Validate de manière à vérifier que le répertoire de configuration est disponible lorsque le programme PROBE bascule le service de données sur un autre noeud.
Le programme dns_probe met en oeuvre un processus qui vérifie en permanence que la ressource DNS contrôlée par le service de données modèle fonctionne. Le programme dns_probe est démarré par la méthode dns_monitor_start, elle-même automatiquement exécutée par le RGM lorsque le service de données modèle a été mis en ligne. Le service de données est arrêté par la méthode dns_monitor_stop, que le RGM exécute avant de mettre le service de données modèle hors ligne.
Cette rubrique décrit les principaux éléments de la méthode SONDE pour l'application modèle. Elle 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 PROBE, reportez-vous à la rubrique Listing de code du programme PROBE.
Probe tourne en boucle infinie. Il utilise nslookup pour vérifier que la ressource DNS correcte fonctionne. Si le DNS fonctionne, la sonde passe en mode sommeil pendant un intervalle prédéfini (via la propriété système Thorough_probe_interval), puis vérifie à nouveau. Dans le cas contraire, ce programme tente de le redémarrer localement ou, en fonction du nombre de tentatives de démarrage, demande au RGM de déplacer le service de données sur un autre noeud.
Ce programme requiert les valeurs des propriétés suivantes :
Thorough_probe_interval : pour définir le délai pendant lequel la sonde passe en mode de sommeil.
Probe_timeout : pour mettre en oeuvre la valeur de délai d'attente de la sonde au niveau de la commande nslookup, qui effectue le test.
Network_resources_used : pour obtenir l'adresse IP sur laquelle tourne le DNS.
Retry_count et Retry_interval : pour déterminer le nombre de tentatives de redémarrage et la période pendant laquelle les effectuer.
RT_basedir : pour obtenir le répertoire contenant le programme de SONDE ainsi que l’utilitaire gettime.
La fonction scha_resource_get() obtient les valeurs de ces propriétés et les stocke dans des variables de shell, comme cela est indiqué ci-après :
PROBE_INTERVAL=`scha_resource_get -O Thorough_probe_interval \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME` PROBE_TIMEOUT_INFO=`scha_resource_get -O Extension -R $RESOURCE_NAME \ -G $RESOURCEGROUP_NAME Probe_timeout` Probe_timeout=`echo $probe_timeout_info | awk '{print $2}'` DNS_HOST=`scha_resource_get -O Network_resources_used -R $RESOURCE_NAME \ -G $RESOURCEGROUP_NAME` RETRY_COUNT=`scha_resource_get -O Retry_count -R $RESOURCE_NAME -G \ $RESOURCEGROUP_NAME` RETRY_INTERVAL=`scha_resource_get -O Retry_interval -R $RESOURCE_NAME -G \ $RESOURCEGROUP_NAME` RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME -G \ $RESOURCEGROUP_NAME`
pour les propriétés définies au niveau système, comme par exemple Thorough_probe_interval , la fonction scha_resource_get() renvoie la valeur uniquement. Pour les propriétés d'extension, comme par exemple Probe_timeout, la fonction scha_resource_get() retourne le type et la valeur. Utilisez la commande awk pour obtenir la valeur seule.
La sonde elle-même est une boucle while infinie de commandes nslookup. Un fichier temporaire est défini avant la boucle while pour recevoir les réponses de nslookup. Les variables probefail et retries sont initialisées à 0.
# Configuration d'un fichier temporaire pour les réponses de nslookup. DNSPROBEFILE=/tmp/.$RESOURCE_NAME.probe probefail=0 retries=0
La boucle while assure les tâches suivantes :
Définit l'intervalle de sommeil de la sonde.
Utilise hatimerun pour démarrer nslookup, passe la valeur Probe_timeout, et identifie l'hôte cible.
Définit la variable probefail sur la base de la réussite ou de l'échec du code de retour de nslookup.
Vérifie si la réponse de nslookup provient du service de données modèle ou d'un autre serveur DNS si probefail a la valeur 1 (échec).
Voici le code de la boucle while.
while : do # L'intervalle d'exécution de la sonde est spécifié dans la propriété # THOROUGH_PROBE_INTERVAL. Par conséquent, configurer la sonde en mode sommeil # pour une durée de THOROUGH_PROBE_INTERVAL. sleep $PROBE_INTERVAL # Exécute une commande nslookup de l'adresse IP servie par le DNS. hatimerun -t $PROBE_TIMEOUT /usr/sbin/nslookup $DNS_HOST $DNS_HOST \ > $DNSPROBEFILE 2>&1 retcode=$? if [ $retcode -ne 0 ]; then probefail=1 fi # S'assurer que la réponse à nslookup vienne du serveur HA-DNS # et non d'un autre serveur de noms mentionné dans le fichier # /etc/resolv.conf. if [ $probefail -eq 0 ]; then # Obtenir le nom du serveur qui a répondu à l'interrogation nslookup. SERVER=` awk ' $1=="Server:" { print $2 }' \ $DNSPROBEFILE | awk -F. ' { print $1 } ' ` if [ -z "$SERVER" ]; then probefail=1 else if [ $SERVER != $DNS_HOST ]; then probefail=1 fi fi fi
Si la variable probefail est différente de 0 (succès), le délai de la commande nslookup a expiré ou la réponse est venue d'un serveur autre que le serveur DNS du service modèle. Dans un cas comme dans l'autre, le serveur DNS ne fonctionne pas de la manière attendue et le détecteur appelle la fonction decide_restart_or_failover() afin de déterminer s'il convient ou non de redémarrer le service de données localement ou de demander que le RGM déplace le service de données sur un autre noeud. Si la variable probefail est 0, un message est généré indiquant que la sonde a réussi.
if [ $probefail -ne 0 ]; then decide_restart_or_failover else logger -p ${SYSLOG_FACILITY}.err\ -t [$SYSLOG_TAG]\ "${ARGV0} Probe for resource HA-DNS successful" fi
La fonction decide_restart_or_failover() utilise une fenêtre temporelle (Retry_interval) et un compteur d'échecs (Retry_count) afin de déterminer s'il convient ou non de redémarrer le DNS localement ou de demander que le RGM déplace le service de données sur un autre noeud. Cette fonction met en oeuvre la logique conditionnelle suivante. La liste du code de decide_restart_or_failover() dans la rubrique Listing de code du programme PROBE contient le code utilisé.
S'il s'agit du premier échec, redémarrez le service de données. Consignez un message d'erreur et augmentez le compteur dans la variable retries.
Si ce n'est pas le premier échec, mais si le délai a été dépassé, redémarrez le service de données. Consignez un message d'erreur et réinitialisez le compteur ainsi que le délai.
Si le délai n'est pas écoulé mais que le compteur de tentatives a dépassé la valeur autorisée, basculez le service sur un autre noeud. Si le basculement échoue, consignez une erreur et quittez le programme de sonde avec l'état 1 (échec).
Si ni le délai ni le compteur n'ont été dépassés, redémarrez le service de données. Consignez un message d'erreur et augmentez le compteur dans la variable retries.
Si le nombre de redémarrages atteint la limite pendant le délai, la fonction demande au RGM de déplacer le service de données vers un autre noeud. Si le nombre de redémarrages se situe sous la limite ou si l'intervalle a été dépassé, entraînant une réinitialisation du compteur, la fonction tente de redémarrer le DNS sur le même noeud. Remarquez les points suivants concernant cette fonction :
L'utilitaire gettime sert à mesurer le délai entre les redémarrages. Il s'agit d'un programme C situé dans le répertoire (RT_basedir ).
Les propriétés de ressource définies au niveau système Retry_count et Retry_interval déterminent le nombre de tentatives de redémarrage ainsi que l'intervalle pendant lequel le comptage est effectué. Ces propriétés sont définies par défaut à deux tentatives au cours d'une période de 5 minutes (300 secondes) dans le fichier RTR, bien que l'administrateur du cluster puisse modifier ces valeurs.
La fonction restart_service() est appelée afin de tenter de redémarrer le service de données sur le même noeud. Reportez-vous à la rubrique suivante, Redémarrage du service de données, pour obtenir des informations sur cette fonction.
La fonction API scha_control(), avec l'option GIVEOVER, place le groupe de ressources contenant le service de données modèle hors ligne, puis de nouveau en ligne sur un autre noeud.
La fonction restart_service() est appelée par decide_restart_or_failover () pour tenter de redémarrer le service de données sur le même noeud. Cette fonction exécute la logique suivante :
Détermine si le service de données est toujours enregistré sous le PMF. Si le service est toujours enregistré, la fonction exécute les actions suivantes :
Obtient le nom de la méthode Stop et la valeur Stop_timeout pour le service de données.
Utilise hatimerun pour démarrer la méthode Stop du service de données, en lui passant la valeur Stop_timeout.
Si le service de données est correctement arrêté, obtient le nom de la méthode Start et la valeur Start_timeout pour le service de données.
Utilise hatimerun pour démarrer la méthode Start du service de données, en lui passant la valeur Start_timeout.
Si le service de données n'est plus enregistré sous le PMF, il est très probable qu'il a dépassé le nombre maximum de tentatives autorisées sous le PMF. La fonction scha_control() est appelée avec l'option GIVEOVER pour basculer le service de données sur un autre noeud.
function restart_service { # Pour redémarrer le service de données, vérifiez d'abord que # le service de données lui-même est toujours enregistré sous le PMF. pmfadm -q $PMF_TAG if [[ $? -eq 0 ]]; then # Comme le TAG pour le service de données est toujours enregistré # sous le PMF, arrêtez d'abord le service de données, puis redémarrez-le. # Récupérez le nom de la méthode d'arrêt et la valeur STOP_TIMEOUT # pour cette ressource. STOP_TIMEOUT=`scha_resource_get -O STOP_TIMEOUT \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ STOP_METHOD=`scha_resource_get -O STOP \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ hatimerun -t $STOP_TIMEOUT $RT_BASEDIR/$STOP_METHOD \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME if [[ $? -ne 0 ]]; then logger-p ${SYSLOG_FACILITY}.err -t [$SYSLOG_TAG] \ “${ARGV0} Stop method failed.” return 1 fi # Récupérez le nom de la méthode de démarrage et la valeur START_TIMEOUT # pour cette ressource. START_TIMEOUT=`scha_resource_get -O START_TIMEOUT \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ START_METHOD=`scha_resource_get -O START \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ hatimerun -t $START_TIMEOUT $RT_BASEDIR/$START_METHOD \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME if [[ $? -ne 0 ]]; then logger-p ${SYSLOG_FACILITY}.err -t [$SYSLOG_TAG] \ “${ARGV0} Start method failed.” return 1 fi else # L'absence du TAG pour le service de données # implique le service de données a déjà dépassé # le nombre maximum de tentatives autorisées sous le PMF. # Par conséquent, ne tentez pas de redémarrer le # service de données, mais essayez de le basculer # sur un autre noeud dans le cluster. scha_control -O GIVEOVER -G $RESOURCEGROUP_NAME \ -R $RESOURCE_NAME fi return 0 }
Le programme PROBE du service de données modèle se termine avec un code d'échec si toutes les tentatives de redémarrage local échouent et que la tentative de basculement sur un autre noeud échoue également. Ce programme consigne le message Failover attempt failed.
Le RGM appelle la méthode de Démarrage_détecteur pour démarrer la méthode de dns_probe une fois le service de données modèle en ligne.
Cette rubrique décrit les principaux éléments de la méthode Monitor_start 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 obtenir une liste complète du code de la méthode Monitor_start, reportez-vous à la rubrique Listing de code de la méthode Monitor_start.
Cette méthode utilise le PMF (pmfadm) pour démarrer la sonde.
La méthode Démarrage_détecteur obtient la valeur de la propriété Rép_base_TR pour construire le nom entier du chemin d’accès du programme de SONDE. Cette méthode démarre la sonde en utilisant l'option "essayer indéfiniment" de pmfadm (-n -1, -t -1), ce qui signifie que si le démarrage de la sonde échoue, le PMF essaiera de la démarrer un nombre infini de fois sans limites de temps.
# Trouver où réside le programme de sonde en obtenant la valeur # de la propriété RT_basedir de la ressource. RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME -G \ $RESOURCEGROUP_NAME` # Démarre la sonde pour le service de données sous le PMF. Utilise l'option # "essayer indéfiniment" pour démarrer la sonde. Passe le nom de la ressource, # son type et son groupe au programme de sonde. pmfadm -c $RESOURCE_NAME.monitor -n -1 -t -1 \ $RT_BASEDIR/dns_probe -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME
Le RGM appelle la méthode d'Arrêt_détecteur afin d'arrêter l'exécution de dns_probe lorsque le service de données modèle est mis hors ligne.
Cette rubrique décrit les principaux éléments de la méthode Monitor_stop 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 obtenir une liste complète du code de la méthode Monitor_stop, reportez-vous à la rubrique Listing de code de la méthode Monitor_stop.
Cette méthode utilise le PMF (pmfadm) pour vérifier si la sonde fonctionne et, dans ce cas, l'arrête.
La méthode Arrêt_détecteur utilise pmfadm -q pour déterminer si la sonde fonctionne et, le cas échéant, pmfadm -s pour l'arrêter. Si la sonde est déjà arrêtée, la méthode se ferme correctement, ce qui garantit l'idempotence de la méthode.
Veillez à utiliser le signal KILL avec pmfadm pour arrêter la sonde et non un signal susceptible d'être masqué, comme par exemple TERM. Sinon, la méthode Monitor_stop peut se bloquer indéfiniment et son délai d'attente expirer. En effet, la méthode PROBE appelle scha_control() lorsqu'il est nécessaire de redémarrer ou de basculer le service de données. Lorsque scha_control() appelle Monitor_stop pendant le processus de mise hors ligne du service de données, si Monitor_stop utilise un signal qui peut être masqué, Monitor_stop se bloque en attendant la fin de scha_control(), tandis que scha_control() se bloque en attendant la fin de Monitor_stop.
# Voir si le détecteur fonctionne et si oui, le tuer. if pmfadm -q $PMF_TAG; then pmfadm -s $PMF_TAG KILL if [ $? -ne 0 ]; then logger -p ${SYSLOG_FACILITY}.err \ -t [$SYSLOG_TAG] \ "${ARGV0} Could not stop monitor for resource " \ $RESOURCE_NAME exit 1 else # arrêt réussi du détecteur. Consigner un message. logger -p ${SYSLOG_FACILITY}.err \ -t [$SYSLOG_TAG] \ "${ARGV0} Monitor for resource " $RESOURCE_NAME \ " successfully stopped" fi fi exit 0
La méthode Monitor_stop consigne un message d'erreur si elle ne peut pas arrêter la méthode PROBE. Le RGM place le service de données modèle en mode MONITOR_FAILED sur le noeud primaire, ce qui peut entraîner une erreur grave du noeud.
Arrêt_détecteur ne doit pas se fermer avant l'arrêt de la sonde.
Le RGM appelle la méthode Monitor_check lorsque la méthode de SONDE tente de basculer le groupe de ressources contenant le service de données vers un autre noeud.
Cette rubrique décrit les principaux éléments de la méthode Monitor_check 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 obtenir une liste complète du code de la méthode Monitor_check, reportez-vous à la rubrique Listing de code de la méthode Monitor_check.
La méthode Monitor_check doit être mise en oeuvre de manière à ne pas entraîner de conflits avec d'autres méthodes qui sont exécutées simultanément.
La méthode Monitor_check appelle la méthode Validate pour vérifier que le répertoire de configuration du DNS est disponible sur le nouveau noeud. La propriété d'extension Confdir pointe vers le répertoire de configuration du DNS. Par conséquent, Monitor_check obtient le chemin d'accès et le nom pour la méthode Validate, ainsi que la valeur de Confdir. Elle transmet cette valeur à Validation , comme le montre l'affichage suivant :
# Obtenez le chemin d'accès complet pour la méthode # Validate à partir de la propriété RT_basedir du type de ressource. RT_BASEDIR=`scha_resource_get -O RT_basedir -R $RESOURCE_NAME \ -G $RESOURCEGROUP_NAMÈ # Obtenez le nom de la méthode Validate pour cette ressource. VALIDATE_METHOD=`scha_resource_get -O Validate \ -R $RESOURCE_NAME -G $RESOURCEGROUP_NAMÈ # Obtenez la valeur de la propriété Confdir afin de démarrer le service # de données. Utilisez le nom de ressource et le groupe de ressource # entrés pour obtenir la valeur de Confdir définie lors de l'ajout de la # ressource. config_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \ -G $RESOURCEGROUP_NAME Confdir` # scha_resource_get retourne le type et la valeur pour les propriétés # d'extension. Utilisez awk pour obtenir uniquement la valeur de la # propriété d'extension. CONFIG_DIR=`echo $config_info | awk `{print $2}'` # Appelez la méthode validate afin que le service de données puisse # être correctement basculé sur le nouveau noeud. $RT_BASEDIR/$VALIDATE_METHOD -R $RESOURCE_NAME -G $RESOURCEGROUP_NAME \ -T $RESOURCETYPE_NAME -x Confdir=$CONFIG_DIR
Reportez-vous à la rubrique Fonctionnement de la méthode Validate pour comprendre comment l'application modèle vérifie si un noeud peut convenir pour l'hébergement du service de données.