Mesdames, messieurs, Oyé Oyé, après moult discussions et un petit sondage rapide complètement pas représentatif sur Twitter, il semble qu’entre une découverte de vRealize Network Insight et NSX-T, ce dernier l’emporte largement. Je vais donc commencer, dans la mesure de mes moyens comme toujours, de vous faire découvrir (presque en même temps que moi en fait), NSX-T 2.4, depuis son installation jusqu’à, j’espère, son exploitation au quotidien après quelques mois en production (d’ici fin 2019). Programme chargé et très ambitieux, sachant, que, comme je l’ai souvent rappelé, les journées n’ont que 24h !

Je vous propose de commencer cette série par l’installation en mode lab, car, oui, notre projet est en cours et avance vite, mais nous n’en sommes pas encore à la mise en oeuvre (deuxième quinzaine de Mai si tout va bien). Mais, vous le savez, j’aime beaucoup découvrir les choses par moi-même, ça permet de faire des bêtises sans risque, de les comprendre, de s’interroger sur certaines fonctions obscures et surtout anticiper, autant que faire se peut, les besoins et les opportunités de PoC dans le futur.

On se lance ? En avant !

Installation de l’appliance.

NSX-T 2.4 est livré en une seule appliance qui va assurer le rôle de manager mais aussi de contrôleur (là ou les précédentes versions séparaient ces fonctions). Cette appliance s’installe très simplement, comme quasi toute les distributions de VMware aujourd’hui, via une OVA à importer.

Une fois les paramètres de base de la VM rentrés, on doit ensuite configurer à minima l’appliance avec divers mots de passe et options réseau. Rien de bien compliqué.

Après importation, ne perdons pas de temps, lançons la VM. Celle-ci démarre très vite et ping en quelques secondes, mais il faut environ 30 secondes pour que la bannière d’authentification soit disponible … et quelques dizaines de plus pour vraiment avoir une interface opérationnelle. Un boot sur les chapeaux de roues.

Configuration initiale.

On se connecte. Validons la CLUF, après l’avoir lu en entier bien sûr ! Je coche l’option “VMware Customer Experience Improvement Program”, plutôt deux fois qu’une sachant que cette instance se trouve sur mon Lab, c’est le moins que je puisse faire ^^. On se retrouve tout de suite sur un écran qui vous incite fortement à utiliser l’assistant, mais comme on est un peu ouf guedin sur ce blog, on va configurer le truc pas à pas, mais via les menus pour tâtonner, se planter, et comprendre ! Je vous ferai grâce de la partie hésitante, ne vous inquiétez-pas.

La première chose à faire consiste à enregistrer et préparer vos hyperviseurs ainsi que vos “computer managers” nécessaires notamment à la création des logical switch (mais on verra cela plus avant dans l’article). Ici, on va faire simple et se connecter directement au vCenter pour que NSX retrouve tout ce qu’il lui faut en une seule fois. (Techniquement, pour cette partie, il n’a pas forcément besoin d’une telle connexion pour travailler, un accès direct à ESXi ou un KVM suffit pour démarrer). On va se rendre dans la section “Compute Managers” et ajouter le vCenter en question.

Maintenant, rentrons dans le vif du sujet. Notre première opération va consister à créer une zone de transport de type VLAN. Pour l’instant, on ne va donc pas utiliser l’overlay GENEVE et juste créer des logical switchs (à la manière des portgroup sur des dvSwitchs vSphere classiques) “branchés” sur des VLAN physiques. Cela nous suffit pour pouvoir utiliser les fonctions de distributed firewall.

Dans la section Fabric-TransportZone, on va ajouter une nouvelle TZ “vlanTransportZone” et y associer un nouveau NVDS (NSX Virtual Distributed Switch, l’équivalent NSX-T de dvSwitch). On précise aussi qu’elle va être de type VLAN. Pa partie “Uplink teaming policies names” permet d’indiquer la liste des politiques d’uplink autorisées pour cette transport zone. Comme NSX-T c’est bien fichu, si on ne rentre rien, il applique la politique par défaut.

Il nous reste maintenant à configurer notre premier ESXi, c’est une opération “tout en un” qui installe les packages vib NSX-T (pas de reboot ni de mode maintenance, well done VMware !) et configure le nouveau nvds afin de pouvoir y déployer des logical switchs mappés sur des VLAN. Pour se faire, rendez-vous dans la section Fabric-Nodes. On choisit l’option Managed by : vLab, notre vCenter récemment intégré, sélectionner l’ESXi à installer (ici “vulcain”) et cliquez sur “Configure NSX”.

La configuration nécessite pas mal de paramètres. Prenons les dans l’ordre :
– La transportZone est celle que nous avons créé plus tôt.
– Le NVDS aussi, à savoir “nvds0”.
– Pour la partie encadrée en bleue on va choisir des options pré-configurées pour plus de facilité. Notamment, le Uplink profile indique que nous n’allons utiliser qu’une seule vmnic sur la machine, sans politique de teaming/failover d’aucune sorte.
– On indique ensuite qu’on ne souhaite pas exploiter le LLDP (un protocole L2 permettant, pour chaque port réseau, de fournir régulièrement des informations complètes du switch de raccordement, du type de lien etc. auquel un “peer” est branché. Ceux qui connaissent bien CDP savent de quoi je parle, c’est un équivalent).
– Enfin, on va préciser le nom de l’interface physique qui devra être “reliée logiquement” à l’uplink défini dans la fameuse politique sélectionnée plus haut, à savoir nsx-edge-single-nic-uplink-profile. Je ne sais si je suis très clair, mais en gros, vous mappez votre/vos interfaces physiques sur les uplinks définis dans les Uplink Profiles. C’est un niveau d’abstraction complémentaire à un dvSwitch classique où on vous demande de connecter directement vos interfaces.

Le reste est laissé tel quel et ne concerne que les cas où vous souhaitez réaliser une migration pour récupérer une interface vmnic déjà utilisée. C’est parti …

Notre ESXi est configuré !

On peut désormais créer des logical switchs, les portgroups de NSX-T. On va se déplacer dans le menu “Advanced Networking & Security”, puis dans Networking-Switching. L’ajout d’un LS est globalement très simple, un nom, un vlan associé et c’est tout par défaut (même si la partie Switching Profiles est particulièrement riche potentiellement, mais on va laisser de coté cette partie). Vous noterez qu’une fois créé, on dispose de tout un tas d’onglets de supervision, de gestion des ports créés, de gestion de la QoS etc. Tout ce qu’il faut, en somme pour gérer son switch au quotidien, comme on le ferait sur un switch physique.

… et … cerise sur le gâteau, la création du logical switch a évidemment créé celui-ci aussi sur vCenter, c’était le minimum. Bon, par contre, comme vous pourrez le constater sur le screenshot, aucune information sur ledit switch, étant donné que tout est géré du coté NSX-T, contrairement à NSX-V où on utilisait des dvSwitchs/Portgroups classiques. On peut commencer à s’amuser un peu. On va brancher une VM sur ce switch, aussi simplement que si on la changeait de portgroup. Comme pour un vmotion ou un changement de dvSwitch, la coupure de réseau est très courte mais on peut perdre un ping ou deux.

Accessoirement, vous pouvez noter aussi que les logical switch NSX-T apparaissent “nus”, sans un parent de type NVDS. J’avoue que j’aurais préféré qu’à la manière d’un distributed vswitch, on ait une petite hiérarchie pour regrouper les logical switchs. Il va falloir être vigilent pour les nommer correctement pour retrouver ce classement logique (par exemple nomDuNVDS-LogicalSwitch-suffixe).

Vous prendrez bien un peu de micro-segmentation ?

Notre petite VM de test “titan” est désormais à la merci de nos règles de segmentation ! On va commencer par modifier la règle par défaut, pour appliquer les best-practices de base d’une bonne sécurité, en la changeant de “Allow” à “Drop”. Tout se fait via des menus popup, très classiques, comme on en trouve dans quasi tous les systèmes pare-feu du marché depuis longtemps (ceux qui connaissent bien NSX-V ne seront pas perdus non plus). Ensuite on va ajouter une ou deux règles suivant différents critères pour autoriser l’ICMP et le ssh vers notre VM. Bref, je ne détaille pas trop, c’est relativement trivial.

Il va sans dire que lorsque vous opérez et que appliquer les nouvelles règles, celles-ci sont poussés quasi instantanément et le comportement réseau des objets affectés est modifié directement.

… à suivre !

Cette première partie s’achève et vous aura, j’espère, permis de découvrir un peu l’interface, l’ergonomie, la logique d’installation (au moins pour les premières étapes). J’espère aussi que cela vous aura mis un peu l’eau à la bouche pour la suite. Nous aborderons la prochaine fois la création d’une transport zone GENEVE, plus complexe à monter, car nécessitant le déploiement d’un Edge Node.

N’hésitez pas à poser vos questions dans les commentaires. Si je suis sec, ne vous inquiétez pas, j’ai des experts à disposition pour les prochaines semaines que je pourrai challenger à loisir, c’est cadeau ! (big up à Grégory, Romain, Alexis, Damien, Mickael …)