Oh my DRS Goodness!

Ceux d’entre nous qui faisons de l’administration d’infrastructure vSphere au quotidien ont au moins une fois entendu la fameuse phrase “Mais pourquoi DRS ne fait rien alors que le cluster n’est pas équilibré ?!“. Le sujet à déjà largement été traité par des références dans le domaine comme l’est Frank Denneman mais nous allons reformuler la raison une bonne fois pour toute et en français : DRS ne déclenchera un vmotion que si le gain du déplacement est supérieur à son coût.

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

Tags: Distributed Resource Scheduler, DRS, overcommit

Comments (2) | February 21st, 2014