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

Ce chapitre présente brièvement les interfaces de programmation d'application constituant la bibliothèque de développement de services de données ou BDSD. La BDSD est mise en oeuvre dans la bibliothèque libdsdev.so et incluse dans le package Sun Cluster.

Ce chapitre contient les rubriques suivantes :

• Présentation générale de la BDSD

• Gestion des propriétés de configuration

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

• Mise en oeuvre d'un système de détection des pannes

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

• Débogage de la mise en œuvre d'un type de ressources

Présentation générale de la BDSD

L'interface API de la BDSD est mise en couche au-dessus de l'interface API GR. À ce titre, elle ne remplace pas l'interface API GR mais l'encapsule et étend ses fonctionnalités. La BDSD 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 aux problèmes de haute disponibilité et d'évolutivité intrinsèques de votre application la plus grande partie du temps dédié au développement, sans perdre de temps à intégrer dans Sun Cluster les procédures d'arrêt, de démarrage et de surveillance de l'application.

Gestion des propriétés de configuration

Toutes les méthodes de rappel nécessitent d'accéder aux propriétés de configuration. La BDSD 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. Par conséquent, vous n'avez pas à écrire une fonction d'analyse sur la ligne de commande.

• Configure les structures de données internes que les autres fonctions BDSD vont utiliser. Par exemple, les fonctions de convenance permettant de rechercher et d'extraire les valeurs de propriétés du RGM enregistrent ces valeurs dans ces structures. De même, les valeurs de la ligne de commande, qui sont prioritaires sur les valeurs issues du RGM, sont enregistrées dans ces structures de données.

pour la méthode Validate, scds_initialize analyse les valeurs de propriétés qui sont transférées à la ligne de commande, supprimant ainsi la nécessité d'écrire une fonction d'analyse pour cette méthode.

La fonction scds_initialize initialise également l'environnement de connexion et valide les paramètres de contrôle du système de détection des pannes.

La BDSD offre un ensemble de fonctions permettant de rechercher et d'extraire les propriétés de ressources, de type de ressources et de groupe de ressources, ainsi que les propriétés d'extension fréquemment utilisées. Ces fonctions standardisent l'accès aux propriétés à l'aide des conventions suivantes :

• Chaque fonction exécute uniquement un argument de gestion (retourné par scds_initialize).

• Chaque fonction correspond à une propriété particulière. Le type de valeur retournée de la fonction correspond au type de la valeur de propriété récupéré.

• Les fonctions ne retournent 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.

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

Une méthode Start doit réaliser les actions requises pour démarrer un service de données sur un nœud du cluster. En règle générale, ces actions comprennent la récupération des propriétés de ressource, la localisation des fichiers exécutables et de configuration propres à l'application et le lancement 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 Start peut utiliser les fonctions de convenance des propriétés pour récupérer les valeurs de propriétés spécifiques, comme Confdir_list, servant à identifier les répertoires et les fichiers de configuration de l'application à lancer.

Une méthode Start peut exécuter scds_pmf_start pour lancer une application sous le contrôle de la fonction PMF (Process Monitor Facility). Cette fonction vous permet de spécifier le niveau de surveillance à appliquer au processus et de redémarrer le processus en cas d'échec. Reportez-vous à la rubrique Méthode xfnts_start ; vous y découvrirez un exemple de méthode Start mise en œuvre avec la BDSD.

Une méthode Stop doit être idempotente, ce qui permet de la fermer avec succès même si elle est appelée sur un nœud lorsque l'application ne fonctionne pas. Si la méthode Stop échoue, la ressource arrêtée bascule en mode STOP_FAILED, ce qui engendre une réinitialisation forcée du cluster.

Pour éviter le basculement de la ressource en mode STOP_FAILED, la méthode Stop doit tout mettre en œuvre pour arrêter la ressource. La fonction scds_pmf_stop se caractérise par une tentative d'arrêt de la ressource par phase. Elle tente tout d'abord de l'arrêter à l'aide du signal SIGTERM, puis, en cas d'échec, elle utilise un signal SIGKILL. Reportez-vous à scds_pmf_stop(3HA) pour de plus amples informations.

Mise en oeuvre d'un système de détection des pannes

La BDSD simplifie considérablement la mise en oeuvre d'un système de détection des pannes en fournissant un modèle prédéfini. Une méthode Monitor_start lance le système de détection des pannes, sous le contrôle de la fonction PMF, lors du démarrage de la ressource sur un nœud. Ce système tourne en boucle tant que la ressource est exécutée sur le nœud. La logique de haut niveau d'un système de détection des pannes de la BDSD se présente comme suit :

• La fonction scds_fm_sleep utilise la propriété Intervalle_sonde_complet pour déterminer l'intervalle de temps entre les détections. Tout échec du processus d'application déterminé par la fonction PMF lors de cet intervalle engendre le redémarrage de la ressource.

• La détection elle-même renvoie une valeur indiquant la gravité des échecs : de 0 signifiant l'absence d'échec à 100 pour un échec total.

• La valeur de retour de la détection est transmise à la fonction scds_action qui conserve un historique des échecs cumulatifs dans l'intervalle de la propriété Intervalles_nouvelles_tentatives.

• La fonction scds_action détermine ce que vous devez faire en cas d'échec.

  • Si la gravité de l'échec cumulatif est inférieur à 100, ne faites rien.

  • Si la gravité 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émarrage dépasse la valeur de la propriété Retry_count, dans le délai spécifié par Retry_interval, basculez le service de données.

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

La BDSD offre des fonctions de convenance pour renvoyer les données d'adresse réseau des ressources ou des groupes de ressources. Par exemple, scds_get_netaddr_list recherche et extrait les ressources d'adresse réseau utilisées par une ressource en permettant à un système de détection des pannes d'analyser l'application.

La BDSD comprend également un ensemble de fonctions pour la surveillance TCP. En règle générale, ces fonctions établissent une connexion de prise simple à un service, lisent et écrivent des données sur un service puis assurent la déconnexion du service. Le résultat de la détection peut être transmis à la fonction BDSD scds_fm_action pour déterminer l'action à mettre en œuvre.

Reportez-vous à la rubrique Méthode xfnts_validate pour obtenir un exemple de détection TCP des pannes.

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

La BDSD intègre des fonctions facilitant le débogage de votre service de données.

L'utilitaire BDSD scds_syslog_debug() propose une structure de base pour ajouter des instructions de débogage à la mise en œuvre d'un type de ressources. Le niveau de débogage (compris entre 1 et 9) peut être défini de façon dynamique par la mise en œuvre de types de ressources par noeud du cluster. Toutes les méthodes de rappel du type de ressources lisent le fichier /var/cluster/rgm/rt/nomtr/loglevel (qui contient uniquement un nombre entier compris entre 1 et 9). La routine BDSD scds_initialize() lit ce fichier et définit le niveau de débogage en interne sur le niveau spécifié. Le niveau de débogage par défaut 0 indique que le journal ne contient aucun message de débogage.

La fonction scds_syslog_debug() utilise l'option retournée par la fonction scha_cluster_getlogfacility() comme une priorité de LOG_DEBUG. Vous pouvez configurer ces messages de débogage dans /etc/syslog.conf.

Vous pouvez transformer certains messages de débogage en message d'informations d'une opération standard du type de ressources (notamment au niveau de la priorité LOG_INFO) à l'aide de l'utilitaire scds_syslog. Si vous consultez l'application BDSD modèle dans le Chapitre 8, Mise en œuvre du type de ressource BDSD modèle, vous constaterez que les fonctions scds_syslog_debug et scds_syslog sont utilisées librement.

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

Vous pouvez utiliser le type de ressources HAStoragePlus pour rendre un système de fichiers local hautement disponible dans un environnement Sun Cluster. Les partitions du système de fichiers local doivent se trouver sur les groupes de disques globaux. Vous devez activer les commutations d'affinité et configurer l'environnement Sun Cluster pour prendre en charge le basculement. Ceci permet à l'utilisateur de rendre n'importe quel système de fichiers disponible à n'importe quel hôte connecté directement à ces disques multi-hôtes. 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 de plus amples informations sur la configuration du type de ressources HAStoragePlus dans la rubrique “Enabling Highly Available Local File Systems” du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.