Quorum et périphériques de quorum
Cette section comporte les rubriques suivantes :
Remarque –
Pour connaître la liste des périphériques pris en charge comme périphériques de quorum par le logiciel Sun Cluster, contactez votre fournisseur de services Sun.
Comme les nœuds de cluster partagent des données et des ressources, un cluster ne doit jamais être divisé entre des partitions séparées actives simultanément, au risque d'altérer les données. Le moniteur d'appartenance au cluster (MAC) et l'algorithme de quorum garantissent l'exécution d'une instance au plus du même cluster à un moment donné, même si l'interconnexion de cluster est partitionnée.
Pour plus d'informations sur le quorum et le moniteur d'appartenance au cluster, reportez-vous à Appartenance au cluster du Présentation de Sun Cluster pour SE Solaris.
Deux types de problèmes proviennent des partitions de cluster :
Le Split brain se produit lorsque l'interconnexion de cluster entre les nœuds est perdue et que le cluster se retrouve partitionné en sous-clusters. Chaque partition « croit » être la seule partition, car les nœuds d'une partition ne peuvent pas communiquer avec ceux de l'autre partition.
Une amnésie survient lorsque le cluster redémarre après un arrêt avec des données de configuration antérieures au moment de l'arrêt. Ce problème peut se produire si vous démarrez le cluster sur un nœud qui n'était pas sur la partition de cluster qui fonctionnait en dernier.
Le logiciel Sun Cluster évite les split brain et amnésies en :
-
affectant un vote à chaque nœud ;
-
mandatant une majorité de votes en faveur d'un cluster opérationnel.
Une partition dotée d'une majorité de votes obtient un quorum et est autorisée à fonctionner. Ce mécanisme de vote majoritaire évite les phénomènes de split brain et d'amnésie lorsque plus de deux nœuds sont configurés au sein d'un cluster. Toutefois, le décompte des votes des nœuds seul n'est pas suffisant lorsque plus de deux nœuds sont configurés dans le cluster. Dans un cluster à deux noeuds, la majorité est deux. Si un tel cluster à deux nœuds est partitionné, un vote externe est nécessaire pour que l'une des partitions obtienne le quorum. Ce vote externe est alors fourni par un périphérique de quorum.
À propos des décomptes de votes de quorum
Utilisez la commande scstat -q pour déterminer les informations suivantes :
-
Nombre total de votes configurés
-
Votes présents actuels
-
Votes requis pour le quorum
Pour plus d'informations sur cette commande, reportez-vous à scstat(1M).
Les nœuds comme les périphériques de quorum apportent leurs votes au cluster afin de constituer le quorum.
Un nœud apporte ses votes en fonction de son état :
-
Un nœud apporte un vote lorsqu'il est initialisé et devient membre du cluster.
-
Un nœud apporte zéro vote lors de son installation.
-
Un nœud apporte zéro vote lorsqu'un administrateur système place le nœud à l'état de maintenance.
Les périphériques de quorum apportent des votes en fonction du nombre de votes qui leur sont connectés. Lorsque vous configurez un périphérique de quorum, le logiciel Sun Cluster lui affecte un décompte de votes de N-1, où N correspond au nombre de votes connectés au périphérique de quorum. Par exemple, un périphérique de quorum connecté à deux noeuds avec un nombre de votes différent de zéro possède un nombre de quorums égal à un (deux moins un).
Un périphérique de quorum apporte son vote si l'une des deux conditions suivantes est vérifiée :
-
L'un des nœuds au moins auquel le périphérique de quorum est connecté est membre du cluster.
-
L'un des nœuds au moins auquel le périphérique de quorum est connecté est en cours d'initialisation et ce nœud était membre de la dernière partition de cluster ayant possédé le périphérique de quorum.
Vous pouvez configurer les périphériques de quorum pendant l'installation du cluster ou ultérieurement, à l'aide des procédures décrites dans le Chapitre 5, Administration du quorum du Guide d’administration système de Sun Cluster pour SE Solaris.
À propos de la 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, les nœuds ne peuvent pas tous communiquer, ainsi, des nœuds individuels ou des sous-ensembles de nœuds risquent de tenter de former des clusters individuels ou des sous-ensembles. Chaque partition ou sous-ensemble peut « croire » être seul propriétaire des disques multihôtes et à en posséder l'accès. Si plusieurs nœuds tentent d'écrire sur les disques, les données peuvent être endommagées.
La séparation en cas d'échec limite l'accès des nœuds aux périphériques 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 nœuds 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 des périphériques multihôtes. Si un membre de cluster, actuellement membre principal (propriétaire) du groupe de périphériques de disques échoue ou est inaccessible, un nouveau nœud principal est choisi. Ce nouveau nœud permet d'accéder au groupe de périphériques de disques pour poursuivre en n'étant soumis qu'à des interruptions mineures. Pendant ce processus, l'ancien nœud principal doit perdre l'accès aux périphériques pour que le nouveau nœud 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 nœud de libérer les périphériques dont il était le nœud 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.
Le système Sun Cluster utilise le mode de réservation des disques SCSI pour implémenter la séparation en cas d'échec. Grâce au système de réservation SCSI, les nœuds défectueux sont « isolés » à l'extérieur des périphériques multihôtes, pour les empêcher d'accéder à ces disques.
Les réservations de disques SCSI-2 prennent en charge une forme de réservations qui octroie l'accès à tous les nœuds liés au disque (en cas d'absence de réservation) ou à un seul nœud (celui qui détient 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. Lors de la séparation en cas d'échec, le nœud séparé panique et un message de « conflit de réservation » s'affiche sur la console.
Si un nœud est détecté comme n'étant plus membre de cluster, une réservation SCSI est déclenchée sur tous les disques partagés entre ce nœud et les autres. Le nœud séparé risque de ne pas « savoir » qu'il est en cours de séparation et s'il essaie d'accéder à l'un des disques partagés, il détectera la réservation et s'emballera.
Mécanisme failfast pour la séparation en cas d'échec
On appelle failfast le mécanisme par le biais duquel la structure du cluster s'assure qu'un nœud défectueux ne peut pas redémarrer et commencer à écrire dans le stockage partagé.
Les nœuds 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 disque. Il permet à un nœud de paniquer s'il ne peut pas accéder à un disque réservé par un autre nœud.
L'ioctl MHIOCENFAILFAST provoque la vérification par le pilote de l'erreur renvoyée par toutes les lectures et écritures d'un nœud sur le disque s'il s'agit du code d'erreur Reservation_Conflict . À l'arrière-plan, l'ioctl teste régulièrement le disque pour rechercher le code d'erreur Reservation_Conflict. Les chemins de flux de contrôle au premier plan et à l'arrière-plan paniquent 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 nœuds. 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 façon, que vous ayez des disques SCSI-2 ou SCSI-3.
Si un nœud perd la connectivité aux autres nœuds 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 nœud. Un autre noeud faisant partie de la partition pouvant atteindre le quorum effectue des réservations sur les disques partagés. Si le nœud qui ne possède pas de quorum essaie d'accéder aux disques partagés, il reçoit un conflit de réservation et panique du fait 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 OpenBootTM (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? sur eeprom(1M), à l'invite ok de la PROM OpenBoot dans un cluster SPARC. Vous pouvez également configurer ce paramètre avec l'utilitaire SCSI que vous pouvez exécuter après le démarrage du BIOS dans un cluster x86.
À propos des configurations de quorum
La liste suivante présente des faits concernant les configurations de quorum :
-
Les périphériques de quorum peuvent contenir des données utilisateur.
-
Dans une configuration N+1, où les périphériques de quorum N sont chacun connectés à l'un des 1 par le biais des nœuds N et du nœud N+1, le cluster survit à la mort de tous les 1 par le biais des nœuds N ou de l'un des nœuds N/2. Cette disponibilité suppose que le périphérique de quorum fonctionne correctement.
-
Dans une configuration N-nœud où un seul périphérique de quorum se connecte à tous les nœuds, le cluster peut survivre à la mort d'un des nœuds N-1. Cette disponibilité suppose que le périphérique de quorum fonctionne correctement.
-
Dans une configuration à N nœuds où un périphérique de quorum unique se connecte à tous les nœuds, le cluster peut survivre à la défaillance du périphérique de quorum si tous les nœuds du cluster sont disponibles.
Pour consulter les exemples de configurations de quorum à éviter, voir Configurations de quorum déconseillées . Pour consulter les exemples de configurations de quorum conseillées, voir Configurations de quorum conseillées .
Respect des contraintes des périphériques de quorum
Vous devez respecter les conditions requises suivantes. Si vous ignorez ces conditions, vous risquez de compromettre la disponibilité du cluster.
-
Vérifiez que le logiciel Sun Cluster prend en charge votre périphérique comme périphérique de quorum.
Remarque –Pour connaître la liste des périphériques pris en charge comme périphériques de quorum par le logiciel Sun Cluster, contactez votre fournisseur de services Sun.
Le logiciel Sun Cluster prend en charge deux types de périphérique de quorum :
-
Les disques partagés multihôtes prenant en charge les réservations PGR SCSI-3.
-
Les disques partagés à deux hôtes prenant en charge les réservations SCSI-2.
-
-
Dans une configuration à deux nœuds, vous devez configurer au moins un périphérique de quorum pour garantir qu'un nœud unique puisse continuer en cas de défaillance de l'autre nœud. Reportez-vous à la Figure 3–2.
Pour consulter les exemples de configurations de quorum à éviter, reportez-vous à Configurations de quorum déconseillées . Pour consulter les exemples de configurations de quorum conseillées, voir Configurations de quorum conseillées .
Respect des recommandations portant sur les périphériques de quorum
Utilisez les informations suivantes pour évaluer la configuration de quorum la mieux adaptée à votre topologie :
-
Disposez-vous d'un périphérique pouvant être connecté à tous les nœuds du cluster ?
-
Si oui, configurez ce périphérique comme périphérique de quorum unique. Vous n'êtes pas tenu de configurer un autre périphérique de quorum, car votre configuration est optimale.
Attention – Si vous ne tenez pas compte de ce conseil et ajoutez un autre périphérique de quorum, ce dernier va réduire la disponibilité de votre cluster.
-
Sinon, configurez votre ou vos périphériques sur deux ports.
-
-
Assurez-vous que le nombre total de votes apportés par les périphériques de quorum est strictement inférieur au nombre de votes apportés par les nœuds. Sinon, vos nœuds ne pourraient pas constituer un cluster en cas d'indisponibilité de tous les disques, et ce même si tous les nœuds fonctionnent.
Remarque –Dans certains environnements, vous pouvez réduire la disponibilité globale du cluster en fonction de vos besoins. Dans ces cas-là, vous pouvez ignorer les techniques habituelles préconisées. Soyez conscient toutefois que le non-respect de cette technique conseillée réduit la disponibilité globale. Par exemple, dans la configuration indiquée dans Configurations de quorum atypiques , le cluster est moins disponible : Les votes du quorum excèdent les votes des nœuds. Si l'accès au stockage partagé entre Nodes A et Node B est perdu, tout le cluster échoue.
Pour consulter l'exception à cette recommandation, voir Configurations de quorum atypiques .
-
Spécifiez un périphérique de quorum entre chaque paire de nœuds partageant l'accès au périphérique de stockage. Cette configuration de quorum accélère le processus de séparation en cas d'échec. Voir Quorum dans les configurations supérieures à deux nœuds .
-
En général, si l'ajout d'un périphérique de quorum permet de rendre pair le nombre de votes, la disponibilité globale du cluster diminue.
-
Les périphériques de quorum ralentissement légèrement les reconfigurations suite à l'arrivée ou à la mort d'un nœud. Limitez donc l'ajout de périphériques de quorum au strict minimum.
Pour consulter les exemples de configurations de quorum à éviter, reportez-vous à Configurations de quorum déconseillées . Pour consulter les exemples de configurations de quorum conseillées, reportez-vous à Configurations de quorum conseillées .
Configurations de quorum conseillées
Cette section indique des exemples de configurations de quorum conseillées. Pour consulter les exemples de configurations de quorum à éviter, reportez-vous à Configurations de quorum déconseillées .
Quorum dans les configurations à deux nœuds
Deux votes de quorum sont nécessaires pour la formation d'un cluster à deux nœuds. Ces deux votes peuvent dériver des deux nœuds de cluster ou d'un seul nœud et d'un périphérique de quorum.
Figure 3–2 Configuration à deux nœuds
Quorum dans les configurations supérieures à deux nœuds
Vous pouvez configurer un cluster supérieur à deux nœuds sans périphérique de quorum. Cependant, si vous procédez ainsi, vous ne pouvez pas démarrer le cluster sans une majorité de nœuds dans le cluster.
Configurations de quorum atypiques
La Figure 3–3 suppose que vous exécutez des applications stratégiques (une base de données Oracle, par exemple) sur Node A et Node B. Si le nœud A et le nœud B sont indisponibles et ne peuvent accéder aux données partagées, vous pouvez souhaiter la mise hors service totale du cluster. Sinon, cette configuration n'est pas véritablement optimale car elle n'offre pas la meilleure disponibilité.
Pour plus d'informations sur la recommandation à laquelle cette exception est liée, voir Respect des recommandations portant sur les périphériques de quorum .
Figure 3–3 Configuration atypique
Configurations de quorum déconseillées
Cette section donne des exemples de configurations de quorum à éviter. Pour consulter les exemples de configurations de quorum conseillées, reportez-vous à Configurations de quorum conseillées .
- © 2010, Oracle Corporation and/or its affiliates