Comprendre les roles dans un cluster VMware HA en 2026

VMware HA reste l’un des mécanismes fondamentaux de vSphere pour absorber la perte d’un hôte ESXi sans dépendre d’une procédure manuelle. Son objectif est simple : lorsqu’un hôte devient indisponible, redémarrer ses machines virtuelles sur les hôtes restants du cluster, dans la limite des ressources disponibles et des contraintes configurées.

En 2026, il faut toutefois éviter de présenter HA comme une solution magique. HA ne garantit ni l’absence d’interruption, ni la préservation de la mémoire d’une VM en cours d’exécution. Il orchestre un redémarrage. Le délai observé dépend de la détection de l’incident, de la décision de failover, de l’accès aux disques de la VM, de la capacité du cluster et du temps de démarrage du système invité.

La terminologie historique distinguait des hôtes « primaires » et « secondaires ». Cette formulation est désormais surtout utile pour comprendre des documentations anciennes. Dans les versions modernes de vSphere, le composant responsable est FDM, pour Fault Domain Manager. Chaque hôte ESXi membre d’un cluster HA exécute l’agent FDM. L’un des hôtes prend le rôle de master, les autres sont des agents esclaves, ou followers selon certains contextes techniques. Le rôle n’est pas une propriété permanente de l’hôte : il résulte d’une élection et peut changer après une panne ou une reconfiguration du cluster.

Architecture FDM : agents HA et rôle du master

Lorsque HA est activé sur un cluster, vCenter déploie et configure l’agent FDM sur tous les hôtes ESXi concernés. FDM ne remplace pas vCenter : il assure justement la continuité de la réaction à une panne d’hôte lorsque vCenter devient temporairement indisponible après la configuration initiale.

Le master FDM assure notamment les responsabilités suivantes :

• surveiller les autres hôtes du cluster ;
• centraliser l’état des VM protégées ;
• décider du redémarrage des VM après une défaillance confirmée ;
• coordonner les actions de failover ;
• maintenir une vision de l’inventaire HA via les métadonnées présentes sur les datastores accessibles au cluster ;
• déterminer quels hôtes peuvent accueillir les VM à redémarrer selon les ressources et les règles applicables.

Les hôtes non masters communiquent leur état et l’état des VM locales au master. Ils appliquent aussi certaines protections locales. Par exemple, un hôte isolé peut arrêter ou couper ses VM si la politique d’isolation le demande, même s’il ne peut plus joindre le master.

Une distinction importante doit être conservée : HA gère l’indisponibilité d’un hôte, tandis que DRS gère l’équilibrage de charge et les placements optimaux. DRS peut déplacer des VM avant ou après un événement HA, mais ce n’est pas DRS qui prend la décision initiale de redémarrer les VM d’un hôte perdu. De même, vMotion n’est pas un mécanisme de reprise après panne : il suppose que l’hôte source fonctionne encore.

Election du master FDM

Au démarrage d’un cluster HA, après l’ajout d’un hôte ou à la suite de la perte du master, les agents FDM organisent une élection. Le principe vise à sélectionner un hôte capable de gérer efficacement le cluster et ayant la meilleure visibilité sur ses ressources partagées.

L’élection prend notamment en compte la connectivité aux datastores accessibles par les membres du cluster. Historiquement, la logique favorisait l’hôte ayant accès au plus grand nombre de datastores partagés ; ce critère reste essentiel, car les datastores participent à la fois à la détection de panne et à la reconstruction de l’état des VM. Des critères de départage, comme l’identité de l’hôte, permettent ensuite de désigner un seul master. Pour aller plus loin, consultez vMotion, DRS et DPM.

Cette élection est automatique. Il ne faut donc pas concevoir l’architecture autour d’un « hôte primaire » matériellement plus puissant ou plus critique qu’un autre. Tous les hôtes doivent être capables d’assumer le rôle de master FDM. Une hétérogénéité excessive des accès stockage, des réseaux VMkernel ou des versions ESXi rend le diagnostic plus complexe et augmente le risque de comportements inattendus lors d’un incident.

Après l’élection, le master doit disposer d’une vision suffisamment fiable de l’inventaire. Il s’appuie sur les agents FDM, sur les fichiers et métadonnées HA stockés sur les datastores partagés, ainsi que sur l’état remonté par vCenter lorsqu’il est disponible. Si vCenter tombe, HA continue à surveiller et à redémarrer les VM selon les paramètres déjà distribués aux hôtes. En revanche, les opérations d’administration, les changements de configuration et une partie de l’observabilité restent limités jusqu’au retour de vCenter.

Détection d’une panne : heartbeats réseau et datastore

La qualité de HA dépend en grande partie de sa capacité à distinguer une panne réelle d’un problème de communication. Redémarrer une VM alors que son hôte d’origine l’exécute toujours crée un risque de double exécution, particulièrement dangereux pour les bases de données, les systèmes de fichiers distribués et les applications à état.

VMware HA combine donc plusieurs signaux.

Le premier mécanisme est le heartbeat réseau entre agents FDM. Les hôtes du cluster communiquent sur le réseau de management, généralement via une interface VMkernel dédiée ou partagée selon l’architecture. Lorsqu’un master cesse de recevoir les heartbeats d’un hôte, il suspecte une défaillance. Mais l’absence de heartbeat réseau ne prouve pas que l’hôte est arrêté : il peut s’agir d’une rupture réseau, d’une erreur VLAN, d’une saturation, d’un défaut de commutateur ou d’un problème de pile TCP/IP.

Le second mécanisme est le datastore heartbeat. Les hôtes HA écrivent périodiquement des informations de présence sur des datastores partagés sélectionnés par le cluster. Si le master perd le heartbeat réseau d’un hôte mais continue de voir son activité sur les datastores heartbeat, il sait que l’hôte est probablement encore actif. Il évite alors de redémarrer immédiatement les VM.

Inversement, si les heartbeats réseau et datastore disparaissent, le master dispose d’un faisceau d’indices plus fort indiquant que l’hôte ne fonctionne plus ou qu’il a perdu simultanément ses accès essentiels. Le failover peut alors être déclenché.

Le datastore heartbeat est particulièrement utile dans un scénario de partition réseau. Imaginons un hôte ESXi toujours opérationnel, avec des VM en production, mais isolé du réseau de management. Sans contrôle complémentaire, le master pourrait croire l’hôte mort et relancer ses VM ailleurs. La persistance des écritures de heartbeat sur le stockage partagé permet de différer cette décision et de limiter le risque de split brain.

La conception doit néanmoins rester réaliste. Les datastores heartbeat ne remplacent pas une architecture réseau résiliente. Ils sont eux-mêmes dépendants des chemins de stockage, des contrôleurs, du réseau SAN ou de la connectivité NFS. Il est recommandé de vérifier que plusieurs datastores partagés et réellement accessibles par les hôtes du cluster sont disponibles pour cette fonction. Un cluster reposant sur un unique datastore introduit un point de fragilité évident.

La fonctionnalité de VM Component Protection, lorsqu’elle est disponible et adaptée au stockage utilisé, complète cette approche en traitant certains scénarios de perte d’accès aux composants de stockage d’une VM. Elle ne doit toutefois pas être confondue avec la détection standard de panne d’hôte.

Hôte isolé, partitionné ou définitivement indisponible

Trois situations méritent d’être distinguées dans les procédures d’exploitation.

Une panne d’hôte complète correspond par exemple à une coupure électrique, un kernel panic, un arrêt brutal, une panne matérielle ou une indisponibilité totale de l’hyperviseur. Les heartbeats réseau et datastore cessent généralement. HA redémarre les VM sur des hôtes survivants si la capacité le permet.

Une isolation survient lorsqu’un hôte perd la communication avec le réseau de management et avec les adresses d’isolation configurées, tout en pouvant continuer à exécuter les VM. L’hôte isolé applique alors la politique d’isolation définie dans le cluster. Les choix classiques sont :

• laisser les VM sous tension ;
• arrêter les VM ;
• couper l’alimentation des VM.

L’option « laisser sous tension » réduit le risque d’interruption inutile, mais elle peut retarder ou empêcher le redémarrage ailleurs si l’hôte reste isolé et conserve l’accès aux disques. Les options d’arrêt ou de coupure favorisent le failover, au prix d’une interruption volontaire des VM locales. Le bon choix dépend de la topologie, de la tolérance au risque applicatif et de la fiabilité du réseau de management.

Une partition réseau est plus subtile. Le cluster peut se scinder en plusieurs groupes d’hôtes incapables de communiquer entre eux. Chaque groupe conserve potentiellement une partie des VM et une partie de l’accès aux datastores. FDM utilise alors les informations de stockage et les mécanismes de protection pour éviter autant que possible les redémarrages concurrents. C’est précisément dans ces situations que la documentation d’exploitation, les tests de panne contrôlés et la connaissance des dépendances réseau deviennent indispensables. Pour aller plus loin, consultez l’administration d’un hôte ESXi.

Les adresses d’isolation doivent être configurées avec discernement. Elles servent à déterminer si l’hôte peut encore joindre un point réseau significatif. Une passerelle par défaut unique n’est pas toujours suffisante : sa disponibilité ne prouve pas que le chemin de management vers les autres hôtes ou vers les services critiques est fonctionnel. À l’inverse, multiplier les cibles sans comprendre leur routage peut créer des résultats ambigus.

Politique de redémarrage des VM et ordre de reprise

Lorsqu’une panne est confirmée, HA tente de redémarrer les VM affectées sur les hôtes disponibles. Les fichiers de configuration de la VM et ses disques doivent naturellement rester accessibles depuis l’hôte de destination. HA n’est donc pas une solution de reprise si les disques virtuels résident sur un stockage local perdu avec l’hôte, sauf architecture spécifique de stockage distribué ou réplication externe.

La politique de redémarrage par VM définit l’intention de disponibilité. Selon les versions et l’interface vSphere, on retrouve notamment des niveaux tels que désactivé, faible, moyen ou élevé. Ces niveaux influencent la priorité de redémarrage et le comportement de placement, mais ne remplacent pas une analyse de dépendance applicative.

Une VM de contrôleur de domaine, de service DNS, de base de données ou de middleware peut être plus critique qu’une VM applicative stateless. Pourtant, redémarrer les composants dans le mauvais ordre peut prolonger l’indisponibilité. Les groupes de démarrage et les règles d’ordre permettent de formaliser certaines dépendances. Ils doivent rester simples et documentés : une chaîne de dépendances trop rigide réduit les options de placement et ralentit parfois la reprise globale.

HA propose aussi des options de surveillance des VM. La VM Monitoring s’appuie sur les heartbeats émis via VMware Tools pour détecter une VM figée alors que l’hôte reste sain. Si les heartbeats disparaissent, HA peut réinitialiser la VM selon la sensibilité configurée. Cette fonction est utile, mais elle nécessite une validation applicative. Une VM peut être temporairement incapable de répondre à VMware Tools pendant un démarrage, une saturation CPU ou une opération de maintenance. Des faux positifs peuvent donc déclencher des redémarrages inutiles.

Après une panne, HA ne garantit pas que chaque VM redémarre immédiatement. Il place les VM selon la capacité disponible, les règles d’affinité ou d’anti-affinité, les contraintes de périphériques, les réservations et les politiques de redémarrage. Une règle DRS non compatible avec l’état dégradé ou une règle « must » trop stricte peut empêcher un redémarrage. Les équipes doivent distinguer les règles nécessaires à l’intégrité fonctionnelle de celles qui relèvent seulement d’une préférence de placement.

Admission Control : réserver réellement la capacité de failover

L’admission control est souvent mal compris. Il ne sert pas à accélérer le redémarrage après incident ; il sert à empêcher que le cluster soit trop chargé avant l’incident. Sans admission control, un cluster peut accepter de nouvelles VM jusqu’à saturation. Lorsqu’un hôte tombe, il ne reste alors aucune marge pour relancer les VM perdues.

HA calcule et applique une capacité de failover selon une politique définie. L’approche moderne la plus lisible consiste généralement à réserver un pourcentage de ressources CPU et mémoire pour les pannes d’hôtes. Par exemple, dans un cluster de quatre hôtes homogènes, réserver 25 % peut couvrir la perte théorique d’un hôte, sous réserve que les capacités réellement consommées, les réservations VM et la répartition des charges soient cohérentes.

Le calcul ne doit pas être réduit à une simple règle arithmétique. Un cluster de quatre hôtes affichant 25 % de capacité libre peut malgré tout échouer à reprendre certaines VM si :

• une VM possède une forte réservation mémoire ;
• les hôtes ne sont pas homogènes ;
• des contraintes NUMA ou des périphériques limitent le placement ;
• des règles d’affinité empêchent l’utilisation d’un hôte ;
• la capacité libre est concentrée sur des hôtes non éligibles ;
• la surcharge CPU acceptable en fonctionnement dégradé a été mal évaluée.

Les réservations mémoire des VM ont un impact direct. Une réservation constitue un engagement que l’hôte de destination doit pouvoir satisfaire. Dans un cluster fortement réservé, l’admission control peut refuser de nouvelles mises sous tension même si les graphiques de consommation moyenne semblent confortables. C’est un comportement sain : la réservation garantit une capacité, pas une moyenne statistique.

Les politiques de capacité de failover peuvent inclure une tolérance exprimée en nombre d’hôtes défaillants ou en pourcentage de ressources. Une option dédiée permet aussi de définir explicitement la capacité à réserver. Le choix dépend surtout de l’homogénéité du cluster et de la maturité du modèle de capacité.

Quelques recommandations pratiques :

• dimensionner sur les réservations et les pics réalistes, pas seulement sur la consommation moyenne ;
• prévoir la maintenance : un cluster capable de survivre à une panne mais incapable d’absorber un hôte en maintenance n’offre qu’une résilience limitée ;
• surveiller régulièrement l’état de conformité HA et les alertes d’admission control ;
• documenter les VM avec réservations importantes ;
• tester le comportement lors de l’indisponibilité contrôlée d’un hôte ;
• vérifier les règles DRS, les groupes d’hôtes et les règles d’affinité avant de conclure qu’une capacité théorique est réellement exploitable.

Une stratégie fréquente consiste à réserver N+1, c’est-à-dire la capacité nécessaire à la perte d’un hôte. Pour des charges critiques ou un domaine de panne plus exposé, N+2 peut être justifié. Le bon niveau n’est pas universel : il résulte d’un arbitrage entre coût, risque accepté, fenêtre de maintenance et objectifs de reprise. Pour aller plus loin, consultez l’architecture vSphere et vCenter.

Exploitation : vérifier HA avant d’en avoir besoin

HA doit être validé comme un service opérationnel, pas seulement activé dans l’interface. Les vérifications périodiques devraient couvrir l’état des agents FDM, la redondance du réseau de management, l’accessibilité des datastores heartbeat, les paramètres d’isolation, les alertes de capacité et les journaux d’événements HA.

Sur un hôte ESXi, les journaux FDM sont utiles pendant une investigation. Les emplacements et noms exacts peuvent varier selon les versions, mais la consultation des journaux système et du service FDM permet de corréler une élection, une perte de heartbeat ou une décision de failover. Une première collecte peut être réalisée avec :

grep -i fdm /var/log/fdm.log

Pour vérifier l’état général des services de l’hôte et rechercher des événements récents, les commandes suivantes peuvent compléter l’analyse :

esxcli system maintenanceMode get
esxcli network ip interface list
esxcli storage filesystem list

Ces commandes ne remplacent pas l’analyse dans vCenter, où l’on retrouve l’historique des événements du cluster, les décisions HA, les échecs de redémarrage et les causes de non-admission. Elles sont surtout utiles lorsqu’un hôte reste joignable en SSH ou via la console locale.

Enfin, le test reste indispensable. Une simulation contrôlée de panne d’hôte, réalisée dans une fenêtre approuvée et avec des VM de test représentatives, révèle souvent les écarts entre la configuration théorique et la réalité : datastore non partagé, règle DRS bloquante, capacité insuffisante, dépendance applicative oubliée ou politique d’isolation inadaptée.

HA est efficace lorsqu’il s’inscrit dans une conception cohérente : réseau de management redondant, stockage partagé résilient, capacité réservée, règles de placement maîtrisées et applications capables de redémarrer proprement. Il ne supprime pas le besoin de sauvegarde, de réplication intersite ou de plan de reprise d’activité. Il traite un scénario précis, la perte d’un hôte, avec une mécanique robuste à condition que les fondations du cluster le soient aussi.