Hypervisor.fr

La liste des vExpert 2013 vient d’être publiée et pour la 4ème année nous avons l’honneur d’en faire partie. Cette année nous sommes 580+ soit presque 200 de plus qu’en 2012, une liste trop longue au goût de certains… Merci à tous (une fois de plus) pour votre soutien et votre confiance !

Tags: vExpert

Suite à la publication de l’excellent Understanding VMware vSphere 5.1 Storage DRS rédigé (et surtout illustré) par Frank Denneman, nous nous permettons une petite remarque au sujet de la réactivité de SDRS lors du dépassement du seuil de remplissage. Dans le white paper, on peut lire ceci :

vSphere Storage DRS attempts to avoid an out-of-space situation and therefore runs a load-balancing operation as soon as the datastore exceeds its space-utilization threshold. This operation can be outside of the normal load-balancing interval of every 8 hours.

La première phrase est aussi intéressante qu’imprécise. On y apprend que la réaction est immédiate mais aussi qu’elle dépend de vCenter. Et suite à une batterie de tests sur différents environnement (5.0 et 5.1), nous avons remarqué que la fréquence de rafraîchissement de cette information dans vCenter n’est malheureusement que d’une (1) fois toutes les 30 minutes au mieux. (on soupçonne un algorithme basé sur l’utilisation du datastore mais visiblement pas encore très efficace). Pour le vérifier, rien de tel qu’un petit oneliner de PowerCLI qui check la propriété info.timestamp des datastores :

Get-View -ViewType datastore -property info,name,summary|?{$_.summary.accessible}|select name,{$_.info.timestamp.ToLocalTime()}

On constate donc qu’un des pilier de SDRS repose sur une donnée dont la fiabilité peut malheureusement varier et dont la fraîcheur peut laisser à désirer même dans le cas des 30 minutes. En attendant que ça bouge coté VMware, voici un workaround (nettement moins dingue que celui d’une certaine kb), qui consiste à forcer le refresh rapide à votre convenance sans que la tache n’apparaisse dans le vCenter (merci le SDK). Dans notre exemple, refresh de tous les datastores dont la propriété info.timestamp serait “veille” de plus de 5 minutes :

Get-View -ViewType datastore -property info,summary|?{$_.summary.accessible}|?{($(get-date) - $_.info.timestamp.ToLocalTime()).TotalMinutes -gt 5}|%{$_.RefreshDatastore()}

La seconde phrase de la citation, c’est un RTFM politiquement correct pour ceux qui font encore l’amalgame entre les 8h d’intervales de l’I/O load balancing et le Space-Utilization Load Balancing.

Tags: monitoring, PowerCLI, SDK, SDRS

Il y a quelques années, un petit outil pas très connu nommé “VC StatLevelConfig“ faisait son apparition dans la liste des Flings de VMware. Cet outil permettait à l’époque de changer unitairement le niveau par défaut de collecte des compteurs de performance du vCenter. Par exemple, si vous vouliez garder les stats d’active memory sur 24h pour vos ESX, cet outil vous permettait de le faire de façon unitaire plutôt que d’augmenter le niveau de collecte global du vCenter. Tout ce mécanisme de collecte est très bien détaillé dans le post de Luc Dekens :

Malheureusement la page de ce fling n’existe plus (même si l’outil est toujours disponible) mais nous avons trouvé son équivalent en PowerCLI au détour de 2 kb traitant de SIOC (ici et là). Il s’agit d’un module powershell qu’il suffit de charger avec la commande “Import-Module” et vous aurez ensuite accès à 2 nouvelles cmdlet (Get-PxCounterLevelMapping et Set-PxCounterLevelMapping) pour opérer les changements désirés.

A titre d’exemple, voici le niveau par défaut du compteur mem.active.average dont nous parlions plus haut :

Après exécution de la commande magique, le résultat (avant/après sur les graphiques) :

Get-PxCounterLevelMapping|?{$_.Name -eq "mem.active.average"}|Set-PxCounterLevelMapping -AggregateLevel 1

Ces modifications auront des conséquences sur la taille et peut être les performances de la base de données de votre vCenter mais ce sera toujours mieux qu’une augmentation “globale” qui entraînera la collecte de compteurs dont vous n’aurez peut être jamais besoin…

Tags: fling, PowerCLI

MAJ 23.10.2013 : Et re-re-paf, la version 5.1 U1c !!!

MAJ 02.08.2013 : Et re-paf, la version 5.1 U1b !!

MAJ 23.05.2013 : Et paf, la version 5.1 U1a !

Après la version 5.1.0, la version 5.1.0a, la version 5.1.0b, voici la version 5.1 U1 dispo à peine depuis hier que déjà un important bug lié au composant SSO vient renforcé l’impression que la version 5.1 ne fera pas partie de vos préférées…

Customers with SSO configured with multiple domain-based identity sources along with vCenter Server domain user accounts that are associated with a large number of groups should not upgrade to vCenter Server 5.1 Update 1.

Comme tout bon geek, nous avons succombé à la tentation du Rasberry Pi et, comme beaucoup, bien avant de savoir quoi en faire. Après avoir passé la période Raspbmc, GPIO et même 100% wireless, nous ne trouvions pas d’usage “définitif” pour notre petite e-framboise, jusqu’à ce que nous rencontrions un gros  problème de NTP sur notre homelab.

The Global Positioning System (GPS) is a space-based satellite navigation system that provides location and time information in all weather conditions, anywhere on or near the Earth where there is an unobstructed line of sight to four or more GPS satellites.

[...]

About nine satellites are visible from any point on the ground at any one time, ensuring considerable redundancy over the minimum four satellites needed for a position.

[...]

GPS time is theoretically accurate to about 14 nanoseconds. However, most receivers lose accuracy in the interpretation of the signals and are only accurate to 100 nanoseconds

C’est sur le blog de Peter Mount que nous avons pu trouver un howto des plus simples au quel nous avons ajouté un dongle wifi usb :

Le tout monitoré grâce à un template cacti :

Et en prime, un module GPIO LedBorg RGB pour savoir de visu si la source GPS du serveur NTP est ok :

Enfin, pour les fanatiques de la précision, il y a le GPS/PPS sur Raspberry Pi détaillé par David Taylor.

Tags: cacti, GPS, NTP, RaspberryPi