Evidemment il y a un algorithme complexe, du paramétrage et des seuils variables pour rendre le mécanisme suffisamment intelligent mais dans le cas d’un cluster pas ou peu overcommité (cpu et/ou ram uniquement), le déséquilibre est une situation “normale” puisque le coût d’un vmotion sera presque toujours supérieur a son bénéfice. DRS estime le gain à partir de la demande des vm et n’a de raison d’agir que si elles ne peuvent pas obtenir les ressources demandées. Le bon nivellement des VM dans le cluster n’est absolument pas pris en compte. De plus, DRS fait une projection de ce que la vm pourrait consommer dans un futur proche en fonction des statistiques passées afin de ne pas réagir trop tard.

Néanmoins, dans certains cas il peut s’avérer nécessaire de forcer DRS à “secouer” un peu le cluster pour répartir les vm. Après une opération de maintenance ou de façon proactive (moins de vm par host=moins de conséquences en cas de crash) ou encore pour niveler les I/O disque/réseau pas (encore) pris en compte par DRS.

Nous nous sommes justement retrouvés dans cette situation suite à l’ajout de plusieurs host dans un cluster 5.0 U1 et face à l’immobilisme de DRS, nous nous sommes souvenus d’un post détaillé de Frank à ce sujet faisant référence à une kb vmware.

This issue may occur in an environment with a large number of relatively low demand virtual machines

Il s’agit de modifier *temporairement* les paramètres MinGoodness et CostBenefit pour que DRS déclenche un vmotion à la moindre occasion sans en considérer le coût. le résultat est immédiat :

Depuis vSphere 5.1, l’algorithme de DRS à été modifié pour palier à des situations similaires (vSphere 4.1 U3 et vSphere 5.0 U2 intègre aussi la modification) mais il est toujours possible de forcer si besoin avec d’autres paramètres :

Starting with this release, DRS algorithm is improved to better balance the load in a DRS cluster. If you notice that the cluster is still not balanced with the default settings, you can configure the advanced DRS options with the following values and run DRS to further improve the load balancing capability of the DRS cluster:

SevereImbalanceDropCostBenefit 1
FixSevereImbalanceOnly 0

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 !

Disponible uniquement sur les resource pools dans le client legacy, cette vue synthétise l’utilisation “near real-time” cpu/ram du cluster des 5 dernières minutes (quickstats). Il suffit de créer un resource pool à la racine de votre cluster (sans reservations ni limites, les shares n’ont pas d’importances ici) pour avoir une visibilité comparable des ressources du cluster :

La vue “Guest Memory” se paye même le luxe d’être un peu plus détaillée graphiquement alors que la vue “Host Memory” est faussée par la mémoire allouée aux VM.

get-vm|?{$_.PowerState -eq "PoweredOn"}|%{move-vm -vm $_ -destination (get-random @((($vmhost = $_.Vmhost).Parent|get-view).host|%{get-view $_}|?{$_.Runtime.ConnectionState -eq "connected" -and !$_.Runtime.InMaintenanceMode -and $_.Runtime.StandbyMode -eq "none" -and $_.name -cne $vmhost.name})).name -whatif}

Pour être un peu plus précis, ce script va faire un vmotion sur un des autres ESX disponibles du cluster parent. OneLiner oblige, ce script ne tient pas compte des vm qui seraient déplacées par DRS avant son passage. Il est par contre nécessaire d’avoir un minimum de “mou” sur le cluster en question pour éviter une vilaine contention.

Dans l’état, le script vous affichera la liste des vmotion, il suffit d’ôter le “-whatif” et relancer pour agiter la pulpe