EDIT du 16/10/2018 : on vient d’avoir la confirmation que les corruptions peuvent aussi survenir lors que l’on réalisé un expand sans que celui ne déclenche l’ajout d’un component.
Mon précédent billet sur le sujet faisait état d’un bug sur les dernières versions de VSAN à partir de la 6.6.0 pouvant, dans certaines conditions, mener à des corruptions de données sur certaines VMs “à risque”. L’heure est venue, je pense de faire le tour de la question après pas mal de rebondissement depuis quelques jours.
Il a été difficile d’arriver à obtenir des informations claires pendant cette période et le caractère éminemment critique de ce bug (la corruption de données étant, sans doute, le pire scénario pour un constructeur ou un éditeur de solutions de stockage quel qu’il soit) a forcément généré pas mal d’anxiété parmi les clients de VMware et Dell EMC ayant des productions sur ces versions. la récente communauté VMUG France a été particulièrement active à cette occasion et a d’ores et déjà prouvé, s’il en était encore besoin, tout son intérêt, notamment pendant ces périodes tendues.
Je vous propose donc un nouveau billet précis et donnant des informations vérifiées et confirmées par le support VMware.
Suis-je exposé ?
Vérifiez tout simplement votre version de vSAN. Si vous êtes en version 6.6, 6.6.1, 6.6.1u2 ou 6.7, vous êtes potentiellement exposé. Tout dépend de l’activité historique de vos VMs. Aujourd’hui, il semble que très peu de clients (une dizaine sur l’ensemble des clients VSAN de VMware) se soient manifestés au support et aient été confirmés comme victimes de ce bug particulier.
Comment le bug se matérialise ?
Ce que je vais vous indiquer maintenant est un interprétation de toutes les informations parcellaires qu’on a récolté depuis plusieurs jours. Elles sont globalement confirmées par le support VMware, cependant, je n’ai pas la prétention d’être une source officielle en la matière. Comme toujours, je vous recommande chaudement, en cas de doute chez vous, d’ouvrir un case au support.
– Vous avez créé ou déplacé une VM vers votre cluster VSAN. Pour le moment, pas de souci.
– Pour une raison ou une autre (passage en maintenance d’un host ou outage quelconque sur votre production) les objets VSAN de votre VM ont du être resynchronisés. Vous passez à “l’étape 1”, STAGE1 comme disent les anglais. Pour le moment, tout va bien.
– Vous avez ensuite procédé, à un moment ou un autre, à une extension d’un des disques de votre machine. Deux cas se présentent alors : Premier cas, le volume global du disque est inférieur à la taille maximum d’un composant VSAN (255GB par défaut), la encore, pas de souci, vous êtes tranquille ; Deuxième cas, le volume étendu passe la barre d’un multiple de 255GB logiques. A ce moment, tant que la volumétrie réellement stockée à l’intérieur du disque n’oblige pas VSAN à créer un nouveau component de 255GB, tout va bien… Confirmation du 16/10/2018, apparemment, même si vous ne déclenchez pas l’ajout d’un component avec votre extension, vous rentrez malgré tout en stage2 :( :(
– Dès que VSAN doit rajouter un component de 255GB à votre disque étendu, vous rentrez en STAGE2… et là, ça commence à devenir tendu.
– Enfin, si à la suite de cette situation, VSAN doit faire un resync des objets de la VM (quelle que soit les conditions), dans ce cas, vous passez en STAGE3 et votre VM a de grandes chances d’être dans un état inconsistent.
D’une manière générale, il est urgent de ne pas paniquer tant que VMware n’a pas établi clairement les facteurs de risques. Certes, c’est compliqué pour les clients déjà impactés, mais apparemment, même en STAGE3, le bug n’est pas systématique et il nous manque des infos internes pour vraiment juger de l’impact. Ceci étant, il est grand temps que la société communique officiellement sur le sujet à mon avis, ça commence à faire le buzz un peu partout (reddit, twitter etc.).
Des contre mesures / solutions de contournement ?
Comme l’indique le KB#58715, afind de protéger vos VMs de futures compromissions, VMware vous recommande chaudement (et nous aussi) de revenir à la méthode pré-VSAN 6.6 d’extenion de disque. Pour se faire, suivez les instructions du KB pour positionner le paramètre avancé ClomEnableInplaceExpansion. Une fois fait, toutes les modifications/extensions réalisées sur votre VSAN seront protégées contre ce bug. Par contre, les VMs déjà en souffrance (STAGE2) le resteront.
D’autre part, si vous êtes en STAGE2, une solution définitive consiste migrer les VMs en question (si vous pouvez les identifier, voir plus bas) vers un autre stockage, puis les rapatrier vers VSAN. De même, vous pouvez tenter, si c’est possible pour vous, un clone sur place. En effet, une fois le paramètre appliqué, les opérations de clonage ou svMotion utiliseront l’ancienne méthode – safe – de provisionning.
Un autre problème majeur ici, c’est que le temps ne joue pas en faveur de VMware : en effet, toutes les VMs en STAGE2 sont à la merci d’un resync quelconque, y compris non prévu à cause d’un incident de production… Cela explique aussi, sans doute, pourquoi ce bug a tardé à émerger, sachant que VSAN 6.6 est quand même sorti depuis plus d’un an maintenant.
Comment savoir si j’ai des VMs corrompues ?
Le support VMware dispose de scripts spécifiques, qui permettent d’avoir une idée du niveau de mélasse dans laquelle vous êtes en identifiant les components VSAN présentant un risque. Donc, comme déjà évoqué, n’hésitez pas à contacter le support pour qu’il réalise l’analyse de votre environnement.
D’ailleurs, c’est une vraie question : si nous sommes exposés, doit-on systématiquement appeler le support, même si nous n’avons pas de symptômes ? Je n’ai pas la réponse, mais pour ma part, je pense qu’il faut attendre la communication officielle. Peut-être aussi que, comme pour certains ETA chez Dell EMC ou HP, nous seront directement sollicités pour réaliser cet audit. Cela participerait grandement à l’image de VMware et ses partenaires dans cette affaire d’ailleurs.
Le patch !
Evidemment, VMware travaille activement à la construction d’un patch adapté. Il nous a été confirmé à plusieurs reprises que celui-ci devrait sortir d’ici la fin de cette semaine à l’heure où j’écris ces lignes (semaine du 24 au 28 Septembre 2018) que le patch sortirait durant la semaine du 1 au 7 Octobre (snif …). Nous ne savons pas encore en détail quelle sera la procédure à suivre pour l’appliquer, mais une chose est sûre : il faudra passer en maintenance de type “Ensure availability” (vous devrez consentir à une une baisse du niveau de redondance FTT pendant l’opération) pour éviter tout risque de resync pre-patch.
Mise à jour du 2 Octobre 2018 : l’ETA correspond pour VxRail vient de sortir et grosso modo indique les mêmes informations que celles contenues dans le KB officiel coté VMware.
Quelles conséquences pour VMware ?
Difficile de savoir si la société va vraiment souffrir et/ou que sa notoriété en sera affectée. Le fait est qu’à ma connaissance, c’est vraiment la première alerte sérieuse autour de VSAN et nombreux sont ceux (parmi les concurrents HCI) à attendre la société au tournant. Le plus important je pense c’est la manière dont elle va se sortir de ce faux-pas, en terme de com’, comme en terme technique. Pour l’instant, la situation est relativement bien gérée techniquement, un peu moins bien commercialement et en terme de communication, d’après moi.
Quelques références si vous souhaitez vous penchez, vous aussi, sur la question :
– L’article de VMware sur sa knowledgebase qui traite du bug, KB#58715.
– Mon premier billet d’alerte, il y a quelques jours, ici.
– Un billet de Cormac Hogan discutant components VSAN, à consulter ici.
– Le thread Reddit qui discute du bug, à consulter ici.
Comme toujours, un grand merci à la communauté VMUGFR pour les nombreux échanges (David, Erwan, Gaël, Cyril, Noham, Frédéric etc.) ainsi qu’à certains insiders de VMware qui se reconnaîtront certainement ^^.