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

Mise en œuvre des méthodes de rappel

Cette rubrique fournit des informations d'ordre général sur la mise en œuvre des méthodes de rappel.

Accès aux informations sur les propriétés de ressource et de groupe de ressources

En règle générale, les méthodes de rappel doivent accéder aux propriétés de la ressource. L'interface APIGR fournit des commandes shell et des fonctions C que vous pouvez utiliser dans les méthodes de rappel pour accéder aux propriétés d'extension définies par l'utilisateur des ressources. Reportez-vous aux pages man scha_resource_get(1HA) et scha_resource_get(3HA).

La bibliothèque DSDL fournit un ensemble de fonctions C (une par propriété) permettant d'accéder aux propriétés définies par le système et une fonction d'accès aux propriétés d'extension. Reportez-vous aux pages man scds_property_functions(3HA) et scds_get_ext_property(3HA).

Vous ne pouvez pas utiliser le mécanisme de propriété pour enregistrer des données d'état dynamiques pour un service de données car aucune fonction API n'est disponible pour paramétrer les propriétés de ressource (à l'exception de Status et Status_msg). Le cas échéant, il est préférable d'enregistrer les données d'état dynamiques dans des fichiers globaux.


Remarque –

L'administrateur du cluster peut définir certaines propriétés de ressource à l'aide de la commande scrgadm ou par l'intermédiaire d'une interface administrative graphique. Cependant, n'appelez pas scrgadm à partir d'une méthode de rappel car cette commande échoue pendant la reconfiguration du cluster (c'est-à-dire lorsque le gestionnaire RGM appelle la méthode).


Idempotence des méthodes

En règle générale, le gestionnaire RGM n'appelle pas successivement plus d'une fois une méthode sur la même ressource avec les mêmes arguments. Par contre, si une méthode Start échoue, le gestionnaire RGM peut appeler une méthode Stop sur une ressource même si cette dernière n'a jamais été démarrée. De même, le gestionnaire RGM peut exécuter la méthode Stop sur le démon d'une ressource, même si celui-ci s'était déjà arrêté de lui-même. Les mêmes scénarios s'appliquent aux méthodes Monitor_start et Monitor_stop.

C'est pourquoi vous devez intégrer le principe d'idempotence dans vos méthodes Stop et Monitor_stop. Les appels répétés de Stop ou Monitor_stop sur la même ressource avec les mêmes arguments fournissent les mêmes résultats qu'un appel unique.

L'idempotence se caractérise notamment par le fait que l'Arrêt et l'Arrêt_détecteur doivent revenir à 0 (succès) même si la ressource ou le détecteur sont déjà arrêtés ou qu'aucun travail n'est effectué.


Remarque –

Les méthodes Init, Fini, Boot et Update doivent également être idempotentes. Il n'est pas nécessaire qu'une méthode Démarrage soit idempotente.