Supervision de VPlex via les API web

VPlex est un composant strategique et particulièrement critique d’une infrastructure de production. Il est à l’interface entre les serveurs qui produisent de l’I/O et les baies de stockage qui servent ces I/O. Il est donc très important de pouvoir superviser au mieux les équipements qui le constituent.

Il existe plusieurs solutions pour assurer la supervision de VPlex via un produit tiers (en dehors de la console de supervision intégrée, donc). Parmi ces solutions, on peut citer deux méthode classiques : les traps SNMP et le polling actif via l’utilisation d’un jeu d’API publiques sur les services web des consoles de service.

Je vais vous présenter rapidement la deuxième solution, celle que nous avons choisi pour notre institution. Nous utilisons Nagios pour tous les indicateurs techniques de nos infrastructures et c’est par ce biais que nous avons mis en place des pollings réguliers pour interroger notre VPlex Metro.

Le principe d’utilisation de ces APIs est simple, car basé directement sur un échange HTTP sur l’un des deux service console. Il s’agit donc de construire une requête spécifique envoyée via un HTTP-GET et, en retour, obtenir et interpréter le résultat de cette commande. Pour exécuter cette requête, il suffit d’utiliser un outil comme WGET ou CURL.

Voici la requête permettant de récupérer la liste des FANs (ventilateurs intégrés aux appliances) pour un engine donné (un cluster) :

Cette requête peut être décomposée ainsi :

• -s -k : deux options spécifiques à curl, évitant l’affichage de la barre de progression et permettant d’accepter les certificats autosignés/invalides
• -H Username:supervision -H Password:MOTDEPASSE : rajoute de deux entêtes complémentaires à la requête HTTP-GET pour s’authentifier sur le VPlex
• https://krakenhn/vplex/engines/engine-1-1/fans : la requête proprement dite

Pour ceux qui connaissent déjà un peu l’environnement CLI de VPlex, vous noterez que la chaîne suivant le FQDN du cluster VPlex interrogé (ici cluster1.fqdn.com) est en grande partie identique au contexte à l’intérieur duquel on souhaite opérer l’interrogation.

Voici ce qui est retourné par l’exécution de la commande :

Comme vous pouvez le noter, ce retour est formatté en JSON ( Wikipedia, site officiel ). Malgré sa syntaxe un peu particulière, cela reste relativement simple à comprendre. Ici, le VPlex nous a renvoyé, comme prévu, la liste des FANs présents dans l’engine 1-1, tel que demandé dans la chaîne HTTP. Si l’on veut récupérer le statut de chaque FAN, il suffit de renvoyer une requête plus précise en indiquant le nom spécifique du FAN à interroger :

On obtient en retour le résultat suivant :

Les paramètres du FAN son listés et leur statut est remonté via les champs “value”. Ici, par exemple, le statut “operational-status” est “online”, en mode nomminal, donc.

D’une manière générale, l’ensemble des contextes du VPlex peut ainsi être interrogé et, une fois mis en forme, remonté dans une console de supervision. Le principe est simple, son exploitation aussi, pour peu que l’on ait un peu de temps pour construire les scripts de mise en forme adéquats, évidemment.

Il existe également des règles d’écriture des URLs d’interrogation qui permettent de récupérer en une seule fois toute une série de paramètres ou d’états. Ainsi la requête suivante récupère l’ensemble des états “operational-status” d’une branche contextuelle, ici les FANs :

Vous notez qu’on indique derrière le “?” , en fin de chaine HTTP, le type de paramètre à interroger pour tous les contextes situés sous …/fans/ . Le retour de cette commande est de ce type :

Encore une fois, un résultat sans ambiguïté et relativement lisible.

Pour les besoins de supervision de notre infrastructure, nous avons donc construit en interne une série de scripts shell permettant d’interroger les éléments du VPlex et de retourner leur résultat sous une forme compatible avec Nagios. Voici la liste de tous les composants que nous supervisons actuellement avec succès via cette méthode :

• L’état général hardware des engines : alimentations, fans, modules de management, état général des cartes mères
• L’état des communications entre les clusters et le witness VPlex
• L’état général des communications entre les directeurs (état des liaisons WanCom principalement)
• L’état des distributed devices (état du mirroir, état de fonctionnement local)
• L’état des devices locaux (état des mirroirs locaux, si existants, état de fonctionnement)

L’ensemble de ces indicateurs permettent d’assurer une supervision opérationnelle relativement exhaustive, sans trop se disperser dans des interrogations moins critiques.

Ces scripts shell de type BourneShell/BASH sont disponibles dans la section téléchargement. D’autre part, EMC fournit dans le CLI Guide de VPlex tout le détail de cette méthode d’interrogation, avec des exemples et des cas pratiques (EMC VPlex CLI Guide P/N 300-012-311, chapitre VPLEX Element Manager API).

Sachez enfin qu’il est également possible de modifier la configuration du VPlex par ces API (à la manière de naviseccli pour les environnements Clariion/VNX). Ceci étant, à mon sens, leur utilisation ne doit être réservée qu’à des opérations très particulières, notamment lors du provisionning initial, pour de l’automatisation, par exemple.