Dépannage du quorum d'un cluster Proxmox avec exemples pratiques

Introduction

Le quorum est la ceinture de sécurité d'un cluster Proxmox VE. Il garantit que seule une partition majoritaire peut planifier des charges de travail, évitant ainsi la corruption de données et le split brain lorsque le cluster est partitionné. En interne, Proxmox s'appuie sur corosync pour l'appartenance et le quorum. Lorsque le quorum est perdu, le système de fichiers du cluster Proxmox (pmxcfs sous /etc/pve) devient accessible en lecture seule et les actions de haute disponibilité sont mises en pause par conception.

Ce guide explique le quorum et les votes, les modes de défaillance courants, les commandes exactes pour inspecter l'état de corosync, et les techniques de récupération sécurisées. Vous y trouverez des exemples pratiques pour les clusters à 3 et 5 nœuds, des conseils pour les conceptions à 2 nœuds, et un petit pilote que vous pouvez exécuter localement pour valider votre approche avant de toucher à la production.

Aperçu du flux de travail

Utilisez ce flux de travail étape par étape chaque fois que vous suspectez des problèmes de quorum ou que vous voyez des nœuds flapper entre online et unknown :

Définir la conception de quorum prévue

Compter les participants votants. Par défaut, chaque nœud a 1 vote. Visez un nombre impair de votants (3, 5, 7...).
Pour les clusters à 2 nœuds, ajoutez un brise-égalité (QDevice) ou un troisième nœud léger. Faire tourner 2 nœuds sans brise-égalité est fragile.
Documentez les anneaux corosync (ring0 et ring1 optionnel) et les réseaux dédiés qu'ils utilisent.

Exécutez sur n'importe quel nœud :

Vérifier l'état actuel du quorum

pvecm status

Lignes clés :

Quorate : Yes/No
Expected votes, Total votes, Quorum (nombre requis)
Liste d'appartenance et nœuds vus

Vérifiez aussi corosync directement :

corosync-quorumtool -s

Cela confirme si corosync considère le cluster comme quorate et liste les comptes de votes.

Exemple : cluster 3 nœuds sain

# pvecm status
Quorate: Yes
Expected votes: 3
Total votes: 3
Quorum: 2
Membership:
 Nodeid Votes Name
0x00000001 1 10.0.0.11 (local)
0x00000002 1 10.0.0.12
0x00000003 1 10.0.0.13

Inspecter la santé du transport et des anneaux

Afficher la santé des anneaux et l'état des interfaces :

systemctl status corosync
journalctl -u corosync -b --no-pager | tail -n 200

Confirmer la configuration active :

cat /etc/pve/corosync.conf

Extrait typique :

totem {
 version: 2
 cluster_name: pve
}

nodelist {
 node {
 name: pve1
 nodeid: 1
 ring0_addr: 10.10.10.11
 ring1_addr: 172.16.10.11
 }
 node {
 name: pve2
 nodeid: 2
 ring0_addr: 10.10.10.12
 ring1_addr: 172.16.10.12
 }
 node {
 name: pve3
 nodeid: 3
 ring0_addr: 10.10.10.13
 ring1_addr: 172.16.10.13
 }
}

Vérifications réseau pour ring0/ring1 :
Ping entre chaque paire de nœuds sur les sous-réseaux ring0 et ring1.
Vérifier que la MTU est cohérente de bout en bout. Si vous utilisez des trames géantes (9000) d'un côté, utilisez-les partout sur ce chemin.
Gardez corosync sur un VLAN ou une interface dédiée, calme, séparée du trafic VM est-ouest important.
Assurez-vous que les noms DNS/hosts dans corosync.conf se résolvent identiquement sur tous les nœuds, ou préférez les adresses IP.

*Comprendre les votes, votes attendus et risque de split brain***

Le quorum requiert une majorité stricte des votes attendus.
Si un cluster à 3 nœuds perd 1 nœud, les 2 restants conservent le quorum (2 sur 3). S'il perd 2 nœuds, le quorum est perdu.
Ne faites jamais tourner d'invités qui écrivent sur du stockage partagé sur une partition sans quorum. C'est ainsi que survient le split brain.

Modèles de remédiation sécurisés

Privilégiez le rétablissement de la connectivité aux contournements. Réparez d'abord le réseau.
Si un seul nœud est isolé : réparez sa carte réseau/VLAN d'anneau, vérifiez les ports du commutateur, le câblage et le pare-feu hôte.
Après la récupération d'un nœud, assurez-vous que corosync tourne :

systemctl restart corosync

N'utilisez les contournements de quorum que dans une fenêtre de maintenance contrôlée où vous êtes certain qu'aucune autre partition ne peut exécuter les mêmes invités ou accéder au même stockage partagé. Exemple (temporaire et risqué) :

# Réduire temporairement les votes attendus à 1 (ne pas utiliser pendant une scission active)
pvecm expected 1

C'est un dernier recours pour regagner l'accès en écriture à /etc/pve pour des réparations lorsque vous avez physiquement isolé tous les autres nœuds. Supprimez le contournement en redémarrant corosync après les réparations.

Exemples pratiques

Votes attendus : 3, Quorum : 2. Avec 2 nœuds up, Quorate : Yes. Aucune action requise ; investiguez le nœud défaillant pendant que le cluster tourne.

Exemple A : cluster 3 nœuds, un nœud en panne

Votes attendus : 5, Quorum : 3. Avec 3 nœuds up, Quorate : Yes. La capacité est réduite ; planifiez la réparation mais les services restent sûrs.

Exemple B : cluster 5 nœuds, deux nœuds en panne

Quand l'un ou l'autre nœud tombe ou que le lien flappe, le quorum chute fréquemment. Ajoutez un QDevice sur un troisième hôte pour fournir un vote supplémentaire, ou convertissez en conception à 3 nœuds. Pour le QDevice, installez corosync-qdevice sur une machine séparée (même un Raspberry Pi), puis sur chaque nœud Proxmox lancez :

Exemple C : cluster 2 nœuds sans brise-égalité

pvecm qdevice setup <ip-hote-qdevice>

Vérifiez avec pvecm status que le QDevice apparaît comme votant.

Mises en garde Proxmox, HA et stockage

Si la HA est activée, ne forcez pas le démarrage de services sur un nœud sans quorum.
Avec Ceph ou du stockage partagé, évitez toute action qui pourrait créer deux primaires écrivant simultanément. Validez d'abord le quorum et la santé du stockage.
L'édition de /etc/pve/corosync.conf nécessite le quorum ; quand le quorum est perdu, ce système de fichiers est en lecture seule par conception. Récupérez le quorum d'abord ou utilisez un contournement de maintenance planifié avec une isolation stricte.

Plan pilote local

Un petit pilote local vous permet de prouver votre approche avant de toucher à la production.

Périmètre

Construisez un cluster laboratoire à 3 nœuds (imbriqués ou hôtes de secours). Ciblez deux anneaux corosync sur VLANs dédiés, plus un pont séparé pour le trafic VM.

Critères de succès

Perdre 1 nœud sur 3 conserve le quorum (2 sur 3).
Perdre ring0 ou ring1 seul ne fait pas tomber le quorum (knet doit utiliser l'anneau survivant).
Le temps de récupération après une défaillance d'un nœud unique respecte votre SLO (par exemple, détection sous 10 secondes, stable sous 60 secondes).

Liste de vérification de configuration

Installez Proxmox VE sur tous les nœuds avec versions identiques.
Assurez une synchronisation horaire cohérente (NTP) et une MTU correspondante sur les cartes d'anneau.
Rejoignez les nœuds avec pvecm et confirmez :

pvecm status
corosync-quorumtool -s

Configurez l'anneau ring1 optionnel pour la redondance, puis vérifiez que les deux chemins sont utilisés.

Exercices de défaillance (observer et enregistrer)

Débranchez le câble ring0 d'un nœud

Attendu : corosync bascule sur ring1, le cluster reste quorate.
Validez avec pvecm status.

Éteignez un nœud

Attendu : les 2 nœuds restants restent quorate. Notez les temps de détection et de stabilisation dans les logs.

Introduisez un désaccord MTU sur un lien (ex. 1500 d'un côté, 9000 de l'autre)

Attendu : pertes de paquets causent des avertissements corosync ; corrigez la MTU et confirmez le retour à la stabilité.

Mesures à capturer

pvecm status et corosync-quorumtool -s avant, pendant, après chaque exercice.
Horodatages journalctl -u corosync pour la détection et la récupération.

Critères de sortie

Tous les exercices respectent les critères de succès deux fois de suite sans intervention opérateur au-delà de la réparation prévue. Documentez les commandes exactes et observations pour votre runbook production.

Conclusion

Les problèmes de quorum sont généralement des problèmes de réseau ou de configuration autour de corosync. Commencez par une vue claire des votes attendus, confirmez l'état du quorum avec pvecm status et corosync-quorumtool -s, et réparez la connectivité plutôt que de recourir aux contournements. Gardez corosync sur des chemins stables à faible latence, privilégiez les nombres impairs de votants, et ajoutez un brise-égalité à toute conception à 2 nœuds.

Prochaines étapes

Ajoutez les vérifications de ce guide à vos procédures d'exploitation standard.
Exécutez le pilote local et capturez les temps comme base de référence.
Revoyez la conception des anneaux pour la redondance, la cohérence MTU et l'isolation du trafic VM.
Répétez les exercices de défaillance trimestriellement pour que les ingénieurs d'astreinte sachent exactement quoi faire.

Avec une approche disciplinée et de petits pilotes mesurables, vous pouvez diagnostiquer les problèmes de quorum rapidement et garder vos clusters Proxmox sûrs et prévisibles.