Deepdive – vSphere HA – Comment ça marche ?

Deepdive vSphere HA – Comment ça marche ?

Présentation de HA :

VMware vSphere High Availability (HA), est une solution de « haute disponibilité ». Elle peut être activée sur un cluster avec de multiples hyperviseurs ESXi par l’intermédiaire du vCenter.

HA va permettre en cas de panne d’un hyperviseur du cluster, de redémarrer automatiquement les machines virtuelles reposant sur l’hyperviseur impacté sur d’autres hyperviseurs ESXi au sein de ce même cluster vSphere.

Exemple: Un hôte ESXi02 en panne et le processus de HA relance les VMs sur les autres hyperviseurs du cluster

Quels sont les trois composants majeurs de vSphere HA ?

  • FDM
  • HOSTD
  • vCenter


 

 

 

 

 

 

 

 

FDM

Fault Domain Manager (Anciennement appelé AAM « Legato’s Automated Availability Manager » est responsable de nombreuses tâches comme :

  • La surveillance des hôtes « slave »
  • Le redémarrage et le placement des VMs en cas de problème
  • La gestion d’ajout et de suppression d’hôtes au cluster
  • La surveillance et la gestion de l’état des VMs du cluster
  • La responsabilité des échanges d’informations avec le vCenter
  • La configuration HA des différents hôtes
  • La responsabilité des échanges Heartbeat entre les hôtes

Depuis la version 5, FDM a été complétement réécrit et ne possède plus de dépendance avec l’agent VPXA (l’agent de management responsable de la communication vers VPXD l’agent présent sur le vCenter), il ne dépend plus du DNS et travail avec l’IP de management des hyperviseurs. De plus, si pour X raisons FDM échoue un mécanisme de surveillance « vmware-watchdog » relance l’agent en toute transparence. L’agent FDM est installé dans /opt/vmware/fdm et sa configuration dans /etc/opt/vmware/fdm.

Les logs relatifs à FDM sont stockés dans le fichier /var/log/fdm.log

L’agent FDM va agir sur des problèmes tel que la perte d’un hôte (problème matériel ou software « purple screen ») au sein d’un cluster mais va aussi avoir la capacité à gérer des situations tel qu’une perte du réseau de management ou un APD « All Path Down » du côté stockage.

Pour ceux qui ne savent pas ce qu’est un APD, je vous invite à visiter la KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004684

HOSTD

L’agent FDM communique directement avec HOSTD et le vCenter.

FDM s’appuie sur HOSTD pour récupérer les informations des VMs enregistrées sur l’hyperviseur et pour gérer les VMs.

FDM est entièrement dépendant de HOSTD, si pour X raisons HOSTD devient inaccessible ou n’est pas relancé après un redémarrage, FDM ne peut plus remplir son rôle et attend que HOSTD redevienne actif. Dans une telle situation, l’ESXI ne participera plus aux différents processus liés à FDM. HOSTD gère entre autre les tâches de mise sous tension des VMs.

HOSTD est installé dans /bin et sa configuration dans /etc/vmware/hostd

Les logs relatifs à hostd sont stockés dans le fichier /var/log/hostd.log

vCenter

Le vCenter est le point central d’une infrastructure ESXi. C’est lui qui déploie et configure l’agent HA « FDM » sur les hyperviseurs ESXi, qui informe l’hôte master des changements de configuration du cluster (ajout d’un hôte au cluster, modification d’un paramètre du cluster, etc …).

Il participe à la protection des VMs (Exemple : quand une VM passe en powerOff / powerOn ou qu’un hôte ESXi est déconnecté du vCenter) en informant l’hôte master de les protéger ou non.

Le vCenter n’est pas sollicité lors d’un déclenchement de HA par contre dans le cas d’un ESXi en mode Staless (chargé entièrement en mémoire, pas de disques locaux) ou d’un réseau de management sur un DvSwitch, il est nécessaire d’attendre que la bascule HA redémarre le vCenter afin de pouvoir effectuer de nouveau des changements sur le cluster (Ne pas oublier de mettre le vCenter en High Priority restart).

Les bases du fonctionnement de HA:

Dans la version actuelle de vSphere, l’architecture HA se base sur un agent « master » et des agents « slave » sur les hôtes. Dans l’état normal d’un cluster, il existe un seul hôte avec un agent «master» (maître) et les autres hôtes avec des agents « slave » (esclaves). L’hôte possédant le rôle master est leader sur les décisions au niveau du cluster, il est responsable des échanges d’informations avec le vCenter, de l’état des VMs et de leurs redémarrages en cas de problème. Les hôtes disposant d’agent « slave » communiquent leurs informations au master et sont responsables du redémarrage des VMs de leur hôte en cas de problème sous les ordres du master. A noter que chaque agent à la possibilité de devenir master lors de problème bien spécifique comme un partitionnement de réseau. Un hôte master est responsable de la sécurité d’une VM dans un cluster HA en prenant le lead sur le datastore ou se situe son fichier de configuration .VMX.

Comment est élu le Master ?

Lorsque HA est activé sur un cluster, l’un des hyperviseur du cluster est élu « master ». Cette élection du master dure environ 15s et se fait par communication UDP sur le port 8182 entre les agents des hyperviseurs. Le choix du « master » se base sur l’hôte qui détient le plus grand nombre de datastores connectés. Si plusieurs hôtes ont le même nombre de datastore, le choix se base sur le « Managed Object Id » (MOID) de l’hôte. C’est celui qui détient le plus grand chiffre « lexicalement » (exemple : 79 est plus fort que 110 car il commence par « 7 ») qui est élu. Après élection du master, les autres hyperviseurs du cluster connectés au réseau de management auront une connexion TCP chiffrée « SSL » vers le master.

Pour récupérer le MOID de vos hosts en PowerCLI :

Dans mon cas esxi102 l’emporte avec comme différenciateur le 2nd chiffre « 5 » du nombre 15

En interface GUI, le résultat est bien le même :


Quand intervient une élection de master ?

  • Une élection de master a lieu quand l’une des actions suivantes se produit sur l’hôte master :
  • L’hôte master tombe en panne
  • Une isolation ou partitionnement réseau a lieu
  • Une mise en maintenance est initiée
  • Lors d’une reconfiguration de HA.

Quand un master est élu, ce dernier va essayer de prendre le contrôle sur tous les datastores soit en accès direct, soit par l’intermédiaire d’un hôte slave agissant comme un proxy via son réseau de management. Le master va verrouiller un fichier « protectedlist » stocké sur les datastores actuels et futurs via de tentatives régulières.

L’emplacement de ce fichier dans les datastores:

/<datastore>/.vSphere-HA/<cluster-directory>/protectedlist


Comment est formé le <cluster-directory>:

<uuid of vCenter Server>-<number part of the MoID of the cluster>-<random 8 char string>-<name of the host running vCenter Server>


Le master utilise ce fichier « protectedlist » pour stocker l’inventaire des VMs. Ce fichier lui permet de tracer les VMs protégées par HA. Le contenu du fichier est une liste des VMs protégées qui comprend les informations de réservation CPU et l’overhead mémoire*. Ce fichier est placé sur tous les datastores ou sont hébergé des VMs du cluster.

(*) Pour ce qui se demande encore ce que c’est que l’overheard mémoire. Pour simplifier, ce n’est ni plus ni moins que la quantité de mémoire nécessaire pour faire fonctionner une VM.

Pour les plus curieux : https://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.resmgmt.doc/GUID-4954A03F-E1F4-46C7-A3E7-947D30269E34.html

Que se passe-il lorsque l’hôte master tombe en panne ou est isolé du réseau ?

Quand l’hôte master devient inaccessible, le verrouillage sur le fichier « protectedlist » expire et un nouveau master élu est en mesure de verrouiller de nouveau le fichier si le datastore est toujours accessible.

En cas d’isolation réseau (plus de communication via le réseau de management), le master va libérer le verrou du fichier « protectedlist » sur le datastore afin de s’assurer que le nouveau master élu, sera en mesure de lire le fichier et de déterminer les VMs protégées par HA. Si vous n’êtes pas très chanceux et que l’hôte master tombe au même moment que l’isolation réseau, le redémarrage des VMs sera retardé jusqu’à l’élection d’un nouveau master. (Le délai de reprise d’activité se retrouve un peu allongé).

Comment les hôtes « slave » savent que le master est inaccessible ?

vSphere utilise un signal de pulsation « heartbeat » en réseau point à point dialoguant sur le réseau de management. Si les hyperviseurs « slaves » ne reçoivent plus de heartbeat du « master », ils essaient d’élire un nouveau « master ». Une fois élu, le nouveau master va lire les informations du fichier « protectedlist » et va être capable de redémarrer les VMs dans les 10s qui suivent.

Pourquoi un mécanisme de détection pour les hôtes « slave » inaccessible ?

Le « master » joue un rôle important dans la surveillance de l’état des hôtes « slave ». C’est lui qui informe au vCenter l’état des hôtes « slaves ». Si l’état d’un hôte « slave » est inaccessible ou isolé sur le réseau de management, le master va déterminer quelles sont les VMs qui doivent être redémarrées et sur quels hôtes. Pour effectuer cela, le master utilise un moteur de placement qui va répartir les VMs de manière uniforme sur les hôtes du cluster et initier le redémarrage des VMs.

Quelles sont les responsabilités d’un hôte « Slave » ?

Un hôte « slave » a pour rôle de surveiller l’état des VMs en cours d’exécution sur lui-même et d’informer l’hôte master d’un changement d’état. Les hôtes « Slave » participent à la surveillance de l’état du « master » via les heartbeats envoyés par le réseau de management. Si l’hôte « master » devient inaccessible, ce sont les hôtes « slave » qui vont initier et participer à l’élection du nouveau « master ».

A quoi servent les fichiers sur chaque « slave » et sur le « master » ?

Les hôtes « master » et « slaves » utilisent des fichiers non seulement pour stocker l’état des VMs par hôte, mais aussi pour des mécanismes de communication permettant de faire passer des messages via le stockage en cas d’isolation réseau.

Il existe un fichier « host-<number>-poweron » par hôte participant au cluster et dans chaque fichier, figure l’état des VMs par hôte (slave ou master).

De quoi est composé ce fichier :

host-<number>-poweron


Ce fichier est aussi utilisé par les hôtes « slaves » pour informer le « master » d’une isolation réseau de l’hôte sur le réseau de management. Le master pourra alors en informer à son tour le vCenter.

Analysons le contenu avec l’éditeur VI:

Exemple de fichier host-<number>-poweron avec une seule VM allumée :

Exemple de fichier avec toutes les VMs éteintes :

La 1ère ligne

Contient un nombre incrémenté à chaque modification de l’état d’une VM. (PowerOn / PowerOff)

La 2nd ligne du fichier contient « 0 » ou « 1 ».

0 = Pas d’isolation réseau détectée

1= Une isolation réseau détectée

La 3ème ligne du fichier contient « 0 » ou « 1 ».

0 = Toutes les VMs sont éteintes sur l’hôte

x= Nombre de VMs allumées sur l’hôte

Lorsque HA est configuré, un hôte va aussi stocker des informations à propos de son cluster sur son stockage local dans:

/etc/opt/vmware/fdm/


Chaque hôte (y compris le master), va stocker localement des informations d’états, la matrice de compatibilité HA entre VM / hôte, la configuration du cluster et des VMs enregistrées sur l’hôte. Chaque mise à jour des informations est envoyée au master par le vCenter et propagée aux hôtes « slaves » par le master.

Exemple de modification du paramètre « isolation response » au sein du cluster :

Le changement a bien été pris en compte avec la mise à jour du fichier local «clusterconfig» :

Rôle des fichiers locaux ?

Clusterconfig: Fichier non lisible qui contient les détails de la configuration du cluster

Vmmetadata: Fichier non lisible qui contient la matrice de compatibilité de toutes les VMs protégées par HA et la liste de tous les hôtes compatibles pour la reprise.

fdm.cfg : Fichier contenant les paramètres de configuration de l’agent FDM en ce qui concerne les logs, les alertes et les répertoires de travail

hostlist : Fichier qui contient la liste des hôtes du cluster (nom de l’hôte, IP, MAC adresse et le datastore pour le hertbeat)

Analyse du contenu avec l’éditeur VI du fichier hostlist :

Pour lire les fichiers non lisibles, nous allons utiliser le script « ./prettyPrint.sh » présent dans le répertoire de l’agent FDM de la manière suivante :

A quoi sert exactement le heartbeat ?

Le heartbeat est le mécanisme utilisé par HA pour valider ou non l’état actif d’un hôte ESXi.

Depuis la version 5.0 chaque hôte « slave » envoi un heartbeat à son « master » et le master envoi un heartbeat à chaque hôte « slave » en mode point à point « Unicast » (anciennement en « multicast » sur les précédentes versions de vsphere).


Ces signaux « heartbeats » sont envoyés chaque seconde et ils interviennent à deux niveaux :

Sur le réseau « Heartbeat Network »

  • Le heartbeat réseau permet de déterminer l’état d’un hôte ESXi au travers du réseau de management. L’agent FDM de l’hôte master tente de joindre l’agent FDM de l’hôte slave et inversement. Il est possible d’ajouter des adresses d’isolation comme une passerelle ou autres équipements sur IP permettant la vérification de l’état de l’hôte défaillant via un ping.

Sur le stockage « Heatbeat Datastore »

  • Le heartbeat sur les datastores est arrivé avec la version 5.0 de vSphere afin d’ajouter de la résilience et empêcher des redémarrages inutiles des VMs lors d’une isolation réseau.

Exemple de scénario :

  • L’hyperviseur « ESXi02 » slave ne répond plus aux échanges heartbeat réseau de l’agent FDM de l’hôte master et inversement.
  • L’hyperviseur ESXi02 ne ping pas non plus « l’isolation response address »
  • L’hyperviseur ESXi02 via son agent FDM répond aux « heartbeat datastore » avec le datastore VMFS
  • L’hyperviseur ESXi02 a donc conscience d’être isolé par l’intermédiaire du fichier « host-<number>-poweron » présent sur le datastore VMFS car la 2nd ligne passe à la valeur 1.
  • L’hyperviseur ESXi02 va prendre en compte la configuration de « l’isolation response » (Leave power on / power off ou shutdown).


Comment fonctionne le heartbeat Datastore ?

Ce mécanisme va permettre à l’hôte « master » de déterminer l’état de l’hôte non accessible par son réseau de management. Afin de déterminer la panne sur l’hôte distant (en panne ou en isolation réseau) on va se baser sur les fichiers « host-<number>-poweron » présent dans /.vSphere-HA/FDM-fxxxxxxxxxxx.

Ce fichier est mise à jour par l’hôte qui se retrouve isolé, sans ce fichier, il n’y a aucun moyen au master de valider l’isolation car le réseau de management est coupé !

Grâce au contenu de ce fichier le master va prendre les mesures appropriées.

  • Si le master détermine qu’un hôte est en état inaccessible et sans échange de « heartbeat datastore », le master va redémarrer les VMs de l’hôte en question sur l’un des autres hôtes du cluster.
  • Si le master détermine qu’il s’agit d’une isolation réseau, il prendra les mesures appropriées pour les VMs en fonction de la configuration de «l’isolation response» ci-dessous :


Par défaut, HA sélectionne deux datastores pour le « heartbeat datastore » mais il est possible d’en spécifier plus en modifiant la valeur de « das.heartbeatDsPerHost » (Paramètre intéressant pour des configurations en cluster étendu sur 2 sites)

Comment sont sélectionnés les volumes participants au Heartbeat Datastore ?

Premièrement, HA donne une priorité plus élevée à des volumes de type VMFS que NFS. Le choix des volumes peut être défini manuellement ou automatiquement par le vCenter via un algorithme de sélection basé sur le nombre d’hôtes connectés aux LUN. Sur des configurations de type « cluster étendu » ou « métro-cluster », le vCenter ne sera pas forcement conscient de cette notion de site distant, il convient donc de définir manuellement deux datastores présentés à un maximum d’hôtes du cluster sur chacun des sites.

Sur du stockage en mode bloc (le cas de VMFS), HA va utiliser un mécanisme propre à VMFS appelé « heartbeat region ». Afin de mettre à jour ce « Heartbeat region », l’hôte doit avoir au moins un fichier ouvert sur le datastore. Afin de s’assurer qu’un fichier est ouvert sur le datastore, HA créé un fichier spécialement pour le « Heartbeat region ».

Un fichier par hôte est créé sur les datastores désignés pour le Heartbeat de datastore dans /.vSphere-HA/FDM-xxxxxxxxxx

Le fichier est le suivant :

host-<number>-hb


Sur du stockage en mode fichier (NFS), chaque hôte va écrire son fichier de « heartbeat region », dans /.vSphere-HA/FDM-xxxxxxxxxx et une fois toutes les 5 secondes l’hôte master vient vérifier l’état de l’hôte en vérifiant que l’horodatage du fichier a changé.

Que se passe-t-il si je supprime des datastores ?

HA sait gérer le retrait d’un datastore VMFS ou NFS et sélectionne de nouveaux volumes pour le heartbeat datastore.

Une attention particulière doit être portée sur les environnements à réseau convergé (1), l’utilisation du « datastore heartbeat » à peu de valeur due au fait que la perte d’une interface réseau crée une panne sur le réseau mais aussi sur le stockage.

Pour ceux qui ne le savent pas, un réseau convergé, permet simplement de faire transiter le réseau normal (management, vm, etc …) et stockage via les mêmes cartes réseaux. Je vous invite à jeter un œil sur le protocole FCOE et les cartes de type CNA « Converged Network Adapter ».

Comment réagit HA dans le cas d’un partitionnement du réseau ?

Attention à ne pas confondre le partitionnement réseau avec une isolation réseau ! Le partitionnement réseau arrive la plupart du temps sur des configurations en cluster étendu. Un simple problème sur un commutateur du réseau de management (mauvaise configuration vlan, configuration de cluster mêlant IPV4/IPV6, déplacement du réseau de management de certains hôtes sans utiliser la mise en maintenance, etc …) et le cluster peut se retrouver divisé en deux parties.

Exemple d’isolation réseau :


Exemple de partitionnement réseau :

Deux hôtes sont considérés partitionnés quand ils sont opérationnels mais ne peuvent pas se joindre via le réseau de management.

Comme nous l’avons expliqué, un hôte échange des heartbeats via son réseau de management, s’il n’observe plus de trafic et qu’il ne parvient pas à joindre les « isolation adresses » configurées, il reconnait être isolé.

Mais lorsque plusieurs hôtes d’un même cluster se retrouvent isolés au même moment, pour X raisons, nous allons nous retrouver face à des groupes d’hôtes isolés. Chaque groupe ne pouvant plus communiquer avec l’autre groupe mais uniquement au sein de son groupe.

Lorsqu’un cluster est partitionné en plusieurs groupes, chaque groupe partitionné va élire son propre hôte master. Si vous avez deux partitions réseau votre cluster aura deux hôtes master et ce jusqu’à la correction du problème réseau. Une fois la panne corrigée l’un des deux hôtes master reprendra son rôle de master et sera de nouveau responsable du cluster.

Un master informe qu’un hôte est partitionné ou isolé quand il ne peut pas communiquer avec un autre hôte via le réseau de management mais qu’il peut toujours recevoir le « heartbeat datastore ». Il est difficile aux masters de différencier les deux états (isolation réseau ou partitionnement réseau)

Le nouveau master va tenter de protéger les VMs dans son nouveau groupe. Le problème est que l’hôte master du 1er groupe protège peut être encore les VMs et verrouille le fichier « protectedlist ». N’oublions pas que le verrouillage se base sur l’emplacement du fichier .VMX d’une VM et non sur le .VMDK

En cas de nouvelle création de VM pendant le partitionnement réseau. La VM sera crée depuis le vCenter et donc sur les hôtes vu par le vCenter (1er groupe partitionné). Il reste possible de créer une VM sur l’un des hyperviseurs du 2nd groupe en se connectant en direct sur l’hyperviseur depuis un vSphere Client mais il est recommandé de solutionner le problème de partitionnement réseau avant. A noter, que pendant le partitionnement réseau l’admission control* n’est peut-être pas en mesure de garantir les ressources suffisantes en cas de crash d’un hôte.

(*) Un mécanisme de HA qui permet d’assurer que des ressources suffisantes sont disponibles dans un cluster pour assurer la protection des VMs lors d’un basculement. https://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.avail.doc/GUID-5432CA24-14F1-44E3-87FB-61D937831CF6.html

Il convient d’étudier finement la configuration de HA en fonction du design de votre infrastructure afin d’éviter ce genre de problème notamment sur un design en cluster étendu.

Ci-dessous un tableau des différents états possible d’un hôte :

Etat de l’hôte

Network Heartbeat

Storage Heartbeat

Host Ping

Isolation Response

Running

YES

n/a

n/a

n/a

Isolated

NO

YES

NO

YES

Partitioned

NO

YES

NO

NO

Failed

NO

NO

NO

n/a

FDM Agent Down

n/a

n/a

YES

n/a

Afin d’imager la situation, prenons l’exemple ci-dessous :

  • 4 hyperviseurs ESXi (ESXi01, 02, 03, 04) dans le même cluster étendu
  • 1 datastore VMFS étendu et visible par les 4 hôtes ESXi
  • L’isolation response configuré sur « Leave Poweron »
  • Une « isolation response address » uniquement sur le Site-A (il est recommandé d’avoir une IP par Site distant)
  • On considère que l’hôte master avant de partitionnement réseau est l’ESXI01
  • Le vCenter est une machine virtuelle hébergée sur ESXi01.


Lors du partitionnement réseau le cluster va être divisé en deux :

  • 1er groupe (Site-A): ESXi01 et ESXi02
  • 2nd groupe (Site-B): ESXi03 et ESXi04

Lors du partitionnement, les agents FDM des hôtes du 2nd groupe (Site-B) ne peuvent plus communiquer avec l’agent FDM de l’hôte master du 1er groupe (Site-A) via les échanges heartbeat sur le réseau de management.

Sur le Site-B :

  • Les hôtes du 2nd groupe (Site-B) ne peuvent pas non plus communiquer avec l’isolation response address ni avec le vCenter hébergé sur ESXi01.
  • Les hôtes ESXi03 et 04 du Site-B peuvent uniquement communiquer avec le datastore VMFS via son heartbeat de stockage.

Sur le Site-A :

  • Sur le Site-A rien ne change, le datastore reste disponible, le master reste ESXi01 et ce dernier dialogue avec ESXi02 sur le même segment.

Sur le Site-B :

  • Chaque hôte ESXi03 et 04 s’échange l’information que l’hôte master a disparu.
  • Une nouvelle élection d’hôte master a lieu et un des hôtes (ESXi03 ou ESXi04) est déclaré master.
  • Le nouveau master (admettons ESXi03) recommence via son agent FDM ces échanges heartbeat réseau avec l’hôte (ESXi04) et n’est donc pas dans un cas d’isolation réseau.

Sur le Site-A :

  • L’hôte master (ESXi01) communique toujours via le heartbeat datastore, il n’est donc pas nécessaire de redémarrer les VMs
  • Toutes les VMs du Site-B sont absentes du Site-A mais les fichiers sont verrouillés sur le stockage.

Sur le Site-B :

  • Le nouveau master (ESXi03) communique toujours via le heartbeat datastore, il n’est donc pas nécessaire de redémarrer les VMs.
  • Toutes les VMs du Site-A sont absentes du Site-B mais les fichiers sont verrouillés sur le stockage.
  • Comme il s’agit d’un problème de type « Network Partitioned » et non d’une isolation réseau. La ligne correspondante à une « isolation réseau » des fichiers « host-<xx>-poweron » n’est pas mise à la valeur 1.
  • Le nouveau master du Site-B ne déclare pas d’isolation réseau car la 1er condition est remplie (L’échange du heartbeat réseau entre l’agent FDM du nouveau hôte master (ESXi03) et celui de l’hôte slave (ESXi04) ).

Sur le Site-A :

  • Le fichier « protectedlist » va rester verrouillé par l’hôte master du Site-A (ESXi01) et contenir la liste complète des VMs (Site-A + Site-B) protégées par HA

Que se passe-t-il si un hôte tombe pendant un état de partitionnement du réseau ?

Reprenons notre exemple précédent et admettons que notre hôte ESXi04 du Site-B tombe pendant notre problème de partitionnement réseau.


L’agent FDM de l’hôte master (ESXi03) et celui de l’hôte (ESXi04) du Site-B ne peuvent plus communiquer via le réseau de management pour s’échanger le heartbeat réseau.

L’isolation response address n’est pas joignable non plus car elle est sur le Site-A.

Le heartbeat datastore ne s’échange pas non plus car il s’agit d’une panne sérieuse de l’hyperviseur ESXi04.

N’oublions pas que la liste des VMs protégées par HA figure dans le fichier « protectedlist » verrouillé par l’hôte master du Site-A (ESXi01). L’hôte master du Site-A va donc pouvoir redémarrer les VMs de l’hôte en panne (ESXi04) sur les hôtes du Site-A.

J’espère que cet article vous permettra de comprendre le fonctionnement de HA 😉

twitterlinkedin
Publié dans Vmware vSphere Tagués avec : , , , , , , , , , , , , ,
3 commentaires sur “Deepdive – vSphere HA – Comment ça marche ?
  1. KOICOU dit :

    Merci, bel article.

    D’après ce que je lis vous êtes un expert. Je serai heureux si vous pouvez me venir en aide. J’ai l’alerte suivante au niveau d’une machine de mon cluster « Action de contrôle de la machine virtuelle HA » ainsi qu’un avertissement « Erreur de contrôle de la machine virtuelle HA ».

    Depuis ce jour impossible de démarrer cette machine virtuelle. Lorsque je lance le démarrage, le processus se lance et se termine par un échec.
    Merci!

    • Philippe Lima dit :

      Merci.

      Votre problème vient surement de l’activation du contrôle d’admission « admission control HA » au niveau du cluster. Cette fonction permet de s’assurer que suffisamment de ressources sont disponibles pour permettre la protection par HA et s’assurer que les réservations de ressources pour les VM sont respectées. Vous avez peut être trop de VM sur votre infra pour satisfaire votre politique de HA.

      Le admission control du HA impose certaines contraintes comme la mise sous tension d’une VM ou la migration d’une VM entre hôte si les politiques de HA ne sont pas respectées.

      Pour le désactiver et permettre aux VM de démarrer sans respect des contraintes HA, il suffit de cocher la case « disable – power on VM that violate availability constraints » dans la configuration HA.
      Cependant, sans ce contrôle, il est impossible de garantir que toutes les VM puissent être redémarrés par HA après la panne d’un hôte ESXi. (Il est déconseillé de le désactiver mais vous pouvez avoir besoin de le faire temporairement pour certaines actions).

  2. Fadiga Abdoulaye aziz dit :

    Un article bien rédigé et très intéressant.

    Merci  beaucoup

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*