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 : https://vblog.io/downloads/vplexdirector_template_v1.0.xml
Les scripts (archive tar.gz) sont à télécharger ici : https://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 :
Capture

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 !

12 thoughts on “Une nouvelle méthode de supervision VPlex … et son template Cacti !

  1. Nicolas M says:

    C’est top !

    Bravo pour le boulot !! :D

    Par contre ca fait beaucoup mais alors beaucoup de ssh vers les vplex.
    2 ssh par valeur récupérées.

    J’ai modifié le script pour mettre en cache les données durant 50s (valeur modifiable) de maniére a ne faire que 2 ssh par vplex et par poller cacti.

    Aussi modifié la maniére de récuperer les valeurs avec “paste” plutot que de faire 2 boucles pour compter la ligne

    cat check_director_metric.sh

    #! /bin/bash

    if [ -f “/tmp/debug_on” ]; then
    echo “START $0 args / $*” >>/tmp/vplex_debug.log
    fi

    if [ “$2” = “” ]; then
    echo “USAGE: $0 ”
    exit 0
    fi

    SSHOPTS=”-o StrictHostKeyChecking=no”
    PERPETUAL_PREFIX=”/var/log/VPlex/cli/director-”
    PERPETUAL_SUFFIX=”_PERPETUAL_vplex_sys_perf_mon.log”
    DEFAULTUSER=service
    VPLEX=$1
    DIRECTOR=$2
    METRIC=$3

    REFRESH=50
    file_d=/tmp/def_${1}_${2}
    file_v=/tmp/val_${1}_${2}
    file_r=/tmp/rel_${1}_${2}

    if [ -f $file_d ]; then
    file_age_d=$(( date +%sstat -L --format %Y $file_d ))
    else
    file_age_d=1000
    fi

    if [ -f $file_v ]; then
    file_age_v=$(( date +%sstat -L --format %Y $file_v ))
    else
    file_age_v=1000
    fi

    if [ $file_age_d -gt $REFRESH ]; then
    ssh ${SSHOPTS} ${DEFAULTUSER}@${VPLEX} -C head -1 ${PERPETUAL_PREFIX}${DIRECTOR}${PERPETUAL_SUFFIX} | tr ‘,’ ‘\n’ > $file_d
    fi

    if [ $file_age_v -gt $REFRESH ]; then
    ssh ${SSHOPTS} ${DEFAULTUSER}@${VPLEX} -C tail -1 ${PERPETUAL_PREFIX}${DIRECTOR}${PERPETUAL_SUFFIX} | tr ‘,’ ‘\n’ > $file_v
    fi

    paste -d”;” $file_d $file_v > $file_r
    VALEUR=$(cat $file_r | grep “$METRIC” | gawk -F”;” ‘{print $2}’)

    OUT=”value:$VALEUR”
    echo $OUT

    if [ -f “/tmp/debug_on” ]; then
    echo “STOP $0 resultats / $OUT” >>/tmp/vplex_debug.log
    fi

    • Cédric Cédric says:

      Effectivement, j’ai depuis modifié aussi le polling pour garder les données en cache, ça limite les ouvertures de session SSH sur les consoles VPlex, donc tu as devancé ma v1.1 :D . J’intègrerai tout cela dans une prochaine version. D’autre part, je n’avais jamais utilisé paste, mais bien joué pour la simplification, c’est excellent :)

      C’est bien d’avoir un expert Shell dans ses contacts, je prend note :D

      Merci Nicolas !

      • Nicolas M says:

        A noter également les logs par Volumes.
        Je vais faire un template inspiré du tien.

        -rw-r–r– 1 service users 9390532 Aug 12 14:48 director-2-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log

        service@xxxxxxxxxx:/var/log/VPlex/cli> head director-2-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log
        Virtual Volume,fe-lu ops (counts/s),fe-lu read (KB/s),fe-lu write (KB/s),fe-lu read-lat recent-average (us),fe-lu write-lat recent-average (us)
        2015-06-30 05:45:00
        xxxxxxxxxx,4.1,1.11,42.9,580,2087
        xxxxxxxxxx,0.833,0.525,4.44,436,1752
        xxxxxxxxxx,1.97,0.617,13.9,637,1710
        2015-06-30 05:46:01

    • Cédric Cédric says:

      En essayant ta modif, je viens de tomber sur un souci de “cohabitation” quand on utilise spine et qu’on indique plusieurs threads par Device, les check_metric se bouffent le nez par moment et les données ne sont plus fiable. Donc si vous utilisez le check_metric de Nicolas, pensez bien à indiquer un seul thread par directeur, pour être tranquille avec cet effet pervers ;)

      Concernant les virtual volumes, effectivement, on peut aussi exploiter le perpetual monitor ad-hoc, par contre, le template devra intégrer un outil “d’inventaire” préalable si l’on veut générer ça automatiquement pour tous les VV… ça se complique ;)

  2. leo says:

    Merciiiii et encore un tres beau boulot.

    pour info, pour les personnes utilisant des liaisons WAN-COM IP, il faut changer les scripts check_director_wanbw.sh & check_director_wanio.sh pour y ajouter les ports IP A2-XG00 / 01

    • leo says:

      hmmm, attention je viens de tomber un bug répertorié chez EMC.
      en jouant avec les “monitors” du vplex, il s’avere que certain compteurs sont classés differements suivant les release code utilisé et a priori non mis a jour lors de monté de version… :(

      dans mon cas, sur l’un des cluster, les donnés wan-com sont rangé dans le compteur suivant “ip-com-port.xxx A2-XG00/01” et sur l’autre cluster dans “fc-com-port.xxx A2-XG00/01”

      après discution avec un ingé EMC, il faudrait “destroy” les monitor par default puis restart le management server. Ce qui aura comme effet de recreer les 2 monitors avec les bons compteurs.

      suite au prochain épisode :)

      • leo says:

        effectivement la procédure validée par EMC fonctionne.

        attention néanmoins, les compteurs seront donc accessible via “ip-com-port.xxx A2-XG00/01” sur les 2 clusters, il faut donc adapter les scripts wanio et wanbw en adéquation.

  3. Leon Lee says:

    Hi Cedric,

    This is Leon from Beijing. I use your template for cacti now. I got some issue for it: I have enabled snmp for EMC VNX5600 and uploaded those scripts to “/opt/apache/htdocs/cacti/scripts/vplex” directory. In addition, I have imported the xml file to cacti but I still can not get the snmp data from rrdtool. The rrdtool feedback “nan” from web user interface. could you please give me some helps?

    Best Regards,
    Leon Lee

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *