Quand VPlex fait du zèle sur la cohérence des données

Comme quoi, tout arrive… même l’improbable : nous avons connu notre premier incident “VPlex” il y a une petite semaine ! Et encore, pour parler d’incident, il faudrait parler de réel bug logiciel, ce qui n’est à proprement parler pas le cas, on va le voir. Nous avons subi récemment un incident majeur sur notre environnement de production TIER2. Plus exactement : nous avons connu une perte temporaire de presque la totalité de nos liens FC à nos datastores TIER2 pendant une trentaine de secondes. Les impacts sur nos VM ont été assez importants évidemment et je vous laisse à votre imagination pour le détail ;) . Ceci étant, tout est rentré dans l’ordre assez rapidement (sous moins de 2 heures au total) et malgré quelques soucis applicatifs détectés au fil de l’eau pendant encore quelques heures supplémentaires, plus de peur que de mal. Comme quoi, toute la couche SAN de VMWare est tout de même extrêmement robuste.

Mais que s’est-il donc passé pendant ces 30 secondes fatidiques ?
Il était une fois …

… un gros chantier en cours depuis quelques jours chez nous. En effet, nous sommes en train de restructurer l’ensemble de nos VMFS de production TIER2 (VPlex/VNX) pour prendre en compte l’évolution de la taille de moyenne de nos VM. Il y a encore quelques années, les machines virtuelles pesaient quelques 100 à 200 Go, données comprises. Toutes celles qui dépassaient les 300 Go étaient gérées en mode hybride VMDK pour le système et l’application et RDM pour les données. Aujourd’hui les machines sont de plus en plus grosses et la norme est souvent autour de 250 Go. De plus, le RDM est une solution élégante pour gérer de la volumétrie spécifique, mais elle reste relativement lourde en terme de provisionning.

Dans ces conditions, nous avons choisi de passer nos datastores de 2 To à 4 To pour pouvoir éviter autant que faire se peut la création de RDM et conserver une agilité forte dans la gestion des volumes. Dans la pratique, cela passe donc par un dé-commissionnement progressif de l’ensemble de nos vmfs de 2 To (une trentaine) au profit de nouveau de 4 To (une quinzaine). Inutile de dire que ce jeu de chaise musicale est source d’un grand stress en terme d’I/O sur nos baies VNX. Certes on aurait pu choisir plus simplement d’étendre les VMFS en agrégeant une deuxième LUN à la première, mais c’était aussi l’occasion de re-formatter tout cela et repartir sur des vmfs tout neufs.

C’est alors que Jeudi, 15h52 est arrivé. Nous étions en pleine phase de storage vmotion et les baies étaient très chargées. Dans le feu de l’action, sans attendre que cette première phase de déménagement des VM soit réellement terminée, j’ai procédé à l’ajout de 3 nouvelles LUNs de 4 To depuis nos VNX vers le VPlex. Et là, catastrophe, l’ensemble de nos ESXi TIER2 ont perdu une grande partie de leurs chemins vers leurs datastores, les storage vmotion encours se sont plantés. De plus, voyant cela, nos deux clusters HA, sur déclenchement d’un PDL (Permanently Device Lost), ont tenté de relancer des VM sur d’autres ESXi … bref, la grosse grosse pagaille.

Heureusement pour nous, le TIER1 n’a pas été touché et nous avons gardé la main sur nos outils d’administration (vCenter compris), ce qui nous a permis de cerner le problème en quelques minutes. Enfin, sans que nous n’ayons touché quoi que ce soit, l’ensemble des datastores sont revenus à la vie progressivement et nous avons retrouvé nos environnements. Voila pour les faits.

Nous avons bien sûr appelé le support EMC à la suite de cette grosse panne. Après investigation et pas mal d’explications, je vais tenter de vous présenter ce qui s’est passé réellement coté VPlex et pourquoi.

Tout d’abord un peu de théorie concernant le comportement de VPlex et des VNX vis à vis du provisionning d’un LUN entre le back-end et les directeurs : lorsque vous ajoutez un LUN dans un storage group d’une VNX, la baie va envoyer à l’hôte (ou aux hôtes s’il y en a plusieurs dans le SG en question) un message SCSI de type “Unit Attention” avec un code sense spécifique de type “Report LUN data changed”, de plus elle va l’envoyer sur L’ENSEMBLE des LUNs déjà provisionnées dans le storage group. En retour, et pour CHAQUE LUN, le VPlex va envoyer une commande de type “Report LUN” pour savoir ce qui a changé, et accessoirement, détecter le nouveau LUN.

Jusque là, pas de problème… sauf que, dans ces conditions et afin de garantir la cohérence des données, le VPlex va mettre en pause les I/O de toutes les LUNs en question ! Imaginez donc un cas où on ajoute des volumes à un storage group contenant déjà une bonne quarantaine de LUN, que votre baie est un peu sous l’eau à cause d’une charge d’I/O très importante et qu’en plus, les débits FC saturent sur certains SP… vous obtenez un effet boule de neige catastrophique : le VPlex bloque les IO, les commandes “LUN Report” ne reviennent pas en temps et en heure depuis la VNX et au final, le VPlex considère qu’il y a un souci sur tout le back-end et des timeout surviennent sur les ESXi, finissant par provoquer des PDL sur les hosts.

Après quelques dizaines de seconde de perte de communication entre VPlex et la baie, les LUN Report sont reçus, le VPlex libère à nouveau les IO coté front-end et les ESXi retrouvent leur volumes. Alors, vous allez me dire : “si on est en distributed device, normalement, l’autre miroir est capable de prendre le relais automatiquement”. On pourrait le penser en principe, sauf que là, nous ne sommes pas dans un cas de perte de lien ou de perte totale de communication entre VPlex et une baie, mais bien dans un mode spécifique de re-découverte qui impose, pour le moment en tout cas, au VPlex de figer les IO coté front-end, et pas seulement back-end.

C’est précisément ce qui s’est passé ce Jeudi noir : des baies surchargées par des storage vmotion, des temps de réponses aux commande LUN Report du VPlex beaucoup trop longs et donc, par cascade, une perte des chemins vers tous les LUNs du storage group de la baie en cause et se faisant une perte de la quasi totalité de notre stockage TIER2 pendant 15/20 secondes.

Si on analyse la source du dysfonctionnement, on peut constater que c’est uniquement lié au comportement du VPlex qui, par “excès de zèle” en quelque sorte, bloque les IO pendant la redécouverte de tous les LUNs. Comme évoqué en introduction, ce n’est pas vraiment un bug, mais malgré tout, conscient des limites de ce mode de fonctionnement, EMC nous a indiqué qu’ils travaillaient dors et déjà à une amélioration du code des directeurs pour limiter, voir éviter totalement un cas de panne de ce type.

J’espère avoir été assez clair et surtout exact dans mes explications, mais sachez donc que si, comme nous, vous entreprenez des gros chantiers de réorganisation de vos LUNs, la règle d’or : faites les choses tranquillement, dans l’ordre, l’une après l’autre. Attendez que vos manipulations front-end (et donc les charges d’IO) soient complètement terminées pour vous occuper du dé-commissionnement VPlex et VNX. Vous éviterez ainsi le risque de vous retrouver dans le contexte potentiel d’une perte massive de chemins.

En attendant, nous attendons donc un joli patch pour régler cela, je surveillerai avec attention de mon coté la sortie des futurs codes VPlex ;)

5 thoughts on “Quand VPlex fait du zèle sur la cohérence des données

    • Cédric Cédric says:

      Nous sommes en 5.4p1 si je me rappelle bien.

      Je viens par ailleurs d’avoir la configuration par EMC qu’un patch était en ce moment même en développement pour une livraison prévue d’ici mi-Juin.

  1. Bonjour Cédric,
    Le patch devrait corriger les lock de tous les LUN durant un ajout de LUN, c’est bien ça ?
    Je me posais la question de l’intérêt d’un tel lock : lors d’une extension par ajout d’un lun, le lock devrait se faire au niveau du FS en cluster (VMFS).

    • Cédric Cédric says:

      Quand je parle de lock, il s’agit d’un verrou purement VPlex, qui pause toutes les I/O liées au back-end en question le temps de refaire l’inventaire complet. C’est ce que j’ai compris en tout cas.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *