On m’oblige a faire des choses, vraiment, je vous le dis comme je le pense, qui me semblent un peu insurmontables au début (genre Everest, voyez). L’exemple le plus récent concerne une obscure fonction de vRealize Operations appelée “SuperMetric”. Jusqu’à présent, je savais que ça existait, mais je n’avais jamais vraiment pris le temps ni éprouvé le besoin de creuser cela, tant les metrics disponibles en standard étaient déjà riches et la plupart du temps parfaitement suffisants pour mon usage quotidien.
Or, lors d’une petite discussion sur le slack VMUG avec certains éminents collègues et compagnons de route (big up les amis !), une demande spécifique d’un client a amené le collègue en question à se demander si, par le plus grand des hasards, un SuperMetric ne serait pas la solution. La question était pourtant, en apparence, simple : “je voudrais remonter le CPU moyen des VMs d’un dossier”. Je vous arrête tout de suite, ne cherchez pas, le metric en question n’existe pas dans vROps. Alors, pouvions-nous nous en sortir avec ces fameux SuperMetric, obscurs et pleins de promesses ?
Je ne vais pas faire durer le suspens plus longtemps, la réponse est oui. Et vous allez voir qu’en prenant le temps nécessaire, une fois qu’on a compris le principe de base, les SuperMetrics sont relativement simples à mettre en oeuvre. Je précise tout de suite, que la mécanique que je vais présenter repose sur la version 7.0 de vROps, mais elle doit être relativement similaire depuis pas mal de versions (depuis l’arrivée de l’interface HTML5 je pense).
Avant toute chose, sachez que les SuperMetrics ne sont disponibles qu’à partir de la version Advanced, pas en version Standard, malheureusement. Merci à Gaël pour l’info (qui pleure toutes les larmes professionnelles de son corps, du coup …)
Commençons donc par le début : rendez-vous sur la page d’administration de vROps dans la section “Configuration”, puis, évidemment, “SuperMetrics”. On va s’empresser d’en créer un premier, soyons fous, joueurs et facétieux, en cliquant sur le petit “+” de rigueur.
Alors, déjà, pas de panique, on va détailler tout cela. Vous disposez en substance de 5 grandes parties sur l’atelier :
– La partie haute concerne la “formule” de votre SuperMetric. C’est là que va s’enrichir celle-ci en fonction des sources que vous allez employer et du résultat attendu.
– La partie centrale gauche contient par défaut l’ensemble des objets réels de votre base vROps, typiquement les VM, les hosts, les dvSwitchs, les clusters etc.
– La partie centrale droite contient l’ensemble des “types d’objets” disponibles dans l’arbre de vROps : le type “Virtual Machine”, le type “Host”, le type “Virtual Machine Folder” etc. En somme, les structures dont héritent, en fonction de leur type, justement, les objets eux-même. Une machine virtuelle “toto” présente dans votre DC hérite directement du type d’objet “Virtual Machine” et de tous ses metrics et attributs de base (des propriétés comme la quantité de RAM, le nombre de vCPU, mais aussi des metric comme l’évolution de la conso CPU en pourcentage, en MHz etc.).
– La partie en bas à gauche affiche l’ensemble des “Metrics” de l’objet sélectionnée.
– La partie en bas à droite affiche l’ensemble des “Attributs” du type d’objet sélectionné.
Pour notre exemple, nous allons nous focaliser sur les types d’objets.
Voila pour les présentations, maintenant, comme ça marche exactement ? Notre demande, je le rappelle, consiste à calculer le CPU moyen d’un ensemble de VMs. Donc si je traduis cela en terme vROps : on veut calculer la moyenne arithmétique des metrics “CPU Usage (%)” d’un ensemble d’objets “Virtual Machine”.
Dans le sélecteur de fonction en haut à gauche, on va d’abord sélectionner la fonction “avg” (moyenne arithmétique, donc … vous suivez ?), puis dans la partie Operators, ajouter une parenthèse ouvrante et tant qu’à faire, pour ne pas l’oublier, une parenthèse fermante aussi (en fait il y a un moyen beauucoup plus efficace : vous tapez avg() dans le champ texte ^^). Enfin, ce sera utile pour la suite, placez votre curseur pile entre les deux parenthèses. On va y insérer des choses très vite.
Ensuite, nous allons sélectionner dans la partie centrale droite le type d’objet “Virtual Machine”. Je vous rappelle qu’on veut calculer une moyenne de CPUs de machines virtuelles, donc c’est relativement logique de prendre le type d’objet correspondant. Enfin, dans la partie droite en bas, vROps va vous afficher la liste des attributs et metrics disponibles pour le type d’objet sélectionné plus haut, “Virtual Machine” en l’occurence. Faites votre marché et allez trouver le type d’attribut “CPU->Usage (%)”. Enfin, double-cliquez sur celui-ci. Son “code” va être automatiquement ajouté à l’endroit où se trouve votre curseur dans le champ texte où on a commencé à écrire notre formule de calcul.
On est pas mal, là, dites-moi ! On vient tout simplement de construire une formule qui se tient et qui, de plus, n’a pas d’erreur (il y a un interpréteur syntaxique intégré sur le champ, donc si ce n’est pas correct, vous aurez des alertes en rouge). On a plus qu’à donner un nom à notre SuperMetric et le sauvegarder. La première partie, la plus difficile à mon sens, est terminée. On vient tout simplement de construire un SuperMetric qui est capable de calculer une valeur moyenne dynamique de la conso CPU d’un ensemble de VMs. Maintenant il va falloir l’associer à l’ensemble souhaité. Notre cahier des charges indique que l’on veut une conso moyenne sur l’ensemble des VMs présentes dans les dossiers de VM de notre infra. Pour ce faire, placez vous dans l’onglet “Object types” et cliquez sur l’icône “+”. L’assistant vous demande de sélectionner le type d’objet que vous souhaitez associer à votre SuperMetric. On va choisir “Virtual Machine Folder”, évidemment.
La nouvelle étape est franchie. Maintenant, il ne nous reste plus qu’à dire à vROps de commencer à enrichir ce nouveau SuperMetric. Désormais, cela va se passer dans la section “Policies”. Pour faire ultra-simple, voire simpliste, les politiques vROps permettent de “tuner” l’ensemble du comportement et du fonctionnement du produit. Il y faudrait sans doute un livre entier pour comprendre et décrire l’ensemble des possibilités offertes par les celle-ci, mais pour ce qui nous occupe, on va juste s’en servir pour prendre en compte notre SuperMetric fraîchement créé.
On va d’abord, histoire de ne pas tout casser, créer un backup de la politique active. Ici, comme on part de la politique par défaut, on va créer tout simplement une nouvelle politique à partir de celle-ci. Pour se faire, allez dans l’onglet “Policy Library” et cliquez sur le petit “+”. Ensuite, dans l’assistant, donnez-lui un nom et dans le sélecteur “start with”, sélectionnez “Default Policy”. Si vous disposez déjà d’une politique maison, utilisez celle-ci comme point de départ.
Maintenant, placez-vous dans la section “Collect Metrics and Properties” et dans le filtre, indiquez le nom de votre SuperMetric. Normalement, vROps vous renvoie un certain nombre de lignes : la première vous permet d’active le metric sur l’ensemble des objets de vROps, les autres vous détaillent les différents types d’objets que vous avez spécifiquement choisi comme cibles. Dans notre cas, normalement, vous n’avez que deux lignes, la deuxième indiquant justement dans la colonne “Object type”, “Virtual Machine Folder”. Sélectionnez cette deuxième ligne et précisez, dans la colonne “State” que vous voulez que la politique s’en occupe, via le choix “Local”.
Un petit clic sur “Save” et votre politique est désormais crée. C’est une copie de votre politique initiale à ceci près qu’elle est capable de calculer et suivre le SuperMetric “VM-avgCPU”. Allez, on est presque au bout, il nous reste à activer la politique. Pour cela, sélectionnez celle-ci et cliquez sur l’icône “Flèche bleue vers la droite” aka “Set Default Policy”.
C’est fini ! Votre SuperMetric est créé, vous l’avez affecté au type d’objet “Virtual Machine Folder”, vous avez créé une copie de votre politique active, ajouté la prise en compte du SuperMetric et enfin, remplacé la politique active par la nouvelle. Quand je disais que vous étiez un super-héros ! Vous pouvez d’ailleurs vérifier que tout s’est bien passé en consultant les divers sections et notamment en revenant dans celle des SuperMetric pour confirmer que le vôtre est bien actif dans la politique fraîchement créée.
Et qu’est-ce qu’on fait maintenant ? On va l’utiliser pour grapher pardi ! A ce niveau je ne vais pas trop détailler, mais modulo quelques minutes, vous devriez voir apparaître comme par magie, si vous vous placez dans un dossier de VM (cette fois-ci dans la section “Environment->vSphere Hosts and Clusters” par exemple), onglet “All metrics”, votre SuperMetric, comme s’il avait toujours été là.
Ce petit tutoriel en forme d’assistant ne fait que toucher du doigt le potentiel réel des SuperMetrics, vous pouvez en effet combiner plusieurs metrics pour calculer, on peut imaginer des centaines de combinaisons et usages possibles. Vous pouvez par exemple calculer le markup VMware de vos hyperviseurs en faisant le ratio entre l’ensemble des CPUs usages de chaque VM présentes sur la machine et la consommation CPU reportée par l’ESXi lui-même, où même comparer la consommation d’un ensemble de VM X avec un autre ensemble Y…. bref, les possibilités sont infinies et j’avoue que le temps que je viens de passer pour ce billet va me permettre de répondre beaucoup plus facilement à certaines questions très pointues qui nous sont demandées en terme de tableaux de bords. Le plus dur est d’arriver à “planifier” votre SuperMetric sur le papier avant de l’implémenter réellement sur votre vROps.
Je rappelle aussi que ce tuto s’applique globalement à des installations “standards” de vROps (notamment la partie des politiques), donc n’oubliez pas de bien adapter cela à votre propre usage et contexte. J’espère que ça vous aidera en tout cas !
Super-héros, je vous salue ^^
Pour aller plus loin, la docs VMware, très bien faite, que j’ai utilisé pour démarrer, à lire avec avidité ici.
La référence des fonctions et opérateurs disponibles (c’est dingo, on peut même écrire des programmes pour calculer des valeurs !), à consulter ici.
5