Credstore_admin.pl on Zwindler's Reflection

Erreur multipath « Path not correctly configured for failover »

Wed, 24 May 2017 14:15:45 +0000

Path not correctly configured for failover

Il y a quelque temps, nous avons du décommissionner une vieille baie HP EVA (qui nous coutait plus cher en maintenance que d’acquérir une baie neuve) et migrer les LUNs vers une baie EMC VNX, elle encore sous maintenance. Cependant, lorsque la migration a été faite, le consultant qui s’est chargé de reconfigurer multipath pour migrer d’une baie à l’autre l’a un peu fait « rapidement ».

Quelques mois plus tard, lors d’une maintenance classique sur une des baies EMC, de grosses anomalies ont été détectés. Lors de la coupure d’un contrôleur pour mise à jour, certains serveurs hébergeant une partie de nos progiciels, encore sous Redhat 4, se bloquaient au niveau I/O au lieu de basculer sur les chemins encore disponibles. L’occasion rêvée pour refaire un peu de multipath !

Dans cet article, je vais donc passer en revue quelques unes des erreurs que j’ai pu rencontrer, et comment les corriger.

Liloo Dallas Multipath ?

D’abord un bref rappel.

Pour ceux qui ne connaissent pas multipath, il s’agit d’un module de Linux qui permet de gérer les chemins multiples vers une même disque. On l’utilise sur des réseaux de stockage d’entreprises qui disposent de plusieurs niveaux de tolérance aux pannes.

Chacun des chemins SAN menant à un même disque (LUN A sur le schéma ci dessus) sont indexés côté OS par leur propre special device du type /dev/sd[n] (4 chemins : sde, sdf, sdg et sdh dans l’exemple).

On ne peut pas directement les utiliser puisqu’on utiliserait dans ce cas là qu’un seul des chemins disponibles. Et écrire en direct sur 2 chemins menant vers un même disque en même temps serait catastrophique.

Heureusement, Multipath détecte de lui même (via l’UUID du disque) que les chemins sont en fait un même périphérique et créé pour nous un fichier spécial /dev/dm-[n] qui permet de pointer vers le disque via l’ensemble de ses chemins.

Vérifier le plus évident

Initialement, l’anomalie n’était pas visible car les vérifications de l’état de multipath n’avaient été faites qu’avec le niveau de détail standard : les chemins sont bien déclarés, visibles et fonctionnels… RAS de ce côté.

# multipath -l
mpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active]
\_ 1:0:5:3 sdh 8:112 [active]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active]
\_ 1:0:4:3 sdg 8:96 [active]
[…]

De même les modules multipath étaient bien chargés dans le kernel :

# lsmod |grep dm
dm_mirror 32585 0
dm_round_robin 5185 1
dm_emc 7745 1
dm_multipath 22865 3 dm_round_robin,dm_emc
dm_mod 76585 7 dm_mirror,dm_multipath

Cependant, le démon multipathd qui permet de gérer les bascules de chemins est lui hors service…

# service multipathd status
multipathd est arrêté

ATTENTION : Le démarrage du démon multipath peut éventuellement provoquer une coupure des chemins, ce qui va planter le serveur et les traitements en cours. Il faut donc bien prendre garde que le serveur ne soit pas utilisé lors de son activation.

chkconfig multipathd on
chkconfig --add multipathd

Doublons dans les user-friendly device names

Une fois les problèmes basiques réglés, nous avons remarqué que le consultant en question ne s’était pas trop embêté avec les user-friendly names. Voici ce que la commande suivante renvoyait :

# multipath -v2
remove: mpath9 (dup of mpath2)
mpath9: map in use
remove: mpath23 (dup of mpath2)
mpath23: map in use

Bien que non bloquant, ceci est clairement peu élégant ;-).

Comme je l’explique plus haut, multipath agrège les /dev/sd[n] en un seul et unique /dev/dm-[n]. Cependant, il est déconseillé d’utiliser directement le fichier /dev/dm-[n]. En effet, tout comme les /dev/sd[n] (que ce soit dans le cadre de multipath ou pas d’ailleurs), les fichiers /dev/dm-[n] sont susceptibles de changer au cours de la vie du serveur ! De quoi avoir une mauvaise surprise après maintenance…

Pour résoudre ce problème, plusieurs solutions sont conseillées. Soit on utilise le WWID du disque qui est garanti unique, soit on utilise le device mapper qui transpose ce dm-[n] un user-friendly name du type /dev/mpath[n].

Dans le cas présent, au gré de la migration, les WWID avaient générés plusieurs mpath pour un même disque et il n’y avait plus de cohérence !

Pour régler le problème, le plus simple est de couper toutes les applications, puis d’effacer la configuration (pas les données, hein, juste les chemins et la table de correspondance) pour repartir de zéro. On récupère les WWID de chaque disques, puis on supprime tous les chemins courants avec les commandes suivantes :

multipath -ll #affiche les chemins et leurs informations
multipath -F #flush de tous les chemins enregistrés

Une fois les chemins supprimés, il faut modifier le fichier de configuration /etc/multipath.conf pour y ajouter en fin de fichier la déclaration des WWID à associer à des friendly_names fixés manuellement :

[...]
multipaths {
multipath {
wwid "360060160da302f009cd38abe2f5ee111"
alias mpath0
}
multipath {
wwid "36006016067302f00e458ad06345ee111"
alias mpath2
}
}

En enfin, on peut les réenregistrer à l’aide de la commande :

multipath -v2

Mode ALUA 4/PNR 1 pour les LUNs

Pour autant, la vraie cause de l’anomalie n’a pu être détectée que lorsque le mode de détails supérieur a été utilisé pour afficher les chemins (option -ll). Plusieurs messages d’erreurs relativement explicites se sont affichés, et notamment :

la mention Path not correctly configured for failover
les chemins en « [active][faulty] »

multipath -ll
Path not correctly configured for failover
Path not correctly configured for failover
Path not correctly configured for failover
Path not correctly configured for failover
mpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active][faulty]
\_ 1:0:5:3 sdh 8:112 [active][faulty]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active][faulty]
\_ 1:0:4:3 sdg 8:96 [active][faulty]

Après consultation de ressources en lignes et du « [Host Connectivity Guide for Linux][3] », il apparait que le mode « ALUA 4 actif actif» n’est pas supporté sur les serveurs Redhat Entreprise Linux 4. Il faut utiliser le mode « PNR 1 actif passif» qui lui est bien certifié.

Dans notre cas, c’est pourtant bien ce mode « ALUA 4 » qui avait été déclaré côté baie EMC pour les chemins vers l’hôte. A l’inverse, la configuration qui avait été appliquée côté serveur était bien en mode « PNR 1 ». Il y avait donc une incohérence de ce côté-là.

Changer le mode des LUNs sur une baie VNX

La modification du type de Failover pour un LUN donné peut se faire depuis la console Unisphere mais ce n’est pas évident à trouver !

Une fois connecté, il faut choisir une des baies, ouvrir le menu « Hosts » puis « Host List ». Sélectionner le serveur concerné dans la liste, puis ouvrir l’onglet « Initiators » en bas de page.

Sélectionner un port, puis cliquer sur « Edit », et reconfigurer les 4 chemins.

Valider, et recommencer l’opération autant de fois que nécessaire.

Le mot de la fin

Dans notre cas, beaucoup d’erreurs avaient été faites lors de la configuration des LUNs, de la baie de disques et de multipath. Ça donne donc un bon tour d’horizon des premières choses à vérifier si jamais votre multipath sous Linux fonctionne mal.

Lorsque vous avez comme nous des baies EMC, j’aimerais insister sur le fait que le Host Connectivity Guide for Linux (lien mort, j’utilise Internet Archive) est vraiment un document très important, qui vous aidera à correctement tout configurer. N’hésitez pas à le lire en détail !

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…