Mise à jour VxRail 4.5.225 : récit d’une épopée

Rappelez-vous (voir ici), il y a 7 mois environ, nous lancions notre chantier de mise en oeuvre de notre nouveau cluster VxRail généraliste, dit “le monstre”. En l’espace d’environ 2 mois, l’ensemble de l’environnement passait en production et la migration d’un peu plus de 500 VMs pouvait commencer. A l’époque, les machines tournaient sur ESXi 6.5 patch 02 / VSAN 6.6 pour un ensemble VxRail en 4.5.152. Même si le cluster a, depuis, été parfaitement stable coté service (c’est l’essentiel), nous avons encore souffert de certains bugs de jeunesse sur la partie purement management et supervision hardware de nos serveurs PowerEdge P570F, malgré une nette amélioration depuis nos gros ennuis de fin d’année dernière (voir mes nombreux billets sur VxRail … allez, je vous laissez cliquer sur la section en haut au centre ^^).

Pour autant, le tremblement de terre provoqué par le récent bug VSAN de corruption potentielle (dont j’ai longuement parlé aussi entre fin septembre et début octobre) nous a contraint à anticiper quelque peu la mise à jour de notre VxRail pour passer de la “152” à la toute dernière version disposant du patch critique, la “225”. Je vous propose le récit de cette épopée, qui, sans trop anticiper sur mes conclusions, s’est globalement très bien déroulée, même si nous n’avions pas du tout anticipé sa durée réelle…

Du Lundi 14h … au Vendredi soir, tard…

Pour résumer, l’opération consistait donc à mettre à jour l’ensemble de nos 20 serveurs Bi-Xeon P570F sur lesquels tournent actuellement un peu plus de 500 VMs. Tout d’abord, qu’entends-on exactement par “mise à jour” quand on parle d’un cluster VxRail : par définition, étant donné que l’offre est totalement packagée, il s’agit non seulement de passer les patchs purement VMware, mais également de procéder à la mise à niveau de tous les composants hardware présents sur les plateformes. Pour votre information, voici la liste de ces composants dans notre cas :

Autant dire que le travail était conséquent pour le robot du VxRail Manager. Pour passer tout ces firmwares et patchs, il a fallut pas moins de 3 reboots par machine ! Comptez environ 20 minutes par reboot “normal” et vous avez déjà plus d’une heure de consommé pour chaque serveur, auquel il faut ajouter aussi le temps de mise à jour des composants eux-même, soit environ 30 minutes de plus. Au total, cela représente donc 30 heures minimum théoriques pour l’ensemble des ESXi.

D’autre part et plus spécifiquement concernant VSAN, il faut savoir qu’aujourd’hui, sur nos quelques 295 To utiles, nous en avons consommé environ 150 To, soit environ 50% de la volumétrie. Cela représente environ 7 To par machine. La conséquence directe de ces volumes répartis c’est que lors du passage en maintenance de chaque host, même si vous choisissez l’option de dégrader quelque peu le niveau de disponibilité de vos données (l’option “ensure accessibility”), vous avez forcément un certain nombre de téra-octets à migrer avant que la machine puisse réellement être disponibilité à l’upgrade. Voici rapidement pourquoi :
Etape 1 : le premier ESXi est passé en maintenance en choisissant “ensure accessibility” ; il est ensuite mis à jour et retourne dans le pool ensuite. Lors de la sortie de maintenance, le cluster VSAN va directement procéder à une resynchronisation des données ayant évolué entre l’arrêt de la machine et son retour aux affaire.
Etape 2 : vous passez en maintenance votre deuxième ESXi… mais il faut attendre malgré tout que les données en cours de resynchro du premier ESXi soient terminées (c’est un petit peu plus compliqué que ça, mais je schématise).
Etapes 3 et suivantes : vous héritez donc d’un temps de resynchro variable sur chacune de vos machines qui peut durer, suivant la vitesse de votre back-end réseau, ma quantité de données à synchroniser/reconstruire et la vitesse intrinsèque de vos disques, plusieurs dizaines de minutes avant de pouvoir continuer.

De notre coté nous avons en général constaté un temps de resynchro de 30 à 45 minutes en moyenne (avec quelques pics à plus d’une heure). En gros… multipliez par deux votre temps par machine, ce qui donne 60 heures pour notre cas. Comme pour tout bon plat bien préparez, ajoutez une pincée de “temps de traitement/timeout divers par le VxRail Manager” et éventuellement quelques VMs qui refusent de quittez leur serveur, nous obligeant à relancer le process quelques fois, disons 4 heures… et vous avez votre temps de migration global : 3 jours pleins.

Ha oui, bon ça ne fait “que” trois jours… mais c’était sans compter sur notre Murphy adoré, ma bonne dame ! En effet, histoire de compliquer l’affaire, nous avons eu un problème hardware sur une des machines, en plein milieu de l’upgrade. En substance, lors d’un reboot, le serveur en question s’est retrouvé bloqué sur l’initialisation du BIOS ! Il a donc fallu escalader le souci auprès du support et obtenir, après quelques heures de diagnostic et tentatives de remédiation, le remplacement de la carte mère.

Dans l’interval, pour sécuriser notre production, j’ai procédé au forçage de la resynchro des données de VSAN, ne sachant pas à l’avance combien de temps prendrait un tel changement matériel ni si ce changement aurait nécessité, dans le pire des cas, une reconfiguration complète de l’ESXi et la perte des diskgroup VSAN. De plus, nous avions porté, suivant les préconisation de Dell EMC, le temps de reconstruction après perte de redondance sur VSAN à 200 minutes, au lieu de 60 par défaut.

Cette mésaventure nous a tout de même fait perdre plus d’une journée de travail sur VxRail. Et bon an mal an, nous sommes arrivé au terme de la mise à jour le Vendredi soir. Environ 4,5 jours après le GO, Lundi après-midi vers 14h.

Concluons !

Il quand même temps de conclure, après une beaucoup trop longue prose sans screenshot, un compte sur vBlog.io ^^. Malgré le temps passé, les complications rencontrées et une opération qui s’est même poursuivie un Vendredi (Vade Retro), je dois rendre hommage ici à toute l’équipe Dell EMC pour leur professionnalisme, leur sollicitude et leur réactivité. En effet, nous avons eu droit (sans trop insister qui plus est) une personne dédiée sur place pendant quasi toute la semaine, dans nos locaux, pour piloter cet upgrade et assurer la coordination avec le support. D’autre part, pour ce qui concerne plus spécifiquement la gestion de crise du serveur planté au boot, entre la détection du problème en fin de journée le Mercredi et le retour de l’ESXi après le changement du matériel le Jeudi dans l’après-midi, il s’est écoulé moins de 24h ! Une prouesse quand on sait que nous n’étions pas techniquement en sévérité 1, le cluster étant parfaitement fonctionnel malgré la perte d’un des hosts, et qu’il aura fallut changer tout le backplane de la machine (opération longue et complexe à réaliser).

Concernant la plateforme VxRail elle-même, quoi que j’ai pu en dire depuis plus de deux ans maintenant (même si je ne regrette rien de mes coups de gueule ^^), cette récente expérience me conforte encore dans notre choix initial : il faut bien se rendre compte qu’il nous aurait été matériellement impossible de réaliser toutes ces mises à jours logicielles en si peu de temps, avec les ressources internes dont nous disposons, si nous avions choisi des Ready Node. Entre tous les composants, la prise en charge complète des problèmes, qu’ils soient identifiés VMware ou Dell EMC, nous aurions du jongler entre les hotlines, attendre certainement beaucoup plus longtemps le remplacement de la carte mère et surtout, le plus important, nous aurions été dans une situation plus que délicate vis à vis de notre production, avec une pression sans commune mesure de notre coté.

Enfin, et comme cette épopée a aussi été une grande aventure humaine (comment ça je force un peu ?), je tiens à chaleureusement remercier Pierre-Eric, Dominique et Yannick pour leur aide précieuse pendant toute cette lonnnngue semaine… vous êtes au top messieurs, vous avez assuré !

6 thoughts on “Mise à jour VxRail 4.5.225 : récit d’une épopée

  1. Rémy says:

    Bonjour Cédric,

    Je trouve que c’est très bien d’avoir de la réactivité et un bon support mais ça me parait fou que vous ayez eu besoin d’une personne dédié pour effectuer la mise à jour.
    Un peu comme si pour mettre à jour vsphere de 6 vers 6.5 on aurait besoin d’un ingénieur vmware dédié pour plusieurs jours.

    Et je m’étonne que vous soyez satisfait en conclusion au vu de l’épopée ^^

    Je parle en connaissance de cause, nous avons aussi du vxrail et nous avons systématiquement des problèmes pour chaque mise à jour et nous n’avons pas la chance d’avoir quelqu’un dédié au support pour ça, il doit falloir être un plus gros client pour avoir droit à cet avantage ;)

    Et sur nos 4 noeuds, nous avons déjà eu 2 remplacements de carte mère, une remplacement de cpu, d’un HBA et d’une carte réseau … (sur des Dell E460F).

    Autant vous dire que la mise à jour vers la 4.5 me fait un peu peur (nous sommes en core en 4.0).

    • Cédric Cédric says:

      Bonjour Rémy. Beaucoup de choses dans votre commentaire. Je vais essayer de répondre point par point.

      Tout d’abord, vu la criticité de la plateforme et l’importance de cette upgrade, nous avons demandé une présence sur site et elle a été acceptée. Je ne vais jamais refuser la présence d’un corp Dell EMC si on me l’offre de bonne grâce. Après, bien évidemment, cette opération aurait pu être pilotée à distance par le RCM, mais personnellement je suis plus que convaincu qu’une présence IRL est souvent un facteur de réactivité dans ce genre d’opé. Et désolé d’insister, mais si je peux avoir un expert sur place pour le passage d’un vCenter de 6.0 en 6.5, je le prend sans hésiter, question de principe (que ce soit VMware directement ou un intégrateur).

      D’autre part, je fais toujours la distinction entre les problématiques hardware, les impondérables et la théorie. Je ne demanderai jamais à un éditeur ou un constructeur de me garantir que tout fonctionnera parfaitement à tous les coups. Par contre, ce que j’exige au minimum c’est un engagement très fort de ceux-ci en cas de problème et/ou une opération critique. J’ai d’ailleurs eu longuement l’occasion de m’épancher sur les dysfonctionnements de la plateforme VxRail durant sa première année d’existence. Après, évidemment, il est possible que notre relation historique avec EMC puis plus récemment Dell EMC ait joué en notre faveur pour l’obtention d’un FE pour cette migration. Comme toujours, une relation de confiance mutuelle entre un éditeur/constructeur et un client se mesure aussi à cela. On ne peut pas réduire un constructeur à son prix de vente et je sais pertinemment que tout le monde n’est pas d’accord avec moi sur ce point d’ailleurs.

      Enfin, pour ce qui concerne ma satisfaction, elle est bien entendu subjective. Je suis satisfait car, au final, ce qui est important pour moi et pour nos utilisateurs, c’est que la production n’ai pas été perturbée par ce gros chantier ultra critique. Je n’aurais pas eu la même conclusion si nous avions eu des impacts production.

      Cédric

  2. Rémy says:

    Merci pour la réponse et je suis d’accord avec vous, je prendrais également volontiers un ingénieur Vmware ou Emc sur site pour mes migrations ;)

    Pour ma part, les résolutions de bugs de mises à jour VxRail se résument à plusieurs heures/journées passés en Webex avec un technicien distant et m’empêchant de travailler sur d’autres sujets. Quand on nous vends du “one click upgrade” et que ça ne marche jamais, on s’agace un peu à force ;)

    Mais je comprends votre point de vue, c’est important d’avoir une bonne relation avec un éditeur et que le support soit présent et efficace, surement plus que le reste.

  3. Cédric Cédric says:

    Je suis tout à fait d’accord avec toi sur le mythique “One clic upgrade”, à tel point que je m’en sers de running gag presque à chaque rencontre des avant-vente ou techniciens de Dell EMC, mais je ne désespère pas qu’on y arrive un jour. D’ailleurs, je pense qu’on va tenter ça sur un de nos clusters d’ici fin Novembre, tout en ouvrant un case au cas où par sécurité ^^

  4. David Goasduff says:

    Merci pour le REX!
    Ceci prouve tout de même que certains avantages de l’hyper-convergé peuvent devenir aussi leur inconvénients.
    Cela prouve aussi qu’une offre ‘pacagé’ aura certes plus d’intérêt dans environnement de production passé une ‘certaine’ quantité de hosts et de VM.
    Mais depuis que j’ai goûté à Pure Storage (stockage ‘monolithique’ :-) ) et sa simplicité de gestion (les MAJ sont gérés par le support et ça se passe parfaitement bien) je ne suis pas prêt à développer notre partie VSAN (même si ça marche très bien).
    Mais une fois de plus, merci Cédric, pour ton retour.

  5. Cédric Cédric says:

    C’est compliqué de cacluler un vrai ROI sur VSAN aujourd’hui, c’est vrai, qu’on soit en packagé ou en DIY. En fait je mûris de plus en plus mon avis sur le HCI. Je suis passé d’un scepticisme modéré il y a quelques années (j’avais fait un billet la dessus d’ailleurs) à une conviction forte que c’était l’avenir pour une majorité de productions “PME+” plus récemment, pour terminer aujourd’hui en une sorte d’équilibre à la lumière de mon expérience dans VxRail (plus de 2 ans déjà… ça passe vite). Tiens, ça serait pas mal que je refasse un billet général sur ça d’ailleurs :)

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.