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.