Vérification des défaillances de Sun Cluster HA pour Netscape

Les moniteurs de défaillances de tous les services de données Sun Cluster HA pour Netscape ont recours à une méthode commune de surveillance de l'instance du service. Ils utilisent tous la surveillance des défaillances à distance et locale.

Le moniteur de défaillances qui tourne sur le noeud qui est actuellement le maître de l'hôte logique sur lequel le service de données s'exécute est appelé le moniteur de défaillances local. Le moniteur de défaillances qui tourne sur un noeud pouvant être le maître de l'hôte logique est appelé un moniteur de défaillances distant.

Les moniteurs de défaillances de Sun Cluster HA pour Netscape effectuent périodiquement une opération de service de données simple avec le serveur. Si cette opération échoue ou dépasse le délai accordé, on considère qu'il y a une anomalie.

Si une vérification échoue, la vérification des défaillances locale tente de redémarrer localement le service de données. En général, cette mesure suffit pour rétablir le service de données. La vérification à distance conserve un dossier des échecs de la vérification, mais elle ne met en branle aucune mesure. Suite à deux échecs successifs de la vérification (ce qui indique que le redémarrage du service de données n'a pas permis de corriger le problème), la vérification à distance lance la commande hactl(1M) en mode "relève" afin d'amorcer la reprise de l'hôte logique. Certains services de données Netscape utilisent un algorithme de fenêtre coulissante des réussites et des échecs des vérifications : si un nombre prédéterminé d'échecs survient dans la fenêtre, la vérification prend des mesures.

Vous pouvez utiliser la commande hadsconfig(1M) pour ajuster les valeurs d'intervalle de vérification et de délai des moniteurs de défaillances de Sun Cluster HA pour Netscape. Si vous réduisez l'intervalle de vérification des défaillances, la détection des anomalies est plus rapide, mais vous risquez de provoquer des reprises erronées en raison de problèmes passagers. Par ailleurs, si vous diminuez la valeur du délai de vérification, la détection des anomalies se rapportant au service de données est plus rapide, mais vous risquez de provoquer des reprises erronées si le service de données est simplement occupé en raison d'une charge importante. Dans la plupart des cas, les valeurs par défaut de ces paramètres sont adéquates. Ces paramètres sont décrits à la page de manuel hadsconfig(1M) ainsi qu'aux sections de configuration du chapitre consacré à chaque service de données dans le Sun Cluster 2.2 Software Installation Guide.

Vérification des défaillances de Sun Cluster HA pour DNS

La vérification des défaillances de Sun Cluster HA pour DNS effectue une opération nslookup afin de déterminer l'état du serveur Sun Cluster HA pour DNS. Elle recherche le nom de domaine de l'hôte logique Sun Cluster HA pour DNS dans le serveur Sun Cluster HA pour DNS. Selon la configuration de votre fichier /etc/resolv.conf, nslookup peut contacter d'autres serveurs si le serveur Sun Cluster HA pour DNS principal est en panne. Ainsi, l'opération nslookup peut réussir même si le serveur Sun Cluster HA pour DNS principal est en panne. Pour prévenir cette situation, la vérification des défaillances détermine si les réponses proviennent du serveur Sun Cluster HA pour DNS principal ou d'autres serveurs.

Vérification des défaillances de Sun Cluster HA pour Netscape HTTP

La vérification des défaillances de Sun Cluster HA pour Netscape HTTP vérifie l'état du serveur http en tentant de se relier à celui-ci, à l'adresse de l'hôte logique figurant sur le port configuré. Précisons que le moniteur de défaillances se sert du numéro du port spécifié pour hadsconfig(1M) lors de la configuration de l'instance du service nshttp.

Vérification des défaillances de Sun Cluster HA pour Netscape News

La vérification des défaillances de Sun Cluster HA pour Netscape News détermine l'état du serveur de nouvelles en se reliant à celui-ci, à l'adresse IP de l'hôte logique et au numéro de port nntp. Puis, elle tente de lancer la commande date NNTP sur le serveur de nouvelles et vérifie si la réponse du serveur lui parvient à l'intérieur du délai précisé pour la vérification.

Vérification des défaillances de Sun Cluster HA pour Netscape Mail ou du serveur de messagerie

La vérification des défaillances de Sun Cluster HA pour Netscape Mail ou du serveur de messagerie détermine l'état du serveur de courrier ou de messagerie en le vérifiant sur les trois ports de service pris en charge par le serveur, soit SMTP, IMAP et POP3 :

• SMTP (port 25) -- Exécute un message "hello" SMTP sur le serveur puis lance la commande quit.

• IMAP (port 143) -- Exécute la commande CAPABILITY IMAP4 suivie de la commande LOGOUT IMAP4.

• POP3 (port 110) -- Exécute la commande quit.

Pour tous ces essais, la vérification des défaillances prévoit de recevoir en réponse une chaîne du serveur, à l'intérieur du délai de vérification. Précisons que si la vérification détecte une anomalie sur l'un des trois ports de service ci-dessus, on estime que le serveur est en panne. Afin d'éviter les reprises erronées, la vérification des défaillances nsmail fait appel à un algorithme de fenêtre coulissante pour effectuer le suivi des échecs et des réussites de la vérification. Si le nombre d'échecs précisés dans la fenêtre coulissante est supérieur au nombre prédéterminé, la vérification à distance commande une relève.

Vérification des défaillances de Sun Cluster HA pour Netscape LDAP

La vérification locale de Sun Cluster HA pour Netscape LDAP peut effectuer un nombre variable de redémarrages locaux avant d'amorcer une reprise. Le mécanisme de redémarrage local se sert d'un algorithme de fenêtre coulissante. Ainsi, une reprise n'a lieu que si le nombre maximal de tentatives de cette fenêtre est atteint.

La vérification à distance de Sun Cluster HA pour Netscape LDAP utilise une connexion Telnet simple avec le port LDAP pour vérifier l'état du serveur. Le numéro du port LDAP est celui qui est précisé à l'installation à l'aide de hadsconfig(1M).

La vérification locale :

• Vérifie le serveur en lançant un script de surveillance. Le script recherche le nom LDAP commun "moniteur". Le nom commun est défini par le serveur de répertoires et il n'est utilisé que pour la surveillance. La vérification se sert de l'utilitaire ldapsearch pour effectuer cette opération.

• Tente de redémarrer le serveur localement suite à la détection d'une anomalie du serveur.

• Lance la commande hactl(1M) en mode abandon après avoir décidé que le noeud local ne peut pas lancer en toute confiance le serveur de répertoires, tandis que la vérification à distance lance la commande hactl(1M) en mode relève. Si l'hôte logique peut avoir plusieurs maîtres, toutes les vérifications à distance exécutent l'opération de relève à l'unisson. Toutefois, après la relève, l'environnement sous-jacent s'assure qu'un noeud maître unique est choisi pour le serveur de répertoires.