Guide des développeurs pour les services de données Sun Cluster pour SE Solaris

Fonctionnalité commune à toutes les méthodes

Cette rubrique décrit la fonctionnalité suivante, utilisée dans toutes les méthodes de rappel du service de données modèle :

Identification de l'interpréteur de commandes et exportation du chemin

La première ligne d'un script Shell doit identifier l'interpréteur de commandes. Chacun des scripts de méthode du service de données modèle identifie l'interpréteur de commandes de la manière suivante :

#!/bin/ksh

Tous les scripts de méthode de l’application modèle exportent le chemin vers les binaires et les bibliothèques de Sun Cluster au lieu de se fier aux paramètres PATH de l’utilisateur.

#######################################################################
# MAIN
#######################################################################

export PATH=/bin:/usr/bin:/usr/cluster/bin:/usr/sbin:/usr/proc/bin:$PATH

Déclaration des variables `PMF_TAG` et `SYSLOG_TAG`

Tous les scripts de méthode (à l’exception de Validate) utilisent pmfadm pour lancer (ou arrêter) le service de données ou le détecteur, en transmettant le nom de la ressource. Chaque script définit une variable PMF_TAG pouvant être transmise à pmfadm pour identifier le service de données ou le détecteur.

De la même manière, chaque script de méthode a recours à la commande logger pour consigner des messages dans le journal système. Chaque script définit une variable SYSLOG_TAG pouvant être transmise à logger avec l'option -t pour identifier le type de ressource, le groupe de ressources ainsi que le nom de la ressource pour laquelle est consigné le message.

Toutes les méthodes définissent SYSLOG_TAG de la même manière, comme l'indique l'exemple suivant. Les méthodes dns_probe, dns_svc_start, dns_svc_stop et dns_monitor_check définissent PMF_TAG comme suit (l'usage de pmfadm et logger provient de la méthode dns_svc_stop) :

#########################################################################
# MAIN
#########################################################################

PMF_TAG=$RESOURCE_NAME.named

SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME

   # Envoi d’un signal SIGTERM au service de données et attente pendant 80 % du
# délai total imparti.
   pmfadm -s $PMF_TAG.named -w $SMOOTH_TIMEOUT TERM
   if [ $? -ne 0 ]; then 
      logger -p ${SYSLOG_FACILITY}.info \
          -t [$SYSLOG_TAG] \
          “${ARGV0} Failed to stop HA-DNS with SIGTERM; Retry with \
           SIGKILL”

Les méthodes dns_monitor_start, dns_monitor_stop et de dns_update définissent PMF_TAG comme suit (l'usage de pmfadm provient de la méthode dns_monitor_stop) :

#########################################################################
# MAIN
#########################################################################

PMF_TAG=$RESOURCE_NAME.monitor
SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME
...

# Voir si le détecteur tourne et, le cas échéant, l'arrêter. 
if pmfadm -q $PMF_TAG.monitor; then 
   pmfadm -s $PMF_TAG.monitor KILL

Analyse des arguments de la fonction

Le RGM appelle toutes les méthodes de rappel, à l'exception de Validate, de la manière suivante :

 nom_méthode -R nom_ressource -T nom_type_ressource -G  nom_groupe_ressources

Le nom de la méthode correspond au nom de chemin d'accès du programme mettant en œuvre la méthode de rappel. Un service de données spécifie le nom de chemin d’accès de chaque méthode du fichier RTR. Ces noms de chemin correspondent au répertoire spécifié par la propriété RT_basedir, également dans le fichier RTR. Par exemple, dans le fichier RTR du service de données modèle, le répertoire de base et les noms des méthodes sont spécifiés de la manière suivante :

RT_BASEDIR=/opt/SUNWsample/bin;
Start = dns_svc_start;
Stop =  dns_svc_stop;
...

Tous les arguments des méthodes de rappel sont transmis comme des valeurs marquées, avec -R indiquant le nom de l'instance de la ressource, -T indiquant le type de la ressource et -G indiquant le groupe dans lequel est configurée la ressource. Reportez-vous à la page man rt_callbacks (1HA) pour de plus amples informations sur les méthodes de rappel.

Remarque –

La méthode Validate est appelée avec des arguments supplémentaires (les valeurs des propriétés de la ressource et du groupe de ressources ciblées par l'appel). Reportez-vous à la rubriqueGestion des mises à jour des propriétés pour de plus amples informations.

Chaque méthode de rappel a besoin d'une fonction pour analyser les arguments transmis. Tous les rappels étant transmis avec les mêmes arguments, le service de données fournit une seule fonction d'analyse employée dans tous les rappels de l'application.

L'exemple suivant montre l'utilisation de la fonction parse_args() pour les méthodes de rappel de l'application modèle.

#########################################################################
# Analyse des arguments du programme.
#
function parse_args # [args ...]
{
      typeset opt

      while getopts 'R:G:T:' opt
      do
             case "$opt" in
             R)
                  # Nom de la ressource DNS.
                  RESOURCE_NAME=$OPTARG
                  ;;
             G)
                  # Nom du groupe de ressources dans laquelle est
# configurée la ressource.
                  RESOURCEGROUP_NAME=$OPTARG
                  ;;
             T)
                  # Nom du type de ressources.
                  RESOURCETYPE_NAME=$OPTARG
                  ;;
             *)
                  logger -p ${SYSLOG_FACILITY}.err \
                  -t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
                  "ERROR: Option $OPTARG unknown"
                  exit 1
                      ;;
             esac
    done
}

Remarque –

bien que la méthode PROBE de l'application modèle soit définie par l'utilisateur (et qu'il ne s'agisse pas d'une méthode de rappel de Sun Cluster), elle est appelée avec les mêmes arguments que les méthodes de rappel. Par conséquent, cette méthode contient une fonction d'analyse identique à celle employée par les autres méthodes de rappel.

La fonction d'analyse est appelée dans MAIN sous la forme :

parse_args “$@”

Génération de messages d'erreur

Il est recommandé que les méthodes de rappel utilisent la fonction syslog pour émettre des messages d'erreur à l'adresse des utilisateurs finaux. Toutes les méthodes de rappel du service de données modèle utilisent la fonction scha_cluster_get() pour récupérer le numéro de la fonction syslog employée pour le journal du cluster, de la manière suivante :

SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`

La valeur est enregistrée dans une variable de shell, SYSLOG_FACILITY, et peut être utilisée comme fonction de la commande logger pour consigner des messages dans le journal du cluster. Par exemple, la méthode Start du service de données modèle récupère la fonction syslog et consigne un message indiquant que le service de données a été lancé, de la manière suivante :

SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`
...

if [ $? -eq 0 ]; then
   logger -p ${SYSLOG_FACILITY}.err \
         -t [$SYSLOG_TAG] \
         "${ARGV0} HA-DNS successfully started"
fi

Reportez-vous à la page man scha_cluster_get(1HA) pour de plus amples informations.

Obtention des informations des propriétés

La plupart des méthodes de rappel doivent obtenir des informations sur les propriétés des ressources et des types de ressource du service de données. L'API fournit la fonction scha_resource_get() à cette fin.

Deux types de propriétés de ressources, les propriétés définies par le système et les propriétés d'extension, sont disponibles. Les propriétés définies par le système sont prédéfinies alors que les propriétés d'extension du fichier RTR doivent être configurées par l'utilisateur.

Lorsque vous utilisez scha_resource_get() pour obtenir la valeur d'une propriété définie par le système, vous spécifiez le nom de celle-ci à l'aide du paramètre -O. La commande ne renvoie que la valeur de la propriété. Par exemple, dans le service de données modèle, la méthode Monitor_start doit localiser le programme de sonde de manière à pouvoir le lancer. Le programme d'analyse réside dans le répertoire de base du service de données, vers lequel pointe la propriété RT_basedir. Ainsi, la méthode Monitor_start récupère la valeur de la propriété RT_basedir et la place dans la variable RT_basedir comme suit :

RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G \ $RESOURCEGROUP_NAME`

Pour les propriétés d'extension, vous devez spécifier, à l'aide du paramètre -O, qu'il s'agit d'une propriété d'extension et fournir le nom de la propriété comme dernier paramètre. La commande renvoie à la fois le type et la valeur de ce type de propriété. Par exemple, dans le service de données modèle, le programme de sonde récupère le type et la valeur dans la propriété d'extension probe_timeout, puis utilise awk pour ne placer la variable que dans la variable de shell PROBE_TIMEOUT, de la manière suivante :

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}'`