Cluster Proxmox : pourquoi Corosync semble sain alors que votre cluster meurt

février 28, 2026 • février 28, 2026 • Lecture : 26 min • Views: 2

Cet article vous a aidé ?

Vous ouvrez l’interface Proxmox et elle rame. Les migrations s’interrompent. La HA oscille. Les VM tournent—jusqu’à ce qu’elles ne tournent plus.
Ensuite vous vérifiez l’évidence : le quorum Corosync. Il indique que tout va bien.

C’est le piège. Corosync peut être « correct » au sens étroit—adhésion et quorum intacts—alors que
le reste du cluster suffoque à cause de la latence, de la contention sur le système de fichiers, de blocages de stockage ou de dérive temporelle.
Corosync est le pouls. Votre cluster peut pourtant perdre du sang.

Ce qu’est (et n’est pas) Corosync

Corosync fournit l’adhésion au cluster et la messagerie. Dans Proxmox VE, c’est le composant qui décide
qui fait partie du groupe et si le groupe a le quorum. Il ne garantit pas que votre plan de gestion
soit réactif, que votre stockage soit sain, ni que vos hyperviseurs puissent réellement effectuer du travail au rythme
dont vous avez besoin.

Proxmox empile beaucoup de choses sur la simple capacité des nœuds à se voir :
pmxcfs (le système de fichiers de cluster Proxmox qui stocke l’état de configuration),
pveproxy et pvedaemon (services API/UI),
pve-ha-lrm/crm (logique HA),
pvestatd (statistiques),
et tout ce que fait aujourd’hui votre backend de stockage (ZFS, iSCSI, NFS, Ceph, LVM local… choisissez votre mal de tête préféré).

L’adhésion Corosync peut rester stable même si :

pmxcfs est bloqué en attente d’opérations FUSE et vous ne pouvez pas appliquer de changements de configuration
le réseau perd des paquets ou subit des pics de latence—juste pas assez pour perdre le quorum
la dérive temporelle provoque des bizarreries d’authentification et de fencing
des blocages de stockage figent les threads I/O de QEMU et les migrations expirent
les démons de gestion sont bloqués sur DNS, PAM/LDAP ou des appels système sur le système de fichiers

Deux faits secs qui sauvent des carrières

Le quorum est binaire ; la santé ne l’est pas. Vous pouvez avoir le quorum et rester inutilisable.
La plupart des « problèmes de cluster » Proxmox sont en fait des problèmes de latence. Pas toujours réseau—souvent stockage ou contention CPU qui se manifeste par des battements manqués ailleurs.

Faits intéressants et contexte historique (parce que les systèmes traînent du bagage)

Corosync a évolué depuis le projet OpenAIS, qui visait à implémenter des concepts d’interface applicative pour le clustering sous Linux.
Totem est la couche de communication de groupe de Corosync ; son mécanisme de jeton explique pourquoi le réglage du « token timeout » peut vous donner l’illusion de puissance—puis des regrets.
Le quorum dans Corosync est un problème de vote (via votequorum) plutôt qu’un système de notation de santé ; il ne mesure pas la réactivité des services.
pmxcfs est un système de fichiers distribué basé sur FUSE ; excellent pour de petits fichiers de configuration et terrible pour votre patience quand il se bloque.
Le « filesystem de cluster » de Proxmox n’est pas un système de fichiers général ; c’est un magasin de configuration répliqué. Le traiter comme un stockage partagé est la voie vers la consultation d’un thérapeute.
La prévention de split-brain est un biais de conception dans la plupart des piles de cluster ; Proxmox tend à préférer « arrêter les écritures » plutôt que « risquer une corruption silencieuse ».
Le point douloureux historique de CEPH était l’amplification des petites écritures ; les versions modernes se sont beaucoup améliorées, mais votre réseau et vos disques décident encore si c’est une Ferrari ou une tondeuse.
L’ordonnancement du noyau Linux et la pression I/O peuvent créer des modes de panne où « tout semble en ligne mais rien ne bouge »—surtout sur des hyperviseurs surchargés.

Une citation à garder sur votre écran :
Espérer n’est pas une stratégie. — Gen. Gordon R. Sullivan

Blague #1 : Corosync qui affiche « quorum » pendant que votre GUI plante, c’est comme votre détecteur de fumée qui dit « pile OK » en plein feu de cuisine.

Playbook de diagnostic rapide

Quand le cluster meurt, vous n’avez pas le temps pour une lecture interprétative des logs. Il vous faut un chemin court vers le goulot d’étranglement.
Voici l’ordre qui trouve rapidement les causes racines en environnement réel.

Première étape : s’agit-il d’un problème d’adhésion réseau ou d’un blocage du plan de gestion ?

Vérifier la stabilité de l’adhésion Corosync (pvecm status, corosync-cfgtool -s).
Vérifier si pmxcfs est réactif (pvecm updatecerts va se bloquer si le fs du cluster est figé ; de simples lectures dans /etc/pve peuvent aussi bloquer).
Vérifier si l’API/UI est bloquée (status systemd et journal pour pveproxy/pvedaemon).

Deuxième étape : quelle est la source dominante de latence actuellement ?

Latence réseau/perte de paquets (ping -f n’est pas la réponse ; utilisez mtr, ethtool -S, compteurs côté switch).
Latence stockage (ZFS zpool iostat -v, Ceph ceph -s et slow ops, statistiques clients NFS).
Steal CPU / file d’exécution / pression mémoire (la charge moyenne n’est pas suffisante ; vérifiez vmstat, top, pressure-stall-information si disponible).

Troisième étape : quelque chose « réessaie » indéfiniment ?

Requêtes DNS et LDAP (les connexions GUI se bloquent, les appels API stagnent).
Flapping multipath (les chemins iSCSI meurent et reviennent comme une série télé).
Backfill/récupération Ceph saturant le cluster (il est « assez sain » mais assez lent pour provoquer des timeouts partout).

Décisions de triage rapides

Si l’adhésion est stable mais que pmxcfs est bloqué : traitez cela comme une panne du plan de contrôle. Arrêtez de modifier la configuration et trouvez le blocage.
Si des pics de latence stockage apparaissent : arrêtez les migrations, arrêtez les sauvegardes, arrêtez tout ce qui multiplie l’I/O. Rétablissez d’abord la baseline.
Si le réseau perd/présente des pics de latence : priorisez la stabilisation du réseau du ring plutôt que de « tuner les token timeouts ». Le tuning est un dernier recours, pas un remède.

Modes de panne où Corosync paraît sain

1) pmxcfs est bloqué : Corosync est correct, mais les écritures de configuration se bloquent

pmxcfs est l’endroit où Proxmox stocke la configuration à l’échelle du cluster : définitions de VM, configurations de stockage, règles de pare-feu, domaines utilisateurs, et plus.
Il s’appuie sur la messagerie de Corosync, et il est monté sur /etc/pve via FUSE.

Quand pmxcfs est lent ou coincé, vous verrez des symptômes comme :

Actions GUI qui se bloquent (création de VM, édition de stockage, changement de HA)
Commandes qm/pct qui gèlent quand elles touchent les configs
SSH OK ; les VM continuent de tourner ; mais la gestion est « sous l’eau »

Causes courantes : pression CPU extrême, interblocages FUSE, blocages disque affectant le journal local, ou retards de messages corosync qui ne cassent pas encore le quorum.

2) Les timeouts de jeton ne sont pas en panne ; votre budget de latence l’est

Le mécanisme de jeton de Corosync attend une livraison des messages dans des délais. Vous pouvez avoir un quorum stable même avec des pics intermittents de latence qui
n’excèdent pas votre token timeout—mais ces pics suffisent à geler migrations, sauvegardes et décisions HA.

Un schéma classique : vous avez « corrigé » corosync en augmentant le token timeout. L’adhésion cesse de flapper.
Pendant ce temps, le cluster devient tolérant à une latence tellement mauvaise que tout le reste en souffre. Vous n’avez pas réparé le réseau.
Vous avez juste appris à Corosync à arrêter de se plaindre.

3) Les blocages de stockage figent l’hyperviseur, pas Corosync

Les incidents Proxmox les plus coriaces sont induits par le stockage. Une écriture VM se bloque dans le noyau ou QEMU,
l’hôte subit de l’attente I/O, et soudain tous vos démons de gestion répondent comme s’ils répondaient depuis un tunnel.

Corosync peut encore échanger des heartbeats si le CPU est programmé occasionnellement. C’est suffisant pour garder le quorum.
Mais ce n’est pas suffisant pour un système réactif.

4) Dérive temporelle : le poison lent

Les problèmes NTP/chrony ne cassent pas toujours le quorum. Mais ils peuvent casser tout ce qui suppose la monotonie du temps :
négociations TLS, authentification, corrélation des logs, décisions de fencing, et « pourquoi ce nœud pensait-il être 5 minutes dans le futur ? »

Vous allez aussi courir après des fantômes dans les logs parce que des événements apparaissent hors ordre. Ce n’est pas « amusant ». C’est comment on perd des heures.

5) La HA n’est pas « en panne », elle hésite sous défaillance partielle

La HA de Proxmox dépend d’une vue cohérente des ressources, des états des nœuds et de la disponibilité du stockage.
Avec le quorum intact mais la latence sous-jacente, la HA peut rester bloquée : tenter de redémarrer des ressources en boucle, attendre des verrous, ou refuser des actions
parce qu’elle ne peut pas vérifier l’état en toute sécurité. De l’extérieur, on croit que « la HA est cassée ». De l’intérieur, elle se montre prudente.

6) L’interface est lente parce que pveproxy attend quelque chose de stupide

Coupables fréquents : recherches DNS inverses, timeouts LDAP/PAM, lectures bloquées dans /etc/pve,
ou un chemin à thread unique saturé quelque part dans le traitement des requêtes.

Tâches pratiques : commandes, sorties, décisions

Ce sont les vérifications que j’exécute vraiment quand je suis de permanence. Chaque tâche inclut ce que la sortie signifie et la décision à prendre.
Exécutez-les sur au moins deux nœuds : un « bon » et un « mauvais ». Les différences sont votre indice.

Task 1: Verify quorum and expected votes

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Tue Feb  4 10:12:31 2026
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Signification : Corosync voit 3 nœuds, le quorum est atteint, les votes correspondent aux attentes.
Décision : Si c’est « Yes » mais que vous avez toujours des problèmes, cessez d’accuser le quorum et commencez à mesurer la latence, pmxcfs, et le stockage.

Task 2: Check Corosync link status and MTU mismatches

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 10.10.10.11
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.10.20.11
        status  = ring 1 active with no faults

Signification : Les rings sont opérationnels. « No faults » ne signifie pas « bonne latence ».
Décision : Si les rings montrent des fautes de manière intermittente, corrigez d’abord les problèmes L2/L3 (bonding, MTU, erreurs de switch) avant de toucher au tuning de Corosync.

Task 3: Read Corosync’s own complaints (they’re subtle)

cr0x@server:~$ journalctl -u corosync -S -2h --no-pager | tail -n 30
Feb 04 09:41:02 pve01 corosync[1267]:   [KNET  ] link: host: 2 link: 0 is down
Feb 04 09:41:03 pve01 corosync[1267]:   [KNET  ] host: 2 link: 0 recovered
Feb 04 09:58:19 pve01 corosync[1267]:   [TOTEM ] Token has not been received in 1800 ms
Feb 04 09:58:19 pve01 corosync[1267]:   [TOTEM ] A processor failed, forming new configuration.

Signification : Courtes coupures de lien et délais de token. Vous pouvez rester quoré tant que des reconfigurations ont lieu.
Décision : Si vous voyez des avertissements de token, considérez cela comme un incident réel : enquêtez sur les erreurs réseau, la famine CPU, ou les tempêtes IRQ.

Task 4: Confirm pmxcfs is mounted and responsive

cr0x@server:~$ mount | grep /etc/pve
pve on /etc/pve type fuse.pve (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Signification : Le montage existe. Il peut cependant être lent.
Décision : Ensuite, testez la réactivité en lecture/écriture.

Task 5: Test whether /etc/pve operations hang

cr0x@server:~$ time ls -l /etc/pve/nodes/pve01/qemu-server | head
total 8
-rw-r----- 1 root www-data 1324 Feb  4 09:55 101.conf

real    0m0.012s
user    0m0.002s
sys     0m0.004s

Signification : Une réponse rapide est normale. Si cela prend des secondes ou se bloque, pmxcfs étouffe.
Décision : Si lent/bloqué sur un seul nœud, suspectez une pression locale sur les ressources. Si lent sur tous les nœuds, suspectez de la latence corosync ou une contention pmxcfs à l’échelle du cluster.

Task 6: Check pmxcfs and pve services health

cr0x@server:~$ systemctl status pve-cluster pvedaemon pveproxy --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Tue 2026-02-04 08:01:12 UTC; 2h 11min ago
   Main PID: 1123 (pmxcfs)
      Tasks: 13 (limit: 154263)
     Memory: 52.4M
        CPU: 2min 1.911s

● pvedaemon.service - Proxmox VE API Daemon
     Active: active (running)

● pveproxy.service - Proxmox VE API Proxy Server
     Active: active (running)

Signification : Les services sont « running ». Cela ne signifie pas qu’ils sont réactifs.
Décision : Si « active » mais que l’UI bloque, inspectez les logs et les appels bloquants (tâches suivantes).

Task 7: See if pveproxy is timing out on auth/DNS

cr0x@server:~$ journalctl -u pveproxy -S -2h --no-pager | tail -n 25
Feb 04 10:01:18 pve02 pveproxy[2044]: proxy detected vanished client connection
Feb 04 10:02:41 pve02 pveproxy[2044]: authentication failure; rhost=10.10.30.50 user=admin@pam msg=timeout
Feb 04 10:02:41 pve02 pveproxy[2044]: failed login attempt; user=admin@pam

Signification : Les timeouts d’authent peuvent provenir de lenteurs LDAP/PAM/DNS, pas forcément de mots de passe erronés.
Décision : Si vous voyez des timeouts, testez la résolution de noms et la reachabilité de l’annuaire ; ne « redémarrez pas des services au hasard » pour l’instant.

Task 8: Validate time sync and drift across nodes

cr0x@server:~$ chronyc tracking
Reference ID    : 192.0.2.10
Stratum         : 3
Ref time (UTC)  : Tue Feb 04 10:11:32 2026
System time     : 0.000347812 seconds slow of NTP time
Last offset     : -0.000112345 seconds
RMS offset      : 0.000251901 seconds
Frequency       : 12.345 ppm fast
Leap status     : Normal

Signification : Une bonne synchronisation montre de faibles décalages et un état de leap « Normal ».
Décision : Si le décalage est important ou si le leap status n’est pas normal, corrigez l’heure maintenant. Ne dépannez pas le comportement du cluster tant que les horloges ne sont pas synchronisées.

Task 9: Detect CPU pressure and I/O wait that starves everything

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 812344  54212 9248120    0    0     4    21  920 1800  6  2 88  4  0
 3  1      0 790112  54180 9249008    0    0   120  8020 1100 2100  9  3 44 44  0
 4  2      0 780004  54140 9249912    0    0   200  9100 1200 2400  8  4 36 52  0

Signification : Un wa élevé (I/O wait) indique que le système est bloqué sur le stockage. Un b élevé suggère des processus bloqués.
Décision : Si le wa est constamment élevé pendant l’incident, arrêtez de poursuivre Corosync et allez diagnostiquer le stockage.

Task 10: ZFS health and latency on a node using local ZFS

cr0x@server:~$ zpool status -x
all pools are healthy

Signification : Pas d’erreurs connues sur le pool. Cela ne renseigne pas sur la latence.
Décision : Si c’est lent, vérifiez iostat et le comportement des sync writes ensuite.

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
rpool       320G   1.45T     80   1200  5.4M   98.2M
  mirror    320G   1.45T     80   1200  5.4M   98.2M
    nvme0n1    -      -      40    610  2.7M   49.1M
    nvme1n1    -      -      40    590  2.7M   49.1M

Signification : Écritures lourdes. Si cela corrèle avec des blocages du plan de gestion, vous pourriez saturer le stockage.
Décision : Envisagez de limiter les sauvegardes/réplications, et vérifiez les écritures synchrones (bases, NFS sync, ou ZFS mal réglé).

Task 11: Ceph cluster state (if you run it)

cr0x@server:~$ ceph -s
  cluster:
    id:     1b2c3d4e-5555-6666-7777-88889999aaaa
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 38 sec
  services:
    mon: 3 daemons, quorum a,b,c (age 2h)
    mgr: x(active, since 2h)
    osd: 9 osds: 9 up (since 2h), 9 in (since 2h)
  data:
    pools:   6 pools, 512 pgs
    usage:   12 TiB used, 18 TiB / 30 TiB avail
    pgs:     512 active+clean

Signification : « slow ops » est Ceph qui vous dit poliment que votre stockage souffre.
Décision : Traitez les slow ops comme un incident de production. Mettez en pause les opérations I/O lourdes. Examinez la latence des OSD, le réseau, et les réglages recovery/backfill.

Task 12: Check for network errors on Corosync interfaces

cr0x@server:~$ ip -s link show dev bond0
3: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1234567890  987654      12      0       0       0
    TX:  bytes packets errors dropped carrier collsns
    2233445566  876543       0      0       0       0

Signification : RX errors non nulles est un indice. Douze erreurs peuvent être « rien » ou le sommet d’un iceberg—corrélez dans le temps.
Décision : Si les erreurs augmentent lors d’incidents, vérifiez le câblage, les optiques, le firmware des NIC, les ports du switch, et la cohérence MTU bout en bout.

Task 13: Measure latency and loss between nodes (without fooling yourself)

cr0x@server:~$ mtr -r -c 50 -n 10.10.10.12
Start: 2026-02-04T10:12:01+0000
HOST: pve01                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.10.12               0.0%    50    0.4   0.6   0.3   2.1   0.3

Signification : Bon : faible moyenne, pire cas bas, pas de perte.
Décision : Si le pire cas grimpe à des dizaines/centaines de ms ou si de la perte apparaît, Corosync peut encore sembler « correct » tandis que le reste expire. Corrigez la qualité du chemin réseau.

Task 14: Check for stuck tasks and why migrations/backs ups don’t finish

cr0x@server:~$ pvesh get /cluster/tasks --limit 5
[
  {
    "endtime": 0,
    "id": "UPID:pve02:0000A1B2:00C3D4E5:67A1B2C3:vzdump:105:root@pam:",
    "node": "pve02",
    "pid": 41394,
    "starttime": 1707040801,
    "status": "running",
    "type": "vzdump",
    "user": "root@pam"
  }
]

Signification : Une sauvegarde qui tourne « pour toujours » est souvent corrélée à des blocages de stockage ou à des commits de snapshot qui ne peuvent pas se vider.
Décision : Vérifiez les logs du nœud concerné et la latence du stockage sous-jacent. Ne tuez pas la tâche juste pour le plaisir sans savoir si elle détient des verrous ou des snapshots.

Task 15: Spot HA manager indecision

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Tue Feb  4 10:12:12 2026)
lrm pve01 (active, Tue Feb  4 10:12:11 2026)
lrm pve02 (active, Tue Feb  4 10:12:10 2026)
lrm pve03 (active, Tue Feb  4 10:12:09 2026)

service vm:101 (started)
service vm:102 (freeze) (request_stop)
service ct:203 (started)

Signification : « freeze » indique que la HA ne peut pas progresser—souvent dû à la contention de verrous, à l’indisponibilité du stockage, ou à des agents bloqués.
Décision : Enquêtez sur le stockage de la ressource affectée et les verrous de configuration. Ne forcez pas les actions HA tant que vous ne savez pas sur quoi elles attendent.

Task 16: Find config lock contention (the quiet killer)

cr0x@server:~$ ls -l /var/lock/pve-manager
total 0
-rw-r----- 1 root www-data 0 Feb  4 10:08 vzdump.lock
-rw-r----- 1 root www-data 0 Feb  4 10:09 pve-storage-lock

Signification : Les verrous existent pendant les opérations normales, mais s’ils persistent longtemps, quelque chose est coincé.
Décision : Corrélez l’âge des verrous avec la liste des tâches et la performance du stockage. Si un verrou est obsolète à cause d’un processus crashé, résolvez la tâche bloquée en toute sécurité avant de supprimer les verrous.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne exploitait un cluster Proxmox trois nœuds pour des services internes. Tout était « redondant » : NICs doubles, deux switches,
RAID sur les hyperviseurs. Ils en étaient fiers. À raison.

Puis un lundi matin, l’UI gelait de façon intermittente. Les migrations pendaient. Des sauvegardes qui prenaient habituellement des minutes prirent des heures.
L’astreint fit le rituel : vérifia pvecm status. Quorum. Aucun nœud parti. Corosync semblait propre.
Ils déduisirent donc que le réseau de cluster allait bien et commencèrent à fouiller dans les logs UI de Proxmox.

La mauvaise hypothèse : « Si Corosync a le quorum, le réseau du cluster est sain. »
Le quorum signifiait seulement que les nœuds pouvaient encore échanger assez de messages pour s’accorder sur l’adhésion. Cela ne disait rien sur la latence en queue de pointe.

La vraie cause était un port de switch défaillant d’une façon qui ne coupait pas complètement le lien. Il introduisait des micro-burst intermittents et des erreurs CRC.
Les liens knet de Corosync récupéraient vite, donc l’adhésion restait stable. Mais les écritures pmxcfs étaient retardées, et l’API attendait constamment des réponses du système de fichiers du cluster.

La réparation fut ennuyeuse : remplacement du câble et du SFP suspects, déplacement sur un autre port, vérification que les compteurs d’erreurs restaient plats.
Le « mystère » disparut instantanément. Le postmortem ajouta une ligne qui comptait : mesurez les compteurs d’erreur réseau et la latence, pas seulement le quorum.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre organisation avait un déploiement Proxmox+Ceph. Ils voulaient moins d’avertissements « Corosync token timeout » pendant des fenêtres de forte charge.
Quelqu’un proposa d’augmenter le token timeout et les temps de consensus pour que Corosync tolère la lenteur temporaire.
Le changement réduisit le bruit dans les logs. Tout le monde célébra. Bref.

Des semaines plus tard, une maintenance de stockage déclencha une recovery Ceph qui satura le réseau backend.
Le cluster resta quoré. C’était le problème. Les nœuds restèrent membres tout en devenant progressivement non réactifs sous I/O wait.
Les décisions HA furent retardées. Les migrations se mirent en file. L’UI était à moitié fonctionnelle—juste assez pour créer une fausse confiance.

L’« optimisation » a aggravé le mode de défaillance en étirant la fenêtre où tout était techniquement connecté mais pratiquement inutilisable.
Les opérateurs attendirent plus longtemps avant de déclarer un incident parce que « Corosync est stable ». Pendant ce temps, l’impact métier augmentait.

La réparation finale ne fut pas seulement un retour en arrière sur les timeouts. Ils séparèrent le trafic : Corosync sur un réseau faible latence et non congestionné ;
recovery Ceph ajustée pour éviter la saturation ; et ajout d’alertes sur la latence tail et les slow ops plutôt que sur les flaps d’adhésion.
Les token timeouts revinrent près des valeurs par défaut. Le bruit des logs remonta ; les vraies pannes diminuèrent.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un environnement régulé exploitait Proxmox pour des charges critiques. L’équipe était conservatrice au point d’énerver.
Ils maintenaient une règle stricte : chaque nœud avait un accès de gestion hors-bande, une procédure documentée de « shutdown sûr »,
et un exercice trimestriel où ils s’entraînaient à récupérer d’échecs partiels sans improviser.

Lors d’un incident d’alimentation, un nœud revint avec un pool de stockage dégradé et des erreurs I/O intermittentes. Le quorum Corosync tint,
mais les opérations de gestion devinrent peu fiables : changements de config parfois bloqués, sauvegardes en panne, et HA hésitante à reloger des charges.

Au lieu de s’agiter, ils suivirent le playbook : geler les changements, identifier le nœud défaillant, évacuer les VM mobilisables en toute sécurité,
et garder le reste stable. Ils utilisèrent l’accès hors-bande pour confirmer les erreurs matérielles, puis retirèrent le nœud de la planification.

La pratique ennuyeuse—étapes documentées, ordre d’opérations connu, et refus de « juste cliquer partout »—empêcha qu’un problème matériel embrouillé
ne devienne un incident global. L’activité métier n’en souffrit que très peu. L’équipe retourna à l’ennui de leurs propres processus,
ce qui est exactement l’ambiance souhaitable pour le travail de fiabilité.

Blague #2 : Si votre cluster fonctionne sur la « connaissance tribale », félicitations—vous avez inventé un point unique de défaillance qui a des sentiments.

Erreurs fréquentes : symptôme → cause racine → correctif

1) Symptom: Quorum is “Yes,” but GUI actions hang

Cause racine : latence pmxcfs ou contention de verrous ; appels API bloqués en attente de /etc/pve.
Correctif : Testez la latence de ls /etc/pve sur plusieurs nœuds ; vérifiez CPU/I/O wait ; réduisez la charge ; résolvez les tâches bloquées tenant des verrous.

2) Symptom: HA shows “freeze” or repeated restart attempts

Cause racine : la HA ne peut confirmer l’état à cause de timeouts de stockage, verrous, ou mises à jour retardées du filesystem de cluster.
Correctif : Vérifiez ha-manager status, les tâches, et la santé du stockage ; stabilisez le stockage d’abord ; évitez de forcer les démarrages jusqu’à ce que l’état soit cohérent.

3) Symptom: Migrations start and then stall at a fixed percentage

Cause racine : le backend de stockage ne suit pas (slow ops Ceph, latence NFS, pression ZFS sync), ou le débit réseau s’effondre sous contention.
Correctif : Mesurez la latence du stockage, vérifiez les slow ops Ceph, vérifiez les erreurs NIC ; suspendez les autres activités I/O lourdes ; assurez-vous que le réseau de migration n’est pas partagé avec un stockage saturé.

4) Symptom: Corosync logs show token warnings but quorum stays

Cause racine : pics de latence tail dus à la congestion, problèmes IRQ, ou famine CPU ; des reconfigurations peuvent se produire sans perte totale d’adhésion.
Correctif : Traitez comme un incident réseau/hôte ; vérifiez ip -s link, ethtool -S, mtr et la attente CPU ; corrigez le chemin sous-jacent.

5) Symptom: Random “permission denied” or TLS/auth issues after “nothing changed”

Cause racine : dérive temporelle entre nœuds ; fenêtres de validation de certificats violées ; échecs d’authentification Kerberos/LDAP sensibles au temps.
Correctif : Corrigez chrony/NTP, validez la dérive sur tous les nœuds, puis retestez les flux d’auth. Ne commencez pas par faire tourner des certificats.

6) Symptom: Only one node is “slow,” but it doesn’t leave the cluster

Cause racine : problèmes matériels ou noyau locaux : erreurs disque, dégradation ZFS, erreurs NIC, pression mémoire.
Correctif : Comparez métriques et logs avec un nœud sain ; évacuez les charges ; enquêtez sur le matériel ; ne laissez pas un nœud malade empoisonner le plan de contrôle.

7) Symptom: Everything gets bad during backups

Cause racine : les sauvegardes saturent le stockage ou le réseau ; les commits de snapshot sont lents ; des verrous sont maintenus plus longtemps ; les opérations de gestion s’accumulent.
Correctif : Échelonnez les sauvegardes, limitez la bande passante des sauvegardes, séparez le trafic de sauvegarde, et assurez une marge pour le stockage. Les sauvegardes doivent être ennuyeuses, pas un test de charge.

Listes de contrôle / plan pas-à-pas

Checklist A: When the cluster “feels slow” but quorum is fine

Geler les changements. Pas de nouvelles configurations de stockage, pas d’éditions de pare-feu, pas de remaniement HA tant que le blocage n’est pas compris.
Choisir un nœud « mauvais » et un nœud « bon ». Exécutez les mêmes contrôles ; les différences sont en or.
Confirmer la stabilité d’adhésion : pvecm status, corosync-cfgtool -s, journal Corosync.
Tester la réactivité de pmxcfs : un rapide ls sous /etc/pve en mesurant le temps.
Vérifier verrous et tâches bloquées : pvesh get /cluster/tasks, inspecter les fichiers de lock.
Mesurer la pression hôte : vmstat, charge, I/O wait, pression mémoire.
Mesurer la qualité réseau : compteurs d’erreurs + mtr entre nœuds sur le ring Corosync.
Mesurer la santé du stockage : ZFS iostat/status ou slow ops Ceph.
Pensez au tuning seulement ensuite. Tuner sans mesurer, c’est construire un désastre lent mais « stable ».

Checklist B: Stabilize first, then recover functionality

Arrêter les multiplicateurs de charge : mettre en pause migrations, reporter les sauvegardes, limiter recovery/backfill si sur Ceph (avec précaution).
Isoler le nœud malade : si un nœud montre des erreurs/latence, migrer ce qui peut l’être et le retirer des décisions HA jusqu’à réparation.
Vérifier la synchro horaire : assurez-vous que les horloges s’accordent avant d’interpréter les logs et les événements de fencing.
Rétablir le réseau de référence : éliminer perte de paquets, erreurs CRC, incohérences MTU et liens congestionnés.
Rétablir le stockage de référence : corriger erreurs disque, réparer pools dégradés, traiter les slow ops, assurer de l’espace libre suffisant.
Réactiver les opérations progressivement : migrations/sauvegardes une par une, surveiller latence et logs.

Checklist C: Hardening so this doesn’t happen again

Séparer les classes de trafic : Corosync sur liens faible-latence ; stockage sur son propre réseau ; migrations séparées si possible.
Alerter sur la latence tail, pas seulement sur « up/down ». Les alarmes de quorum sont nécessaires mais insuffisantes.
Planifier la capacité pour sauvegardes et recoveries. Si votre cluster ne peut pas gérer un événement de recovery plus la charge normale, il n’est pas résilient.
Tester les exercices de panne. Entraînez-vous au « un nœud lent », « un lien qui flappe », « slow ops stockage ». Les vrais incidents ne doivent pas être vos premières répétitions.

FAQ

1) Why does `pvecm status` show “Quorate: Yes” when the GUI is unusable?

Parce que le quorum concerne l’adhésion et le vote, pas la réactivité. L’interface dépend de pmxcfs et des démons API qui peuvent se bloquer sur I/O, verrous, DNS ou latence de stockage.

2) If Corosync shows no faults, can the network still be the problem?

Oui. Des pics courts, microbursts, erreurs CRC et jitter peuvent ruiner la latence tail sans faire chuter l’adhésion. Vérifiez les compteurs et mtr, pas seulement le statut du ring.

3) Should I increase Corosync token timeout to stop flapping?

Seulement après avoir prouvé que le réseau et l’ordonnancement hôte sont stables et que vous en avez toujours besoin. Augmenter les timeouts peut masquer de vrais problèmes de latence et retarder la détection de panne.

4) What’s the quickest way to tell if pmxcfs is the bottleneck?

Mesurez le temps d’un simple ls dans /etc/pve sur plusieurs nœuds. S’il est lent ou se bloque, pmxcfs est impliqué. Ensuite vérifiez CPU et I/O wait.

5) Can storage problems really affect Corosync and cluster management?

Absolument. Les blocages de stockage provoquent de l’I/O wait, qui retarde les processus et l’ordonnancement. Corosync peut continuer à échanger assez de messages, mais pmxcfs et les appels API en pâtiront.

6) How does time drift break a Proxmox cluster if quorum is fine?

La dérive peut casser TLS/auth, embrouiller les logs, et provoquer des décisions incohérentes en HA ou fencing. Corrigez la sync horaire avant un dépannage plus profond.

7) Why do migrations hang more often than “normal VM runtime” during incidents?

Les migrations amplifient les besoins en bande passante et stockage et sont sensibles à la latence. Une VM peut survivre avec cache et réessais ; une migration est une boucle serrée qui expire.

8) What should I do if one node is slow but still part of the cluster?

Traitez-le comme une défaillance partielle : évacuez les charges quand c’est sûr, réduisez ce qui dépend de ce nœud, et enquêtez sur le matériel/réseau/stockage de cet hôte spécifiquement.

9) Is it safe to restart corosync or pmxcfs during an incident?

Parfois, mais ce n’est pas un geste de premier recours. Un redémarrage peut provoquer des changements d’adhésion et un churn de verrous. Stabilisez d’abord réseau/stockage, puis redémarrez avec un objectif clair.

10) What’s the best “single metric” to alert on for these issues?

Il n’y en a pas une seule. Combinez : réactivité pmxcfs (checks synthétiques), perte/jitter réseau, latence de stockage/slow ops, et I/O wait hôte. Le quorum seul est un métrique rassurant mais insuffisant.

Prochaines étapes à faire cette semaine

Si vous exploitez Proxmox en production, voici le chemin pratique qui change réellement les résultats :

Ajouter un check synthétique pmxcfs : mesurer et alerter si ls /etc/pve dépasse un seuil faible sur n’importe quel nœud.
Alerter sur les erreurs réseau des interfaces Corosync : erreurs CRC, drops, flaps de lien. Cela détecte tôt les dégradations « quorum OK ».
Alerter sur la latence stockage : anomalies ZFS iostat, slow ops Ceph, retransmissions client NFS. Le stockage est la majorité silencieuse de ces incidents.
Garder les timeouts Corosync raisonnables : n’utilisez pas le tuning comme pansement pour un mauvais réseau. Si vous devez tuner, documentez pourquoi et quelles mesures le justifient.
Réaliser un exercice de panne : simulez un réseau de stockage congestionné ou un lien qui flappe et entraînez-vous à « stabiliser d’abord ». Votre futur vous remerciera et sera un peu moins fatigué.

Corosync ne vous ment pas. Il répond juste à une question plus petite que celle que vous posez.
Si vous voulez un cluster qui survit, mesurez l’organisme entier—qualité réseau, latence stockage, réactivité du plan de contrôle—et traitez le « quorum: yes » comme le début du diagnostic, pas la fin.