Haute disponibilité : ressources HA, groupes, règles d'affinité, fencing¶

Day 1 · DéployerNiveau 3 · MaîtriserCours + labRédigé · à valider en lab

La HA de Proxmox VE redémarre automatiquement une VM ou un conteneur sur un autre nœud quand son nœud tombe. Elle exige un stockage partagé ou répliqué, un cluster quorate et un fencing fiable. Depuis PVE 9.0, les groupes HA sont remplacés par des règles HA : règles d'affinité nœud (node affinity) et règles d'affinité ressource (resource affinity).

Notions clés¶

Élément	Rôle
Ressource HA	VM ou CT géré par la HA (`vm:101`, `ct:102`)
CRM (`pve-ha-crm`)	Gestionnaire maître du cluster, décide des placements
LRM (`pve-ha-lrm`)	Agent local de chaque nœud, exécute démarrages et arrêts
Fencing	Garantit qu'un nœud perdu est réellement arrêté avant de relancer ses ressources ailleurs
Watchdog	Minuterie qui redémarre le nœud s'il n'est plus rafraîchi ; `softdog` par défaut, matériel possible (`iTCO_wdt`, IPMI)

Fencing : comment un nœud se « suicide »¶

flowchart TD
    A[pve02 perd le quorum] --> B[LRM de pve02 cesse<br/>de rafraîchir le watchdog]
    B --> C[Watchdog : reset de pve02<br/>après environ 60 s]
    A --> D[CRM sur pve01, partition quorate]
    D --> E[Attente de l'expiration<br/>du verrou de pve02]
    C --> F[pve02 considéré fencé]
    E --> F
    F --> G[vm:101 relancée<br/>sur pve01 ou pve03]

Comptez environ 2 minutes entre la panne et le redémarrage de la VM ailleurs. La VM redémarre : la HA n'est pas une tolérance de panne sans coupure.

Ce qui change en PVE 9 : des groupes aux règles¶

PVE 8 (groupes)	PVE 9 (règles)
Groupe avec liste de nœuds et priorités	Règle node-affinity : `--nodes "pve01:2,pve02:1"`
`restricted`	`--strict 1` : la ressource ne tourne que sur les nœuds listés
`nofailback` sur le groupe	Option `failback` sur la ressource (défaut `1`)
Pas d'équivalent natif	Règle resource-affinity `positive` (garder ensemble) ou `negative` (séparer)
Groupe choisi dans Manage HA de la VM	Règles gérées au niveau Datacenter → HA

La conversion des groupes en règles est automatique, mais seulement quand tous les nœuds sont en PVE 9. Les règles sont stockées dans /etc/pve/ha/rules.cfg. Une ressource ne peut appartenir qu'à une seule règle node-affinity ; des règles contradictoires sont désactivées jusqu'à correction.

Paramètres d'une ressource¶

Option	Défaut	Effet
`state`	`started`	`started`, `stopped`, `disabled` (sortie de l'état `error`), `ignored` (hors HA)
`max_restart`	1	Tentatives de redémarrage sur le même nœud
`max_relocate`	1	Tentatives de déplacement vers un autre nœud
`failback`	1	Retour vers le nœud prioritaire quand il revient

Politique à l'arrêt d'un nœud¶

Datacenter → Options → HA Settings, shutdown_policy : conditional (défaut : extinction = relance ailleurs, redémarrage = gel), freeze, failover, migrate. Pour une maintenance, préférez le mode maintenance : ha-manager crm-command node-maintenance enable pve02 (voir RB-02).

Mise en œuvre¶

GUICLI

Datacenter → HA → Resources → Add : VM 101, Max. Restart 1, Max. Relocate 1, Request State started.
Datacenter → HA → Affinity Rules → Add une règle Node Affinity : ressources vm:101,vm:102, nœuds pve01 (priorité 2) et pve02 (priorité 1).
Même écran → Add une règle Resource Affinity negative pour vm:111,vm:112 (deux contrôleurs de domaine à séparer).

ha-manager add vm:101 --state started --max_restart 1 --max_relocate 1
ha-manager rules add node-affinity pref-pve01 \
  --resources vm:101,vm:102 --nodes "pve01:2,pve02:1"
ha-manager rules add resource-affinity dc-separes \
  --affinity negative --resources vm:111,vm:112
ha-manager rules list
ha-manager status

Recommandations MSP¶

HA uniquement sur stockage partagé (Ceph, SAN) ou ZFS répliqué ; en ZFS répliqué, la VM redémarre sur la dernière réplique : perte des données depuis la dernière synchronisation.
Séparer les paires redondantes (DC, DNS, nœuds applicatifs) avec une règle resource-affinity negative.
Ne pas mettre en HA le QDevice, le PBS local ni les VM dont le redémarrage automatique est dangereux (bases en cluster applicatif).
Toute modification du watchdog ou des réglages CRS passe par le MSP.

Pièges vus en support

Règle node-affinity strict avec un seul nœud : la VM reste arrêtée si ce nœud tombe.
Ressource en error : la remettre en started ne suffit pas, passer d'abord par disabled.
Perte de quorum de tout le cluster (coupure réseau Corosync) : tous les nœuds portant des ressources HA redémarrent.
VM arrêtée depuis l'invité alors qu'elle est en started : la HA la redémarre aussitôt. Utiliser Shutdown dans la GUI ou --state stopped.
Après la mise à niveau 8 → 9, groupes non convertis car un nœud est resté en 8 : consulter journalctl -eu pve-ha-crm.

Lab : provoquer un basculement¶

Cluster de test uniquement

Ce lab coupe brutalement un nœud. Jamais en production.

Prérequis : cluster de test 3 nœuds avec stockage partagé, VM de test 901 sur pve02.

Mettre vm:901 en HA et créer une règle node-affinity préférant pve02 (priorité 2), puis pve03 (1).
Vérifier ha-manager status : service vm:901 (pve02, started).
Couper pve02 brutalement (Power Off IPMI ou echo b > /proc/sysrq-trigger). Chronométrer.
Observer sur pve01 : watch ha-manager status.
Rallumer pve02 et observer la VM.

Questions : Q1. Où redémarre la VM et en combien de temps ? Q2. Que se passe-t-il au retour de pve02 ? Q3. Comment empêcher ce retour ?

Corrigé

Q1. Sur pve03 (priorité suivante), après environ 2 minutes : pve02 passe fence, puis vm:901 est relancée.
Q2. Avec failback=1 (défaut), la VM migre de nouveau vers pve02, nœud le plus prioritaire.
Q3. ha-manager set vm:901 --failback 0.

Testez-vous¶

Que remplace une règle node-affinity en PVE 9 ?

Réponse

Les groupes HA de PVE 8 : liste de nœuds avec priorités, et strict remplace restricted.
Quand les groupes sont-ils convertis automatiquement ?

Réponse

Lorsque tous les nœuds du cluster sont passés en PVE 9.
Comment garantir que deux VM ne tournent jamais sur le même nœud ?

Réponse

Une règle resource-affinity negative : ha-manager rules add resource-affinity <nom> --affinity negative --resources vm:111,vm:112.
Pourquoi un nœud isolé redémarre-t-il tout seul ?

Réponse

Sans quorum, son LRM cesse de rafraîchir le watchdog, qui redémarre le nœud : c'est le fencing, qui permet de relancer ses ressources ailleurs sans risque d'écriture concurrente.