mercredi 16 décembre 2015

[HA Deepdive - PART 2 -] Fonctionnement de VMware HA en environnement vSphere 5.x


Suite de la PART 1



Heartbeat réseau

 

Tous les Esclaves envoient leur heartbeat vers le Maitre du cluster uniquement et le Maitre envoie son heartbeat vers l’ensemble des Esclaves.

 Heartbeat de stockage


 

 Dès lors que l’Esclave ne parvient plus à envoyer son heartbeat au Maître, il va aller modifier le fichier « poweron ». Le Maître ne parvenant plus à envoyer son heartbeat à l’Esclave, il va aller vérifier la valeur positionnée dans le fichier « poweron » : si la valeur positionnée est « 1 », il va aller vérifier le Heartbeat de stockage.

Toutes les 5 secondes, les membres du cluster mettent à jour le fichier « host-XX-hb » (ce fichier est stocké avec le fichier « protectedlist » sur le datastore servant au heartbeat).
Cela permet au Maître de vérifier si un Esclave, dont le HB réseau ne lui parvient plus, est encore en vie ou pas. Et le cas échéant de déclencher le redémarrage des VMs.


Cycle de déclaration d’un hôte HS

 

Perte d’un Esclave

 

T0 – Perte de l’hôte Esclave
T3s – Le Maître commence le monitoring des datastores heartbeat pendant 15 secondes
T10s – L’hôte est déclaré comme étant inaccessible, le Maître ping le réseau de management de l’Esclave pendant 5s
T15s – Si il n’y a pas de datastore heartbeat  de configuré, l’hôte est considéré comme HS
T18s – Si le datastore heartbeat est configuré, l’hôte est considéré comme HS




 

Perte d’un Maître

 

T0 – Perte de l’hôte Maître
T10s – Process d’élection du nouveau Maître
T25s – Le nouveau Maître élu lit le fichier « protedlist »
T35s – Le nouveau Maître redémarre les VMs protégées









Isolation et partition 

En cas d’incident réseau, 2 cas peuvent être rencontrés concernant l’isolement d’un ou plusieurs hôtes ESXi




Isolation

On parle d’isolation lorsque qu’un Esclave n’est plus accessible ni par son Maître, ni par les autres Esclaves. Il y a alors 2 cas de figures : soit l’Esclave est HS et HA va redémarrer les VM, soit il ne l’est pas et HA va appliquer ce qui a été configuré dans l’ « Isolation Response ».

Dans ce cas l’hôte a 3 actions possibles à appliquer aux VMs qu’il héberge : 
  •   Power off : toutes les VMs sont éteintes violemment. Aucune garantie n’est apportée quant à la consistance des données. Les VMs seront redémarrées par HA sur un autre hôte du cluster. 
  • Shut down : toutes les VMs sont éteintes « proprement » au travers des VMware Tools. Si elles ne sont pas éteintes au bout de 5 minutes, un « Power off » sera exécuté. Si les tools ne sont pas installées, le « Power off «  est exécuté immédiatement. Les VMs seront redémarrées par HA sur un autre hôte du cluster.
     
  • Leave powered on : l’état des VMs reste inchangé.


Ainsi, voici le cycle de décision d’isolation d’un hôte :

  • L’hôte Maitre ne parvient plus à communiquer avec l’Esclave et réciproquement. 
  •  L’Esclave va maintenant tenter de pinger sa gateway : il a besoin de savoir si c’est lui qui est isolé du réseau, ou si c’est juste le réseau de management entre lui et le Maître qui est HS (la gateway peut être remplacée par tout autre équipement réseau équipé d’une adresse IP: on peut configurer jusqu’à 10 adresses IP à pinger)
o   Si l’Esclave parvient à communiquer avec la Gateway (ou toute autre adresse configurée en tant qu’adresse d’isolation), => l’Esclave ne se considère pas comme isolé et aucune action sur les VMs n’est entreprise.
o   Si l’Esclave ne parvient pas à communiquer avec la Gateway (ou toute autre adresse configurée en tant qu’adresse d’isolation), => l’Esclave se considère comme isolé, va alors modifier le fichier « poweron » en remplaçant le 0 par le 1 et va vérifier ce qui a été configuré dans le « Host Isolation Response » et agit en conséquence (Power off / Shutdown / Leave poweron)


  • Pendant ce temps, le Maître vérifie l’état du HeartBeat de stockage de l’Esclave : dans notre cas, le HeartBeat de stockage est maintenu par l’Esclave. 
  • Le Maître (qui ne parvient plus à communiquer avec l’Esclave) vérifie également si le fichier « poweron » a été modifié ou non.
    •  S’il a été modifié, le Maître va comparer l’état des VMs de l’hôte qui ne répond plus avec le fichier « poweron » et fait redémarrer les VMs sur les autres membres du cluster si nécessaire (si « Host Isolation Response » était positionné sur « Power off » ou « Shutdown ».)
    • S’il n’a pas été modifié, le Maître ne fait rien car il en déduit qu’il ne s’agit que d’un problème de communication sur le réseau de management des hôtes.

0 commentaires :

Enregistrer un commentaire