Structure à haute disponibilité

Grâce au système Sun Cluster, tous les composants qui se trouvent sur le « chemin » reliant les utilisateurs aux données, y compris les interfaces réseau, les applications elles-mêmes, le système de fichiers et les disques multihôtes, sont hautement disponibles. Un composant du cluster est dit hautement disponible s'il est capable de survivre à toute panne (matérielle ou logicielle) unique du système.

Le tableau suivant affiche les types de panne des composants Sun Cluster (tant matériels que logiciels) et les types de récupération intégrés à la structure à haute disponibilité :

La structure à haute disponibilité du logiciel Sun Cluster détecte rapidement une panne de nœud et crée un serveur équivalent pour les ressources de la structure sur un nœud restant du cluster. Les ressources de la structure ne sont jamais toutes indisponibles en même temps. Celles qui ne sont pas affectées par une panne de nœud restent totalement disponibles pendant la récupération. En outre, celles du nœud défectueux redeviennent disponibles dès que la récupération est terminée. Une ressource de la structure récupérée n'a pas à attendre la récupération de toutes les autres.

La plupart des ressources de la structure à haute disponibilité sont récupérées de façon transparente pour les applications (services de données) les utilisant. La sémantique d'accès aux ressources de la structure est totalement préservée après l'échec d'un nœud. Les applications ne peuvent pas détecter que le serveur des ressources de la structure a été déplacé sur un autre nœud. La panne d'un nœud unique est complètement transparente pour les programmes des nœuds restants utilisant les fichiers, périphériques et volumes de disques connectés à ce nœud. Cette transparence est possible s'il existe un autre chemin matériel vers les disques d'un autre nœud. On peut par exemple utiliser des périphériques multihôtes ayant des ports connectés à plusieurs nœuds.

Moniteur d'appartenance au cluster

Pour assurer que les données ne s'altèrent pas, tous les nœuds doivent arriver à un accord cohérent sur l'appartenance au cluster. Si nécessaire, le moniteur d'appartenance au cluster coordonne la reconfiguration des services (applications) du cluster en réponse à une panne.

Le MAC reçoit des informations sur la connectivité aux autres nœuds depuis la couche de transport intracluster. Il utilise l'interconnexion du cluster pour échanger des informations d'état au cours d'une reconfiguration.

Après avoir détecté une modification d'appartenance au cluster, le CMM effectue une configuration synchronisée du cluster. Dans une configuration synchronisée, les ressources du cluster peuvent être redistribuées, en fonction de la nouvelle appartenance au cluster.

Contrairement aux versions précédentes du logiciel Sun Cluster, le CMM s'exécute entièrement dans le noyau.

Pour plus d'informations sur la protection du cluster contre le partitionnement en plusieurs clusters distincts, voir À propos de la séparation en cas d'échec .

Mécanisme failfast

Si le CMM détecte un problème crucial sur un nœud, il demande à la structure du cluster de l'arrêter de force et de le supprimer de l'appartenance au cluster. Ce mécanisme d'arrêt et de suppression est appelé failfast. Il entraîne l'arrêt d'un nœud de deux façons.

• Si un nœud quitte le cluster puis tente de démarrer un nouveau cluster sans avoir de quorum, il est « séparé » pour être empêché d'accéder aux disques partagés. Pour plus d'informations sur l'utilisation du mécanisme failfast, voir À propos de la séparation en cas d'échec .

• Si un ou plusieurs démons propres au cluster meurent (clexecd, rpc.pmfd, rgmd ou rpc.ed), la panne est détectée par le CMM et le nœud panique.

Lorsque la mort d'un démon de cluster provoque la panique d'un nœud, un message semblable au suivant s'affiche sur la console correspondant à ce nœud.

panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

Après la panique, le nœud peut redémarrer et tenter de rejoindre le cluster. Si le cluster est composé de systèmes SPARC, le nœud peut rester à l'invite de la PROM OpenBoot^TM. L'action suivante du nœud est déterminée par la définition du paramètre auto-boot?. Vous pouvez le définir avec eeprom(1M) à l'invite ok de la PROM OpenBoot.

Référentiel de configuration du cluster (CCR)

Le CCR utilise un algorithme de validation à deux phases pour les mises à jour : une mise à jour doit être effectuée sur tous les membres de cluster, faute de quoi elle est annulée. Le CCR utilise l'interconnexion du cluster pour appliquer les mises à jour distribuées.

Le CCR est constitué de fichiers texte, mais vous ne devez jamais les modifier manuellement. Chaque fichier contient une somme de contrôle enregistrée pour assurer la cohérence entre les nœuds. Une mise à jour manuelle de ces fichiers peut provoquer l'arrêt d'un nœud ou de l'ensemble du cluster.

Le CCR s'appuie sur le moniteur d'appartenance pour garantir qu'un cluster ne fonctionne que si un quorum a été atteint. Il est chargé de vérifier la cohérence des données au sein du cluster, d'effectuer des récupérations lorsque cela s'aèvre nécessaire et de faciliter les mises à jour des données.