Annexe B Détection des défaillances de Sun Cluster

Cette annexe décrit la détection des défaillances pour Sun Cluster et traite des thèmes suivants :

• "Aperçu de la détection de défaillances"

• "Surveillance du réseau public (PNM)"

• "Vérification des défaillances de Sun Cluster"

• "Vérification des défaillances propres à un service de données"

Cette section présente un aperçu de la détection de défaillances par Sun Cluster. Cette détection de défaillances englobe trois méthodes générales :

• Un mécanisme de pulsation

• Une surveillance des défaillances des réseaux

• Une surveillance des défaillances de services de données particuliers

La surveillance des défaillances effectue des vérifications de validité afin de s'assurer que la responsabilité du problème est imputée au noeud défectueux et non au noeud fonctionnel.

Certains renseignements présentés sont propres à cette version de Sun Cluster, et peuvent changer au fur et à mesure que le produit évolue. Les estimations de temps précisées pour la détection des diverses défaillances sont approximatives et ne visent qu'à donner des indications du comportement général de Sun Cluster. Ce document n'est pas un manuel relatif au fonctionnement logique interne de Sun Cluster ; il ne décrit pas non plus une interface de programmation.

Aperçu de la détection de défaillances

Tel que mentionné à la section d'architecture de base de Sun Cluster, lorsqu'un serveur tombe en panne, l'autre serveur prend la relève. Un point important reste à déterminer : comment le serveur sait-il que l'autre est en panne ?

Sun Cluster emploie trois méthodes de détection des défaillances.

• Pulsation et surveillance du lien AGC - Ces moniteurs se servent des liens privés. Pour Ethernet, il existe deux moniteurs : un moniteur de lien AGC et un moniteur d'appartenance à la grappe. Pour SCI, on compte trois moniteurs : un moniteur de lien AGC, un moniteur d'appartenance à la grappe et un moniteur de pulsation SCI de bas niveau.

• Surveillance des défaillances du réseau - Toutes les connexions des serveurs au réseau public sont vérifiées : si un serveur n'est pas en mesure de communiquer par l'entremise du réseau public en raison d'une anomalie matérielle ou logicielle, un autre serveur de l'ensemble de serveurs prend la relève.

• Vérification des défaillances propre à un service de données - Chaque service de données de Sun Cluster effectue la détection de défaillances qui lui est propre. Cette dernière méthode consiste à déterminer si le service de données effectue des tâches utiles et pas seulement à savoir si l'ordinateur et le système d'exploitation semblent fonctionner.

Dans le cas des deuxième et troisième méthodes, un serveur vérifie si l'autre serveur envoie une réponse. Après avoir détecté une anomalie apparente, le serveur qui effectue la surveillance réalise différentes vérifications de validité sur lui-même avant de prendre, de force, la relève de l'autre serveur. Ces vérifications de validité visent à s'assurer que le problème qui touche le serveur qui effectue la vérification n'est pas la cause de l'absence de réponse de l'autre serveur. Ces vérifications de validité sont réalisées par hactl(1M), un sous-programme de bibliothéque qui fait partie de l'environnement de base de Sun Cluster. Ainsi, le code de détection de défaillances propre à un service de données n'a qu'à lancer la commande hactl(1M) pour effectuer les vérifications de validité du serveur qui effectue la vérification. (Pour plus de détails, consultez la page de manuel hactl(1M).)

Mécanisme de pulsation : moniteur d'appartenance à la grappe

Sun Cluster utilise un mécanisme de pulsation. Le traitement des pulsations est assuré par un processus en temps réel à priorité élevé qui est fixé en mémoire ; ainsi, il n'est pas soumis à l'échange de pages. Ce processus est appelé moniteur d'appartenance à la grappe. Dans une liste ps(1), son nom est clustd.

Chaque serveur envoie le message "Tout va bien", ou une pulsation, sur les deux liens privés, environ toutes les deux secondes. De plus, chaque serveur est à l'écoute des messages de pulsation émis par les autres serveurs, sur les deux liens privés. La réception de la pulsation sur un des liens privés suffit pour indiquer qu'un autre serveur fonctionne. Un serveur détermine qu'un autre serveur est en panne s'il ne reçoit pas de message de pulsation provenant de ce serveur pendant une période suffisante, soit environ 12 secondes.

Dans la stratégie globale de détection de défaillances, le mécanisme de pulsation du moniteur d'appartenance à la grappe est le moyen de première intervention. En cas d'absence de pulsation, les pannes du matériel et les anomalies du système d'exploitation sont immédiatement détectées. Il est également possible de détecter les problèmes globaux du système d'exploitation, par exemple la disparition du contenu de tous les tampons de communication. Le mécanisme de pulsation est également la méthode de détection de défaillances la plus rapide de Sun Cluster. Etant donné que le moniteur d'appartenance à la grappe fonctionne en temps réel et qu'il est fixé en mémoire, un court délai d'absence de pulsation est acceptable. En revanche, pour les autres méthodes de détection de défaillances, Sun Clusterne doit pas indiquer qu'un serveur est en panne si celui-ci est tout simplement lent. Pour ces méthodes, on définit des délais relativement longs, équivalents à plusieurs minutes et, dans certains cas, deux dépassements ou plus du délai accordé sont requis pour que Sun Cluster prenne la relève.

Puisque le moniteur d'appartenance à la grappe tourne en temps réel et est fixé en mémoire, il se peut, paradoxalement, que le moniteur d'appartenance fonctionne même si son serveur n'effectue aucune tâche utile relative aux services de données. D'où l'utilité de la surveillance des défaillances propre à un service de données, décrite dans "Vérification des défaillances propres à un service de données".

Vérification de validité du noeud qui effectue la vérification

La vérification des défaillances du réseau et la vérification des défaillances propre à un service de données exige de chaque noeud qu'il vérifie si un autre noeud envoie une réponse. Avant de prendre la relève, le noeud qui effectue la surveillance réalise différentes vérifications de validité élémentaires sur lui-même. Ces vérifications visent à s'assurer que le problème n'est pas imputable au noeud qui effectue la surveillance. Il s'agit également de faire en sorte que la relève du serveur qui semble être défectueux permette réellement d'améliorer la situation. Si on ne procède pas aux vérifications de validité, des relèves erronées risquent de se produire. Autrement dit, un noeud en panne pourrait, à tort, indiquer qu'un autre noeud n'envoie pas de réponse et prendre la relève du serveur qui fonctionne bien.

Le noeud qui effectue la vérification effectue les vérifications de validité suivantes sur lui-même avant de prendre la relève d'un autre noeud :

• Le noeud qui effectue la vérification détermine sa propre capacité à utiliser le réseau public (voir "Surveillance du réseau public (PNM)").

• Le noeud qui effectue la vérification détermine également si ses propres services de données HD répondent. Tous les services de données HD qui sont exécutés par le noeud effectuant la vérification sont également contrôlés. Si l'un d'eux ne répond pas, la relève est interdite, selon l'hypothèse que le noeud qui effectue la vérification ne pourra pas faire tourner les services d'un autre noeud s'il n'arrive pas à exécuter les siens. De plus, l'absence de réponse de la part des services de données HD du noeud qui effectue la vérification peut indiquer que celui-ci a un problème sous-jacent pouvant provoquer l'échec de vérification de l'autre noeud. Sun Cluster HA pour NFS offre un exemple de ce phénomène : pour verrouiller un fichier sur un autre noeud, les démons lockd et statd du noeud qui effectue la vérification doivent fonctionner. En vérifiant la réponse de ses démons lockd et statd, le noeud qui effectue la vérification peut déterminer que l'absence de réponse de la part de ses propres démons est la cause de l'absence de réponse de l'autre noeud.

Surveillance du réseau public (PNM)

L'élément PNM a deux fonctions principales :

• Surveiller l'état des adaptateurs configurés d'un noeud et signaler les pannes générales des adaptateurs ou du réseau.

• Effectuer une reprise transparente en faveur d'autres adaptateurs de relève d'un noeud en cas de panne de l'adaptateur principal.

La PNM est mise en oeuvre à titre de démon (pnmd) qui recueille périodiquement les statistiques du réseau sur l'ensemble des interfaces de réseau public d'un noeud. Si les résultats indiquent des anomalies, pnmd tente d'identifier une des situations suivantes :

• Le réseau est au repos.

• Le réseau est en panne.

• L'interface réseau est en panne.

La PNM envoie ensuite une commande ping multidestinataires. La PNM place les résultats de ses recherches dans le CCD et compare les résultats locaux aux résultats d'autres noeuds (qui sont également placés dans le CCD). Cette comparaison sert à déterminer si le réseau est en panne ou si l'interface réseau est défectueuse. Si la PNM établit que l'interface réseau est défectueuse et que des adaptateurs de secours sont configurés, elle assure la reprise pour l'adaptateur réseau.

Le ping multidestinataires établi par la PNM pourrait ne pas être compris par certains composants matériels non-Sun présents dans la configuration. Ainsi, devez-vous connecter directement un dispositif de réseau Sun au réseau que vous surveillez.

Les résultats de la surveillance PNM sont utilisés par diverses entités. La composante de reprise de l'adaptateur réseau de la PNM se sert des résultats de la surveillance pour déterminer si le recours à un adaptateur de reprise est justifié. Par exemple, si le réseau est en panne, aucune reprise d'adaptateur n'est effectuée. Les moniteurs de défaillances associés aux services de données HD SC et la commande API hactl utilisent la fonction PNM pour déterminer la cause de la panne des services de données. Les informations produites par PNM servent à établir s'il convient de transférer le service de données ainsi que l'emplacement du service de données après le transfert.

Les messages syslog enregistrés par la fonction PNM suite à la détection de pannes d'adaptateur sont lus par le gestionnaire SC, qui les traduit en icônes graphiques affichées par l'entremise de l'interface utilisateur graphique.

Il est également possible de lancer les utilitaires PNM depuis la ligne de commande afin de déterminer l'état des composants réseau. Pour de plus amples renseignements, consultez les pages de manuel pnmset(1M), pnmstat(1M), pnmptor(1M) pnmrtop(1M), et pnmd(1M).

Vérification des défaillances de Sun Cluster

PNM vérifie l'état du réseau public et commande un passage aux connexions de secours au besoin. Toutefois, en cas d'impossibilité complète d'accéder au réseau public, PNM n'assure pas la reprise pour les services de données ou les hôtes logiques. En pareil cas, PNM signale l'anomalie, mais il incombe à un vérificateur des défaillances externe de prendre en charge la commutation entre les noeuds de secours.

Si vous utilisez VxVM comme gestionnaire de volumes, l'environnement Sun Cluster est responsable de la surveillance de chaque groupe de sauvegarde de reprise d'adaptateur réseau (NAFO) défini par hôte logique, ainsi que de la mise en branle d'une commutation vers un noeud de secours, lorsque l'une des situations suivantes survient :

• Aucun accès au réseau public n'est possible (aucun groupe de sauvegarde NAFO n'est disponible) et le noeud de secours dispose d'au moins un groupe NAFO.

• L'accès au réseau public est en partie interrompu -- au moins un groupe de sauvegarde NAFO est encore actif lorsque plus d'un groupe (plusieurs sous-réseaux) est défini pour un hôte logique -- et le noeud de secours dispose d'un nombre supérieur de groupes de sauvegarde NAFO valides et actifs.

Si aucune de ces conditions n'existe, Sun Clusterne commande pas de commutation.

Si vous utilisez Solstice DiskSuite comme gestionnaire de volumes, la perte de l'accès au réseau public entraîne l'interruption du noeud déconnecté ; en outre, les hôtes logiques qui ont ce noeud pour maître sont transférés au noeud de secours.

L'environnement Sun Cluster ne surveille les réseaux publics que si la configuration comprend un hôte logique et qu'un service de données est "activé" et enregistré sur cet hôte logique. Seuls les groupes de sauvegarde NAFO utilisés par un hôte logique sont surveillés.

Vérification des défaillances propres à un service de données

La vérification des défaillances propre à un service de données découle du fait que, même si le noeud serveur et le système d'exploitation tournent, les logiciels ou le matériel peuvent être dans un état tel qu'aucune tâche utile ne peut être exécutée par les services de données. Dans l'environnement global, la panne totale du noeud ou du système d'exploitation est détectée par le mécanisme de pulsation du moniteur d'appartenance à la grappe. Toutefois, un noeud peut fonctionner suffisamment bien pour que le mécanisme de pulsation continue à être exécuté même si le service de données n'effectue aucune tâche utile.

En revanche, la vérification des défaillances propre à un service de données ne doit pas forcément détecter la panne d'un noeud ou l'arrêt de l'envoi, par celui-ci, de messages de pulsation à la grappe. On présume que le moniteur d'appartenance à la grappe détecte ces anomalies et que la vérification des défaillances des services de données ne contient aucun processus pour remédier à ces situations.

Une vérification des défaillances de service de données agit comme un client du service de données. Une vérification des défaillances qui tourne sur un ordinateur surveille le service de données exporté par cet ordinateur et, ce qui est plus important encore, le service de données exporté par un autre serveur. Un serveur en panne n'est pas suffisamment fiable pour détecter ses propres anomalies : ainsi, chaque serveur surveille un autre noeud en plus de se vérifier lui-même.

En plus de se comporter comme un client, la vérification des défaillances propre à un service de données se sert également, dans certains cas, des statistiques du service de données pour déterminer si des tâches utiles sont exécutées ou non. Une vérification peut en outre détecter la présence de certains processus cruciaux pour un service de données particulier.

En général, la vérification des défaillances réagit à l'absence de service en commandant à un serveur de prendre la relève d'un autre serveur. Dans certains cas, la vérification des défaillances tente d'abord de redémarrer le service de données sur l'ordinateur initial avant de commander la relève. Si plusieurs redémarrages ont lieu à l'intérieur d'une brève période, on considère que cet ordinateur a des problèmes graves. En pareil cas, la relève par un autre serveur a lieu immédiatement, sans qu'un autre redémarrage local ne soit tenté.

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

Le serveur de surveillance effectue deux types de vérification périodique du service NFS d'un autre serveur.

1. Le serveur qui effectue la vérification envoie l'indication NULL RPC à tous les processus démons du noeud cible qui doivent assurer un service NFS ; ces démons sont rpcbind, mountd, nfsd, lockd et statd.

2. Le serveur qui effectue la vérification effectue un essai bout en bout : il tente de monter un système de fichiers NFS depuis l'autre noeud, puis de lire et d'écrire un fichier dans ce système de fichiers. Il réalise cet essai bout en bout pour chaque système de fichiers que l'autre noeud partage actuellement. Etant donné que le montage est coûteux, on y a recours moins souvent qu'aux autres vérifications.

Si une de ces vérifications repère une anomalie, le noeud qui effectue la vérification envisagera la possibilité de prendre la relève du noeud en utilisation. Toutefois, certaines conditions peuvent empêcher la relève d'avoir lieu immédiatement :

• Délai de grâce pour redémarrage local - Avant d'effectuer la relève, le noeud qui effectue la vérification attend pendant une courte période :

  • Afin que le noeud défectueux puisse prendre connaissance de son anomalie et remédier à la situation en redémarrant localement ses propres démons

  • Afin que le noeud défectueux puisse réduire sa charge de travail (dans le cas où il serait simplement surchargé)

Après cette attente, le vérificateur effectue une nouvelle vérification et il ne commande la relève que si une anomalie est signalée. En général, deux dépassements du délai imparti, en ce qui concerne la vérification, sont requis pour qu'une relève ait lieu, afin de tenir compte des serveurs lents.

• Réseaux publics multiples - Si l'autre noeud est relié à plusieurs réseaux publics, le noeud qui effectue la vérification vérifie au moins deux de ceux-ci.

• Verrous - Certains utilitaires de sauvegarde emploient la fonction lockfs(1M), qui interdit différents types de mises à jour d'un système de fichiers, afin que la sauvegarde puisse prendre un instantané d'un système de fichiers demeurant inchangé. Malheureusement, dans l'environnement NFS, la commande lockfs(1M) signale que le système de fichiers est inaccessible. Ainsi, le message suivant apparaît à l'intention des clients NFS : Le serveur NFS ne répond pas. Avant d'effectuer la relève, le noeud qui effectue la vérification interroge l'autre noeud afin de déterminer si le système de fichiers est en mode lockfs et, si c'est le cas, la relève est interdite. La relève est interdite parce que la commande lockfs est une composante normale de tout processus administratif de sauvegarde. Précisons que les utilitaires de sauvegarde n'utilisent pas tous lockfs. Certains permettent en effet au service NFS de continuer sans interruption.

• Démons - L'absence de réponse de la part des démons lockd et statd n'entraîne pas une relève. Les démons lockd et statd assurent, de concert, le verrouillage réseau des fichiers NFS. Si ces démons n'envoient pas de réponse, la situation est simplement consignée dans syslog, et aucune relève n'a lieu. lockd et statd, dans le cadre de leurs tâches normales, doivent effectuer des RPC des ordinateurs clients, de sorte qu'un client en panne ou partitionné puisse provoquer l'arrêt de lockd et statd pendant une période prolongée. Ainsi, un client défectueux peut faire croire que lockd et statd sont en panne sur le serveur. Par ailleurs, si une relève de la part du serveur qui effectue la vérification a lieu, ce serveur sera sans doute interrompu de la même façon par le client défectueux. Dans le modèle actuel, un client défectueux ne provoque pas de relève erronée.

Suite à l'exécution de ces essais propres à Sun Cluster HA pour NFS, le processus d'établissement de la pertinence d'une relève se poursuit par des appels de la commande hactl(1M) (voir "Vérification de validité du noeud qui effectue la vérification").

Le serveur qui effectue la vérification vérifie également son propre service NFS. La logique employée est semblable à celle des essais de l'autre serveur, mais au lieu de prendre la relève, des messages d'erreur sont consignés dans syslog, et on tente de redémarrer les démons dont les processus n'existent plus. Autrement dit, le redémarrage d'un processus démon n'est effectué que si ce processus est terminé ou en panne. Le redémarrage d'un processus démon n'est pas tenté si ce processus existe toujours mais ne répond pas, car il faudrait alors mettre un terme au démon sans savoir quelles structures de données il met à jour. En outre, aucun redémarrage n'est tenté si le dernier redémarrage local a eu lieu récemment (il y a moins d'une heure). L'autre serveur reçoit plutôt l'indication d'envisager une relève (pourvu que cet autre serveur réussisse ses vérifications de validité). Enfin, le démon rpcbind n'est jamais redémarré, car aucun moyen ne permet d'informer les processus qui étaient inscrits sous rpcbind qu'ils doivent se réinscrire.

Vérification des défaillances SGBD-HD

Les vérifications des défaillances de Sun Cluster HA pour Oracle, Sun Cluster HA pour Sybase et Sun Cluster HA pour Informix surveillent de façon semblable le serveur de base de données. Les vérifications des défaillances du SGBD-HD se configurent par le lancement d'un des utilitaires, soit haoracle(1M), hasybase(1M) soit hainformix(1M). (Pour une description détaillée des options de ces utilitaires, voir les pages de manuel en ligne.)

Une fois que les utilitaires ont été configurés et activés, deux processus sont démarrés sur le noeud local, et deux autres sont lancés sur le noeud à distance, simulant ainsi un accès client. Le vérificateur de défaillances distant est amorcé par le démon ha_dbms_serv et démarré lorsque hareg -y dataservicename est lancé.

Le module SGBD-HD se sert de deux méthodes pour déterminer si le service SGBD est disponible. Tout d'abord, SGBD-HD extrait des données du SGBD lui-même :

• Sous Oracle, le tableau V$SYSSTAT est consulté.

• Sous Sybase, les variables globales @@io_busy, @@pack_received, @@pack_sent, @@total_read, @@total_write et @@connections sont consultées.

• Sous Informix, le tableau SYSPROFILE est consulté.

Si les données extraites révèlent que des tâches sont exécutées pour des clients, aucune autre vérification du SGBD n'est effectuée. Ensuite, si les données du SGBD précisent qu'aucune tâche n'est réalisée, SGBD-HD présente une petite transaction d'essai au SGBD. Si tous les clients sont au repos, les données du SGBD indiquent qu'aucune tâche n'est exécutée. Autrement dit, la transaction d'essai fait la distinction entre une panne de la base de données et une situation de repos normale. Etant donné que la transaction d'essai n'est exécutée que si les données indiquent qu'aucune activité n'a lieu, elle n'impose aucune charge additionnelle si la base de données est active. La transaction d'essai consiste à :

• Créer un tableau portant le nom HA_DBMS_REM ou HA_DBMS_LOC

• Entrer des valeurs dans le tableau créé

• Mettre à jour la valeur introduite

• Effacer le tableau créé

SGBD-HD filtre minutieusement les codes d'erreur produits par le SGBD, à l'aide d'un tableau qui précise les codes qui doivent provoquer ou non une relève. Par exemple, dans le cas de Sun Cluster HA pour Oracle, une condition table space full (espace de tableau plein) ne provoque pas une relève, car un administrateur doit intervenir pour remédier à la situation. (Si une relève avait lieu, le nouveau serveur maître se buterait au même problème, soit table space full.)

En revanche, si un code d'erreur tel que could not allocate Unix semaphore (impossible d'allouer le sémaphore UNIX) survient, Sun Cluster HA pour Oracle tente de redémarrer ORACLE localement sur ce serveur. Si un redémarrage local a eu lieu récemment, l'autre ordinateur prend plutôt la relève (après avoir réussi ses propres vérifications de validité).

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.

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

La vérification des défaillances de Sun Cluster HA pour Lotus comporte deux éléments -- une vérification locale qui tourne sur le noeud où les processus du serveur Lotus Domino s'exécutent actuellement, et une vérification à distance qui tourne sur tous les autres noeuds qui sont des maîtres possibles de l'hôte logique du serveur Lotus Domino.

Les deux vérifications se servent d'une connexion Telnet simple avec le port Lotus Domino afin de vérifier l'état du serveur Domino. Si une vérification n'arrive pas à se connecter, elle lance une reprise ou une relève en appelant la commande hactl(1M).

La vérification des défaillances locale peut effectuer trois redémarrages locaux avant de lancer une reprise. Le mécanisme de redémarrage local utilise un algorithme de fenêtre de temps coulissante. Ainsi, une reprise n'a lieu que si le nombre maximal de tentatives de cette fenêtre est atteint.

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

Sun Cluster HA pour Tivoli ne se sert que d'une vérification des défaillances locale. Celle-ci tourne sur le noeud où le répartiteur d'objets Tivoli, soit le démon oserv, s'exécute actuellement.

La vérification des défaillances se sert de la commande Tivoli wping pour vérifier l'état du démon oserv observé. Les situations suivantes peuvent faire échouer la commande wping du démon oserv :

• Le démon oserv surveillé ne tourne pas.

• Le démon oserv du serveur se termine pendant la surveillance d'un démon oserv client.

• Les rôles Tivoli adéquats (autorisation) n'ont pas été définis pour l'utilisateur administratif. Pour plus de détails sur Tivoli, voir le Sun Cluster 2.2 Software Installation Guide.

Si la vérification locale n'arrive pas à détecter le démon oserv à l'aide de la commande ping, elle lance une reprise en appelant la commande hactl(1M). La vérification des défaillances effectue un redémarrage local avant de lancer une reprise.

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

La vérification des défaillances de Sun Cluster HA pour SAP surveille la disponibilité de l'instance Centrale, particulièrement le serveur de messagerie, le serveur de mise en file d'attente et le répartiteur. La vérification ne surveille que le noeud local en vérifiant la présence de processus SAP cruciaux. Elle utilise également l'utilitaire SAP lgtst pour vérifier s'il est possible de joindre le serveur de messagerie.

Dès qu'une anomalie est détectée, par exemple lorsqu'un processus se termine prématurément ou lorsque la commande lgtst signale une erreur, la vérification des défaillances tentera d'abord de redémarrer SAP sur le noeud local un certain nombre de fois (ce nombre est défini à l'aide de la commande hadsconfig(1M)). Si le nombre de redémarrages défini par l'utilisateur a été épuisé, la vérification des défaillances lance une commutation en appelant la commande hactl(1M), si cette instance a été configurée afin de permettre une reprise (également modifiable à l'aide de la commande hadsconfig(1M)). L'instance Centrale est arrêtée avant que la commutation n'ait lieu, puis elle est redémarrée sur le noeud distant une fois que la commutation a été effectuée.

Affichage des messages LOG_DB_WARNING pour la vérification SAP

Le paramètre Sun Cluster HA pour SAP LOG_DB_WARNING détermine si les messages d'avertissement doivent ou non être affichés lorsque le système de vérification de Sun Cluster HA pour SAP ne peut se connecter à la base de données. Lorsque LOG_DB_WARNING est défini sur y et que le système de vérification ne peut se connecter à la base de données, un message est créé au niveau avertissement de la fonction locale0 Par défaut, le démon syslogd(1M) n'affiche pas ces messages sur /dev/console ou sur /var/adm/messages. Pour les visualiser, vous devez modifier le fichier /etc/syslog.conf afin d'afficher les messages de priorité local0.warning. Par exemple :

...
*.err;kern.notice;auth.notice;local0.warning /dev/console
*.err;kern.debug;daemon.notice;mail.crit;local0.warning /var/adm/messages
...

Après avoir modifié le fichier, vous devez relancer syslogd(1M). Pour plus d'informations, consultez les pages syslog.conf(1M) et syslogd(1M) du manuel.