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 :
|
1 2 3 4 5 6 7 8 9 |
getthumbprint=`esxcli --server $srv --username $USER --password $PWD system version get | grep "thumbprint"` if [ $? -eq 1 ]; then echo "Thumbprint introuvable ou impossible de se connecter, Stop" echo "Output : $getthumbprint" exit 1 else thumbprint=`echo $getthumbprint | cut -d ' ' -f 8` echo "Thumbprint $thumbprint / connexion ok" fi |
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 :
|
1 2 3 4 5 6 |
esxcfg-mpath --server machine-esx55 --username root --password ROOTEU -L vmhba1:C2:T0:L0 state:active naa.6848f690ef2a580019114e591975b8d8 vmhba1 2 0 0 NMP active unknown.vmhba1 unknown.2:0 vmhba2:C0:T1:L20 state:active naa.6000144000000010300c3356f0ff79ba vmhba2 0 1 20 NMP active fc.20000024ff4a3aa8:21000024ff4a3aa8 fc.5000144047300c33:50001442900c3300 vmhba2:C0:T1:L21 state:active naa.6000144000000010300c3356f0ff79fe vmhba2 0 1 21 NMP active fc.20000024ff4a3aa8:21000024ff4a3aa8 fc.5000144047300c33:50001442900c3300 vmhba2:C0:T1:L22 state:active naa.6000144000000010300c3356f0ff7a0b vmhba2 0 1 22 NMP active fc.20000024ff4a3aa8:21000024ff4a3aa8 fc.5000144047300c33:50001442900c3300 (...) |
… désormais, sous VMA 6, on obtient ceci :
|
1 2 3 4 5 6 |
esxcfg-mpath --server machine-esx6 --username root --password ROOTEU -L vmhba1:C2:T0:L0 state:active vmhba1:C2:T0:L0 vmhba1 2 0 0 NMP active unknown.vmhba1 unknown.2:0 vmhba2:C0:T3:L0 state:active vmhba2:C0:T3:L0 vmhba2 0 3 0 NMP active fc.vmhba2 fc.5000144047300e28:50001442900e2800 vmhba2:C0:T3:L3 state:active vmhba2:C0:T3:L3 vmhba2 0 3 3 NMP active fc.vmhba2 fc.5000144047300e28:50001442900e2800 vmhba2:C0:T2:L0 state:active vmhba2:C0:T2:L0 vmhba2 0 2 0 NMP active fc.vmhba2 fc.5000144047200e28:50001442800e2800 (...) |
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 :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
. ./include.sh if [ "$2" == "" ]; then echo "USAGE : $0 <serveur> <defaultpathwwn>" exit 0 fi srv=$1 defaultpathwwn=$2 # recuperation du thumbprint # on tente de se connecter sans thumbprint pour recup celui retourne par l'erreur # sioux, non ? getthumbprint=`esxcli --server $srv --username $USER --password $PWD system version get | grep "thumbprint"` if [ $? -eq 1 ]; then echo "Thumbprint introuvable, Stop" echo "Output : $getthumbprint" exit 1 else thumbprint=`echo $getthumbprint | cut -d ' ' -f 8` echo "Thumbprint $thumbprint / connexion ok" fi esxcli -d $thumbprint --server $srv --username $USER --password $PWD storage nmp path list >/tmp/tmpsto$$ nbdev=`cat /tmp/tmpsto$$ | grep -v "^ " | grep -v "^$" | wc -l` echo "Parcours des devices/chemins, total a traiter: $nbdev..." idx=0 ko=0 exec 3>/tmp/tmpmpath$$ done echo "Parcours termine, $idx enregistres" echo "Verification et correction..." exec 3/dev/null 2>&1 if [ $? -eq 0 ]; then if [ "$pref" = "preferred" ]; then echo "$device / via $cpath ($scsitarget) $cur $pref -> OK!" else echo "$device / via $cpath $cur $pref -> /!\\ NOK /!\\" echo "Correction en cours ..." esxcli -d $thumbprint --server $srv --username $USER --password $PWD storage nmp psp fixed deviceconfig set -d $device -p $scsitarget ko=$(( $ko + 1 )) fi fi done echo "Verifications et corrections termines, $ko corrections" # fin rm /tmp/tmpsto$$ rm /tmp/tmpmpath$$ exit 0</defaultpathwwn></serveur> |
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 :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
vi-admin@caladanvma:~/scripts$ sh checkpref6.sh bacassab 800c3300 Thumbprint 2D:38:F0:B4:65:9C:AA:BB:CC:DD:EE:FF:11:22:33:44:55:66:77:88 / connexion ok Parcours des devices/chemins, total a traiter: 25... Parcours termine, 25 enregistres Verification et correction... naa.6000144000000010200c338525b5e630 / via 50001442800c3301 (vmhba2:C0:T1:L0) current preferred -> OK! naa.6000144000000010200e284a9a16ffcb / via 50001442800c3301 (vmhba2:C0:T1:L1) current preferred -> OK! naa.6000144000000010200c338525b5ed71 / via 50001442800c3301 (vmhba2:C0:T1:L2) current preferred -> OK! naa.6000144000000010200e284a9a17024b / via 50001442800c3301 (vmhba2:C0:T1:L3) current -> /!\\ NOK /!\\ Correction en cours ... naa.6000144000000010300c3356f0ff7560 / via 50001442800c3301 (vmhba2:C0:T1:L4) current preferred -> OK! naa.6000144000000010300c3356f0ff84c0 / via 50001442800c3301 (vmhba2:C0:T1:L5) current preferred -> OK! Verifications et corrections termines, 1 corrections |
Comme toujours, n’hésitez pas à commenter si je n’ai pas été clair où si certaines parties sont à optimiser ou faire évoluer :)
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.
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 ;)