Dans cette partie, nous allons faire une brève découverte de NSX-T mais également voir à quel point cette solution est intégrée dans vSphere 7.
¶ C'est quoi NSX-T ?
NSX-T est une gamme de logiciels de virtualisation du réseau et de sécurité.
Ce que nous faisons essentiellement avec NSX-T c'est la création de systèmes de réseau virtuel tels que des routeurs, des firewall, des switches (j'insiste, le tout étant biensur virtualisé).
En comparaison avec vSphere, si l'on ne dispose pas de NSX-T, on peut créer des "vSphere Distributed Switches" et c'est tout. Aucun autre équipement réseau virtualisé ne sera à disposition.
L'un des grands avantages de vSphere 7 est une très grande compatibilité d'intégration avec NSX-T 3.0.
¶ NSX-T
De la même manière que le "Distributed Switches" pour vSphere, NSX-T permet de créer un vSwitch que l'on appelle le "N-VDS".
Donc si l'on souhaite créer des réseaux virtuels à l'aide de NSX-T, alors ce "N-VDS" devra être installé sur nos hôtes ESXi.
Ces ESXi sont appelés dans l'environnement NSX-T des "Transport nodes"
On peut donc considérer le "N-VDS" comme une sorte de "module" installé sur nos hôtes ESXi à partir duquel on peut accéder à l'interface utilisateur NSX-T, permettant de créer par exemple des segments de couche deux aussi simplement que l'on créé des "Port Groups" dans un "vSphere Distributed Switch".
ATTENTION : Une des choses importantes à comprendre dans l'univers de NSX-T c'est que lorsqu'on parle de "segment", on parle de switch virtuel.
L'un des grands avantages de "NSX-T" vient donc du fait que l'on pourrai créer des "segments" plus larges qui couvriraient des hôtes KVM, des hôtes bare metal voir même des hôtes Edge.
C'est d'ailleurs pour cela que "NSX-T" possède une interface séparée des ESXi : on peut créer des switches virtuels qui s'étendent non seulement aux ESXi mais également aux hôtes bare metal, etc.
¶ NSX-T 3.0 et VMNICS
Dans les chapitres précédents nous avons appris que les VMNICS ne pouvaient être associés qu'à un seul vSwitch. Dans ce cas, si l'on possède déjà une infrastructure vSphere et que nos adaptateurs physiques sont déjà associés à des vSwitches (standards ou distribués), comment pouvons-nous utiliser en même temps des "N-VDS" ?
Devons-nous supprimer certains adaptateurs physiques de nos vSwitch pour les associer aux N-VDS ou ajouter d'autres adaptateurs physiques dans la mesure du possible ?
Mettre en place une telle configuration peut être un véritable problème et un véritable casse-tête puisque dans un environnement déjà existant nos VMNICS sont probablement déjà associés à des vSwitches. De plus que deviennent les VMs qui sont déjà connectées à notre vSwitch ?
La solution à ce problème est très simple : vSphere 7 et les "vSphere Distributed Switches".
En effet contrairement aux versions précédentes, depuis l'arrivée de vSphere 7 les "vSphere Distributed Switches" en version 7.0 et supéreure sont nativement compatibles avec les "Ports Groups" utilisés par "NSX-T".
Cela veut dire qu'il sera possible de créer des "Ports Groups" pour "NSX-T" directemement sur nos "vSphere Distributed Switches".
Avec NSX-T en version 3.0 et vSphere 7 nous pouvons à présent nous passer des "N-VDS" et utiliser directement les mêmes "vSphere Distributed Switches" à la fois pour NSX-T 3.0 et pour des groupes de ports dédiés aux VMs.
Les segments créés par NSX-T seront alors visibles directement comme étant des "Port Groups" dans le "vSphere Distributed Switches", de la même manière que les "Ports Groups" que nous connaissions auparavant.
De plus comme ils existent sur le même "vSphere Distributed Switch", ils utiliseront les mêmes adaptateurs physiques. Avec NSX-T en version 3.0 et vSphere 7 il n'est plus nécessaire de se demander comment faire cohabiter NSX-T et "vSphere Distributed Switch" sur nos VMNICS, simplifiant énormément la migration de "vSphere Distributed Switch" vers "NSX-T".
¶ Micro-segmentation
Un autre avantage non négligeable de "NSX-T" est la micro-segmentation.
Imaginons que nous avons deux machines virtuelles connectées sur le même "Port Group" dans le même "vSphere Distributed Switch".
Imaginons également que la VM1 soit un serveur Web recevant du trafic externe et que nous voulions qu'une partie de ce trafic soit autorisée à sortir de la VM1 pour atteindre la VM2 qui serait par exemple un serveur de base de données de l'application Web de la VM1.
Toute fois nous ne voulons pas nécessairement que le trafic Web de la VM1 atteigne la VM2.
Au contraire, nous voulons ouvrir des flux très spécifiques pour la VM2 qui seraient en provenance uniquement de la VM1 et sur le port de connexion spécifique à notre base de données.
Pour cela nous allons pouvoir utiliser des règles de pare-feu qui seront attachées aux deux VMs.
Un groupe de règles dédié et attaché à la VM1 puis un autre dédié et attaché à la VM2 avec chacun des autorisations de flux différentes.
Y compris si les deux VMs sont dans le même réseau, connectées au même "Port Group" sur le même "vSphere Distributed Switch".
C'est ce à quoi correspond la Micro-segmentation: Avoir la possibilité de créer des règles de pare-feu directement sur chacune des VMs individuellement.
C'est une des features majeure de "NSX-T".
Ce qu'il nous serait donc possible de faire avec vSphere 7 et NSX-T 3.0 par exemple pourrait ressemble à ça :
- Installer "NSX-T"
- Utiliser un "vSphere Distributed Switches" comme switch pour NSX-T**
- Commencer à créer des règles de Micro-segmentation pour nos VMs même si elles n'ont pas été migrées sur un Segment NSX-T.
C'est un énorme avantage de "NSX-T" si l'on souhaite l'utiliser uniquement pour la Micro-segmentation sans forcément utiliser toutes ses autres capacités puisqu'il ne sera pas nécessaire de retravailler l'architecture réseau. Il suffira juste d'installer "NSX-T" et de commencer à mettre en place la Micro-segmentation via des règles de pare-feu sur des VMs qui sont déjà connectées à des "Ports Groups" existant.
En effet, si l'on possède déjà des "Distributed Ports Groups" et que l'on créé par la suite des "Segments" sur nos "vSphere Distributed Switches", nous pourrons toujours avoir des VMs connectées sur les "Distributed Ports Groups" de nos "vSphere Distributed Switches".
Il ne sera pas utile de faire de gros changements d'infrastructure pour ajouter des règles de pare-feu sur nos VMs.
On peut voir ça comme du "plug n play", dès l'instant où "NSX-T" est installé il sera possible d'ajouter des règles de pare-feu aux VMs de nos "Distributed Ports Groups" sans les migrer sur des "Segments" et ainsi mettre en place de la Micro-segmentation.
Chapitre précédent : 5 - vSphere Distributed Port Groups : démonstration - Chapitre suivant : 7 - vSphere 7 Distributed Switch Features : démonstration