Photo-2014-06-10-11-05-42_5420

Scripts de gestion des chemins FC sous ESXi avec VPlex

English sum-up :
Some shell scripts to statically select a preferred path within all FC paths availables on an ESXi connected via VPlex metro.

MAJ 30 Novembre 2014 : quelques corrections de bug dans les scripts (test de connexion notamment).

Je vous en avais parlé il y a quelques mois (voir ce billet), nous n’utilisons pas – encore – PowerPath VE pour nos serveurs ESXi et nous travaillons donc avec le MPIO intégré en mode “Fixed/Preferred” de VMWare. Pour le coup, cela nous oblige à sélectionner “à la main” des chemins préférés correspondant bien au cluster local de chaque ESXi dans notre infra VPlex Metro. Pour plus de précision à ce sujet, je vous renvoie une seconde fois au billet précédent sur ce sujet.

Nos scripts historiques étaient certes très précis et fonctionnaient bien, mais il leur manquait une qualité importante : la vitesse ! En effet, pour parcourir l’ensemble des devices FC d’un ESXi, vérifier les chemins préférés et les modifier éventuellement, cela prenait du temps… beaucoup de temps, via les commandes esxcfg-XXX et esxcli. Désormais, il n’est pas rare d’avoir, pour un ESXi donné, quasiment une centaine de devices différents. Au final, cela représentait des heures de parcours sur l’ensemble de nos machines.

Il fallait accélérer tout cela et c’est désormais chose faite ! Vous allez le voir dans la suite, les nouveaux “turbo-scripts” sont beaucoup plus rapides (une à deux minutes par serveur disposant de plusieurs dizaines de device), mais il a fallut sacrifier un peu les tests préalables et l’inspection de chaque device, l’un après l’autre. La nouvelle méthode traite tous les devices en une seule fois, sans vérifier si toutes les commandes sont couronnées de succès. Ceci étant, l’expérience nous a montré que dans l’ensemble, toute cette mécanique fonctionnait globalement très bien et de manière fiable. La confiance aidant, voici donc le résultat : des scripts simples, efficaces, rapides et directement “publiables” sur ce blog car extrèmement génériques (contrairement aux précédents).

Lire la suite …

ram-chart

VPlex et Cross-connect : bien choisir son chemin

Une des fonctions phare de VPlex Metro est la disponibilité en lecture ET écriture de l’ensemble des volumes distribués sur les deux (ou plus) clusters ainsi configurés. Cela permet d’assurer une disponibilité maximum des volumes pour tous les serveurs, où qu’ils soient servis. Ceci étant, on zone traditionnellement un serveur situé dans une salle informatique sur le VPlex “local” situé dans celle-ci. Deux avantages : les liaisons inter-site ne sont pas sollicitées par des accès front-end et la latence des liens est également plus réduite.

Ceci étant, en cas d’indisponibilité totale d’un des clusters VPlex, suite à une grosse panne matérielle ou un dégât localisé quelconque, même si le reste des DC est intact, tous les serveurs connectés à ce cluster vont perdre leurs accès stockage. Dommage de ne dépendre que d’un des clusters, sachant que l’autre fonctionne encore et que les liaisons inter-site sont encore opérationnelles.

C’est là qu’intervient la fonctionnalité “Cross-connect”. En fait de fonctionnalité, c’est juste un paramétrage particulier auquel EMC à choisit de donner un nom, car dans la pratique, il ne s’agit que de “zoner” les serveurs d’un site sur les deux VPlex, plutôt qu’un seul. En théorie, aucun problème, vous récupérez de facto des chemins FC supplémentaires qui sont visibles et utilisables par le serveur. Dans la pratique, c’est plus compliqué, comme nous allons le voir.

Lire la suite …

ram-chart

Accélerer le boot de vos ESXi 5.x (maj)

MAJ du 14/05/2013 : petite précision sur les locks SCSI associés.

Si vous utilisez beaucoup les Raw Device Mappings, ou RDM dans le jargon VMWare, vous avez sans doute noté un ralentissement notoire de vos ESXi lors de reboot pour maintenance ou mises à jour diverses. En fait, ce ralentissement est dû au polling de toutes les LUNs RDM, notamment pour détecter d’éventuels VMFS, qui peut être ralenti à cause de locks SCSI (notamment les RDM utilisés par des clusters MSCS).

Lire la suite …