Cluster Proxmox VE : quorum, QDevice et haute disponibilité sans mauvaise surprise

Un cluster Proxmox VE survit à la perte d’un serveur uniquement si plus de la moitié des votes reste joignable ; en dessous, il se met en lecture seule et, si la HA est active, les nœuds concernés se redémarrent eux-mêmes. Avec deux nœuds, il faut donc un troisième vote externe (le QDevice). Avec trois nœuds ou plus, la discipline se joue ailleurs : un réseau Corosync sain, un watchdog qui fonctionne, et assez de capacité pour absorber la reprise des machines virtuelles.

Ce guide s’appuie sur la documentation officielle de Proxmox VE 9 (chapitres « Cluster Manager » et « High Availability », consultés le 5 octobre 2026). Chaque chiffre cité vient de cette documentation, et non de l’expérience d’un forum.

Ce que le quorum protège vraiment

Dans un cluster Proxmox VE, chaque nœud détient un vote par défaut. Pour modifier l’état du cluster (créer une VM, changer une configuration, déplacer une ressource), une majorité de ces votes doit être en ligne. Quand elle ne l’est plus, la documentation est explicite : le cluster bascule en lecture seule. Ce comportement n’a rien d’un caprice. Il empêche deux moitiés d’un réseau coupé de modifier chacune leur copie de la configuration, puis de diverger sans retour possible.

Cette configuration commune vit dans pmxcfs, un système de fichiers adossé à une base de données, répliqué en temps réel sur tous les nœuds par Corosync. C’est pour cela qu’un cluster Proxmox est « multi-maître » : n’importe quel nœud peut accepter une opération d’administration, tant que le quorum est là. Pour situer ce modèle dans l’ensemble de la plateforme, notre état de l’art de Proxmox VE décrit la place du cluster entre stockage, réseau et sauvegarde.

L’arithmétique est simple, et c’est précisément ce qui piège les équipes : la majorité s’écrit « moitié plus un », et l’ajout d’un nœud ne rend pas toujours le cluster plus tolérant.

Le cas du quatrième nœud mérite qu’on s’y arrête. Passer de trois à quatre serveurs ajoute de la capacité de calcul, pas de tolérance : le quorum monte de deux à trois et le cluster n’encaisse toujours qu’une seule perte. La documentation montre d’ailleurs un exemple à quatre nœuds où pvecm status affiche quatre votes attendus pour un quorum de trois. D’où l’intérêt des nombres impairs, ou d’un vote externe pour les clusters pairs, ce que la documentation recommande justement pour le QDevice.

Un mot sur la commande pvecm expected 1. La documentation la cite comme contournement lorsqu’il faut retirer un nœud d’un cluster qui a perdu son quorum. C’est un outil de dernier recours qui force le cluster à accepter un seul vote : l’utiliser « pour que ça remarche » sur un cluster dont le second nœud est simplement injoignable revient à se passer volontairement de la protection décrite plus haut.

Le réseau Corosync : la partie que l’on bâcle

Corosync transporte les messages du cluster, et la documentation le décrit comme un protocole qui demande une latence basse et régulière, mais très peu de bande passante. Une carte réseau dédiée de 1 Gbit/s suffit dans la plupart des cas. L’important est de ne pas la partager avec un trafic qui sature les liens, comme le stockage en réseau ou la migration à chaud, car la latence des paquets Corosync s’en trouverait dégradée.

Les exigences chiffrées tiennent en quelques lignes :

• une latence inférieure à 5 millisecondes entre tous les nœuds (le niveau d’un réseau local) pour un fonctionnement stable ;
• au-delà, un petit cluster peut encore tenir, sans garantie, et la chose devient « plutôt improbable » avec plus de trois nœuds et des latences supérieures à environ 10 ms ;
• jusqu’à 8 liens Corosync par cluster, un lien supplémentaire servant de secours si le réseau dédié tombe ;
• des horloges synchronisées entre les nœuds, et un tunnel SSH sur le port TCP 22 entre eux.

Il y a un second détail que l’on découvre trop tard : le transport. Depuis Proxmox VE 6.0, Corosync 3 s’appuie sur Kronosnet, qui n’utilise que de l’UDP en unicast. On peut encore forcer le multicast ou l’unicast historique en changeant le transport dans corosync.conf, mais la documentation prévient que cela désactive tout le chiffrement et la redondance. Autant dire que personne ne devrait le faire sur une plateforme de production.

Les agrégats de liens (bonds) méritent une attention particulière, parce qu’on les met par réflexe sur un réseau « redondant ». La documentation détaille un scénario précis : une interface du bond cesse d’émettre alors que son état de lien reste « up ». Selon le mode, les nœuds peuvent se retrouver avec une connectivité asymétrique, certains ne voyant que certains autres, et Corosync n’arrive plus à former un quorum stable. Si la HA est active, même des nœuds dont le bond est sain peuvent alors se réinitialiser ; dans le pire cas, c’est tout le cluster.

Le détail des modes, tel que la documentation le présente :

• active-backup ne crée pas d’asymétrie, mais le basculement vers le lien de secours peut ne pas se produire, et le nœud isolé finit par se fencer si la HA est active ;
• balance-rr, balance-xor, balance-tlb et balance-alb sont déconseillés pour Corosync, car ils peuvent produire l’asymétrie décrite ci-dessus ;
• 802.3ad (LACP) peut s’en remettre, mais avec le réglage par défaut bond-lacp-rate slow les paquets LACPDU partent toutes les 30 secondes, soit un basculement de 90 secondes, plus long que la minute après laquelle un nœud HA se fence lui-même. Le réglage fast, appliqué des deux côtés, ramène ce délai à 3 secondes.

Ce dernier point illustre bien la manière dont des paramètres qui semblent indépendants (un réglage de switch, un délai de watchdog) interagissent. La recommandation la plus sûre reste celle de la documentation : un lien physique dédié pour Corosync, et un bond seulement en lien supplémentaire.

Deux nœuds : le QDevice, et ses limites

Deux serveurs plus un partage de stockage, c’est la configuration que beaucoup d’équipes choisissent d’instinct. Elle ne résiste pourtant à aucune panne sans aide : avec deux votes et un quorum de deux, la perte d’un nœud suffit à geler l’autre. La documentation propose le QDevice, qui fournit un troisième vote depuis un hôte indépendant.

Le principe repose sur deux services. Le démon corosync-qdevice tourne sur chaque nœud Proxmox. Il consulte un arbitre tiers, corosync-qnetd, installé sur une machine extérieure au cluster. Cet arbitre voit tous les nœuds et n’accorde son vote qu’à une seule partition à la fois, et seulement si cette partition peut ainsi retrouver le quorum. C’est ce qui rend le dispositif sûr en cas de coupure réseau : il ne peut pas voter pour les deux moitiés. Un détail pratique appréciable, toujours selon la documentation, est que le QDevice se connecte en TCP/IP et n’est donc pas soumis aux exigences de latence de Corosync : l’arbitre peut vivre hors du réseau local, par exemple sur un petit serveur distant.

La mise en place tient en quelques commandes :

1. installer corosync-qnetd sur l’hôte externe, et corosync-qdevice sur tous les nœuds du cluster ;
2. vérifier que tous les nœuds sont en ligne ;
3. lancer pvecm qdevice setup <IP-DU-QDEVICE> depuis un nœud ;
4. contrôler avec pvecm status : la ligne « Flags » doit afficher « Quorate Qdevice », et le tableau des membres compte une ligne « Qdevice » avec son vote.

La commande copie automatiquement la clé SSH du cluster sur l’hôte externe. La documentation précise qu’il faut prévoir un accès par clé pour le compte root de cette machine, ou autoriser temporairement le mot de passe le temps de l’installation, et que pvecm updatecerts règle l’erreur « Host key verification failed » qui peut survenir à cette étape. Comme cet hôte détient un vote sur le quorum et reçoit un accès root par clé, il doit être durci comme le reste de la plateforme : les bonnes pratiques de notre guide pour sécuriser un cluster de virtualisation s’y appliquent aussi.

Il reste une idée fausse tenace : le QDevice n’est pas à brancher partout. Pour un cluster au nombre de nœuds pair, il ajoute un vote et ne fait qu’améliorer la disponibilité ; sa panne vous ramène à la situation sans QDevice. Pour un nombre impair, la documentation le déconseille, car l’algorithme lui donne N-1 votes. Prenons l’exemple de la documentation, un cluster de quinze nœuds : sans QDevice, sept nœuds peuvent tomber avant la perte de quorum ; avec un QDevice configuré, si l’arbitre lui-même tombe, aucun des quinze nœuds ne peut plus défaillir. Il devient presque un point unique de défaillance. Autre risque cité : la reprise massive de services HA sur l’unique nœud restant, qui peut le saturer. Ceph, pour sa part, cesse de fournir ses services quand il ne reste en ligne que (N-1)/2 nœuds ou moins.

Un cluster à deux nœuds avec QDevice reste donc une solution de petite structure, pas une architecture de production exigeante. Pour les services qui comptent, trois vrais nœuds restent plus lisibles.

Fencing : pourquoi un nœud se redémarre tout seul

La haute disponibilité repose sur une règle que la documentation martèle : un service ne peut être relancé ailleurs qu’après la garantie que l’ancien hôte est hors service. Sans cela, on risque une situation décrite sans détour : un nœud qui a perdu tous ses réseaux sauf celui du stockage continue d’écrire sur le stockage partagé pendant qu’un second nœud démarre la même VM. Deux écritures concurrentes sur le même disque peuvent détruire les données au point de rendre la machine inutilisable.

Proxmox VE a choisi de ne pas imposer de matériel de coupure (alimentations pilotables, isolement par le switch), jugé coûteux et générateur de nouveaux composants critiques. Il utilise l’auto-fencing par watchdog. En fonctionnement normal, ha-manager réarme régulièrement la minuterie du watchdog. Si le nœud perd le quorum, se fige ou que les démons HA ne tournent plus, la minuterie expire et le serveur redémarre. Pour un nœud portant des services HA, la documentation indique que ce redémarrage survient environ soixante secondes après la perte d’un quorum stable.

Reste la question du watchdog lui-même. Par défaut, tous les modules de watchdog matériel sont bloqués « pour des raisons de sécurité », décrits dans la documentation comme « un pistolet chargé s’ils ne sont pas correctement initialisés ». Pour en activer un, on indique le module dans /etc/default/pve-ha-manager, par exemple WATCHDOG_MODULE=iTCO_wdt. À défaut, softdog, le watchdog logiciel du noyau, prend le relais. Il fonctionne, mais il n’est pas indépendant du serveur qu’il surveille et offre donc une fiabilité moindre qu’un circuit matériel. Les cartes mères récentes en embarquent souvent un, qu’il faut toutefois configurer : c’est un point à vérifier dans le BIOS avant la mise en production.

Ce que fait ha-manager entre la panne et la reprise

Le dispositif repose sur deux démons. Sur chaque nœud, le gestionnaire de ressources local (LRM, pve-ha-lrm) exécute les actions sur les services ; un gestionnaire de ressources de cluster (CRM, pve-ha-crm) prend les décisions pour l’ensemble, et un seul nœud porte à la fois le rôle de maître. Le mécanisme de verrou est la clé : le LRM n’agit que s’il détient son verrou, et c’est en parvenant à acquérir le verrou d’un nœud défaillant que le CRM peut le déclarer fencé, puis récupérer ses services.

La séquence réelle se déroule donc ainsi :

1. le nœud devient injoignable ou perd le quorum ;
2. il se réinitialise lui-même par watchdog ;
3. le CRM obtient son verrou et le marque comme fencé ;
4. il choisit un nœud d’accueil pour chaque service, puis le LRM de ce nœud démarre la VM ou le conteneur.

Il s’agit d’un redémarrage, pas d’une migration à chaud : la VM perd son état mémoire et subit un démarrage, avec ce que cela implique pour les applications. D’où une phrase de la documentation à garder en tête : les temps de détection et de reprise typiques de ha-manager sont d’environ deux minutes, ce qui plafonne la disponibilité à 99,999 %. Au niveau « cinq neufs », le budget annuel est de 5,26 minutes ; deux pannes de nœud dans l’année en consomment déjà l’essentiel. Voilà pourquoi viser une disponibilité supérieure demande de rendre l’application elle-même redondante, comme le rappelle la documentation.

Quelques réglages à connaître pour ne pas subir le comportement par défaut :

• max_restart (1 par défaut) fixe le nombre de tentatives de redémarrage sur le même nœud après un échec de démarrage ;
• max_relocate (1 par défaut) fixe ensuite le nombre de tentatives sur un autre nœud ;
• l’état demandé d’une ressource (started, stopped, disabled, ignored) se pilote avec ha-manager set, et un qm stop classique sur une VM HA ne fait que demander l’état arrêté.

Pour le positionnement, les règles d’affinité entre nœuds et ressources permettent de restreindre une ressource à certains nœuds, ce qui est utile dès qu’une VM dépend d’un périphérique présent sur un seul serveur. Côté VMware, le même problème se résout avec un autre vocabulaire (agent FDM, hôte maître, heartbeat, isolation) que détaille notre article sur les rôles dans un cluster VMware HA, utile pour une équipe qui migre et veut retrouver ses repères.

Maintenance : arrêts, redémarrages et mode maintenance

Faire de la maintenance sur un nœud HA, c’est tenir compte du fait que la pile HA réagit à vos opérations. La documentation prévoit deux voies. La première est la politique d’arrêt (shutdown_policy), réglable dans l’interface (Datacenter, Options, HA Settings) ou dans datacenter.cfg. Quatre valeurs existent :

• Migrate : à la demande d’arrêt, le nœud se déclare indisponible et toutes les ressources HA sont migrées ailleurs ; l’arrêt est retardé tant que tout n’est pas parti. Les services liés localement, par exemple par un passthrough matériel, ne peuvent pas migrer et font bloquer l’arrêt jusqu’à une intervention manuelle ;
• Failover : tous les services sont arrêtés, puis récupérés ailleurs si le nœud ne revient pas rapidement ;
• Freeze : tout est arrêté et gelé, sans reprise tant que le nœud n’est pas revenu ;
• Conditional : la valeur par défaut, par compatibilité ascendante, qui distingue arrêt et redémarrage. Dans le premier cas, les services sont arrêtés puis relancés ailleurs plutôt que migrés à chaud, pour éviter de déplacer toute la mémoire vive.

La seconde voie est le mode maintenance manuel, adapté lorsque l’intervention n’implique pas un redémarrage ou doit durer plus qu’un cycle. On l’active depuis la ligne de commande :

ha-manager crm-command node-maintenance enable NOM-DU-NOEUD

Les services HA du nœud sont alors migrés vers d’autres nœuds, choisis d’après les règles HA et le mode de l’ordonnanceur de ressources (CRS). Le nœud d’origine est mémorisé : en désactivant le mode maintenance, les services reviennent. Un piège pratique : le mode ne se désactive pas au redémarrage. Vous pouvez oublier qu’un nœud est en maintenance pendant des semaines.

Pour répéter ces scénarios sans toucher à la production, la documentation fournit un simulateur HA. Il permet de démarrer, arrêter, migrer des services simulés ou de provoquer des pannes sans disposer d’un vrai cluster. Les équipes qui passent de VMware y gagnent une journée de pratique à moindre coût.

Dimensionner pour le pire cas : la reprise concentre la charge

La documentation le dit sans emphase mais l’enjeu est considérable : à la défaillance d’un nœud, le CRM répartit ses services sur les nœuds restants, ce qui augmente leur nombre de services et peut entraîner une charge élevée, surtout sur de petits clusters. Il faut donc concevoir le cluster pour absorber ce cas. Autrement dit, un cluster de trois nœuds chargés à 70 % chacun ne tient pas la perte d’un nœud, quelle que soit la qualité du quorum.

L’ordonnanceur CRS choisit le nœud d’accueil en fonction de la charge, selon trois modes : basic (le nombre d’invités actifs, mode par défaut), static (les quotas CPU et mémoire configurés) ou dynamic (en plus, la consommation moyenne réelle). Les règles d’affinité réduisent d’abord l’ensemble des nœuds éligibles, et le moins chargé l’emporte parmi eux. Le mode basic est simple et prévisible ; les deux autres demandent de faire confiance à des métriques, ce qui se justifie si votre parc est très hétérogène.

Les exigences de départ, que beaucoup découvrent après coup, sont aussi dans la documentation : stockage partagé pour les VM et les conteneurs, redondance matérielle partout, composants de qualité serveur. Une HA sur un cluster dont les VM résident sur un disque local, sans réplication, ne reprend rien : le disque tombe avec la machine. Le choix entre Ceph, ZFS avec réplication, NFS ou iSCSI relève du stockage virtualisé, et il conditionne autant la reprise que les performances.

Enfin, une HA qu’on ne mesure pas est une promesse. Une supervision qui surveille l’état du quorum, la latence entre nœuds, l’état du watchdog (armed ou standby dans ha-manager status) et la charge des nœuds restants se construit facilement, par exemple avec une pile Prometheus et Grafana. Une alerte sur « un nœud est hors cluster depuis dix minutes » a plus de valeur que dix graphiques de CPU.

Check-list avant la mise en production

Avant d’activer la HA sur une ressource qui compte, il vaut la peine de dérouler ce qui suit, en provoquant les pannes plutôt qu’en les supposant :

• trois nœuds, ou deux nœuds plus un QDevice hébergé hors du cluster, et pvecm status qui affiche Quorate ;
• un lien Corosync dédié, un second lien en secours, une latence mesurée sous 5 ms ;
• un watchdog matériel déclaré dans /etc/default/pve-ha-manager si la carte mère en propose un, et un état armed constaté ;
• du stockage partagé ou répliqué, vérifié par une reprise réelle d’une VM de test ;
• une capacité qui tient avec un nœud en moins, calculée sur la mémoire autant que sur le processeur ;
• une procédure de maintenance écrite : politique d’arrêt choisie, mode maintenance testé, rappel sur la désactivation.

Le débranchement volontaire d’un câble sur un nœud de test apprend plus que dix relectures de documentation. Faites-le un jour calme, avec un chronomètre, et notez le délai réel entre la coupure et le redémarrage de la VM : c’est le chiffre que votre direction retiendra.

Sources consultées

Documentation officielle de Proxmox Server Solutions, consultée le 5 octobre 2026 :

• Cluster Manager (pvecm, quorum, QDevice, réseau Corosync)
• High Availability (ha-manager, fencing, politique d’arrêt, CRS)