Alors, NSX-T ou NSX-V ?

Quelle question !

Si je devais résumer mes discussions sur le SDN depuis au moins 6 à 8 mois, je pense que ce serait celle-ci que je retiendrai, LE sujet central qui alimente l’essentiel des débats. En effet, aujourd’hui quasiment tous les techniciens, ingénieurs et architectes avec qui j’échange régulièrement s’accordent pour dire que la virtualisation de réseau est désormais une nécessité, un préalable à l’automatisation complète de la gestion de la sécurité et du cycle de vie des architectures virtuelles et plus généralement des environnements de production. Jusqu’à il y a environ deux ans, avant l’avènement des containers et de la consommation de cloud public, la problématique était certes déjà évoquée voire discutée, mais elle n’avait pas encore atteint la masse critique nécessaire pour devenir le centre des preoccupations de nombreuses directions informatiques.

Pour autant, si vous exploitez les technologies VMware actuellement, la question de départ, NSX-T ou NSX-V, peut sembler légitime et doit être de toutes façons travaillée avant d’y répondre.

Sans être un expert en SDN ni même un spécialiste du réseau d’une manière générale, je vous propose de vous présenter, de mon point de vue, les grandes différences entre les deux produits et surtout pourquoi nous avons fait un choix résolu vers NSX-T. Bouuuuh ! On va surement me jeter des pierres, tant j’ai entendu ici ou là de nombreux experts répondre régulièrement qu’il ne fallait pas comparer les deux. Sauf que, on va le voir, il faut malgré tout avoir des éléments pour faire le bon choix ^^.

Ce que j’ai retenu personnellement des nombreuses discussions que j’ai pu avoir sur NSX avec des experts reconnus (olé messieurs Alexis, Romain et Erik), on peut globalement catégoriser les grandes différences entre T et V. Cela permet de “faire son choix” plus facilement suivant les principaux objectifs recherchés.

Des différences conceptuelles

NSX-V et NSX-T reposent tous les deux sur un principe d’encapsulation des trames réseaux “internes”, mais n’exploitent pas les mêmes protocoles pour réaliser cet overlay sur le réseau physique.
– NSX-V exploite depuis longtemps le système VXLAN, utilisant des datagrammes UDP (donc niveau 3, routables) pour y intégrer une nouvelle couche “interne” niveau 2. C’est le protocole le plus ancien et historiquement le plus déployé. Sa principale limite aujourd’hui est liée à son implémentation : fondamentalement, VXLAN est dédié à l’encapsulation de VLAN
– NSX-T lui se base sur un nouveau protocole d’encapsulation plus générique (d’où son nom Generic Network Virtualisation Encapsulation) qui permet de s’adapter à des technologies actuelles de segmentation, comme les VLAN, mais aussi d’autres protocoles plus haut niveau et surtout à venir. De plus, ce nouveau système a été choisi par la communauté OpenStack comme le support des spécifications de OpenvSwitch, ce qui induit une compatibilité entre NSX-T et des environnements cloud public, exploitant largement les technologies Open Source.

Sans rentrer dans le détail, GENEVE est à VXLAN ce qu’IPv6 est à IPv4, en somme : plus extensible, plus riche, plus facile à faire évoluer. Si vous voulez aller plus loin, n’hésitez pas à vous rendre sur ces deux billets : LES RÉSEAUX D’OVERLAY : PRINCIPES ET FONCTIONNEMENT chez WeScale et What is GENEVE? chez RedHat.

En filigrane, je ne peux pas m’empêcher de penser que GENEVE semble aussi une réponse en forme de “troll technologique” à VXLAN, dans le sens où il faisait le boulot de manière efficace et était sans doute capable d’évoluer aussi. Un troll technologique, donc, mené par VMware, Microsoft, RedHat et Intel, notamment envers les pure-players du monde du réseau, Cisco en tête ^^. Maintenant, ça n’est qu’une interprétation et n’est certainement pas à prendre en compte dans un débat fondamental sur telle ou telle technologie, bien évidemment !

Différences fonctionnelles

– NSX-V est, par définition, un SDN VMware qui n’est implantable que sur un environnement vSphere/ESXi. Ceci le limite commercialement et stratégiquement à des écosystèmes plutôt “On premise”, traditionnellement. La stratégie de VMware est clairement tournée vers le cloud hybride depuis plusieurs années. Logique, donc, qu’elle pousse de plus en plus son grand frère NSX-T (oui, NSX-T est un grand frère de NSX-V, car il est directement issu du développement initial de la société Nicira, rachetée par VMware en 2012).
– NSX-T est quant à lui totalement agnostique. VMware vSphere est bien entendu un des environnements de virtualisation pris en charge, mais ce n’est pas le seul, puisque KVM est également parfaitement supporté. Il est également compatible et intégré aux technologies des containers (avec Pivotal PKS, notamment).

Malgré tout, à l’heure où j’écris ces lignes, NSX-T n’est pas encore totalement à niveau en matière de richesse fonctionnelle par rapport à NSX-V (notamment, l’architecture Tier0-Tier1 impose encore quelques contraintes aujourd’hui), mais l’objectif affiché de VMware est clair : arriver à l’équilibre au plus vite (il ne reste plus grand chose). Pour avoir un éclairage complémentaire, rendez-vous sur VMware NSX-V vs NSX-T Comparison de chez Vembu, l’éditeur de solutions de backup… que je n’ai toujours pas testé, honte à moi !

Différences opérationnelles

– NSX-V est, par nature encore une fois, un composant intégré à vSphere. La console se place comme un plug-in (désormais compatible avec le client HTML5) et est parfaitement lié à votre environnement de production.
– NSX-T est un produit séparé, disposant de sa propre console et surtout de ses propres concepts de déploiement (EdgNode, TierX routers etc.).

Cela peut paraître moins pratique au premier abord, je trouve l’approche beaucoup plus séduisante au final, car ne nous y trompons pas, NSX (V comme T) sont des produits destinés aux ingénieurs et techniciens réseaux/sécurité, pas spécialement aux ingénieurs et techniciens systèmes ! On entend souvent des peurs irrationnelles provenant des “anciens du réseau” qui se sentent dépossédés de leur travail par les ingénieurs plus généralistes qui travaillent depuis longtemps sur la virtualisation. Mais rassurez-vous, l’expertise réseau encore toute sa place à l’heure du SDN. Je dirais même que, plus encore, un ingénieur réseau/sécurité pourra être encore plus intégré à la production qu’auparavant où on ne “l’appelait” que lorsqu’on avait des flux publics à mettre en oeuvre (je schématise, mais vous avez compris l’idée).

Cycle de vie

Clairement, NSX-V est désormais dans sa phase de plateau et n’évoluera désormais qu’à la marge, alors que NSX-T est en train de monter en puissance. C’est une direction qu’il faut prendre en compte quand vous envisagez de déployer une nouvelle technologie aussi importante et stratégique pour vos datacenters. Pour cela, en particulier, NSX-T semble être la voix à prendre, si vous décidez de partir sur un SDN VMware, bien évidemment :)

Conclusion et décision

Vous l’avez compris entre les lignes, je pense, pour toutes les raisons présentées dans ce billet, nous avons fait un choix qui nous parait aujourd’hui évident et tourné vers l’avenir, à savoir NSX-T. Nous franchissons ici une marge plus importante encore, de mon point de vue, que notre démarche de bascule vers l’hyper-convergé, il y a un peu plus de 2 ans. Toujours plus de standardisation, toujours plus de software design, toujours plus d’automatisation potentielle !

Petit disclaimer pour terminer : n’étant pas un spécialiste (pas encore ^^) de NSX, n’hésitez pas à me reprendre si j’ai dit des bêtises indignes d’un professionnel, de même, si vous voulez apporter un éclairage sur certains aspects, lâchez-vous dans les commentaires ! Et grand merci d’avance à ceux qui se jetterons dans l’arène du Net ^^.