Cluster Proxmox : migration à chaud et haute disponibilité

Un cluster Proxmox VE est un groupe d'hôtes (des nœuds) qui partagent la même configuration et s'administrent comme un seul ensemble : on y déplace une VM allumée d'un nœud à l'autre (la migration à chaud), et le gestionnaire de haute disponibilité redémarre automatiquement sur un autre nœud les VM d'un nœud tombé en panne. Ce chapitre explique le quorum, construit le cluster de Sorbier à trois nœuds, puis met en place la migration, la réplication et la haute disponibilité. La théorie générale (disponibilité, SPOF, basculement) est dans le cours Haute disponibilité.

Comment fonctionne un cluster Proxmox

Trois briques composent un cluster :

• Corosync fait communiquer les nœuds en permanence. Il sait à chaque instant quels nœuds sont présents, et il compte les votes : un vote par nœud par défaut ;
• pmxcfs, le système de fichiers du cluster, est monté sur /etc/pve. Il contient la configuration de tout le cluster (stockages, VM, droits, pare-feu) et la réplique instantanément sur tous les nœuds. C'est pour cela que /etc/pve/qemu-server/177.conf est visible depuis n'importe quel nœud ;
• le HA Manager surveille les VM déclarées hautement disponibles et les redémarre ailleurs si leur nœud disparaît.

Le quorum est la règle qui empêche le cluster de se couper en deux moitiés qui agiraient chacune de leur côté (le split-brain) : un groupe de nœuds n'a le droit d'agir que s'il réunit plus de la moitié des votes. Pour un cluster de n votes, le quorum vaut ⌊n / 2⌋ + 1.

Un groupe de nœuds qui perd le quorum passe /etc/pve en lecture seule : on ne peut plus démarrer, créer ni modifier de VM. Un nœud sans quorum qui ne porte aucune VM hautement disponible laisse tourner ses VM déjà démarrées ; s'il en porte, il redémarre de lui-même au bout d'une minute (l'auto-isolation, décrite plus bas), ce qui arrête tous ses invités.

Préparer le cluster

Avant de créer le cluster de Sorbier :

Corosync peut utiliser jusqu'à huit liens réseau, et bascule tout seul sur le suivant si le premier tombe. Sorbier en déclare deux : le lien 0 dans le VLAN 99 d'administration (.213 à .215) et le lien 1 sur le réseau de stockage (.242 à .244), deux chemins physiques différents. L'idéal, dans une installation plus importante, est un réseau dédié au seul Corosync, sur ses propres cartes : un réseau de stockage saturé par une sauvegarde peut retarder les messages du cluster.

Créer le cluster et ajouter les nœuds

Dans l'interface, sur pve1 : Datacenter > Cluster > Create Cluster. Cluster Name : sorbier ; Cluster Network : lien 0 192.168.10.213, puis Add pour le lien 1 192.168.10.242. Ensuite, Join Information affiche un bloc de texte à copier. Sur pve2 : Datacenter > Cluster > Join Cluster, colle les informations, saisis le mot de passe root de pve1 et les adresses de pve2 pour les deux liens. Recommence sur pve3.

En ligne de commande :

# Sur pve1 : créer le cluster avec ses deux liens
pvecm create sorbier --link0 192.168.10.213 --link1 192.168.10.242

# Sur pve2 : rejoindre le cluster par l'adresse de pve1
pvecm add 192.168.10.213 --link0 192.168.10.214 --link1 192.168.10.243

# Sur pve3
pvecm add 192.168.10.213 --link0 192.168.10.215 --link1 192.168.10.244

Puis vérifie, depuis n'importe quel nœud :

root@pve1:~# pvecm status
Cluster information
-------------------
Name:             sorbier
Config Version:   3
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Tue Nov  3 10:12:44 2026
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

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 192.168.10.213 (local)
0x00000002          1 192.168.10.214
0x00000003          1 192.168.10.215

Les lignes à lire : Quorate: Yes, Expected votes: 3, Total votes: 3, Quorum: 2. Les trois nœuds apparaissent maintenant dans l'arbre de l'interface, sous Datacenter, et tu peux les administrer tous depuis l'interface de n'importe lequel.

Le cas d'un cluster à deux nœuds. Pour un laboratoire ou une petite agence à deux nœuds, ajoute un QDevice : installe corosync-qnetd sur une petite machine Debian extérieure au cluster (une VM sur un autre hôte, un mini-PC), corosync-qdevice sur les deux nœuds, puis lance depuis un nœud pvecm qdevice setup <adresse-du-qdevice>. Le QDevice apporte le troisième vote, sur le port TCP 5403. Sur un cluster à nombre impair de nœuds, Proxmox le déconseille.

La migration à chaud

La migration à chaud (live migration, l'équivalent du vMotion de VMware) déplace une VM allumée d'un nœud à l'autre sans interrompre ses services. Elle sert à vider un nœud avant une maintenance, à répartir la charge, à rapprocher deux VM qui se parlent beaucoup. Le principe :

1. Proxmox démarre sur le nœud cible une VM identique, en pause ;
2. il copie la mémoire de la VM pendant qu'elle continue de tourner ; les pages modifiées pendant la copie sont recopiées, en plusieurs passes de plus en plus courtes ;
3. quand il reste très peu de pages, il met la VM source en pause, copie le reste et l'état du processeur, et reprend la VM sur la cible. L'interruption dure quelques dizaines de millisecondes : les connexions TCP ne s'en aperçoivent pas.

Si les disques sont sur un stockage partagé, seule la mémoire voyage. S'ils sont sur un stockage local, Proxmox sait aussi copier les disques pendant la migration (option with local disks), mais c'est beaucoup plus long.

Dans l'interface : sélectionne la VM, Migrate, choisis le Target node, et laisse le mode Online si elle tourne. En ligne de commande :

qm migrate 179 pve2 --online                       # disque sur le NFS partagé
qm migrate 186 pve3 --online --with-local-disks    # disque local, copié pendant la migration
pct migrate 182 pve2 --restart                     # un conteneur : arrêt, déplacement, redémarrage

Le trafic de migration passe par défaut par le réseau du cluster. Sorbier l'envoie sur le réseau de stockage, plus rapide, dans Datacenter > Options > Migration Settings, ce qui écrit dans /etc/pve/datacenter.cfg :

migration: secure,network=192.168.10.240/28

secure chiffre la migration dans un tunnel SSH : la mémoire d'un contrôleur de domaine contient des secrets qui ne doivent pas circuler en clair, même sur un réseau interne.

La réplication ZFS entre nœuds

Sans stockage partagé, une autre solution existe pour les disques sur ZFS local : la réplication. Proxmox envoie périodiquement vers un autre nœud les blocs modifiés depuis la dernière réplication. Si le nœud tombe, la VM peut redémarrer sur l'autre nœud à partir de la dernière copie, avec la perte des données écrites depuis.

# Répliquer la VM 186 (disque sur local-zfs) vers pve2 toutes les 15 minutes
pvesr create-local-job 186-0 pve2 --schedule "*/15"
pvesr status

Dans l'interface : VM, onglet Replication, Add. La perte maximale de données (le RPO, voir le cours Sauvegarde et PRA) est l'intervalle de réplication : ici 15 minutes. C'est la solution des petits clusters sans NAS.

La haute disponibilité

Le HA Manager de Proxmox VE surveille les ressources HA (des VM ou des conteneurs déclarés hautement disponibles) et les redémarre sur un autre nœud si le leur disparaît. Ses exigences :

• au moins trois nœuds (ou deux et un QDevice), pour un quorum fiable ;
• des disques sur un stockage partagé (ou répliqués, en acceptant la perte des dernières minutes) ;
• de la place sur les nœuds restants : avec trois nœuds, deux doivent pouvoir porter toutes les VM hautement disponibles (chapitre 12).

L'auto-isolation (fencing). Avant de redémarrer une VM ailleurs, le cluster doit être sûr qu'elle ne tourne plus sur son ancien nœud : deux instances de la même VM écrivant sur le même disque le détruiraient. Proxmox utilise un chien de garde (watchdog), matériel ou, à défaut, le softdog du noyau : un nœud qui a des ressources HA et perd le quorum cesse de « nourrir » son chien de garde, qui le redémarre au bout de 60 secondes. Les autres nœuds attendent ce délai, puis relancent ses VM. Au total, la détection et la reprise prennent environ 2 minutes.

Déclarer une ressource HA. Dans l'interface : VM, More > Manage HA, ou Datacenter > HA > Resources > Add, avec l'état demandé (Request State) started. En ligne de commande :

ha-manager add vm:177 --state started --max_restart 1 --max_relocate 1
ha-manager add vm:181 --state started
ha-manager add vm:179 --state started
ha-manager status

Les états possibles d'une ressource : started (le HA Manager la maintient démarrée), stopped (arrêtée, mais déplaçable), disabled (arrêtée et non déplacée) et ignored (le HA Manager l'ignore, le temps d'une intervention manuelle). max_restart et max_relocate fixent combien de fois il essaie de la redémarrer sur place, puis sur un autre nœud.

Les règles d'affinité. Depuis Proxmox VE 9, la répartition des ressources se règle par des règles (Datacenter > HA > Affinity Rules) qui remplacent les anciens groupes HA :

• une règle d'affinité de nœud indique sur quels nœuds une ressource doit tourner de préférence ;
• une règle d'affinité de ressources garde des ressources ensemble (positive) ou séparées (negative).

Chez Sorbier, les deux contrôleurs de domaine ne doivent jamais tourner sur le même nœud : la panne de ce nœud couperait l'annuaire, le DNS et le DHCP d'un coup.

# Garder srv-ad et srv-ad2 sur des nœuds différents
ha-manager rules add resource-affinity separer-dc --affinity negative --resources vm:177,vm:181

# Préférer pve1 pour srv-ad (sans l'interdire ailleurs)
ha-manager rules add node-affinity srv-ad-pve1 --resources vm:177 --nodes pve1

La maintenance d'un nœud. Avant de mettre à jour ou d'arrêter pve2, passe-le en mode maintenance : le HA Manager migre à chaud ses ressources vers les autres nœuds, et ne lui en confie plus aucune jusqu'à la sortie du mode.

ha-manager crm-command node-maintenance enable pve2
# … mise à jour, redémarrage de pve2 …
ha-manager crm-command node-maintenance disable pve2

Pour une intervention qui touche tout le cluster (changement du réseau du cluster, de Corosync), Proxmox VE 9.2 permet de désarmer la haute disponibilité : ha-manager crm-command disarm-ha freeze libère tous les chiens de garde, si bien qu'aucun nœud ne s'auto-isole et qu'aucune reprise automatique n'a lieu pendant les travaux ; ha-manager crm-command arm-ha la réarme ensuite.

Ce qui se passe quand on éteint un nœud sans mode maintenance dépend de la politique d'arrêt (Datacenter > Options > HA Settings) : conditional par défaut (les ressources sont arrêtées si le nœud s'éteint, gelées s'il redémarre), freeze, failover ou migrate.

La répartition de charge (CRS)

Quand le HA Manager doit placer une ressource (reprise après une panne, mode maintenance, démarrage), c'est le planificateur de ressources du cluster (Cluster Resource Scheduler, CRS) qui choisit le nœud cible. Son mode se règle dans Datacenter > Options > Cluster Resource Scheduling :

Avec le mode Static-load ou Dynamic-load, le HA Manager peut aussi rééquilibrer automatiquement le cluster (CRS Load Balancer, à activer dans le même menu), à la manière du DRS de VMware : quand le déséquilibre du cluster (calculé à partir de l'écart type des charges des nœuds) dépasse un seuil (30 % par défaut) pendant plusieurs tours du HA Manager, de dix secondes chacun, il migre à chaud des ressources HA vers les nœuds moins chargés. Ces migrations respectent toujours les règles d'affinité, et une ressource peut en être exclue (option auto-rebalance désactivée). L'option ha-rebalance-on-start, dans le même menu, fait en plus choisir par le CRS le nœud le plus adapté au moment où une ressource HA démarre (encore en aperçu technologique avec les modes Static-load et Dynamic-load).

Chez Sorbier, le mode Basic serait trompeur : il compte une VM Windows de 4 Gio comme un conteneur de 512 Mio. Le mode Static-load tient compte de la taille réelle des invités, et Dynamic-load de ce qu'ils consomment vraiment ; dans tous les cas, la règle d'affinité négative garde srv-ad et srv-ad2 sur des nœuds différents.

Proxmox Datacenter Manager

Au-delà d'un cluster, Proxmox Datacenter Manager (version 1.x depuis décembre 2025) rassemble dans une seule interface plusieurs clusters et nœuds isolés : vue d'ensemble des ressources, suivi des mises à jour, et migration d'une VM d'un cluster à l'autre. Pour Sorbier, il servira le jour où l'agence de Marseille aura son propre petit cluster.

Exercices