Install VxRail, partie 4 : GO !

Enfin ! Après plusieurs mois d’attente, notre cluster VxRail est désormais dans sa configuration cible et quasi-prêt à rentrer en production. Si vous n’avez pas suivi le roman associé et que vous voulez dévorer ma longue prose, je vous conseille de lire mes précédents billets à ce sujet : ici, ici, ici, ici, ici ou encore là.

Pour conclure cette première série de billets détaillant la mise en oeuvre de VxRail chez nous, je vous propose un petit résumé du projet, ses rebondissmeents, ses cascades à vous couper le souffle et, finalement, son dénouement en mode “Happy End” :)

Les objectifs

Je vous rappelle rapidement notre objectif initial : construire un cluster VMware dit “d’administration”, autonome et indépendant des technologies déjà en place chez nous, permettant d’héberger l’ensemble de nos machines critiques assurant la supervision et la gestion de nos infrastructures de production. Le deal avec EMC lors de l’acquisition en Juin dernier consistait à mettre en oeuvre un cluster VxRail en mode stretched 3+3. Or à l’époque, VxRail 3.5 venait tout juste d’être annoncé et ne supportait pas encore cette topologie. Il a donc fallu attendre plusieurs mois, le temps que la version 4.0 soit disponible pour pouvoir enfin configurer les appliances correctement.

Les étapes intermédiaires

Après réception des appliances fin Juillet dernier, nous avons patienté plus de 3 mois, sagement… Début Novembre, VxRail 4.0 était enfin annoncé mais toujours pas réellement GA et a forcieri disponible. Histoire patienter et accessoirement de commencer à découvrir l’environnement et le packaging, nous avons pris la décision de déployer les nodes en l’état (3.5) et pour du test uniquement. Après quelques reports liés à des grosse mises en production, ce fut fait fin Novembre.

Ce n’est qu’à partir du 6 décembre que nous avons enfin pu mettre la main sur VxRail 4.0. J’ai d’abord procédé à la mise à jour “in place” sur notre configuration existante. Ce qui ressort de cette opération c’est avant tout la simplicité de l’opération : 3 clics, 15 minutes et le cluster était à jour. Quel confort !

Ceci étant, malgré nos espoirs initiaux, il n’est pas possible de changer la topologie d’un cluster déjà déployé (pas encore en tout cas). Conséquence de quoi nous avons dû ré-imager complètement l’ensemble des nodes, purger le vCenter d’hébergement de toute la configuration existante, afin de repartir à zéro, en 4.0 et en config cible.

Réinstallation des Nodes en 4.0

Nous nous sommes attelé à la tâche de purge et de réinstallation Mardi et Mercredi dernier. Du coté du vCenter, c’était relativement simple à réaliser : déconnexion forcée de l’ensemble des nœuds puis suppression de l’inventaire, suppression des références diverses créés lors de l’initialisation du cluster (VM Policies, droits sur les users techniques, dossier de VM etc.). A noter qu’une doc précise des objets à supprimer est disponible chez Dell EMC pour ne rien oublier.

Du coté du reset des nœuds, l’opération a été réalisée par l’équipe d’EMC sur place, avec un certain brio il faut bien le dire (petite pomade à Eric, Patrice au passage ^^). Comptez environ 45 minutes par node tout de même. Globalement, tout s’est très bien passé pour la partie intégration. Vous démarrez avec 3 nodes puis vous ajoutez les 3 nodes suivants l’un après l’autre. On a malgré tout eu une petite surprise lors de la première tentative d’installation : le VxRail manager refusait de valider la configuration sous prétexte que nous n’étions pas en 10Gbit coté réseau. Je me cite : “Pfff, mais qu’est-ce qui se passe encore, évidemment que l’on est en 10G, c’est forcément un problème VxRail”.

Aheum … On a passé un temps important à vérifier les KB EMC et VMware puis re-re-re-checker les paramètres réseau des machines et des switchs pour nous rendre compte au final que le problème ne venait pas des appliances… Non, c’était tellement évident : en fait nos switch ne faisaient tout simplement que du Gigabit Ethernet. Quoi ? Qu’est-ce ? Comment ? Vous voulez plaisanter ? Bon je vous passe les détails du pourquoi de tout ça (petites économies …) mais une chose importante est tout de même à retirer de cette petite galère : l’assistant VxRail 4.0 effectue des tests plus poussés que VxRail 3.5, notamment au niveau réseau et c’est une bonne chose !

Nous avons finalement recâblé notre cluster pour disposer de VRAIE connectivité 10G et, évidemment, tout est rentré dans l’ordre.

Stretched cluster VSAN 3+3

Une fois les 6 nodes en place, il fallait construire le stretched cluster VSAN. Là on sortait clairement du pûr domaine de VxRail, car c’est une opération pure VMware évidemment. Cela passe par la mise en oeuvre d’un witness dédié, extérieur au cluster lui-même, forcément (Il s’agit d’une petite VM qui intégre un ESXi minimal assurant les fonctions de témoin et arbitre en cas de split brain).

Mais, là encore, tout ne s’est pas passé comme prévu et nous avons pris beaucoup de temps pour obtenir un fonctionnement optimal. Bon, en même temps, forcer l’installation d’un witness VSAN 6.2a en modifiant à l’arrache la configuration réseau de la VM (passage des interfaces VMXNet en E1000, oui, oui, tranquille …) pour qu’elle puisse tourner sur un ESXi 5.5, ce n’était pas une bonne idée.

Si vous ne voulez pas avoir de souci de votre coté, ne faites pas comme nous : un witness VSAN 6.2a doit absolument tourner sur un ESXi 6.0, il ne MARCHE PAS sur un 5.5 ! Oui, je sais, on a souvent l’impression de pouvoir un peu déroger aux best-practices, on se croit plus intelligent que l’ensemble des ingénieurs ayant construit les choses… mais, vous savez quoi, les listes de compatibilité ne sont pas là juste pour faire joli.

Après une installation du witness complètement respectueuse des règles, le mode stretched a été opérationnel en quelques minutes. Oui, il suffit de RTFM et de respecter la doc, incroyable hein :)

Aloooooors, il marche ou pas maintenant ?

La réponse est … OUI ! Ca fonctionne tellement bien que la machine a même fait un petit call-home eSRS à cause des congestions constatées sur certains disques lors des tests de charge en question. Le support VCE/Dell a d’ailleurs été particulièrement réactif, un très bon point.

Aujourd’hui, il nous reste une dernière chose à réaliser : déplacer la moitié de nos nœuds dans notre deuxième salle. En effet, afin de pouvoir intervenir facilement sur les machines physiques pendant la phase d’installation, nous avons tout déployé sur un même site. Bien nous en a pris d’ailleurs, aux vues de toutes les manipulations réalisées depuis quelques semaines ^^. L’opération en elle même est relativement simple : mettre en maintenance les 3 nœuds de l’appliance à déplacer, power-off, déménagement, câblage et relance.

Et la suite…

Une seule phrase résume assez bien la situation aujourd’hui : ce n’est que le début ! En effet, nous allons commencer à migrer nos premiers workloads sur le nouveau cluster d’administration d’ici la fin Janvier je pense et je pourrais vous faire un retour d’expérience “production” dans la foulée (notamment vis à vis de l’utilisation de l’emploi du Storage-vMotion cross-vCenter).

De plus, nous avons acquis très récemment un deuxième cluster VxRail (plus léger et non-stretched) qui sera dédié, quant à lui, à l’activité de pré-production et qualification. Là aussi, on retira une expérience non négligeable sur laquelle on pourra s’appuyer pour notre futur schéma directeur stockage/virtualisation. Celui-ci est dors et déjà prévu au premier semestre 2017 (plus d’information dans ce billet). Il y sera certainement question, entre autres, d’un gros investissement dans de l’hyper-convergé à l’horizon début 2018 pour remplacer notre TIER2 VMware actuel et VxRail fera forcément partie des prétendants de poids.