Premier constat, le temps de compute des valeurs moyennes de cpu et ram est très important et c’est évidement proportionnel au nombre de nœuds. Pour optimiser ce script, nous nous somme rabattu sur les quickstats du resource pool “racine” du cluster (aka “resources”). Ces valeurs étant basé sur les 5 dernières minutes d’activité (et non sur les 24 dernières heures comme le script original), il faut l’exécuter au moment de la journée où l’activité du cluster est la plus importante pour avoir des valeurs vraiment représentatives du workload. Le gros avantage de ces valeurs est qu’il n’est pas nécessaire de faire une requête dans les statistiques, elles sont pré-computées et disponibles sous forme de propriétés, on passe donc d’une exécution pouvant aller jusqu’à plusieurs minutes à 2 secondes par cluster. Comme dirait Mozinor, “tu peux pas test”.

Deuxième constat, le mode “slot size” d’admition control ne tiens pas compte de l’overcommit. Duncan et Frank l’explique en détail dans leur bouquin mais voici un exemple encore plus parlant :

3 hosts sur 12 (25%) en mode “slot size” contre 67% en mode “resources”. Dans ce dernier mode, HA tiens compte de la consommation réelle du cluster pour déterminer ce qu’il reste.

With the resources failover policy in place, vSphere HA uses the following calculations to control virtual machine migration in the cluster
1. Calculate the total resource requirements for all powered-on virtual machines in the cluster.
[...]

Il est donc clair que sur des gros cluster avec de l’overcommit, le mode “slot size” est totalement inutilisable.

En attendant de déguster la dinde farcie aux marrons de tante Yolande, voici le oneliner powershell à deguster en amuse-bouche :

foreach ($cluster in (Get-View -ViewType ClusterComputeResource|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster|?{$_.host}|select @{n="mem";e={(($_|%{(Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.HostMemoryUsage/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="cpu";e={(($_|%{((Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.OverallCpuUsage)/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="vcpu";e={(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState,Config.Hardware.NumCpu|?{$_.Runtime.PowerState -eq "poweredOn"}|Select @{n="vcpu";e={$_.Config.Hardware.NumCPU}}|Measure-Object -Average -Property vcpu).average}}|measure -average -property mem,cpu,vcpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum -and ($_|measure -Sum).sum -gt "64") {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()}))})}),$true)}}}

Joyeux Noël à tous !

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.

Vous avez probablement remarqué la ressemblance frappante avec les schémas de Frank Denneman et c’est tout à fait voulu. Frank a en effet démontré depuis longtemps l’intérêt de ces schémas ultra épurés avec le moins de texte possible et des couleurs très soft. D’ailleurs, c’est nettement plus dur à faire qu’il n’y parait…

Nous avons également produit une version pdf sans commentaires.

Indicates that you want to stop the specified virtual machines by terminating their processes running on the ESX. You can use this parameter to stop a virtual machine that is not responding and cannot be stopped or restarted in other ways.

Cela ressemble fortement à un kill des process vmx dans un shell, via esxtop ou esxcli mais nécessiterai d’être connecté à l’ESXi plutôt qu’au vcenter :

To use the Kill parameter, you need to have a direct connection to ESX 4.1 or later.

Mais une fois de plus le monkey test à payé, nous testons la commande en étant connecté au vcenter et ça marche. la vm est littéralement killée sans aucune tache apparente dans le vcenter ni sur l’ESX et HA la restart :

Nous avons également vérifié avec Wireshark qu’aucune communication n’avait lieu entre le client PowerCLI et l’ESXi.