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 …)
4.5
Hello Cédric, tout d’abord merci de partager tes retours d’expérience concrètes (toujours sans langue de bois) !! J’ai eu l’occasion dernièrement de tester la 2.4 et j’ai fini par me dire qu’il était préférable de manière générale de créer un Logical Switch depuis la section Segment (au lieu du menu Advanced Networking…), qu’il soit de type Vlan ou Overlay. Ce point mériterait confirmation par les équipes VMware mais d’après moi l’usage du Segment permet de définir (si nécessaire) une passerelle locale à chaque ESX qui permet de traiter les flux inter-vlans comme du trafic Est-Ouest sans remonter vers les cœurs de réseau extérieurs. NSX se base alors sur une fonctionnalité du NSX Edge mais le flux ne remonte pas jusqu’au Edge, un Distributed Router portant la passerelle est distribué sur chaque Host (la même passerelle est donc présente sur chaque Host et isolée entre les Hosts par l’Overlay pour éviter l’overlapping) et le routage inter-vlan est géré au niveau du kernel de chaque Host. Dans un environnement ou le réseau est étendu entre 2 datacenters distants cette distribution des passerelles permet d’éviter nativement l’ effet « trombone ». Si il y a une volonté de traiter les flux inter-vlans comme du trafic Nord-Sud où les passerelles sont situées sur les cœurs de réseaux extérieurs, pas de soucis avec l’usage du Segment qui semble le permettre également. D’après ma compréhension, utiliser la rubrique « Advanced Networking » permet simplement de créer des Logical Switch et des Logical Router de type NFV, la passerelle peut ainsi très bien être déployée sur le Logical Router qui sera connecté via un Downlink Port au Logical Switch s’il est nécessaire de maintenir tous les flux sur les Hosts mais le transit du trafic se fera à travers l’appliance virtuelle NSX Edge et non au niveau du Host. A confirmer…
Hello Judum, alors déjà je sens que tu as un niveau de compétence bien supérieur au mien sous NSX-T, donc je serais bien embêté d’argumenter avec toi :) La deuxième chose, pour ce qui me concerne, j’ai trouvé la partie advanced & networking beaucoup plus claire à utiliser que que la partie networking, notamment au niveau segment et routeur, notamment.
Autant j’ai réussi à activer ce que je voulais dans adv net & sec, autant en passant par networking, c’était le binz total… malgré une relecture attentive de la doc NSX-T :)
Les questions sont intéressantes néanmoins… si c’est confirmé, ce serait quand même très surprenant de mon point de vue qu’une création de LS ou de routeur ne soit pas “câblée” de la même façon suivant par quel menu tu passes, mais à voir.
Oui difficile de connaître les meilleurs pratiques pour le moment…les Hands-on Lab ne sont pas en 2.4, la doc ne précise rien sur ce point, et je n’ai pas trouvé d’éclaircissement sur le forum communautaire VMware. J’ai d’abord cru que le Networking > Segments n’était qu’un Wizard, mais force est de constater que les fonctions offertes sont différentes entre les 2x menus. Dans quel intérêt?? Si tes interlocuteurs savent te répondre dans le cadre de tes ateliers la réponse serait intérèssante… Si j’ai une réponse d’ici là je la posterai ici :-) Julien.
Tout d’abord, chouette article Cédric !
Ensuite, je pense qu’il y a certains raccourcis qui sont fait dans les commentaires:
– la différence entre le menu “normal” et la partie “Advanced Networking & Security”, ce sont les APIs qui sont utilisées. Dans les onglets “Networking / Security / Inventory / Tools” (a.k.a. Simplified UI), c’est la nouvelle API qui est utilisée (Declarative Policy) alors que dans l’onglet “Advanced Networking & Security” c’est l’API historique qui est utilisée (Imperative Policy). A terme, seule la nouvelle API va rester, donc autant s’habituer. ;)
– segment = logical switch, pas de différence. Segment = 2.4, Logical Switch (before 2.4)
– si on créé un segment en mode VLAN, il n’y a pas de distributed routing. Ca reste du VLAN normal et le routage est à faire sur l’infra physique.
Merci Romain pour la correction!! C’est très clair.
Pour info, j’étais sur un lab en 2.3 depuis 2 mois, et j’ai migré en 2.4. Toute ma conf migrée était dans “advanced networking”. Je me demande si c’est pas pour de la compatibilité et que ces menus sont amenés à disparaitre pour éviter la confusion.
Bonjour,
Oui Joffrey je pense que tu as raison. La partie Advanced Networking va sans doute disparaitre dans les prochaines versions. Cela m’a été confirmé à demi mots par l’équipe de compte VMware avec laquelle je travaille. Selon Tom Gillis (le SVP/GM Réseaux / Sécurité VMware), la 2.4 est la plus importante release jamais sortie par VMware pour NSX. Elle introduit un certain nombre de breaking changes comme la partie Unified Appliance et le nouveau Policy Model. Dorénavant les choses devraient être plus stable selon lui. En tout cas je l’espère car difficile de développer sur leurs API si elles changent tous les quatre matins :(
5
bonsoir
Article intéressant, malheureusement destiné aux personnes ayant déjà installé et travaillé sous NSX. il aurait été intéressant d’avoir un schéma d’adressage vers quoi vous vouliez aller afin de suivre les config réseau, vswitch et attribution de nic soit en hand-lab ou prod. je reviendrai surement jeter un oeil pour suivre les faq et autres solutions.
Cordialement