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é !