Corosync est l’un des composants clés qui permettent à plusieurs serveurs Proxmox VE de fonctionner en cluster coordonné. Son rôle ne consiste pas à exécuter des machines virtuelles ni à stocker leurs disques, mais à assurer la communication entre les nœuds, à gérer l’adhésion au cluster et à fournir les informations nécessaires pour déterminer si un quorum est atteint. C’est une pièce peu visible lors du fonctionnement quotidien, mais essentielle en cas de panne d’un serveur ou d’une connexion réseau.

Les éléments essentiels de Corosync dans Proxmox en 20 secondes

• Corosync maintient la coordination entre les nœuds formant un cluster Proxmox.
• L’adhésion (membres) définit quels serveurs font partie du cluster, tandis que le quorum indique si la majorité est atteinte.
• Proxmox utilise Corosync avec pmxcfs, Kronosnet et son système de haute disponibilité (HA).
• Ses temporisateurs facilitent la détection des défaillances et la réorganisation de l’adhésion.
• Un réseau stable, redondant et à faible latence est plus crucial que de disposer d’un très large débit.

Lorsque vous créez un cluster avec pvecm, Proxmox configure cette infrastructure de communication presque automatiquement, sans que l’administrateur ait à manipuler directement tous ses composants. C’est pourquoi il est possible de gérer Proxmox pendant des années sans entrer dans les détails de Corosync.

Comprendre son fonctionnement est utile, car des concepts comme cluster, quorum, Corosync, fencing, watchdog, QDevice, HA ou Ceph sont liés, mais abordent des problématiques différentes. Les confondre peut conduire à penser qu’une infrastructure rassemblant simplement plusieurs serveurs est forcément hautement disponible.

Qu’est-ce que Corosync et quel est son rôle dans Proxmox

Corosync est un moteur de communication pour clusters, utilisé par plusieurs projets d’HA sous Linux. Proxmox VE l’intègre comme composant clé de son architecture de clustering afin que les serveurs aient une vision cohérente de qui appartient au cluster.

Une installation peut par exemple comprendre :

Les serveurs doivent savoir qu’ils partagent le même cluster et maintenir une information actualisée sur la présence des autres.

Si PVE03 ne répond plus, il ne suffit pas de le marquer comme déconnecté. PVE01 et PVE02 doivent convenir d’une nouvelle adhésion dans laquelle PVE03 ne participe plus.

C’est ici qu’intervient l’une des principales fonctions de Corosync.

L’adhésion (membres)

L’adhésion décrit quels nœuds font partie du cluster à un moment donné.

Elle peut changer lorsqu’un serveur s’éteint, redémarre, perd sa connectivité ou revient en ligne.

Ce concept est important car un serveur apparemment disparu peut continuer à fonctionner, mais être isolé à cause d’un problème réseau.

Le quorum

Le second concept est le quorum.

Proxmox utilise un modèle basé sur des votes pour déterminer si une partie du cluster dispose d’une majorité suffisante pour continuer à fonctionner.

Dans un exemple simple de trois nœuds :

Nœud	Votos
PVE01	1
PVE02	1
PVE03	1
Total	3

Si PVE03 ne répond plus, il reste deux votes sur trois. La majorité est atteinte, donc il y a quorum.

En cas d’isolement complet de PVE01, il n’a qu’un seul vote. Il ne peut pas savoir si PVE02 et PVE03 sont éteints ou simplement séparés par une coupure réseau.

Le quorum empêche que deux parties agissent simultanément sur les mêmes ressources, évitant ainsi le risque de split brain, une situation critique en systèmes distribués où différents groupes de serveurs pourraient croire qu’ils sont la partie valable du cluster.

C’est pour cette raison que la configuration en trois nœuds est privilégiée dans Proxmox. Ce n’est pas parce que trois serveurs virtualisent mieux que deux, mais parce que trois votes permettent de conserver une majorité de deux, même après la perte d’un membre.

Corosync, Kronosnet, pmxcfs et QDevice : comment s’articulent ces composants

Corosync ne fonctionne pas seul. Autour de lui gravitent plusieurs autres composants qu’il est utile de distinguer.

Composant	Rôle principal
Corosync	Communication, adhésion et gestion du quorum du cluster
Kronosnet (knet)	Transport des communications entre nœuds
pmxcfs	Système de fichiers distribué pour la configuration de Proxmox
pvecm	Outil Proxmox pour gérer le cluster
QDevice	Vote externe pour certains modes de quorum
Watchdog	Aide à isoler un nœud problématique via un redémarrage automatique en HA
HA Manager	Gestion des ressources protégées par haute disponibilité

Séparer ces fonctions permet de mieux comprendre ce qui se passe en cas de défaillance d’un composant.

Kronosnet : le transport

Les versions actuelles de Corosync utilisent Kronosnet, souvent appelé knet, comme couche de transport.

Il se charge de transporter les communications entre les nœuds et permet l’utilisation de multiples liens entre eux.

Ce qui a une conséquence pratique : un cluster peut disposer d’une redondance pour la communication de Corosync.

Mais cette redondance doit être mise en place dans l’infrastructure.

Deux liens configurés sur des VLAN différents mais passant par la même carte réseau, switch ou chemin physique peuvent continuer à partager un point de défaillance unique.

pmxcfs : la configuration distribuée de Proxmox

Proxmox intègre un composant essentiel : Proxmox Cluster File System (pmxcfs).

C’est le système de fichiers monté sous /etc/pve, permettant de distribuer la configuration du cluster entre ses nœuds.

On y trouve la configuration des machines virtuelles, le stockage, les utilisateurs et autres éléments Proxmox.

pmxcfs utilise les informations fournies par Corosync pour maintenir la cohérence du cluster. Lorsqu’un nœud perd le quorum, le comportement de ce système change pour éviter d’éventuelles modifications conflictuelles.

C’est pourquoi un administrateur peut constater que /etc/pve devient en lecture seule après une perte de quorum. Ce n’est pas un simple problème de droits d’accès au système de fichiers.

pvecm : l’outil visible par l’administrateur

Proxmox fournit pvecm comme interface d’administration du cluster.

Un des commandes de base est :

pvecm status

Il permet de consulter des informations telles que le nombre de nœuds, de votes, le quorum et l’état général.

Il est aussi utile de taper :

pvecm nodes

La configuration de Corosync utilisée par Proxmox se trouve dans :

/etc/pve/corosync.conf

Ce fichier fait partie de la configuration critique du cluster et ne doit pas être modifié sans connaître ses conséquences.

QDevice : pourquoi apparaît dans les clusters à deux nœuds

Un cluster de deux nœuds pose un problème évident.

Si chaque serveur a un vote et que la communication entre eux est coupée, aucun ne peut savoir si l’autre est éteint ou simplement isolé.

Une solution proposée par Proxmox pour certains petits clusters consiste à ajouter un QDevice, généralement appuyé par un QNetd externe.

Son rôle peut être compris comme étant une extension du vote externe dans le processus de quorum.

Il n’est pas nécessaire que cet élément supplémentaire soit un autre serveur Proxmox capable de faire tourner des VM.

Cela permet de construire une architecture du type :

Élément	Fonction
PVE01	Cœur + vote
PVE02	Cœur + vote
QDevice	Arbitrage de quorum

Là où le détail est important : QDevice aide pour le quorum, mais il ne garantit pas la récupération automatique.

Si PVE01 tombe, PVE02 peut maintenir la situation nécessaire pour continuer à fonctionner grâce au mécanisme de quorum, mais toutes les machines devant être récupérées devront tenir dans PVE02.

Un troisième vote ne fournit ni RAM, ni CPU, ni stockage.

Token et consensus : comment Corosync détecte un changement

Pour maintenir le cluster en coordination, Corosync utilise différents temporisateurs. Deux parmi les plus connus sont token et consensus.

token fait partie du mécanisme de détection des problèmes de circulation du token entre membres.

consensus intervient lors de l’établissement d’une nouvelle adhésion.

Ces paramètres expliquent pourquoi la disparition d’un serveur ne provoque pas une réaction immédiate. Dans un système distribué, réagir trop vite peut aussi être dangereux.

Une perte de paquets ou quelques millisecondes de congestion ne devraient pas faire considérer un serveur en parfait état comme étant défaillant.

C’est pour cela que ces temporisateurs existent.

Ils expliquent aussi pourquoi diminuer à tout prix la valeur de Corosync pour accélérer le basculement peut en réalité produire l’effet inverse : un réseau instable peut provoquer des fausses détections et des changements de membres inutiles.

La taille du cluster influence également ces réglages. Corosync dispose de token_coefficient, qui permet de majorer le temps effectif en fonction du nombre de nœuds.

Ce paramètre a récemment été particulièrement examiné car Proxmox VE 9.2 utilise un coefficient explicite de 125 ms lors de la création de nouveaux clusters, par opposition au comportement historique associé à 650 ms quand aucune valeur n’est spécifiée.

Ce changement est surtout notable dans les grands clusters, mais une installation mise à jour depuis une version antérieure peut conserver ses réglages existants. Il est donc plus fiable de consulter les valeurs effectives plutôt que de se fier uniquement à la version installée.

On peut vérifier cela avec :

corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'

Ces temporisateurs méritent d’être révisés dans des infrastructures importantes, mais Corosync dépasse largement token et consensus. Se concentrer uniquement sur ces chiffres risque de faire oublier sa fonction principale : assurer une vision cohérente du cluster.

Quel lien entre Corosync et Proxmox HA

Corosync n’est pas le système de haute disponibilité de Proxmox en soi.

Il fournit une partie de l’information nécessaire à HA pour fonctionner.

Lorsqu’une machine virtuelle est configurée comme ressource HA, Proxmox HA Manager surveille où elle devrait être exécutée et peut réagir face à certains types de défaillances.

En cas de disparition soudaine d’un hôte, le processus se décompose en plusieurs étapes :

1. Perte du nœud ou de sa connectivité.
2. Corosync détecte le changement.
3. Les membres survivants établissent une nouvelle adhésion.
4. On vérifie si le quorum est toujours atteint.
5. Les mécanismes de fencing s’assurent que le nœud problématique ne puisse pas provoquer de conflits.
6. Le HA Manager peut restaurer les ressources sur d’autres serveurs.

Cela explique pourquoi HA n’est pas la même chose que la migration à chaud (Live Migration).

Lors d’une migration en direct, le serveur d’origine continue à fonctionner et participe activement au déplacement de la VM.

En cas de panne soudaine, le serveur initial peut avoir disparu complètement. La VM doit alors être récupérée dans un autre nœud et relancée.

Watchdog et fencing

Proxmox utilise un watchdog dans son architecture HA.

Si un nœud perd le quorum et ne peut pas maintenir correctement le watchdog, celui-ci peut entraîner son redémarrage. Proxmox prévoit environ 60 secondes pour cette opération de self-fencing.

La logique est prudente.

Avant de permettre à un autre serveur de prendre le relais de certains ressources, il est d’abord important de s’assurer que le nœud isolé ne continue pas à les utiliser.

Le fencing a précisément pour but d’empêcher deux hôtes d’être simultanément propriétaires du même resource.

Cela explique aussi la relation entre temporisateurs de Corosync et watchdog. Proxmox recommande de laisser un marge suffisante pour que la nouvelle adhésion puisse s’établir avant de déclencher le fencing.

Une architecture réseau spécifique pour Corosync

L’une des particularités de Corosync est qu’il n’a pas forcément besoin de beaucoup de bande passante, mais nécessite une connexion stable et à faible latence.

Ce point est crucial.

Une interface de 1 Gbit/s stable peut suffire pour certains environnements, alors qu’une connexion à 25 Gbit/s saturée par Ceph, migrations et sauvegardes peut en réalité poser problème au trafic du cluster.

La documentation de Proxmox recommande de faire très attention à ce réseau et propose de configurer plusieurs liens avec Kronosnet.

Dans un environnement professionnel, il est conseillé de vérifier :

• la latence entre les nœuds ;
• la perte de paquets ;
• le jitter ;
• la redondance des interfaces ;
• la redondance du switching ;
• la taille MTU cohérente ;
• la congestion réseau ;
• la séparation du trafic intensif ;
• les chemins physiques réellement indépendants.

Cela devient encore plus important lorsque Proxmox partage son infrastructure avec Ceph.

Ceph peut générer beaucoup de trafic lors de la récupération, du rééquilibrage ou de la reconstruction. Un incident peut justement survenir au moment où Corosync doit communiquer le plus, tout en générant simultanément beaucoup de trafic pour le stockage.

Planifier ces deux réseaux sans prendre en compte cet environnement dégradé peut entraîner de nombreux problèmes.

Corosync n’est pas Ceph

La présence conjointe de ces deux composants dans beaucoup d’installations Proxmox peut causer une confusion.

Corosync gère la coordination du cluster Proxmox.

Ceph fournit un stockage distribué.

Une installation peut utiliser Corosync sans Ceph, par exemple avec du stockage partagé via NFS, iSCSI, Fibre Channel ou autres architectures.

Elle peut aussi utiliser Ceph, mais dans ce cas, il existe deux systèmes distribués distincts, chacun avec ses mécanismes, réseaux et temporisateurs.

Avoir Corosync avec quorum ne garantit pas forcément que Ceph est sain. Et avoir Ceph en bonnes répliques ne garantit pas la conservation du quorum par Proxmox.

Ce que doit connaître un administrateur Proxmox sur Corosync

Il n’est pas indispensable de connaître tous les paramètres de corosync.conf pour faire fonctionner une infrastructure Proxmox correctement.

Cependant, il est utile d’avoir en tête quelques questions clés :

Question	Ce qu’elle permet de savoir
Combien de votes y a-t-il ?	Comment se définit le quorum
Que se passe-t-il lorsqu’un nœud disparaît ?	La tolérance réelle du cluster
Y a-t-il QDevice ?	Comment le quorum est résolu dans les petits clusters
Quels liens Corosync utilise-t-il ?	Redondance de la communication
Corosync partage-t-il le réseau avec Ceph ?	Risque de congestion
Que signifient token et consensus ?	Temporisateurs effectifs
Le HA est-il présent ?	Quels services se recuperent automatiquement
Quel watchdog est utilisé ?	Mécanisme de fencing
Y a-t-il une capacité N+1 ?	Les VM pourront-elles réellement se récupérer

La dernière question est en dehors de Corosync, mais sans doute la plus importante : un cluster avec un quorum parfait, Corosync parfaitement configuré et un réseau totalement redondant reste inutile si les nœuds survivants manquent de CPU ou RAM pour rétablir les machines du serveur défaillant.

Les sauvegardes ne font pas partie de Corosync.

L’HA cherche à réduire le temps d’indisponibilité dû à certains défauts d’infrastructure. Les copies de sauvegarde, quant à elles, permettent de restaurer des données après une corruption, une attaque par ransomware, un effacement accidentel, etc.

Comprendre ses limites aide à les situer à leur juste place. Corosync est la couche qui permet aux membres de Proxmox de partager une vision commune de qui est toujours dans le cluster et qui peut prendre des décisions.

Il reste en grande partie silencieux. C’est pourquoi il est essentiel de le connaître avant que le jour ne arrive où l’un des serveurs ne répond plus.

Questions fréquentes

Qu’est-ce que Corosync dans Proxmox ?

Corosync est le système utilisé par Proxmox VE pour assurer la communication, l’adhésion et les services liés au quorum entre les nœuds d’un cluster. Il permet de maintenir une vision cohérente de quels serveurs font partie de l’infrastructure.

Proxmox peut-il fonctionner sans Corosync ?

Un serveur Proxmox VE n’est pas obligé d’être en cluster. Lorsqu’il fonctionne seul, Corosync n’est pas nécessaire. C’est quand plusieurs nœuds sont liés par le clustering que Corosync devient indispensable.

Corosync fournit-il une haute disponibilité ?

Pas directement. Corosync assure la communication, l’adhésion et le quorum, mais la haute disponibilité (HA) nécessite aussi le gestionnaire HA de Proxmox, le système de fencing, le stockage, etc. Ces éléments conjugués permettent la reprise automatique des charges.

Corosync a-t-il besoin d’un réseau dédié ?

Proxmox recommande de prêter une attention particulière à sa configuration réseau. Ce n’est pas forcément la bande passante qui prime, mais la faible latence, la stabilité et une redondance bien conçue pour éviter les défaillances.