Par Guillaume Caballé - The Expert Virtual Infrastructure,
Ingénieur Réseaux & Infrastructure Cloud chez SQUAD
Introduction
En Février 2017, VMware ajoutait le produit NSX-T à son catalogue : alors que la solution de Software-Defined Networking (SDN) NSX-V était déjà présente sur le marché, quels sont les différences entre ces deux produits, et quels sont les avantages / applications de NSX-T ? C'est ce que nous allons résumer dans cet article.
In the beginning, there was... NSX-V
La solution NSX-V (pour "NSX for vSphere") répond au besoin d'avoir une plateforme de déploiement de réseau virtualisé (SDN) pour les environnements VMWare. Selon eux, il est l'équivalent d'un hyperviseur réseau, capable de reproduire l'ensemble des services réseaux du Layer 2 au Layer 7. Il ne peut être lié qu'à une seule instance vSphere, limitant de ce fait son adoption dans les autres écosystèmes.
if "hypervisor" == "ESX" then NSX-V
NSX-V apparaît sous forme de plugin pour vSphere, où il est possible de provisionner une infrastructure réseau complète : Logical Switches, Distributed Logical Routers, Edge Firewall, Edge Services (DHCP, NAT, Load Balancing, VPN),…
L'un des principaux bénéfices apportés est de pouvoir réaliser un vMotion (déplacement de VMs) depuis un serveur ESXi vers un autre ESXi sans interruption de service réseau. Cela est rendu possible grâce au composant Distributed vSwitch qu'embarque la solution NSX-V. Il intègre également le protocole VXLAN pour tout ce qui concerne les réseaux d'overlay.
Depuis la version 6.1, il possède une meilleure gestion des environnements multi-tenants, néanmoins il n'est pas capable d'assurer une isolation réseau totale entre les clients.
NSX-T, un concurrent ?
NSX-T, dont l'acronyme signifie "NSX Transformers", se détache de son prédécesseur par son intégration avec des plateformes de virtualisation multiples : OpenStack (et KVM), mais aussi AWS et Azure (via l'offre NSX Cloud). Il supporte aussi les technologies de containerisation (Kubernetes, Pivotal, Openshift, Docker), en apportant une gestion complète de l'architecture réseau pour les flux des containers.
T pour "Third-Party"
À la différence de NSX-V, NSX-T est un produit séparé, et non un plugin, ce qui semble évident car un client n'a pas forcément besoin de posséder un environnement vSphere pour l'utiliser. L'appliance utilisée, le NSX Manager, est maintenant une VM pouvant être déployé sur vSphere ou bien sur KVM. Le composant NSX Edge, déployé auparavant automatiquement sur vSphere, peut désormais se déployer sur KVM ou bien sur un serveur baremetal.
T pour "Tunneling"
En outre, il intègre désormais le protocole GENEVE (Generic Network Virtualization Encapsulation, protocole co-écrit par
VMware, Microsoft, Red Hat et Intel) au lieu de VXLAN, permettant une gestion des metadatas plus poussée, et une légère amélioration de performance lors du traitement de paquets. L'adoption de ce nouveau protocole (toujours à l'état de draft auprès de l'IETF aujourd'hui), s'explique par plusieurs raisons :
- La fondation OpenStack se base sur le projet OVN et son OpenvSwitch pour la gestion de son control plane, et GENEVE a récemment été adopté comme protocole de tunneling par défaut pour OVN. Openstack va donc utiliser, dans un futur proche, GENEVE dans son implémentation d'OVS
- Le projet open-source OVN a été initialement lancé par l'équipe OpenvSwitch dans l'entreprise Nicira Networks, rachetée par VMWare en 2012 : cela a facilité / poussé l'utilisation de GENEVE dans la solution NSX-T
Bien qu'il soit plus récent, le produit apparait cependant comme l'aîné de NSX-V, par sa capacité à s'interfacer avec des solutions tierces. S'il est vrai que celui-ci paraissait moins complet que NSX-V à sa sortie (notamment sur la partie Identity Firewall ou encore le Service Insertion), avec plusieurs features absentes, il a depuis rattrapé son retard au fur et à mesure des versions, au point d'être aujourd'hui aussi complet.
Les principaux changements que l'on peut noter sur NSX-T sont :
- la compatibilité avec des hyperviseurs tiers et des clouds publics
- la configuration et le déploiement via NSX API (Infrastructure as Code)
- l'apparition de l'encapsulation GENEVE pour le transport des flux entre machines
- la gestion des flux de container à container
- la gestion multi-tenant (plusieurs clients provisionnés sur un même SDDC)
Conclusion :
Alors que NSX-V possède une affinité très forte avec vSphere, NSX-T va se détacher de cette contrainte pour s'adresser à des environnements multi-hyperviseurs.
En déclinant son produit, VMware indique qu'elle mise fortement sur NSX dans l'avenir. L'apparition de NSX-T témoigne de sa volonté d'offrir des solutions à des problématiques actuelles de SDDC, dans le but d'attirer de nouveaux clients. Par ailleurs, l'intégration avancée de nouvelles technologies (Docker, Kubernetes, Openstack, ou encore l'Infrastructure as Code) montre un souhait d'ouverture général.
Il sera intéressant de suivre les évolutions de ces gammes, et voir si elles resteront séparées, ou bien si celles-ci convergeront dans un futur proche. On peut déjà apercevoir un début de réponse sur la version 2.4 de NSX-T, qui unifie les interfaces des deux solutions pour qu'elles soient similaires.
