Hello les gens ! un grand bonjour, après plus de 3 mois de pause motivation, changement de perspective et re-faisage de monde. La rentrée est là, et les chantier techniques reprennent, avec des jolis projets, notamment, le recyclage de nos vieux VxRail et la mise en place d’un environnement tout neuf avec du VSAN, du NSX-T, du Cloud Director 10.3. Ce billet sera peut-être un peu « fourre-tout », mais il me permet de me remettre le pied à l’étrier du « retex » (ça me manquait, en fait) à la sauce vBlog.io ^^.
L’heure est aux chantiers techniques. Qu’est-ce que vous voulez, quand on a pu d’sous, on se débrouille avec ce qu’on a encore en stock. On troque notre habit d’architecte/acheteur contre celui de recyleur en chef ! Finalement, cela permet aussi de revenir aux fondamentaux, de reconstruire les choses, d’être plus efficace ou tout simplement, de moins faire souffrir la planète … Enfin, si l’on y ajoute le recul de plusieurs années de production « haut-de-gamme », c’est aussi un bon moyen de se faire plaisir et de faire SON TRAVAIL, ne nous le cachons pas. Nous sommes donc parti de deux environnements de production historiques VxRAIL, sortis du circuit récemment, mais composés encore de sacrées bestioles. Un ensemble de 12 machines à recycler, tout de même. L’objectif était de monter un nouveau cluster pour nos environnements de tests et qualifications divers, pouvoir mettre en place des labs « nested », des « bulles » où l’on peut évaluer et planifier plus tranquillement des mises à jours complexes ou risqués, etc. Cela nous manquait depuis des années, même si nous avons fait quelques tentatives de disposer de ce genre de choses, cela restait trop limité pour nos besoins.
Parlons technique le chantier consistait à :
– remonter un vCenter de test
– créer un nouveau cluster d’au moins 12 machines, avec des disques locaux compatibles avec du VSAN (Hybride
– créer une nouvelle instance NSX-T, indépendante de notre prod actuelle
– enfin y rajouter par dessus, la crème dans le café, la cerise sur le gâteau, un Cloud Director 10.3 permettant de consommer tout cela avec élégance et cloisonnement…
… un beau projet non ? Bien barbu et avec de la pression en prime, car le delivery, encore lui, nous « imposait » une livraison sous une dizaine de jours, maximum.
Je vous passe les détails sur la partie vCenter et ESXi, ce n’est pas le plus important et tout le monde ou presque sait faire en 2021. Ceci étant, il n’est pas inintéressant de rappeler qu’il faut bien penser à tout pour ne pas galérer ou perdre du temps pendant cette phase industrielle. Nous avons évoqué AutoDeploy, mais étant donné le périmètre, ça nous a semblé un peu trop lourd pour ce qui était en jeu. Donc, retour à de l’huile de coude. Je vous fais une petit liste qui pourra peut-être vous aider :
– Préparation de la futur topologie vSphere : un seul VLAN pour l’essentiel, sauf pour NSX-T et Geneve. En gros, deux VLAN pour l’ensemble.
– Préparation du VLAN mutualisé, des affectations d’IP
– Ré-inventaire de toutes les connexions à nos top-of-rack, nos switchs divers, vérification des connectiques
– Re-paramétrage de toutes les interfaces IPMI, iDrac (et autres ILO, si vous travaillez avec HPE)
– Extraction de tous les disques à l’exception des disques système (histoire de ne pas faire d’install incohérente et ne pas se poser de question sur la partition ESXi)
– Reformattage et installation d’ESXi 7.02a, via stick USB ou iso-CD.
– Configuration minimal du réseau de management, pour intégration à vCenter et utilisation des Host-Profiles
– Installation de vCenter 7.02 sur un autre cluster, temporairement pour piloter la reconfiguration de l’ensemble
– Reconnexion de tous les ESXi
– Création d’un nouveau cluster via le wizard « Quickstart ». Je ne sais pas si vous l’avez déjà utilisé, mais il est très efficace$
– Configuration VSAN après réinsertion et repartitionnement de tous les disques
– Changement de tous les certificats SSL vers une conformité avec notre PKI interne
Pour tout cela, il faut compter, si tout se passe bien, environ 3 jours. Première question, que je vois poindre le bout de sons nez : pourquoi virer VxRail et ne conserver que le commodity-hardware ? Je vais vous répondre franchement, mais rappelez-vous aussi les enjeux (plateforme de test et qualif, etc) : certes, on perd l’autoconfiguration, le guichet unique de Dell, la gestion complète des plateformes matérielles (firmware divers), la validation soft/hard et le packaging à la livraison, mais, je ne vous le cache pas, aujourd’hui je trouve que VxRail est moins « nécessaire » qu’il y a 3 ou 4 ans : vCloud Foundation et son orchestre sont désormais la nouvelle frontière et les contraintes intrinsèques du produit m’ont un peu refroidi ces dernières années (toujours des appels au support, avec une réactivité plus qu’aléatoire ces derniers mois). Ne vous méprenez-pas, VxRail est toujours parfait pour les aspects responsabilité sur la production critique et/ou institutionnelle, mais pour du test&dev&qual ou de la production « silver/bronze », non clairement, le full stack VMware est presque parfait aujourd’hui. Ceci d’autant plus que les prix sont de plus en plus serrés.
Nous avons donc un nouveau vcenter, un cluster VSAN/Compute tout neuf, full VMware. Il est temps de passer à NSX-T mon amour ^^. Je ne compte plus le nombre de réinstallations NSX au sein de mon vLab@Home depuis 2 ans (Je l’ai reconstruit très récemment d’ailleurs ! Un petit billet de renew/how-to/bilan de l’ancien ne serait pas inutile, au passage …). Cela paraissait une promenade de santé. Maiiiiis, NSX-T reste un produit où il faut être précis, tout vérifier et re-vérifier.
Bingo, cela n’a pas manqué, j’ai du passer 2 à 3 heures à débugguer un souci entre 2 edges Gateways et les Transport Nodes. Je vous passe les tests en tout genre et les ‘appels’ à des amis (notamment VincentF, de VMware, que je remercie encore pour sa disponibilité, une personne charmante et extrêmement compétente sur toutes les technos réseau). Au final, après la vérification de tous les paramètres NSX-T, je suis tombé sur la root-cause, encore ce FICHU MTU. Pour rappel, un flux réseau NSX-T encapsulé dans l’overlay GENEVE a besoin d’un MTU au moins égal à 1600 pour pouvoir transmettre sans souci des payload IP classiques de 1500 octets.
Sans blague, je vais me fendre d’un paragraphe rognotudju, à défaut d’un billet entier : DITES LES BARBUS DU RESEAU, vous pourriez pas définir le MTU de TOUS LES EQUIPEMENTS ET OS à 9000 qu’on arrête de passer des heures à chaque fois ? Vous êtes HYPER LOURDs avec ça. C’est pas comme si on bossait, en plus, avec des jumbo depuis plus de 5/10 ans …
C’est encore un enseignement sur lequel il faut capitaliser, toujours. Vérifiez bien que vos ping -s 8972 marchent correctement, même si, a priori « ya pas de raison ». Faites-le, vraiment. Pinguez, pinguez, re-pinguez, sur chaque VLAN impliqué, avec les bon payloads. Ne vous fiez pas à la route, vérifiez s’il n’y a pas une départementale en travaux au milieu de votre trajet autoroutier. On sait jamais, peut-être que votre gros SUV ne passera pas ^^. C’est à croire que la plus belle invention du réseau depuis plus de 40 ans et les début d’IP, c’est tout simplement ping et traceroute. Pour notre cas particulier, il se trouve que le MTU de nos Cisco Nexus sont associés aux VLAN, et pas « globaux ». Pensant avoir déjà traité la question lors de nos précédentes mises en production, je n’imaginait pas qu’il faille y revenir sur d’autres VLAN spécifiques.
A la fin de cette première étape. Notre environnement dispose d’un cluster complet, avec NSX-T en tête de gondole coté réseau. Tout est prêt pour accepter Cloud Director 10.3. Mais ceci est une autre histoire et c’est suffisant pour me sentir reprendre du poil de la bête, après une si longue absence sur ce blog …