Rappelez-vous, il y a quelques jours, je vous racontais l’histoire de notre gros incident avec VPlex. Pour résumer, il s’est produit lors d’un phase de provisionnement de LUNs depuis nos VNX vers VPlex, couplé à une forte charge des baies en question. Le concours de plusieurs facteurs, expliqués dans le billet, nous avait conduit à perdre la visibilité de tous nos datastores temporairement sur nos ESXi, avec les conséquences que vous imaginez.
Entre temps j’ai découvert un outil assez génial, SexiLog, qui m’a permis de monter des tableaux de bord quasi temps réel de la latence et des IOps de nos nombreux datastores et en particulier ceux de notre TIER2, servis par les VNX.
Or, nous avons enfin pu relancer nos chantiers de migration, avec précaution évidemment ! Or, lors d’une opération de provisionning de LUN aujourd’hui, on a pu enfin constater DE VISU, l’impact d’une telle opération avec SexiLog !
… Et le moins qu’on puisse dire c’est qu’il est saisissant, jugez plutôt :
La première copie d’écran concerne à gauche la latence moyenne de nos datastores (TIER2, TIER1) et à droite les IOps. Vous remarquez tout de suite l’énorme “double pic”. En fait, il correspond exactement au moment ou j’ai ajouté aux storage-groups VPlex une nouvelle LUN, sur chaque baie VNX (nous avons deux VNX en mirroir VPlex entre nos deux DC). L’autre image correspond au pic d’événements syslog reçus encore une fois au même moment. Vous noterez le type d’event : esx.problem.scsi.device.io.latency.high (pour rappel lorsqu’on rajoute une ou plusieurs LUNs à un storage group, une VNX envoie une commande “LUN attention” sur chaque LUN existante ainsi que sur les nouvelles LUNs. Dans la foulée, le VPlex fige les I/O de toutes les LUNs, rescan tout ce petit monde et si tout est ok de son coté, rouvre les vannes).
En définitive, et pour conclure sur cette “affaire”, VPlex et VNX, via leurs interaction lors de l’ajout ou la suppression de LUN, peuvent avoir un impact production non négligeable et qu’il faut anticiper. Accessoirement et comme déjà évoqué dans mon premier billet, sachez qu’EMC travaille déjà à un correctif spécifique pour éviter ces effets potentiels…