Une perte de quorum est une panne déroutante : les machines virtuelles tournent, le stockage répond, et pourtant l'interface refuse la moindre modification. Parfois des noeuds redémarrent tout seuls alors que leur matériel va parfaitement bien. Ce n'est pas un dysfonctionnement, c'est une protection qui fait exactement son travail, et tout l'enjeu du diagnostic consiste à comprendre ce qu'elle protège avant de chercher à la contourner.
Si vous êtes en incident, allez directement au paragraphe 02 pour constater, puis au 04 pour diagnostiquer. Ne commencez pas par forcer le nombre de voix attendues : c'est la manoeuvre qui transforme une indisponibilité en perte de données, et le paragraphe 05 explique pourquoi.
01Ce que fait le quorum, et pourquoi il coupe
Les noeuds d'un cluster Proxmox VE partagent une base de configuration, montée sur
/etc/pve. Pour que deux noeuds n'écrivent jamais des choses contradictoires dans
cette base, corosync impose qu'une majorité stricte de voix soit joignable avant
d'autoriser la moindre écriture. Sous ce seuil, la partie minoritaire se met en retrait.
| Conséquence | Ce que vous observez |
|---|---|
| Configuration en lecture seule | Impossible de démarrer, créer ou modifier une machine |
| Interface partiellement muette | Les noeuds hors quorum apparaissent en gris |
| Haute disponibilité en retrait | Les ressources ne basculent plus |
| Isolation automatique | Les noeuds sous HA redémarrent après environ deux minutes |
| Machines existantes | Elles continuent de tourner, tant qu'aucune isolation n'intervient |
Proxmox VE n'utilise pas de dispositif d'isolation externe : chaque noeud s'auto-isole grâce à un chien de garde qui le redémarre s'il perd le quorum alors qu'il héberge des ressources en haute disponibilité. C'est ce qui garantit qu'une machine ne tournera jamais deux fois en même temps sur le même disque. Un incident purement réseau provoque donc le redémarrage de serveurs dont le matériel et le stockage vont parfaitement bien.
02Lire l'état en trois commandes
pvecm status
| Champ | Ce qu'il dit |
|---|---|
| Expected votes | Le nombre de voix que le cluster croit devoir trouver |
| Highest expected | Le maximum jamais atteint, utile pour repérer un abaissement manuel |
| Total votes | Les voix réellement présentes en ce moment |
| Quorum | Le seuil à atteindre, soit la majorité stricte |
| Flags | La mention Quorate, ou son absence, qui résume tout |
# etat de chaque lien, par noeud : connecte ou non corosync-cfgtool -s # latence observee, minimum, moyenne, maximum corosync-cfgtool -n
journalctl -u corosync -u pve-cluster --since "-2h" --no-pager
# les messages qui comptent vraiment
journalctl -u corosync --since "-2h" | grep -Ei 'retransmit|token|link|forming|left'
Les mentions de retransmission signalent des paquets perdus : le réseau corosync est saturé, instable, ou partagé avec autre chose. Les mentions de jeton perdu indiquent que le noeud n'a pas reçu à temps le signal qui circule entre membres : latence trop élevée, ou noeud trop chargé pour répondre dans les délais. Ces deux familles de messages orientent immédiatement le diagnostic vers le réseau, pas vers Proxmox.
03Les causes, par fréquence
| Cause | Signe caractéristique | Vérification |
|---|---|---|
| Lien corosync partagé avec Ceph ou la production | Perte pendant une reconstruction ou une sauvegarde | Plan d'adressage, corrélation horaire |
| Un seul lien corosync déclaré | Toute panne réseau devient fatale | corosync-cfgtool -s |
| Port de commutateur ou câble défaillant | Un seul noeud concerné, de façon répétée | Compteurs d'erreurs du commutateur |
| MTU incohérent | Fonctionne, puis coupe sur les gros paquets | ping -M do -s 8972 |
| Dérive d'horloge | Journaux incohérents entre noeuds | chronyc tracking |
| Pare-feu ou règle de commutateur | Apparue après un changement réseau | Trafic corosync bloqué entre noeuds |
| Noeud saturé | Jetons perdus sur un noeud très chargé | Charge processeur au moment de l'incident |
| Agrégation de liens pour corosync | Bascule plus lente que le délai toléré | Configuration des interfaces |
| Maintenance non annoncée | Coïncide avec un redémarrage de commutateur | Journal des changements |
Corosync et Ceph sur le même lien physique. Corosync a besoin d'une latence faible et stable, pas de débit ; Ceph consomme tout le débit disponible pendant une reconstruction. Le jour où un disque tombe, Ceph sature le lien, corosync perd ses jetons, le cluster perd le quorum, et des noeuds parfaitement sains redémarrent au milieu d'une reconstruction. C'est l'enchaînement que nous constatons le plus souvent sur les plateformes que nous reprenons.
04La démarche en dix minutes
- Établir qui voit qui. Depuis chaque noeud joignable, tester les deux réseaux corosync vers tous les autres. La carte des liens qui passent et de ceux qui ne passent pas désigne presque toujours le coupable.
- Mesurer la latence et la perte sur le lien 0, pas seulement la joignabilité. Un lien qui répond au ping peut parfaitement perdre un paquet sur dix.
- Vérifier le MTU de bout en bout, surtout si une modification réseau a eu lieu récemment.
- Comparer les horloges.
- Chercher la corrélation horaire : que se passait-il sur la plateforme à l'instant de la coupure, reconstruction Ceph, sauvegarde, migration de masse.
# latence et perte reelles sur le lien 0, pendant une minute ping -i 0.2 -c 300 10.10.1.12 | tail -3 # MTU de bout en bout, sans fragmentation autorisee ping -M do -s 8972 -c 4 10.10.4.12 # ecart d'horloge chronyc tracking | grep -E 'System time|Last offset' # charge du noeud au moment des pertes de jeton uptime
Regarder d'abord si les deux liens corosync sont tombés ou un seul. Si un seul est tombé et que le cluster a quand même perdu le quorum, c'est que le second lien n'était pas réellement indépendant : même commutateur, même carte, ou même agrégation. Cette constatation vaut toutes les analyses de journaux.
05Rétablir le service
L'ordre compte. Réparer le réseau rétablit le quorum tout seul, sans aucune commande, et c'est toujours la bonne première tentative.
- Réparer la cause réseau : câble, port, configuration de commutateur, retour d'un noeud. Le quorum se reforme en quelques secondes.
- Si un noeud est revenu mais reste isolé, redémarrer corosync sur ce noeud seul.
- En dernier recours seulement, si des noeuds sont réellement arrêtés et le resteront, abaisser temporairement le nombre de voix attendues.
systemctl restart corosync
sleep 10
pvecm status
# si la base de configuration reste muette
systemctl restart pve-cluster
Abaisser le nombre de voix attendues lève la protection qui empêche deux parties d'un cluster coupé en deux d'écrire chacune de leur côté. Ne l'employez que si vous avez la certitude que les noeuds absents sont éteints, et non simplement isolés par une panne réseau. Dans le doute, réparez le réseau, même si c'est plus long. Le réglage est temporaire et disparaît au redémarrage de corosync.
# sur un cluster de trois dont un seul reste debout
pvecm expected 1
pvecm status
Modifier la configuration quand rien ne répond
Sans quorum, /etc/pve est en lecture seule, y compris pour corriger ce qui a causé
le problème. Il existe un mode local qui permet d'écrire sur un seul noeud, à utiliser avec
précaution et jamais sur deux noeuds en même temps.
systemctl stop pve-cluster
pmxcfs -l
# ... correction de la configuration ...
killall pmxcfs
systemctl start pve-cluster
06Le cluster coupé en deux
C'est le scénario que toute la mécanique cherche à éviter : une panne réseau sépare le cluster en deux groupes qui ne se voient plus, chacun persuadé que l'autre est tombé. Avec un nombre impair de voix, un seul groupe atteint la majorité et l'autre se met en retrait : le système se protège seul. Avec un nombre pair, aucun des deux n'y parvient, et la plateforme se fige entièrement.
Ne forcez jamais le quorum des deux côtés d'une coupure. Deux parties qui écrivent chacune dans leur copie de la configuration produisent des divergences impossibles à fusionner, et si une même machine virtuelle démarre des deux côtés sur un stockage partagé, son système de fichiers est détruit en quelques secondes. Choisissez un côté, laissez l'autre éteint, et ne rallumez qu'une fois le réseau réparé.
07Prévenir la prochaine fois
- Deux liens corosync réellement indépendants : cartes différentes, commutateurs différents, chemins différents. C'est la mesure la plus efficace du lot.
- Pas d'agrégation pour corosync. Corosync gère lui-même la redondance de ses liens, plus vite et plus sûrement qu'un lien agrégé.
- Un lien 0 dédié, jamais partagé avec Ceph, la migration ou la production.
- Un nombre impair de voix, au besoin avec un QDevice pour les clusters à nombre pair de noeuds.
- Surveiller la latence du lien 0 et le nombre de liens actifs, en continu. Ces deux indicateurs se dégradent avant l'incident, ce qui laisse le temps d'agir. Ils figurent au tableau des indicateurs du guide cluster.
- Déclarer les fenêtres de maintenance réseau à l'équipe qui exploite le cluster. Un redémarrage de commutateur non annoncé provoque exactement les mêmes symptômes qu'une panne.
08Liste de contrôle
| Étape | Action | Outil |
|---|---|---|
| Constater | Voix présentes, voix attendues, mention Quorate | pvecm status |
| Constater | Liens actifs et latence par noeud | corosync-cfgtool -s -n |
| Constater | Retransmissions et jetons perdus | journalctl -u corosync |
| Diagnostiquer | Carte de qui voit qui, sur les deux liens | ping depuis chaque noeud |
| Diagnostiquer | Perte de paquets, pas seulement joignabilité | 300 paquets, lecture du taux |
| Diagnostiquer | MTU de bout en bout | ping -M do |
| Diagnostiquer | Dérive d'horloge | chronyc tracking |
| Diagnostiquer | Corrélation avec une activité lourde | Supervision, journaux |
| Rétablir | Réparer le réseau d'abord | Le quorum revient seul |
| Rétablir | Redémarrer corosync sur le noeud isolé | systemctl restart corosync |
| Rétablir | Abaisser les voix seulement si extinction certaine | pvecm expected |
| Après | Consigner la cause et l'heure | Dossier d'exploitation |
| Après | Vérifier l'indépendance réelle des deux liens | Schéma réseau |
Une perte de quorum est presque toujours un problème de réseau, pas un problème de Proxmox. Le diagnostic commence donc par le câble, le commutateur et la latence, et la réparation du réseau rétablit le service sans qu'aucune commande de cluster soit nécessaire. Les commandes qui forcent le quorum existent pour des cas précis et rares, et elles sont dangereuses partout ailleurs.
Une plateforme Proxmox a exploiter sereinement
Nous exploitons des clusters Proxmox VE et Ceph en production pour des PME, des structures reglementees et des collectivites. Remplacement de noeud, montee de version, reprise d'une plateforme existante : nous intervenons au forfait comme en astreinte.