VSAN 6.6/6.7 : attention aux extensions de vmdk sur vos VM (maj)

EDIT5 du 27/09/2018 : J’ai créé un autre article qui fait un point de situation global.

Bonsoir à tous !

Ca fait plaisir de vous retrouver après plus de 15 jours d’absence. La cause : un début de rentrée assez dingue pour ce qui me concerne. Cela explique, sans l’excuser, le désert de news sur vBlog, alors que l’actualité est pourtant riche en ce moment (VMUGFR, retour sur les annonces du VMworld 2018 de Las Vegas, quelques REX sur des gros incidents récents sur notre prod etc. …).

Je rouvre les vannes techniquement en vous faisant part d’une alerte sur laquelle tous les admins VSAN devraient être vigilants. A l’occasion du reboot VMUG France qui s’est tenu hier matin à Paris (c’était génial, mais je vous ferai un billet spécial ce week-end), j’ai eu l’occasion d’échanger avec des éminents collègues au sujet de nos productions respectives et ils m’ont fait part d’un bug bien inquiétant rencontré depuis plusieurs semaines chez eux. Il porte sur des cas spécifiques de corruption de données sur leurs environnements Exchange tournant sur VSAN, précisément. VMware est bien entendu sollicité et en cours de qualification/caractérisation actuellement.

Oops, même si ce n’est pas une généralité (cela n’a rien de systématique), la corruption de données n’est jamais à prendre à la légère sur un support de stockage, quel qu’il soit. Voici quelques détails des conditions particulières pouvant conduire à cette extrémité.

Gäel et Cyril, que je salue bien bas au passage, ont été victimes, sur leur cluster VSAN, de ce bug “bizarre” avec leurs environnements Exchange 2016 virtualisés : à l’occasion de passages en maintenance de certains noeuds contenant des données de ces VM, ils ont eu la désagréable surprise de récupérer des corruptions de leurs bases ! De plus, ils ont aussi plus ou moins régulièrement des comportement assez suspects sur certains autres filesystems (des passage en Read Only de certains fs Linux … signe que quelque chose ne tourne pas rond sur le stockage backend, en général). A priori, pourtant, aucun problème n’existe coté réseau ou état de santé du cluster VSAN lui-même.

Après pas mal d’investigation (et pas mal de temps …), VMware a semble-t-il mis le doigt sur ce bug, documenté depuis le 18 Septembre dans ce KB#58715. A la date de rédaction de ce billet (21/09/2018), l’article n’est pas très détaillé, c’est le moins que l’on puisse dire, mais fait tout de même état d’un potentiel risque de corruption “in-guest” de “certaines bases de données” sous “certaines conditions relativement rares”, dans le cas ou le vmdk concerné a déjà été étendu directement sur VSAN. Vague…

Il toucherait toutes les builds VSAN depuis la 6.6. La relative bonne nouvelle c’est qu’il semble que VMware ait déjà trouvé la root cause, car une date de livraison d’un patch spécifique a été avancée, sans être officiellement confirmée, au 27 Septembre prochain. Vu le contexte et la sensibilité d’un tel bug, il sera vraisemblablement accompagné d’une alerte de criticité et de divers ETA, notamment chez Dell EMC pour VxRail et plus généralement chez tous les intégrateurs VSAN.

Je ne peux m’empêcher de dubiter sur la solution de contournement actuellement proposée : le passage d’un obscur paramètre VSAN “ClomEnableInplaceExpansion” à 0. C’est d’autant plus étrange que ce paramètre est totalement dynamique, a appliquer sur tous les ESXi du cluster (de ce que je comprends) et qu’il est actif sous une minute environ.

Impossible de trouver de la doc sur ce machin (si vous avez des sources, je suis preneur), mais si son label est représentatif, cela signifierait que celui-ci interdirait à l’avenir une forme d’extension dynamique des vmdk en mode “Inplace”. Difficile en revanche de savoir ce que ça implique pour VSAN au niveau performance ou fonctionnement général. Peut-être est-ce une méthode par défaut (parmi plusieurs disponibles dans le code) d’extension dynamique des volumes thin…

On en saura sans doute plus dans les jours qui viennent. Mais, en attendant, chers confrères avec des environnements VSAN 6.6+, gardez l’oeil sur le KB !

Grand merci à la communauté VMUGFR pour l’échange sur notre slack ! Au passage, je vous glisse une petite pub sur cet espace, à l’adresse https://vmugfrance.slack.com. Si vous souhaitez vous inscrire, n’hésitez pas à me contacter, je ferai suivre une invitation.

EDIT du Lundi 24/09/2018 :
On m’a confirmé que ce bug avait été pris très au sérieux par VMware (normal) et que le patch tant attendu sera publié d’ici la fin de cette semaine. Le bug en question concerne pour le moment très peu de clients par rapport au nombre d’instances VSAN et se déclenche après une succession d’opérations spécifiques (notamment extend d’un vmdk sur une VM puis mise en maintenance d’un ESXi hébergeant une partie tout ou partie des objets de celle-ci). Il est effectivement contourné complètement et dynamiquement après mise à jour du fameux paramètre ClomEnableInplaceExpansion, on peut donc en déduire que ce n’est pas le “format des données stockées” qui est en cause, mais bien le comportement de VSAN au moment ou un “write” se produit. Le patch fourni sera intégré directement à la prochaine version de ESXi qui devrait sortir courant Octobre (6.7u1 très vraisemblablement). Enfin, le bug peut potentiellement se manifesté quelle que soit la VM, pas seulement les VM transactionnelles.

EDIT du Mardi 25/09/2018 :
Après discussion avec des collègues du VMUG France (sur notre magnifique espace Slack ^^), il semblerait que le message de VMware soit plutôt flou. Nous n’avons pas tous le même discours, en fonction des sources. Pour le support, la modification du paramètre mystère ClomEnableInplaceExpansion n’éliminerait pas les risques sur les VMs déjà étendues sur VSAN, alors que j’avais de mon coté eu l’info inverse. Bref, nous enquêtons et on vous tiens au courant !

EDIT du 26/09/2018 :
VMware travaille très fort sur ce bug, c’est certain aujourd’hui. Les informations fournies par le support sont désormais assez claires :
– Le bug touche uniquement les version de VSAN suivantes : vSAN 6.6 (vSphere 6.5 EP2), vSAN 6.6.1 (vSphere 6.5u1), vSAN 6.6.1u2 (vSphere 6.5u2), vSAN 6.7.
– Ce bug est par ailleurs lié à une nouvelle méthode d’extension des vmdk introduite par VSAN 6.6.
– L’application de la solution de contournement présentée dans le KB, le fameux passage du paramètre mystère, consiste précisément à revenir à la méthode pré-VSAN 6.6.
– Par conséquent, toute extension de VM postérieure à ce changement sera “immunisée” contre ce bug : du coup, on vous encourage à l’appliquer, tant que le patch n’est pas passé chez vous !
– On devrait pouvoir, via un script spécifique, identifier les VMs présentant un risque d’exposition.
– Les conditions pour s’exposer au bug sont tout de même très spécifiques, d’après ce que l’on a compris, il faut que votre extend de vmdk soit un multiple de 255GB (la taille par défaut d’un objet VSAN si mes souvenirs sont bons), de plus il faut que votre vm ait déjà fait l’objet d’un resync après un passage en maintenance ou un outage quelconque. Bref, il faut aller le chercher vraiment loin : un petit coté Murphy pour ceux à qui c’est arrivé (très très peu de clients au niveau mondial visiblement, qui se comptent sur les doigts des deux mains).
En gros, ne vous inquiétez pas outre mesure, même si mes précédentes infos pouvaient paraître anxiogènes, elles étaient plus liées à l’absence d’information qu’à un risque fort et avéré. Malgré tout, comme toujours, restons vigilants et passons le patch ASAP :). Pour aller plus loin, vous pouvez vous rendre aussi sur le thread reddit suivant : https://www.reddit.com/r/vmware/comments/9htupv/received_notice_from_our_tam_regarding_a_new/

EDIT du 27/09/2018 : rendez-vous sur le nouveau billet “Point de situation” pour la suite.