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 oeuvre 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 gestionnaire 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 gestionnaire 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 gestionnaire RGM, sont enregistrées dans ces structures de données.

pour la méthode de Validation, 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 ressource, 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 gestionnaire 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 de Démarrage doit réaliser les actions requises pour démarrer un service de données sur un noeud 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 de Démarrage peut utiliser les fonctions de convenance des propriétés pour récupérer les valeurs de propriétés spécifiques, comme Liste_rép_conf , servant à identifier les répertoires et les fichiers de configuration de l'application à lancer.

Une méthode de Démarrage 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 de démarrage_xfnts ; vous y découvrirez un exemple de méthode de Démarrage mise en oeuvre avec la BDSD.

Une méthode d'Arrêt doit être idempotente, ce qui permet de 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'Arrêt échoue, la ressource arrêtée bascule en mode ÉCHEC_ARRÊT, ce qui engendre une réinitialisation forcée du cluster.

Pour éviter le basculement de la ressource en mode ÉCHEC_ARRÊT, la méthode d'Arrêt doit tout mettre en oeuvre 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 de Démarrage_détecteur 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 noeud. Ce système tourne en boucle tant que la ressource est exécutée sur le noeud. 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é Intervalle_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 est supérieur à la valeur de la propriété Nombre_nouvelles_tentatives dans l'intervalle spécifié par Intervalle_nouvelles_tentatives , 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 oeuvre.

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

Débogage de la mise en oeuvre 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 oeuvre 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 oeuvre 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, 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” in Sun Cluster 3.1 Data Service Planning and Administration Guide.