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.
