Une nouvelle méthode de supervision VPlex … et son template Cacti !

Je vous en parle depuis longtemps (plus d’un an désormais), étant donné son statut central et critique au sein d’un réseau de stockage, la supervision d’un VPlex est un élément important voir crucial, pour anticiper et gérer la qualité générale des accès (haut débit, faible latence, dynamique globale). J’ai essayé beaucoup de choses pour arriver à suivre correctement l’activité d’un cluster VPlex, sans vraiment obtenir une satisfaction complète. Après l’exploitation des moniteurs VPlex, sa supervision via snmp problématique ou encore plus récemment, son intégration à VMWare vRealize Operations via Storage Analytics, je n’ai pas vraiment trouvé chaussure à mon pied, alliant facilité d’accès, légèreté et fiabilité sur le long terme.

Mais ça c’était avant ! En effet, profitant encore une fois de la période estivale plus calme pour nos cerveaux, je me suis penché à nouveau sur le problème et j’ai tenté une approche totalement différente, reposant sur un nouveau principe que j’espère plus fiable et systématique. Après quelques tests concluants, j’en ai dérivé un template Cacti directement intégrable dans le framework éponyme bien connu et qui vous permet un suivi complet du maximum d’indicateurs disponibles. Je vous propose de voir tout cela en détail dans ce billet.

L’approche est la suivante : qui mieux que VPlex lui-même est capable de récupérer les bonnes informations, les bons métriques, de manière fiable, pour en faire profiter l’administrateur ? En effet, si vous travaillez avec VPlex, vous utilisez surement régulièrement les statistiques temps réel intégrées dans la console Unisphere. Il se trouve que ces stats sont directement issues de moniteurs VPlex spécifiques, automatiquement créés par la plate-forme lors de l’installation. Ces “perpetual monitors” génèrent directement des fichiers logs dont les noms sont standards et dont l’enrichissement est parfaitement régulier et normalisé. Le principe consiste tout simplement à interroger ces logs directement via SSH et récupérer les métriques souhaités après extraction.

Les logs des perpetual monitors sont accessibles dans le répertoire /var/log/VPlex/cli de chaque Management Station. Il existe un log par directeur, reposant sur la règle de nommage suivante : /var/log/VPlex/cli/director-C-E-D_PERPETUAL_vplex_sys_perf_mon.log où C-E-D représente le “nom” du directeur au sein du cluster géré par la management station (C=numéro du cluster, E=numéro d’engine, D=directeur A ou B). Un VPlex Metro est constitué de deux clusters (au minimum) ; chaque cluster est constitué de 1 à 4 engine(s), chacun à son tour constitué de deux directeurs. Par exemple, le directeur B de l’engine 1 du cluster 2 s’appelle 2-1-B, son log est donc le fichier /var/log/VPlex/cli/director-2-1-B_PERPETUAL_vplex_sys_perf_mon.log.

Ces fichiers sont au format CSV avec le séparateur “,”. La ligne 1 constitue l’entête des colonnes et ensuite, chaque ligne ajoutée contient toutes les valeurs de colonnes correspondantes, le tout à la fréquence assignée sur le moniteur. Pour consulter la la fréquence des perpetual monitors, rien de plus simple : on se connecte sur VPlex cli :

… la fréquence de mise à jour est de 5 secondes, en moyenne (sysperf). Afin de récupérer les informations, il faut établir une session ssh sur la management console où se trouve le directeur (pas de VPlex CLI, juste une session Linux) que l’on veut superviser puis récupérer la dernière ligne de valeurs du fichier de log correspondant.

Pour une exploitation dans Cacti, il va falloir préparer un peu notre système, pour que cela se passe bien. La première chose à faire est de mettre en place une authentification par clef SSH afin de ne pas avoir de mot de passe à saisir lors du déclenchement des scripts d’interrogation. Schématiquement, le user sur lequel s’exécute le “poller” Cacti (souvent le compte d’exécution du serveur HTTP, www-data sous Debian, par exemple) doit pouvoir se connecter via clef ssh sur chaque management console. Cette partie sort quelque peu du focus de ce billet et je ne détaillerai pas complètement le procédé. Malgré tout, voici les étapes à réaliser :
– Créer, si ce n’est pas déjà fait, une paire de clef privé/publique SSH pour le compte d’exécution du poller cacti
– Coller la clef publique du compte d’exécution du poller cacti dans le fichier ~/.ssh/authorized_keys du compte “service” de la management console
– Vérifier directement sous le compte d’exécution cacti qu’on atteint bien directement la console en faisant un ssh service@ sans rentrer de mot de passe. Voici une session typique (krakenhn.intra.lab.com est le FQDN de Management station) :

… une note importante : les scripts VPlex que j’ai mis à votre disposition pour le template Cacti utilisent par défaut le compte “service” de VPlex pour se connecter. Si vous souhaitez aller plus loin en matière de sécurité, c’est tout à fait possible, bien entendu, mais vous devrez directement changer ce compte au sein du script unique qui est appelé par tous les autres <path-to-cacti>/scripts/vplex/check_director_metric.sh en modifiant la variable “DEFAULTUSER”. Enfin, si vous souhaitez en savoir plus sur la mise en place d’une authentification SSH par échange de clefs, je vous conseille de vous rendre à cette adresse sur le site de Mathieu Androz (très bon site par ailleurs ;) ).

Une fois cette mise en place terminée, le plus gros du travail est fini. Il s’agit désormais d’intégrer le template Cacti via un import XML ainsi que télécharger et décompresser dans le répertoire <path-to-cacti>/scripts/vplex/ (à créer pour l’occasion) les scripts de l’archive.

Le template Cacti est à télécharger ici : http://vblog.io/downloads/vplexdirector_template_v1.0.xml
Les scripts (archive tar.gz) sont à télécharger ici : http://vblog.io/downloads/vplexdirector_scripts_v1.1.tar.gz

La supervision Cacti de VPlex est basée, comme déjà évoqué, sur la notion de directeur. Vous devrez donc créer, pour chacun de vos clusters, un “Device” par directeur présent. Pour un VPlex Metro mono-engine, il s’agit donc de créer 4 devices, un par directeur : 1-1-A, 1-1-B, 2-1-A et 2-1-B. Lorsque vous créez un directeur, renseignez bien le nom de sa management station dans le hostname ainsi que son nom C-E-D dans le champ “snmp username”. En effet, j’ai utilisé la même astuce que pour la supervision XtremIO pour éviter d’avoir à rentrer le nom du directeur à chaque création de datasource :

Une fois intégré et correctement paramétré, ce template vous fournira les graphiques suivants, pour chaque directeur ajouté :

Et via un tableau de bord en mode preview sur Cacti, ça donne ça :

MAJ du 12/08/2015 : Suite à la proposition d’optimisation importante de Nicolas, lecteur de vBlog (voir les commentaires de ce billet, un grand merci pour sa contribution), je viens de réaliser une nouvelle archive des scripts intégrant les corrections (mise en cache temporaire des résultats des interrogations ssh, pour gagner énormément en temps de polling et accessoirement soulager un peu les consoles VPlex des nombreuses requêtes SSH initiales). L’archive passe donc en version 1.1. Par contre, information importante qui en découle, n’utilisez pas le multi-thread pour les devices VPlex et limitez-vous donc à un seul thread (valeur par défaut de Cacti, de toutes façons).

A votre disposition pour toute question, remarques, suggestions et corrections éventuelle !