Rogue LUN : an ESXi and VPlex story

Désolé pour le titre un peu “putaclic”, mais comme le trailer officiel de Rogue One, a Starwars story est sorti hier, je me devais, en bon geek quarantenaire, de caser une référence quelconque dans un de mes billets. Donc, comme on dit, ça c’est fait :)

Voici donc une saga pas banale qui nous est arrivé ces derniers jours sur notre environnement test & dev (ouf !), sur lequel j’ai passé plusieurs jours avec l’aide du support Dell|EMC, mais sans pour autant – pour l’instant, tout du moins – avoir trouvé la root-cause. L’histoire en question commence il y a quelques mois, dans une ferme bac à sable lointaine, très lointaine …

C’est que le début…

Nous sommes en Mai 2016 et tout se passe bien pour notre BAS (Bac A Sable), le cluster est en vCenter 6.0u2 et les ESXi viennent d’être upgradés en 6.0u1 avec au dessus un joli vCloud Director 6.10, secondé par un NSX Manager en 6.2.2. Bref, tout roule.

Et puis, subitement, à partir de début juin, je constate au gré de mes nombreux mini-PoC, des erreurs de connectivité sur certains datastores. Le message est relativement obscure mais n’en demeure pas moins inquiétant, même s’il n’y a a priori aucun impact visible sur les VM hébergées par ce cluster (en apparence du moins, ce ne sont pas des machines très sollicitées) :

Vous remarquez que la perte de connexion et la reconnexion se passent dans la même seconde, autant dire que cela sent, au premier abord, des erreurs plutôt FibreChannel : erreur de transmissions, erreurs SFP ou autre. Pourtant, après contrôle, rien de tout cela, aucun problème sur notre réseau FC. Rien non plus sur notre VPlex, tout est au vert. Bon, après tout, c’est du bac à sable, s’il n’y a pas d’impact, ce n’est pas si grave, je verrai cela plus tard, me dis-je promptement (les informaticiens sont des flemmards, vous savez bien ^^).

D’accord, d’accord …

Sauf que, l’été se passe et à la rentrée, nous avons besoin de la puissance de ce cluster pour un gros environnement de pré-production. Nous réactivons toutes les VM concernées. Au bout de quelques jours on reçoit des infos de “grosses lenteurs” sur ces machines, issues des personnes utilisatrices de ces machines. Retour en mode investigation, plus poussée cette fois, mais comme en Juin dernier, nous ne trouvons rien dans les logs des autres éléments de la chaine (FC, VPlex, baies back-end). En désespoir de cause, nous réinstallons complètement l’ensemble des ESXi avec tous les derniers patchs et relançons l’environnement.

Quelques jours plus tard, cette fois-ci, plus grave encore, nous venons de perdre un des datastores hébergeant les VMs ! Même si ce n’est pas à proprement parler de la production, c’est tout de même fortement inquiétant, d’autant plus que je vois désormais arriver ce type d’alerte sur les environnements de TEST (autre cluster, autre vCenter) !

A la recherche de la LUN perdue

Précisément, depuis le plantage, les chemins FibreChannel de la LUN perdue sont marqués comme “Dead” sur l’ensemble des ESXi de notre cluster BAS. Impossible de réactiver ces LUNs. Nous avons quasi tout essayé :
– Rescans, reboot unitaires des ESXi, pas mieux
– réinstall en ESXi 5.5 d’une des machines pour voir si ça venait d’un pb de driver quelconque, pas mieux
– suppression de la storage-view “bac à sable” du virtual volume et reboot de tous les ESXi, puis enfin réintégration, pas mieux

Là, ça commence à se corser sévère et plutôt que de perdre du temps, j’ouvre un call chez EMC car j’imagine que peut-être le souci vient de VPlex (même si aucune alerte n’apparaît dans les logs de celui-ci). Je vous la fait assez courte, mais malgré plusieurs jours d’épluchage de logs et escalade aux experts VMware et VPlex, rien de vraiment concluant ne sort pour cette histoire de LUN. Par contre, le dossier étant également ouvert pour les soucis de connectivité repérés il y a déjà plusieurs semaines, on trouve finalement qu’un de nos hyperviseurs membre du cluster a une carte HBA défaillante et génère des tonnes de SCSI reset, provoquant par effet collatéral des problèmes de connexion au directeur VPlex. Il aura donc suffit de sortir ce serveur et lui couper ses ports FC pour retrouver une situation nominale de ce coté là.

Et la LUN alors ? le coté obscure gagne ou pas ?

Finalement, n’en pouvant plus, je décide de supprimer complètement toutes les déclarations du VPlex (virtual volume, device, extent) pour ne conserver que le “claim” de la LUN, puis je reconstruis tout ça et re-présente le volume aux ESXi. Au passage un grand merci à Xavier sur twitter qui a partagé sa propre expérience d’un cas similaire et m’a convaincu que c’était une option radicale, mais qui semblait avoir de bonne chances de réussir :

Et là, Ô miracle ! les chemins d’accès à la LUN repassent au vert ! Par contre, le datastore formatté en VMFS 5.0 ne remonte toujours pas. En fait, les ESXi le voient comme un snapshot (effectivement, son UID ayant changée lors de la reconstruction du virtual volume, ça parait logique). Il aura donc fallu quelques manipulations complémentaires (re-signature) pour récupérer entièrement notre datastore perdu.

Voici pour votre culture, les commandes passées pour récupérer le vmfs :

Au final, on a tout récupéré et quelques jours plus tard, le cluster est toujours aussi stable. De plus, les erreurs de connectivité ont quasi disparu. Tout n’est pas rose pour autant car il reste encore à trouver la root-cause de la “LUN brûlée” et pour l’instant, il y a peu de pistes sérieuses.

Avez-vous déjà été confronté à ce type de problème de votre coté, quelle que soit la conf SAN derrière, VPlex ou non ?