Guide du développeur de services de données Sun Cluster pour SE Solaris

Chapitre 6 Bibliothèque de développement de services de données

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 :

Présentation générale de la DSDL

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.

Gestion des propriétés de configuration

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 :

La fonction scds_initialize() à exécuter au début de chaque méthode de rappel :


Remarque –

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 :

Démarrage et arrêt d'un service de données

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).

Mise en oeuvre d'un détecteur de pannes

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 :

Accès aux données d'adresse réseau

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.

Débogage de la mise en oeuvre d'un type de ressources

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().

Activation des systèmes de fichiers locaux à haut niveau de disponibilité

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.