test

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

Chapitre 7 Conception des types de ressource

Ce chapitre explique l'usage habituel de la BDSD dans la conception et la mise en œuvre 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. Ce chapitre décrit enfin la manière d'utiliser la BDSD pour mettre en œuvre 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 œuvre, 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 œuvre 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 œuvre 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 en œuvre le type de ressource, vous pouvez la déclarer comme propriété d'extension dans le fichier RTR de la mise en œuvre du type de ressource, puis y accéder à l'aide de l'utilitaire scds_get_ext_property() de la BDSD.

Méthode Validate

La méthode de validation de l'implémentation d'un type de ressources est appelée par le RGM sous l'une des conditions suivantes :

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 membre d'un jeu de nœuds 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ée sur chaque nœud pouvant héberger (en tant que primaire) le groupe contenant la ressource. Si INIT_NODES a la valeur RT_INSTALLED_NODES , Validate est appelée sur chaque nœud où est installé le logiciel du type de ressource, généralement tous les nœuds du cluster. La valeur par défaut de INIT_NODES est RG_PRIMARIES (reportez-vous à rt_reg(4)). Au moment où la méthode Validate 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 Validate pour la mise en œuvre 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 utilisez 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 œuvre 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 Validate 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 œuvre 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 œuvre de la fonction svc_validate(). Un exemple typique de la mise en œuvre d'un type de ressource viserait à s'assurer qu'un fichier de configuration d'application appelé app.conf existe sous la propriété Confdir_list. Cette vérification peut être facilement mise en œuvre par un appel système stat() effectué sur le nom de chemin d'accès approprié, dérivé de la propriété Confdir_list.

Méthode Start

La méthode de rappel Start associée à la mise en œuvre 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 doit exécuter les opérations nécessaires pour démarrer une ressource de service de données sur le nœud 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 Start 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 œuvre 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 nœud 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 nœud du cluster à ce moment. Dans ce cas, il ne rime à rien de tenter de démarrer la ressource sur ce nœud. Il est préférable de laisser le RGM tenter de démarrer la ressource sur un autre nœud. 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 nœud du cluster absolument nécessaires pour l'application) ou que le démarrage de la ressource peut échouer sur tous les autres nœuds du cluster et ainsi se retrouver avec l'état START_FAILED. 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 nœud. 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 nœud 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 œuvre la détection des échecs.

Méthode Stop

La méthode de rappel Stop de la mise en œuvre d'un type de ressource est appelée par le RGM sur le nœud 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 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 œuvre 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 Start ou par un autre biais), la méthode Stop peut être mise en œuvre 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 œuvre de la méthode Stop, parce que, même si le système rencontre actuellement un problème, cette méthode doit tenter d'arrêter l'application sur ce nœud.

Méthode Monitor_start

Le RGM appelle la méthode de Monitor_start 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 œuvre du type de ressource utilisent généralement un détecteur de pannes sur un démon séparé tournant en arrière-plan. La méthode de rappel de Monitor_start 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. Il utilise le nom du chemin d'accès relatif (basé sur RT_Basedir pour l'emplacement des mises en œuvre 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 Monitor_retry_interval et Monitor_retry_count 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 œuvre 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 Monitor_stop

Le RGM appelle la méthode Monitor_stop pour arrêter le démon du détecteur de pannes démarré par le biais de la méthode Monitor_start. L'échec de la méthode de rappel est traité exactement de la même manière que l'échec de la méthode Stop ; c'est pourquoi la méthode Monitor_stop doit être aussi idempotente et 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 Monitor_check

La méthode de rappel Monitor_check d'une ressource est appelée sur un nœud pour la ressource spécifiée afin de s'assurer que le nœud 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 nœud ?).). 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 nœud du cluster. Comme abordé dans la rubrique Méthode Validate, la fonction svc_validate() mise en œuvre 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 œuvre du type de ressource, la méthode Monitor_check peut être rédigée de manière à exécuter quelques tâches supplémentaires. La méthode Monitor_check doit être mise en œuvre 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é de laisser la méthode Monitor_check tirer profit de la fonction svc_validate() rédigée dans le but de mettre en œuvre la validation spécifique à l'application des propriétés de la ressource.

Méthode Update

Le RGM appelle la méthode Update de la mise en œuvre 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 Update n'est appelée que sur les nœuds (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 œuvre du type de ressource étant donné que le RGM exécute la méthode Validate propre au type de ressource avant de lancer la méthode Update. La méthode Validate 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 de Update 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 TUNABLE = ANYTIME 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 œuvre d'un type de ressource et utilisée par le démon du détecteur de pannes, pour autant que la méthode Update redémarre le démon du détecteur.

Les candidats possibles sont les suivants :

Ces propriétés ont une incidence sur la manière dont un démon de détecteur de pannes vérifie l'état du service, sur la fréquence de cette vérification, sur l'intervalle de temps de l'historique, utilisé par le démon pour suivre les erreurs et sur les seuils de redémarrage définis par le gestionnaire de processus (PMF). Pour mettre à jour ces propriétés, vous pouvez utiliser l'utilitaire scds_pmf_restart() fourni dans la BDSD.

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. Update ne transmet pas les propriétés modifiées à la ligne de commande (comme le fait Validate).

Méthodes d'Init, de Fini et d' Initialisation

Il s'agit de méthodes à action unique, telles que définies par les spécifications de l'API de gestion des ressources. L'exemple d'implémentation fourni 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 Init et Boot sont exactement les mêmes que pour l'implémentation d'un type de ressource en une action unique. La méthode de Fini exécute généralement une opération désactivant l'action des méthodes d'Init ou d'Initialisation.

Conception du démon du détecteur de pannes

Les mises en œuvre 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 œuvre par le biais de BDSD :

Dans la plupart des cas, le contrôle de santé spécifique à l'application peut être mis en œuvre 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 */