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.