Structure à haute disponibilité

Le système SunPlex rend tous les composants du « chemin d'accès » reliant les utilisateurs aux données hautement disponibles, y compris les interfaces réseaux, les applications elles-mêmes, le système de fichiers et les périphériques multihôtes. Un composant du cluster est dit hautement disponible s'il est capable de survivre à toute panne (matérielle ou logicielle) unique du système.

Vous trouverez dans le tableau les types de pannes de SunPlex (matérielles et logicielles) et les types de récupération intégrés à la structure à haute disponibilité.

La structure à haute disponibilité de Sun Cluster détecte rapidement l'échec d'un nœud et crée un nouveau serveur équivalent pour les ressources de la structure sur un autre nœud. Les ressources de la structure ne sont jamais toutes indisponibles en même temps. Celles n'ayant pas été affectées par l'échec d'un nœud sont totalement disponibles durant 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 s'aperçoivent simplement pas que le serveur de la ressource a été déplacé vers un autre nœud. L'échec d'un seul nœud est totalement transparent pour les programmes sur les autres nœuds utilisant les fichiers, les périphériques et les volumes de disques rattachés à ce nœud, tant qu'il existe un autre chemin d'accès matériel aux disques depuis 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 être sur 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 du cluster. 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, le MAC réalise une configuration synchronisée du cluster, au cours de laquelle les ressources peuvent être redistribuées en fonction de la nouvelle appartenance au cluster.

Contrairement à certaines versions antérieures du logiciel Sun Cluster, le MAC s'exécute entièrement dans le noyau.

Reportez-vous à la rubrique À propos de la séparation en cas d'échec pour de plus amples informations sur la manière dont le cluster s'autoprotège d'un partitionnement en plusieurs clusters distincts.

Mécanisme failfast

Si le MAC détecte un problème critique sur un nœud, il fait appel à la structure du cluster pour arrêter le nœud de force (panique) et le supprimer de l’appartenance au cluster. Le mécanisme par lequel ce processus intervient est appelé failfast. Il provoque l'arrêt d'un nœud de deux manières.

• Si un nœud quitte le cluster puis tente de démarrer un nouveau cluster sans avoir de quorum, on le « sépare » pour l'empêcher d'accéder aux disques partagés. Reportez-vous à la rubrique À propos de la séparation en cas d'échec pour de plus amples informations sur l'utilisation du mécanisme failfast.

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

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 soit se réinitialiser et tenter de rejoindre le cluster, soit rester sur l'invite de la PROM OpenBoot^TM (OBP) si le cluster est constitué de systèmes SPARC. L'action entreprise est déterminée par la définition du paramètre auto-boot?. Vous pouvez définir auto-boot? avec eeprom(1M), à l'invite ok de la PROM OpenBoot.

Cluster Configuration Repository (CCR)

Le CCR utilise un algorithme de validation à deux phases pour les mises à jour : si une mise à jour ne se déroule pas correctement sur tous les membres du cluster, elle est réexécuté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 nécessaire et de faciliter les mises à jour des données.