test

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

Chapitre 7 Conception des types de ressource

Ce chapitre explique l'usage habituel de la DSDL (Bibliothèque de développement de services de données) dans la conception et la mise en oeuvre des types de ressource. Il se concentre également sur la conception du type de ressource permettant de valider la configuration de la ressource ainsi que de démarrer, arrêter et surveiller la ressource. Enfin, il explique comment utiliser la DSDL pour mettre en oeuvre les méthodes de rappel associées au type de ressource.

Reportez-vous à la page de manuel rt_callbacks(1HA) pour en savoir plus.

Pour accomplir ces tâches, vous devez accéder aux paramètres des propriétés de ressources. L'utilitaire DSDL scds_initialize() vous propose une méthode uniforme pour accéder à ces propriétés de ressource. Il est conçu de manière à être appelé au début de chaque méthode de rappel. Cet utilitaire récupère toutes les propriétés d'une ressource depuis la structure d'un cluster et et les met à la disposition de la famille de fonctions scds_getname().

Ce chapitre contient les rubriques suivantes :

Fichier RTR (Resource Type Registration)

Le fichier Resource Type Registration (RTR) indique les détails concernant le type de ressource dans le logiciel Sun Cluster. Ces détails comprennent des informations telles que :

L'exemple de fichier RTR fourni avec la DSDL est suffisant pour la plupart des mises en oeuvre de types de ressource. Vous devez seulement modifier certains éléments de base, tels que le nom du type de ressource et le nom du chemin d'accès des méthodes de rappel associées au type de ressource. Si une nouvelle propriété est nécessaire pour mettre en oeuvre le type de ressource, vous pouvez la déclarer comme propriété d'extension dans le fichier RTR de la mise en oeuvre du type de ressource, et y accéder à l'aide de l'utilitaire scds_get_ext_property() de la DSDL.

Méthode Validate

L'objectif de la méthode de rappel Validate de la mise en oeuvre d'un type de ressource est de vérifier que les paramètres de ressource proposés (tels que spécifiés par les paramètres de propriété proposés pour la ressource) sont acceptables pour le type de ressource.

La méthode Validate de mise en oeuvre d'un type de ressource est appelée par le gestionnaire RGM (Resource Group Manager) dans l'un des deux cas suivants :

Ces deux scénarios se distinguent par la présence de l'option de ligne de commande -c (création) ou -u (mise à jour) transmise à la méthode Validate de la ressource.

La méthode Validate est appelée sur chaque élément d'un jeu de noeuds défini par la valeur de la propriété Init_nodes du type de ressource. Si Init_nodes a la valeur RG_PRIMARIES , Validate est appelé sur chaque noeud pouvant héberger (en tant que primaire) le groupe contenant la ressource. Si Init_nodes a la valeur RT_INSTALLED_NODES, Validate est appelé sur chaque noeud où est installé le logiciel de type de ressource, généralement tous les noeuds du cluster.

La valeur par défaut de Init_nodes est RG_PRIMARIES (voir la page de manuel rt_reg(4)). Au moment où la méthode Validate est appelée, le gestionnaire RGM n'a pas encore créé la ressource (dans le cas d'un rappel de création) ou n'a pas encore appliqué les valeurs mises à jour des propriétés actualisées (dans le cas d'un rappel de mise à jour).

Remarque –

Si vous utilisez des systèmes de fichiers locaux gérés par le type de ressource HAStoragePlus, vous utilisez la fonction scds_hasp_check() pour vérifier l'état de ce type de ressource. Ces informations sont obtenues à partir de l'état (en ligne ou autre) de toutes les ressources SUNW.HAStoragePlus dont dépend la ressource, à l'aide des propriétés système Resource_dependencies ou Resource_dependencies_weak définies pour cette ressource. Reportez-vous à la page de manuel scds_hasp_check(3HA) pour obtenir une liste complète des codes d'état renvoyés par la fonction scds_hasp_check ().

La fonction DSDL scds_initialize() gère ces situations de la manière suivante :

Supposons que la fonction qui met en oeuvre la validation des propriétés d'une ressource s'appelle svc_validate(), et qu'elle utilise la famille de fonctions scds_get_name() pour examiner la propriété qu'elle doit valider. En admettant qu'un paramètre de ressource acceptable soit représenté par un code de retour 0 émis par cette fonction, la méthode Validate du type de ressource peut alors être représentée par le fragment de code suivant : 

int
main(int argc, char *argv[])
{
   scds_handle_t handle;
   int rc;

   if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR) {
   return (1);   /* Initialization Error */
   }
   rc = svc_validate(handle);
   scds_close(&handle);
   return (rc);
}

La fonction de validation doit également consigner le motif de l'échec de la validation de la ressource. Toutefois, pour aller à l'essentiel (vous trouverez au Chapitre 8, Mise en oeuvre du type de ressource DSDL modèle des informations plus réalistes sur la fonction de validation), un exemple plus simple de la fonction svc_validate() peut être mis en oeuvre de la manière suivante : 

int
svc_validate(scds_handle_t handle)
{
   scha_str_array_t *confdirs;
   struct stat    statbuf;
   confdirs = scds_get_confdir_list(handle);
   if (stat(confdirs->str_array[0], &statbuf) == -1) {
   return (1);   /* Invalid resource property setting */
   }
   return (0);   /* Acceptable setting */
}

Vous ne devez donc vous préoccuper que de la mise en oeuvre de la fonction svc_validate().

Méthode de Démarrage

La méthode de rappel de Démarrage associée à la mise en oeuvre d'un type de ressource est appelée par le RGM sur un cluster donné afin de démarrer la ressource. Les noms du groupe de ressources, de la ressource et du type de ressource sont transmis à la ligne de commande. La méthode Start effectue les opérations nécessaires pour démarrer une ressource de service de données sur le noeud du cluster. Généralement, ceci implique la récupération des propriétés de la ressource, la localisation des fichiers exécutables et/ou de configuration spécifiques à l'application, ainsi que le démarrage de l'application avec les arguments de ligne de commande appropriés.

Avec la DSDL, la configuration de la ressource est déjà récupérée par l'utilitaire scds_initialize(). L'opération de démarrage de l'application peut être contenue dans une fonction svc_start(). Une autre fonction, svc_wait(), peut être appelée pour vérifier que l'application démarre bien. Le code simplifié de la méthode Start est le suivant : 

int
main(int argc, char *argv[])
{
   scds_handle_t handle;

   if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR) {
   return (1);   /* Initialization Error */
   }
   if (svc_validate(handle) != 0) {
   return (1);   /* Invalid settings */
   }
   if (svc_start(handle) != 0) {
   return (1);   /* Start failed */
   }
   return (svc_wait(handle));
}

Cette mise en oeuvre de la méthode de démarrage appelle svc_validate() pour valider la configuration de la ressource. En cas d'échec, cela signifie soit que la configuration de la ressource et la configuration de l'application ne correspondent pas, soit qu'il y a un problème lié au système sur ce noeud de cluster. Par exemple, un système de fichiers de cluster requis par la ressource peut ne pas être disponible sur ce noeud de cluster. Dans ce cas, il est inutile d'essayer de démarrer la ressource sur ce noeud de cluster. Il est préférable de laisser le RGM tenter de démarrer la ressource sur un autre noeud.

Notez toutefois que l'instruction précédente considère que svc_validate () est suffisamment conservatrice, c'est-à-dire qu'elle ne vérifie que les ressources du noeud de cluster qui sont absolument indispensables à l'application. Si ce n'était pas le cas, la ressource risquerait de ne pas pouvoir démarrer sur tous les noeuds de cluster et, par conséquent, prendrait l'état START_FAILED. Reportez-vous à la page de manuel scswitch(1M) et au Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour en savoir plus sur cet état.

La fonction svc_start() doit renvoyer la valeur 0 pour un démarrage réussi de la ressource sur le noeud. Si la fonction de démarrage rencontre un problème, elle doit renvoyer une valeur différente de zéro. Si cette fonction échoue, le RGM tente de démarrer la ressource sur un autre noeud du cluster.

Pour tirer parti au maximum de la DSDL, la fonction svc_start() peut appeler l'utilitaire scds_pmf_start() pour démarrer l'application sous le gestionnaire de processus (PMF). Cet utilitaire utilise également l'action de rappel d'échec du PMF pour détecter l'échec du processus. Pour en savoir plus, reportez-vous à la description de l'argument d'action - a à la page de manuel pmfadm(1M).

Méthode Stop

La méthode de rappel d'Arrêt de la mise en oeuvre d'un type de ressource est appelée par le RGM sur le noeud du cluster pour arrêter l'application. La sémantique de rappel de la méthode Stop exige que les conditions suivantes soient remplies :

L'utilitaire de la DSDL scds_pmf_stop() devrait suffire pour la plupart des applications, dans la mesure où il essaie d'abord d'arrêter l'application normalement avec SIGTERM . Cette fonction envoie ensuite un SIGKILL au processus. Elle considère que l'application a été démarrée par le gestionnaire de processus à l'aide de scds_pmf_start(). Pour en savoir plus sur cet utilitaire, reportez-vous à la section Fonctions PMF.

En supposant que la fonction spécifique à l'application qui doit arrêter cette dernière s'appelle svc_stop(), mettez en oeuvre la méthode Stop de la manière suivante : 

if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR)
{
   return (1);   /* Erreur d'initialisation */
}
return (svc_stop(handle));

Que la mise en oeuvre de la fonction précédente svc_stop() inclue ou non la fonction scds_pmf_stop() n’a pas d’importance. Cela dépend d'un éventuel démarrage de l’application par le gestionnaire de processus via la méthode Start.

La méthode svc_validate() n'est pas utilisée dans la mise en oeuvre de la méthode Stop car, même si le système rencontre un problème, la méthode Stop doit tenter d'arrêter l'application sur ce noeud.

Méthode Monitor_start

Le RGM appelle la méthode Monitor_start pour lancer un détecteur de pannes pour la ressource. Les détecteurs de pannes contrôlent l'état de l'application qui est gérée par la ressource. Les mises en oeuvre de types de ressource mettent généralement en oeuvre un détecteur de pannes sur un démon séparé exécuté en arrière-plan. La méthode de rappel Monitor_start est utilisée pour démarrer ce démon avec les arguments appropriés.

Le démon du détecteur étant sujet aux échecs (il peut mourir par exemple, laissant l'application sans surveillance), vous devez utiliser le gestionnaire de processus pour lancer le démon du détecteur. L'utilitaire de la DSDL scds_pmf_start() dispose d'une prise en charge intégrée pour le démarrage des détecteurs de pannes. Il utilise le nom du chemin d'accès relatif de RT_basedir pour l'emplacement des mises en oeuvre de la méthode de rappel du type de ressource de ce démon de détecteur. Cet utilitaire utilise les propriétés d'extension Monitor_retry_interval et Monitor_retry_count gérées par la DSDL pour éviter des redémarrages illimités du démon.

Il impose également la même syntaxe de ligne de commande que celle définie pour toutes les méthodes de rappel (c'est-à-dire -R resource -G resource-group -T resource-type) sur le démon du détecteur, bien que celui-ci ne soit jamais appelé directement par le RGM. Enfin, l'utilitaire autorise également la mise en oeuvre du démon du détecteur pour permettre à l'utilitaire scds_initialize() de configurer son propre environnement. L'effort principal consiste à concevoir le démon du détecteur lui-même.

Méthode Monitor_stop

Le RGM appelle la méthode Monitor_stop pour arrêter le démon du détecteur de pannes qui a été démarré à l'aide de la méthode Monitor_start. L'échec de la méthode de rappel est considéré exactement comme un échec de la méthode Stop, c'est pourquoi la méthode Monitor_stop doit être idempotente et aussi robuste que la méthode Stop.

Si vous employez l'utilitaire scds_pmf_start() pour démarrer le démon du détecteur de pannes, recourez à scds_pmf_stop() pour l'arrêter.

Méthode de Monitor_check

Le RGM exécute la méthode de rappel Monitor_check sur une ressource spécifiée d'un noeud pour vérifier si le noeud de cluster est capable de maîtriser la ressource. En d'autres termes, il exécute cette méthode pour savoir si l'application qui est gérée par la ressource peut fonctionner sur le noeud.

En général, dans cette situation on doit s'assurer que toutes les ressources système requises par l'application sont effectivement disponibles sur le noeud du cluster. Comme expliqué à la section Méthode Validate, c'est la fonction svc_validate() que vous mettez en oeuvre qui permet de s'en assurer.

Selon l'application spécifique qui est gérée par la mise en oeuvre du type de ressource, il est possible de rédiger la méthode Monitor_check de manière à effectuer des tâches supplémentaires. La méthode Monitor_check doit être mise en oeuvre pour ne pas entrer en conflit avec les autres méthodes exécutées en même temps. Si vous utilisez la DSDL, la méthode Monitor_check doit appeler la fonction svc_validate(), qui met en oeuvre la validation spécifique à l'application des propriétés de la ressource.

Méthode de Mise_à_jour

Le RGM appelle la méthode Update de mise en oeuvre d'un type de ressource pour appliquer les modifications apportées par l'administrateur du cluster à la configuration de la ressource active. La méthode Mise_à_jour n'est appelée que sur les noeuds (le cas échéant) sur lesquels la ressource est en ligne.

Les modifications qui viennent d'être apportées à la configuration de la ressource sont nécessairement acceptables pour la mise en oeuvre du type de ressource, car le RGM exécute la méthode Validate du type de ressource avant d'exécuter la méthode Update . La méthode Validate est appelée avant que les propriétés de la ressource ou du groupe de ressources soient modifiées, et la méthode Validate peut s'opposer aux modifications proposées. La méthode de Mise_à_jour est appelée après l'application des modifications de manière à permettre à la ressource active (en ligne) de prendre les nouveaux paramètres en compte.

Vous devez être prudent lorsque vous déterminez les propriétés que vous souhaitez pouvoir mettre à jour de manière dynamique, et que vous les marquez avec le paramètre TUNABLE = ANYTIME dans le fichier RTR. De manière générale, vous pouvez spécifier que vous souhaitez pouvoir mettre à jour de manière dynamique les propriétés relatives à la mise en oeuvre d'un type de ressource utilisées par le démon du détecteur de pannes. Toutefois, la mise en oeuvre de la méthode Update doit au moins redémarrer le démon du détecteur.

Les propriétés que vous pouvez utiliser sont les suivantes :

Ces propriétés affectent la manière dont un démon de détecteur de pannes vérifie l'état du service, la fréquence à laquelle il effectue ces vérifications, l'intervalle qu'il utilise pour effectuer le suivi des erreurs dans l'historique, et les seuils de redémarrage définis par le gestionnaire de processus. Pour mettre à jour ces propriétés, l'utilitaire scds_pmf_restart() est fourni avec la DSDL.

Si vous avez besoin de pouvoir mettre à jour de manière dynamique une propriété de ressource, mais que la modification de cette propriété risque d'affecter l'application en cours d'exécution, vous devez mettre en oeuvre les actions appropriées. Vous devez vous assurer que les mises à jour de cette propriété sont correctement appliquées aux instances en cours d'exécution de l'application. Actuellement, vous ne pouvez pas utiliser la DSDL pour mettre à jour de manière dynamique une propriété de ressource de cette manière. Update ne vous permet pas de transmettre les propriétés modifiées à la ligne de commande (contrairement à Validate).

Description des méthodes Init, Fini et Boot

Il s'agit de méthodes à action unique, tel que défini par les spécifications de l'API de gestion des ressources. L'exemple d'implémentation fourni avec la DSDL n'illustre pas l'utilisation de ces méthodes. Toutefois, si vous avez besoin de ces méthodes, elles disposent de toutes les fonctions de la DSDL. Généralement, les méthodes Init et Boot sont exactement les mêmes pour un type de ressource qui mettrait en oeuvre une action unique. Quant à la méthode Fini, elle exécute une opération qui annule l'action des méthodes Init ou Boot.

Conception du démon du détecteur de pannes

Les mises en oeuvre du type de ressource qui utilisent la DSDL possèdent généralement un démon de détecteur de pannes qui prend en charge les opérations suivantes :

Les utilitaires de la DSDL sont conçus de manière à ce que la boucle principale du démon du détecteur de pannes puisse être représentée par le pseudo code que vous trouverez à la fin de cette section.

Gardez les éléments suivants à l'esprit lorsque vous mettez en oeuvre un détecteur de pannes avec la DSDL :

Dans la plupart des cas, le contrôle d'état spécifique à l'application peut être mis en oeuvre dans un utilitaire autonome distinct (svc_probe(), par exemple). Vous pouvez l'intégrer à cette boucle principale générique : 

for (;;) {
   /* sleep for a duration of thorough_probe_interval between
   *  successive probes.
   */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));
   /* Now probe all ipaddress we use. Loop over
   * 1. All net resources we use.
   * 2. All ipaddresses in a given resource.
   * For each of the ipaddress that is probed,
   * compute the failure history. 
   */
   probe_result = 0;
   /* Iterate through the all resources to get each
   * IP address to use for calling svc_probe()
   */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Grab the hostname and port on which the
   * health has to be monitored.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS supports only one port and
   * hence obtaint the port value from the
   * first entry in the array of ports.
   */
   ht1 = gethrtime();
   /* Latch probe start time */
   probe_result = svc_probe(scds_handle, hostname, port, timeout);
   /*
   * Update service probe history,
   * take action if necessary.
   * Latch probe end time.
   */
   ht2 = gethrtime();
   /* Convert to milliseconds */
   dt = (ulong_t)((ht2 - ht1) / 1e6);
   /*
   * Compute failure history and take
   * action if needed
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Each net resource */
   }       /* Keep probing forever */