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.