NSX-T : Chronique de notre déploiement

Bonjour à tous ! Tout d’abord, désolé pour le peu d’activité depuis début Mai sur le blog mais entre les ponts, les projets et les tonnes de chantiers divers à préparer, je n’avais que très peu de temps (et peu de motivation aussi en rentrant @home, disons-le) pour publier sur vBlog. Pourtant, j’ai des tonnes de choses à vous dire ^^. Pour commencer, je vous propose un retour intermédiaire sur notre phase de déploiement de NSX-T qui vient de commencer depuis Lundi 20 Mai dernier. Nous avons globalement bien avancé, après la relecture du dossier de spécification et le remplissage du fichier de configuration général. Petit récit de ce début de semaine.

Premier jour : quand les certificats SSL s’en mêlent, les heures défilent…

L’installation de NSX-T est relativement rapide en général, comme je l’ai déjà présenté lors de précédents billets. En gros, vous installez votre première appliance NSX Manager et ensuite, tout le reste se fait à travers l’interface graphique : déploiement des deux appliances complémentaires, installation des packages vib sur vos clusters de compute, déploiement des Edge Nodes etc. Par contre, la gestion des certificats SSL de NSX-T 2.4.0 est incomplète sur l’interface HTML : vous pouvez facilement générer des CSR pour chaque NSX Manager ainsi que pour la VIP du cluster ad-hoc, vous pouvez ensuite importer le certificat généré sur votre PKI interne, mais par contre, vous êtes obligé d’utiliser les API ReST pour appliquer ces certificats sur les bons composants internes … De plus, on a repéré un bug qui empêchait d’appliquer le certificat associé au service web porté par la VIP : à chaque fois, NSX réutilisait le certificat SSL auto-signé généré initialement lors de l’installation … Bref, compliqué, pas fini et buggué. Par chance, ça a fini par “tomber en marche” Mardi matin sans qu’on sache trop pourquoi.

EDIT du 23/05 : VMware a semble-t-il corrigé ce bug sur la nouvelle release, nous avons pu vérifier cela après notre upgrade en 2.4.1 (voir plus bas).

Deuxième jour : tout roule contrôle …

Après cet épisode des certificats SSL laborieux, la suite s’est très bien passée par contre :

• Préparation de notre cluster VxRail à l’implantation de NSX-T : il a fallut “transformer” notre cluster de 20 serveurs portant chacun 4 interfaces 10 Gigabit actives (réparties selon les best-practices DellEMC) à un cluster de 20 serveur sur 2 interfaces 10 Gigabit seulement. Il a donc fallut modifier les shares NIOC et sortir les interfaces du dvSwitch de production. Une opération sensible qui n’a finalement eu aucun impact visiblement sur nos quelques 620 VMs de production sur ce cluster.
  

  

• Installation/Déploiement de la couche NSX-T sur notre cluster “compute” : une fois préparé, nous avons d’abord déployé les vib sur un seul ESXi du cluster pour vérifier que tout se passait bien, puis généralisé l’opération sur les 19 machines restantes.
• Histoire de valider le bon fonctionnement post-installation, nous avons créé notre premier segment/logical-switch en utilisant la transport zone VLAN qui nous permettra d’implémenter la micro-segmentation sur notre production actuelle. Nous avons ensuite déplacé une VM de test sur ce segment et vérifié que le distributed firewall fonctionnait bien.
• Nous avons terminé l’après midi par le déploiement de notre cluster Edge constitué de deux Edge Nodes chez nous puis, en tout dernier, instancié un routeur TIER0.
  Enfin, on a terminé par quelques tests de connectivité entre notre routeur TIER0 et son partenaire de routage physique.

La journée de Mardi a été très chargée mais fructueuse. Nous étions parés hier pour pour terminer par la création de notre première “bulle NSX-T” via la mise en oeuvre d’un TIER1 et de quelques segments internes.

Troisième jour : NSX-T 2.4.1 est GA … sans blague !

C’est alors qu’hier soir, un de mes buddy du VMUG France, Alexis, balance un joli tweet “NSX-T 2.4.1 est GA !” … nan, vrai ? En pleine implémentation ! Ils sont joueurs chez VMware, je suis sûr qu’ils étaient au courant qu’on installait pile cette semaine et qu’ils se sont dit “on va bien les charrier ce Mercredi” … Ce matin, Mercredi, notre sang n’a fait qu’un quart de tour : c’est finalement une très bonne idée de mettre à jour, au moins on aura déroulé ce process une fois avant la production et de facto l’expérience qui va avec. Nous voila partis upgrader notre infrastructure NSX-T à peine sortie du carton ^^ (après avoir vérifié la matrice de compatibilité quand même … on est jamais assez prudent).

Pour l’instant et à l’heure où j’écris ces lignes, l’upgrade se passe très bien : NSX-T met en maintenance l’ESXi, upgrade les packages et ressort la machine de maintenance, donc pas de reboot (ça permet de gagner au moins 15/20 minutes par serveur). Nous en sommes à 7 ESXi réalisés en une heure.

EDIT du 23/05 : petit édit pour vous confirmer tout s’est terminé sans accro en début d’après-midi. Au total donc, environ 4 heures pour 20 serveurs ESXi, deux Edge nodes et 3 NSX Managers.

Entre temps, j’ai eu quelques précisions sur NSX-T 2.4.1 : en dehors des release notes officielles qui sont relativement légères (voir ici) : la “.1” est en fait particulièrement critique, intégrant de nombreuses corrections “sensibles”, et encore je n’utilise pas la terminologie dont on m’a parlé en off … En gros, comme souvent : n’installez pas la “.0” ^^.

Opérations à venir

La fin de semaine sera consacrée à créer notre TIER1 et terminer nos petits tests unitaires, revalider l’ensemble de la configuration et peut-être, si nous avons le temps, faire un test de restauration de la configuration NSX. Evidemment, je vous ferai un retour dès que possible.

Pour terminer, ne vous inquiétez pas, ma série sur la découverte de NSX-T n’est pas terminée, j’ai pas mal de retard sur la troisième partie, mais elle va sortir bientôt !