Haute disponibilité des VM : Proxmox HA, vSphere HA et migration à chaud

La haute disponibilité des machines virtuelles consiste à redémarrer automatiquement, sur un autre hyperviseur du cluster, les VM d'un hyperviseur tombé en panne. La migration à chaud, elle, déplace une VM en fonctionnement d'un hôte à l'autre sans l'arrêter, pour une maintenance planifiée. Ce chapitre explique ce dont un cluster d'hyperviseurs a besoin, comment fonctionnent la migration à chaud et le redémarrage automatique, puis met en place Proxmox VE HA et présente vSphere HA et Hyper-V.

Ce que la virtualisation change

Avant la virtualisation, un service tournait sur un serveur physique : la panne d'un serveur coupait un service. Aujourd'hui, un seul hyperviseur porte souvent vingt machines virtuelles : sa panne coupe vingt services d'un coup. Chez Ravelle Conseil, c'est le plus gros SPOF (chapitre 2).

Mais la virtualisation apporte aussi la solution : une VM n'est qu'un ensemble de fichiers (sa configuration et ses disques virtuels). Si ces fichiers sont accessibles depuis un autre hyperviseur, la VM peut y redémarrer en quelques instants. Le cours virtualisation présente les hyperviseurs et la création des VM, et monte un cluster Proxmox VE avec migration à chaud ; ce chapitre s'intéresse à leur disponibilité et compare les solutions.

Trois mécanismes à ne pas confondre

Les ingrédients d'un cluster d'hyperviseurs

1. Au moins trois nœuds, pour le quorum (chapitre 7), ou deux nœuds et un arbitre (un QDevice sous Proxmox VE).
2. Un stockage accessible depuis tous les nœuds : partagé (un NAS ou un SAN), distribué (Ceph) ou répliqué (ZFS). Sans cela, les disques d'une VM restent prisonniers de l'hôte en panne.
3. Un réseau redondant, avec si possible un réseau dédié aux échanges du cluster (Corosync sous Proxmox), séparé du trafic des VM et du stockage : une saturation du réseau de stockage ne doit pas faire croire à la mort d'un nœud.
4. Un mécanisme d'isolation (fencing) : chien de garde sous Proxmox VE, carte de gestion ou isolation par le stockage ailleurs.
5. Une réserve de capacité : les nœuds restants doivent pouvoir accueillir les VM du nœud perdu (voir plus bas).

Comment fonctionne la migration à chaud

Déplacer une VM qui tourne, c'est surtout déplacer sa mémoire vive, qui change en permanence. La technique la plus répandue est la pré-copie :

1. L'hôte de destination prépare une VM vide identique.
2. Toute la mémoire de la VM est copiée par le réseau, pendant qu'elle continue de tourner.
3. Les pages de mémoire modifiées pendant la copie sont recopiées, puis celles modifiées pendant cette seconde copie, et ainsi de suite : chaque passe est plus courte.
4. Quand il ne reste presque plus rien à copier, la VM est mise en pause quelques millisecondes, les dernières pages et l'état du processeur sont transférés, et la VM reprend sur l'hôte de destination.
5. L'hôte de destination annonce sur le réseau que l'adresse MAC de la VM est désormais derrière lui, pour que les commutateurs mettent à jour leur table.

Les conditions : un stockage partagé (sinon, il faut aussi copier les disques, ce qui est possible mais beaucoup plus long), des processeurs compatibles entre les hôtes (sous Proxmox, le type de processeur virtuel de la VM doit exister sur tous les nœuds ; un type générique comme x86-64-v2-AES garantit la compatibilité), et un réseau rapide entre les hôtes.

Sous Proxmox VE, depuis l'interface (bouton Migrate) ou en ligne de commande :

qm migrate 101 pve2 --online                       # VM 101 vers le nœud pve2, sans arrêt
qm migrate 101 pve2 --online --with-local-disks    # si ses disques sont locaux : plus long

Proxmox VE HA pas à pas

Proxmox VE (version 9 en 2026, sur Debian 13) intègre un gestionnaire de haute disponibilité. Chez Ravelle Conseil, on passe d'un hyperviseur à trois : pve1, pve2 et pve3, avec leurs adresses d'administration 10.10.30.11 à 10.10.30.13.

1. Créer le cluster.

pvecm create cl-ravelle        # sur pve1
pvecm add 10.10.30.11          # sur pve2, puis sur pve3 : rejoindre le cluster de pve1
pvecm status                   # « Quorate: Yes », 3 votes attendus, 3 votes présents

2. Rendre le stockage accessible à tous les nœuds. Selon le budget : un partage NFS ou un volume iSCSI d'un NAS, déclaré une fois au niveau du centre de données (Datacenter > Storage), comme le NAS TrueNAS du labo (iSCSI pour les VM Proxmox) ; un stockage Ceph réparti sur les trois nœuds ; ou une réplication ZFS entre nœuds (voir plus bas).

3. Déclarer les VM comme ressources HA.

ha-manager add vm:101 --state started     # LB1
ha-manager add vm:102 --state started     # LB2
ha-manager add vm:111 --state started     # WEB1
ha-manager add vm:112 --state started     # WEB2
ha-manager status

L'état demandé started signifie : le gestionnaire maintient la VM démarrée, et la redémarre ailleurs si son nœud tombe. Par défaut, il tente un redémarrage sur le même nœud (max_restart vaut 1), puis une relocalisation sur un autre nœud (max_relocate vaut 1) si la VM refuse de démarrer.

4. Écrire les règles de placement. Depuis Proxmox VE 9, les anciens groupes HA sont remplacés par des règles :

• une règle d'affinité de nœud dit sur quels nœuds une ressource doit, ou de préférence doit, tourner ;
• une règle d'affinité de ressources dit si des ressources doivent tourner ensemble (affinité positive) ou séparées (affinité négative, ou anti-affinité).

La règle la plus importante de Ravelle Conseil empêche les deux répartiteurs, et les deux serveurs web, de se retrouver sur le même nœud :

ha-manager rules add resource-affinity lb-separes --affinity negative --resources vm:101,vm:102
ha-manager rules add resource-affinity web-separes --affinity negative --resources vm:111,vm:112

Sans ces règles, une série de migrations peut réunir LB1 et LB2 sur pve2 sans que personne le remarque : la panne de pve2 couperait alors l'intranet, malgré deux répartiteurs.

5. Ce qui se passe quand un nœud tombe. Chaque nœud réarme son chien de garde tant qu'il appartient au groupe qui a le quorum. Un nœud isolé du cluster qui porte des ressources HA cesse de le réarmer et redémarre de lui-même au bout de 60 secondes : c'est l'auto-isolation. Le nœud qui coordonne le cluster attend que cette isolation soit certaine, puis redémarre les VM du nœud perdu sur les nœuds restants, en respectant les règles. La documentation de Proxmox VE indique une durée typique d'environ deux minutes entre la panne et le service rétabli.

6. La maintenance d'un nœud. Pour mettre à jour pve2 sans coupure :

ha-manager crm-command node-maintenance enable pve2    # ses VM HA migrent à chaud ailleurs
# mise à jour et redémarrage de pve2
ha-manager crm-command node-maintenance disable pve2   # pve2 reprend des VM

Seules les VM gérées par le gestionnaire HA migrent automatiquement ; les autres se migrent à la main avant l'opération. Proxmox VE propose aussi de désarmer temporairement toute la haute disponibilité du cluster (ha-manager crm-command disarm-ha freeze, puis arm-ha) pour une intervention lourde sur le réseau du cluster, afin d'éviter des isolations intempestives.

vSphere HA, DRS et Fault Tolerance

Chez VMware, la haute disponibilité des VM repose sur un cluster d'hôtes ESXi géré par vCenter, avec un stockage partagé (des banques de données, ou datastores, sur un SAN, un NAS ou vSAN).

• vSphere HA surveille les hôtes grâce à un agent sur chacun ; un hôte principal est élu. Pour distinguer un hôte en panne d'un hôte simplement isolé du réseau, vSphere HA utilise deux canaux : les battements sur le réseau d'administration et des battements écrits sur les banques de données partagées. Les VM d'un hôte en panne redémarrent sur les autres, selon des priorités de redémarrage. Le contrôle d'admission réserve de la capacité dans le cluster pour que ce redémarrage soit toujours possible.
• DRS (Distributed Resource Scheduler) répartit la charge en déplaçant automatiquement les VM par vMotion (la migration à chaud de VMware), et place les VM selon des règles d'affinité et d'anti-affinité.
• vSphere Fault Tolerance exécute une copie secondaire d'une VM, synchronisée en permanence, sur un autre hôte : si l'hôte principal tombe, la copie prend le relais sans aucune interruption. C'est coûteux en ressources et limité en nombre de processeurs virtuels : on le réserve à quelques VM critiques.

Depuis le rachat de VMware par Broadcom fin 2023, les licences sont vendues en abonnements groupés, plus chers pour beaucoup de petites structures : c'est l'une des raisons de la progression de Proxmox VE dans les PME et les collectivités.

Hyper-V et le cluster de basculement

Sous Windows Server, des hôtes Hyper-V réunis dans un cluster de basculement (chapitre 7) rendent leurs VM hautement disponibles : chaque VM devient un rôle du cluster, redémarré sur un autre nœud en cas de panne, et déplaçable à chaud par migration dynamique (Live Migration). Les disques des VM sont placés sur des volumes partagés de cluster (CSV), accessibles par tous les nœuds en même temps.

Hyper-V Replica est une solution plus simple, sans cluster : un hôte réplique de façon asynchrone une VM vers un autre hôte, toutes les 30 secondes, 5 minutes ou 15 minutes. En cas de sinistre, on démarre la copie à la main. C'est une solution de reprise (RPO de quelques minutes, RTO de quelques minutes à condition d'agir), pas de haute disponibilité automatique.

Le stockage des VM : partagé, distribué ou répliqué

Le chapitre 9 revient sur la réplication synchrone et asynchrone.

Dimensionner : la réserve de capacité

Un cluster ne sert à rien si les nœuds restants ne peuvent pas accueillir les VM du nœud perdu. La mémoire vive est presque toujours la ressource limitante.

Exemple. Trois nœuds de 128 Go de mémoire, dont on réserve 8 Go à chaque hôte pour Proxmox lui-même et Ceph : il reste 120 Go par nœud, soit 360 Go en tout. Pour survivre à la panne d'un nœud, toutes les VM doivent tenir sur deux nœuds : 2 × 120 = 240 Go au maximum, soit en moyenne 80 Go de VM par nœud. Chaque nœud ne doit donc être rempli qu'à 80 ÷ 128 = 62,5 % de sa mémoire en temps normal.

C'est le prix de la haute disponibilité : un tiers de la mémoire d'un cluster de trois nœuds reste en réserve. Avec plus de nœuds, la réserve relative diminue : sur cinq nœuds, la réserve d'un nœud ne représente plus qu'un cinquième de la capacité.

Exercices