NSX-v vs NSX-T : comparaison complète

La virtualisation a révolutionné la manière dont les centres de données sont conçus. La plupart des centres de données modernes ont recours à la virtualisation matérielle et effectuent le déploiement de serveurs physiques en tant qu’hyperviseurs afin d’exécuter des machines virtuelles sur ces serveurs. Cette approche améliore l’évolutivité, la flexibilité et la rentabilité du centre de données. VMware est l’un des principaux acteurs du marché de la virtualisation et ses produits jouissent d’une excellente réputation dans le secteur informatique ; son hyperviseur VMware ESXi et VMware vCenter sont des composants largement reconnus de la solution de virtualisation VMware vSphere.

Le réseau est un élément crucial de tout centre de données, y compris les centres de données virtualisés, et si vous avez besoin de réseaux de grande envergure et de configurations réseau complexes pour votre centre de données virtualisé, envisagez d’utiliser les réseaux définis par logiciel (SDN). Le réseau défini par logiciel est une architecture qui vise à rendre les réseaux agiles et flexibles. L’objectif du SDN est d’améliorer le contrôle du réseau en permettant aux entreprises et aux fournisseurs de services de répondre rapidement à l’évolution des conditions à remplir. VMware se soucie de ses clients et propose la solution VMware NSX pour la mise en place de réseaux définis par logiciel. L’article de blog d’aujourd’hui traite de VMware NSX et explore la différence entre VMware NSX-v et VMware NSX-T.

NAKIVO pour la sauvegarde de VMware vSphere

Protection complète des données pour les machines virtuelles VMware vSphere et options de récupération instantanée. Cibles de sauvegarde sécurisées sur site, hors site et dans le cloud. Fonctionnalités anti-ransomware.

DÉCOUVREZ LA SOLUTION

Qu’est-ce que VMware NSX et comment l’utiliser ?

VMware NSX est une solution de virtualisation réseau qui permet de créer des réseaux définis par logiciel (SDN) dans des centres de données virtualisés. Tout comme les VMs sont dissociées du matériel des serveurs physiques, les réseaux virtuels, comprenant notamment des commutateurs, des ports, des routeurs, des pare-feu, etc., sont construits dans l’espace virtuel. Les réseaux virtuels sont provisionnés et gérés indépendamment du matériel sous-jacent. Les machines virtuelles sont connectées aux ports virtuels de commutateurs virtuels; la connexion entre les réseaux virtuels s’effectue via des routeurs virtuels, et les règles d’accès sont configurées sur des pare-feu virtuels. Par ailleurs, l’équilibrage de charge réseau est également disponible. VMware NSX est le successeur de VMware vCloud Networking & Security (vCNS)et de Nicira NVP, racheté par VMware en 2012.

Microsegmentation

Lorsqu’on utilise une approche traditionnelle pour configurer l’accès entre plusieurs réseaux dans un environnement virtuel, on effectue généralement le déploiement d’un routeur physique ou d’une passerelle périphérique fonctionnant sur une machine virtuelle, bien que cette approche ne soit ni particulièrement rapide ni pratique. VMware a mis en œuvre le concept de microsegmentation dans NSX à l’aide d’un pare-feu distribué intégré au cœur de l’hyperviseur. Les politiques de sécurité, ainsi que les paramètres d’interaction réseau pour les adresses IP, les adresses MAC, les VMs, les applications et autres objets, sont tous définis dans ce pare-feu distribué. Les règles peuvent être configurées à l’aide d’objets tels que les utilisateurs et groupes Active Directory si NSX est déployé au sein de votre entreprise où un contrôleur de domaine Active Directory (ADDC) est utilisé. Chaque objet peut être considéré comme un microsegment au sein de son propre périmètre de sécurité du réseau approprié, doté de sa propre zone démilitarisée (DMZ).

Le pare-feu distribué vous permet de segmenter les entités du centre de données virtuel, telles que les machines virtuelles. La segmentation peut s’appuyer sur les VM-Names et attributs des machines virtuelles, l’identité des utilisateurs, des objets vCenter tels que les centres de données et les hôtes, ou encore sur des attributs réseau traditionnels comme les adresses IP, les groupes de ports, etc.

Le composant « Edge Firewall » vous aide à répondre aux principales conditions à remplir en matière de sécurité périmétrique, telles que la création de DMZ basées sur des structures IP/VLAN, l’isolation entre locataires dans les centres de données virtuels multi-locataires, la traduction d’adresses réseau (NAT), les VPN partenaires (extranet) et les VPN SSL basés sur les utilisateurs.

Si une machine virtuelle est migrée d’un hôte à un autre — d’un sous-réseau à un autre —, les règles d’accès et les politiques de sécurité sont adaptées en fonction du nouvel emplacement. Si un serveur de base de données s’exécute sur une machine virtuelle (VM) migrée, les règles définies pour cette VM dans le pare-feu continueront de s’appliquer à celle-ci après la migration vers un autre hôte ou réseau, permettant ainsi au serveur de base de données d’accéder au serveur d’applications s’exécutant sur la VM qui n’a pas été migrée. Il s’agit là d’un exemple concret de la flexibilité et de l’automatisation accrues offertes par VMware NSX. NSX peut s’avérer particulièrement utile pour les fournisseurs de cloud et les grandes infrastructures virtuelles. VMware propose deux types de plateformes de réseau défini par logiciel NSX : NSX-v et NSX-T.

NSX pour vSphere (NSX-v) est étroitement intégré à VMware vSphere et nécessite le déploiement de l’ VMware vCenter. VMware NSX-v est spécifique aux environnements d’hyperviseur vSphere et a été développé avant NSX-T.

NSX-T (NSX-Transformers) a été conçu pour différentes plateformes de virtualisation et des environnements multi-hyperviseurs, et peut également être utilisé dans les cas où NSX-v n’est pas applicable. Alors que NSX-v ne prend en charge le SDN que pour VMware vSphere, NSX-T prend également en charge la pile de virtualisation réseau pour KVM, Docker, Kubernetes et OpenStack, ainsi que les Workloads natives d’AWS. VMware NSX-T peut être déployé sans vCenter Server et est adapté aux systèmes de calcul hétérogènes.

Les principaux scénarios d’utilisation de NSX-v sont répertoriés dans le tableau ci-dessous. Ce tableau est divisé en trois lignes, dont l’une décrit la catégorie de scénario. Les scénarios d’utilisation de NSX-T sont mis en évidence en gras.

Composants NSX

Les principaux composants de VMware NSX sont NSX Manager, les contrôleurs NSX et les passerelles NSX Edge.

NSX Manager est un composant centralisé de NSX utilisé pour la gestion des réseaux. NSX Manager peut être déployé en tant que machine virtuelle sur l’un des serveurs ESXi gérés par vCenter (à partir d’un modèle OVA). Si vous utilisez NSX-v, NSX Manager ne peut fonctionner qu’avec un seul serveur vCenter, tandis que NSX Manager pour NSX-T peut être déployé en tant que machine virtuelle ESXi ou KVM et peut fonctionner simultanément avec plusieurs serveurs vCenter. NSX Manager pour vSphere repose sur le Photon OS (similaire à vCenter Server Appliance).

NSX-T Manager fonctionne sous le système d’exploitation Ubuntu.

Contrôleurs NSX . Le contrôleur NSX est un système de gestion d’état distribué utilisé pour superposer des tunnels de transport et contrôler des réseaux virtuels ; il peut être déployé sous forme de machine virtuelle sur des hyperviseurs ESXi ou KVM. Le contrôleur NSX gère tous les commutateurs logiques au sein du réseau et traite les informations relatives aux VMs, aux hôtes, aux commutateurs et aux VXLAN. La présence de trois nœuds de contrôleur garantit la redondance des données en cas de défaillance d’un nœud du contrôleur NSX.

NSX Edge est un service de passerelle qui fournit aux VMs un accès aux réseaux physiques et virtuels. NSX Edge peut être installé en tant que routeur virtuel distribué ou en tant que passerelle de services. Les services suivants peuvent être fournis : routage dynamique, pare-feu, traduction d’adresses réseau (NAT), protocole de configuration dynamique des hôtes (DHCP), réseau privé virtuel (VPN), équilibrage de charge et haute disponibilité.

Options de déploiement

Le concept de déploiement est assez similaire pour NSX-v et NSX-T. Pour déployer NSX, vous devez suivre les étapes suivantes :

• Déployez NSX Manager en tant que machine virtuelle sur un hôte VMware ESXi à l’aide d’une appliance virtuelle. Veillez à enregistrer NSX Manager sur VMware vSphere vCenter (pour NSX-v). Si vous utilisez NSX-T, NSX Manager peut être déployé en tant qu’appliance virtuelle sur un hôte KVM, car VMware NSX-T vous permet de créer un cluster de NSX Managers.
• Effectuez le déploiement de trois contrôleurs NSX et créez un cluster de contrôleurs NSX.
• Installez VIBs (modules du noyau) sur les hôtes ESXi pour activer le pare-feu distribué, le routage distribué et VXLAN si vous utilisez NSX-v. Si vous utilisez NSX-T, les modules du noyau doivent également être installés sur les hyperviseurs KVM.
• Installez NSX Edge en tant que machine virtuelle sur ESXi (pour NSX-v et NSX-T). Si vous utilisez NSX-T et qu’il n’est pas possible d’installer Edge en tant que machine virtuelle sur ESXi, Edge peut être déployé sur un serveur physique. L’installation d’Edge en tant que machine virtuelle sur des hyperviseurs KVM n’est pas prise en charge pour le moment (pour NSX-T v.2.3). Si vous devez réaliser le déploiement d’Edge sur un serveur physique, consultez la liste de compatibilité matérielle (notamment pour les processeurs et les cartes réseau) avant de procéder.

Fonctionnalités communes à NSX

Il existe une série de fonctionnalités disponibles pour les deux types de NSX.

Les fonctionnalités communes à NSX-v et NSX-T sont les suivantes :

• Virtualisation de réseau logicielle
• Réseau superposé logiciel
• Routage distribué
• Pare-feu distribué
• Automatisation via API
• Surveillance et statistiques détaillées

Notez que les API diffèrent entre NSX-v et NSX-T.

Octroi de licences

Le système d’octroi de licences est identique pour les deux types de NSX, dans la mesure où il vous offre davantage de flexibilité et d’universalité. Par exemple, vous pouvez commander une licence pour utiliser NSX pour vSphere, et si vous apportez des modifications à votre infrastructure et devez réaliser le déploiement de NSX-T, vous pouvez utiliser la licence obtenue pour ESXi-v. NSX reste NSX : il n’y a aucune distinction du point de vue des licences, car les éditions de licence sont également les mêmes.

Encapsulation en superposition

L’encapsulation en superposition pour les réseaux virtuels est utilisée pour abstraire les réseaux virtuels en transportant les informations de couche 2 sur la couche 3. Un réseau logique de couche 2 est créé par-dessus les réseaux de couche 3 existants (réseaux IP) sur une infrastructure physique existante. Ainsi, deux VMs peuvent communiquer entre elles sur le réseau, même si le chemin entre elles doit être routé. Un réseau physique peut être appelé « réseau sous-jacent » (underlay network).

VXLAN vs GENEV

NSX-v utilise le protocole d’encapsulation VXLAN tandis que NSX-T utilise GENEVE qui est un protocole plus moderne.

VXLAN . Une encapsulation MAC sur IP est utilisée pour VXLAN et le principe de fonctionnement de l’isolation du réseau diffère de la technique VLAN. Le VLAN traditionnel dispose d’un nombre limité de réseaux, soit 4 094 selon la norme 802.1q, et l’isolation des réseaux s’effectue au niveau de la couche 2 d’un réseau physique en ajoutant 4 octets dans les en-têtes des trames Ethernet. Le nombre maximal de réseaux virtuels pour VXLAN est de 2^24. L’identifiant de réseau VXLAN est utilisé pour marquer chaque réseau virtuel dans ce cas. Les trames de couche 2 du réseau superposé sont encapsulées dans des datagrammes UDP transmis sur un réseau physique. Le numéro de port UDP est, dans ce cas, 4789.

L’en-tête VXLAN se compose des éléments suivants.

• 8 bits sont utilisés pour les indicateurs. L’indicateur I doit être défini sur 1 pour que l’en-tête VXLAN Network ID (VNI) soit valide. Les 7 bits restants correspondent à des champs R réservés qui doivent être mis à zéro lors de la transmission. Les champs R mis à zéro sont ignorés à la réception.
• VXLAN Network Identifier (VNI) , également appelé VXLAN Segment ID , est une valeur de 24 bits utilisée pour déterminer le réseau de superposition spécifique utilisé pour la communication entre les VMs.
• Les champs réservés (24 bits et 8 bits) doivent être mis à zéro et ignorés à la réception.

La taille de l’en-tête VXLAN est fixe et égale à 8 octets. L’utilisation de trames Jumbo avec une MTU définie à 1 600 octets ou plus est recommandée pour VXLAN.

GENEVE. L’en-tête « GENEVE » ressemble beaucoup à celui de VXLAN et présente la structure suivante :

• Un en-tête de tunnel compact est encapsulé dans UDP sur IP.
• Un petit en-tête de tunnel fixe est utilisé pour fournir des informations de contrôle, ainsi qu’un niveau de base de fonctionnalités et d’interopérabilité.
• Des options à longueur variable sont disponibles pour permettre la mise en œuvre de futures innovations.

La taille de l’en-tête GENEVE est variable.

NSX-T utilise GENEVE (GEneric NEtwork Virtualization Encapsulation) comme protocole de tunneling qui préserve les capacités traditionnelles de déchargement disponibles sur les cartes réseau (NIC) pour des performances optimales. Des métadonnées supplémentaires peuvent être ajoutées aux en-têtes de superposition et permettent d’améliorer la différenciation contextuelle pour le traitement d’informations telles que la télémétrie de bout en bout, le suivi des données, le chiffrement, la sécurité, etc. au niveau de la couche de transfert de données. Les informations supplémentaires contenues dans les métadonnées sont appelées « TLV » (Type, Longueur, Valeur). GENEVE est développé par VMware, Intel, Red Hat et Microsoft. GENEVE s’appuie sur les meilleurs concepts des protocoles d’encapsulation VXLAN, STT et NVGRE .

La valeur MTU pour les trames Jumbo doit être d’au moins 1 700 octets lors de l’utilisation de l’encapsulation GENEVE , en raison du champ de métadonnées supplémentaire de longueur variable pour les en-têtes GENEVE (une MTU de 1 600 ou plus est utilisée pour VXLAN, comme vous vous en souvenez).

NSX-v et NSX-T ne sont pas compatibles en raison de la différence d’encapsulation en superposition expliquée dans cette section.

Réseau de couche 2

Vous savez désormais comment les trames Ethernet virtuelles de couche 2 sont encapsulées sur les réseaux IP ; il est donc temps d’explorer la mise en œuvre des réseaux virtuels de couche 2 pour NSX-v et NSX-T.

Nœuds de transport et commutateurs virtuels

Les nœuds de transport et les commutateurs virtuels constituent les composants de transfert de données de NSX.

Nœud de transport (TN) : il s’agit de l’appliance compatible NSX participant à la transmission du trafic et à la superposition de la mise en réseau NSX. Un nœud doit contenir un commutateur hôte pour pouvoir servir de nœud de transport. NSX-v nécessite l’utilisation d’un commutateur virtuel distribué vSphere (VDS), comme c’est habituellement le cas dans VMware vSphere. Les commutateurs virtuels standard ne peuvent pas être utilisés avec NSX-v.

NSX-T suppose que vous deviez effectuer le déploiement d’un commutateur virtuel distribué NSX-T (N-VDS). Open vSwitches (OVS) sont utilisés pour les hôtes KVM, tandis que les commutateurs virtuels VMware sont utilisés pour les hôtes VMware ESXi et peuvent servir à cette fin.

N-VDS (commutateur virtuel distribué, anciennement appelé « hostswitch ») est un composant logiciel NSX situé sur le nœud de transport, qui assure la transmission du trafic. N-VDS est le composant principal du plan de données des nœuds de transport ; il achemine le trafic et dispose d’au moins un contrôleur d’interface réseau physique (NIC). NSX Switches (N-VDS) Les différents nœuds de transport sont indépendants, mais peuvent être regroupés en leur attribuant des noms identiques pour une gestion centralisée.

Sur les hyperviseurs ESXi, N-VDS est implémenté par le commutateur distribué VMware vSphere via le module NSX-vSwitch chargé dans le noyau de l’hyperviseur. Sur les hyperviseurs KVM, l’hostswitch est implémenté par le module Open-vSwitch (OVS) .

Les zones de transport sont disponibles à la fois pour NSX-v et NSX-T. Les zones de transport définissent les limites de la distribution des réseaux logiques. Chaque zone de transport est liée à son commutateur NSX (N-VDS). Les zones de transport pour NSX-T ne sont pas associées à des clusters.

Il existe deux types de zones de transport pour VMware NSX-T en raison de l’encapsulation GENEVE : Overlay ou VLAN. Quant à VMware NSX-v, une zone de transport définit uniquement les limites de distribution du VXLAN.

Modes de réplication des commutateurs logiques

Lorsque deux machines virtuelles résidant sur des hôtes différents communiquent directement, le trafic unicast est échangé en mode encapsulé entre deux adresses IP de points d’extrémité attribuées aux hyperviseurs, sans qu’il soit nécessaire de procéder à une diffusion. Parfois, le trafic réseau de couche 2 émis par une machine virtuelle doit être diffusé de la même manière que le trafic de couche 2 dans les réseaux physiques traditionnels, par exemple si un expéditeur ne connaît pas l’adresse MAC de l’interface réseau de destination. Cela signifie que ce même trafic (diffusion, monodiffusion, multidiffusion) doit être envoyé à toutes les VMs connectées au même commutateur logique. Si les VMs résident sur des hôtes différents, le trafic doit être répliqué vers ces hôtes. Le trafic de diffusion, de monodiffusion et de multidiffusion est également appelé trafic BUM.

Voyons la différence entre les modes de réplication pour NSX-v et NSX-T.

NSX-v prend en charge les modes monodiffusion, multidiffusion et hybride.

NSX-T prend en charge le mode monodiffusion avec deux options : Réplication hiérarchique à deux niveaux (optimisée, identique à celle de NSX-v) et réplication de tête (non optimisée).

La suppression ARP réduit le volume de trafic de diffusion ARP envoyé sur le réseau et est disponible pour les modes de réplication de trafic Unicast et Hybride. La suppression ARP est donc disponible à la fois pour NSX-v et NSX-T.

Lorsqu’une VM1 envoie une requête ARP pour connaître l’adresse MAC d’une VM2, cette requête est interceptée par le commutateur logique. Si le commutateur dispose déjà de l’entrée ARP correspondant au Réseau cible de la VM2, il envoie la réponse ARP à la VM1. Dans le cas contraire, le commutateur envoie la requête ARP à un contrôleur NSX. Si le contrôleur NSX contient les informations relatives à la liaison IP-MAC de la VM, il envoie la réponse avec cette liaison, puis le commutateur logique transmet la réponse ARP à la VM1. S’il n’y a pas d’entrée ARP sur le contrôleur NSX, la requête ARP est alors rediffusée sur le commutateur logique.

Pontage de couche 2 NSX

Le pontage de couche 2 est utile pour migrer des Workloads depuis des réseaux superposés vers des VLAN, ou pour répartir des sous-réseaux entre des Workloads physiques et virtuelles.

NSX-v : Cette fonctionnalité fonctionne au niveau du noyau d’un hyperviseur sur lequel s’exécute une machine virtuelle de contrôle.

NSX-T : Un nœud NSX-bridge distinct est créé à cette fin. Les nœuds NSX-bridge peuvent être regroupés en clusters afin d’améliorer la tolérance aux pannes de l’ensemble de la solution.

Dans la machine virtuelle de contrôle NSX-v, la redondance était assurée par le schéma de haute disponibilité (HA). Une copie de la VM est active tandis que la seconde est en veille. En cas de défaillance de la VM active, la bascule vers la VM de veille et son activation peuvent prendre un certain temps. NSX-T ne présente pas cet inconvénient, car il utilise un cluster tolérant aux pannes à la place du schéma actif/en veille pour la haute disponibilité.

Le modèle de routage

Lorsque vous utilisez VMware NSX, les termes suivants sont employés :

Trafic est-ouest désigne le transfert de données sur le réseau au sein du centre de données. Ce nom est utilisé pour ce type particulier de trafic, car les lignes horizontales sur les schémas indiquent généralement le trafic du réseau local (LAN).

Trafic nord-sud désigne le trafic client-serveur ou le trafic circulant entre un centre de données et un emplacement situé en dehors de celui-ci (réseaux externes). Les lignes verticales sur les schémas représentent généralement ce type de trafic réseau. Le routeur logique distribué (DLR) est un routeur virtuel capable d’utiliser des routes statiques et des protocoles de routage dynamiques tels que OSPF, IS-IS ou BGP.

Le terme « tenant » désigne un client ou une organisation bénéficiant d’un accès à un environnement sécurisé et isolé fourni par un fournisseur de services gérés (MSP). Une grande organisation peut recourir à une architecture multi-locataires en considérant chaque service comme un tenant distinct. VMware NSX peut s’avérer particulièrement utile pour fournir une infrastructure en tant que service (IaaS).

Routage dans NSX-v

NSX pour VMware vSphere utilise le DLR (routeur logique distribué) et le routage centralisé. Chaque hyperviseur dispose d’un module de routage au niveau du noyau permettant d’effectuer le routage entre les interfaces logiques (LIF) sur le routeur distribué.

Prenons, par exemple, le schéma de routage typique de NSX-v, lorsque vous disposez d’un ensemble de trois segments : des VMs exécutant des bases de données, des VMs exécutant des serveurs d’applications et des VMs exécutant des serveurs web. Les VMs de ces segments (bleu ciel, vert et bleu foncé) sont connectées à un routeur logique distribué (DLR) qui est lui-même connecté aux réseaux externes via des passerelles périphériques (NSX Edge).

Si vous travaillez avec plusieurs locataires, vous pouvez utiliser une architecture NSX Edge à plusieurs niveaux, ou bien chaque locataire peut disposer de son propre DLR dédié et de sa propre machine virtuelle de contrôleur, cette dernière résidant sur le cluster périphérique. La passerelle NSX Edge relie des réseaux isolés (stub) à des réseaux partagés (uplink) en fournissant des services de passerelle courants tels que le DHCP, le VPN, le NAT, le routage dynamique et l’équilibrage de charge. Les déploisements courants de NSX Edge incluent la zone DMZ, les extranets VPN et les environnements cloud multi-locataires où NSX Edge crée des frontières virtuelles pour chaque tenant.

Si vous devez acheminer du trafic depuis une machine virtuelle située dans le segment A (bleu) du premier tenant vers le segment A du deuxième tenant, le trafic doit transiter par la passerelle NSX Edge. Dans ce cas, il n’y a pas de routage distribué, car le trafic doit passer par un point unique, à savoir la passerelle NSX Edge désignée.

Vous pouvez également observer le principe de fonctionnement sur le schéma où les composants sont répartis en clusters : cluster de gestion, cluster Edge et cluster de calcul. Dans cet exemple, chaque cluster utilise 2 hôtes ESXi. Si deux VMs s’exécutent sur le même hôte ESXi mais appartiennent à des segments de réseau différents, le trafic transite par la passerelle NSX Edge située sur un autre hôte ESXi du cluster Edge. Après le routage, ce trafic doit être renvoyé vers l’hôte ESXi sur lequel s’exécutent les VMs source et destination.

Dans ce cas, l’itinéraire de transmission du trafic n’est pas optimal. Les avantages offerts par le routage distribué dans le modèle multi-locataires avec des passerelles Edge ne peuvent pas être exploités, ce qui entraîne une latence accrue pour votre trafic réseau.

Routage dans NSX-T

NSX-T utilise un modèle de routage distribué à deux niveaux pour résoudre les problèmes expliqués ci-dessus. Les nœuds Tier0 et Tier1 sont tous deux créés sur les nœuds de transport ; ce dernier n’est pas indispensable, mais vise à améliorer l’évolutivité.

Le trafic est acheminé via le chemin le plus optimal, car le routage est alors effectué sur l’hyperviseur ESXi ou KVM sur lequel s’exécutent les VMs. Le seul cas où un point de routage fixe doit être utilisé est lors de la connexion à des réseaux externes. Des nœuds Edge distincts sont déployés sur des serveurs exécutant des hyperviseurs.

Des services supplémentaires tels que BGP, NAT et Edge Firewall peuvent être activés sur les nœuds Edge, qui peuvent à leur tour être regroupés en cluster pour améliorer la disponibilité. De plus, NSX-T offre également une détection plus rapide des pannes. En termes simples, le meilleur moyen de répartir le routage est de le réaliser au sein même de l’infrastructure virtualisée.

Adressage IP pour les réseaux virtuels

Lorsque vous configurez NSX-v , vous devez élaborer un plan d’adressage IP au sein des segments NSX. Dans ce cas, il faut également ajouter des commutateurs logiques de transit qui relient les DLR et les passerelles Edge. Si vous utilisez un grand nombre de passerelles Edge, vous devez définir le schéma d’adressage IP pour les segments reliés par ces passerelles Edge.

NSX-T , en revanche, ne nécessite pas ces opérations. Tous les segments de réseau entre Tier0 et Tier1 obtiennent automatiquement des adresses IP. Aucun protocole de routage dynamique n’est utilisé ; à la place, des routes statiques sont employées et le système connecte automatiquement les composants, ce qui facilite la configuration ; vous n’avez pas besoin de passer beaucoup de temps à planifier l’adressage IP des composants du réseau de service (transit).

Intégration pour l’inspection du trafic

NSX-v offre une intégration avec des services tiers tels que des antivirus sans agent, des pare-feu avancés (pare-feu de nouvelle génération), des IDS (systèmes de détection d’intrusion), des IPS (systèmes de prévention d’intrusion) et d’autres types de services d’inspection du trafic. L’intégration avec les types d’inspection du trafic répertoriés s’effectue au niveau du noyau de l’hyperviseur à l’aide d’un bus protégé « VMCI » (Virtual Machine Communication Interface).

NSX-T ne propose pas ces fonctionnalités pour le moment.

Sécurité

Des pare-feu distribués au niveau du noyau peuvent être configurés pour NSX-v et NSX-T ; ils fonctionnent au niveau des adaptateurs virtuels des machines virtuelles. Des options de sécurité des commutateurs sont disponibles pour les deux types de NSX, mais l’option “Rate-limit Broadcast & Multicast traffic” n’est disponible que pour NSX-T.

NSX-T vous permet d’appliquer des règles de manière plus granulaire, ce qui se traduit par une utilisation plus rationnelle des nœuds de transport. Par exemple, vous pouvez appliquer des règles en fonction des objets suivants : commutateur logique, port logique, NSGroup. Cette fonctionnalité peut être utilisée pour réduire la configuration des ensembles de règles sur les instances de commutateur logique, de port logique ou de NSGroup, afin d’atteindre des niveaux plus élevés d’efficacité et d’optimisation. Vous pouvez également économiser de l’espace d’échelle et des cycles de recherche de règles, en plus de prendre en charge un déploiement multi-locataires, et d’appliquer des règles spécifiques aux locataires (règles qui s’appliquent aux Workloads du locataire concerné).

Le processus de création et d’application des règles est assez similaire pour NSX-v et NSX-T. La différence réside dans le fait que les politiques créées pour NSX-T sont envoyées à tous les contrôleurs, où les règles sont converties en adresses IP, tandis que dans NSX-v, les politiques sont immédiatement transférées vers vShield Firewall Daemon (VSFWD).

NSX-v vs NSX-T – Tableau comparatif

Maintenant que vous connaissez les fonctionnalités les plus intéressantes de VMware NSX, résumons les principales caractéristiques de NSX-v et NSX-T abordées dans cet article de blog, et comparons-les dans le tableau ci-dessous.

Conclusion

NSX-v est la solution la plus adaptée si vous utilisez uniquement un environnement vSphere, tandis que NSX-T peut être utilisé non seulement pour vSphere, mais aussi pour les plateformes de virtualisation KVM, Docker, Kubernetes et OpenStack dans le cadre de la mise en place de réseaux virtuels. Il n’y a pas de réponse unique à la question de savoir quel type de NSX est le meilleur. Le choix entre NSX-v et NSX-T dépend de vos besoins et des fonctionnalités offertes par chaque type de NSX.

La politique de licence NSX est simple : il vous suffit d’acheter une seule licence NSX, quel que soit le type de NSX que vous comptez utiliser. Par la suite, vous pourrez installer NSX-T dans un environnement NSX-v ou inversement, selon vos besoins, tout en continuant à utiliser votre licence NSX unique.

Vous pouvez créer votre propre centre de données défini par logiciel avec VMware en utilisant la solution NSX. VMware vous fournit fonctionnalités de regroupement pour garantir la continuité des opérations, la haute disponibilité et la tolérance aux pannes ; toutefois, la sauvegarde des machines virtuelles reste une mesure indispensable.

Sauvegardez régulièrement vos VMs de production liées à différents projets ainsi que celles fonctionnant en tant que composants de VMware vSphere et VMware NSX (telles que vCenter, NSX Manager, NSX Controller, NSX Edge) afin de protéger vos données. NAKIVO Backup & Replication peut vous aider à créer le VMware-Backup de manière fiable et efficace, même si vous utilisez des clusters.

Essayez NAKIVO Backup & Replication

Profitez d'un essai gratuit pour découvrir toutes les fonctionnalités de protection des données de la solution. 15 jours gratuits. Aucune restriction en termes de fonctionnalités ou de capacité. Aucune carte bancaire requise.

Essayez gratuitement