Cluster HA avec Proxmox à 2 nœuds : configurer correctement le quorum, le QDevice et le fencing

Un cluster HA avec Proxmox et 2 nœuds est en pratique un cas particulier : il se met en place rapidement, mais sur la question du quorum (décision de majorité dans le cluster) et du fencing (isolement strict d’un nœud défaillant pour prévenir la corruption des données) il est nettement plus exigeant qu’un enchaînement classique à 3 nœuds. La raison est simple : avec exactement deux voix, il n’y a pas de majorité sans un « tiers arbitre ». Dès que la communication ou le stockage vacille, des situations de « split-brain » menacent — c’est‑à‑dire deux côtés qui croient chacun être l’instance valide.

Cet article montre de manière pragmatique comment résoudre correctement le quorum pour deux nœuds Proxmox (QDevice), comment le fencing est mis en œuvre et testé de façon réaliste dans Proxmox (y compris le Watchdog) et quelles stratégies de vérification et de repli aident en exploitation. L’accent est mis sur les impacts sur la disponibilité, l’intégrité des données et l’exploitation — pas sur les détails des frameworks.

Cluster HA avec Proxmox et 2 nœuds en pratique

Dans Proxmox, la communication de cluster repose sur Corosync (messagerie de cluster) et la configuration du cluster se trouve dans pmxcfs (Proxmox Cluster File System, un système de fichiers de configuration distribué dépendant du quorum). Pour les décisions de cluster, Corosync utilise un quorum : ce n’est que si une majorité est joignable que la vue du cluster est considérée comme « valid » et que les actions d’écriture du cluster sont autorisées.

Avec trois nœuds, c’est robuste : deux sur trois constituent une majorité. Avec deux nœuds, sans aide, c’est fragile : si un nœud ou seulement la connexion tombe, il ne reste qu’une seule voix — et ce n’est pas une majorité. Le cluster se bloque alors (au mieux). Dans le pire des cas, des administrateurs contournent les mécanismes de protection du quorum et prennent le risque d’un split-brain : les deux côtés continuent à fonctionner, écrivent sur le même stockage ou effectuent des actions HA contradictoires.

Important pour la planification : « HA » n’est pas seulement « une VM démarre sur un autre hôte ». HA signifie avant tout des décisions cohérentes en cas d’erreur. Pour cela, il faut soit au minimum trois voix, soit une « tierce voix » externe et contrôlée.

Principe de base : QDevice comme tierce voix pour le quorum Proxmox

La solution propre pour deux nœuds Proxmox est un QDevice. Il ne s’agit pas d’un autre hôte Proxmox, mais d’une aide au quorum : un service externe (qnetd, Corosync Quorum Net Daemon) fournit une voix supplémentaire via le réseau. Les nœuds du cluster se lient à ce service en tant que clients (qdevice). Ainsi, en cas de panne ou de partition, une majorité peut de nouveau émerger : 1 nœud + QDevice = 2 voix (majorité sur 3).

Pourquoi cela fonctionne : QDevice ne prend pas de « décisions HA », mais sert de témoin contrôlé indiquant à quelle partition la voix supplémentaire est attribuée. Cela réduit nettement le risque de split‑brain, mais ne remplace pas le fencing. En effet, même avec un quorum un nœud peut « encore tourner », tout en n’étant plus fiable (p. ex. stockage bloqué, noyau bloqué, timeouts I/O). Il faut alors un mécanisme qui garantisse : Un seul hôte peut continuer à écrire sur les ressources partagées.

Conditions préalables et vérification du design avant la mise en œuvre

Avant de configurer QDevice ou le fencing, clarifiez le contexte. Beaucoup d’installations à 2 nœuds ne posent pas problème à Proxmox lui‑même, mais échouent à cause d’hypothèses implicites sur le réseau, le stockage ou l’alimentation.

1) Réseau : au moins deux chemins, latence définie, MTU cohérente

Pour Corosync, ce n’est pas la « bande passante » qui compte, mais la latence stable et de faibles pertes de paquets. Prévoyez idéalement des réseaux séparés (ou des VLAN) pour le management/cluster (Corosync) et le trafic des VM. Si vous utilisez une interface Corosync dédiée, veillez à une MTU identique et à une configuration de commutateur cohérente. Les « jumbo frames uniquement parfois » sont un classique provoquant des partitions sporadiques.

2) Stockage : stockage partagé vs réplication

En HA sur Proxmox, on observe souvent deux modèles :

• Stockage partagé (p. ex. iSCSI/NFS/SAN) : les deux hôtes voient le même datastore. Avantage : la VM peut démarrer rapidement sur l’autre hôte. Risque : un split‑brain peut corrompre le stockage si les deux hôtes écrivent simultanément.
• Stockage répliqué (p. ex. réplication ZFS) : les données sont synchronisées / répliquées périodiquement entre les hôtes. Avantage : moins d’écritures « simultanées » sur le même périphérique bloc. Inconvénient : le RPO/RTO dépend des intervalles de réplication et du processus de basculement.

Pour les deux cas : sans fencing, le stockage partagé en configuration à 2 nœuds est particulièrement risqué. Même avec QDevice, le fencing doit être prévu comme « dernière instance ».

3) Gestion hors bande et Watchdog

Pour un fencing fiable, vous avez généralement besoin d’une interface hors bande telle que IPMI (maintenance BMC) ou d’une PDU commutable. En alternative, il existe des mécanismes basés sur le stockage (p. ex. SBD), qui, dans les environnements Proxmox, se situent souvent en dehors du chemin standard. De plus, un Watchdog doit être activé : il s’agit d’un timer matériel ou noyau qui redémarre l’hôte si le système « bloque » et ne l’alimente plus régulièrement (keepalive). Cela traite les deadlocks où un hôte a encore de l’alimentation mais ne prend plus de décisions sûres.

Mise en œuvre : configurer QDevice (qnetd) pour deux nœuds Proxmox

La recommandation du point de vue de l’exploitation : faites fonctionner le service QDevice sur un troisième système, indépendant des deux hôtes Proxmox (circuit électrique/USV différent, idéalement autre baie/segment d’emplacement). Il peut s’agir d’une petite VM ou d’un mini‑serveur. L’important n’est pas tant la performance que la disponibilité et des chemins réseau propres.

Étape 1 : installer QNetd sur l’hôte QDevice

Exemple pour un système Debian/Ubuntu servant d’hôte QDevice :

sudo apt update
sudo apt install -y corosync-qnetd
sudo systemctl enable --now corosync-qnetd
sudo systemctl status corosync-qnetd

Assurez‑vous que le pare‑feu autorise le port qnetd (par défaut TCP 5403). Dans les réseaux RESTrictifs, c’est souvent le premier écueil : Corosync fonctionne en interne typiquement via UDP/Multicast ou UDP/Unicast, alors que qnetd utilise TCP.

Étape 2 : assurer la synchronisation temporelle et une résolution de noms fiables

Les composants du cluster sont sensibles aux dérives d’horloge. Activez NTP/Chrony sur tous les systèmes. De plus, la résolution de noms doit être stable (DNS ou /etc/hosts), car les certificats et les identités peuvent jouer un rôle pour qdevice/qnetd.

Étape 3 : enregistrer QDevice dans le cluster Proxmox

Sur un nœud Proxmox (typiquement celui qui a initialisé le cluster), intégrez QDevice. Proxmox fournit pour cela pvecm (Proxmox VE Cluster Manager).

# Status prüfen
pvecm status

# QDevice hinzufügen (Hostname oder IP des QNetd-Hosts)
pvecm qdevice setup <QNETD_HOSTNAME_ODER_IP>

Le processus d’installation génère et distribue les clés/certificats nécessaires et réécrit la configuration Corosync en conséquence. Ensuite, vérifiez à nouveau l’état du cluster :

pvecm status
pvecm qdevice status

Attendu dans un cluster à 2 nœuds : vous verrez, en plus des deux voix des nœuds, des informations de quorum supplémentaires fournies par QDevice. Si QDevice n’est pas joignable, le quorum retombe en cas d’incident sur le modèle problématique à 2 voix.

Pièges typiques avec QDevice

• QDevice dans le même segment Layer‑2 que les deux nœuds, mais sur le même port de commutateur : si le switch tombe, QDevice tombe en même temps. Le „dritte Zeuge“ est alors nicht unabhängig.
• QDevice en tant que VM sur le cluster Proxmox lui‑même : c’est un cercle vicieux. Si le cluster vacille, la VM censée stabiliser le quorum vacille aussi.
• Règles de pare‑feu floues : qnetd nécessite une connectivité TCP stable. La perte de paquets ou l’inspection TLS sur le chemin peut provoquer des déconnexions sporadiques.
• Tentatives de réglage trop agressives des timeout de Corosync : dans les petits réseaux, des timeouts plus courts semblent „schneller“, mais augmentent les faux déclenchements lors de brefs incidents. Mesurez d’abord, modifiez ensuite.

Fencing dans Proxmox : pourquoi le quorum seul n’est pas suffisant

Même avec QDevice, le quorum indique seulement qui est autorisé à décider. Il n’indique pas si un autre nœud est réellement arrêté. C’est là qu’intervient le fencing (souvent appelé STONITH : „Shoot The Other Node In The Head“). Objectif : si, du point de vue du cluster, un hôte doit être mis hors service, il est éteint ou réinitialisé de manière fiable avant que les ressources (VMs, Storage) ne continuent de fonctionner sur l’autre hôte.

Dans Proxmox, le HA est géré par le HA Manager intégré. Le HA Manager peut gérer des services (VMs/containers) et les déplacer en cas d’incident. Mais : si les deux hôtes pensent simultanément être « actifs », le HA peut effectuer des actions erronées sans fencing. Avec un stockage partagé, cela est particulièrement dangereux, car des blocs de données peuvent être écrits en parallèle.

Options réalistes de fencing en fonctionnement à 2‑nœuds

• IPMI/Redfish Power Off/Reboot: Le classique en environnement serveur. Condition préalable : le BMC doit être joignable, isolé et sécurisé, et ne pas se trouver sur le même segment réseau que le segment en panne.
• Schaltbare PDU / Smart Power: Fonctionne aussi lorsque le BMC est instable. Doit toutefois être géré de manière sûre sur le plan organisationnel (droits d’accès, journalisation).
• Watchdog + Selbstfencing: Si l’hôte détecte en interne qu’il n’est plus sûr (p. ex. perte de quorum/du cluster), il peut redémarrer lui‑même. Ce n’est pas un substitut au fencing externe, mais cela augmente la robustesse face à des états « suspendus ».

Important : un « arrêt propre » n’est pas du fencing. Le fencing doit, en cas de doute, être forcé, car précisément en cas de panne un « arrêt propre » ne fonctionne souvent plus de manière fiable.

Activer et vérifier le watchdog dans Proxmox (Bonnes pratiques)

Un watchdog est un mécanisme qui réinitialise le système lorsqu’il ne répond plus. Sous Linux, /dev/watchdog est souvent disponible via un module noyau (p. ex. iTCO_wdt sur les plateformes Intel). Proxmox peut utiliser le watchdog pour le HA afin de ne pas continuer à fonctionner « à moitié mort » en cas d’impasse.

Étape 1 : vérifier si un périphérique watchdog est disponible

ls -l /dev/watchdog* || true

# Kernelmeldungen zum Watchdog
dmesg | grep -i watchdog || true

# Geladene Module
lsmod | grep -i wdt || true

Si aucun périphérique n’apparaît, vérifiez les options BIOS/UEFI (Watchdog/Server Management) et les modules noyau appropriés. Dans les environnements virtualisés, le watchdog peut être fourni par la plateforme VM ; sur du Bare Metal, il s’agit typiquement du matériel/du jeu de puces.

Étape 2 : vérifier la configuration du watchdog dans Proxmox

Selon la version de Proxmox et le type de configuration, le watchdog est activé via des services système / des composants HA. Vérification rapide en exploitation :

systemctl status pve-ha-lrm pve-ha-crm || true
journalctl -u pve-ha-lrm -u pve-ha-crm --since "-2h" | tail -n 200

Interprétation : il ne s’agit pas de chercher des services « verts », mais des indications que les composants HA tournent et qu’il n’y a pas de timeouts récurrents/boucles de redémarrage. Si le HA n’est pas utilisé, le watchdog RESTe intéressant comme filet de sécurité — mais vos processus opérationnels (Monitoring/Alerting) doivent alors détecter de façon fiable les blocages d’hôte.

Liste de contrôle pratique : tester avant le premier basculement HA

Avant de mettre des VM productives en tant que ressources HA, effectuez des tests contrôlés. L’objectif n’est pas « ça marche une fois », mais « nous comprenons quand cela ne fonctionne pas et comment nous réagissons ».

1) État de base du cluster et du quorum

pvecm nodes
pvecm status

# Corosync-Health grob prüfen
systemctl status corosync
journalctl -u corosync --since "-1h" | tail -n 200

Surveillez la perte de paquets, les expirations de token et les changements récurrents de membres. Un cluster à 2 nœuds doit fonctionner « ennuyeusement » : pas de rejoins permanents, pas de flaps.

2) Vérifier l’état du QDevice et les dépendances

pvecm qdevice status

# QNetd vom Node aus erreichen
nc -vz <QNETD_HOSTNAME_ODER_IP> 5403

Si la connexion TCP échoue de façon sporadique, résolvez cela avant l’activation du HA. Sinon, en cas de panne vous perdrez la voix majoritaire.

3) Simulation de coupure de liaison : déconnecter le réseau Corosync

Déconnectez de façon contrôlée l’interface Corosync (pas l’interface de management, afin de pouvoir continuer l’administration) et observez ce qui se passe : un côté obtient-il le quorum ? L’autre reste-t-il correctement bloqué ? C’est précisément ici que l’on voit si QDevice et le design réseau fonctionnent.

Observations pendant le test :

watch -n 2 'pvecm status; echo; pvecm qdevice status'

Si les deux côtés semblent toujours « actifs » ou si les actions HA deviennent confuses, c’est un signal d’alerte : vous devez revoir proprement le fencing/isolation et les chemins réseau.

Scénarios d’erreur typiques et dépannage en exploitation

Scénario A : « Le cluster n’a pas de quorum » après une courte secousse réseau

Causes : perte de paquets sur le trajet Corosync, problèmes de tampon/queue du switch, incompatibilité MTU, QoS/policing, switches virtuels causant des drops. Dans les architectures à 2 nœuds, on le remarque immédiatement, car il n’y a pas de troisième voix pour stabiliser la vue.

Procédure :

• Vérifier les logs Corosync pour les expirations de token.
• Mesurer le chemin réseau : drops sur les NIC/ports de switch, erreurs, CRC, duplex.
• Si possible : configurer un second réseau Corosync (redondance), plutôt que d’« optimiser » finement les timeouts.

Scénario B : QDevice est joignable, mais le quorum se comporte « inattendu »

Causes : QDevice pas indépendant (partage la même cause de panne), problèmes de résolution de noms/certificats, session TCP instable, routage asymétrique. Vérifiez que les deux nœuds communiquent réellement de façon stable avec qnetd et que qnetd lui-même fonctionne sans interruptions.

Vérifications rapides :

# Auf dem QDevice-Host
systemctl status corosync-qnetd
journalctl -u corosync-qnetd --since "-2h" | tail -n 200

Scénario C : la VM démarre après le basculement, mais le stockage est incohérent ou « bloqué »

C’est le cas dangereux : le quorum/HA a « réagi », mais sans fencing sûr l’ancien hôte peut encore émettre des I/O ou garder des verrous. Selon le stockage (NFS, iSCSI, Cluster‑FS, Ceph) cela se manifeste par des blocages, des erreurs de système de fichiers ou des disques VM corrompus.

Mesures :

• En cas de doute : arrêter brutalement l’hôte concerné (Out-of-Band) avant de poursuivre le débogage.
• Vérifier les logs de stockage (côté Target/Controller). Beaucoup de causes ne se situent pas sur l’hyperviseur.
• Ne remettre les ressources HA en service que lorsqu’il est clairement établi qu’aucune « double écriture » n’est active.

Recommandation de mise en œuvre : conception HA à 2 nœuds minimale et robuste

Si, pour des raisons de budget ou d’espace, vous devez rester à deux nœuds, l’objectif est un design qui réagit de manière prévisible en cas d’incident. Un paquet minimal viable et pragmatique ressemble à ceci :

• 2 hôtes Proxmox avec des chemins réseau séparés pour Corosync/gestion/trafic VM (au minimum logiquement via VLAN, de préférence physiquement).
• 1 hôte QDevice indépendant (qnetd), non exploité sur les deux hôtes Proxmox.
• Fencing hors‑bande (IPMI/Redfish ou PDU) en tant que processus d’urgence défini, y compris responsabilités et voies d’accès.
• Watchdog activé et testé pour atténuer les états bloqués.
• Runbooks pour blocages de partition/de stockage : qui éteint quel hôte et quand, comment resynchroniser, comment valider la cohérence des données ?

Ce n’est pas aussi ‚glamour‘ que des listes de fonctionnalités, mais cela réduit les pannes réelles et surtout les risques pour les données.

Stratégie de repli et récupération : que faire si Quorum/Fencing réagit mal ?

En pratique, il faut partir du principe qu’un état indéterminé surviendra au moins une fois : partition partielle, gel du stockage, BMC inaccessible, bascule HA bloquée. L’essentiel est alors de disposer d’une séquence de récupération conservatrice qui protège les données.

Séquence de récupération conservatrice (éprouvée en exploitation)

1. Arrêter les écritures : si un stockage partagé est impliqué et que vous suspectez une double écriture, priorisez l’arrêt forcé d’un nœud (coupure d’alimentation OOB) avant de tenter une reconfiguration ‚amiable‘.
2. Stabiliser l’état du cluster : ce n’est qu’une fois qu’il est clair quel hôte doit être ‚master‘ que vous restaurez Corosync/Quorum (chemin réseau, accessibilité de qnetd).
3. Valider le stockage : selon le backend : vérifications du système de fichiers, logs du contrôleur de stockage, sessions iSCSI, verrous NFS. Objectif : aucune incohérence silencieuse.
4. Activer les services HA de manière contrôlée : pas d’activation immédiate ‚tout en pilote automatique‘, mais étape par étape, avec surveillance de la latence I/O, des verrous et des erreurs noyau.

Règle opérateur : mieux vaut prendre 10 minutes de décision supplémentaires que passer 10 heures en récupération de données. Deux nœuds ne pardonnent aucune ambiguïté.

Conclusion : 2 nœuds sont possibles — mais seulement avec discipline

Un cluster HA avec Proxmox et 2 nœuds peut être exploité de manière fiable si vous compensez consciemment la faiblesse systémique (absence de majorité naturelle). QDevice n’est pas un « nice-to-have », mais la base pour atteindre un quorum pertinent en cas de défaillance. Fencing et Watchdog sont les filets de sécurité qui empêchent la corruption des données et les états indéterminés lorsque la réalité frappe (blocages de stockage, fluctuations réseau, hôtes partiellement défaillants).

Si vous planifiez aujourd’hui : intégrez QDevice et le fencing dès le départ, testez les défaillances critiques de manière contrôlée et documentez une procédure de récupération conservatrice. Ainsi, un ‚petit‘ cluster à 2 nœuds devient une configuration qui vit en exploitation sur des états clairs, et non sur l’espoir.

Pour ce sujet, Proxmox Qdevice et Proxmox Fencing sont également importants. L’article replace ces aspects de façon compréhensible et montre ce qui compte au quotidien.