VxRail et son adolescence tourmentée, VSAN et sa trentaine triomphante

Je vous avais fait part il y a quelques temps de mon “rognotudju” au sujet d’un de nos clusters VxRail, victime d’une panne hardware qui n’en finissait pas et sur laquelle le support Dell EMC avait été franchement mauvais. Depuis, ce souci a été enfin résolu, courant Janvier 2018 (quand même, plus de 3 mois elapsed …) et tout fonctionne bien depuis, ouf.

Sauf que, entre temps, c’est un nouveau cluster flambant neuf chez nous, équipé de 6 Noeuds full-flash Dell PowerEdge, qui nous a encore réclamé une attention de tous les instants.

Petit récit à la Dallas de cette épopée…

Dallas, je vous dit …

Le cluster en question, destiné à héberger un ensemble de monster VMs pour un projet “Big Data”, est arrivé chez nous courant décembre et a été mis en place entre la fin de l’année et le début du mois de Janvier. Au début, aucun problème particulier à signaler, tout se comportait très bien et rien ne pouvait laisser présager des moments bien troubles par la suite. En effet, courant Janvier, nous avons commencé à constater des déconnexions de certains hosts ESXi depuis son vCenter de rattachement. Pour autant, les VMs hébergées sur ces machines continuaient de fonctionner sans sourciller. Le problème était d’autant plus étrange que cela se produisait de manière aléatoire sur plusieurs hyperviseurs, sans logique particulière.

Après une première investigation interne et pas mal d’analyse de logs vmkernel, hostd et consors, la cause n’était toujours pas identifiées mais semblait être lié à un plantage du hostd, provoquant de facto une perte de connectivité avec le vCenter. Il suffisait, au début du moins, de relancer le démon hostd pour que tout rentre dans l’ordre. Cependant, cette solution de contournement n’a duré qu’un temps car la fréquence des déconnexions s’amplifiait. Au bout d’un certain temps, la relance les hostd n’était plus suffisante et nous étions obligés de passer à plus radical : un passage forcé en maintenance et un reboot complet de l’ESXi via SSH.

Cette situation a perduré pendant environ 3 semaines. Je vous passe les dizaines d’échanges avec la hotline VxRail, sans constater de réels progrès, avant qu’en désespoir de cause, je monte personnellement au créneau auprès de l’avant-vente et en particulier notre ingénieur d’affaire favori. En fait, la hotline ne déméritait pas du tout, mais semblait embourbée entre ses procédures, les nombreux SR “doublons” créés par la plateforme qui appelait à l’aide via eSRS et les interventions ponctuelles des Field Engineers Nantais pour essayer de dépatouiller l’affaire. Certains pourront trouver que 3 semaines d’attente, c’est déjà trop pour des comportements aussi anxiogènes pour une production. Certes, mais rappelez-vous aussi que nous n’avions strictement aucun impact visible sur les VMs de l’environnement, il ne s’agissait finalement “que” de problème de supervision et d’administration.

Dans l’intervalle, nous avons du, entre autres :
– Faire une update du VxRail pour le passer de la version 4.5 à 4.5.070, puis en 4.5.150
– Faire une update iDrac des PowerEdge (nous avions des comportements plantogènes sur les Dell PTAgent des ESXi)
– Rebooter régulièrement les ESXi, évidemment …
– Réaliser des “Power-Drain” sur toutes les machines, c’est à dire, les éteindre physiquement, débrancher les alims et appuyer sur le bouton Power pendant quelques temps.
– Tenter de bidouiller les process ESXi en programmation des relances autos de certains

Bref, on cachait un peu la misère toute en tentant d’éliminer les différentes pistes possibles les unes après les autres. Après de grosses discussions, call-conf et escalades multiples, notre cas a finalement atterri au niveau de l’engineering VxRail, carrément, paf, bam.

Ce n’est que début Mars que nous avons finalement eu une réponse définitive de la hotline, qui résultait d’une analyse conjointe de Dell EMC et VMware itself. La root cause n’était en fin de compte pas liée à un module spécifique de VxRail, mais un bug VMware sur le driver LSI Logic générique, pilotant les contrôleurs SAS H330 des PowerEdge. Voici un extract de la réponse sur support

"VMware engineering found that the issue originated from the faulty LSI HBA driver (14.15.00): This is a low memory exausted issue in lsi_msgpt3 driver side. The plugin will talk to driver to get the device info. But the driver will hang when handle the IOCTL request from the plugin as the low memory is exausted. So it will lead the plugin hang and at last the hostd process will hang."

Au final, nous avons du mettre à jour le driver lsi_msgpt3 en 16.00.01 ainsi que les firmwares desdites cartes contrôleur. Depuis, plus aucune erreur ni perte de connexion.

Conclusions

A la lumière de ce deuxième épisode douloureux sur nos plateformes VxRail, que faut-il retenir, de mon point de vue, de nos divers expériences sur l’étalon HCI de Dell EMC ?

D’une part, que malgré quasiment 2 ans d’existence (Mon billet résumant l’annonce, en Février 2016, de EMC VxRail ici), Dell EMC est encore dans un mode de maturation de la plateforme et reste entièrement dépendant, quoi qu’on en dise, de VMware pour une grosse partie des couches logicielles impliquées. Le guichet unique et les promesses de déploiement ultra rapide de ce type de solution n’exonèrent pas pour autant d’un vrai travail d’intégration (j’en avais déjà parlé lors de mon coup de gueule, justement).

D’autre part et pour apporter une touche plus positive, je ne peux que constater la robustesse générale de VSAN, vu ce que nous lui avons fait subir sur les différentes clusters pendant toute les phases de diagnostic : reboots, maintenances, même certains power-off sans ménagement, dans certains cas. Rien n’a pu, jusqu’à présent (soyons prudent ^^), provoquer de réels problèmes d’accessibilité aux VM hébergées sur les datastores.

Dans un autre registre, cela nous a aussi appris qu’il fallait respecter certaines règles et bonnes pratiques lors de la mise en place d’un cluster VxRAIL : en effet, lors de l’installation, vous ne choisissez pas l’ordre dans lequel les serveurs sont intégrés ; si vous n’y prêtez pas attention, il est probable que l’ordre de rackage physique des machines ne respectent pas l’ordre logique dans le cluster. Pour en être certain, vous avez deux solutions :
– soit vous installez les machines comme vous voulez, vous configurez le cluster et ensuite vous ré-arrangez les machines physiquement en fonction de leur place logique. C’est fastidieux, mais ça a le mérite de fonctionner ^^
– soit vous rackez les hosts dans l’ordre croissant/décroissant de leur numéros de série : par défaut, l’assistant d’installation VxRail détecte les serveurs du plus petit numéro au plus élevé. Même si nous n’avons pas de preuve que cela marche à tous les coups, au moins vous limitez grandement le risque de faire de la chaise musicale par la suite :) . Au passage, ce serait d’ailleurs une bonne chose de réclamer une évolution du logiciel à Dell EMC pour pouvoir ordonner comme on le souhaite les ESXi pendant la phase d’installation.

Enfin et surtout, Dell EMC, depuis sa fusion, a encore beaucoup de travail pour rattraper le niveau d’excellence du support EMC dont nous avons bénéficié pendant plus de 10 ans sur VPlex, XtremIO, Isilon, VNX, et même Clariion CX. C’est d’autant plus important qu’une grosse partie du leadership actuel de la société repose sur sa capacité à réussir dans le domaine des plateformes HCI demain. Impossible pour elle de passer à coté en 2018 et dans les prochaines années, vues les ambitions de ses concurrents (Nutanix en tête évidemment, confère ma série d’article sur ce sujet) et l’intérêt croissant qu’elles suscitent chez nous-autres clients.