Si un hôte échoue et que ses machines virtuelles doivent être redémarrées, vous pouvez contrôler l'ordre dans lequel cela se fait avec le paramètre de priorité de redémarrage des machines virtuelles. De même, vous pouvez configurer la réponse de vSphere HA lorsque des hôtes perdent la connectivité au réseau de gestion à d'autres hôtes en utilisant les paramètres de réponse d'isolation. D'autres facteurs sont également pris en compte lorsque vSphere HA redémarre une machine virtuelle après un échec.

Les paramètres suivants s'appliquent à toutes les machines virtuelles du cluster en cas d'échec ou d'isolation d'un hôte. Vous pouvez configurer des exceptions pour des machines virtuelles spécifiques. Reportez-vous à Personnaliser une machine virtuelle secondaire.

Priorité de redémarrage des VM

La priorité de redémarrage des machines virtuelles détermine l'ordre relatif dans lequel des ressources sont attribuées aux machines virtuelles en cas d'échec d'un hôte. Les machines virtuelles de ce type sont attribuées aux hôtes avec une capacité non réservée. Celles ayant la priorité la plus élevée sont attribuées en premier, puis les machines virtuelles ayant une priorité inférieure, et ainsi de suite jusqu'à ce que toutes les machines virtuelles aient été placées ou qu'aucune capacité de cluster ne soit disponible pour satisfaire aux réservations ou à la mémoire de temps système des machines virtuelles. Ensuite, un hôte redémarre les machines virtuelles qui lui sont attribuées par ordre de priorité. En cas de ressources insuffisantes, vSphere HA attend de disposer de capacité non réservée supplémentaire, par exemple, grâce au retour en ligne d'un hôte, puis tente à nouveau de placer ces machines virtuelles. Pour empêcher que cette situation se présente, configurez le contrôle d'admission de vSphere HA afin qu'il réserve davantage de ressources en cas d'échec. Le contrôle d'admission vous permet de contrôler la capacité de cluster réservée par les machines virtuelles qui est indisponible afin de satisfaire aux réservations et à la mémoire de temps système des machines virtuelles.

Les valeurs de ce paramètre sont Désactivée, Basse, Moyenne (par défaut) et Haute. Le paramètre Désactivée est ignoré par la fonctionnalité Surveillance de VM et d'application de vSphere HA car celle-ci protège les machines virtuelles contre les échecs au niveau du système d'exploitation et non contre les échecs des machines virtuelles. Lorsqu'un échec se produit au niveau du système d'exploitation, vSphere HA redémarre le système d'exploitation et la machine virtuelle est laissée en fonctionnement sur le même hôte. Vous pouvez modifier ce paramètre pour des machines virtuelles individuelles.

Remarque :

La réinitialisation d'une machine virtuelle provoque un redémarrage du système d'exploitation invité mais ne place pas la machine virtuelle en cycle d'alimentation.

Les paramètres de priorité du redémarrage des machines virtuelles varient en fonction des besoins de l'utilisateur. Attribuez une priorité plus élevée de redémarrage aux machines virtuelles qui fournissent les services les plus importants.

Par exemple, dans le cas d'une application multitâche, vous pouvez classer les attributions en fonction des fonctionnalités hébergées sur les machines virtuelles.

  • Haute. Serveurs de base de données qui fournissent des données aux applications.

  • Moyenne. Serveurs d'application qui exploitent les données de la base de données et fournissent des résultats sur des pages web.

  • Basse. Serveurs Web qui reçoivent des demandes d'utilisateurs, transmettent des requêtes à des serveurs d'application et transmettent les résultats aux utilisateurs.

Si un hôte échoue, vSphere HA tente d'inscrire sur un hôte actif les machines virtuelles concernées qui étaient sous tension et qui disposent d'un paramètre de priorité de redémarrage défini sur Désactivée ou qui étaient hors tension.

Réponse d'isolation de l'hôte

La réaction à l'isolation d'un hôte détermine les événements survenant lorsqu'un hôte d'un cluster vSphere HA perd ses connexions au réseau de gestion mais continue à s'exécuter. Vous pouvez utiliser la réaction à l'isolation afin que vSphere HA mette hors tension les machines virtuelles en cours d'exécution sur un hôte isolé et les redémarre sur un hôte non isolé. Les réponses à l'isolement d'un hôte exigent que l'État de surveillance de l'hôte soit activé. Si l'état de surveillance de l'hôte est désactivé, les réponses à l'isolement d'un hôte sont également suspendues. Un hôte détermine qu'il est isolé lorsqu'il est incapable de communiquer avec les agents en cours d'exécution sur les autres hôtes et d'envoyer un ping à ses adresses d'isolation. L'hôte exécute ensuite sa réaction à l'isolation. Les réactions sont Mettre hors tension et redémarrer les VM ou Arrêter et redémarrer les machines virtuelles. Vous pouvez personnaliser cette propriété pour des machines virtuelles individuelles.

Remarque :

Si le paramètre de priorité de redémarrage d'une machine virtuelle est défini sur Désactivée, aucune réaction à l'isolation de l'hôte n'est fournie.

Pour utiliser le paramètre Arrêter et redémarrer les machines virtuelles, vous devez installer VMware Tools dans le système d'exploitation invité de la machine virtuelle. L'arrêt de la machine virtuelle offre l'avantage de préserver son état. L'arrêt est préférable à la mise hors tension de la machine virtuelle qui ne prend pas en compte pas les dernières modifications apportées aux disques ni ne valide les transactions. Le basculement des machines virtuelles qui sont en train de s'arrêter est plus long car la fermeture doit aussi être effectuée. Les machines virtuelles qui n'ont pas été arrêtées au bout de 300 secondes ou du délai défini par l'option avancée das.isolationshutdowntimeout sont mises hors tension.

Lorsque vous avez créé un cluster vSphere HA, vous pouvez changer les paramètres par défaut du cluster relatifs à la Priorité de redémarrage et à la Réponse à l'isolement de machines virtuelles spécifiques. Ces remplacements sont utiles pour les machines virtuelles qui sont utilisées pour des tâches spéciales. Par exemple, les machines virtuelles qui fournissent des services d'infrastructure, comme DNS ou DHCP, doivent éventuellement être mises sous tension avant d'autres machines virtuelles du cluster.

Une condition de split-brain peut se produire sur une machine virtuelle lorsqu'un hôte se retrouve isolé ou partitionné depuis un hôte principal qui ne peut pas communiquer avec lui à l'aide des banques de données des signaux de pulsation. Dans une telle situation, l'hôte principal n'est pas en mesure de déterminer si l'hôte est actif et le déclare inactif. L'hôte principal fait ensuite une tentative pour redémarrer les machines virtuelles qui s'exécutent sur l'hôte isolé ou partitionné. Cette tentative réussit si les machines virtuelles continuent de s'exécuter sur l'hôte isolé ou partitionné et celui-ci perd l'accès aux banques de données des machines virtuelles quand il s'est retrouvé isolé ou partitionné. Il existe alors une condition de split-brain, car la machine virtuelle se retrouve avec deux instances. Toutefois, seule une de ces instances est en mesure de lire ou d'écrire sur les disques virtuels de la machine virtuelle. VM Component Protection peut vous aider à empêcher cette condition de split-brain. Lorsque vous activez VMCP avec le paramètre intensif, il contrôle l'accessibilité de la banque de données sur les machines virtuelles sous tension et arrête celles qui perdent l'accès à leurs banques de données.

Pour résoudre ce problème, ESXi génère une question sur la machine virtuelle qui a perdu les verrouillages disque pour le moment où l'hôte quitte son état d'isolation et est dans l'impossibilité obtenir de nouveau les verrouillages disque. vSphere HA répond automatiquement à cette question ce qui permet à l'instance de la machine virtuelle qui a perdu les verrouillages disque de se mettre hors tension, laissant uniquement l'instance qui dispose des verrouillages disque.

Facteurs pris en charge pour le redémarrage de la machine virtuelle

Après un échec, l'hôte principal du cluster fait une tentative de redémarrage des machines virtuelles concernées en identifiant un hôte susceptible de les mettre sous tension. Lors de la sélection de cet hôte, l'hôte principal tient compte d'un certain nombre de facteurs.

Accessibilité des fichiers

Avant de pouvoir redémarrer une machine virtuelle, ses fichiers doivent être accessibles depuis l'un des hôtes actif du cluster avec lequel l'hôte principal peut communiquer via le réseau.

Machine virtuelle et compatibilité de l'hôte

S'il existe des hôtes accessibles, la machine virtuelle doit être compatible avec au moins l'un d'entre eux. La compatibilité définie pour une machine virtuelle comprend l'effet de l'une des règles d'affinité machine virtuelle/hôte. Par exemple, si une règle permet à une machine virtuelle de s'exécuter sur deux hôtes, elle est prise en compte pour le placement sur ces deux hôtes.

Réservations de ressources

Parmi les hôtes sur lesquels la machine virtuelle peut s'exécuter, au moins un doit disposer d'une capacité non réservée suffisante pour satisfaire aux besoins de la mémoire de temps système de la machine virtuelle et aux réservations de ressources. Quatre types de réservations sont prises en compte : CPU, mémoire, vNIC (carte réseau virtuelle) et Virtual Flash. De plus, un nombre de ports réseau suffisant doit être disponible pour mettre sous tension la machine virtuelle.

Limites d'hôtes

En plus des réservations de ressources, une machine virtuelle ne peut être placée sur un hôte que si cela ne lui fait pas dépasser le nombre maximal de machines virtuelles autorisées ou de vCPU utilisés.

Contraintes de la fonctionnalité

Si l'option avancée qui a été définie nécessite que vSphere HA fasse respecter les règles d'affinité machine virtuelle/machine virtuelle, vSphere HA n'enfreint pas cette règle. De plus, vSphere HA n'enfreint pas les limites configurée pour chaque hôte pour les machines virtuelles Fault Tolerance.

Si aucun hôte ne répond aux considérations précédentes, l'hôte principal émet un événement indiquant qu'il ne dispose pas des ressources suffisantes pour que vSphere HA démarre la machine virtuelle et ressaiera une fois les conditions du cluster améliorées. Par exemple, si la machine virtuelle n'est pas accessible, l'hôte principal réessaie après une modification de l'accessibilité des fichiers.

Limites des tentatives de redémarrage de la machine virtuelle

Si l'agent principal de vSphere HA tente de redémarrer une machine virtuelle, ce qui implique de l'inscrire et de la mettre sous tension, et échoue, ce redémarrage est ressayé après un certain délai. vSphere HA tente de redémarrer la machine virtuelle un nombre maximal de fois (6 par défaut), mais tous les échecs de redémarrage ne sont pas pris en compte dans ce maximum.

Par exemple, la raison la plus probable qu'une tentative de redémarrage échoue est que soit la machine virtuelle continue de s'exécuter sur un autre hôte, soit que vSphere HA a essayé de redémarrer la machine virtuelle trop tôt après que celle-ci ait échoué. Dans ce cas, l'agent principal retarde la nouvelle tentative de deux fois le délai d'attente imposé après la dernière tentative, avec un délai minimal de 1 minute et un délai maximal de 30 minutes. Par conséquent, si le délai est défini sur 1 minute, la tentative initiale est à T=0, les tentatives supplémentaires seront effectuées à T=1 (1 minute), T=3 (3 minutes), T=7 (7 minutes), T=15 (15 minutes) et T=30 (30 minutes). Chacune de ces tentatives est décomptée du nombre maximal et seules six tentatives sont effectuées par défaut.

Les autres échecs de tentatives entraînent des tentatives qui sont comptabilisées, mais avec un intervalle de temps différent. Par exemple, l'hôte sélectionné pour redémarrer la machine virtuelle perd l'accès à l'une des banques de données de la machine virtuelle après que l'agent principal ait fait son choix. Une tentative est alors effectuée après un délai par défaut de 2 minutes. Cette tentative est décomptée de la limite.

Enfin, certaines tentatives ne sont pas comptabilisées. Par exemple, si l'hôte sur lequel la machine virtuelle devait être redémarrée échoue avant que l'agent principal n'émette la demande de redémarrage, une nouvelle tentative est effectuée au bout de 2 minutes, mais cet échec n'est pas soustrait au nombre maximal de tentatives.

Notifications de redémarrage de la machine virtuelle

vSphere HA génère un événement de cluster lorsqu'une opération de basculement est en cours pour les machines virtuelles du cluster. L'événement affiche également un problème de configuration dans l'onglet Résumé du cluster qui indique le nombre de machines virtuelles en cours de redémarrage. Il existe quatre catégories distinctes de machines virtuelles de ce type.

  • Les machines virtuelles en cours de placement : vSphere HA tente actuellement de redémarrer ces machines virtuelles

  • Les machines virtuelles en attente d'une tentative : une tentative de redémarrage a échoué et vSphere HA attend actuellement qu'un délai arrive à expiration avant de réessayer.

  • Les machines virtuelles nécessitant des ressources supplémentaires : les ressources disponibles sont insuffisantes pour redémarrer ces machines virtuelles. vSphere HA réessaiera une fois que des ressources supplémentaires deviendront disponibles, par exemple si un hôte revient en ligne.

  • Machines virtuelles Virtual SAN inaccessibles : vSphere HA ne peut pas redémarrer ces machines virtuelles Virtual SAN, car elles ne sont pas accessibles. Il réessaiera dès qu'il y aura un changement d'accessibilité.

Ces nombres de machines virtuelles sont mis à jour de manière dynamique à chaque fois qu'une modification est observée dans le nombre de machines virtuelles pour lesquelles une opération de redémarrage est en cours. Le problème de configuration est effacé une fois que vSphere HA a redémarré toutes les machines virtuelles ou a arrêté d'essayer.

Dans vSphere 5.5 ou version antérieure, un événement par machine virtuelle est déclenché en cas d'échec de la tentative de redémarrage de la machine virtuelle. Cet événement est désactivé par défaut dans vSphere 6.x et peut être activé en définissant l'option avancée de vSphere HA das.config.fdm.reportfailoverfailevent sur 1.