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 :
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.
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 :
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 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.
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 :
Dans le cas de la création d'une ressource, elle 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 la ressource sont donc disponibles pour le développeur du type de ressource comme si la ressource avait déjà été créée dans le système.
Dans le cas de la mise à jour d'une ressource ou d'un groupe de ressources, les valeurs proposées pour les propriétés mises à jour par l'administrateur sont lues depuis la ligne de commande, et les autres propriétés (dont les valeurs ne sont pas modifiées) sont lues depuis Sun Cluster à l'aide de l'API de gestion des ressources. Un développeur du type de ressource utilisant BDSD ne doit pas se préoccuper de ces tâches administratives. La validation d'une ressource peut s'effectuer comme si toutes les propriétés de la ressource étaient à la disposition du développeur.
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.
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.
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 :
La méthode Stop doit être idempotente parce qu'elle peut être appelée par le RGM même si la méthode Start n'a pas fonctionné correctement sur le nœud. Par conséquent, la méthode Stop doit réussir (valeur 0) même si l'application ne tourne pas sur le noeud du cluster et n'a aucune tâche à accomplir.
Si la méthode Stop du type de ressource échoue (valeur différente de 0) sur un nœud du cluster, la ressource arrêtée se retrouve à l'état STOP_FAILED. En fonction du paramètre Mode_basculement de la ressource, il est possible que cela entraîne un redémarrage abrupt du nœud du cluster par le RGM. Il est donc important de concevoir la méthode Stop de manière qu'elle tente vraiment d'arrêter l'application, même en y mettant fin brutalement (par exemple, à l'aide d'un signal SIGKILL) si toutes les autres tentatives se soldent par un échec. Il convient également de s'assurer qu'elle le fasse en temps utile, étant donné que la structure traite l'expiration du Stop_timeout comme un échec de l'arrêt et fait donc passer la ressource à l'état STOP_FAILED.
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.
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.
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.
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.
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 :
Intervalle_sonde_complet ;
Nombre_nouvelles_tentatives ;
Intervalle_nouvelles_tentatives ;
Nombre_nouvelles_tentatives_détecteur ;
Intervalle_nouvelles_tentatives_détecteur ;
Délai_sonde.
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).
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.
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 :
Surveillance périodique de la santé de l'application gérée. Cet aspect particulier du démon du détecteur dépend fortement de l'application et peut varier considérablement d'un type de ressource à l'autre. La BDSD présente certaines fonctions intégrées permettant de contrôler la santé de services simples basés sur le protocole TCP. Les applications mettant en œuvre des protocoles basés sur le langage ASCII tels que HTTP, NNTP, IMAP et POP3 peuvent être mises en œuvre à l'aide de ces utilitaires.
Conservation d'une trace des problèmes rencontrés par l'application utilisant les propriétés de ressource Intervalle_nouvelles_tentatives et Nombre_nouvelles_tentatives. Décision concernant l'attitude à adopter en cas d'échec : le script d'action du gestionnaire de processus doit-il redémarrer le service ou les échecs de l'application se sont-ils accumulés si rapidement qu'un basculement doit être envisagé ? Les utilitaires scds_fm_action() et scds_fm_sleep () de la BDSD sont destinés à vous aider à mettre ce mécanisme en œuvre.
Prise des mesures appropriées (généralement, redémarrer l'application ou tenter de basculer le groupe contenant la ressource). L'utilitaire BDSD scds_fm_action() met en œuvre un tel algorithme. Il calcule l'accumulation actuelle des échecs de sonde au cours du délai Intervalle_nouvelles_tentatives (secondes) défini dans ce but.
Mise à jour de l'état des ressources de manière à ce que la commande scstat puisse accéder à l'état de santé de l'application, tout comme l'IUG de la gestion du cluster.
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 :
La détection de la mort du processus de l'application par le biais de la fonction scds_fm_sleep () est assez rapide, étant donné que sa notification par le gestionnaire de processus est asynchrone. Comparez ce cas à celui où un détecteur de pannes s'active au bout d'un délai donné pour vérifier la santé du service et constate la mort de l'application. Le délai de détection des pannes se trouve considérablement réduit, ce qui permet d'accroître la disponibilité du service.
Si le RGM rejette la tentative de basculement du service par le biais de l'API scha_control(3HA), scds_fm_action() réinitialise (oublie) son historique des pannes actuel. La raison en est que l'historique des pannes se situe déjà au-delà de Nombre_nouvelles_tentatives, et si le démon du détecteur s'active au cours de l'itération suivante et est incapable de contrôler la santé du démon, il essaie à nouveau d'appeler la fonction scha_control(), nouvelle tentative vouée à l'échec étant donné que la situation ayant donné lieu au 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 corriger 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 pannes de l'application dans le cas d'un échec du redémarrage, étant donné que l'utilisateur tente généralement d'utiliser scha_control() rapidement si la situation ne se règle pas d'elle-même.
L'utilitaire scds_fm_action() met à jour l'état des ressources en le faisant passer à SCHA_RSSTATUS_OK, SCHA_RSSTATUS_DEGRADED ou SCHA_RSSTATUS_FAULTED, sur la base de 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 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 */ |