La notion de QUORUM dans un cluster Proxmox

Le quorum dans un cluster

Cours ponctuel — Bloc 2 - SISR 2

1. Le problème que le quorum vient résoudre

Imaginons un cluster de 4 serveurs. Une panne réseau coupe la communication en deux groupes : 2 serveurs d'un côté, 2 serveurs de l'autre — chaque groupe continuant de fonctionner et de croire qu'il est le seul survivant. Si les deux groupes continuaient à agir indépendamment (par exemple, chacun démarrant sa propre copie d'une même VM), on obtiendrait deux versions divergentes des mêmes données, potentiellement incompatibles.

Ce scénario catastrophe porte un nom : le split-brain (cerveau divisé).

⚠️ Le risque du split-brain : sans mécanisme de protection, deux moitiés d'un cluster séparées par une panne réseau pourraient chacune continuer à modifier les mêmes données de façon indépendante — menant à une corruption ou à une perte de données lors de la reconnexion des deux moitiés.

Le quorum est le mécanisme qui empêche ce scénario.

2. Définition du quorum

Le quorum est le nombre minimal de nœuds devant être joignables et d'accord entre eux pour qu'un cluster soit autorisé à continuer à fonctionner et à prendre des décisions.

La règle de calcul la plus courante : la majorité absolue

Quorum = (nombre total de nœuds / 2) + 1     (arrondi à l'entier inférieur pour la division)

Nombre total de nœuds	Quorum nécessaire
3	2
4	3
5	3
6	4

💡 À retenir : avec cette règle de majorité absolue, il est mathématiquement impossible que deux groupes séparés atteignent chacun le quorum en même temps — un seul des deux groupes, au maximum, peut être majoritaire. C'est précisément ce qui empêche le split-brain.

3. Pourquoi un nombre pair de nœuds pose un problème particulier

Reprenons l'exemple d'un cluster à 4 nœuds, coupé en deux groupes de 2 et 2. Aucun des deux groupes n'atteint le quorum requis (3) — dans ce cas précis, aucune moitié ne peut continuer à fonctionner, ce qui est le comportement voulu (sécurité avant tout), mais signifie aussi que le cluster entier est à l'arrêt malgré la disponibilité de la moitié des ressources.

⚠️ Piège classique : construire un cluster avec un nombre pair de nœuds (ex. 2 ou 4) sans mécanisme complémentaire est déconseillé, car une simple coupure réseau au "milieu" peut bloquer l'intégralité du cluster, alors qu'un nombre impair de nœuds tolère mieux ce genre de scénario.

4. Le cas particulier du cluster à 2 nœuds

Un cluster à seulement 2 nœuds est le cas le plus fragile : la moindre coupure réseau entre eux empêche instantanément tout quorum (1 nœud sur 2 requis... mais la règle de majorité stricte impose souvent 2 sur 2 dans ce cas précis selon l'implémentation). Deux solutions existent :

Solution	Principe
Ajouter un 3ᵉ nœud "complet"	Solution la plus robuste, mais nécessite un serveur physique supplémentaire
*Ajouter un QDevice (quorum device)*	Un dispositif léger, ne participant pas au fonctionnement du cluster, mais dont le vote sert uniquement à départager les situations à égalité

Le QDevice

Un QDevice est un service externe (souvent hébergé sur une machine tierce, indépendante des deux nœuds du cluster) dont le seul rôle est de fournir un vote supplémentaire en cas de partition réseau, permettant à un cluster à 2 nœuds de conserver un mécanisme de quorum fiable sans nécessiter un troisième serveur complet.

🎯 Bonne pratique : pour un cluster à 2 nœuds en production, la mise en place d'un QDevice est fortement recommandée plutôt que de fonctionner sans protection de quorum fiable.

5. Vérifier l'état du quorum sous Proxmox

pvecm status

La sortie de cette commande indique notamment : - le nombre de votes attendus (généralement égal au nombre de nœuds, ou plus si un QDevice est configuré) ; - le nombre de votes actuellement présents ; - si le quorum est atteint (Quorate: Yes) ou non (Quorate: No).

🔑 Point clé : un cluster qui perd son quorum n'est pas nécessairement "en panne" au sens matériel — il peut être parfaitement fonctionnel matériellement, mais se bloquer volontairement par sécurité. C'est un comportement voulu, pas un bug.

6. Le lien avec la haute disponibilité

Le mécanisme de haute disponibilité (voir la fiche dédiée) s'appuie directement sur le quorum : un nœud qui perd le quorum ne peut pas décider seul de redémarrer une VM ailleurs — cela reviendrait au même risque de split-brain qu'évoqué plus haut (la VM pourrait alors tourner à deux endroits en même temps sur les mêmes données).

7. Glossaire

Terme	Définition
Quorum	Nombre minimal de nœuds devant s'accorder pour qu'un cluster continue de fonctionner
Split-brain	Situation où deux parties d'un cluster séparées agissent indépendamment sur les mêmes données
QDevice	Dispositif externe léger fournissant un vote supplémentaire pour départager un cluster à 2 nœuds
`Quorate`	Indicateur (oui/non) signalant si le cluster a atteint son quorum