VPlex : débloquer un port FC capricieux

A l’occasion d’une upgrade récente de nos VNX, un de nos ports VPlex back-end a décidé de cesser de fonctionner pendant une phase d’upgrade de nos VNX (a priori rien à voir, donc). J’ai tout de suite pensé qu’il était peu vraisemblable que ce soit un problème hardware, car la coïncidence avec la mise à jour semblait plus que troublante. Malgré tout, par sécurité, j’ai d’abord essayé de changer tout le chemin optique vers son switch de raccordement, sans succès.

Voici un petit récit du diagnostic.

J’ai ensuite tenté de changer le port du switch et même le SFP du port du VPlex, toujours sans résultat.

En désespoir de cause, j’ai donc contacté le support EMC pour investigation. Après quelques échanges de principe sur les tests déjà effectués, l’orientation du support semblait uniquement “hardware”, malgré mes rappels de la fameuse “coïncidence” avec l’upgrade de flarecode de nos VNX. Ne trouvant rien, le support a fini par conclure qu’une petite visite sur site d’un des “locaux” d’EMC Nantes serait de bon aloi ;)

Je vous passe les diag complémentaires réalisés sur site, qui ont bien confirmé qu’il ne s’agissait sûrement pas d’un problème hardware. Au final, nous en étions rendu à envisager un reboot du directeur concerné, opération lourde évidemment. Mais c’était sans compter sur l’expérience de Pierre-Eric (l’ingénieur EMC sur place) qui, lorsque j’évoquais “mais, il n’y a pas une petite commande sur VPlex pour tout simplement resetter le port, comme un port disable/enable sur un switch FC Brocade ??” me répond un “mais ouais !” franc et massif :)

Et – ô miracle – cette commande simplissime a permis de résoudre notre problème ! Il suffit d’utiliser la commande set enabled <true|false> sur le port bloqué. voici la trace de la session VPlexCli.

Tellement facile… vous nous trouvez pas ? En analysant à froid le problème, ce qui a vraisemblablement du se passer c’est que le port du directeur a effectivement vu des tonnes d’erreurs de transmissions liées aux nombreuses bascules de SP (il y en a eu plusieurs au cours de l’upgrade) et qu’il a fini par se bloquer par sécurité. Le seul problème c’est qu’il n’apparaissait pas comme tel dans l’interface VPlexCLI et n’indiquait qu’un insipide “no light/down”.

Comme quoi, avant de déclencher le branle-bas de combat, si vous êtes confronté à ce genre de comportement sur un de vos directeur, un petit “disable/enable” sur le port devrait être la première action à réaliser ;)

Merci à Pierre-Eric d’EMC pour son aide fructueuse !