Conception du démon du détecteur de pannes

Les mises en oeuvre du type de ressource qui utilisent la DSDL possèdent généralement un démon de détecteur de pannes qui prend en charge les opérations suivantes :

• Contrôle régulier de l'état de l'application gérée. Cette tâche dépend de l'application et peut varier considérablement d'un type de ressource à un autre. La DSDL contient des fonctions d'utilitaire intégrées qui procèdent à des vérifications d'état pour des services TCP simples. Vous pouvez utiliser ces utilitaires pour mettre en oeuvre des applications qui utilisent des protocoles ASCII, tels que HTTP, NNTP, IMAP et POP3.

• Consignation des problèmes rencontrés par l'application à l'aide des propriétés de ressource Retry_interval et Retry_count . Lorsque l'application est en échec total, le détecteur de pannes doit déterminer si le script d'action du gestionnaire de processus doit redémarrer le service ou si les échecs de l'application se sont accumulés si rapidement qu'il faut procéder à un basculement. Les utilitaires de la DSDL scds_fm_action() et scds_fm_sleep() sont destinés à vous aider à mettre en oeuvre ce mécanisme.

• Prise de mesures appropriées, soit en redémarrant l'application, soit en procédant à une tentative de basculement du groupe de ressources. L'utilitaire scds_fm_action () de la DSDL met en oeuvre cet algorithme. Il calcule l'accumulation actuelle des échecs de sonde au cours du délai Retry_interval (en secondes) défini dans ce but.

• Mise à jour de l'état de la ressource, de manière à ce que la commande scstat et l'interface utilisateur graphique de gestion du cluster puissent connaître l'état de l'application.

Les utilitaires de la DSDL sont conçus de manière à ce que la boucle principale du démon du détecteur de pannes puisse être représentée par le pseudo code que vous trouverez à la fin de cette section.

Gardez les éléments suivants à l'esprit lorsque vous mettez en oeuvre un détecteur de pannes avec la DSDL :

• La mort du processus de l'application est détectée assez rapidement par la fonction scds_fm_sleep(), car sa notification par le gestionnaire de processus est asynchrone. Le temps de détection des pannes s'en trouve réduit de manière significative, ce qui augmente la disponibilité du service. Autrement, le détecteur de pannes risquerait de se réactiver régulièrement pour vérifier l'état d'un service et constaterait que le processus de l'application est mort.

• Si le RGM rejette la tentative de basculement du service à l'aide de l'API scha_control, la fonction scds_fm_action() réinitialise, ou oublie, son historique des pannes actuel. La raison en est que son historique dépasse déjà Retry_count. Si le démon du détecteur s'active au cours de l'itération suivante et est incapable de contrôler l'état du démon, il tente à nouveau d'appeler la fonction scha_control(). Cet appel est probablement rejeté une fois de plus, étant donné que la situation qui a entraîné son 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 remédier à 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 échecs de l'application en cas d'échec du redémarrage, étant donné que l'utilisateur tente généralement d'utiliser scha_control() rapidement si la situation ne s'améliore pas d'elle-même.

• L'utilitaire scds_fm_action() met à jour l'état de la ressource en le faisant passer à SCHA_RSSTATUS_OK, SCHA_RSSTATUS_DEGRADED ou SCHA_RSSTATUS_FAULTED selon 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 d'état spécifique à l'application peut être mis en oeuvre dans un utilitaire autonome distinct (svc_probe(), par exemple). Vous pouvez l'intégrer à cette boucle principale générique :

for (;;) {
   /* sleep for a duration of thorough_probe_interval between
   *  successive probes.
   */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));
   /* Now probe all ipaddress we use. Loop over
   * 1. All net resources we use.
   * 2. All ipaddresses in a given resource.
   * For each of the ipaddress that is probed,
   * compute the failure history. 
   */
   probe_result = 0;
   /* Iterate through the all resources to get each
   * IP address to use for calling svc_probe()
   */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Grab the hostname and port on which the
   * health has to be monitored.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS supports only one port and
   * hence obtaint the port value from the
   * first entry in the array of ports.
   */
   ht1 = gethrtime();
   /* Latch probe start time */
   probe_result = svc_probe(scds_handle, hostname, port, timeout);
   /*
   * Update service probe history,
   * take action if necessary.
   * Latch probe end time.
   */
   ht2 = gethrtime();
   /* Convert to milliseconds */
   dt = (ulong_t)((ht2 - ht1) / 1e6);
   /*
   * Compute failure history and take
   * action if needed
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Each net resource */
   }       /* Keep probing forever */