lundi 30 novembre 2015

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



Qu’est-ce que VMware High Availability ?


VMware HA est la fonctionnalité avancé de VMware qui permet de faire redémarrer les machines virtuelles (VM), après un désastre, sur les hôtes ESXi survivants.

Le déclenchement de HA s’accompagne inévitablement d’une interruption de service.

HA s’active et se configure au niveau du cluster. Pour rappel, un cluster VMware est un regroupement logique d’hôtes ESXi dont les ressources CPU et RAM sont mises en commun.

Il est possible de configurer jusqu’à 32 hôtes ESXi dans un seul et même cluster.



Résumé fonctionnel du comportement de HA :
Après le crash d’un hôte ESXi, les membres du cluster s’aperçoivent de l’absence de heartbeat réseau de l’hôte tombé. Ils vérifient alors le heartbeat de stockage de cet hôte.

Si le heartbeat est absent, les VMs qui étaient hébergées par l’hôte qui est tombé seront redémarrées sur les hôtes survivants du cluster. A contrario, si le heartbeat est présent, HA ne sera pas déclenché, et aucune action de redémarrage de VM ne sera entreprise.



Hôtes Maîtres et Esclaves

À l’activation de HA, les hôtes ESXi membres du cluster élisent un hôte « Maître ». Les autres membres du cluster seront tous « esclaves ».

L’hôte désigné « maître » est celui qui a le plus de datastores connectés. En cas d’égalité, c’est celui qui le MOID (Managed Object ID)  le plus élevé qui l’emporte. Après l’élection, chaque Esclave établi une connexion point à point (TCP/UDP 8182) sécurisés SSL avec le Maître.

Après son élection le Maître va essayer de prendre possession des datastores auxquels il est directement connecté et ceux qui sont connectés à ces Esclaves. Pour cela, il créé un fichier appelé « protectedlist » qui sera copié sur l’ensemble des datastores dont il a pris la possession. Ce fichier « protectedlist » contient un inventaire de toutes les VMs protégées par HA (VM qui seront redémarrées) ainsi que des informations sur les réservations de CPU et l’overhead de RAM.

Tant que le Maître est fonctionnel, il maintient un lock sur le fichier « protectedlist ».

Si il crash, le lock expire et le nouveau Maître relockera le fichier sur les datastores qui lui seront accessibles.

En cas d’isolation, le Maître libère le lock, et le nouveau Maître le relockera afin de prendre connaissance des VMs à protéger. Si le Maître devait crasher au moment où il est considéré comme isolé, les VMs qu’il héberge seront redémarrées dès qu’un nouveau Maître aura été élu et qu’il aura posé son lock sur le fichier.

Rôle de l’hôte Maître

 

L’hôte Maître est en charge de la surveillance de l’état des hôtes  Esclave du cluster et doit reporter leur état au serveur vCenter.

Il est en plus évidement en charge du placement initial, puis du redémarrage des VMs en cas de crash d’un hôte membre du cluster.

Rôle de l’hôte Esclave

 

L’hôte Esclave est en charge de la surveillance des VMs qu’il héberge et doit informer le Maître de tout changement d’état de ses VMs.

Il surveille également la présence du Maître, pour le cas échéant, initier et participer à l’élection d’un nouveau Maître.

Son dernier rôle consiste à envoyer son heartbeat au Maître pour lui indiquer son propre état.
Les communications se font en point-à-point, pas en multicast.



Les fichiers de configuration

 

En plus du fichier « protectedlist »  qui est maintenu exclusivement par l’hôte Maître,  nous rencontrons les fichiers « poweron ».

Ces fichiers sont créés et maintenus aussi bien par les hôtes Maîtres et Esclaves. Chaque hôte en créé un. Ce fichier contient le nom des VMs qui sont allumées.

À chaque changement d’état d’une VM, le fichier est mis à jour.

Mais ce fichier est également utilisé par l’hôte Esclave pour informer le Maître qu’il est isolé : si l’Esclave est isolé du réseau de management, il met un « 1 » en première ligne du fichier, et non plus un « 0 », zéro qui indique qu’il n’est pas isolé

-       0 : pas isolé (valeur par défaut)

-       1 : isolé du réseau de management

Seront également créés les fichiers suivants en local sur les hôtes:

-       Clusterconfig : fichier non éditable qui contient les détails de configuration du cluster

-       Compatlist : fichier non éditable qui contient la patrice de compatibilité des VM protégées et des hôtes du cluster

-       fdm.cfg : ce fichier contient des informations sur la configuration de l'agent FDM (alertes, logs, répertoire de travail du FDM)

-       hostlist : liste des hôtes du cluster (hostname, @ IP, @ MAC, Datastore HB)
 

0 commentaires :

Enregistrer un commentaire