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 :
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 :
les propriétés nécessaires à la mise en oeuvre
les types de données et les valeurs par défaut de ces propriétés
le chemin du système de fichiers pour les méthodes de rappel associées à la mise en oeuvre du type de ressource
différents paramètres pour les propriétés définies par le système
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.
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 :
création d'une ressource du même type ;
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 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).
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 :
Dans le cas d'une création de ressource, scds_initialize() analyse les propriétés proposées pour la ressource, telles qu'elles sont transmises sur la ligne de commande. Les valeurs proposées pour les propriétés de ressources sont donc disponibles comme si la ressource avait déjà été créée dans le système.
Dans le cas d'une mise à jour de la ressource ou du groupe de ressources, les valeurs proposées pour les propriétés qui sont mises à jour par l'administrateur du cluster sont lues depuis la ligne de commande. Les autres propriétés (dont les valeurs ne sont pas actualisées) sont lues depuis Sun Cluster à l'aide de l'API de gestion des ressources. Si vous utilisez la DSDL, vous n'avez pas besoin de vous préoccuper de ces tâches. Vous pouvez valider une ressource comme si toutes les propriétés de la ressource étaient disponibles.
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().
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).
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 :
La méthode Stop doit être idempotente parce qu'elle peut être appelée par le gestionnaire RGM, même si la méthode Start n'a pas fonctionné correctement sur le noeud. Par conséquent, la méthode Stop doit aboutir (valeur zéro), même si l'application n'est pas en cours d'exécution sur le noeud de cluster et qu'elle n'a aucune tâche à accomplir.
Si la méthode Stop du type de ressource échoue (valeur différente de zéro) sur un noeud de cluster, la ressource qui est arrêtée passe à l'état STOP_FAILED. En fonction du paramètre Failover_mode de la ressource, ceci peut entraîner un redémarrage brutal du noeud de cluster par le RGM.
Vous devez donc concevoir la méthode Stop de manière à ce qu'elle arrête vraiment l'application. Vous devrez peut-être recourir à SIGKILL pour fermer l'application de manière brutale si la procédure de fermeture normale échoue.
Vous devez également vous assurer que cette méthode arrête l'application dans les temps, car la structure traite l'expiration de la propriété Stop_timeout comme un échec de l'arrêt et, par conséquent, fait passer la ressource à l'état STOP_FAILED.
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.
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.
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.
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.
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 :
Thorough_probe_interval
Retry_count
Retry_interval
Nombre_nouvelles_tentatives_détecteur ;
Intervalle_nouvelles_tentatives_détecteur ;
Délai_sonde.
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).
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.
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 :
Contrôle régulier de l'état de l'application gérée. Cette tâche dépend de l'application et peut varier considérablement d'un type de ressource à un autre. La DSDL contient des fonctions d'utilitaire intégrées qui procèdent à des vérifications d'état pour des services TCP simples. Vous pouvez utiliser ces utilitaires pour mettre en oeuvre des applications qui utilisent des protocoles ASCII, tels que HTTP, NNTP, IMAP et POP3.
Consignation des problèmes rencontrés par l'application à l'aide des propriétés de ressource Retry_interval et Retry_count . Lorsque l'application est en échec total, le détecteur de pannes doit déterminer si le script d'action du gestionnaire de processus doit redémarrer le service ou si les échecs de l'application se sont accumulés si rapidement qu'il faut procéder à un basculement. Les utilitaires de la DSDL scds_fm_action() et scds_fm_sleep() sont destinés à vous aider à mettre en oeuvre ce mécanisme.
Prise de mesures appropriées, soit en redémarrant l'application, soit en procédant à une tentative de basculement du groupe de ressources. L'utilitaire scds_fm_action () de la DSDL met en oeuvre cet algorithme. Il calcule l'accumulation actuelle des échecs de sonde au cours du délai Retry_interval (en secondes) défini dans ce but.
Mise à jour de l'état de la ressource, de manière à ce que la commande scstat et l'interface utilisateur graphique de gestion du cluster puissent connaître l'état de l'application.
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 :
La mort du processus de l'application est détectée assez rapidement par la fonction scds_fm_sleep(), car sa notification par le gestionnaire de processus est asynchrone. Le temps de détection des pannes s'en trouve réduit de manière significative, ce qui augmente la disponibilité du service. Autrement, le détecteur de pannes risquerait de se réactiver régulièrement pour vérifier l'état d'un service et constaterait que le processus de l'application est mort.
Si le RGM rejette la tentative de basculement du service à l'aide de l'API scha_control, la fonction scds_fm_action() réinitialise, ou oublie, son historique des pannes actuel. La raison en est que son historique dépasse déjà Retry_count. Si le démon du détecteur s'active au cours de l'itération suivante et est incapable de contrôler l'état du démon, il tente à nouveau d'appeler la fonction scha_control(). Cet appel est probablement rejeté une fois de plus, étant donné que la situation qui a entraîné son rejet au cours de la dernière itération perdure. La réinitialisation de l'historique garantit que le détecteur de pannes tente au moins de remédier à la situation localement (par exemple, par le biais d'un redémarrage de l'application) au cours de l'itération suivante.
scds_fm_action() ne réinitialise pas l'historique des échecs de l'application en cas d'échec du redémarrage, étant donné que l'utilisateur tente généralement d'utiliser scha_control() rapidement si la situation ne s'améliore pas d'elle-même.
L'utilitaire scds_fm_action() met à jour l'état de la ressource en le faisant passer à SCHA_RSSTATUS_OK, SCHA_RSSTATUS_DEGRADED ou SCHA_RSSTATUS_FAULTED selon l'historique des pannes. Cet état est donc disponible pour la gestion du système de cluster.
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 */