Ce chapitre présente les interfaces de programmation d'application constituant la bibliothèque de développement de services de données (DSDL). La DSDL est mise en oeuvre dans la bibliothèque libdsdev.so et est incluse dans le package Sun Cluster.
Ce chapitre contient les rubriques suivantes :
L'API de la DSDL est mise en couche au-dessus de l'interface de programmation de l'application de gestion des ressources (APIGR). À ce titre, elle ne remplace pas l'APIGR mais l'encapsule et étend ses fonctionnalités. La DSDL simplifie le développement de services de données en offrant des solutions prédéfinies en fonction de problèmes d'intégration spécifiques dans Sun Cluster. Par conséquent, vous pouvez consacrer la majeure partie du temps de développement aux problèmes de haute disponibilité et d'évolutivité intrinsèques à votre application. De cette manière, vous perdez moins de temps à intégrer dans Sun Cluster les procédures de démarrage, d'arrêt et de surveillance de l'application.
Toutes les méthodes de rappel nécessitent l'accès aux propriétés de configuration. La DSDL prend en charge l'accès aux propriétés en :
Analysant l'environnement.
Offrant un ensemble de fonctions de convenance permettant de rechercher et d'extraire les valeurs de propriétés.
La fonction scds_initialize() à exécuter au début de chaque méthode de rappel :
Contrôle et traite les arguments de la ligne de commande (argc et argv[]) que le RGM transfère à la méthode de rappel, ce qui vous évite d'avoir à écrire une fonction d'analyse de la ligne de commande.
Configure les structures de données internes que les autres fonctions DSDL vont utiliser. Par exemple, les fonctions de convenance permettant de rechercher et d'extraire les valeurs de propriétés du gestionnaire RGM enregistrent ces valeurs dans ces structures. De la même manière, les valeurs de la ligne de commande, qui sont prioritaires sur les valeurs issues du gestionnaire RGM, sont enregistrées dans ces structures de données.
Initialise l'environnement de connexion et valide les paramètres de contrôle du détecteur de pannes.
Pour la méthode Validate, scds_initialize () analyse les valeurs de propriété qui sont transmises sur la ligne de commande, ce qui vous évite d'avoir à écrire une fonction d'analyse pour Validate.
La DSDL offre un ensemble de fonctions permettant de rechercher et d'extraire les propriétés de types de ressource, de ressources et de groupes de ressources, ainsi que les propriétés d'extension couramment utilisées. Ces fonctions normalisent l'accès aux propriétés à l'aide des conventions suivantes :
Chaque fonction ne prend en charge qu'un argument de gestion (renvoyé par scds_initialize()).
Chaque fonction correspond à une propriété particulière. Le type de valeur renvoyée de la fonction correspond au type de la valeur de propriété récupérée.
Les fonctions ne renvoient pas d'erreurs, les valeurs ayant été précalculées par scds_initialize(). Les fonctions récupèrent les valeurs dans le RGM à moins qu'une nouvelle valeur soit passée sur la ligne de commande.
Une méthode de Start effectue les opérations nécessaires pour démarrer un service de données sur un noeud de cluster. En général, ces opérations incluent l'extraction des propriétés de ressource, la localisation des fichiers exécutables et de configuration spécifiques à l'application, et le démarrage de l'application à l'aide des arguments de ligne de commande appropriés.
La fonction scds_initialize() recherche et extrait la configuration des ressources. La méthode de Start peut utiliser les fonctions de convenance des propriétés pour extraire les valeurs de propriétés spécifiques, telles que Confdir_list, qui permettent d'identifier les répertoires et les fichiers de configuration de l'application à lancer.
Une méthode de Start peut appeler scds_pmf_start() pour lancer une application sous le contrôle du gestionnaire de processus (PMF). Le PMF vous permet de spécifier le niveau de surveillance à appliquer au processus et permet de redémarrer le processus en cas d'échec. La section Méthode Démarrage_xfnts présente un exemple de méthode de Start mise en oeuvre avec la DSDL.
Une méthode d'Stop doit être idempotente pour que l'on puisse la fermer avec succès, même si elle est appelée sur un noeud lorsque l'application ne fonctionne pas. Si la méthode d'Stop échoue, la ressource qui est arrêtée passe à l'état STOP_FAILED, ce qui peut entraîner le cluster à effectuer un redémarrage brutal.
Pour éviter que la ressource ne passe à l'état STOP_FAILED, la méthode d' Stop doit tout mettre en oeuvre pour arrêter la ressource. La fonction scds_pmf_stop() permet une tentative d'arrêt de la ressource par phase. Elle tente d'abord de l'arrêter à l'aide d'un signal SIGTERM et, en cas d'échec, elle utilise un signal SIGKILL. Pour plus d'informations, reportez-vous à la page de manuel scds_pmf_stop(3HA).
La DSDL simplifie grandement la mise en oeuvre d'un détecteur de pannes en fournissant un modèle prédéfini. Une méthode Monitor_start démarre le détecteur de pannes, sous le contrôle du gestionnaire de processus, lorsque la ressource démarre sur un noeud. Le détecteur de pannes fonctionne en boucle tant que la ressource est exécutée sur le noeud. La logique de haut niveau d'un détecteur de pannes de la DSDL est la suivante :
La fonction scds_fm_sleep() utilise la propriété Thorough_probe_interval pour déterminer l'intervalle de temps entre les détections. Tout échec du processus de l'application détecté par le gestionnaire de processus au cours de cet intervalle entraîne un redémarrage de la ressource.
La sonde elle-même renvoie une valeur qui indique la gravité des échecs : de 0 en l'absence d'échec à 100 en cas d'échec total.
Cette valeur est envoyée à la fonction scds_action(), qui conserve un historique des échecs cumulatifs dans l'intervalle de la propriété Retry_interval.
La fonction scds_action() indique ce qu'il faut faire en cas d'échec :
Si la gravité de l'échec cumulatif est inférieure à 100, ne faites rien.
Si la valeur de l'échec cumulatif atteint 100 (échec total), redémarrez le service de données. Si Intervalle_nouvelles_tentatives est dépassé, réinitialisez l'historique.
Si le nombre de redémarrages est supérieur à la valeur de la propriété Retry_count dans l'intervalle spécifié par Retry_interval, procédez au basculement du service de données.
La DSDL dispose de fonctions de convenance pour renvoyer les données d'adresse réseau des ressources et des groupes de ressources. Par exemple, scds_get_netaddr_list() recherche et extrait les ressources d'adresse réseau utilisées par une ressource, permettant ainsi à un détecteur de pannes d'analyser l'application.
La DSDL comprend également un ensemble de fonctions pour la surveillance TCP. En général, ces fonctions établissent une connexion de prise simple à un service, lisent et écrivent des données sur ce service, et se déconnectent du service. Le résultat de la détection peut être envoyé à la fonction scds_fm_action() de la DSDL pour déterminer l'action à mettre en oeuvre.
La section Méthode xfnts_validate présente un exemple de détection TCP des pannes.
La DSDL offre des fonctions intégrées pour vous aider à déboguer votre service de données.
L'utilitaire DSDL scds_syslog_debug() propose une structure de base pour ajouter des instructions de débogage à la mise en oeuvre d'un type de ressources. Le niveau de débogage (nombre compris entre 1 et 9) peut être défini de manière dynamique pour chaque mise en oeuvre de type de ressource sur chaque noeud de cluster. Un fichier nommé /var/cluster/rgm/rt/rtname/loglevel, qui ne contient qu'un nombre entier compris entre 1 et 9, est lu par toutes les méthodes de rappel du type de ressource. La fonction DSDL scds_initialize() lit ce fichier et définit le niveau de débogage en interne au niveau spécifié. Le niveau 0 de débogage par défaut indique que le service de données ne consigne pas les messages de débogage.
La fonction scds_syslog_debug() utilise l'option renvoyée par la fonction scha_cluster_getlogfacility() comme une priorité de LOG_DEBUG. Vous pouvez configurer ces messages de débogage dans le fichier /etc/syslog.conf.
Vous pouvez convertir certains messages de débogage en messages d'information pour les opérations courantes du type de ressource (notamment au niveau de la priorité LOG_INFO) à l'aide de la fonction scds_syslog(). Notez que l'exemple d'application DSDL du Chapitre 8, Mise en oeuvre du type de ressource DSDL modèle utilise librement les fonctions scds_syslog_debug() et scds_syslog().
Vous pouvez utiliser le type de ressource HAStoragePlus pour rendre un système de fichiers locaux hautement disponible au sein d'un environnement Sun Cluster. Les partitions du système de fichiers local doivent se trouver sur les groupes de disques globaux. Les commutations d'affinité doivent être activées, et l'environnement Sun Cluster doit être configuré de manière à prendre en charge le basculement. Cette configuration permet à l'administrateur du cluster de rendre tout système de fichiers situé sur des disques multi-utilisateur accessible par tout hôte directement connecté à ces disques. Nous vous recommandons fortement d'utiliser un système de fichiers local hautement disponible pour certains services de données à fort pourcentage d'E/S. Vous trouverez des informations sur la configuration du type de ressource HAStoragePlus dans la section Enabling Highly Available Local File Systems du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.