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 qu'une seule partition majoritaire peut planifier les charges de travail, évitant ainsi la corruption de données et le split brain lors d'une partition réseau. Sous le capot, Proxmox s'appuie sur Proxmox corosync pour la gestion des membres et du quorum. Quand le quorum est perdu, le filesystem de cluster Proxmox (pmxcfs à /etc/pve) passe en lecture seule et les actions de Haute Disponibilité (HA) s'arrêtent par conception. Cette base est essentielle pour un Proxmox cluster troubleshooting efficace.

Ce guide explique le quorum et les votes, les modes de panne fréquents, les commandes précises pour inspecter l'état de corosync, ainsi que des techniques de reprise sûres. Vous trouverez des exemples concrets pour des clusters à 3 et 5 nœuds, des conseils pour les architectures à 2 nœuds, et un petit pilote local à effectuer avant toute modification en production.

Vue d'ensemble du workflow

À utiliser chaque fois que vous suspectez un problème de quorum ou que vous voyez des nœuds alterner entre « online » et « unknown » :

Cartographier la conception du quorum visé

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

Sur n'importe quel nœud :

Vérifier l'état actuel du quorum

pvecm status

Lignes clés à contrôler :

Quorate: Yes/No
Expected votes, Total votes, Quorum (compte requis)
Liste de membership et nœuds vus

Vérifiez aussi corosync directement :

corosync-quorumtool -s

Cette commande confirme si corosync considère le cluster quorate et récapitule les 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 le transport et la santé des rings

Afficher l'état de corosync et les 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
  }
}

Contrôles réseau pour ring0/ring1 :
Faites un ping entre chaque paire de nœuds sur les sous-réseaux ring0 et ring1.
Vérifiez que le MTU est cohérent de bout en bout. Si vous utilisez des jumbo frames d'un côté, utilisez-les partout sur ce chemin.
Conservez corosync sur un VLAN ou une interface dédiée, séparée du trafic VM est-ouest volumineux.
Assurez-vous que les noms DNS/hosts dans corosync.conf se résolvent à l'identique sur tous les nœuds, ou préférez les IPs.

Comprendre votes, expected votes et risque de split brain

Le quorum exige une majorité stricte des expected votes.
Dans un cluster à 3 nœuds, si 1 nœud tombe, les 2 restants conservent le quorum (2 sur 3). S'il en manque 2, le quorum est perdu.
Ne lancez jamais d'invités écrivant sur un stockage partagé depuis une partition sans quorum. C'est ainsi que survient un Proxmox split brain.

Modèles de remédiation sûrs

Préférez restaurer la connectivité plutôt que d'utiliser des overrides. Réparez le réseau en premier.
Si un seul nœud est isolé : corrigez son NIC/VLAN de ring, vérifiez les ports de switch, le câblage et le pare-feu hôte.
Après récupération d'un nœud, assurez-vous que corosync tourne :

systemctl restart corosync

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

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

C'est un dernier recours pour retrouver l'accès en écriture à /etc/pve afin d'effectuer des réparations lorsque tous les autres nœuds sont physiquement isolés. Supprimez l'override en redémarrant corosync après les réparations.

Exemples pratiques

Exemple A : cluster à 3 nœuds, un nœud en panne
Expected votes: 3, Quorum: 2. Avec 2 nœuds en ligne, Quorate: Yes. Aucune action immédiate requise ; enquêtez sur le nœud en panne pendant que le cluster fonctionne.

Exemple B : cluster à 5 nœuds, deux nœuds en panne
Expected votes: 5, Quorum: 3. Avec 3 nœuds en ligne, Quorate: Yes. La capacité est réduite ; planifiez la remise en état mais les services restent sûrs.

Exemple C : cluster à 2 nœuds sans tie-breaker
Au moindre défaut d'un nœud ou d'un lien instable, le quorum chute fréquemment. Ajoutez un QDevice sur un troisième hôte pour apporter une voix supplémentaire, ou migrez vers une conception à 3 nœuds.

Proxmox, HA et stockage : précautions

Si HA est activée, n'effectuez pas de démarrages forcés de services sur un nœud sans quorum.
Avec Ceph ou tout stockage partagé, évitez toute action pouvant créer deux primaires écrivant en concurrence. Validez d'abord l'état du quorum et la santé du stockage.
L'édition de /etc/pve/corosync.conf nécessite le quorum ; lorsque le quorum est perdu, ce filesystem est en lecture seule par conception. Restaurez le quorum d'abord ou utilisez un override planifié avec isolement strict.

Plan pilote local

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

Portée

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

Critères de succès

La perte d'1 nœud sur 3 conserve le quorum (2 sur 3).
La perte de ring0 ou ring1 seul ne fait pas chuter le quorum (knet utilise l'anneau survivant).
Le temps de reprise après la perte d'un nœud est sous votre SLO (p. ex. détection en < 10 s, stabilisation en < 60 s).

Checklist de mise en place

Installez Proxmox VE sur tous les nœuds avec des versions identiques.
Assurez une synchronisation horaire cohérente (NTP) et des MTU correspondants sur les NICs des rings.
Joignez les nœuds avec pvecm et confirmez :

pvecm status
corosync-quorumtool -s

Configurez ring1 (optionnel) pour la redondance, puis vérifiez que les deux chemins sont utilisés.

Exercices de panne (observez et consignez)

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 journaux.

Introduisez un MTU incohérent sur un lien

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

Mesures à capturer

pvecm status et corosync-quorumtool -s avant, pendant et après chaque exercice.
Timestamps de journalctl -u corosync pour la détection et la reprise.

Critères de sortie

Tous les exercices satisfont les critères de succès deux fois de suite sans intervention autre que la réparation prévue. Documentez les commandes exactes et les observations pour votre runbook de production.

Conclusion

Les problèmes de Proxmox cluster quorum proviennent le plus souvent du réseau ou de la configuration autour de Proxmox corosync. Commencez par clarifier les expected votes, confirmez l'état du quorum avec pvecm status et corosync-quorumtool -s, puis corrigez la connectivité plutôt que de recourir immédiatement aux overrides. Maintenez corosync sur des chemins stables et à faible latence, privilégiez un nombre impair de votants et ajoutez un tie-breaker à toute conception à 2 nœuds.

Prochaines étapes

Intégrez les vérifications de ce guide à vos procédures standard.
Exécutez le pilote local et capturez les temps comme référence.
Révisez la conception des anneaux pour la redondance, la cohérence MTU et l'isolement du trafic VM.
Répétez des exercices de panne chaque trimestre afin que les équipes d'astreinte sachent exactement quoi faire.

Avec une approche disciplinée et des pilotes courts et mesurables, vous pourrez diagnostiquer rapidement les problèmes de quorum et garder vos clusters Proxmox sûrs et prévisibles, en réduisant les risques de Proxmox split brain et en accélérant tout Proxmox cluster troubleshooting.