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 clusters est partitionnée.
Pour plus d'informations sur MAC, consultez “Appartenance au cluster” dans le manuel Présentation de Sun Cluster pour SE Solaris
Des partitions de cluster peuvent provoquer deux types de problèmes :
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 pense être unique car les nœuds d'une partition ne peuvent communiquer avec le nœud d'une 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 lorsque vous démarrez le cluster sur un nœud qui ne faisait pas partie de la dernière partition de cluster ayant fonctionné.
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 nœuds, 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 son vote 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 leurs votes en fonction du nombre de votes connectés au périphérique. Lorsque vous configurez un périphérique de quorum, le logiciel Sun Cluster lui attribue un nombre N-1 de votes où N est le nombre de votes connectés au périphérique de quorum. Par exemple, un périphérique de quorum connecté à deux nœuds 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.
La configuration des périphériques de quorum s'effectue au moment de l'installation, ou ultérieurement à l'aide des procédures décrites dans “Administration du quorum” dans le Guide d'administration du système 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, tous les nœuds ne peuvent pas 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 sous-ensemble ou partition peut croire qu'il/elle est le/la seul(e) à être propriétaire des périphériques multihôtes et à en posséder l'accès. Si plusieurs nœuds 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 nœuds aux périphériques multihôtes en les empêchant physiquement d'accéder aux disques. Lorsqu'un nœud 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 les périphériques multihôtes. Lorsqu'un membre du cluster fonctionnant comme nœud principal (propriétaire) du groupe de périphériques de disques échoue ou devient inaccessible, un nouveau nœud 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 nœud principal doit renoncer à l'accès aux périphériques avant 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.
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 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.
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 nœuds reliés aux disques (lorsque aucune réservation n'est en place), soit restreindre l'accès à un seul nœud (détenant la réservation).
Lorsqu'un membre détecte qu'un autre nœud ne communique plus sur l'interconnexion du cluster, il lance une procédure de séparation en cas d'échec pour empêcher le nœud d'accéder aux disques partagés. En présence d'une séparation en cas d'échec, il est normal que le nœud 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 nœud 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 nœud et les autres nœuds. Le nœud 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 nœud défectueux ne se réinitialise pas et ne commence pas à écrire sur le stockage partagé est appelé failfast .
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 disques, il donne au nœud 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 nœuds.
Avec MHIOCENFAILFAST, le pilote contrôle le retour d'erreur de toutes les opérations de lecture et d'écriture qu'un nœud 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 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 nœuds. Le mécanisme failfast fonctionne de la même manière avec 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 nœud faisant partie de la partition et pouvant atteindre un quorum place les réservations sur les disques partagés, et lorsque le nœud 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 nœud 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? avec eeprom(1M), à l'invite ok de la PROM OpenBoot sur un cluster SPARC ou avec l'utilitaire SCSI exécuté en option après l'initialisation du BIOS sur 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ù N périphériques de quorum sont chacun connectés à l'un des 1 à N nœuds et au nœud N+1, le cluster survit à la mort soit de tous les 1 à N nœuds, soit de l'un des N/ 2 nœuds. 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 mort de n'importe lequel des N- 1 nœuds. 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.
Vous trouverez des exemples de configurations de quorum à éviter dans Configurations de quorum déconseillées . De même, vous trouverez des exemples de configurations de quorum conseillées dans Configurations de quorum conseillées .
Respect des contraintes des périphériques de quorum
Vous devez respecter les conditions requises suivantes. Faute de quoi, vous risquez de compromettre la disponibilité de votre 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 SCSI-3 PGR
-
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 à Figure 3–2.
Vous trouverez des exemples de configurations de quorum à éviter dans Configurations de quorum déconseillées . De même, vous trouverez des exemples de configurations de quorum conseillées dans Configurations de quorum conseillées .
Respect des techniques conseillées pour 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. Il est inutile de configurer un autre périphérique de quorum car vous disposez de la configuration 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 –Parfois, dans certains environnements particuliers, il peut être souhaitable de réduire la disponibilité globale du cluster pour répondre à 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 décrite dans Configurations de quorum atypiques , le cluster est moins disponible : Les votes du quorum excèdent les votes des nœuds. Le cluster se caractérise par le fait que si l'accès au stockage partagé entre les nœuds A et B est perdu, la totalité du cluster échouera.
Pour les exceptions à cette règle, reportez-vous à 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. Reportez-vous à 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.
Vous trouverez des exemples de configurations de quorum à éviter dans Configurations de quorum déconseillées . De même, vous trouverez des exemples de configurations de quorum conseillées dans Configurations de quorum conseillées .
Configurations de quorum conseillées
Vous trouverez des exemples de configurations de quorum à éviter dans 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 venir des deux nœuds du cluster ou juste 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
Il est possible de configurer un cluster comportant plus de deux nœuds sans périphérique de quorum. Toutefois, dans ce cas, vous ne pourrez pas démarrer le cluster sans disposer de la majorité des nœuds du cluster.
Configurations de quorum atypiques
La Figure 3–3 suppose que vous exécutez des applications essentielles à une mission (base de données Oracle par exemple) sur les Nœud A et Nœud 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 les techniques conseillées en rapport avec cette exception, reportez-vous à Respect des techniques conseillées pour les périphériques de quorum.
Figure 3–3 Configuration atypique
Configurations de quorum déconseillées
De même, vous trouverez des exemples de configurations de quorum conseillées dans Configurations de quorum conseillées .
- © 2010, Oracle Corporation and/or its affiliates