Je l’ai déjà indiqué dans un précédent article, je ne suis pas un spécialiste du matériel Dell et le client n’en dispose que pour nos clusters Nutanix.

Voici le script que j’utilise pour configurer les noeuds en mode « Maximum Performance ».

Si vous débutez comme moi sur le sujet, je vous conseille mon précédent article qui décrit en détail l’installation de l’outil de configuration distant RACADM (Remote Access Controller Admin).

#Chargement Cmdlet Nutanix
asnp nutanix*
 
#Choix du cluster
$Cluster = Read-host "IP address of the Nutanix cluster to update"

$iDracPwd = Read-host "iDrac root Password"
 
Connect-NTNXCluster $Cluster -AcceptInvalidSSLCerts -UserName:Admin -ForcedConnection   


Get-NTNXHost | select name,ipmiaddress,managementservername
 
$IPMIs = (Get-NTNXHost).ipmiaddress
 
foreach ($IPMI in $IPMIS) {
 
write-host "Modification des parametres BIOS du noeud $IPMI"
 
racadm.exe -r "$IPMI" -u root -p $iDracPwd set bios.SysProfileSettings.SysProfile Custom
racadm.exe -r "$IPMI" -u root -p $iDracPwd set bios.SysProfileSettings.ProcPwrPerf MaxPerf
racadm.exe -r "$IPMI" -u root -p $iDracPwd jobqueue create BIOS.setup.1-1
 
Cette commande permet d'avoir un retour sur la configuration du parametre	
#racadm.exe -r "$IPMI" -u root -p $iDracPwd get bios.SysProfileSettings.ProcPwrPerf
 
}
 
exit

Ce script ne contient pas la phase de redémarrage nécessaire à la prise en compte des paramètres, comme il s’agit de clusters Nutanix.

Nous constations depuis quelque temps des alertes contentions CPU sur vROps que nous n’expliquions pas. J’avais fait le tour de ce que cette alerte représentait pour moi : CPU Ready – Co-Stop – I/O Wait – Swap Wait, mais rien de m’avait sauté aux yeux.

contention_cpu

La semaine dernière, je passais en revues nos configurations pour en ressortir les incohérences (ne pas avoir Enterprise Plus n’est pas une excuse pour ne pas vérifier la conformité). Plusieurs hôtes de récupération avaient été ajoutés dans différents clusters, mais leurs configurations étaient légèrement différentes des autres nœuds au niveau de la gestion d’alimentation :

power_management

Je tenais enfin mon explication, et effectivement toutes les VMs qui remontaient de la contention étaient hébergées sur des hôtes qui n’étaient pas configurés en .

Une très bonne définition donnée ici par Valentin du support VMware dans une discussion sur le forum VMware à propos du CPU Latency  :

vmwaresupport

le « Dynamic voltage frequency scaling » est clairement la cause dans mon cas.

Un autre très bon article sur le sujet : http://port5480.blogspot.fr/2015/10/cpu-contention-high-in-vrops.html