Chapitre 717 minIntermédiaire
Cluster, basculement et quorum : actif/passif, actif/actif
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- distinguer un cluster actif/passif d'un cluster actif/actif ;
- expliquer le split-brain et la façon de l'empêcher ;
- calculer le quorum d'un cluster et placer un témoin ;
- décrire les étapes d'un basculement.
5 exercices corrigés1 schéma
Un cluster de haute disponibilité (en français, une grappe de serveurs) est un groupe de serveurs, les nœuds, qui se surveillent mutuellement et se partagent des ressources : si un nœud tombe, un autre démarre à sa place l'adresse IP, le stockage et le service qu'il portait. C'est le basculement. Ce chapitre explique les clusters actif/passif et actif/actif, le battement de cœur, le risque de split-brain, le quorum et le fencing, avec deux exemples : Pacemaker et Corosync sous Linux, le cluster de basculement de Windows Server.
C'est quoi un cluster ?
Le mot désigne plusieurs choses selon le contexte :
- un cluster de haute disponibilité : des nœuds prêts à reprendre les ressources d'un nœud en panne. C'est l'objet de ce chapitre ;
- un cluster de répartition de charge : des serveurs identiques derrière un répartiteur (chapitre 6) ;
- un cluster de calcul : des centaines de machines qui se partagent un calcul scientifique. Rien à voir avec la disponibilité.
Dans un cluster de haute disponibilité, une ressource est tout ce qui doit tourner quelque part dans le cluster : une adresse IP virtuelle, un système de fichiers sur un disque partagé, un service (une base de données, un serveur de fichiers), une machine virtuelle. Un gestionnaire de cluster décide sur quel nœud chaque ressource tourne, la surveille, et la déplace en cas de panne : Pacemaker (avec Corosync pour la communication) sous Linux, le cluster de basculement de Windows Server, le gestionnaire HA de Proxmox VE ou vSphere HA pour les machines virtuelles (chapitre 8).
Actif/passif ou actif/actif
| Actif/passif | Actif/actif | |
|---|---|---|
| Principe | Un nœud porte le service, l'autre attend pour le reprendre | Tous les nœuds rendent le service en même temps |
| Bascule | Le passif démarre le service : quelques secondes à quelques minutes de coupure | Les survivants continuent : seules les connexions du nœud perdu sont coupées |
| Utilisation du matériel | Le passif ne sert à rien tant que tout va bien | Tout le matériel travaille |
| Données | Un seul nœud écrit à la fois : simple | Plusieurs nœuds écrivent : il faut une réplication multi-maître ou un verrouillage distribué |
| Règle de capacité | Le passif doit pouvoir porter toute la charge | Les survivants doivent pouvoir absorber la charge du nœud perdu |
| Exemples | Une base de données sur stockage partagé, deux pare-feu en CARP, deux répartiteurs avec keepalived | Une ferme de serveurs web derrière un répartiteur, un cluster Galera, un cluster d'hyperviseurs |
La règle de capacité de l'actif/actif. Trois nœuds chargés à 60 % représentent 180 % de charge totale ; si l'un tombe, les deux autres doivent en porter 90 % chacun : ça tient. Quatre nœuds chargés à 80 % représentent 320 % ; à trois, chacun devrait en porter environ 107 % : le cluster s'effondre au moment précis où il devait sauver le service. Un cluster actif/actif se surveille donc aussi en capacité.
On parle aussi de cluster N+M : N nœuds actifs et M nœuds de réserve, par exemple quatre serveurs actifs et un passif capable de remplacer n'importe lequel.
Le battement de cœur
Les nœuds s'échangent en permanence des messages courts, les battements de cœur (heartbeats), pour savoir qui est vivant. Quand un nœud ne reçoit plus les battements d'un autre pendant un délai donné (quelques secondes), il le considère comme mort.
Le problème : l'absence de battements ne prouve pas que le nœud est mort. Elle prouve seulement qu'on ne l'entend plus. Le nœud est peut-être vivant, avec un câble arraché, un commutateur en panne ou un processeur saturé. C'est pourquoi :
- les battements circulent sur au moins deux chemins indépendants (deux réseaux, deux cartes, deux commutateurs). Corosync gère plusieurs liens pour la même raison ;
- un réseau dédié au cluster évite qu'une saturation du réseau des utilisateurs passe pour une panne ;
- et surtout, le cluster ne se fie pas aux seuls battements pour reprendre des ressources : il lui faut le quorum, et souvent le fencing.
Le split-brain
Le split-brain (cerveau divisé) arrive quand un cluster se coupe en deux groupes qui ne s'entendent plus, et que chaque groupe se croit seul survivant. Les deux démarrent les mêmes ressources :
- la même adresse IP virtuelle existe deux fois sur le réseau ;
- les deux groupes montent le même disque partagé et écrivent dessus en même temps, chacun sans connaître les écritures de l'autre : le système de fichiers est corrompu ;
- ou chacun écrit dans sa propre copie des données répliquées, et les deux copies divergent : à la réparation, il faut choisir laquelle garder, et l'autre est perdue.
Le split-brain est pire qu'une panne : une panne arrête le service, le split-brain détruit des données. Tout le reste de ce chapitre sert à l'empêcher.
Le quorum : la majorité décide
Le quorum est la règle qui décide quel groupe de nœuds a le droit de continuer quand le cluster se coupe : seul le groupe qui réunit la majorité stricte des votes (en général un vote par nœud) garde ses ressources. L'autre groupe arrête les siennes. Deux groupes ne peuvent pas avoir chacun la majorité : le split-brain devient impossible.
majorité = partie entière de (nombre de votes ÷ 2) + 1
| Nœuds | Majorité nécessaire | Pannes tolérées |
|---|---|---|
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
Le tableau explique deux règles pratiques :
- un nombre impair de nœuds : quatre nœuds ne tolèrent pas plus de pannes que trois, et une coupure en deux moitiés de deux nœuds laisse les deux moitiés sans quorum, donc tout le service arrêté ;
- deux nœuds ne suffisent pas : avec deux nœuds, la majorité vaut 2. Si l'un tombe, le survivant n'a qu'un vote sur deux, et il doit s'arrêter. Un cluster de deux nœuds sans arbitre ne tolère aucune panne.
L'arbitre des clusters à deux nœuds. Pour qu'un cluster de deux nœuds tolère une panne, on ajoute un troisième vote porté par un arbitre léger, qui ne fait tourner aucune ressource :
| Plateforme | Arbitre | Où le placer |
|---|---|---|
| Proxmox VE, Corosync | Un QDevice : le service corosync-qnetd sur une petite machine extérieure | Une petite VM ou un mini-PC, hors des deux nœuds |
| Windows Server | Un témoin : témoin disque (un petit disque partagé), témoin de partage de fichiers (un dossier partagé), témoin cloud (un stockage dans Azure) | Un serveur ou un site indépendant des deux nœuds |
L'arbitre doit être indépendant des deux nœuds : un témoin hébergé sur l'un des deux nœuds tomberait avec lui, et on retrouverait le problème. Windows Server ajuste aussi automatiquement les votes quand des nœuds s'arrêtent proprement (quorum dynamique), ce qui permet à un cluster de survivre à des pannes successives.
Le fencing : être sûr que l'autre est arrêté
Le quorum dit qui a le droit de continuer. Il ne garantit pas que le nœud minoritaire a vraiment arrêté ses ressources : un nœud figé pendant 30 secondes peut se réveiller et terminer une écriture en cours sur le disque partagé, alors que son voisin a déjà repris le service. Le fencing (l'isolation) consiste à mettre de force le nœud douteux hors d'état de nuire avant de reprendre ses ressources.
| Méthode | Principe |
|---|---|
| Par la carte de gestion (IPMI, iDRAC, iLO) | Le survivant demande à la carte de gestion du nœud douteux de couper son alimentation |
| Par une multiprise administrable | Le survivant coupe la prise électrique du nœud |
| Par le réseau de stockage | Le survivant fait couper l'accès du nœud au stockage partagé |
| Par chien de garde (watchdog) | Chaque nœud réarme un minuteur matériel ou logiciel tant qu'il a le quorum ; s'il le perd, il cesse de le réarmer et la machine redémarre d'elle-même. C'est l'auto-isolation qu'utilise Proxmox VE |
Sous Linux, la méthode s'appelle STONITH (Shoot The Other Node In The Head, « tire dans la tête de l'autre nœud »), et Pacemaker refuse par défaut de démarrer des ressources tant qu'aucun dispositif de fencing n'est configuré. C'est volontaire : un cluster sans fencing peut corrompre ses données.
Les étapes d'un basculement
Quand un nœud actif tombe, le basculement suit toujours le même ordre :
- Détection : les autres nœuds ne reçoivent plus ses battements de cœur pendant le délai prévu.
- Vérification du quorum : le groupe restant vérifie qu'il a la majorité ; sinon, il arrête ses propres ressources.
- Fencing : le nœud perdu est isolé (coupé par sa carte de gestion, ou redémarré par son chien de garde après un délai connu).
- Reprise des ressources, dans l'ordre de leurs dépendances : d'abord le stockage (monter le système de fichiers), puis l'adresse IP virtuelle, puis le service.
- Reconnexion des clients : les connexions en cours sont perdues, les clients se reconnectent à la même adresse.
La durée totale du basculement est la somme de ces étapes : quelques secondes pour une adresse virtuelle seule, une à trois minutes pour un service qui doit démarrer, et davantage pour une base de données qui doit relire son journal.
Sous Linux : Pacemaker et Corosync
Sous Linux, la pile de référence associe Corosync (la communication entre nœuds, l'appartenance au cluster et le quorum) et Pacemaker (le gestionnaire de ressources). L'outil pcs les pilote. Voici, en aperçu, un cluster de trois nœuds qui fait tourner une adresse virtuelle et un service, toujours ensemble :
pcs host auth node1 node2 node3 -u hacluster
pcs cluster setup cl-ravelle node1 node2 node3
pcs cluster start --all
pcs resource create vip ocf:heartbeat:IPaddr2 ip=10.10.20.40 cidr_netmask=24 op monitor interval=10s
pcs resource create appli systemd:appli op monitor interval=20s
pcs constraint colocation add appli with vip INFINITY # toujours sur le même nœud
pcs constraint order vip then appli # la VIP d'abord, le service ensuite
pcs status
Dans la réalité, il faut aussi déclarer le fencing (pcs stonith create …, avec l'agent qui correspond à la carte de gestion des serveurs). Pacemaker est puissant mais exigeant : pour une simple adresse virtuelle devant un service sans état (deux répartiteurs, deux serveurs DNS), keepalived suffit. On réserve Pacemaker aux services qui ne doivent tourner qu'à un seul endroit à la fois : une base de données sur stockage partagé, un serveur NFS, une application qui ne supporte pas deux instances.
Sous Windows Server : le cluster de basculement
Windows Server intègre la fonctionnalité Clustering de basculement (Failover Clustering), disponible dans les éditions Standard et Datacenter. Elle sert à rendre hautement disponibles des machines virtuelles Hyper-V, des serveurs de fichiers ou des instances SQL Server.
# Sur chaque nœud
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
# Depuis un nœud : valider la configuration, puis créer le cluster
Test-Cluster -Node SRV-HV1, SRV-HV2
New-Cluster -Name CL-RAVELLE -Node SRV-HV1, SRV-HV2 -StaticAddress 10.10.20.50
# Deux nœuds : un témoin de partage de fichiers sur un troisième serveur
Set-ClusterQuorum -FileShareWitness \\SRV-FIC\TemoinCluster
Get-ClusterNode
Get-ClusterGroup
Test-Cluster vérifie le matériel, le réseau, le stockage et la configuration système, et produit un rapport : un cluster qui ne passe pas la validation n'est pas supporté par Microsoft. Le cluster obtient un nom et une adresse à lui (CL-RAVELLE, 10.10.20.50), sous lesquels on l'administre. Les rôles (une VM, un serveur de fichiers) se déplacent d'un nœud à l'autre avec Move-ClusterGroup, ou automatiquement en cas de panne. Les volumes partagés de cluster (CSV) permettent à tous les nœuds d'accéder en même temps au même stockage, ce qui rend la migration à chaud des VM possible.
Exercices
Exercice 1 sur 5 Quorum : qui continue ? Réussi À revoir
- Un cluster de cinq nœuds. Combien de nœuds peuvent tomber sans arrêter le service ?
- Une coupure réseau sépare ce cluster en un groupe de trois nœuds et un groupe de deux. Que fait chaque groupe ?
- Un cluster de quatre nœuds se coupe en deux groupes de deux. Que se passe-t-il ? Pourquoi est-ce un argument pour un nombre impair de nœuds ?
- Un cluster de six nœuds répartis sur deux salles (trois et trois) perd la liaison entre les salles. Que se passe-t-il, et que proposes-tu ?
Voir la réponseMasquer la réponse de l'exercice 1
- Majorité : 5 ÷ 2 = 2,5, partie entière 2, plus 1 = 3. Le cluster tolère donc 2 pannes.
- Le groupe de trois a la majorité (3 ≥ 3) : il garde ses ressources, isole les deux autres et reprend leurs ressources. Le groupe de deux n'a pas le quorum : il arrête ses ressources.
- La majorité vaut 3. Aucun groupe de deux ne l'atteint : les deux groupes arrêtent tout, et le service s'interrompt. Quatre nœuds ne tolèrent qu'une panne, comme trois, et ajoutent ce risque d'égalité : un nœud de plus sans gain de tolérance.
- Même situation : 3 contre 3, majorité à 4, aucune salle ne continue. Il faut un septième vote dans un troisième lieu (un arbitre léger, un témoin), pour que la salle qui le voit encore ait 4 votes sur 7.
Tu avais trouvé ?
Exercice 2 sur 5 Le témoin mal placé Réussi À revoir
Un cluster Hyper-V de deux nœuds, SRV-HV1 et SRV-HV2, utilise un témoin de partage de fichiers… hébergé dans une VM qui tourne sur SRV-HV1.
- SRV-HV2 tombe. Le service continue-t-il ?
- SRV-HV1 tombe. Le service continue-t-il ?
- Où faut-il placer le témoin ?
Voir la réponseMasquer la réponse de l'exercice 2
- Oui. SRV-HV1 voit encore le témoin (puisqu'il l'héberge) : 2 votes sur 3, il a le quorum.
- Non. Le témoin tombe avec SRV-HV1. SRV-HV2 n'a plus qu'un vote sur trois : il perd le quorum et arrête les rôles, alors qu'il est parfaitement en état de les porter. Le témoin n'a protégé que contre la moitié des pannes.
- Sur une machine indépendante des deux nœuds : un autre serveur physique, un NAS, un autre site, ou un témoin cloud. Pas dans une VM du cluster lui-même.
Tu avais trouvé ?
Exercice 3 sur 5 Actif/actif : ça tient ? Réussi À revoir
- Un cluster actif/actif de trois serveurs, chacun chargé à 60 %. L'un tombe. Quelle charge portent les deux autres ?
- Même question pour quatre serveurs chargés à 80 %, dont un tombe.
- Quelle charge maximale par serveur permet à un cluster de quatre serveurs de survivre à une panne ?
Voir la réponseMasquer la réponse de l'exercice 3
- Charge totale : 3 × 60 = 180 %. Répartie sur 2 serveurs : 90 % chacun. Ça tient, de justesse.
- Charge totale : 4 × 80 = 320 %. Répartie sur 3 serveurs : environ 107 % chacun. Ça ne tient pas : les survivants saturent, et le service s'effondre.
- Il faut que la charge totale tienne sur 3 serveurs à 100 % au plus : 4 × c ≤ 300 %, donc c ≤ 75 % par serveur. En pratique, on garde une marge et on vise moins.
Tu avais trouvé ?
Exercice 4 sur 5 Remettre un basculement dans l'ordre Réussi À revoir
Remets dans l'ordre les étapes du basculement d'un service de base de données dans un cluster actif/passif sur stockage partagé : (a) les clients se reconnectent ; (b) le nœud actif est éteint par sa carte de gestion ; (c) les nœuds restants constatent qu'ils ont la majorité ; (d) l'adresse IP virtuelle démarre ; (e) les battements de cœur du nœud actif cessent d'arriver ; (f) le système de fichiers partagé est monté ; (g) le service de base de données démarre et relit son journal.
Voir la réponseMasquer la réponse de l'exercice 4
e, c, b, f, d, g, a. Détection (e), quorum (c), fencing (b), puis les ressources dans l'ordre de leurs dépendances : le stockage (f), l'adresse (d), le service (g), et enfin les clients (a). On peut aussi démarrer l'adresse après le service : l'essentiel est que le fencing précède le montage du stockage, sinon deux nœuds risquent d'écrire en même temps sur le même disque.
Tu avais trouvé ?
Exercice 5 sur 5 Diagnostiquer un split-brain Réussi À revoir
Un cluster maison de deux serveurs Linux partage un disque iSCSI. Les battements de cœur passent par le réseau des utilisateurs, et aucun fencing n'est configuré « parce que ça marche sans ». Un matin, le commutateur redémarre pendant 40 secondes. Le soir, le système de fichiers partagé est corrompu.
- Explique ce qui s'est passé.
- Cite trois corrections.
Voir la réponseMasquer la réponse de l'exercice 5
- Pendant le redémarrage du commutateur, aucun nœud ne recevait plus les battements de l'autre. Chacun a cru l'autre mort et, faute de quorum (deux nœuds, pas d'arbitre) et de fencing, a monté le disque iSCSI et démarré le service. Pendant quelques dizaines de secondes, deux nœuds ont écrit sur le même système de fichiers sans se coordonner : c'est un split-brain, et la corruption en est la conséquence directe.
- Trois parmi : un troisième vote (un arbitre sur une machine indépendante) pour que l'un des deux seulement garde le quorum ; un fencing par la carte de gestion, pour qu'un nœud soit éteint avant que l'autre monte le disque ; des battements de cœur sur deux chemins, dont un réseau dédié ; un système de fichiers de cluster prévu pour l'accès simultané si les deux nœuds doivent vraiment écrire ensemble.
Tu avais trouvé ?