Install VxRail, partie 2 : Chad, please, free the 4.0 !

“Chad, please, free the 4.0”, le nouveau hastag Twitter : #ChadFreeThe4.0

Avant toute chose, désolé pour le titre un peu trollesque : je n’ai pas pu résister à chambrer Chad Sakac (il faut se permettre des choses incroyables dans la vie…), président de la division VCE de Dell EMC, qui a pourtant fait jouer ses relations pour essayer de nous faire obtenir la dernière version à temps, sans succès. De plus j’ai appris que Chad aimait parler Français quand il le pouvait, donc il lira peut-être ce modeste billet. Big Up, Chad !

Mais bon, trêve de plaisanteries, après une première journée riche en découvertes et rebondissements (voir ce billet), la seconde a été plus calme et a en très grande partie confirmé les conclusions de la veille. Notre cluster VxRail est désormais complètement opérationnel en 3.5 avec 6 Nœuds sur un seul site. Certes il n’est pas en configuration définitive, mais au moins, en attendant la GA de VxRail 4.0, il est fonctionnel et nous allons pouvoir éprouver ses performances et sa robustesse.

Voici un petit résumé des opérations réalisées.

et de 5 … et de 6 !

Nous avions quitté notre cluster VxRail hier soir avec une appliance complète de 4 nœuds opérationnels. Nous avons donc commencé par tenter d’ajouter un serveur supplémentaire. Comme déjà décrit hier, cette fois-ci, nous avons laissé la machine se débrouiller en ne paramétrant rien de plus que le VLAN d’administration via la console ESXi sans même affecter d’IPv4 (par défaut l’ESXi est en DHCP).

Malgré cela, la console VxRail n’affichait pas d’option “expand” (elle est sensée faire de l’auto-detect), ce qui signifiait qu’elle ne voyait pas arriver la nouvelle machine. En fait, il nous a fallut redémarrer la couche d’autoconfig et autodiscover présente sur l’ESXi dont le nom de code est “loudmouth” (joli nom d’ailleurs :) ). Une fois relancé le service (par une commande triviale /etc/init.d/loudmouth restart), la console a bien découvert le nouveau nœud et nous étions prêts à lancer la phase d’intégration au cluster.

L’assistant est relativement simple étant donné que tout a déjà été paramétré lors de la configuration initiale de VxRail : VLANs, ranges d’IPs, règles de nommage des ESXi etc. Malgré tout, lors du lancement de la procédure nous somme tombé sur un problème de connexion au vCenter. Là, pour le coup, ce n’était pas un souci d’interface chaise-clavier, mais bien d’un bug spécifique du code 3.5 vis à vis des credentials utilisés. Nous avons retrouvé rapidement une KB et appliqué la solution de contournement. Ce bug se manifeste uniquement lorsque vous utilisez un vCenter externe déjà installé : VxRail ne renseigne pas correctement le nom du user qui est sensé être utilisé mais tente l’accès systématiquement avec administrator@vsphere.local (du coup, si le mot de passe que vous avez rentré n’est pas celui de ce compte par défaut du SSO vCenter, ça ne fonctionnera pas). Il suffit de modifier un fichier de configuration application.properties situé dans la VM VxRail et tout rentre dans l’ordre.

Une fois ce premier nœud ajouté, le second a été une partie de plaisir : boot du serveur, modification du VLAN de management, reboot de l’ESXi, ajout via l’interface VxRail. Tout cela a duré moins de 10 minutes. Voila qu’on s’approche enfin des ordres de grandeur annoncés par EMC sur VxRail : effectivement, quand tout est prêt, installé et en nominal, l’ajout d’un nœud est une formalité.

Le file d’Ariane entre VxRail et sa maison mère : eSRS

La seconde partie de journée a consisté à connecter VxRail au support EMC via eSRS. Là encore, un assistant est disponible pour réaliser l’ensemble de l’opération. Je ne détaillerai pas trop cette partie car je n’étais pas présent pendant ce temps. Cependant, d’après le débriefing des collègues d’EMC, hormis un problème de Site-ID, indépendant de VxRail, l’intégration à eSRS s’est passée sans encombre. Il faut noter ici que malheureusement, à l’heure actuelle, vous ne pouvez pas utiliser une plateforme eSRS déjà installée chez vous (ce qui est notre cas). En effet, VxRail impose une VM dédiée pour les échanges avec les infrastructures d’EMC. La aussi, je pense que les choses vont sans doute évoluer dans l’avenir, mais c’est une contrainte spécifique à prendre en compte pour le moment. Encore une preuve, s’il en était encore besoin, que VxRail a vraiment été conçue pour être installé de manière totalement autonome, voir autarcique. Cela a un coté très séduisant quand vous montez une infrastructure toute neuve, mais quand vous souhaitez vous intégrer à une production existante, c’est plus compliqué et certaines limites doivent être anticipées.

Pour conclure en 3.5

Au final, ces deux jours ont été particulièrement instructifs et constructifs : ils m’ont permis de vraiment comprendre le fonctionnement général de VxRail et en voir les limites. C’est particulièrement important, à mon sens, quand vous comptez baser, peut-être, une grosse partie de votre production sur ce type de produit à l’avenir. Plus qu’un PoC, ce cluster d’administration va nous permettre aussi de vivre cette technologie et juger sur pièce. En cela, l’investissement initial est déjà bien parti pour être un succès, malgré les petits soucis et bugs de “jeunesse” qu’on pourra sans doute lui pardonner. Rappelez-vous que VxRail a à peine 6/8 mois d’existence concrète !

Pour résumé, c’est un excellent début, mais il reste encore beaucoup de travail avant la mise en production : le passage en 4.0 (je sais, je radote un peu, mais c’est à la hauteur de ma frustration actuelle ^^), la mise en place du stretched cluster VSAN et enfin, les tests de résilience.

A très vite pour la suite !