VMware HA datastore proxy

Pendant le setupage du premier super stretched cluster maison en production avec notre cher confrère vmdude.fr, ce dernier a émis une judicieuse remarque sur la possibilité que notre design rende impossible le fonctionnement de Datastore Heartbeat:

When the master host in a vSphere HA cluster can not communicate with a slave host over the management network, the master host uses datastore heartbeating to determine whether the slave host has failed, is in a network partition, or is network isolated.

Mais qu’en est il lorsque le master n’a pas accès au datastore en question ? C’est après une bonne séance de tests, en isolant volontairement un ESX du réseau de management, avec décorticage de logs que nous avons trouvé la réponse:

17:31:25.502Z [...] Marking slave host-145 as unreachable
17:31:25.502Z [...] [ClusterDatastore::RemoveMountHost] No longer proxying through host-145 for /vmfs/volumes/404021e9-b4550ea3
17:31:25.502Z [...] Releasing datastore /vmfs/volumes/404021e9-b4550ea3
17:31:25.502Z [...] [InventoryManagerImpl::NotifyDatastoreUnlockedLocally] Invoked for datastore (/vmfs/volumes/404021e9-b4550ea3).
[...]
[...]
17:31:26.513Z [...] [ClusterDatastore::CheckMasterDatastore] Acquiring remote datastore /vmfs/volumes/404021e9-b4550ea3
17:31:26.513Z [...] AcquireViaSlave: Selected slave host-240
17:31:26.513Z [...] AcquireViaSlave: Acquiring from slave host-240
[...]
[...]
17:31:26.614Z [...] [ClusterManagerImpl::ProcessAcquireDatastoreReply] path /vmfs/volumes/404021e9-b4550ea3
[...]
[...]
17:31:30.549Z [...] [ClusterSlave::UnreachableCheck] Waited 5 seconds for icmp ping reply for host host-145
17:31:30.549Z [...] [ClusterSlave::UnreachableCheck] Checking for Partition
[...]
[...]
17:32:08.803Z [...] [ClusterDatastore::ProcessReadHBReply] Failure for /vmfs/volumes/404021e9-b4550ea3 from slave host-240
17:32:08.803Z [...] [ClusterDatastore::UpdateSlaveHeartbeats] (NFS) host-145 @ host-145 is ALIVE

Notre interprétation est que l’ESX que nous avons volontairement isolé (host-145) avait été désigné “proxy” car il avait accès à des datastores que le master ne pouvait pas atteindre. Lorsqu’il n’a plus été joignable, un autre slave (host-240) à été choisi pour remonter les informations de datastore heartbeating au master pouvant ainsi déterminer si le slave (host-145) était mort ou isolé . Grace à Duncan Epping, nous en avons eu la confirmation :

The proxying is designed for a situation where the master cannot see a specific datastore, but slaves can. In that case the proxy service is used by the master to allow certain actions to take place.

Conclusion, même dans un cluster où la moitié des ESX ne sont pas connectés aux datastores de l’autre moitié, FDM est capable d’utiliser un (ou plusieurs ?) slave en tant que proxy pour assurer les fonctions du master.

Tags: datastore heartbeat, FDM, HA, hidden feature

Comments (0) | December 3rd, 2013