Gestion des chemins ESXi : script v2.0 compatible vSphere 6

Les administrateurs VPlex connaissent bien la problématique aujourd’hui en environnement VMWare : comment faire pour sélectionner facilement le chemin FC “le plus adapté” vers le bon directeur pour un device donné (a priori le cluster le plus proche géographiquement). Comme déjà évoqué, il existe une solution toute simple, mais payante (et fort cher …) chez EMC : PowerPath VE. Certes, cet outil permet également d’assurer la répartition de charge dynamique sur les différents liens, mais ce n’est pas forcément nécessaire suivant le type de charge.

Il y a quelques temps déjà (le temps pass vite !), je vous avais proposé un script shell s’appuyant sur les outils disponibles à travers l’appliance VMA 5.5 de VMWare pour réaliser cela automatiquement.

En prévision de notre passage à vSphere 6, dans quelques jours, j’ai donc préparé une nouvelle VMA 6.0 et j’ai logiquement testé la plupart de mes scripts, dont celui évoqué plus haut. Et malheureusement, ce que je pressentais s’est produit : le comportement et les outputs des commandes esxcli/esxcfg et autre ont un peu bougé, rendant certains shells inopérants.

La première chose importante est désormais l’utilisation pour esxcli des “fingerprint” de connexion aux serveurs. Par défaut, esxcli refuse de se connecter à une machine dont il ne connait pas la signature, même si vous donnez le bon user/password. Gage de sécurité, certes, mais aussi source de complexité pour intégrer tout cela rapidement. Pour le coup, je ne me suis pas laissé abattre et j’ai utilisé une astuce pour continuer bravement à “ignorer” ces signatures (je sais ce n’est pas joli joli, mais il y a une échéance forte pour nous et je ne pouvais pas attendre de mettre en place une solution pérenne avec l’intégration de certificats). Si vous souhaitez en savoir plus sur ce nouveau comportement, rendez-vous sur ce KB chez VMWare.

Il se trouve que esxcli est en fait très gentil lorsqu’il refuse de se connecter : il donne le thumbprint de la machine ! Donc, ni une ni deux, il suffit de tenter la première fois, récupérer le thumbprint retourné par la commande et relancer celle-ci avec l’option --thumbprint=SIGNATURE. Accessoirement, cela permet aussi de vérifier que le serveur cible est bien accessible. Voici l’extrait du code shell nécessaire pour gérer la connexion dynamiquement :

Le second problème suite au passage à la nouvelle VMA, c’est la sortie incomplète de la commande esxcfg-mpath lorsque l’on interroge un ESXi 6. Jusqu’en ESXi 5.5, on obtient ce type de sortie :

… désormais, sous VMA 6, on obtient ceci :

Le device id n’est plus indiqué, la sortie est même de mon point de vue buggée dans le sens ou on a deux infos redondantes. Or, je me servais précisément des deux informations scsitarget ET device pour pouvoir faire le rapprochement avec les chemins FC. Il a donc fallu revoir entièrement le process de traitement des chemins.

D’une manière générale, la philosophie reste exactement la même (vous pouvez donc reprendre les explications du premier billet), mais on utilise une autre méthode. Il se trouve qu’après cogitation, la nouvelle version est encore plus rapide que la précédente et, de plus, je n’utilise plus que esxcli.

Voici le code :

Vous noterez que le script contient deux passes : une passe de récolte des informations et une passe d’analyse et de correction au besoin. Le temps de parcours est globalement beaucoup plus rapide car on ne modifie le chemin que s’il est incorrect, alors que dans la précédente version, on le faisait systématiquement pour les devices cibles. Cela réduit les requêtes aux serveurs et fait gagner beaucoup de temps puisqu’on ne déclenche que 2+n commandes esxcli, n étant le nombre de chemins à corriger (les deux premières incompressibles correspondent à l’obtention du fingerprint et la récupération de la liste des devices).

Voici une sortie “typique” de ce script :

Comme toujours, n’hésitez pas à commenter si je n’ai pas été clair où si certaines parties sont à optimiser ou faire évoluer :)

2 thoughts on “Gestion des chemins ESXi : script v2.0 compatible vSphere 6

  1. Gaël says:

    On a réalisé le même type de script en PowerCli pour un cluster vSphere 5.1.

    J’espère qu’on ne devra pas reprendre nos scripts pour le passage en 6.0.

  2. Cédric Cédric says:

    Bonjour Gaël,

    Vous pourriez me donner votre script pour que je puisse le mettre à disposition de tous ? Ca intéressera sûrement nombre de lecteurs ;)

Laisser un commentaire

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