Install VxRail, partie 1 : laissez faire les machines …

Comme diraient les anglais, “It’s about time !”. Il est vrai que la mise en route de notre tout plus-très-nouveau-du-coup cluster d’administration basé sur VxRail pris pas mal de retard depuis son acquisition en juin dernier. Ceux qui veulent se rafraichir la mémoire avant de continuer à lire ce roman plein de suspens et de rebondissements peuvent se diriger vers ce billet qui en présente la genèse, celui-ci qui en relate son déballage, et celui-là, plus récent, qui explique plus précisément les causes du retard à l’allumage.

Il était temps, donc, qu’on puisse au moins mettre un nom sur la baïte. C’est en partie chose faite, après une journée d’efforts avec l’aide bienveillante de Pierre-Eric, Patrice et Noham (que je salue au passage). Vous allez le voir, on a tous appris beaucoup de choses et compris, par là même, la philosophie, une partie du fonctionnement et les limites actuelles d’un cluster vSphere/VSAN à la mode de Dell EMC.

Vous êtes prêts ? Ready ? Set ?…

Alors, déjà, VxRAIL 4.0, c’est bien ? Oui, sûrement, mais ce n’est toujours pas disponible !!

Et oui, malheureusement, malgré les efforts de nombreuses personnes et l’annonce récente de la version 4.0 de VxRail, il est encore impossible de disposer des images correspondant à cette release ! Quelle déception si prêt du but :( … En effet, le code lui-même semble stabilisé, mais la fusion Dell EMC a sans doute ajouté à la complexité d’une livraison d’une version majeure et la G.A. n’est toujours pas là.

Face à cette situation, j’avais deux choix : soit je reportais encore cette installation sine-die en attendant la dispo officielle de la 4.0, soit je maintenais l’install en 3.5 et devais me résoudre à y revenir via une upgrade ou une ré-installation complète ensuite. Après discussion avec les équipes de Dell EMC, j’ai finalement confirmé l’installation : au moins, cela permettrait de faire connaissance avec les procédures d’installation et de démarrage d’un VxRail et, accessoirement, essuyer les plâtres éventuels.

Enfin, il était vraiment temps de mettre en route le hardware, livré depuis plus de 3 mois maintenant.

VxRail : un outil industriel qui a ses limites et ses petites lignes

Nous avons commencé cette matinée chargée par une revue de paramétrage avec EMC tout en remplissant le document de pre-check. Déjà à ce niveau j’ai découvert pas mal de choses à savoir pour préparer l’arrivée d’un VxRail. Voici une petite liste des choses auxquelles il faut que vous fassiez attention.

Les règles de nommage de vos noeuds ESXi sont relativement strictes : vous définissez un préfix et une méthode de numérotation pour vos machines, ensuite, le process est complètement automatique. Si vous pensiez pouvoir nommer chaque ESX à votre convenance en fonction d’autres critères (par exemple les noeuds paires dans une salle et impaires dans l’autre, un préfixe spécial pour l’appliance 1 et un second pour l’appliance 2 etc. …), oubliez : l’assistant d’installation de VxRail est un outil de déploiement industriel qui a ses limites.

De même, concernant l’intégration du vCenter qui va accueillir le cluster, là aussi, vous avez des configurations limitées :
– Soit vous laissez VxRail déployer votre vCenter en mode PSC Embedded (tout simple, quoi) : pas de souci, ça marche comme sur des roulettes.
– Soit vous connectez VxRail à un vCenter existant (6.0U2) : là encore pas de souci, ça se connecte et s’installe correctement, mais attention aux licences (voir plus bas)
– Si vous voulez utiliser VxRail pour déployer un vCenter mais que vous souhaitez en outre qu’il soit client d’une PSC déjà déployée par ailleurs : pas possible.
– Si vous avez un vCenter externe en update 1 ou inférieur : pas possible non plus, en gros, vous devez être à jour (mais pas trop non plus, la 6.5 étant désormais GA)

Il s’agit aussi de bien comprendre comment les licences VMware associées à votre nouveau cluster sont attribuées et leurs limites d’utilisation. C’est en particulier vrai pour vCenter. Vous disposez en effet, sur le papier, d’une license “comprise dans le prix” de vCenter 6 Standard. Sauf que cette licence n’est utilisable QUE si vous choisissez l’option de déploiement automatisé du vCenter. Moi, benoitement, je pensais que lors de l’activation de l’appliance, nous allions recevoir par un moyen ou un autre des numéros de licences classiques à rentrer dans le gestionnaire de vSphere. Que nenni : en fait, ces licences (VSAN, vCenter, vRealize Log Insight) sont générées dynamiquement à l’installation et poussées par l’assistant dans la configuration vCenter.

Pour être clair, si vous voulez utiliser un mode d’installation sur un vCenter Externe pour diverses raisons, vous ne pourrez pas utiliser la licence fournie par VxRail ! Une mauvaise surprise pour moi, qui justement avait un budget serré pour ce projet… j’en suis quitte pour m’acheter une instance vCenter de plus. En effet, je souhaitais absolument connecter le nouveau vCenter à notre PSC externe (voir ce billet) pour disposer des avantages indéniables que cela procure au quotidien.

De même, vous aurez noté que vous disposez de licences vRealize Log Insight, également comprises dans le prix d’achat. Mais comme pour vCenter, elles ne sont utilisables que si vous choisissez de déployer ledit vCenter via l’assistant. Impossible de les utiliser autrement en les ajoutant à une instance vRLI existante, par exemple.

En résumé, on peut dire qu’à part les licences VSAN, toutes les autres licences VMware fournies ne sont utilisable que pour une installation qui part de zéro. Dès que vous souhaitez peu ou prou intégrer votre VxRail à une production existante, il n’est plus possible de profiter de celles-ci. A méditer lors du calcul de budget associé ! Evidemment, il s’agit d’une photo à Novembre 2016, peut-être que les choses vont évoluer à l’avenir, tout comme les options d’intégration… à suivre comme toujours.

Laissez faire l’assistant, il est plus intelligent que vous ne croyez ;)

Revenons à notre installation. Tout d’abord, matériellement, il faut savoir que chaque noeud dispose d’une interface réseau dédiée de management du matériel, à la manière des iDRAC ou iLO, que nous connaissons tous depuis longtemps. La configuration de ces interfaces est relativement simple, via le bios de chaque machine (nos noeuds sont basés sur des modèles Quanta). Cependant, sachez que VxRail ne les utilise pas du tout et passe directement par l’interface IPMI des ESXi. Donc, certes, c’est toujours mieux de les avoir à disposition, mais finalement, en dehors d’une nécessité impérieuse de prise de main à distance ponctuelle sur un node quelconque, ne perdez pas votre temps à les paramétrer, vous gagnerez une demi-heure.

D’autre part, les noeuds étant déjà pré-installés avec un ESXi, les machines bootent directement sur l’hyperviseur. Par défaut, chaque interface réseau est configurée en mode “access” sans tagging (comme avec un ESXi installé depuis une iso officielle VMware).

En version 3.5, la première appliance héberge un ESXi un peu spécifique qui inclut les VM nécessaires à l’administration et la création de l’environnement : un vCenter prêt à démarrer, un vRealize Log Insight sur les starting blocks et surtout, une VM VxRail Manager démarrée au boot avec une IP statique pré-configurée (192.168.10.200), tête de pont pour toute la mécanique d’installation assistée et d’administration du cluster. A priori (je vous confirmerai cela quand on aura pu mettre la main dessus), en 4.0, tous les noeuds sont identiques et une “élection” se produit pour désigner un noeud en particulier chargé de lancer la VM VxRail Manager la première fois.

En tout état de cause, nous, bon petits soldats habitués à tout configurer comme il faut avant de commencer à monter des clusters VMware, nous nous sommes attelés à changer les IPv4 de chaque ESXi, les tagguer correctement sur les bon VLAN etc etc. Oui, c’est bien, sauf que ce n’est pas nécessaire… on le verra plus tard.

Une fois nos 4 noeuds sur les bons VLAN, avec les bonnes IPs et la VM VxRail connectée comme il se doit sur le VLAN d’administration, nous avons enfin lancé l’assistant VxRail. Je vous passe quelques détails comme des petits soucis de user/role vCenter (j’y reviendrai dans un autre billet plus opérationnel), mais au final, nous avons lancé la dernière étape avant l’exécution des scripts d’installation : la validation de configuration. … suspens …

Et… bien, non ça ne passait pas. L’erreur principale, imparable était celle-ci (traduite en bon français) : “les IPs de vos ESXi rentrent en conflit avec les ranges d’IP que vous m’avez donné pour les paramétrer”. En gros, nous avions déjà configuré les ESXi avec leurs IPs cibles, pensant bien faire… mais non, on en a trop fait ! Résultat : l’assistant ayant détecté des IPs déjà utilisées, a refusé de lancer la configuration. Cela nous apprendra à penser “legacy” quand il fallait penser “hyperconvergé”. Accessoirement, on aurait gagné aussi quelques heures.

En fait, techniquement, pour profiter au mieux de l’assistant de configuration, il faut en faire le moins possible : contentez-vous de placer tous les serveurs ESXi et la VM VxRail Manager sur le même VLAN via les commandes fournies sur les documentations d’installation. Ne prenez pas de temps à configurer les IPv4 des noeud, et pour cause : toute la configuration réseau de VxRail est réalisée via la couche IPv6 des ESXi, avec l’aide d’un protocole d’auto-discovery des services réseau que les Mac Users connaissent bien : Bonjour/Zéroconf. Plus exactement, c’est la combinaison de l’autoconfig d’IPv6 et du mDNS/DNS-SD qui permet à VxRail de réaliser toutes les opérations initiales de détection des noeuds et de leur configuration cible sans avoir besoin de quoi que ce soit de préparé en IPv4. La encore, on sent un vrai changement de paradigme avec un cas concret et opérationnel des nombreux avantages de l’IPv6 (tiens, il faudra que je vous fasse un “Coup de gueule” sur IPv4 un jour …).

Conclusion de cette première journée

Malgré l’absence de dispo de VxRail 4.0, finalement, cette journée d’installation a été extrêmement intéressante, tant du point de vue de la technique pure que du coté de l’esprit et la manière d’aborder un déploiement VxRail. Demain, nous terminerons la mise en place via l’ajout des deux noeuds restants et quelques tests de migration de VMs et de divers tests de charge.