Je vous ai conté à plusieurs reprises ici notre volonté d’investir en 2016 dans VxRail. L’objectif était à l’époque de pouvoir réellement confronter cette plateforme Hyper-Convergée à la situation d’une production réelle (en prévision d’un investissement éventuel beaucoup plus massif en 2018). Cela s’est traduit à l’époque par l’acquisition de deux clusters VxRail séparés : un cluster 3 Noeuds autonome pour héberger notre “pré-production” et un cluster 2×3 Noeuds en mode stretched pour absorber l’ensemble de nos “machines d’administration” (rendez-vous dans la section VxRail de ce blog pour plus d’info).
Même si l’architecture VxRail est, au départ, basée sur un regroupement de logiciels issus du même éditeur, VMware en l’occurence, placé sur une plateforme hardware industrielle, il ne faut pas sous-estimer la difficulté pour un constructeur, fut-il EMC, de produire et assurer la maintenance de tels environnements. On imagine souvent, à tord, qu’il s’agit juste de monter un bundle, y affecter une ligne de support dédié et “zou, on peut faire du business”. Non, définitivement, l’affaire n’est pas si simple.
Preuve en est, appuyée par notre propre expérience récente de client VxRail, que cet exercice reste un travail complexe et de longue haleine.
En effet, je vous racontais en tout début d’année que j’avais pu procéder “en quelques clics de souris” (voir ici) à l’upgrade en 4.0 de notre premier cluster 2×3 Noeuds. Effectivement, lors du passage de la 3.5 à la 4.0 tout s’était bien passé. Sauf que, plus récemment, une nouvelle update critique (voir ici) allait un peu gripper cette mécanique pourtant bien née et bien huilée, a priori.
En mars, en effet, surgit un ETA EMC nous indiquant la sortie de VxRail 4.0.132 incluant principalement la mise à jour “update 3” de vSphere 6.0 en général et VSAN en particulier (voir le KB#2149127 de VMware). Or, cet ETA produisait également une alerte spécifique pour deux types de clusters nécessitant absolument l’intervention d’EMC pour être passée : les clusters 3 noeuds et les stretched clusters.
CHOUETTE ! Nos deux configurations étaient concernées … En bon petit soldats, nous avons donc planifié avec le support RCM la mise à jour des deux environnements. Et … bien nous en a pris, car le moins que l’on puisse dire, c’est que les opérations ont été très laborieuses, entre les bugs de jeunesse du VxRail Manager et les problèmes spécifiques inhérents à la technologie VMware (notamment des limitations au niveau des timeout de passage en maintenance de noeuds ESXi/VSAN). Somme toute, il aura fallut plusieurs jours par cluster pour pouvoir venir à bout de cette mise à jour 4.0.132. Plug’n play avez-vous dit ?
Alors, ok, ne soyons pas trop méchants : EMC a parfaitement géré cette opération et nous a averti bien en amont de la difficulté prévisible et des précautions à prendre. En cela, les équipes support ont été exemplaires, malgré des problèmes de planification évident, contextuels à cette mise à jour, précisément. Je précise aussi, pour les inquiets, qu’à part quelques dizaines de minutes de lag VSAN pendant une reconstruction de redondance (un problème pur VSAN, pour le coup), nous n’avons jamais subit d’arrêt de production ni de perturbation importante.
Nous pourrons vérifier à l’avenir si les prochaines updates auront été mieux anticipées logiciellement pour redonner à VxRail ce coté “one-clic upgrade” qui faisait partie du cahier des charges initial, rappelons-le. Le temps et la maturité du produit joueront certainement en faveur d’une normalisation de ces phases critiques. Rappelons-nous aussi qu’un autre produit, XtremIO pour ne pas le citer, avait également été un peu malmené lors de l’annonce d’une de ses premières mises à jour majeures : il avait fallu reformatter entièrement la baie ! (voir ici).