Viva la HashTable

On a toujours essayé d’optimiser au maximum les scripts et applications que l’on développait, car dès le moment que l’infrastructure est relativement importante, le gain est loin d’être négligeable (on l’a vu précédemment avec les optimisations sur le vCheck).

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"

vExpert 2013

C’est ce matin tôt que nous avons eu le plaisir de voir que l’on faisait partie des vExpert 2013 !

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 !

Et voilà venu l’ère de vOpenData !

Voici un petit billet qui va parler du projet vOpenData sur lequel on a eu la chance d’offrir notre aide avec hypervisor.fr

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 !

Liste des ESXi avec IP

Voici un petit mémento qu’on avait oublié de poster pour récupérer rapidement le nom et l’IP des serveurs ESXi d’une plateforme vSphere. Plusieurs possibilités pour faire cela, soit on utilise uniquement des propriétés vSphere SDK :

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 :

Powershell v3 et PowerCLI

C’est hier soir que l’on a vu la bonne nouvelle de la semaine, à savoir une nouvelle version (5.1 Release 2) de PowerCLI :

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 SwitchesPowerCLI 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

Page 1 sur 26123451020Dernière page »