En se creusant la tête pour diminuer le temps d’exécution d’un script (ou plutôt d’un OneLiner), on a trouvé une nouvelle piste pour l’optimisation de vos scripts, un peu dans le même esprit que le NoSQL, à savoir se baser sur une association clé-valeur plutôt qu’un schéma relationnel complexe.

Pour cela, on va utiliser des hashtables que l’on va peupler au début du script et utiliser par la suite. La structure HashTable est très utile lors des recherches, car son cout en accès est très faible, en moyenne O(1) en notation BigO (aka ça envoie) :

Pour l’exemple, on avait un OneLiner relativement simple qui consistait à lister les machines virtuelles et leur cluster qui n’étaient pas dans un ressource pool (donc qui avaient comme parent le ressource pool ‘Resources’, un peu plus d’explication à la page 43 du document de gestion de ressource de VMware) :

get-view -ViewType virtualmachine -Property ResourcePool, Name | ?{(Get-View $_.ResourcePool -Property Name).Name -eq "Resources"} | Select @{n="Cluster";e={(get-view (Get-View $_.ResourcePool -Property Parent).Parent -Property Name).Name}}, Name

Ce OneLiner filtre déjà tous les appels Get-View pour minimiser le temps d’exécution mais prenait quand même pas mal de temps…

On a donc essayé de voir ce qu’on pouvait faire avec les hashtables. On a donc créé plusieurs hashtables afin de ne plus avoir aucun appel Get-View à part bien sûr le premier récupérant les machines virtuelles).

$htabResourcePool = @{}
$htabResourcePoolParent = @{}
$htabCluster = @{}

Une fois déclarées, on a peuplé ces hashtables avec les valeurs dont on avait besoin (en utilisant le MoRef pour la clé) :

get-view -viewtype resourcepool -property name -Filter @{"name"="Resources"} | %{$htabResourcePool.Add($_.MoRef,$_.Name)}
get-view -viewtype resourcepool -property parent -Filter @{"name"="Resources"} | %{$htabResourcePoolParent.Add($_.MoRef,$_.Parent)}
get-view -viewtype clustercomputeresource -property name | %{$htabCluster.Add($_.MoRef,$_.Name)}

On pourra ensuite les utiliser directement dans le OneLiner en remplaçant les appels Get-View par des opérations de recherches dans les hashtables :

get-view -ViewType virtualmachine -Property ResourcePool, Name | ?{$htabResourcePool[$_.ResourcePool] -eq "Resources"} | Select @{n="Cluster";e={$htabCluster[$htabResourcePoolParent[$_.ResourcePool]]}}, Name

Pour l’instant, on est au même niveau de résultats que la méthode sans les hashtables, mais il faut se poser la question du temps d’exécution :p

Pour cela, on a créé un script qui va exécuter les 2 traitements :

1. la première méthode en récupérant via des appels Get-View
2. la deuxième méthode en peuplant des hashtables et en les utilisant par la suite (le remplissage des hashtables faisant intégralement parti du test pour être réellement dans le même périmètre).

Le script affichera le nombre de résultat des 2 méthodes (afin de s’assurer que le contenu retourné est bien identique) et le temps pris. Dans notre exemple, nous avions un peu moins de 2200 VMs sur la plateforme interrogée et les résultats parlent d’eux-mêmes :

Pour ne pas se mettre à dos hypervisor.fr qu’on entend crier d’ici « Toucher pas à mon OneLiner! », l’exemple choisi est effectivement très parlant car il y a des imbrications d’appels Get-View donc le passage à des hashtables sera d’autant plus efficace :p

Il se peut donc que suivant le script, le gain de l’utilisation des hashtables ne soient pas aussi flagrant. Cependant, on vous invite à faire le test et comparer les temps d’exécution afin de vous faire un avis.

Voici le script utilisé pour effectuer les tests avec les 2 méthodes :

Write-Host -ForegroundColor Yellow "Benchmarking starting..."

Write-Host "`nMethod 1 (with regular filtered Get-View)"
$startMethod1 = Get-Date
$resultMethod1 = get-view -ViewType virtualmachine -Property ResourcePool, Name | ?{(Get-View $_.ResourcePool -Property Name).Name -eq "Resources"} | Select @{n="Cluster";e={(get-view (Get-View $_.ResourcePool -Property Parent).Parent -Property Name).Name}}, Name
$endMethod1 = Get-Date

Write-Host -ForegroundColor Green "Found"(($resultMethod1 | Measure-Object).Count)"records in"(($endMethod1 - $startMethod1).TotalSeconds)"seconds"

Write-Host "`nMethod 2 (with hashtable)"
$startMethod2 = Get-Date
$htabResourcePool = @{}
$htabResourcePoolParent = @{}
$htabCluster = @{}

get-view -viewtype resourcepool -property name -Filter @{"name"="Resources"} | %{$htabResourcePool.Add($_.MoRef,$_.Name)}
get-view -viewtype resourcepool -property parent -Filter @{"name"="Resources"} | %{$htabResourcePoolParent.Add($_.MoRef,$_.Parent)}
get-view -viewtype clustercomputeresource -property name | %{$htabCluster.Add($_.MoRef,$_.Name)}

$resultMethod2 = get-view -ViewType virtualmachine -Property ResourcePool, Name | ?{$htabResourcePool[$_.ResourcePool] -eq "Resources"} | Select @{n="Cluster";e={$htabCluster[$htabResourcePoolParent[$_.ResourcePool]]}}, Name
$endMethod2 = Get-Date

Write-Host -ForegroundColor Green "Found"(($resultMethod2 | Measure-Object).Count)"records in"(($endMethod2 - $startMethod2).TotalSeconds)"seconds"

On tenait à vous remercier encore une fois de nous suivre et un grand merci à John Troyer pour ce programme et ce que ça représente !

Je ne vais pas reprendre complètement l’histoire du projet (vous pourrez trouver cela dans les posts à ne pas manquer de William Lam vOpenData: An Open Virtualization Community Database ou de Ben Thomas vOpenData – Crunching Everyone’s Data For Fun And Knowledge), mais pour faire simple, vOpenData est une base de statistiques  basée sur la communauté (permettant de répondre à des questions du genre « Quelle est la taille moyenne des VMDK ? » ou « Combien il y a t-il de VM en moyenne par infrastructure ? »)

Le projet se compose d’un script (Perl ou PowerCLI au choix) disponible sur GitHub (https://github.com/vopendata/scripts) qui permet d’exporter des statistiques de votre plateforme (de manière complètement anonyme, il n’y a aucun nom, seuls les UUID sont reportés), puis du site web www.vopendata.org qui vous permettra d’importer les données recueillies par le script.

Au final, le résultat est bluffant, en quelques minutes vous avez mis à disposition vos statistiques qui s’affichent sur un dashboard général (reprenant les différentes infos de toute la communauté) disponible sur http://dash.vopendata.org/public :

Vous l’aurez compris, ce projet se base sur les efforts de toute la communauté, on compte sur vous pour y participer, rendez vous sur www.vopendata.org !

Get-View -ViewType HostSystem -Property Name,Config | Select Name, @{n="IP";e={$_.config.network.vnic.spec.ip.ipaddress}}

Soit, on va utiliser la résolution DNS du nom de l’ESXi :

Get-View -ViewType HostSystem -Property Name | Select Name, @{n="IP";e={[System.Net.Dns]::GetHostAddresses($_.Name)}}

Même si le résultat est identique, la différence se trouve au niveau du temps d’exécution. Sur une plateforme avec ~200 serveurs ESXi, la méthode vSphere SDK prend un peu plus de 26s (même en utilisant le filtre Property du cmdlet Get-View) alors que celle utilisant la méthode DNS prend 0,3s :

Alan Renouf a par la suite publié un billet sur cette sortie en détaillant les nouveautés sur les cmdlets pour la gestion des Distributed Switches : PowerCLI 5.1 R2 Released

En regardant le release note (toujours une très bonne source d’information! disponible ici), ce qui nous a tout de suite marqué, c’est enfin le support de Powershell v3 pour PowerCLI !!!

Cela ouvre pas mal de perspective, notamment sur l’amélioration des performances du Get-ChildItem. On va refaire des tests pour son intégration dans la récupération de fichier depuis un PSDrive, on vous en reparlera surement une fois cela terminé :p

On a aussi vu une nouvelle manière de se connecter à un serveur (cette méthode de connexion reprend le même principe de base que celle des plugins pour le VIClient) :

vSphere PowerCLI introduces an improvement in PowerCLI views.
With the VimClient.Connect() method, you can now connect to a server by server session ID.

En résumé, que du bon dans cette release, on ne peut que vous encourager de mettre à jour (si ce n’est pas déjà fait) en vous rendant sur le site VMware : http://blogs.vmware.com/vipowershell/2013/02/powercli-5-1-release-2-now-available.html

En y réfléchissant, on voulait que le comportement du cmdlet soit un peu identique à celui de Get-View, par exemple la possibilité de l’utiliser tel que :

Get-View -ViewType VirtualMachines
Get-VM | Get-View
Get-View -ViewType HostSystem
Get-VMHost | Get-View

Partant de là, on a regardé la définition du cmdlet Get-View en s’aidant des commandes proxy, par exemple via la commande suivante :

[System.Management.Automation.ProxyCommand]::create((New-Object System.Management.Automation.CommandMetaData(Get-Command Get-View)))

On a donc fait une fonction PowerCLI qui va afficher graphiquement dans la console la charge de différents type d’objets (machine virtuelle, hôte ESXi ou cluster vSphere). Cette fonction peut être utilisée de plusieurs manières, soit en mode standalone :

Get-Load -LoadType VirtualMachine
Get-Load -LoadType HostSystem
Get-Load -LoadType ClustercomputeResource

Une autre manière de l’utiliser est de lui passer des objets via un pipeline:

Get-VM "vm*" | Get-Load
Get-VMHost | Get-Load
Get-Cluster -Location "folder01" | Get-Load

Pour l’instant, il n’y a que ces 3 types d’objets qui sont supportés, si vous essayez d’en utiliser d’autres on saura vous le rappeler :p

La fonction affichera donc en console la charge des objets demandés :

Ca faisait un moment que l’on voulait faire une représentation « graphique » en PowerCLI de la charge des clusters vSphere, un peu à la sauce de ce que propose le VIClient pour les serveurs :

Au final, voici un script PowerCLI qui va permettre d’afficher en console une représentation de la charge des clusters de votre infra :

On s’est autant amusé à réaliser la représentation graphique en ascii art qu’à récupérer les statistiques (notamment avec la recherche du charactère parfait pour simuler les barres ^^). Ce script PowerCLI contient une fonction Get-ClusterLoad qui prend les paramètres facultatifs suivants :

.PARAMETER ClusterName
The cluster name or names separated by coma
.PARAMETER Quickstat
 Switch, when true the method to get stats is based on quickstats through summary child properties. If not, the method will use PerfManager instance with QueryPerf method in order to get non computed stats. The default for this switch is $true.

La fonction peut donc être utilisée pour afficher la charge de tous les clusters (comportement de base sans argument) :

Get-ClusterLoad

Vous pouvez aussi afficher la charge que de certains clusters (en séparant leur nom avec des virgules) :

Get-ClusterLoad -ClusterName vCluster01,vCluster02

Vous pouvez aussi forcer l’utilisation des statistiques réelles plutôt que les quickstats :

Get-ClusterLoad -Quickstat:$false

Les 2 manières de récupérer les statistiques sont radicalement différentes en termes de temps d’exécution. Tout d’abord, la manière par défaut va utiliser les QuickStats disponibles via les sous-propriétés runtime.memory et runtime.cpu du ResourcePool racine du cluster (Resources, objet de type ManagedObjectReference:ResourcePool) :

Cette méthode est rapide puisqu’elle va chercher des valeurs qui ont déjà été computées (non ce mot n’existe pas mais vous aurez compris :p) afin de les utiliser pour calculer la charge du cluster (quelques secondes pour près de 200 ESXi) :

La deuxième méthode (en passant par le switch -QuickStat:$false) va récupérer les  compteurs de statistiques mem.consumed.average et cpu.usagemhz.average de chaque cluster. Cette charge représentera donc une moyenne (et donc pourra être un peu différentes des résultat de la première méthode suivant le load) et sera plus longue à être calculée (un peu plus de 2 minutes pour près de 200 ESXi) :

Le script en l’état n’est pas foncièrement très utile (à part le côté fun du ascii art ^^), mais on travaille sur un plugin qui pourrait être ajouté au vCheck afin d’avoir cette représentation dans le rapport généré. Ce billet sera mis à jour une fois le plugin finalisé.

La fonction qui affiche le graphe en prenant en input un pourcentage est la sous fonction Show-PercentageGraph (ligne 37 à 50):

function Show-PercentageGraph([int]$percent, [int]$maxSize=20) {
	if ($percent -gt 100) { $percent = 100 }
	$warningThreshold = 60 # percent
	$alertThreshold = 80 # percent
	[string]$g = [char]9632 #this is the graph character, use [char]9608 for full square character
	if ($percent -lt 10) { write-host -nonewline "0$percent [ " } else { write-host -nonewline "$percent [ " }
	for ($i=1; $i -le ($barValue = ([math]::floor($percent * $maxSize / 100)));$i++) {
		if ($i -le ($warningThreshold * $maxSize / 100)) { write-host -nonewline -foregroundcolor darkgreen $g }
		elseif ($i -le ($alertThreshold * $maxSize / 100)) { write-host -nonewline -foregroundcolor yellow $g }
		else { write-host -nonewline -foregroundcolor red $g }
	}
	for ($i=1; $i -le ($traitValue = $maxSize - $barValue);$i++) { write-host -nonewline "-" }
	write-host -nonewline " ]"
}

La largeur du graphe généré peut être changé dans la sous fonction Show-PercentageGraph (ligne 37):

[int]$maxSize=20

Vous pouvez aussi modifier le seuil de modification de couleur  dans la sous fonction Show-PercentageGraph (ligne 39/40):

$warningThreshold = 60 # percent
$alertThreshold = 80 # percent

Ces alertes sont apparues alors qu’il n’y avait aucune VM hébergée par ces serveurs, donc potentiellement très peu de trafic réseau. Puisque presque tout troubleshooting passe par l’outil esxtop on a fait un tour  dans le contexte réseau (touche ‘n’) :

Ce qui était bizarre c’est qu’on ne voyait aucun paquet droppé en envoi (compteur %DRPTX) ou en réception (compteur %DRPRX) alors que le graphe de performance du vCenter en affichait.

Vu que le compteur du vCenter est un compteur en summation (ie compteur calculé à partir de valeurs récupérées sur une plage de temps), on a voulu s’assurer que les compteurs esxtop restaient à zéro. On a donc lancé un jeu d’esxtop en mode batch (qui redirige les résultats dans un fichier externe), et en important ces résultats dans un perfmon, on a bien vu qu’a aucun moment les compteurs esxtop ont dépassé 0 …

On vous passe tous les tests infructueux pour trouver d’où pourrait venir cette différence d’interprétation entre les compteurs esxtop et le graphe de performance vCenter. Dans un ultime essai de comprendre d’où cela aurait pu venir, nous avons réalisé une capture de trame depuis l’un des ESXi ayant le problème (aucune VM ne tournait dessus, le serveur était en mode maintenance) via la commande tcpdump-uw :

tcpdump-uw -i vmk0 -s 1514 -w traffic.pcap

Cette commande permet de lancer une capture de trame réseau en n’écoutant que sur l’interface vmk0 (-i vmk0), en capturant toute la trame réseau (-s 1514 pour une trame normale ou -s 9014 pour une trame Jumbo Frames) et en sauvegardant les trames au format pcap pour pouvoir les ouvrir par la suite dans WireShark.

Malheureusement, après une longue étude des trames récupérées, rien n’apparaissaient comme suspect, ou avec une mauvaise destination qui aurait pu être droppé par la vmnic …

Dans une dernière recherche de cause, vu que l’image HP pour ESXi venait juste de sortir (à peine quelques semaines), on s’est demandé si le problème n’aurait pas pu venir des pilotes embarqués. OK, la version était supportée par HP, mais on se rappelle d’anciennes expériences douloureuses avec des pilotes pour cartes Flex10 générant des PSOD ou des pertes aléatoires de connexions, donc bon :p

En comparant via la commande ethtool des lames installées il y a quelques mois et les nouvelles lames (avec la même configuration matérielle), on voit effectivement une différence au niveau de la version utilisée (le pilote et le firmware étant les mêmes), sur une ancienne lame, la version est en 2.102.518.0 :

Alors que les nouvelles lames sont en version 4.1.334.0 :

Nous avons donc effectuer un downgrade du pilote ESXi des cartes OnBoard FlexFabric pour revenir vers la même version que les autres lames pour pouvoir comparer.

Cela s’effectue via la commande esxupdate, on récupère tout d’abord le nom du package installé correspondant au pilote :

esxupdate query --vib-view | grep -i be2net

Ensuite, on supprime ce package :

esxupdate -b cross_oem-vmware-esx-drivers-net-be2net_400.4.1.334.0-1vmw.2.17.249663 remove

Puis on installe le package avec la version voulue (le bundle a été mis sur un datastore pour un accès simplifié depuis le serveur ESXi) :

esxupdate --bundle=/vmfs/volumes/d3a29a6f-aa4be900/SVE-be2net-2.102.518.0-offline_bundle-329992.zip update

Une fois cela fait, plus aucun paquet droppé, même avec du load important !

Moralité, tester, tester, toujours tester avant de mettre en production (et cela pour tous les composants, CPU, mémoire, disques, etc…) ! Et bien connaitre son infra pour savoir exactement ce qui se passe dessus (encore merci aux alarmes « croissants-baguette » de Super Hypervisor !)

]]> http://www.vmdude.fr/how-to/pilotes-hp-pour-esxi-vs-paquets-droppes/feed/ 2 http://www.vmdude.fr/how-to/erreur-vcenter-http503-service-unavailable/ http://www.vmdude.fr/how-to/erreur-vcenter-http503-service-unavailable/#comments Wed, 21 Nov 2012 08:51:21 +0000 Ammesiah http://www.vmdude.fr/?p=2797 Continue reading]]> Alors que l’on travaillait sur un petit plugin pour le vCenter d’historisation des fichiers *.vmx et *.vmdk (juste le descripteur et non pas le -flat) afin de pouvoir tracer facilement les modifications/évolutions de ces fichiers (afin de savoir précisément ce qui se cache derrière les « Reconfigure Virtual Machine »), on a rencontré un petit problème avec les Web Services du vCenter.

En aparté, juste pour le fun, voici un petit teaser du plugin pas encore fini :

Le problème que l’on a rencontré est apparu alors que l’on faisait tourner le programme de récupération de fichiers *.vmx et *.vmdk. Le programme a commencé à récupérer correctement les fichiers, mais au bout d’un certain moment (compte tenu du grand nombre de VM), des erreurs sont apparues, du style :

Au même moment, d’autres problèmes sont apparus, MOB vCenter inaccessible, impossible de prendre la main en console sur une VM :

Après une recherche rapide dans les KB de VMware, on tombe sur la KB 2033822 : vCenter Server returns « 503 Service Unavailable » errors

Voici l’extrait de la KB qui nous concerne :

The vpxd log files contain entries that indicate that a socket connection attempt failed because it timed out. If you run netstat -an on the vCenter Server host machine immediately after the error, you will see many connections where one end is port 8085 on the loopback and the other end is another port on the loopback. Some of these connections will be in the TIME_WAIT state.

vCenter Server uses TCP connections on the loopback (localhost) for Remote Procedure Calls (RPC) to dispatch client requests and to communicate with vCenter Server companion services. As a result, under heavy loads, vCenter Server creates many local TCP connections, then closes them and opens new ones. Some of the closed connections remain open at the server side in theTIME_WAIT state for some time (four minutes with default Windows settings). Because the number of client-side ports is limited, if vCenter Server uses the connections fast enough, at some point the client side tries to reuse a port while the server side still has a connection for this client port in the TIME_WAIT state.

Rapidement, on vérifie sur le serveur vCenter les connexions en TIME_WAIT sur le port 8085 (via la commande netstat -an | findstr « 8085.*TIME_WAIT ») pour se rendre compte qu’effectivement, il y en avait beaucoup :

La KB 1030246 : Port 8085 in VMware vCenter Server nous en apprend un peu plus sur l’utilisation réelle du port 8085 par vCenter :

This means that 8085 is the port where all the SDK connections to vCenter Server are being made, which in turn means that vSphere Client and any scripts built on vCenter Server SDK use this port.

Et on retrouve la même alerte que dans la précédente KB liée à une charge importante :

If there are a lot of scripts or applications making connections with vCenter Server, it is possible to see a large number of ports in a TIME_WAIT state. This is normal because Windows keeps a socket in TIME_WAIT state for certain period of time (Twice Maximum Segment Lifetime, so this wait could be 4 minutes) before recycling it back for use.

Dans notre cas, vu que l’infrastructure est relativement importante (~2000 VM), et que l’on automatise au maximum, on arrive rapidement à saturation des ports disponibles pour les connexions SDK. La KB nous détaille la procédure afin de modifier cette limite :

By default, vCenter Server has 3976 ephemeral ports. If you are running out, you can increase the limit.

To allow more local ports to be available:

• Open Registry Editor (Regedt32.exe).
• Locate this key in the registry:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
• Right-click Parameters and choose New DWORD Value.
• Enter MaxUserPort in the Name data box, enter 65534 (Decimal) in the Value data box, then click OK.
• Note: The default setting for the MaxUserPort value is 5000 (Decimal).The maximum value for Windows Server 2003 is 65534 (Decimal).
• Close Registry Editor.
• Restart the machine for the new setting to take effect.

Afin de régler le problème si vous ne voulez pas modifier cette valeur, vous pouvez attendre les 4 minutes afin que Windows purgent automatiquement les connexions restantes en TIME_WAIT, ou bien relancer le service Windows VMware VirtualCenter Management Webservices (pour les plus pressés).

Moralité, on a pu modifier ce paramètre pour continuer à utiliser les scripts OneLiner PowerCLI en masse ^^

C’est le 2ème VMworld auquel on va et on a eu la chance cette fois ci de pouvoir y aller avec notre confrère hypervisor.fr et de retrouver Timo la bas !

Cette année, notre ressenti a été radicalement différent de l’année dernière. Peut être parce que cette fois on y était pas tout seul, ou parce que ce n’était pas le premier :p En tout cas, on a vraiment pu en profiter un maximum !

Par contre, c’est vrai que l’expérience de l’année passée a permis de mieux préparer celui de 2012, et de plus se concentrer sur les « rencontres » que les présentations. Ce que l’on veut dire par là, c’est que à moins d’avoir des questions à poser sur une présentation, on peut les rattraper via les vidéos Sessions Online par la suite. Certes, cela n’est pas du tout pareil que de le voir en vrai, mais il y a tellement de choses à voir/faire qu’il faut prioriser :p Et puis, sur la fin, on avait tellement de monde que l’on voulait voir qu’on était un peu en mode « Où est Charlie » :p

Au final, on a voulu privilégier les sessions Group Discussion et Meet The Expert tout simplement parce que ce sont des sessions beaucoup plus « intimes » que les autres et où tout se base sur des échanges avec les participants (sachant que Meet The Expert était une session 2:1 vraiment super avec Duncan :p ).

Une des sessions à laquelle on a participé et qui était bien sympa était celle présentée par Kit Colbert sur Understanding Virtualized Memory Performance Management (INF-VSP1729) , on a pris quelques photos pour l’occasion :

Ensuite, traditionnellement les sessions « Must-See » d’Alan et Luc sur PowerCLI Best Practices: The Return! (INF-VSP1329) :

On a pu profiter aussi de la session #NotSupported par William :

On a même pu immortaliser ce VMworld avec Alan et Luc :

Au final on a pas mal discuter avec plein de gens : Luc, Alan, Duncan, Cormak, William. On regrète de ne pas avoir pu voir Franck, on va essayer de se rattraper au prochain VMUG belge :p