HP VSA on Zwindler's Reflection

Superviser des appliances HPE StoreVirtual VSA (LeftHand) avec Nagios/Centron/Shinken

Tue, 08 Jan 2019 12:45:34 +0000

Superviser des Lefthand ?

Dans une vie antérieure (article dans mes tiroirs depuis fin 2015 a priori XD), j’ai eu à gérer, on premise, du stockage hautement disponible HPE VSA pour mes clusters VMware.

Si vous êtes ici, c’est sûrement parce que vous aussi, vous avez acheté des LeftHand (StoreVirtual P4000) et/ou des HPE VSA, et que vous voulez les superviser.

La plupart des tâches d’administration se font depuis la CMC (Centralized Management Console), mais clairement ce n’est pas hyper pratique. La section 7 du manuel StoreVirtual traite de la supervision en général : h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c04581885-1.pdf (lien mort, pas sauvegardé par Internet Archive).

Heureusement, la documentation explicite clairement qu’il est possible d’activer SNMP pour externaliser tout ça.

A noter, je n’ai pas pu m’empêcher de glousser en lisant cette petit phrase dans un manuel d’administration un peu plus ancien, qui dit que vous ne pouvez pas changer, ni même supprimer (#Sécurité), les communautés par défaut :

Section 7 du manuel d’administration http://www.hp.com/ctg/Manual/c01865545.pdf

Nagios / Centreon / Shinken

Pour superviser mes machines dans mes DC « on-premise », j’utilisais Centreon. Tout naturellement je me suis tourné vers Nagios Exchange pour voir s’il n’y avait pas déjà des gens qui avaient fait le travail.

2 plugins ont attirés mon attention :

Prérequis

Le plus récent et le plus téléchargé, check_lhc, nécessite le téléchargement de MIB. Je les avaient trouvé sur circitor (ex. www.circitor.fr/Mibs/Html/L/LEFTHAND-NETWORKS-NUS-COMMON-CLUSTERING-MIB.php), puis de les déposer dans votre serveur Nagios/Centreon/Shinken

/usr/share/snmp/mibs/

J’avais également trouvé des ressources sur le site d’HPE, mais comme ils passent leur temps à le refaire les 3 liens que j’avais sauvegardés sont maintenant HS. Voilà voilà.

En gros, ce que ça disait, c’est que les MIB sont contenues dans l’installeur, celui qui est utilisé pour instancier les VSA la première fois.

Fallait le savoir…

Configurer SNMP

Comme les deux plugins utilisent SNMP, on va… l’activer. #ThanksCaptainObvious.

Depuis la CMC, on peut donc configurer nos StoreVirtual pour qu’elles acceptent des connexions SNMP et configurer une communauté (voir le manuel d’admin, page 93). Clairement, ce n’est pas sorcier.

Dans le Management Group, on a un menu Event, dans lequel on peut configurer un serveur SMTP (pratique pour recevoir les mails qui m’informe que mon cluster est à plat et que mes données sont définitivement corrompues et que je peux aller pointer à Paul Emploi).

Et, SNMP.

Checker

Maintenant que vous avez activé SNMP (avec une communauté bien complexe, readonly et des restrictions IP à vos seuls serveurs de supervision, on est d’accord), on peut voir si ça marche.

Personnellement j’ai préféré check_lefthand, car la doc est plus fournie et les options plus nombreuses .

./check_lefthand.pl -H 10.10.10.16 -C hyperdifficultcommunity
Cowardly exiting, not instructed to check anything!
check_lefthand.pl -H -C [-t timeout] [-p port]
Additional Options:
--module-space
report the available space on each 'module' within a management group
--module-status
report on the various status elements for each 'module' within a management group
--volume-space
report the available space on each volume within a management group
--volume-status
report on the various status elements for each volume within a management group
--cluster-space
report the available space for each cluster within a management group
--cluster-status
report the status of each cluster within a management group

Les deux alertes que j’ai mises en place sont l’état du clusters, et le status de mes volumes (synchronisés ou pas entre les 2 salles).

centreon$ ./check_lefthand.pl -H 10.10.10.16 -C hyperdifficultcommunity --cluster-status
OK - mgmt group: MyAwesomeHPVSA 5/5 Cluster Managers Active.
centreon$ ./check_lefthand.pl -H 10.10.10.16 -C public --volume-status
OK - mgmt group: MyAwesomeHPVSA 4 Volumes with valid replication and Data Protection.

A noter, tout n’est pas parfait. Dans certains cas, j’ai remarqué que l’alerte ne se déclenchait pas quand des nœuds étaient DOWN, car le compteur « total » de nœuds décrémentait en même temps que les nœuds tombaient (ce qui est très bête…).

Mais c’est quand même un début :)

Bonus : Rage

Ouais, je sais…HPE VSA (maintenant HPe StoreVirtual VSA), quoi. L’alternative « géniale » de HPE à VSAN.

Ne me blâmez pas… A l’époque, on m’avait donné le choix entre 2 appliances physiques NetApps plus chères et même pas hautement disponibles (actif/passif) et donc les fameuses HPE VSA Storevirtual. Et puis sur le papier, ça paraissait robuste. C’est basé sur un produit éprouvé, les Lefthands (appliances physiques) et un OS Linux.

What could go wrong?

Maintenant que je ne m’en occupe plus, je peux dire que c’est grâce à ce superbe outil que j’aurai fais un week end non-stop quasiment sans dormir au téléphone avec des techs HPE et VMware de tout autour du monde (mais je me suis fait payer plus de 25 heures d’astreinte #youpi) parce que les nœuds tombaient les uns après les autres sans raison apparente.

Pour les curieux, c’était un problème de hotspare qui se mettait en veille et bloquaient les nodes, les uns après les autres, dès qu’une commande « refresh storage usage » était lancée par l’ESXi (automatique ou manuel).

C’est aussi mon record personnel du ticket support le plus longtemps, tout constructeur/éditeur confondu. Les chiffres sont impressionnants :

un mois pour trouver un workaround (désactiver les hotspares, #genious)
plus de 200 emails
5 mises à jours (dont 4 inutiles)
3 interventions le soir sur la prod
Et last but not least : 2 ans pour trouver le fix (alors que le problème était détecté puisqu’on savait qu’il suffisait de désactiver les hotspares).

DEUX… ANS…

Au final, je ne suis même pas vraiment sûr que le problème soit fixé.

Je ne suis plus sûr de rien, à part du niveau de compétence de HPE sur le sujet des serveurs et du stockage.

Mais qui peut les blâmer, ce n’est pas leur cœur de métier après tout. #ohwait

Mise à jour HP VSA StoreVirtual : site FTP HP.COM hors service

Tue, 21 Feb 2017 13:00:36 +0000

Ma CMC pour HP StoreVirtual ou VSA ne parvient plus à accéder aux mises à jours !

Aaaah, ça faisait longtemps que je n’avais pas dis tout le bien que je pensais d’HPe et notamment d’HP VSA. Mais l’actualité m’a poussé, entre autres choses, à relancer des projets en stand-by.

Note : pour ceux qui ne sauraient pas de quoi je parle, je pense au rachat Simplivity par HPE pour 650 M$ le mois dernier. Racheter le n°2 lorsqu’on a un produit maison envoie un signal clair à tous ceux qui ont investit dans HP VSA => dommage pour vous !

Aujourd’hui, nous avons un cluster HP VSA qui nécessite un petit upgrade avec l’ajout de 2 nœuds supplémentaires. Histoire de faire les choses bien, j’ai voulu m’assurer que les nœuds étaient correctement à jour et quelle n’a pas été ma surprise quand j’ai découvert que la console n’arrivait même plus à contacter le serveur contenant les mises à jour !

Où sont ces mises à jours ?

Pour simplifier le processus de mise à jour des nœuds StoreVirtual, on utilise la console centralisée CMC -qui peut être installée sur un Linux ou un Windows-. Cette console a l’avantage de servir de pivot pour télécharger les patchs depuis un seul et même endroit (dans mon cas, un serveur Windows).

Dans ce cas-là, c’est bien le client (CMC) qui réalise le téléchargement, pas les serveurs VSA.

Et depuis quelques semaines (mois?), visiblement ça ne marche plus, avec un message qui laisse penser (à tort!) à un souci de connectivité Internet entre mon serveur Windows et les serveurs d’HP.

Une partie de la réponse se trouve dans ce post du forum de la communauté HPE.

Check your upgrades.xml file in the download folder. One of the updates from HP added an incorrect FTP address to the top of the section.

En allant fouiller dans le dossier d’installation de la console CMC, j’ai vite compris le problème. Les URLs contenues dans le fichier upgrades.xml pointent vers un FTP hébergé par hp.com.

J’insiste sur HP car il faut bien faire la distinction entre HP et HPe, la société HP ayant effectué sa scission entre Hewlett Packard et HPe l’an dernier. Le client CMC avait d’ailleurs été mis à jour entre la 12.5 et la 12.6 pour retirer toutes les références et les images HP pour les remplacer par la charte graphique HPe !

C:\Program Files (x86)\HP\StoreVirtual\UI\downloads\upgrades.xml
[...]
<DownloadURLs>
<URL>ftp://ftp:cmcdnlds@ftp.hp.com/pub/hp_LeftHandOS/</URL>
[...]

Pour vérifier mon intuition, je suis allé directement parcourir le FTP et effectivement, il n’y a plus de dossier hp_LeftHandOS sur ce FTP.

HPe a donc migré tout simplement son FTP vers le site d’HPe et le client ne peut juste pas se mettre à jour…

… Mais ils n’ont pas mis à jour le client pour qu’il pointe sur HPe au moment de la mise à jour 12.5 vers 12.6 quand ils ont changé la charte graphique.

Non non. Ils ont migré leur FTP après.

Résolution

Le problème est fort heureusement simple à résoudre. Il suffit d’aller chercher la dernière version de la CMC sur le site d’HPe.

Fermez la CMC, allez chercher la dernière version (lien mort, pas disponible sur Internet Archive) et installez la.

Bon à date l’URL de téléchargement que je vous donne est bonne mais avec HPe on est jamais trop sûr que ça dure donc vous m’excuserez si le lien est cassé à l’avenir ;-).

Une fois installée, la nouvelle version devrait maintenant se connecter sur le bon site.

Pour information, la connexion se fait même maintenant en HTTPS et non plus en FTP, comme on peut le constater dans le fichier upgrades.xml.

[...]
<DownloadURLs>
<URL>https://downloads.hpe.com/pub/StoreVirtual/CMC/</URL>
[...]

Comme quoi, il n’y avait vraiment aucune chance que ça fonctionne avant mise à jour…

Erreur hpssaduesxi et esxcli depuis vSphere 6

Sat, 30 Jan 2016 14:00:16 +0000

Contexte

J’ai eu une petite mésaventure avec mes amis d’HP lors d’un incident sur une plateforme HP VSA storeVirtual et j’ai perdu pas mal de temps avec l’utilitaire hpssaduesxi qui ne fonctionnait pas.

Rapidement pour ceux qui ne savent pas de quoi il s’agit, c’est le pendant virtuel de la solution de virtualisation du stockage HP LeftHand (appliances physiques).

Vos nœuds de compute (hyperviseurs) ESXi ou Hyper-V distribuent la totalité du stockage interne ou DAS (ou autre) à une machine virtuelle (HP VSA, 1 pour chaque serveur). Elles se coordonnent ensuite en cluster pour vous fournir un espace de stockage réparti sur tous vos serveurs. Cela permet entre autre d’obtenir à moindre cout du stockage hautement disponible et scalable.

Je reviendrais peut être là dessus dans un autre article.

hpssaduesxi, esxcli et vSphere 6

Comme je le dis en introduction, j’ai eu incident lié au stockage après l’intégration de ma plateforme HP VSA et j’ai donc du ouvrir un ticket auprès de mon support HP.

Sans surprise, la première chose qu’on m’a demandé de faire pour pouvoir traiter ma demande était de collecter les logs de la carte RAID des serveurs ESXi concernés (rapport ADU de son petit nom). Si vous êtes familier des serveurs HP, vous savez qu’un des moyens de récupérer ces informations est de lancer l’utilitaire hpssadu, présent sur les différents OS lorsque vous installez les pilotes HP Smart Storage.

Dans mon cas, on m’a demandé de réaliser cet extrait de configuration et de logs à partir d’un serveur Microsoft ayant accès aux serveurs et la CLI VMware d’installée.

Ok, pas de soucis, le technicien me donne la procédure. J’installe la dernière version de la CLI trouvée sur le site de VMware (lien mort, comme tout chez VMware), j’installe le « HP Smart Storage Administrator Diagnostic Utility (HP SSADU) CLI« .

Anecdote amusante : le technicien HP me donne le lien pour la CLI VMware, mais pas le lien pour le logiciel de sa propre entreprise… Et quand on connait un peu les méandres du site d’HP (surtout en pleine scission Hewlett Parkard vs HPe) c’est très drôle. Peut être que lui non plus ne sait pas où il est ? Pour vous éviter des sueurs froides et des accès de rage, il est ici.

L’étape d’après consiste à installer la CLI, PUIS de copier le binaire hpssaduesxi.exe dans le dossier C:\Program Files (x86)\VMware\VMware vSphere CLI\bin (installation par défaut de la CLI vSphere). A quoi bon l’installer alors, si c’est pour le copier à la main ? Mais bon, passons ces détails insignifiants ;-). **
**

Et c’est bon, le technicien est formel, ça devrait marcher maintenant : vous pouvez extraire votre rapport ADU en tapant la commande suivante dans un prompt (cmd ou PowerShell) dans le bon dossier.

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin> hpssaduesxi.exe --server=[ip_serveur] --user=root --password=[password] report.zip

Coup de théâtre : ça ne fonctionne pas.

Retrieving report...
HPSSADUESXI requires the use of the vSphere CLI (esxcli) client
application. Make certain that this client has been installed
and is available from this directory. If vSphere CLI has been
installed, check the correctness of the inputted parameters.

Mieux, aucun des techniciens que j’ai eu chez HP ne savait pourquoi. Le niveau 1 je peux comprendre. Mais le plateau entier de niveau 2 ?

A force de perdre du temps, j’ai essayé de générer le rapport ADU directement sur les ESXi.

Mais bien sûr, ça ne fonctionne pas. C’est la raison pour laquelle le rapport ADU doit être généré sur un serveur Windows depuis hpssaduesxi.exe.

Solution

En fait, sans trop de surprises, hpssaduesxi n’est qu’une surcouche à esxcli. Et du coup l’erreur est tout de suite apparue lorsque j’ai essayé simplement de me connecter en esxcli aux serveurs VMware.

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin> esxcli.exe --server=[ip_serveur] --user=root --password=[password]
Connect to [ip_serveur] failed. Server SHA-1 thumbprint: BD:F9:D9:40:35:77:E9:AA:8F:BC:04:42:97:AA:A7:4E:AA:E5:BB:4D (not trusted).

Le problème vient du fait que depuis la version 6, VMware a renforcé la sécurité et qu’on ne peut plus « ignorer » les certificats qui ne sont pas acceptés. Tout est expliqué ici (lien mort, comme tout chez VMware).

Le site de VMware donne plusieurs solutions, notamment celle d’ajouter le certificat du vCenter comme autorité de certification dans le serveur Windows. Je n’ai malheureusement pas réussi à faire fonctionner cette solution, qui est pourtant selon moi la meilleure.

En revanche, j’ai réussi à faire fonctionner esxcli et par conséquent hpssaducli en ajoutant l’empreinte SHA-1 de mes serveurs ESXi dans le « credstore », à l’aide de la commande suivante sur le serveur Windows :

C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\apps\general> credstore_admin.pl add --server [ip_serveur] --thumbprint BD:F9:D9:40:35:77:E9:AA:8F:BC:04:42:97:AA:A7:4E:AA:E5:BB:4D
PS C:\Program Files (x86)\VMware\VMware vSphere CLI\bin> .\hpssaduesxi.exe --server=[ip_serveur] --user=root --password=[mdp] report_esxi.zip
Retrieving report... Decoding... report_esxi.zip saved.

Mot de la fin

Je suis vraiment dépité que personne chez HP ne se soit posé la question de l’impact que ça avait sur leur binaire et que personne n’ait mis à jour la documentation fournie au support pour indiquer la marche à suivre en cas d’erreur !

J’espère être mal tombé et que ce problème est connu chez HP, car le fait que ça ait été à moi de leur trouver la réponse me dépasse…