La virtualisation a apporté des changements révolutionnaires dans la manière dont les datacenters sont construits. La majorité des datacenters modernes utilisent la virtualisation matérielle et déploient des serveurs physiques en tant qu’hyperviseurs pour exécuter des machines virtuelles sur ces serveurs. Cette approche améliore l’évolutivité, la flexibilité et l’efficacité économique du datacenter. VMware est l’un des principaux acteurs du marché de la virtualisation et ses produits sont très respectés dans l’industrie informatique, VMware ESXi Hypervisor et VMware vCenter étant des composants largement connus de la solution de virtualisation VMware vSphere.
Le réseau est un composant crucial de chaque datacenter, y compris des datacenters virtualisés, et si vous avez besoin de grands réseaux et de configurations réseau complexes pour votre datacenter virtualisé, envisagez d’utiliser le réseau défini 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 aux évolutions des besoins commerciaux. VMware se soucie de ses clients et propose la solution VMware NSX pour la construction de réseaux définis par logiciel. Le billet de blog d’aujourd’hui porte sur VMware NSX et explore la différence entre VMware NSX-v et VMware NSX-T.
Qu’est-ce que VMware NSX et comment peut-il être utilisé ?
VMware NSX est une solution de virtualisation réseau qui vous permet de construire des réseaux définis par logiciel dans des centres de données virtualisés. Tout comme les VM sont abstraites du matériel serveur physique, les réseaux virtuels comprenant 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 des commutateurs virtuels; la connexion entre les réseaux virtuels est effectuée avec des routeurs virtuels, et les règles d’accès sont configurées sur des pare-feu virtuels. Alternativement, l’équilibrage de charge réseau est également disponible. VMware NSX est le successeur de VMware vCloud Networking & Security (vCNS), et de Nicira NVP qui a été acquis par VMware en 2012.
La micro-segmentation
Lors de l’utilisation d’une approche traditionnelle pour configurer l’accès entre plusieurs réseaux dans un environnement virtuel, un routeur physique ou une passerelle de bord exécutant sur une machine virtuelle est généralement déployé, bien que cette approche ne soit pas particulièrement rapide ou pratique. VMware a mis en œuvre le concept de micro-segmentation dans NSX en utilisant un pare-feu distribué intégré au cœur de l’hyperviseur. Les politiques de sécurité, les paramètres d’interaction réseau pour les adresses IP, les adresses MAC, les machines virtuelles, les applications et autres objets sont tous définis dans ce pare-feu distribué. Les règles peuvent être configurées en utilisant des objets tels que des utilisateurs et des groupes Active Directory si NSX est déployé au sein de votre entreprise où le Contrôleur de Domaine Active Directory (ADDC) est utilisé. Chaque objet peut être considéré comme un micro-segment dans son propre périmètre de sécurité du réseau approprié qui dispose de sa propre DMZ (zone démilitarisée).
Le pare-feu distribué vous permet de segmenter des entités de centre de données virtuel telles que des machines virtuelles. La segmentation peut être basée sur les noms et les attributs des machines virtuelles, l’identité de l’utilisateur, les objets vCenter tels que les centres de données et les hôtes, ou peut être basée sur des attributs de réseau traditionnels tels que les adresses IP, les groupes de ports, etc.
Le composant Pare-feu de Bord vous aide à respecter les exigences clés en matière de sécurité périmétrique, telles que la construction de DMZ basées sur des constructions IP/VLAN, l’isolation entre locataires dans les centres de données virtuels multi-locataires, la Translation d’Adresse Réseau (NAT), les VPN de partenaires (extranet) et les VPN SSL basés sur l’utilisateur.
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 adoptées en fonction de la nouvelle localisation. Si un serveur de base de données est en cours d’exécution sur une machine virtuelle migrée, les règles définies pour cette machine virtuelle dans le pare-feu continueront de fonctionner pour cette machine virtuelle après la migration vers un autre hôte ou réseau est terminée, permettant au serveur de base de données d’accéder au serveur d’applications en cours d’exécution sur la machine virtuelle qui n’a pas été migrée. C’est un exemple d’amélioration de la flexibilité et de l’automatisation en action lors de l’utilisation de VMware NSX. NSX peut être particulièrement utile pour les fournisseurs de cloud et les grandes infrastructures virtuelles. VMware propose deux types de plateforme réseau définie par logiciel NSX – NSX-v et NSX-T.
NSX for vSphere (NSX-v) est étroitement intégré à VMware vSphere et nécessite le déploiement du VMware vCenter. VMware NSX-v est spécifique aux environnements 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 environnements multi-hyperviseurs et peut également être utilisé dans les cas où NSX-v n’est pas applicable. Alors que NSX-v prend en charge le SDN uniquement pour VMware vSphere, NSX-T prend également en charge le stack de virtualisation réseau pour KVM, Docker, Kubernetes, OpenStack ainsi que les charges de travail natives AWS. VMware NSX-T peut être déployé sans serveur vCenter et est adopté pour des 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. Le tableau est divisé en trois lignes, dont une décrit la catégorie de scénario. Les scénarios d’utilisation de NSX-T sont mis en évidence en gras.
| Sécurité | Automatisation | Continuité d’application |
| Micro-segmentation | Automatisation IT | Reprise après sinistre |
| Utilisateur final sécurisé | Cloud pour développeurs | Regroupement multi-centres de données |
| DMZ partout | Infrastructure multi-locataire | Multi-cloud |
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 du modèle OVA). Dans les cas où vous utilisez NSX-v, NSX Manager peut fonctionner 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 avec plusieurs serveurs vCenter à la fois.
NSX Manager pour vSphere est basé sur le système d’exploitation Photon OS (similaire à l’appliance vCenter Server).
NSX-T Manager fonctionne sur le système d’exploitation Ubuntu.
Contrôleurs NSX : Le contrôleur NSX est un système de gestion d’état distribué utilisé pour les tunnels de transport de superposition et le contrôle des réseaux virtuels. Il peut être déployé en tant que machine virtuelle sur des hyperviseurs ESXi ou KVM. Le contrôleur NSX gère tous les commutateurs logiques au sein du réseau et gère les informations relatives aux machines virtuelles, hôtes, commutateurs et VXLAN. Disposer de trois nœuds de contrôleur garantit la redondance des données en cas de défaillance d’un nœud de contrôleur NSX.
NSX Edge : Il s’agit d’un service de passerelle qui fournit un accès aux réseaux physiques et virtuels pour les machines virtuelles. NSX Edge peut être installé en tant que routeur virtuel distribué ou passerelle de services. Il offre les services suivants : routage dynamique, pare-feu, traduction d’adresses réseau (NAT), protocole de configuration dynamique d’hôte (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. Voici les étapes à suivre pour déployer NSX :
Déployez NSX Manager en tant que machine virtuelle sur un hôte ESXi à l’aide d’un appareil virtuel. Veillez à enregistrer NSX Manager sur vSphere vCenter (pour NSX-v). Si vous utilisez NSX-T, vous pouvez déployer NSX Manager en tant qu’appareil virtuel sur un hôte KVM, car VMware NSX-T vous permet de créer un cluster de gestionnaires NSX.
-
Déployez trois contrôleurs NSX et créez un cluster de contrôleurs NSX.
-
Si vous utilisez NSX-v, installez les VIB (modules du noyau) sur les hôtes ESXi pour activer le pare-feu distribué, le routage distribué et VXLAN. 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 déployer Edge sur un serveur physique, vérifiez la liste de compatibilité matérielle (important pour les processeurs et les cartes réseau) avant de le faire.
Capacités communes de NSX
Il existe une série de capacités disponibles pour les deux types de NSX.
Les capacités communes pour NSX-v et NSX-T sont les suivantes :
- Virtualisation réseau basée sur logiciel
- Overlay basé sur logiciel
- Routing distribué
- Pare-feu distribué
- Automatisation pilotée par API
- Surveillance détaillée et statistiques
Sachez que les API sont différentes pour NSX-v et NSX-T.
Licences
Les licences sont les mêmes pour les deux types de NSX, elles offrent donc plus 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 déployer NSX-T, vous pouvez utiliser la licence obtenue pour ESXi-v. NSX est NSX – il n’y a pas de distinction du côté des licences, car les éditions de licence sont également les mêmes.
Encapsulation de l’overlay
L’en-tête VXLAN se compose des parties suivantes.
8 bits sont utilisés pour les indicateurs. Le drapeau I doit être réglé sur 1 pour rendre un identifiant de réseau VXLAN (VNI) valide. Les 7 autres bits sont des champs R réservés qui doivent être réglés sur zéro lors de la transmission. Les champs R réglés sur zéro sont ignorés à la réception.L’identifiant de réseau VXLAN (VNI), également connu sous le nom d’identifiant de segment VXLAN, est une valeur de 24 bits utilisée pour déterminer le réseau de superposition individuel utilisé pour la communication entre les machines virtuelles.
Les champs réservés (24 bits et 8 bits) doivent être réglés sur zéro et ignorés à la réception.
GENEVE. L’en-tête GENEVE ressemble beaucoup à VXLAN et a la structure suivante :
Des options de 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 ( GE néricN etworkV irtualizationE ncapsulation) en tant que protocole de tunnelisation qui préserve les capacités traditionnelles de déchargement disponibles sur les NIC (contrôleurs d’interface réseau) pour une meilleure performance. 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 des informations telles que la télémétrie de bout en bout, le suivi des données, le chiffrement, la sécurité, etc. sur la couche de transfert de données. Les informations supplémentaires dans les métadonnées sont appelées TLV (Type, Longueur, Valeur). GENEVE est développé par VMware, Intel, Red Hat et Microsoft. GENEVE est basé sur les meilleurs concepts des protocoles d’encapsulation VXLAN, STT et NVGRE. - L’identifiant de réseau VXLAN (VNI), également connu sous le nom d’identifiant de segment VXLAN, est une valeur de 24 bits utilisée pour déterminer le réseau superposé individuel utilisé pour communiquer entre les machines virtuelles.
- Les champs réservés (24 bits et 8 bits) doivent être mis à zéro et ignorés à la réception.
A size of the VXLAN header is fixed and is equal to 8 bytes. Using Jumbo frames with MTU set to 1600 bytes or more is recommended for VXLAN.
GENEVE. L’en-tête GENEVE ressemble beaucoup à VXLAN et a la structure suivante:
- A compact tunnel header is encapsulated in UDP over IP.
- A small fixed tunnel header is used to provide control information, as well as a base level of functionality and interoperability.
- Des options de longueur variable sont disponibles pour rendre possible la mise en œuvre d’innovations futures.
La taille de l’en-tête GENEVE est variable.
NSX-T utilise GENEVE (GEneric NEtwork Virtualization Encapsulation) en tant que protocole de tunnelisation qui préserve les capacités traditionnelles de délestage disponibles sur les cartes réseau pour des performances optimales. Des métadonnées supplémentaires peuvent être ajoutées aux en-têtes superposés et permettent d’améliorer la différenciation de contexte pour le traitement des 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 des données. Les informations supplémentaires dans les métadonnées sont appelées TLV (Type, Longueur, Valeur). GENEVE est développé par VMware, Intel, Red Hat et Microsoft. GENEVE est basé sur les meilleurs concepts des protocoles d’encapsulation VXLAN, STT et NVGRE.
La valeur de l’unité de transfert maximale (MTU) pour les trames Jumbo doit être d’au moins 1700 octets lors de l’utilisation de l’encapsulation GENEVE, ce qui est dû au champ de métadonnées supplémentaire de longueur variable pour les en-têtes GENEVE (une MTU de 1600 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 superposée expliquée dans cette section.
Réseau de couche 2
Maintenant que vous savez comment les trames Ethernet de la couche 2 virtuelle sont encapsulées sur les réseaux IP, il est temps d’explorer la mise en œuvre des réseaux de couche 2 virtuelle pour NSX-v et NSX-T.
Nœuds de transport et commutateurs virtuels
Les nœuds de transport et les commutateurs virtuels représentent les composants de transfert de données NSX.
Nœud de transport (TN) est le dispositif compatible NSX participant à la transmission du trafic et à la superposition de 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 du commutateur virtuel distribué vSphere (VDS) comme d’habitude dans vSphere. Les commutateurs virtuels standard ne peuvent pas être utilisés pour NSX-v.
NSX-T suppose que vous devez déployer un commutateur virtuel distribué NSX-T (N-VDS). Les commutateurs Open vSwitch (OVS) sont utilisés pour les hôtes KVM et les commutateurs VMware sont utilisés pour les hôtes ESXi peuvent être utilisés à cette fin.
N-VDS (virtual distributed switch that is previously known as a hostswitch) is a software NSX component on the transport node, that performs traffic transmission. N-VDS is the primary component of the transport nodes’ data plane that forwards traffic and owns at least one physical network interface controller (NIC). NSX Switches (N-VDS) of the different transport nodes are independent but can be grouped by assigning the same names for centralized management.
Sur les hyperviseurs ESXi, N-VDS est implémenté en utilisant le commutateur distribué VMware vSphere à travers le module NSX-vSwitch qui est chargé dans le noyau de l’hyperviseur. Sur les hyperviseurs KVM, le commutateur hôte est implémenté par le module Open-vSwitch (OVS).
Zones de transport sont disponibles pour NSX-v et NSX-T. Les zones de transport définissent les limites de 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 liées à des clusters.
Il existe deux types de zones de transport pour VMware NSX-T en raison de l’encapsulation GENEVE : superposition ou VLAN. Quant à VMware NSX-v, une zone de transport définit les limites de distribution du VXLAN uniquement.
Les modes de réplication de commutation logique
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 point de terminaison attribuées aux hyperviseurs sans nécessité de diffusion. Parfois, le trafic réseau de couche 2 d’origine par une VM 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 émetteur ne connaît pas l’adresse MAC de l’interface réseau de destination. Cela signifie que le même trafic (diffusion, unicast, multicast) doit être envoyé à toutes les VM connectées au même commutateur logique. Si les VM résident sur des hôtes différents, le trafic doit être répliqué vers ces hôtes. Le trafic de diffusion, unicast et multicast est également connu sous le nom de trafic BUM.
Regardons la différence entre les modes de réplication pour NSX-v et NSX-T.
NSX-v prend en charge le mode unicast, le mode multicast et le mode hybride.
NSX-T prend en charge le mode unicast avec deux options : la réplication hiérarchique à deux niveaux (optimisée, la même que pour NSX-v) et la réplication de tête (non optimisée).
La suppression ARP réduit la quantité de trafic de diffusion ARP envoyé sur le réseau et est disponible pour les modes de réplication de trafic unicast et hybride. Ainsi, la suppression ARP est 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, la requête ARP est interceptée par l’échangeur logique. Si l’échangeur possède déjà l’entrée ARP pour l’interface réseau cible de la VM2, la réponse ARP est envoyée à la VM1 par l’échangeur. Sinon, l’échangeur envoie la requête ARP à un contrôleur NSX. Si le contrôleur NSX contient les informations sur le lien entre l’adresse IP et l’adresse MAC de la VM, le contrôleur envoie la réponse avec ce lien et ensuite l’échangeur logique envoie la réponse ARP à la VM1. Si aucune entrée ARP n’est présente sur le contrôleur NSX, alors la requête ARP est re-diffusée sur l’échangeur logique.
Pontage NSX de niveau 2
Le pontage de niveau 2 est utile pour migrer des charges de travail des réseaux superposés aux VLAN, ou pour diviser des sous-réseaux entre charges de travail physiques et virtuelles.
NSX-v: Cette fonctionnalité fonctionne au niveau du noyau d’un hyperviseur sur lequel une VM de contrôle est en cours d’exécution.
NSX-T: Un nœud NSX-bridge distinct est créé à cette fin. Les nœuds NSX-bridge peuvent être assemblés en clusters pour améliorer la tolérance aux pannes de l’ensemble de la solution.
Dans la VM de contrôle NSX-v, la redondance a été mise en œuvre en utilisant le schéma de Haute Disponibilité (HA). Une copie de la VM est active tandis que la seconde copie de la VM est en attente. Si la VM active échoue, cela peut prendre un certain temps pour basculer les VMs et charger la VM en attente en la rendant active. NSX-T ne présente pas cette inconvénient, car un cluster tolérant aux pannes est utilisé à la place du schéma actif/en attente pour la HA.
Le modèle de routage
Dans les cas où vous utilisez VMware NSX, les termes suivants sont utilisés :
Le trafic est-ouest fait référence au transfert de données sur le réseau à l’intérieur du centre de données. Ce nom est utilisé pour ce type particulier de trafic car les lignes horizontales sur les diagrammes indiquent généralement le trafic du réseau local (LAN).
Le trafic nord-sud fait référence au trafic client-serveur ou au trafic qui se déplace entre un centre de données et un emplacement à l’extérieur du centre de données (réseaux externes). Les lignes verticales sur les diagrammes décrivent généralement ce type de trafic réseau.
Routeur logique distribué (DLR) est un routeur virtuel qui peut utiliser des routes statiques et des protocoles de routage dynamiques tels que OSPF, IS-IS ou BGP.
Locataire fait référence à un client ou à une organisation qui obtient l’accès à un environnement sécurisé isolé fourni par un fournisseur de services gérés (MSP). Une grande organisation peut utiliser une architecture multi-locataire en considérant chaque département comme un locataire unique. VMware NSX peut être particulièrement utile pour fournir de l’infrastructure en tant que service (IaaS).
Le routage dans NSX-v
NSX pour vSphere utilise le DLR (routeur logique distribué) et le routage centralisé. Il y a un module de routage noyau sur chaque hyperviseur sur lequel effectuer le routage entre les interfaces logiques (LIFs) sur le routeur distribué.
Considérons, par exemple, le schéma de routage typique pour NSX-v, lorsque vous avez un ensemble de trois segments : des VM exécutant des bases de données, des VM exécutant des serveurs d’application et des VM exécutant des serveurs web. Les VM de ces segments (bleu ciel, vert et bleu foncé) sont connectées à un routeur logique distribué (DLR) qui est à son tour connecté à des réseaux externes via des passerelles de périphérie (NSX Edge).
Si vous travaillez avec plusieurs locataires, vous pouvez utiliser une construction de NSX Edge à plusieurs niveaux, ou chaque locataire peut avoir son propre DLR et sa propre machine virtuelle de contrôleur, ce dernier résidant dans le cluster Edge. Le passerelle NSX Edge relie les réseaux isolés, résiduels aux réseaux partagés (uplink) en fournissant des services de passerelle courants tels que DHCP, VPN, NAT, routage dynamique et équilibrage de charge. Les déploiements courants de NSX Edge incluent dans la DMZ, les VPN Extranets et les environnements Cloud multi-locataires où le NSX Edge crée des frontières virtuelles pour chaque locataire.
Si vous devez transmettre le trafic d’une machine virtuelle située dans segment A (bleu) du premier locataire à segment A du deuxième locataire, le trafic doit passer par la passerelle NSX Edge. Dans ce cas, il n’y a pas de routage distribué, car le trafic doit passer par le seul point qui est la passerelle NSX Edge désignée.
Vous pouvez également voir le principe de fonctionnement sur le schéma sur lequel les composants sont divisés en clusters : cluster de gestion, cluster Edge et cluster de calcul. Dans cet exemple, chaque cluster utilise 2 hôtes ESXi. Si deux machines virtuelles fonctionnent sur le même hôte ESXi mais appartiennent à des segments réseau différents, le trafic passe par la passerelle NSX Edge qui est située sur un autre hôte ESXi du cluster Edge. Après routage, ce trafic doit être transmis à l’hôte ESXi sur lequel les machines virtuelles source et destination sont en cours d’exécution.
La route de transmission du trafic n’est pas optimale dans ce cas. Les avantages disponibles pour le routage distribué dans le modèle multi-locataire avec des passerelles Edge ne peuvent pas être utilisés, ce qui entraîne une plus grande latence 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 niveaux Tier0 et Tier1 sont tous deux créés sur les nœuds de transport, ce dernier n’étant pas nécessaire mais est destiné à améliorer la scalabilité.
Le trafic est transmis en utilisant le chemin le plus optimal, car le routage est alors effectué sur l’hyperviseur ESXi ou KVM sur lequel les machines virtuelles s’exécutent. Le seul cas où un point fixe de routage doit être utilisé est lors de la connexion à des réseaux externes. Des nœuds Edge séparés sont déployés sur des serveurs exécutant des hyperviseurs.
Des services supplémentaires tels que BGP, NAT et le pare-feu Edge peuvent être activés sur les nœuds Edge, qui peuvent à leur tour être combinés en un cluster pour améliorer la disponibilité. De plus, NSX-T fournit également une détection de défaillance plus rapide. En termes simples, la meilleure façon de distribuer le routage est de router à l’intérieur de l’infrastructure virtualisée.
Adressage IP pour les réseaux virtuels
Lorsque vous configurez NSX-v, vous devez composer un plan d’adressage IP à l’intérieur des segments NSX. Les commutateurs logiques de transit reliant les DLR et les passerelles Edge doivent également être ajoutés dans ce cas. Si vous utilisez un grand nombre de passerelles Edge, vous devez composer le schéma d’adressage IP pour les segments qui sont liés par ces passerelles Edge.
NSX-T, cependant, ne nécessite pas ces opérations. Tous les segments réseau entre Tier0 et Tier1 obtiennent automatiquement des adresses IP. Aucun protocole de routage dynamique n’est utilisé. Au lieu de cela, des routes statiques sont utilisées et un système connecte automatiquement les composants, rendant la configuration plus facile ; vous n’avez pas besoin de passer beaucoup de temps à planifier l’adressage IP pour les composants de réseau de service (transit).
Intégration pour l’inspection du trafic
NSX-v propose une intégration avec des services tiers tels que des antivirus sans agent, des pare-feu avancés (pare-feux de prochaine 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 est effectuée au niveau du noyau hyperviseur en utilisant un bus VMCI protégé (interface de communication de machine virtuelle).
NSX-T ne fournit pas ces capacité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, fonctionnant au niveau d’un adaptateur virtuel VM. Les options de sécurité du commutateur sont disponibles pour les deux types de NSX, mais l’option « Limite de débit pour le trafic de diffusion et de multidiffusion » n’est disponible que pour NSX-T.
NSX-T vous permet d’appliquer des règles de manière plus granulaire, ce qui permet une utilisation plus rationnelle des nœuds de transport. Par exemple, vous pouvez appliquer des règles basées sur les objets suivants : commutateur logique, port logique, groupe NS. Cette fonctionnalité peut être utilisée pour réduire la configuration des ensembles de règles sur le commutateur logique, le port logique ou les instances de groupe NS afin d’atteindre des niveaux plus élevés d’efficacité et d’optimisation. Vous pouvez également économiser de l’espace en termes d’échelle et de cycles de recherche de règles, en plus d’héberger un déploiement multi-locataires et d’appliquer des règles spécifiques au locataire (des règles qui s’appl
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 au démon pare-feu vShield (VSFWD).
NSX-v vs NSX-T – Tableau de comparaison
Maintenant que vous êtes familiarisé avec les capacités les plus intéressantes de VMware NSX, résumons les principales fonctionnalités de NSX-v et NSX-T qui ont été explorées dans cet article de blog en plus de les comparer dans le tableau.
NSX-v est la solution la plus optimale 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 construction de réseaux virtuels. Il n’y a pas de réponse unique quant à savoir quel type de NSX est meilleur. Que vous devriez utiliser NSX-v ou NSX-T dépend de vos besoins et des fonctionnalités fournies par chaque type de NSX.
La politique de licence NSX est conviviale – vous n’avez besoin d’acheter qu’une seule licence NSX, quel que soit le type de NSX que vous allez utiliser. Plus tard, vous pouvez installer NSX-T dans un environnement NSX-v ou inversement, selon vos besoins, et continuer à utiliser votre licence NSX unique.
Vous pouvez construire votre propre centre de données défini par logiciel avec VMware en utilisant la solution NSX. VMware vous fournit des
pour assurer la continuité des opérations, la haute disponibilité et la tolérance aux pannes, mais la sauvegarde des machines virtuelles ne sera pas une mesure redondante. Sauvegardez régulièrement vos machines virtuelles de production liées à différents projets et les machines virtuelles fonctionnant en tant que composants de VMware vSphere et VMware NSX (tels que vCenter, NSX Manager, NSX Controller, NSX Edge) afin de protéger vos données. NAKIVO Backup & Replication peut vous aider à créer la sauvegarde VMware de manière fiable et efficace même si vous utilisez des clusters.
Conclusion
NSX-v est la solution la plus optimale 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 construction de réseaux virtuels. Il n’y a pas de réponse unique quant à savoir quel type de NSX est meilleur. Que vous devriez utiliser NSX-v ou NSX-T dépend de vos besoins et des fonctionnalités fournies par chaque type de NSX.
La politique de licence NSX est conviviale – vous n’avez besoin d’acheter qu’une seule licence NSX, quelle que soit le type de NSX que vous allez utiliser. Plus tard, vous pouvez installer NSX-T dans un environnement NSX-v ou inversement, en fonction de vos besoins, et continuer à utiliser votre licence NSX unique.
Vous pouvez construire votre propre centre de données défini par logiciel avec VMware en utilisant la solution NSX. VMware vous fournit des fonctionnalités de clustering pour assurer la continuité des opérations, la haute disponibilité et la tolérance aux pannes, mais la sauvegarde des machines virtuelles ne sera pas une mesure redondante.
Sauvegardez régulièrement vos machines virtuelles de production liées à différents projets et les machines virtuelles fonctionnant comme composants de VMware vSphere et VMware NSX (comme vCenter, NSX Manager, NSX Controller, NSX Edge) afin de protéger vos données. NAKIVO Backup & Replication peut vous aider à créer la sauvegarde VMware de manière fiable et efficace même si vous utilisez des clusters.
Source:
https://www.nakivo.com/blog/nsx-v-vs-nsx-t-comprehensive-comparison/