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.

Il faut avoir à l’esprit qu’en général, les setups de ce type doivent être conçus pour privilégier obligatoirement les chemins “les plus courts” ou en tout cas les chemins vers le VPlex local, pour éviter de solliciter les liaisons WAN. Appliqué aux hyperviseurs ESXi de VMWare, la tâche n’est pas forcément simple à réaliser, en particulier si vous n’utilisez pas PowerPath/VE. En effet, de manière empirique, le seul moyen “simple” est d’effectuer cette opération via l’interface vCenter… vous en avez pour des jours de travail ;)

Au sein de notre infrastructure, nous avons choisir le driver VMWare “Fixed Path”, qui utilise en priorité un chemin et revient automatiquement dessus après une indisponibilité temporaire de celui-ci et une bascule sur les chemins restants. Pour pouvoir sélectionner correctement les chemins locaux, nous avons conçu une batterie de scripts shell, utilisé au sein d’une machine de type VMWare VMA. Le principe est de monter la machine ESXi, lui présenter les volumes VPlex via les deux clusters, puis enfin, de parcourir tous les volumes un par un, sélectionner “le bon chemin” et le fixer.

On utilise pour cela, comme souvent, la commande esxcli comme suit :

La variable $naa doit contenir l’identifiant NAA du volume à traiter. Le chemin par défaut est indiqué dans la variable $setdefpath, et prend une valeur du type “vmhba2:C0:T1:L36” par exemple. Certes, difficile de savoir a priori quelle valeur indiquer : c’est pour cela qu’il faut scripter pour récupérer la “bonne valeur” à positionner. La solution que nous avons trouvé consiste à se baser sur les WWN des directeurs de chaque VPlex. Dans notre cas, chaque directeur est accessible via un WWN dont le “suffixe” est spécifique et dont on a repéré la localisation:

Les directeurs 1-1 sont ceux de notre salle 1, les 2-1 étant ceux de notre salle 2. Au final, voici l’algorithme simplifié qui permet de positionner la bonne valeur de “default path” sur la commande esxcli :

1. On récupère la liste des volumes et leur NAA via une commande esxcfg-scsidevs
2. Pour chaque volume (NAA), on récupère le chemin actuel via une commande esxcli
3. Pour chaque volume, on récupère le “bon chemin” vers le bon directeur, via une commande esxcfg-mpath
4. Et enfin, on positionne le nouveau chemin FC par défaut (fixed) via la commande présentée plus haut

Vous comprenez facilement qu’il faut user et abuser des boucles, car cette opération doit être réalisé pour CHAQUE volume et ce sur CHAQUE serveur de votre ferme. Voici une “session” permettant de positionner un seul chemin d’un seul volume, manuellement :

Vous noterez ici que le volume “aa.6000144000000010200c338525b5e6ad” dispose d’un total de 8 chemins logiques, répartis sur 2 fabric et deux clusters VPlex (4 directeurs, 2 chemins par directeur, 1 lien physique par fabric). Pour l’instant, le chemin par défaut “préféré” de ce volume est le vmhba5:C0:T1:L3, et c’est aussi celui actuellement utilisé (en nomminal donc). Imaginons que le serveur en question soit situé sur le même site que le cluster dont les directeurs sont respectivement Directeur 1-1-A (suffixe 800c3300) et Directeur 1-1-B (suffixe 800c3301). On remarque qu’actuellement, le chemin par défaut pointe sur le directeur 2-1-A, sur l’autre salle. Pour positionner correctement le chemin par défaut sur un des directeurs de la salle 1, il faut donc placer l’ordre suivant :

Ici, nous avons donc choisi le directeur 1-1-A.

A noter également que vous pouvez par ce biais équilibrer la charge des directeurs d’un même cluster VPlex, en précisant alternativement chaque directeur, en fonction des serveurs et des volumes.

Si vous souhaitez plus de précision concernant les scripts que nous avons mis en oeuvre pour automatiser ces process de sélection, vous pouvez me contacter directement par email (section “Qui suis-je ?”)