Quorum et périphériques de quorum

Les noeuds partageant des données et des ressources, il est important que le cluster ne soit jamais divisé en plusieurs partitions actives en même temps. Le moniteur d'appartenance au cluster (MAC) garantit qu'un seul cluster est en fonctionnement, même si l'interconnexion de cluster est partitionnée.

Des partitions de cluster peuvent provoquer deux types de problèmes : le split brain et l'amnésie. Un split brain se produit lorsque l'interconnexion entre les noeuds du cluster est perdue et que celui-ci se partitionne en sous-clusters, tous persuadés d'être une partition unique. Ce phénomène est dû à des problèmes de communication entre les noeuds du cluster. Une amnésie survient lorsque le cluster redémarre après un arrêt avec des données antérieures au moment de l'arrêt. Cette situation peut apparaître si plusieurs versions des données sont stockées sur le disque et qu'une nouvelle représentation du cluster est lancée alors que la dernière version n'est pas disponible.

Le split brain et l'amnésie peuvent être évités en donnant un vote à chaque noeud et en attribuant une majorité de votes à un autre cluster opérationnel. Une partition dotée d'une majorité de votes possède un quorum et est autorisée à fonctionner. Ce mécanisme de votes majoritaires fonctionne bien tant qu'il y a plus de deux noeuds dans le cluster. Dans un cluster à deux noeuds, la majorité est deux. Si ce cluster est partitionné, un vote externe est nécessaire aux partitions pour obtenir un quorum. Ce vote externe est alors fourni par un périphérique de quorum. Un périphérique de quorum peut être n'importe quel disque partagé entre les deux noeuds. Les disques utilisés comme périphériques de quorum peuvent contenir des données utilisateur.

Le Tableau 3–4 décrit comment le logiciel Sun Cluster utilise le quorum pour éviter le split brain et l'amnésie.

Tableau 3–4 Quorum du cluster et problèmes de split-brain et d'amnésie

Type de partition	Solution du quorum
Split brain	Autorise uniquement la partition (sous-cluster) possédant une majorité de votes à fonctionner sur le cluster (où au plus une partition peut exister avec une telle majorité) ; lorsqu'un noeud a perdu la course au quorum, il panique.
Amnésie	Garantit, lors de l'initialisation, que le cluster possède au moins un noeud faisant partie des derniers membres du cluster (possédant donc les données de configuration les plus à jour).

L'algorithme de quorum fonctionne de manière dynamique : comme ce sont les événements du cluster qui déclenchent son calcul, les résultats peuvent varier au cours de la durée de vie du cluster.

Nombre de votes de quorum

Les noeuds du cluster et les périphériques de quorum votent tous pour former un quorum. Par défaut les noeuds du cluster acquièrent un nombre de vote de quorum égal à un lorsqu'ils sont initialisés et deviennent membres du cluster. Les noeuds peuvent aussi avoir un nombre de vote égal à zéro, par exemple, lorsque le noeud est en cours d'installation ou qu'il a été placé à l'état de maintenance par un administrateur.

Les périphériques de quorum acquièrent des votes de quorum en fonction du nombre de noeuds connectés au périphérique. Lorsqu'un périphérique de quorum est défini, il acquiert un maximum de votes égal à N-1 où N est le nombre de noeuds connectés au périphérique de quorum. Par exemple, un périphérique de quorum connecté à deux noeuds avec un nombre de votes égal à zéro possède un nombre de quorums égal à un (deux moins un).

Vous pouvez configurer les périphériques de quorum au cours de l'installation du cluster ou ultérieurement à l'aide des procédures décrites dans le Guide d'administration système de Sun Cluster 3.1.

---

Remarque :

un périphérique de quorum ne participe au compte de votes que si au moins un des noeuds auquel il est rattaché est un membre du cluster. Ainsi, durant l'initialisation du cluster, un périphérique de quorum ne participe au compte que si au moins un des noeuds auquel il est rattaché s'initialise et était un membre du dernier cluster initialisé lorsqu'il a été arrêté.

---

Configurations du quorum

Les configurations du quorum dépendent du nombre de noeuds du cluster.

• Clusters à deux noeuds : deux votes de quorum sont nécessaires pour former un cluster à deux noeuds. Ces deux votes peuvent venir des deux noeuds du cluster ou juste d'un seul noeud et d'un périphérique de quorum. Néanmoins, un périphérique de quorum doit être configuré dans un cluster à noeuds pour assurer qu'un seul noeud puisse continuer si l'autre tombe en panne.

• Clusters à plus de deux noeuds : vous devez spécifier un périphérique de quorum entre chaque paire de noeuds partageant l'accès à un boîtier de stockage de disques. Prenez par exemple un cluster à trois noeuds similaire à celui présenté dans la Figure 3–3. Sur cette figure, le noeudA et le noeudB partagent l'accès au même boîtier de disques, et le noeudB et le noeudC partagent l'accès à un autre boîtier de disques. Il y a un total de cinq votes de quorum, trois venant du noeud et deux des périphériques de quorum partagés entre les noeuds. Un cluster a besoin de la majorité des votes de quorum pour être formé.

  La spécification d'un périphérique de quorum entre chaque paire de noeuds partageant un accès à un boîtier de stockage de disques n'est pas requise par Sun Cluster ni obligatoire. Toutefois, elle peut apporter les votes de quorum requis lorsqu'une configuration N+1 dégénère en cluster à deux noeuds et que le noeud ayant accès aux deux boîtiers de disques tombe également en panne. Si vous avez configuré des périphériques de quorum entre toutes les paires, le noeud restant peut encore fonctionner comme cluster.

  Reportez-vous à la Figure 3–3 pour consulter des exemples de ces configurations.

Figure 3–3 Exemples de configurations de périphériques de quorum

Directives s'appliquant au quorum

Pour installer des périphériques de quorum, suivez les directives suivantes :

• Établissez un périphérique de quorum entre tous les noeuds rattachés au même boîtier de stockage de disques. Ajoutez un disque comme périphérique de quorum dans le boîtier partagé pour assurer, en cas d'échec d'un noeud, que les autres peuvent maintenir le quorum et contrôler les groupes de périphériques de disques du boîtier partagé.

• Vous devez connecter le périphérique de quorum à au moins deux noeuds.

• Un périphérique de quorum peut être n'importe quel disque SCSI-2 ou SCSI-3 utilisé comme périphérique de quorum à deux accès. Les disques connectés à plus de deux noeuds doivent prendre en charge la réservation de groupe persistante (PGR) de SCSI-3, qu'ils soient ou non utilisés comme périphériques de quorum. Reportez-vous au chapitre concernant la planification dans le Guide d'installation du logiciel Sun Cluster 3.1 pour de plus amples informations.

• Un disque contenant des données utilisateur peut être utilisé comme périphérique de quorum.

Séparation en cas d'échec

Une panne entraînant la partition du cluster (appelée split brain) est un des problèmes majeurs que peut rencontrer un cluster. Lorsque ce phénomène se produit, tous les noeuds ne peuvent pas communiquer, ainsi, des noeuds individuels ou des sous-ensembles de noeuds risquent de tenter de former des clusters individuels ou des sous-ensembles. Chaque sous-ensemble ou partition peut croire qu'elle est la seule à être propriétaire des disques multihôtes et à en posséder l'accès. Si plusieurs noeuds tentent d'écrire sur les disques, les données peuvent être altérées.

La séparation en cas d'échec limite l'accès des noeuds aux disques multihôtes en les empêchant physiquement d'accéder aux disques. Lorsqu'un noeud quitte le cluster (parce qu'il a échoué ou a été partitionné), la séparation en cas d'échec assure qu'il ne peut plus accéder aux disques. Seuls les membres actuels des noeuds ont accès aux disques, garantissant ainsi l'intégrité des données.

Les services des périphériques de disques intègrent des capacités de basculement pour les services utilisant les disques multihôtes. Lorsqu'un membre du cluster fonctionnant comme noeud principal (propriétaire) du groupe de périphériques de disques échoue ou devient inaccessible, un nouveau noeud principal est choisi pour prendre le relais et accéder au groupe de périphériques de disques avec un minimum d'interruption. Au cours de ce processus, l'ancien noeud principal doit renoncer à l'accès aux périphériques avant que le nouveau noeud principal puisse être démarré. Toutefois, lorsqu'un membre se détache du cluster et n'est plus joignable, le cluster ne peut pas informer ce noeud de libérer les périphériques dont il était le noeud principal. Il faut donc trouver un moyen de permettre aux membres survivants d'accéder aux périphériques globaux et d'en prendre le contrôle à la place des membres défectueux.

Ce moyen, le système SunPlex le trouve dans la fonction de séparation en cas d'échec du mode de réservation des disques SCSI. Grâce au système de réservation SCSI, les noeuds défectueux sont « isolés » à l'extérieur des disques multihôtes, pour les empêcher d'accéder à ces disques.

Le système de réservation de disques SCSI-2 prend en charge un type de réservation pouvant soit donner accès à tous les noeuds reliés aux disques (lorsqu'aucune réservation n'est en place), soit restreindre l'accès à un seul noeud (détenant la réservation).

Lorsqu'un membre détecte qu'un autre noeud ne communique plus sur l'interconnexion du cluster, il lance une procédure de séparation en cas d'échec pour empêcher le noeud d'accéder aux disques partagés. En présence d'une séparation en cas d'échec, il est normal que le noeud séparé panique et que des messages indiquant un « conflit de réservation » apparaissent sur sa console.

Le conflit de réservation a lieu parce qu'après qu'un noeud a été détecté comme n'appartenant plus au cluster, une réservation SCSI est placée sur l'ensemble des disques partagés entre ce noeud et les autres noeuds. Le noeud séparé n'est peut-être pas conscient de son état et s'il essaie d'accéder à un des disques partagés, il détecte la réservation et panique.

Mécanisme failfast pour séparation en cas d'échec

Le mécanisme par lequel le cluster assure qu'un noeud défectueux ne se réinitialise pas et ne commence pas à écrire sur le stockage partagé est appelé failfast .

Les noeuds membres du cluster activent en permanence un ioctl spécifique, MHIOCENFAILFAST, pour les disques auxquels ils ont accès, notamment les disques de quorum. Cet ioctl est une directive adressée au pilote de disques, il donne au noeud la capacité de paniquer au cas où il ne pourrait accéder à un disque parce que ce dernier a été réservé par d'autres noeuds.

Avec MHIOCENFAILFAST, le pilote contrôle le retour d'erreur de toutes les opérations de lecture et d'écriture qu'un noeud réalise sur le disque pour le code d'erreur Reservation_Conflict. L'ioctl, en arrière-plan, lance périodiquement une opération de test sur le disque pour détecter la présence de Reservation_Conflict. Les chemins de flux de contrôle de premier plan et d'arrière plan paniquent tous deux si le code Reservation_Conflict est renvoyé.

Pour les disques SCSI-2, les réservations ne sont pas persistantes ; elles ne survivent pas aux réinitialisations des noeuds. Pour les disques SCSI-3 dotés de la fonction PGR (réservation de groupe persistante), les informations de réservation sont stockées sur le disque et persistent après réinitialisation des noeuds. Le mécanisme failfast fonctionne de la même manière avec des disques SCSI-2 ou SCSI-3.

Si un noeud perd la connectivité aux autres noeuds du cluster et qu'il ne fait pas partie d'une partition pouvant atteindre un quorum, il est supprimé de force du cluster par un autre noeud. Un autre noeud faisant partie de la partition et pouvant atteindre un quorum place les réservations sur les disques partagés, et lorsque le noeud ne possédant pas de quorum tente d'accéder aux disques partagés, il reçoit un conflit de réservation et panique du fait de la présence du mécanisme failfast.

Après la panique, le noeud peut soit se réinitialiser et tenter de rejoindre le cluster, soit rester sur l'invite de la PROM OpenBoot (OBP). L'action retenue est déterminée par la définition du paramètre auto-boot? de l'OBP.