L’initiative pourrait rester valable si elle n’était pas gavée de gros morceaux de bullshit comme ce magnifique tableau comparatif :

Notre bullshit-o-meter, déjà dans le rouge, a totalement grillé sur la séquence comparative Core Parking vs DPM (extrait ci-dessus). Notre brave Symon (“Microsoft Technical Evangelist” en chemise bleu) semble persuadé qu’un serveur allumé consomme autant qu’un serveur éteint (où l’inverse). Et pourtant :

The Core Parking feature allows Windows Server 2008 R2 to consolidate processing onto the fewest number of possible processor cores, and suspends inactive processor cores

Même si le CPU représente une part non négligeable de la consommation d’un serveur, il n’est question en moyenne que d’1/4 à 1/3 de la consommation totale. Mais quelque chose nous dit que M$ a fini par s’en apercevoir, ils n’ont juste pas encore prévenu Symon. Néanmoins, pour pouvoir consolider au maximum il faut un peu mieux que Dynamic Memory…

Démonstration avec un cluster, hébergeant 66 VM (W2K3 – 2Go), composé de 12 serveurs bi Xeon 5345 + 8Go de RAM sous ESXi 4.1 build 348481. Les VM de ce cluster devant etre dispo à 100% entre 8h et 19h, Distributed Power Management est programmé dans vCenter pour s’activer à 20h et se désactiver à 7h (hors WE). Résultat, 9 serveurs sur 12 OFF (pour Symon, ça veut plus d’électricité du tout) en heures creuses, c’est à dire 60% du temps dans notre cas :

Evidemment, impossible d’atteindre ce taux de consolidation hallucinant de 600% sans l’aide de TPS, Ballooning, Memory compression et Hypervisor swapping :

Ça, c’est du GreenIT et c’est dispo depuis 2008 !

(1-contention rapide / 2-contention lente)

De plus, comme indiqué dans le Resource Management Guide, plus la VM est riche en vCPU et en vRAM, plus elle imposera un overhead important au VMkernel. Cet overhead est réservé et donc totalement “perdu”. Il ne sera pas non plus soumis aux differents mécanismes de récupération d’ESX (Transparent Page Sharing > Memory Idle Tax/Ballooning > Memory Compression > Hypervisor Swapping).

On ne parle que d’une centaine de Mo pour une VM avec 1 vCPU et 1Go de vRAM, mais un petit one-liner de PowerCLI nous permet de savoir de combien on parle pour une infra de plus de 1200 VM :

Write-Host -ForegroundColor Red -BackgroundColor Yellow $([math]::round((Get-View -ViewType virtualmachine -Property Summary,Runtime|?{$_.runtime.PowerState -eq "poweredOn"}|select -ExpandProperty Summary|select -ExpandProperty Runtime|Measure-Object -Sum -Property MemoryOverhead).sum/1GB,1)) / $([math]::round((Get-View -ViewType virtualmachine -Property Summary,Runtime|?{$_.runtime.PowerState -eq "poweredOn"}|select -ExpandProperty Summary|select -ExpandProperty Config|Measure-Object -Sum -Property MemorySizeMB).sum/1KB,1))

Presque 220Go d’overhead sur environ 3,8To de vRAM attribué, soit près de 6% !

Il est donc nettement plus judicieux de bien determiner la taille de vRAM nécéssaire au “Guest OS“ et de tailler au plus juste plutot que mettre une valeur trop large au risque de voir la VM en souffrir plutot que d’en bénéficier (idem pour les vCPU d’ailleurs).

A lire tous les soirs après s’etre brossé les dents : Understanding Memory Resource Management in VMware ESX 4.1

Consultez aussi la liste des Advanced Memory Attributes pour avoir une idée des possibilités de tuning.