Clustering et HA Proxmox : fonctionnement, défaillances et conception appropriée

janvier 4, 2026 • février 3, 2026 • Lecture : 32 min • Views: 8

Cet article vous a aidé ?

La première fois que la HA de Proxmox vous « sauve » en redémarrant une VM sur un nœud qui ne voit pas son disque,
on apprend une leçon utile : la disponibilité est une propriété du système, pas une case à cocher.
Le clustering est simple. Survivre aux pannes est la partie difficile.

Voici le guide pratique, orienté production : comment fonctionne réellement le clustering et la HA sous Proxmox,
ce qui casse dans des environnements réels, et comment concevoir un cluster qui n transforme pas des pannes mineures en danse interprétative.

Un modèle mental qui colle à la réalité

Le clustering Proxmox n’est pas magique. Ce sont trois problèmes séparables que l’on a tendance à confondre :

Plan de contrôle : les nœuds s’accordent sur l’appartenance et la configuration (corosync + pmxcfs).
Plan de données : les disques des VM sont accessibles là où la VM s’exécute (stockage partagé ou réplication).
Orchestration des charges : lorsqu’un nœud tombe, quelque chose décide de redémarrer les VM ailleurs (pve-ha-manager + pve-ha-lrm).

La HA ne fonctionne que si les trois sont conçus pour échouer proprement. Vous pouvez avoir un cluster parfaitement sain
avec un stockage totalement non-HA. Vous pouvez aussi avoir un stockage partagé impeccable et un plan de contrôle qui panique au moindre paquet perdu.
Et vous pouvez avoir les deux, puis vous saboter avec des « optimisations » comme des délais agressifs ou un commutateur unique.

La règle opérationnelle est simple : si vous ne pouvez pas expliquer où se trouve le disque de la VM pendant le basculement, vous n’avez pas de HA.
Vous avez « la possibilité de redémarrer des VM ailleurs ». Ce n’est pas la même chose.

Que contient le système : corosync, pmxcfs, pve-ha-manager

Corosync : appartenance et messagerie

Corosync est la couche de communication du cluster. Il gère l’appartenance des nœuds et distribue de manière fiable l’état du cluster.
Proxmox l’utilise pour répondre à la question « qui fait partie du groupe ». Il est sensible à la latence, au jitter et à la perte de paquets exactement comme votre liaison montante de commutateur la plus chargée l’est face au « ça ira ».

pmxcfs : le système de fichiers de configuration

Proxmox stocke la configuration du cluster dans /etc/pve, soutenue par pmxcfs, un système de fichiers distribué.
Il n’est pas destiné à vos images de VM. Il sert à la configuration : définitions de stockage, configurations de VM, ACL, paramètres du cluster.

Quand le quorum est perdu, /etc/pve bascule en mode protecteur. Les écritures sont bloquées, car laisser deux partitions écrire la configuration indépendamment est la façon de provoquer une divergence de configuration.
C’est une fonctionnalité. C’est aussi pourquoi des gens pensent « Proxmox est en panne » quand seules les écritures sont bloquées.

pve-ha-manager et pve-ha-lrm : le cerveau HA et les mains locales

La pile HA comporte un gestionnaire et des gestionnaires de ressources locaux. Le manager décide de ce qui doit tourner où. L’agent local exécute les démarrages/arrêts.
Il utilise un mélange de logique watchdog et d’état du cluster pour éviter d’exécuter la même VM deux fois. Éviter. Pas garantir. La garantie demande du fencing.

Une citation à garder en tête, dans l’esprit de la réalité opérationnelle : (idée paraphrasée) « L’espoir n’est pas une stratégie. » — souvent attribuée à des ingénieurs et opérateurs de partout, et correcte quelle que soit l’attribution.

Quorum : le mot le plus important de votre cluster

Le quorum répond : est-ce que cette partition de nœuds a l’autorité pour prendre des décisions de cluster ?
Si vous faites tourner un cluster sans comprendre le quorum, vous conduisez un chariot élévateur dans un magasin de verre.

Pourquoi le quorum existe

Lors d’une partition réseau, vous pouvez vous retrouver avec deux groupes de nœuds qui ne se voient plus.
Sans quorum, les deux côtés peuvent « faire ce qui leur semble juste » localement et démarrer la même VM HA.
Voilà comment vous corrompez des systèmes de fichiers, des bases de données, et vos relations avec l’équipe finance.

Règle générale : les nombres impairs gagnent

Un cluster à 3 nœuds peut perdre 1 nœud et garder le quorum. Un cluster à 2 nœuds ne le peut pas.
Vous pouvez faire fonctionner 2 nœuds avec un dispositif de quorum (QDevice), mais si vous essayez de faire de la HA à bon marché,
vous apprendrez à la dure pourquoi on recommande 3.

QDevice : le « troisième vote » sans troisième hyperviseur

QDevice ajoute un vote de quorum externe pour qu’un cluster à 2 nœuds puisse continuer à fonctionner lorsqu’un nœud est en panne (ou partitionné).
Il doit être placé avec soin : si le QDevice se situe sur le même chemin réseau qui a échoué, ce n’est qu’un vote décoratif.
Placez-le là où il tombera en panne différemment de votre interconnexion de cluster.

Blague n°1 (courte et pertinente)

Le quorum, c’est comme l’âge adulte : si vous devez demander si vous l’avez, probablement que non.

Stockage pour la HA : ce que « partagé » signifie vraiment

La décision de stockage est la décision HA. Tout le reste est de la chorégraphie.

Option A : stockage véritablement partagé (SAN/NFS/iSCSI/FC)

Le stockage partagé signifie que le disque de la VM est accessible depuis plusieurs nœuds en même temps, avec des verrous corrects.
En termes Proxmox, ce sont les types de stockage qui prennent en charge l’accès partagé et les bonnes sémantiques (par ex., NFS bien configuré, iSCSI avec LVM, FC avec multipath).

Le stockage partagé accélère le basculement : redémarrer la VM ailleurs, même disque. Il concentre aussi le risque : l’array de stockage devient votre « unique chose » qui peut tout emporter.
Certaines organisations acceptent cela parce que l’array est construit comme un tank. D’autres découvrent que « l’array » est un contrôleur unique et un mot de passe admin changé pour la dernière fois en 2018.

Option B : stockage partagé hyperconvergé (Ceph)

Ceph offre un stockage distribué à travers vos nœuds Proxmox (ou des nœuds de stockage dédiés). Excellent lorsqu’il est conçu correctement :
suffisamment de nœuds, suffisamment de NIC, suffisamment de disques, suffisamment de CPU, et suffisamment d’humilité.

Ceph n’est pas une « HA gratuite ». C’est un système de stockage avec ses propres modes de panne, comportements de récupération et profil de performance.
Lors de la récupération, Ceph peut consommer votre budget IO, ce qui peut ressembler à « la HA Proxmox est cassée » alors qu’en réalité votre cluster fait exactement ce que vous avez demandé : reconstruire des données.

Option C : réplication (réplication ZFS) + redémarrage

La réplication ZFS peut fournir un comportement proche de la HA : répliquer les disques VM du primaire vers des nœuds secondaires selon un planning.
Si un nœud meurt, vous démarrez la VM sur un nœud qui possède une réplique récente. Le compromis est évident : le RPO n’est pas nul à moins d’utiliser la réplication synchrone (qui a ses propres contraintes).

La réplication est un bon choix pour les petits clusters qui peuvent tolérer la perte de quelques minutes de données, ou pour des charges où vous avez déjà une réplication au niveau applicatif.
C’est aussi beaucoup plus simple à exploiter que Ceph pour de nombreuses équipes. Simple, c’est bien. Prévisible, c’est mieux.

Ce qui casse la HA de stockage en pratique

Incompatibilité de verrouillage : le stockage supporte les lectures partagées mais pas des écritures partagées sûres.
Couplage réseau : le trafic de stockage et corosync partagent le même lien congestionné.
Durabilité supposée : « c’est en RAID » devient « c’est sûr » puis « où est le datastore ? »
Basculement sans fencing : deux nœuds pensent posséder le même disque.

Fencing : ce que l’on saute jusqu’à ce que ça fasse mal

Le fencing (STONITH : Shoot The Other Node In The Head) garantit qu’un nœud défaillant ou partitionné est vraiment arrêté avant que les ressources ne soient déplacées ailleurs.
En HA VM, le fencing est la façon d’éviter le désastre des « deux écrivains actifs ».

Sans fencing, vous comptez sur des timeouts et la chance. Les timeouts ne sont pas de l’autorité. Ce sont des estimations.

À quoi ressemble le fencing dans l’univers Proxmox

Proxmox prend en charge l’auto-fencing basé sur watchdog et le fencing externe avec IPMI/iDRAC/iLO.
En pratique, pour une HA sérieuse :

Activez et validez le watchdog sur chaque nœud.
Utilisez la gestion hors bande pour couper l’alimentation d’un nœud qui est « vivant mais incorrect ».
Concevez l’alimentation et le réseau pour qu’un nœud puisse être fenced même si son réseau principal est mort.

Si vous utilisez du stockage bloc partagé (iSCSI/FC) et des systèmes de fichiers clusterisés ou LVM, le fencing compte encore plus.
La corruption des données n’est rarement immédiate. Elle est habituellement retardée, subtile, et nuisible pour une carrière.

Réseau de cluster : anneaux, latence et perte de paquets

Corosync veut une faible latence et une faible perte de paquets. Il tolère moins d’aléas que votre pile de stockage.
Le mode de panne classique est « le réseau est globalement correct », ce que les gens disent quand la perte de paquets est de 0,5 % et que votre cluster perd le quorum de façon intermittente.

Séparer les réseaux par fonction

Corosync : VLAN dédié ou réseau physique si possible. La latence prévisible compte.
Stockage : également dédié, surtout pour Ceph ou iSCSI.
Trafic client/VM : empêchez-le d’écraser votre plan de contrôle du cluster.

Les anneaux doubles ne sont pas une décoration

Corosync peut utiliser plusieurs anneaux (réseaux séparés) pour la redondance. Cela vaut la peine.
Si vous ne pouvez pas vous permettre des commutateurs redondants, acceptez que votre « HA » soit « haute anxiété ».

Blague n°2 (courte et pertinente)

La perte de paquets, c’est comme les termites : la maison a l’air saine jusqu’au moment où elle ne l’est plus.

Comment ça plante : pannes réelles et pourquoi

Mode de panne : perte de quorum bloque les écritures de configuration

Symptomatique : vous pouvez vous connecter, les VM peuvent continuer de tourner, mais vous ne pouvez pas démarrer/arrêter/migrer, et les changements via l’interface échouent.
Cause racine : le nœud (ou la partition) n’a pas le quorum, donc pmxcfs bloque les écritures.
Réponse correcte : restaurer le quorum, ne pas « forcer » à moins que vous n’exécutiez intentionnellement une île monocœur et compreniez les conséquences.

Mode de panne : la HA redémarre les VM mais elles ne démarrent pas

Symptomatique : le gestionnaire HA tente de déplacer/redémarrer, mais la VM échoue avec des disques manquants, stockage hors ligne, ou erreurs IO.
Cause racine : le stockage n’était pas réellement partagé/disponible sur le nœud cible ; ou le réseau de stockage a échoué en même temps que le nœud.
Réponse correcte : considérez le stockage comme partie du domaine de panne ; repensez la diversité des chemins de stockage ; assurez-vous que les définitions de stockage sont cohérentes et disponibles sur tous les nœuds.

Mode de panne : split brain ou risque de « double démarrage »

Symptomatique : le même service semble tourner deux fois, ou le disque partagé montre une corruption, ou la HA oscille.
Cause racine : partition réseau sans fencing effectif, votes attendus mal configurés, ou QDevice mal placé.
Réponse correcte : corriger la conception du quorum et ajouter du fencing. Ne touchez pas aux délais avant d’avoir conçu l’autorité.

Mode de panne : la récupération Ceph donne l’impression que tout est en panne

Symptomatique : après la perte d’un nœud, les VM saccadent, la latence IO explose, le cluster « semble mort ».
Cause racine : Ceph rétro-remplit/récupère, saturant disques et réseau.
Réponse correcte : capacity planning, réseaux rapides, et réglages de récupération raisonnables. Aussi : accepter que le « stockage auto-réparant » consomme des ressources pour guérir.

Tâches pratiques : commandes, sorties et décisions

Ce sont les vérifications que je lance effectivement. Chacune inclut ce que la sortie signifie et quelle décision prendre.
Exécutez-les sur un nœud sauf indication contraire.

Tâche 1 : Vérifier l’appartenance au cluster et le quorum

cr0x@pve1:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 12:10:41 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Signification : Quorate: Yes signifie que cette partition peut changer l’état du cluster en toute sécurité (démarrer des VM HA, éditer la configuration).

Décision : Si Quorate: No, arrêtez de faire des modifications et rétablissez la connectivité/le dispositif de quorum avant de toucher la HA.

Tâche 2 : Afficher la vue par nœud et les votes

cr0x@pve1:~$ pvecm nodes
Membership information
----------------------
Nodeid      Votes Name
0x00000001      1 pve1 (local)
0x00000002      1 pve2
0x00000003      1 pve3

Signification : Confirme qui figure dans la liste d’appartenance et combien de votes chacun possède.

Décision : Si un nœud manque de façon inattendue, investiguez les liens corosync et la santé du nœud avant d’accuser la HA.

Tâche 3 : Vérifier la santé des anneaux corosync (liens knet)

cr0x@pve1:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 10.10.10.11
        status  = ok
LINK ID 1 udp
        addr    = 10.10.20.11
        status  = ok

Signification : Les deux anneaux sont opérationnels. Si un lien est down, vous avez perdu de la redondance.

Décision : Si la redondance des anneaux est brisée, traitez cela comme un sev-2 : le prochain pépin de commutateur devient un incident de cluster.

Tâche 4 : Vérifier le timing et l’appartenance corosync via les stats runtime

cr0x@pve1:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Sun Dec 28 12:11:22 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          1
Ring ID:          1.2c
Quorate:          Yes

Signification : Confirme la perspective de votequorum ; utile quand l’UI ment ou que les logs sont bruyants.

Décision : Si ceci indique non-quorate, arrêtez de chercher des fantômes liés au stockage/perf et corrigez d’abord les communications du cluster.

Tâche 5 : Confirmer que pmxcfs est sain et pas en mode lecture seule

cr0x@pve1:~$ pvesh get /cluster/status
[
  {
    "type": "cluster",
    "name": "prod-cluster",
    "version": 42,
    "quorate": 1
  },
  {
    "type": "node",
    "name": "pve1",
    "online": 1,
    "ip": "10.10.10.11"
  },
  {
    "type": "node",
    "name": "pve2",
    "online": 1,
    "ip": "10.10.10.12"
  },
  {
    "type": "node",
    "name": "pve3",
    "online": 1,
    "ip": "10.10.10.13"
  }
]

Signification : "quorate": 1 indique que le système de fichiers du cluster peut accepter des écritures normalement.

Décision : Si quorate est 0, n’essayez pas d’éditer /etc/pve ; vos changements ne seront pas pris en compte (ou pire, vous créerez un désordre lors de la récupération).

Tâche 6 : Inspecter l’état du gestionnaire HA

cr0x@pve1:~$ ha-manager status
quorum OK
master pve2 (active, Sat Dec 27 23:14:02 2025)

service vm:101 (running, node=pve1)
service vm:120 (running, node=pve3)

lrm pve1 (active, Sat Dec 27 23:14:11 2025)
lrm pve2 (active, Sat Dec 27 23:14:02 2025)
lrm pve3 (active, Sat Dec 27 23:14:07 2025)

Signification : Montre quel nœud est le master HA et si les gestionnaires de ressources locaux sont actifs.

Décision : Si les LRM sont inactifs ou que le master oscille, concentrez-vous sur le quorum et la stabilité corosync avant de toucher aux VM individuelles.

Tâche 7 : Expliquer pourquoi une VM HA spécifique ne bouge pas

cr0x@pve1:~$ ha-manager status --verbose
quorum OK
master pve2 (active, Sat Dec 27 23:14:02 2025)

service vm:101 (running, node=pve1)
  state: started
  request: none
  last_error: none

service vm:130 (error, node=pve2)
  state: stopped
  request: start
  last_error: unable to activate storage 'ceph-vm' on node 'pve2'

Signification : La HA n’est pas « cassée », elle est bloquée par l’activation du stockage sur le nœud cible.

Décision : Passez au debug du stockage (Ceph/NFS/iSCSI), pas au réglage de la HA.

Tâche 8 : Vérifier rapidement la perte/latence réseau du cluster

cr0x@pve1:~$ ping -c 20 -i 0.2 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.355 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.420 ms
...
--- 10.10.10.12 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3815ms
rtt min/avg/max/mdev = 0.312/0.401/0.612/0.081 ms

Signification : Un ping propre ne prouve pas que corosync est heureux, mais une perte/jitter ici est un crater fumant.

Décision : S’il y a perte de paquets, arrêtez. Réparez d’abord le réseau. Corosync sous perte provoque des faux échecs partout ailleurs.

Tâche 9 : Examiner les logs corosync pour le churn d’appartenance

cr0x@pve1:~$ journalctl -u corosync -S -2h --no-pager | tail -n 20
Dec 28 10:41:03 pve1 corosync[1203]:   [KNET  ] link: host: 2 link: 0 is down
Dec 28 10:41:06 pve1 corosync[1203]:   [QUORUM] This node is within the primary component and will provide service.
Dec 28 10:41:11 pve1 corosync[1203]:   [KNET  ] link: host: 2 link: 0 is up
Dec 28 10:41:12 pve1 corosync[1203]:   [TOTEM ] A new membership (1.2b) was formed. Members joined: 2

Signification : Des liens qui flapent ont provoqué des reformations d’appartenance. C’est de la turbulence pour le cluster.

Décision : Traitez les changements répétés d’appartenance comme un précurseur d’incident. Inspectez les NIC, commutateurs, bonding, configuration VLAN, MTU et congestion.

Tâche 10 : Valider la disponibilité du watchdog (prérequis auto-fencing)

cr0x@pve1:~$ dmesg | grep -i watchdog | tail -n 10
[    1.842113] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[    1.842205] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

Signification : Un driver watchdog matériel est présent. C’est la base pour l’auto-fencing.

Décision : S’il n’y a pas de watchdog, ne prétendez pas avoir une HA sûre. Ajoutez un support matériel ou du fencing hors bande.

Tâche 11 : Confirmer la visibilité du stockage sur un nœud cible (exemple NFS)

cr0x@pve2:~$ pvesm status
Name         Type     Status           Total       Used        Avail     %
local        dir      active         19660800    2457600     17203200   12%
nfs-vmstore  nfs      active       1048576000  734003200    314572800   70%

Signification : Le stockage est active sur ce nœud. S’il est inactive, la HA ne peut pas démarrer les disques là-bas.

Décision : Si inactif, corrigez le montage/le réseau/l’auth avant d’autoriser la HA à y placer des charges.

Tâche 12 : Confirmer le backend du disque d’une VM et si elle est migrable

cr0x@pve1:~$ qm config 101
boot: order=scsi0;net0
cores: 4
memory: 8192
name: app-prod-01
net0: virtio=12:34:56:78:9a:bc,bridge=vmbr0
scsi0: ceph-vm:vm-101-disk-0,iothread=1,size=80G
scsihw: virtio-scsi-pci
vmgenid: 0b0b0b0b-1111-2222-3333-444444444444

Signification : Le disque est sur ceph-vm. C’est partagé (si Ceph est sain).

Décision : Si vous voyez local-lvm ou un dataset ZFS local au nœud sans réplication, n’attendez pas de la HA pour redémarrer ailleurs avec succès.

Tâche 13 : Vérifier la santé de Ceph (si vous l’utilisez)

cr0x@pve1:~$ ceph -s
  cluster:
    id:     2f4a9d2e-aaaa-bbbb-cccc-111122223333
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 12/3456 objects degraded

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 7m)
    mgr: pve1(active, since 2h)
    osd: 9 osds: 8 up (since 1m), 9 in (since 30d)

  data:
    pools:   3 pools, 128 pgs
    objects: 1152 objects, 4.5 GiB
    usage:   220 GiB used, 1.8 TiB / 2.0 TiB avail
    pgs:     12 active+undersized+degraded, 116 active+clean

Signification : Ceph est opérationnel mais dégradé ; les performances peuvent être mauvaises et les redémarrages HA lents.

Décision : Pendant les états dégradés, évitez les migrations massives et ne déclenchez pas de redémarrages évitables. Stabilisez Ceph d’abord.

Tâche 14 : Confirmer le statut de réplication pour les configurations ZFS

cr0x@pve1:~$ pvesr status
JobID  Type  State    Last Sync              Duration  Error
1000   local ok       2025-12-28 11:55:02    00:01:42  -
1001   local failed   2025-12-28 11:40:02    00:00:11  ssh connection failed

Signification : Le job 1001 a échoué ; les répliques peuvent être obsolètes sur le nœud cible.

Décision : Ne prétendez pas avoir de couverture HA pour des VM sur un job de réplication qui échoue. Corrigez le transport/l’auth, puis validez le RPO.

Tâche 15 : Vérifier si le cluster manque de ressources (CPU steal, symptômes IO wait)

cr0x@pve1:~$ pvesh get /nodes/pve1/status
{
  "cpu": 0.71,
  "loadavg": [2.15, 2.07, 1.94],
  "memory": {
    "total": 68719476736,
    "used": 51234567890,
    "free": 17484908846
  },
  "swap": {
    "total": 8589934592,
    "used": 2147483648
  },
  "uptime": 123456
}

Signification : Vous échangez sur disque. Dans les clusters, l’échange transforme un « petit pépin réseau » en « pourquoi tout a-t-il ralenti ? ».

Décision : Si le swap est utilisé de façon significative en conditions normales, corrigez la pression mémoire avant de diagnostiquer des oscillations HA.

Tâche 16 : Vérifier la synchronisation temporelle (oui, ça compte)

cr0x@pve1:~$ timedatectl status
               Local time: Sun 2025-12-28 12:14:55 UTC
           Universal time: Sun 2025-12-28 12:14:55 UTC
                 RTC time: Sun 2025-12-28 12:14:55
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Signification : L’horloge est synchronisée. Bien. La dérive temporelle rend les logs inutilisables et peut perturber les systèmes distribués de façon subtile.

Décision : Si non synchronisé, corrigez NTP/chrony sur tous les nœuds avant d’essayer d’interpréter l’ordre des événements pendant un incident.

Méthode de diagnostic rapide

Quand un cluster Proxmox « se comporte bizarrement », vous voulez de la rapidité et les bonnes priorités. Voici l’ordre qui trouve le goulot d’étranglement rapidement.

Première question : le plan de contrôle est-il autoritaire ?

Exécutez pvecm status : avez-vous le quorum ?
Exécutez corosync-cfgtool -s : les liens sont-ils up ? un anneau est-il down ?
Scannez journalctl -u corosync : y a-t-il des memberships répétés ?

Si le quorum est instable, arrêtez ici. Corrigez le réseau du cluster et l’appartenance avant d’investiguer HA, stockage ou symptômes de VM.

Deuxième question : le nœud cible voit-il le stockage de la VM ?

pvesm status sur le nœud cible : stockage active ?
qm config <vmid> : où est vraiment le disque ?
Si Ceph : ceph -s et surveillez dégradations/backfill.

Si le stockage n’est pas disponible partout où il doit l’être, la HA va osciller ou redémarrer dans l’échec.

Troisième question : la HA est-elle bloquée, ou refuse-t-elle d’agir par sécurité ?

ha-manager status --verbose : lisez l’erreur, ne devinez pas.
Vérifiez la préparation watchdog/fencing si vous voyez un risque de double démarrage ou des comportements rappelant du fencing.

Quatrième question : est-ce une véritable famine de ressources ?

pvesh get /nodes/<node>/status : swap, charge, utilisation CPU.
Vérifiez la perte et la latence réseau entre les nœuds ; puis vérifiez séparément le réseau de stockage.

Erreurs fréquentes : symptôme → cause → correction

1) « La HA est cassée, elle ne démarre pas les VM »

Symptômes : actions HA échouent ; l’interface affiche des erreurs ; certains nœuds montrent « inconnu ».

Cause racine : perte de quorum, ou churn d’appartenance corosync.

Correction : Rétablir une connectivité corosync stable (réseau dédié, anneaux redondants). Ajouter QDevice pour 2 nœuds. Ne changez pas les timeouts en premier.

2) « La VM a redémarré sur un autre nœud mais le disque est manquant »

Symptômes : la VM démarre puis échoue ; erreurs de stockage ; disque introuvable.

Cause racine : le disque était sur un stockage local au nœud (ou le stockage partagé n’était pas monté/actif sur la cible).

Correction : Placez les VM HA sur un stockage véritablement partagé (Ceph/NFS/iSCSI/FC) ou implémentez la réplication avec un RPO défini et testez les restaurations/basculements.

3) « Le cluster se fige pendant les sauvegardes/migrations »

Symptômes : timeouts corosync, oscillations HA, interface lente pendant des IO intenses.

Cause racine : le réseau corosync partage un lien congestionné avec le trafic VM/stockage ; ou la CPU est saturée par chiffrement/compression/sauvegardes.

Correction : Séparez les réseaux ; limitez le débit des tâches lourdes ; orientez corosync sur des chemins à faible latence ; prévoyez la capacité CPU pour les fenêtres de sauvegarde.

4) « Cluster à deux nœuds : parfois il arrête de gérer »

Symptômes : après la panne d’un nœud, le nœud restant n’arrive pas à démarrer les ressources HA ou à éditer la config.

Cause racine : absence de QDevice ; votes attendus mal alignés ; quorum non atteignable seul.

Correction : Ajouter un QDevice placé sur un domaine de panne indépendant ; vérifier les votes attendus ; tester les scénarios « un nœud en moins ».

5) « Ceph est à peu près sain mais tout est lent »

Symptômes : latence IO élevée, VM en pause, basculements lents après une panne.

Cause racine : backfill/récupération dégradée saturant les IO ; réseau sous-dimensionné (1GbE) ou disques insuffisants ; trop peu d’OSD.

Correction : Concevoir Ceph correctement : 10/25GbE, suffisamment d’OSD, séparer réseaux public/cluster si applicable, et planifier l’impact des récupérations.

6) « Nous avons réglé les timeouts corosync et maintenant la HA est pire »

Symptômes : perte de quorum plus fréquente, faux décès de nœud, basculements aléatoires.

Cause racine : timeouts fixés en dessous du jitter réel pendant la charge ; le cluster devient trop prompt à déclencher.

Correction : Revenir aux valeurs par défaut sensées ; corriger le réseau ; mesurer le jitter en période de pointe ; seulement ensuite envisager un réglage prudent.

7) « Après un redémarrage, un nœud ne peut pas rejoindre le cluster »

Symptômes : le nœud apparaît hors ligne ; corosync ne démarre pas ; erreurs de mismatch de configuration.

Cause racine : mauvais mapping /etc/hosts, configuration corosync obsolète, MTU incompatible, ou règles de pare-feu.

Correction : Valider la résolution de noms, MTU cohérent, ouvrir les ports requis sur les réseaux de cluster, et confirmer la cohérence de corosync.conf via /etc/pve.

Listes de contrôle / plan étape par étape

Checklist de conception : construire un cluster sur lequel dormir

Choisir la taille du cluster : Préférer 3 nœuds ou plus. Si 2 nœuds, prévoir QDevice et fencing dès le premier jour.
Définir les domaines de panne : commutateurs, circuits d’alimentation, racks, paires ToR, chemins de stockage. Notez-les.
Séparer les réseaux : corosync sur VLAN/fabric physique dédié ; stockage sur son propre réseau ; trafic client séparé.
Redondance : double anneau corosync ; commutation redondante ; NICs en bond seulement si vous maîtrisez la configuration des commutateurs.
Stratégie de stockage : partagé (Ceph/SAN/NFS/iSCSI) pour une vraie HA ; réplication pour « redémarrage avec RPO ». Ne mélangez pas les attentes.
Fencing : watchdog + contrôle d’alimentation hors bande testés. Documentez comment effectuer le fencing manuellement.
Capacité : N+1 compute. La HA sans capacité libre n’est qu’une automatisation de la déception.
Tests opérationnels : redémarrage planifié d’un nœud, coupure d’alimentation, arrêt de port de commutateur, défaillance de chemin de stockage, perte de QDevice (si utilisé).

Plan d’implémentation : du zéro au stable

Construire des nœuds identiques (noyau, drivers NIC, réglages BIOS pour virtualisation, contrôleurs de stockage).
Attribuer des adresses statiques pour les réseaux corosync ; assurer une résolution de noms stable.
Créer le cluster ; configurez immédiatement un corosync à double anneau si vous avez les réseaux.
Valider le comportement du quorum en isolant temporairement un nœud (test contrôlé).
Mettre en place le stockage et valider depuis chaque nœud (pvesm status doit être ennuyeusement cohérent).
Activer le watchdog et vérifier sa présence dans les logs sur chaque nœud.
Créer des groupes HA avec des contraintes sensées (n’autorisez pas tout à s’entasser sur le plus petit nœud).
Mettre une VM non critique en HA, tester la panne d’un nœud, confirmer qu’elle réapparaît ailleurs avec le bon disque et le bon réseau.
Déployer la HA par classe de service ; garder une pool « non HA » pour les pets et expérimentations.

Checklist opérations : routine hebdomadaire « maintenir en bonne santé »

Vérifier pvecm status sur un nœud choisi au hasard : confirmer le quorum stable.
Scanner les logs corosync pour les flaps de lien et le churn d’appartenance.
Si Ceph : vérifier ceph -s et traiter les avertissements avant qu’ils ne deviennent incidents.
Valider les jobs de réplication (pvesr status) si vous en dépendez.
Confirmer la synchronisation temporelle sur tous les nœuds.
Réaliser occasionnellement une migration contrôlée en heures ouvrables (oui, volontairement) pour détecter le drift tôt.

Trois mini-récits du monde de l’entreprise

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne a construit un cluster Proxmox à trois nœuds pour la « HA ». L’équipe a fait comme beaucoup : ils ont clusterisé les nœuds,
activé la HA, et se sont sentis rassurés. Le stockage était « partagé », disaient-ils, parce que chaque nœud atteignait le NAS via NFS.
Personne n’a posé la question peu glamour : le NFS est-il monté et sain sur chaque nœud durant la panne exacte que nous planifions ?

La première vraie panne fut le redémarrage d’un commutateur ToR. Les nœuds sont restés en ligne, mais le VLAN NAS a bégayé.
Corosync se trouvait sur le même chemin d’interconnexion, donc le churn d’appartenance a commencé. Le quorum a vacillé.
La HA a vu un nœud comme non sain et a redémarré deux VM sur un nœud qui, à ce moment-là, n’avait pas le partage NFS monté.

Les VM n’ont pas réussi à démarrer. Les applications sont tombées. L’équipe, regardant l’UI, a interprété cela comme « la HA Proxmox est boguée ».
Ils ont rebooté des nœuds pour « stabiliser », ce qui a empiré les choses car cela a augmenté le churn et les démarrages échoués.

Après coup, le postmortem a révélé la mauvaise hypothèse : « NFS atteignable » avait été pris pour « stockage HA ».
La correction n’était pas exotique. Ils ont séparé corosync sur un réseau dédié, rendu les montages de stockage plus résilients et supervisés,
et ajouté une règle stricte : pas d’étiquette HA sur une VM à moins que son disque vive sur un stockage prouvé accessible depuis n’importe quel nœud cible lors de tests de panne.

La leçon est peu romantique : la HA est un contrat. Si le stockage peut disparaître pendant la même classe de panne qui déclenche le basculement,
votre système HA redémarrera avidement des charges dans le vide et l’appellera succès.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation faisait tourner Proxmox avec Ceph et recevait des alertes « nœud perdu » intermittentes. Quelqu’un a décidé de « resserrer la détection »
en réduisant les timeouts du cluster. Une détection plus rapide équivaut à un basculement plus rapide, raisonnaient-ils. Ils voulaient un système « plus réactif ».

Cela a fonctionné en laboratoire. En production, la réalité a repris ses droits : fenêtres de sauvegarde, IO de voisins bruyants, et un réseau qui allait bien
jusqu’à ce que le trafic de récupération Ceph devienne ambitieux. Pendant les pics, les paquets corosync ont été retardés juste ce qu’il fallait.
Avec les timeouts renforcés, ces retards ont franchi la ligne entre « toléré » et « nœud déclaré mort ».

La HA a commencé à déplacer les VM. Ceph était déjà occupé. Il devait maintenant servir l’IO des VM, gérer la récupération et absorber les tempêtes de migration/redémarrage.
Le cluster a sombré dans une douleur auto-infligée : de faux basculements provoquant une charge réelle, provoquant plus de faux basculements.

La correction fut légèrement embarrassante et totalement efficace : revenir aux timeouts, puis corriger la latence et la congestion sous-jacentes.
Ils ont séparé les trafics, limité les jobs les plus bruyants et ajusté les attentes : la vitesse de basculement ne vaut pas l’instabilité du cluster.

La leçon profonde : les timeouts ne sont pas des réglages de performance. Ce sont des détecteurs de panne. Si vous les réglez en dessous de votre jitter pire cas,
vous n’améliorez pas la disponibilité. Vous générez le chaos plus rapidement.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise soumise à des exigences de conformité strictes exploitait un cluster Proxmox avec stockage iSCSI partagé et un QDevice.
Leur conception n’était pas tape-à-l’œil. Elle était simplement implacablement prudente : réseau corosync dédié, commutateurs redondants,
fencing documenté via gestion hors bande, et tests trimestriels « couper l’alimentation ».

Pendant une maintenance planifiée, une mise à jour de firmware sur un commutateur a mal tourné et le commutateur a cessé de transférer correctement le trafic.
Le ring 0 de corosync est devenu bizarre. Le ring 1 est resté sain. Le cluster n’a pas perdu le quorum.
Les VM n’ont pas oscillé. Le système de monitoring a sonné, mais l’activité métier a à peine remarqué.

L’astreinte a suivi le runbook : confirmer le quorum, confirmer l’état des anneaux corosync, confirmer les chemins de stockage, puis isoler le commutateur défaillant.
Ils ont déplacé volontairement certaines charges au lieu de laisser la HA agir frénétiquement. Ils n’ont pas rebooté les nœuds dans la panique.

Après l’incident, l’équipe n’a reçu aucun point d’héroïsme car rien de dramatique ne s’est produit. C’est le rêve.
La pratique ennuyeuse — anneaux redondants plus diagnostics répétés — a transformé une panne potentiellement compliquée en une opération de maintenance contrôlée.

Si vous voulez une HA qui ressemble à de la compétence plutôt qu’à de l’adrénaline, adoptez ces habitudes ennuyeuses. Le drame n’est pas un KPI.

Faits intéressants et contexte historique

Fait 1 : Proxmox VE base ses communications de cluster sur Corosync, un projet open-source de longue date utilisé également dans les piles Linux HA classiques.
Fait 2 : Le concept de « quorum » précède la virtualisation moderne ; il est ancré dans la sécurité des systèmes distribués : seule la majorité peut décider en sécurité.
Fait 3 : Le split brain n’a pas été inventé par la virtualisation ; les clusters de stockage et la réplication de bases de données s’en débattent depuis des décennies.
Fait 4 : pmxcfs est un système de fichiers de configuration, pas un système distribué généraliste ; le traiter comme « stockage partagé » est une incompréhension courante.
Fait 5 : Le passage de Corosync au transport knet a amélioré la gestion des liens et les options de redondance par rapport aux configurations plus anciennes.
Fait 6 : Le terme STONITH est assez ancien pour paraître une blague, mais l’idée est extrêmement sérieuse : garantir un seul écrivain.
Fait 7 : « HA » signifiait à l’origine basculement de services pour des processus ; la virtualisation a fait du machine entière l’unité de basculement, mais les règles de sécurité sont restées.
Fait 8 : La popularité de Ceph dans les déploiements hyperconvergés vient de la résolution d’un vrai problème : monter le stockage sans array monolithique, au prix d’une complexité opérationnelle.
Fait 9 : Les clusters à deux nœuds sont historiquement délicats dans les systèmes à quorum ; le troisième vote (humain, témoin, ou qdevice) est une pratique bien établie.

FAQ

1) Ai-je besoin de trois nœuds pour la HA Proxmox ?

Si vous voulez un comportement de quorum sensé sans composants spéciaux, oui. Deux nœuds peuvent fonctionner avec QDevice, mais c’est moins indulgent et plus facile à mal concevoir.

2) Que se passe-t-il quand le cluster perd le quorum ?

Les nœuds sans quorum bloqueront les écritures de configuration dans /etc/pve. Les VM en cours peuvent continuer de tourner, mais les opérations gérées par le cluster (surtout les actions HA) peuvent être restreintes.

3) Puis-je faire de la HA si les disques de mes VM sont sur un stockage local ?

Ce n’est pas une vraie HA de basculement. Proxmox peut redémarrer une VM ailleurs seulement si le disque est accessible là-bas (stockage partagé) ou répliqué et promouvable avec un RPO compris.

4) La réplication ZFS est-elle de la « HA » ?

C’est un « redémarrage automatisé avec réplication ». Excellent pour de nombreuses charges, mais ce n’est pas zéro-RPO. Si c’est acceptable et testé, c’est une conception valide.

5) Ai-je vraiment besoin de fencing ?

Si vous utilisez un stockage partagé et que vous vous souciez de l’intégrité des données, oui. Sans fencing, une partition réseau peut conduire à deux écrivains actifs.
Parfois vous avez de la chance. Parfois vous obtenez une base de données corrompue et un long weekend.

6) Corosync doit-il tourner sur le même réseau que Ceph ou NFS ?

Évitez-le. Corosync veut une latence prévisible ; le trafic de stockage est rafaleux et finira par le dominer. Séparez-les sauf si votre environnement est minuscule et que vous acceptez le risque.

7) Comment savoir si la HA échoue à cause du stockage ou des comms du cluster ?

Vérifiez d’abord le quorum (pvecm status). Si quorate, vérifiez si le stockage est active sur la cible (pvesm status) et lisez ha-manager status --verbose pour des erreurs explicites.

8) Pourquoi Proxmox HA refuse-t-elle parfois de déplacer une VM alors qu’un nœud semble non sain ?

Parce qu’elle essaie d’éviter des actions dangereuses : démarrer sans stockage, démarrer deux fois, ou agir sans quorum. Le « refus » est souvent le comportement correct.

9) Puis-je étendre un cluster Proxmox sur deux sites ?

Vous pouvez, mais vous vous engagez à gérer la latence, le risque de partition et la réplication complexe du stockage. Si vous devez le faire, concevez le quorum, le fencing et le stockage comme un système distribué, pas comme un LAN.

10) Quelle est la conception HA la plus simple et fiable pour de petites équipes ?

Trois nœuds, réseau corosync dédié, stockage véritablement partagé (ou réplication avec RPO explicite), watchdog activé, et scénarios de panne testés. Restez ennuyeux.

Conclusion : prochaines étapes pratiques

Le clustering et la HA Proxmox fonctionnent bien quand vous les traitez comme de l’ingénierie système : autorité (quorum), exécution sûre (fencing),
et accessibilité des données (stockage) conçus ensemble. Si l’un d’eux est bâclé, le cluster finira par vous réclamer son dû.

Prochaines étapes que vous pouvez réaliser cette semaine :

Exécutez les vérifications de diagnostic rapide maintenant, pendant que tout est « bien », et enregistrez les sorties de référence.
Classifiez chaque VM : vraie HA (stockage partagé + fencing), redémarrage-avec-RPO (réplication), ou best-effort (local).
Séparez le trafic corosync du trafic stockage et VM, ou au moins prouvez que le réseau peut gérer le pire jitter en charge.
Testez une vraie panne (couper l’alimentation d’un nœud, ou désactiver un port de commutateur) pendant une fenêtre contrôlée et vérifiez : comportement du quorum, décisions HA, disponibilité du stockage.
Documentez comment effectuer le fencing d’un nœud et pratiquez-le. Vous ne voulez pas que votre premier essai de fencing ait lieu pendant une corruption.