test

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

Chapitre 7 Conception des types de ressources

Ce chapitre explique l'usage habituel de la BDSD dans la conception et la mise en oeuvre des types de ressources. 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. Ce chapitre décrit enfin la manière d'utiliser la BDSD 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 obtenir de plus amples informations.

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

Ce chapitre contient les rubriques suivantes  :

Fichier RTR

Le fichier RTR (Resource Type Registration) est un élément important du type de ressource. Ce fichier spécifie les détails du type de ressource dans Sun Cluster. Ces détails comprennent des informations telles que les propriétés requises par la mise en oeuvre, les types de données de ces propriétés, leurs valeurs par défaut, le chemin du système de fichiers pour les méthodes de rappel associées à la mise en oeuvre du type de ressource et différents paramètres pour les propriétés définies par le système.

Le fichier RTR modèle fourni avec la BDSD doit être suffisant pour la plupart des mises en oeuvre du type de ressource. Il vous suffit d'éditer 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 le type de ressource en oeuvre, vous pouvez la déclarer comme propriété d'extension dans le fichier RTR de la mise en oeuvre du type de ressource, puis y accéder à l'aide de l'utilitaire scds_get_ext_property() de la BDSD.

Méthode Validation

Il existe deux scénarios pour l'appel par le RGM de la méthode Validation dans le cadre de la mise en oeuvre d'un type de ressource : 1) à la création d'une nouvelle ressource d'un type donné et 2) à la mise à jour d'une propriété de la ressource ou du groupe de ressources. 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 Validation de la ressource.

La méthode Validation est appelée sur chaque membre d'un jeu de noeuds défini par la valeur de la propriété NOEUDS_INIT du type de ressource. Si NOEUDS_INIT a la valeur ÉLÉMENTS_PRINCIPAUX_GR, Validation est appelée sur chaque noeud pouvant héberger (en tant que primaire) le groupe contenant la ressource. Si NOEUDS_INIT a la valeur NOEUDS_INSTALLÉS_TR, Validation est appelée sur chaque noeud où est installé le logiciel du type de ressource, généralement tous les noeuds du cluster. La valeur par défaut de NOEUDS_INIT est ÉLÉMENTS_PRINCIPAUX_GR (reportez-vous à rt_reg(4)). Au moment où la méthode Validation est appelée, le 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 pour la propriété actualisée (dans le cas d'un rappel de mise à jour). L'objectif de la méthode de rappel Validation pour la mise en oeuvre d'un type de ressource consiste à vérifier que les paramètres de la ressource (tels que spécifiés par les valeurs proposées pour les propriétés de la ressource) sont acceptables pour le type de ressource

Remarque :

si vous utilisez des systèmes de fichiers locaux gérés par HAStoragePlus, vous employez la commande scds_hasp_check pour vérifier l'état de la ressource HAStoragePlus. Ces informations sont obtenues à partir de l'état (en ligne ou autre) de toutes les ressources SUNW.HAStoragePlus(5) dont dépend la ressource à l'aide des propriétés système Dépendances_ressource ou Dépendances_ressource_faibles définies pour la ressource. Reportez-vous à scds_hasp_check(3HA) pour obtenir une liste complète des codes d'état renvoyés par l'appel scds_hasp_check.

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

Supposons que la fonction mettant en oeuvre la validation des propriétés d'une ressource s'appelle svc_validate() et utilise la famille de fonctions scds_get_nom() 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 de Validation du type de ressource peut donc ê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);   /* Erreur d'initialisation */
   }
   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. Pour aller à l'essentiel (vous trouverez au chapitre suivant des informations plus réalistes sur la fonction de validation) un exemple 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);   /* Paramètre de propriété de ressource invalide */
   }
   return (0);   /* Paramètre acceptable */
}

Le développeur du type de ressource ne doit donc se préoccuper que de la mise en oeuvre de la fonction svc_validate(). Un exemple typique de la mise en oeuvre d'un type de ressource viserait à s'assurer qu'un fichier de configuration d'application appelé app.conf existe sous la propriété Liste_rép_conf. Cette vérification peut être facilement mise en oeuvre par un appel système stat() effectué sur le nom de chemin d'accès approprié, dérivé de la propriété Liste_rép_conf.

Méthode Démarrage

La méthode de rappel 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 Démarrage doit exécuter 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 exécutables et/ou des fichiers de configuration spécifiques à l'application ainsi que le lancement des arguments de ligne de commande appropriés.

Avec la BDSD, 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 Démarrage devient : 


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

   if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR) {
   return (1);   /* Erreur d'initialisation */
   }
   if (svc_validate(handle) != 0) {
   return (1);   /* Paramètres invalides */
   }
   if (svc_start(handle) != 0) {
   return (1);   /* Échec du démarrage */
   }
   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, soit les configurations de la ressource et de l'application sont conflictuelles soit ce noeud du cluster rencontre actuellement un problème lié au système. Par exemple, un système de fichiers global requis par la ressource peut ne pas être disponible sur ce noeud du cluster à ce moment. Dans ce cas, il ne rime à rien de tenter de démarrer la ressource sur ce noeud. Il est préférable de laisser le RGM tenter de démarrer la ressource sur un autre noeud. Toutefois, remarquez que les informations indiquées ci-dessus supposent que svc_validate () est suffisamment conservatrice (en d'autres termes, qu'elle ne vérifie que les ressources du noeud du cluster absolument nécessaires pour l'application) ou que le démarrage de la ressource peut échouer sur tous les autres noeuds du cluster et ainsi se retrouver avec l'état ECHEC_DEMARRAGE. Reportez-vous à scswitch( 1M) et au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS pour de plus amples explications 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 retourner une valeur différente de 0. Si cette fonction échoue, le RGM tente de démarrer la ressource sur un autre noeud du cluster.

Pour tirer avantage de la BDSD autant que possible, la fonction svc_start() peut recourir à l'utilitaire scds_pmf_start() pour démarrer l'application sous le gestionnaire de processus. Cet utilitaire permet également de tirer profit de l'action de rappel d'échec du gestionnaire de processus (reportez-vous à l'indicateur d'action -a dans pmfadm( 1M)) pour mettre en oeuvre la détection des échecs.

Méthode Arrêt

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 Arrêt exige que les conditions suivantes soient remplies :

L'utilitaire BDSD scds_pmf_stop() doit suffire pour la plupart des applications étant donné qu'il essaie d'abord d'arrêter l'application à chaud (via SIGTERM) (il suppose qu'elle a été démarrée par le gestionnaire de processus à l'aide de scds_pmf_start()) avant d'émettre un SIGKILL à l'adresse du processus. Reportez-vous à la rubrique Fonctions PMF pour obtenir de plus amples informations sur cet utilitaire.

Sur la base du modèle de code utilisé jusqu'à présent, et en supposant que la fonction spécifique visant à arrêter l'application s'appelle svc_stop() (le fait que la mise en oeuvre de svc_stop() utilise ou non scds_pmf_stop() n'a aucune importance ici et dépend de la méthode de démarrage de l'application : par le gestionnaire de processus à l'aide de la méthode Démarrage ou par un autre biais), la méthode Arrêt peut être mise en oeuvre de la façon suivante : 

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

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

Méthode Démarrage_détecteur

Le RGM appelle la méthode Démarrage_détecteur pour démarrer un détecteur de pannes pour la ressource. Les détecteurs de pannes surveillent la santé de l'application gérée par la ressource. Les mises en oeuvre du type de ressource mettent généralement en oeuvre un détecteur de pannes sur un démon séparé tournant en arrière-plan. La méthode de rappel Démarrage_détecteur est utilisée pour lancer ce démon à l'aide des arguments appropriés.

Le démon du détecteur étant lui-même sensible aux échecs (par exemple, il peut mourir, laissant ainsi l'application sans surveillance), vous devez utiliser le gestionnaire de processus pour démarrer le démon du détecteur. L'utilitaire scds_pmf_start() de BDSD présente une prise en charge intégrée pour le démarrage des détecteurs de pannes. Cet utilitaire utilise le nom du chemin d'accès relatif (basé sur Rép_base_TR pour l'emplacement des mises en oeuvre de la méthode de rappel du type de ressource) du programme du démon du détecteur. Il utilise les propriétés d'extension Intervalle_nouvelles_tentatives_détecteur et Nombre_nouvelles_tentatives_détecteur gérées par la BDSD pour éviter des redémarrages illimités du démon. Il impose une syntaxe de ligne de commande identique à celle définie pour toutes les méthodes de rappel (à savoir, -R ressource -G groupe_ressources -T type_ressource) sur le démon du détecteur bien que celui-ci ne soit jamais appelé directement par le RGM. Il permet à la mise en oeuvre du démon du détecteur de profiter de l'utilitaire scds_initialize() pour configurer son propre environnement. L'effort principal consiste à concevoir le démon du détecteur lui-même.

Méthode Arrêt_détecteur

Le RGM appelle la méthode Arrêt_détecteur pour arrêter le démon du détecteur de pannes démarré par le biais de la méthode Démarrage_détecteur. L'échec de la méthode de rappel est traité exactement de la même manière que l'échec de la méthode Arrêt ; c'est pourquoi la méthode Arrêt_détecteur doit être aussi idempotente et robuste que la méthode Arrêt.

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 Contrôle_détecteur

La méthode de rappel Contrôle_détecteur d'une ressource est appelée sur un noeud pour la ressource spécifiée afin de s'assurer que le noeud du cluster est capable de maîtriser la ressource (en d'autres termes : les applications gérées par la ressource peuvent-elles tourner sans problème sur ce noeud ?). Généralement, cette situation suppose que l'on s'assure que toutes les ressources système requises par l'application sont effectivement disponibles sur le noeud du cluster. Comme abordé dans la rubrique Méthode Validation, la fonction svc_validate() mise en oeuvre par le développeur est destinée à obtenir au moins cette certitude.

En fonction de l'application spécifique gérée par la mise en oeuvre du type de ressource, la méthode Contrôle_détecteur peut être rédigée de manière à exécuter quelques tâches supplémentaires. La méthode Contrôle_détecteur doit être mise en oeuvre de manière à ne pas entrer en conflit avec d'autres méthodes exécutées simultanément. Pour les développeurs utilisant la BDSD, il est recommandé que la méthode Contrôle_détecteur tire profit de la fonction svc_validate() rédigée dans le but de mettre en oeuvre la validation spécifique à l'application des propriétés de la ressource.

Méthode Mise_à_jour

Le RGM appelle la méthode Mise_à_jour de la mise en oeuvre d'un type de ressource pour appliquer les modifications apportées par l'administrateur système à 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.

Il ne fait aucun doute que les modifications venant d'être apportées à la ressource sont acceptables pour la mise en oeuvre du type de ressource étant donné que le RGM exécute la méthode Validation propre au type de ressource avant de lancer la méthode Mise_à_jour. La méthode Validation est appelée avant la modification des propriétés de la ressource ou du groupe de ressources, et elle peut s'opposer aux changements proposés. La méthode 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.

En tant que développeur du type de ressource, vous devez faire preuve de prudence lorsque vous décidez des propriétés pouvant être mises à jour de manière dynamique et les marquez à l'aide du paramètre RÉGLABLE = À_TOUT_MOMENT du fichier RTR. Généralement, vous pouvez spécifier que vous souhaitez pouvoir mettre à jour de manière dynamique une propriété relative à la mise en oeuvre d'un type de ressource et utilisée par le démon du détecteur de pannes, pour autant que la méthode Mise_à_jour redémarre le démon du détecteur.

Les candidats possibles sont les suivants :

Ces propriétés influent sur la manière dont le démon du détecteur de pannes contrôle la santé du service, à quelle fréquence il le fait, quel intervalle d'historique il utilise pour assurer le suivi des erreurs et quels seuils de redémarrage sont définis pour lui par le gestionnaire de processus. L'utilitaire scds_pmf_restart () fourni dans la BDSD permet de mettre ces propriétés à jour.

Si vous pouvez mettre à jour de manière dynamique une propriété de ressource mais que la modification de celle-ci risque d'influer sur l'application en cours d'exécution, vous devez prendre les mesures appropriées de manière à ce que les mises à jour de cette propriété soient appliquées correctement dans toutes les instances de l'application en cours d'exécution. Actuellement, la BDSD ne propose aucune solution permettant de faciliter cette opération. Mise_à_jour ne transmet pas les propriétés modifiées à la ligne de commande (comme le fait Validation).

Méthodes Init, Fini et Initialisation

Il s'agit de méthodes à action unique telles que définies par les spécifications de l'API de gestion des ressources. La mise en oeuvre modèle fournie avec la BDSD n'illustre pas l'utilisation de ces méthodes. Toutefois, toutes les fonctions de la BDSD sont également disponibles dans celles-ci, si un développeur de type de ressource devait en avoir besoin. Généralement, les méthodes d'Init et d'Initialisation sont exactement les mêmes pour le type de ressource qui mettrait en oeuvre une action unique. La méthode Fini exécute généralement une opération désactivant l'action des méthodes Init ou Initialisation.

Conception du démon du détecteur de pannes

Les mises en oeuvre du type de ressource utilisant la BDSD possèdent généralement un démon du détecteur de pannes assumant les responsabilités suivantes :

Les utilitaires BDSD sont conçus de manière à ce que la boucle principale du démon du détecteur de pannes soit représentée par le pseudo-code suivant :

Pour les détecteurs de pannes mis en oeuvre par le biais de BDSD :

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


for (;;) {

   / * Sommeil pendant la durée de l'intervalle Intervalle_sonde_complet
   *  entre des sondages successifs. */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));

   /* Sonde de toutes les adresses IP utilisées. Passage en boucle sur
   * 1. Toutes les ressources net utilisées.
   * 2. Toutes les adresses IP d'une ressource donnée.
   * Pour chacune des adresses sondées,
   * calcul de l'historique des pannes. */
   probe_result = 0;
   /* Itération dans toutes les ressources pour obtenir toutes
    * les adresses IP à utiliser pour l'appel de svc_probe() */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Obtention du nom de l'hôte et du port dont
   * la santé doit être surveillée.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS ne prend en charge qu'un seul port et
   * obtient donc la valeur du port à partir de la
   * première entrée du tableau des ports.
   */
   ht1 = gethrtime(); /* Blocage de l'heure de démarrage de sondage */
   probe_result = svc_probe(scds_handle,

   hostname, port, timeout);
   /*
   * Mise à jour de l'historique des sondages du service,
   * action si nécessaire.
   * Blocage de l'heure de fin de sondage.
   */
   ht2 = gethrtime();
   /* Conversion en millisecondes */
   dt = (ulong_t)((ht2 - ht1) / 1e6);

   /*
   * Calcul de l'historique des pannes et
   * action si nécessaire
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Chaque ressource net */
   }       /* Toujours continuer le sondage */