Un cluster Proxmox VE de 47 nœuds conservant les temporisateurs historiques de Corosync peut atteindre environ 70,95 secondes entre token et consensus avant de compléter une nouvelle adhésion après une perte d’un nœud. Ce chiffre ne représente pas le temps total de récupération des machines virtuelles, mais révèle un problème important : il dépasse le délai de watchdog de 60 secondes utilisé par Proxmox HA pour le self-fencing. Ainsi, une infrastructure de cette taille doit réviser sa configuration avant de supposer que les valeurs héritées restent appropriées.
Les clés de Corosync dans un cluster Proxmox de 47 nœuds en 20 secondes
- Avec un
tokende base de 3 000 ms et un coefficient de 650 ms, 47 nœuds portent letokeneffectif à 32,25 secondes. - Le
consensusautomatique monte à environ 38,70 secondes. - La somme atteint approximativement 70,95 secondes.
- Avec un coefficient de 125 ms utilisé dans les nouveaux clusters Proxmox VE 9.2, il descend à environ 18,98 secondes.
- Au-delà de 32 nœuds, il est également conseillé de vérifier d’autres paramètres, notamment la qualité du réseau de Corosync.
La différence avec un cluster de 10 ou 15 serveurs est significative, car le temps effectif de Corosync n’est pas constant lorsque l’on modifie token_coefficient.
Ce mécanisme a une logique : à mesure que le nombre de membres augmente, Corosync introduit davantage de marge pour que le protocole d’adhésion fonctionne sans que l’administrateur ait à ajuster manuellement le token chaque fois qu’un nœud est ajouté.
Le problème apparaît lorsque un cluster, après des années de croissance, utilise encore une configuration héritée. Un paramètre pertinent à +5 serveurs pouvait avoir peu d’impact, mais peut devenir un délai supplémentaire de dizaines de secondes quand le nombre de nœuds dépasse une trentaine.
De 3 secondes à 32,25 secondes pour le token effectif
Dans les versions traditionnelles de Corosync utilisées par Proxmox, le token démarre à 3 000 millisecondes et le token_coefficient historique est de 650 ms par défaut si rien n’est spécifié autrement.
Pour au moins trois nœuds, le temps effectif se calcule ainsi :
token effectif = token + (nœuds - 2) × token_coefficient
Cette formule est documentée par Corosync. Elle vise à augmenter le délai automatiquement avec la croissance du cluster.
Pour 47 nœuds :
3 000 + (47 - 2) × 650
Les 45 nœuds supplémentaires par rapport aux deux premiers donnent :
45 × 650 = 29 250 ms
Ainsi, le délai effectif est :
3 000 + 29 250 = 32 250 ms
Ce qui donne un token effectif de 32,25 secondes.
Quand il n’est pas fixé explicitement, Corosync le calcule en prenant au minimum 1,2 fois le token effectif :
32 250 × 1,2 = 38 700 ms
Et en sommant :
32 250 + 38 700 = 70 950 ms
Ce qui est approximativement 70,95 secondes.
| Paramètre | 47 nœuds, coefficient 650 ms |
|---|---|
| Token de base | 3 000 ms |
| Incrément par nœud | 29 250 ms |
| Token effectif | 32 250 ms |
| Consensus approximatif | 38 700 ms |
| Token + consensus | 70,95 s |
Ces temporisateurs sont calculés et ne correspondent pas à une mesure réelle du délai de récupération des applications.
Il est important de faire cette distinction. Après avoir formé la nouvelle adhésion, d’autres éléments comme Proxmox HA Manager, fencing, stockage, disponibilité CPU/RAM, démarrage des VM et récupération des services peuvent aussi intervenir.
Mais 70,95 secondes attirent l’attention pour une autre raison.
Les 70,95 secondes entrent en conflit avec le watchdog de Proxmox HA
Proxmox utilise un watchdog dans le cadre de sa gestion du self-fencing.
Un nœud HA qui perd son quorum ne peut plus maintenir correctement ce watchdog. S’il ne récupère pas rapidement, il se redémarrera quand le délai expire. La documentation de Proxmox indique un timeout d’environ 60 secondes pour ce processus.
L’objectif est d’éviter qu’un nœud isolé continue d’exécuter des VM alors qu’une autre partie du cluster pense pouvoir les récupérer ailleurs.
Proxmox insiste donc sur le fait que le temps nécessaire pour former la nouvelle adhésion doit maintenir une marge suffisante par rapport au watchdog.
Avec 29 nœuds et 650 ms, la somme calculée était d’environ 45,21 secondes. Avec 47 nœuds, elle atteint 70,95 secondes.
Ce n’est plus simplement s’approcher du seuil de 60 secondes : la configuration théorique le dépasse clairement.
Cela ne signifie pas nécessairement que le cluster de 47 nœuds va redémarrer ses serveurs à chaque perte d’un membre. Le comportement exact dépend de quels nœuds perdent la connectivité, de la topologie réseau, du quorum, des messages échangés par Corosync, et d’autres temporisateurs.
Mais il est certain qu’un cluster de 47 nœuds ne devrait pas utiliser ces valeurs sans une révision explicite.
Avec 125 ms, le même cluster tombe à environ 19 secondes
Proxmox a réagi en réduisant la valeur du coefficient dans ses nouvelles configurations.
Dans la documentation pour Proxmox VE 9.2, il est spécifié un token_coefficient de 125 millisecondes pour les nouveaux clusters, en remplacement du comportement historique de 650 ms.
Pour le même cluster de 47 nœuds, le calcul est :
3 000 + (47 - 2) × 125
45 × 125 = 5 625 ms
Soit :
3 000 + 5 625 = 8 625 ms
Le consensus approximatif :
8 625 × 1,2 = 10 350 ms
Et la somme donne :
8 625 + 10 350 = 18 975 ms
Soit environ 18,98 secondes.
| Configuration | Token effectif | Consensus | Total approximatif |
|---|---|---|---|
| 47 nœuds, 650 ms | 32,25 s | 38,70 s | 70,95 s |
| 47 nœuds, 125 ms | 8,63 s | 10,35 s | 18,98 s |
La réduction approche 52 secondes en ne modifiant que le coefficient utilisé pour calculer ces temporisateurs.
En pourcentage, la somme de token + consensus diminue d’environ 73 %.
Cela ne garantit pas qu’une VM se récupérera 52 secondes plus tôt dans une situation d’incident, car d’autres étapes interviennent. Mais cela représente une réduction très significative d’une partie du processus de détection et de réorganisation du cluster.
Mettre à jour depuis Proxmox 8 n’implique pas nécessairement de recevoir la nouvelle valeur
C’est un point crucial que les administrateurs doivent vérifier.
Le nouveau comportement s’applique lors de la création de nouveaux clusters avec les versions actuelles de Proxmox VE. Une infrastructure existante conserve généralement son corosync.conf, et une mise à jour depuis une version antérieure ne modifie pas automatiquement ses paramètres Corosync.
Ainsi, un cluster ayant évolué sur plusieurs années peut exécuter Proxmox VE 9 tout en utilisant une configuration conçue à l’origine pour beaucoup moins de nœuds.
Pour vérifier si la configuration effective a évolué, il suffit d’exécuter :
corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'L’important est de regarder la valeur réelle en cours d’utilisation, et non de la déduire simplement de la version installée.
Dans un cluster de 47 nœuds utilisant encore le coefficient historique, on devrait obtenir :
runtime.config.totem.token = 32250
runtime.config.totem.consensus = 38700Avec le coefficient de 125 ms, ces valeurs seraient plutôt :
runtime.config.totem.token = 8625
runtime.config.totem.consensus = 10350Il est essentiel d’obtenir ces valeurs directement depuis le cluster, et pas simplement d’après la version de Proxmox.
De plus, modifier directement token_coefficient en se basant sur une table ou une recommandation sans analyse approfondie n’est pas conseillé. Corosync souligne que ces temporisateurs doivent rester cohérents et adaptés à la réalité du réseau.
Réduire les temporisateurs sur un réseau avec perte de paquets, jitter ou latence variable peut entraîner des détections de panne fausses et des comportements indésirables.
Attention à Corosync quand le cluster dépasse 32 nœuds : un nouveau paramètre
Un cluster de 47 nœuds introduit aussi une autre considération documentée par Corosync, propre aux configurations de grandes tailles.
Pour les anneaux avec plus de 32 nœuds, le paramètre send_join peut devenir pertinent lors de la formation de nouvelles adhésions. La documentation explique qu’il est généralement non nécessaire en dessous de 32 nœuds, mais qu’au-delà, il est conseillé de prêter attention à cette option pour éviter une avalanche de messages join lors de l’établissement d’un nouveau cercle.
Le manuel recommande aussi de faire coïncider tous les autres temporisateurs et de consulter un spécialiste pour des configurations volumineuses.
Dans ce contexte, un cluster de 47 nœuds n’est plus une simple extrapolation mathématique : il requiert une gestion spécifique de Corosync comme une infrastructure autonome, plutôt qu’un simple réseau secondaire.
Proxmox ne limite pas explicitement le nombre maximum de nœuds, mais sa documentation indique qu’il dépend surtout de la capacité des hôtes et de la qualité du réseau. Des déploiements de plus de 50 nœuds sont possibles, sous réserve de bonnes performances réseau.
Les réseaux lors de clusters grands : la clé, c’est la latence
Corosync n’a pas besoin d’un débit immense dans des conditions normales, mais exige latence basse, stabilité et absence de perte de paquets.
Dans un cluster de 47 serveurs, le nombre d’interactions et d’événements à traiter lors du changement d’adhésion augmente significativement.
Il est donc crucial de vérifier, comme minimum, la latence, la perte, la redondance des liens, le commutage, la taille MTU, la saturation du réseau, l’isolement du trafic, et le fonctionnement de Kronosnet.
En présence de HA, il faut aussi tester concrètement la réactivité en cas de perte d’un nœud.
Ce n’est pas suffisant d’observer simplement la déconnexion dans l’interface Proxmox. La performance essentielle est le délai entre la panne et la reprise effective des services, mesurée depuis un autre hôte.
Le délai réel inclut :
Détection Corosync → formation de la nouvelle adhésion → fencing → HA Manager → accès au stockage → démarrage de la VM → lancement de l’application
Chaque architecture produira un temps spécifique. La capacité de chaque nœud joue aussi un rôle : un cluster de 47 nœuds peut voir ses temporisateurs efficaces, mais échouer si ses autres ressources, CPU ou RAM, ne suivent pas en nombre ou performances.
Même problème pour le stockage : si la VM repose sur une plateforme partagée ou distribuée dégradée, accélérer Corosync seul n’assurera pas une récupération rapide.
D’où l’intérêt de considérer le token comme un indicateur, mais pas comme seul levier d’optimisation HA.
Dans un grand cluster de 47 nœuds, une valeur autour de 70,95 secondes est un signal qu’il faut revoir la conception. Un délai de 18,98 secondes indique aussi que la partie critique dispose de beaucoup plus de marge par rapport au watchdog, mais cela ne garantit pas une haute disponibilité immédiate.
Foire aux questions
Combien durerait le Corosync avec 47 nœuds et un coefficient de 650 ms ?
Avec un token de base de 3 000 ms, le token effectif serait d’environ 32,25 secondes, le consensus d’environ 38,70 secondes, pour une somme d’environ 70,95 secondes.
Quel serait le temps avec un token_coefficient de 125 ms ?
Dans le même cluster, le token effectif descend à environ 8,63 secondes, le consensus à 10,35 secondes, totalisant environ 18,98 secondes.
Mettre à jour vers Proxmox VE 9 modifie-t-il automatiquement ce paramètre ?
Pas nécessairement. La valeur de 125 ms est spécifiée pour les clusters neufs. Un cluster existant peut conserver ses paramètres hérités. La meilleure pratique est de consulter directement la configuration effective via :
corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'Il faut vérifier les valeurs en cours d’utilisation, et pas compter sur la version installée de Proxmox.
Peut-on changer directement le coefficient de 650 à 125 ms ?
Ce n’est pas recommandé sans une analyse préalable du réseau et du comportement du cluster. Une réduction excessive des temporisateurs dans un réseau instable peut produire de faux détections de panne et perturber la stabilité globale.
Sources :
- Proxmox VE, Cluster Manager, documentation officielle sur Corosync, taille du cluster et quorum.
- Corosync,
corosync.conf(5), documentation surtoken,token_coefficient,consensusetsend_join. - Proxmox VE, documentation technique HA et mécanismes de fencing.