Conception du démon du détecteur de pannes

Les mises en oeuvre du type de ressource utilisant la BDSD possèdent généralement un démon du détecteur de pannes assumant les responsabilités suivantes :

• Surveillance périodique de la santé de l'application gérée. Cet aspect particulier du démon du détecteur dépend fortement de l'application et peut varier considérablement d'un type de ressource à l'autre. La BDSD présente certaines fonctions intégrées permettant de contrôler la santé de services simples basés sur le protocole TCP. Les applications mettant en oeuvre des protocoles basés sur le langage ASCII tels que HTTP, NNTP, IMAP et POP3 peuvent être mises en oeuvre à l'aide de ces utilitaires.

• Conservation d'une trace des problèmes rencontrés par l'application utilisant les propriétés de ressource Intervalle_nouvelles_tentatives et Nombre_nouvelles_tentatives. Décision concernant l'attitude à adopter en cas d'échec : le script d'action du gestionnaire de processus doit-il redémarrer le service ou les échecs de l'application se sont-ils accumulés si rapidement qu'un basculement doit être envisagé ? Les utilitaires scds_fm_action() et scds_fm_sleep () de la BDSD sont destinés à vous aider à mettre ce mécanisme en oeuvre.

• Prise des mesures appropriées (généralement, redémarrer l'application ou tenter de basculer le groupe contenant la ressource). L'utilitaire BDSD scds_fm_action() met en oeuvre un tel algorithme. Il calcule l'accumulation actuelle des échecs de sondage au cours du délai Intervalle_nouvelles_tentatives (secondes) défini dans ce but.

• Mise à jour de l'état des ressources de manière à ce que la commande scstat puisse accéder à l'état de santé de l'application, tout comme l'IUG de la gestion du cluster.

Les utilitaires BDSD sont conçus de manière à ce que la boucle principale du démon du détecteur de pannes soit représentée par le pseudo-code suivant :

Pour les détecteurs de pannes mis en oeuvre par le biais de BDSD :

• La détection de la mort du processus de l'application par le biais de la fonction scds_fm_sleep () est assez rapide, étant donné que sa notification par le gestionnaire de processus est asynchrone. Comparez ce cas à celui où un détecteur de pannes s'active au bout d'un délai donné pour vérifier la santé du service et constate la mort de l'application. Le délai de détection des pannes se trouve considérablement réduit, ce qui permet d'accroître la disponibilité du service.

• Si le RGM rejette la tentative de basculement du service par le biais de l'API scha_control(3HA), scds_fm_action() réinitialise (oublie) son historique des pannes actuel. La raison en est que l'historique des pannes se situe déjà au-delà de Nombre_nouvelles_tentatives, et si le démon du détecteur s'active au cours de l'itération suivante et est incapable de contrôler la santé du démon, il essaie à nouveau d'appeler la fonction scha_control(), nouvelle tentative vouée à l'échec étant donné que la situation ayant donné lieu au rejet au cours de la dernière itération perdure. La réinitialisation de l'historique garantit que le détecteur de pannes tente au moins de corriger la situation localement (par exemple, par le biais d'un redémarrage de l'application) au cours de l'itération suivante.

• scds_fm_action() ne réinitialise pas l'historique des pannes de l'application dans le cas d'un échec du redémarrage, étant donné que l'utilisateur tente généralement d'utiliser scha_control() rapidement si la situation ne se règle pas d'elle-même.

• L'utilitaire scds_fm_action() met à jour l'état des ressources en le faisant passer à SCHA_RSSTATUS_OK, SCHA_RSSTATUS_DEGRADED ou SCHA_RSSTATUS_FAULTED, sur la base de l'historique des pannes. Cet état est donc disponible pour la gestion du système de cluster.

Dans la plupart des cas, le contrôle de santé spécifique à l'application peut être mis en oeuvre dans un utilitaire autonome distinct (svc_probe(), par exemple) et intégré à cette boucle principale générique :

for (;;) {

   / * Sommeil pendant la durée de l'intervalle Intervalle_sonde_complet
   *  entre des sondages successifs. */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));

   /* Sonde de toutes les adresses IP utilisées. Passage en boucle sur :
   * 1. Toutes les ressources net utilisées.
   * 2. Toutes les adresses IP d'une ressource donnée.
   * Pour chacune des adresses sondées,
   * calcul de l'historique des pannes. */
   probe_result = 0;
   /* Itération dans toutes les ressources pour obtenir toutes
    * les adresses IP à utiliser pour l'appel de svc_probe() */
   pour (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Obtention du nom de l'hôte et du port dont
   * la santé doit être surveillée.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS ne prend en charge qu'un seul port et
   * obtient donc la valeur du port à partir de la
   * première entrée du tableau des ports.
   */
   ht1 = gethrtime(); /* Latch probe start time */
   probe_result = svc_probe(scds_handle,

   hostname, port, timeout);
   /*
   * Mise à jour de l'historique des sondages du service,
   * action si nécessaire.
   * Blocage de l'heure de fin du sondage.
   */
   ht2 = gethrtime();
   /* Conversion en milisecondes */
   dt = (ulong_t)((ht2 - ht1) / 1e6);

   /*
   * Calcul de l'historique des pannes et
   * action si nécessaire
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Chaque ressource net */
   }       /* Toujours continuer le sondage */