6. Haute disponibilité (HA)

La migration à chaud du §2 répond à une maintenance prévue : l'administrateur choisit le moment, la VM part pendant qu'elle tourne. La haute disponibilité répond à ce qu'on ne choisit pas : un nœud qui s'éteint, une carte mère qui lâche, un service qui refuse de démarrer.

Dans ces cas, Proxmox VE décide seul de relancer les machines concernées ailleurs, sans intervention humaine. Cette section décrit précisément comment il prend cette décision, ce qu'il lui faut pour la prendre sans risque, et comment l'administrateur garde la main.

6.1 Ce que « haute disponibilité » veut dire

La haute disponibilité désigne la capacité d'un service à rester accessible malgré la défaillance d'un ou plusieurs composants de l'infrastructure. Elle se mesure en pourcentage de temps de fonctionnement sur une année. Le guide d'administration de Proxmox VE donne la correspondance suivante :

Proxmox VE intègre un gestionnaire de haute disponibilité, ha-manager. Il détecte la panne d'un nœud et redémarre les VM et conteneurs qu'il protège sur un autre nœud du cluster.

La documentation officielle donne un ordre de grandeur honnête : environ 2 minutes entre la panne et le redémarrage du service. Une seule panne par an consomme donc déjà l'essentiel du budget de 99,999 % — c'est le plafond atteignable avec ce mécanisme.

6.2 Les prérequis

Quatre conditions doivent être réunies avant d'activer la HA. Les trois premières sont indispensables.

La HA repose sur deux démons, le CRM (Cluster Resource Manager) et le LRM (Local Resource Manager).

6.3 Fonctionnement interne : le CRM décide, le LRM exécute

Deux démons tournent en permanence sur chaque nœud du cluster.

L'unicité du maître ne repose pas sur une élection réseau, mais sur des verrous du système de fichiers de cluster pmxcfs (/etc/pve). Le CRM qui détient le verrou ha_manager_lock est le maître ; chaque LRM actif détient le verrou de son nœud, ha_agent_<nœud>_lock. Ces verrous sont visibles dans /etc/pve/priv/lock/.

Dans le Shell du nœud :

# Les verrous HA, dans le système de fichiers du cluster
ls /etc/pve/priv/lock/

Résultat attendu (cluster de l'atelier 6, VM 300 sous HA) :

ha_agent_pxe211_lock
ha_agent_pxe212_lock
ha_manager_lock

Ces verrous garantissent qu'un seul CRM décide et qu'un seul LRM agit par nœud. Ils sont aussi la clé du fencing. Si le maître tombe, un autre CRM acquiert ha_manager_lock et prend la relève.

Si un nœud tombe, c'est la prise de son verrou d'agent par le CRM qui l'autorise à voler ses services. Le journal du CRM montre cette prise de fonction au démarrage.

Dans le Shell du nœud :

# Journal du CRM (extrait)
journalctl -u pve-ha-crm

Résultat attendu (pxe213, devenu maître au redémarrage du cluster) :

pve-ha-crm[1412]: successfully acquired lock 'ha_manager_lock'
pve-ha-crm[1412]: watchdog active
pve-ha-crm[1412]: status change slave => master

ha-manager status résume l'ensemble. Sortie du lab, la VM 300 de l'atelier 6 placée sous HA.

Dans le Shell du nœud :

# Résumé de la HA : quorum, maître, LRM, ressources
ha-manager status

quorum OK
master pxe213 (active, Wed Oct  7 18:13:02 2026)
fencing armed (CRM watchdog active)
lrm pxe211 (active, watchdog active, Wed Oct  7 18:13:07 2026)
lrm pxe212 (idle, watchdog standby, Wed Oct  7 18:13:09 2026)
lrm pxe213 (idle, watchdog standby, Wed Oct  7 18:13:08 2026)
service vm:300 (pxe211, started)

La même chose dans Datacenter → HA, sur le cluster du lab avant l'atelier 6 : quorum OK, puis fencing standby (CRM watchdog standby), car aucune ressource n'est encore sous HA (la liste Resources est vide). Le bouton Add de cette liste est celui du § 6.5.

6.4 Le fencing et le watchdog

Le fencing (« mise à l'écart ») est le mécanisme qui isole définitivement un nœud défaillant avant de relancer ses services ailleurs. Il existe pour empêcher le pire scénario d'un cluster : deux instances de la même VM qui écrivent en même temps sur le même disque partagé. Le résultat est une corruption garantie du système de fichiers de la VM.

Le cas difficile n'est pas le nœud mort, mais le nœud à moitié vivant. Il ne répond plus sur le réseau du cluster : Corosync ne le voit plus. Mais son processeur tourne toujours, et ses VM aussi.

Le CRM voudrait relancer ces VM ailleurs ; s'il le fait alors que le nœud continue d'écrire sur Ceph, c'est le split-brain. Ce nœud ne peut pas libérer son verrou lui-même, et personne ne peut lui demander de s'arrêter : il n'est plus joignable.

C'est le rôle du watchdog, un minuteur que le nœud doit réarmer régulièrement faute de quoi il redémarre de force. Le guide d'administration le décrit ainsi. Un nœud qui constate qu'il n'est plus dans la partition quorate ne peut plus réarmer son watchdog.

S'il héberge des services actifs, le watchdog expire et redémarre le nœud au bout de 60 secondes. Le CRM, de son côté, sait qu'au-delà de ce délai le nœud isolé est forcément arrêté : il peut prendre son verrou et relancer ses services sans risque.

La séquence, dans l'ordre :

1. Le nœud est isolé : réseau du cluster coupé, processeur toujours actif.
2. Hors quorum, son LRM ne peut plus réarmer le watchdog.
3. Le watchdog expire au bout de 60 secondes : le nœud redémarre de force.
4. Le CRM acquiert le verrou du nœud : ses services passent en recovery.
5. Les VM redémarrent sur un nœud sain.

Sur le lab, pendant l'atelier 6, ces étapes se lisaient dans le journal du nouveau maître : fencing: acknowledged - got agent lock for node 'pxe212', puis recover service 'vm:300' from fenced node 'pxe212' to node 'pxe213'.

Deux familles de watchdog existent :

softdog tourne dans le noyau qu'il surveille : si ce noyau est figé, il ne peut plus rien déclencher. Un watchdog matériel est un circuit indépendant de la carte mère, qui coupe le serveur quoi qu'il arrive au système. Tous les modules de watchdog matériel sont bloqués par défaut, car un watchdog mal initialisé peut redémarrer un serveur sain.

Pour en activer un, on déclare son module dans /etc/default/pve-ha-manager, lu par le service watchdog-mux. Le fichier livré avec Proxmox VE 9.2 contient ceci.

Dans le Shell du nœud :

# Le fichier lu par watchdog-mux
cat /etc/default/pve-ha-manager

# select watchdog module (default is softdog)
#WATCHDOG_MODULE=ipmi_watchdog

Le mode de fencing du cluster se règle dans datacenter.cfg (fencing: watchdog, valeur par défaut). Les valeurs hardware et both pilotent des équipements de coupure externes, décrits dans /etc/pve/ha/fence.cfg. La documentation de la version 9.2 les marque expérimentales : on s'en tient au watchdog.

Revenons à la définition de base : la haute disponibilité relance un service ailleurs quand son serveur tombe, sans intervention humaine. Le danger est de le relancer alors que l'original tourne encore. Les composants du mécanisme :

Le cas délicat est le nœud coupé du réseau du cluster, dont les VM tournent toujours. Le CRM attend que le watchdog ait redémarré ce nœud, puis prend son verrou d'agent : seulement alors, il relance ses services sur un nœud sain.

Où voir la haute disponibilité sur votre cluster :

6.5 Les ressources HA

Une ressource HA est une VM ou un conteneur confié au ha-manager. Elle est identifiée par un SID (Service ID) de la forme type:id : vm:100 pour la VM 100, ct:200 pour le conteneur 200. Les ressources sont stockées dans /etc/pve/ha/resources.cfg, répliqué sur tous les nœuds par pmxcfs.

Activer la HA pour une VM — via l'interface graphique :

Datacenter → HA → Resources → Add

Équivalent CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Placer la VM 300 sous la protection de la HA : "started" = toujours la maintenir démarrée
ha-manager add vm:300 --state started --max_restart 1 --max_relocate 1

Après ha-manager add vm:950 --state started --max_restart 1 --max_relocate 1 sur le cluster d'exemple, le fichier contient exactement :

vm: 950
    max_relocate 1
    max_restart 1
    state started

Les propriétés d'une ressource, telles que les décrit ha-manager help add sur Proxmox VE 9.2 :

:::tip Une ressource HA se pilote comme une VM ordinaire. Les commandes qm start et qm stop, comme les boutons de l'interface, sont transmises au gestionnaire HA quand la VM en est une ressource. Sur le cluster d'exemple, qm start 950 répond simplement Requesting HA start for VM 950 : c'est le CRM qui décide ensuite du nœud et lance le démarrage. :::

6.6 Les états d'une ressource

Le CRM tient pour chaque ressource un état courant, distinct de l'état demandé. C'est lui qu'affichent ha-manager status et Datacenter → HA. La liste est celle du guide d'administration :

Un état supplémentaire, deleting, apparaît brièvement quand une ressource est retirée par ha-manager remove, service vm:950 (pxe213, deleting), affiché pendant plusieurs secondes.

6.7 Commandes et fichiers à connaître

• 📖 Documentation Proxmox — High Availability
• 📖 Les règles HA dans le guide d'administration
• 📖 Options du fichier datacenter.cfg (CRS — Cluster Resource Scheduling —, fencing, politique d'arrêt)
• 🎥 Simulation de panne d'un nœud et basculement automatique des VM HA (vidéo)