NSX

Posted on by maxime

NSX Présentation

Présentation

Nous allons dans cette suite d’articles présenter NSX et détailler les étapes d’installation et de configuration dans notre Lab.

Depuis quelques années, VMware s’est mis dans l’idée de tout virtualiser. Le software Defined Data Center, si cher à VMware, prend une nouvelle dimension avec la virtualisation des réseaux et NSX. Ceci est certainement la plus grosse nouveauté depuis la virtualisation des serveurs. En tout cas, elle suscite énormément de curiosité et d’attente.

Dans le cas de la virtualisation des serveurs, l’hyperviseur (ESXi), fournit, tel un serveur physique, la mémoire, le CPU, la carte réseau, etc aux différentes VMs. Avec la virtualisation des réseaux, l’hyperviseur reproduit l’équivalent des couches 2 à 7 du modèle OSI (switch, routage, ACL, Firewall, etc) en tant que software. Ceci permet de créer un réseau virtuel isolé. Le réseau virtuel est indépendant du réseau physique et complètement agnostique. Il vient s’interfacer au-dessus de la couche physique et ne demande aucun équipement supplémentaire à part les ESXi habituels.

NSX peut être configuré depuis le web client, la ligne de commande et les REST API.

Nous allons présenter les composants de NSX avant l’installation.

Composants NSX

 

 

Data Plane :

NSX Data Plane correspond aux vSwitch NSX qui sont basés sur les vSphere Distributed Switch (vDS) ainsi que des composants additionnels. Des modules (VIB) sont installés sur les ESXi pour activer les services comme le routage distribué, le firewall logique et pour activer les VXLAN.

Les vSwitch NSX basés sur vDS font abstraction du réseau physique. Voici les avantages :

  • Couche supérieure avec les protocoles comme VXLAN et centralisation de la configuration du réseau
    • Création d’une couche 2 flexible par-dessus le réseau IP existant physique sans ajout de matériel dans votre réseau physique
    • Communication est-ouest et nord-sud en maintenant une isolation entre plusieurs tenants
    • Les applications et VMs ne sont pas impactés, elles voient le réseau virtuel comme un réseau physique
  • Facilite l’ajout d’hyperviseur dans le réseau
  • Plusieurs fonctionnalités supportées : Port Mirroring, QoS, LACP, Network Health Check, NetFlow, Sauvegarde et Restauration des confgiurations, monitoring, management et troubleshooting du réseau virtuel

De plus, le data plane fournit une passerelle entre les VXLAN et le réseau physique (VLAN). L’appliance NSX Edge gère cette partie. Cette appliance interagit sur les couches 2 et 3, le firewall de périmètre, le load balancing et d’autres services comme VPN et DHCP.

 

Control Plane :

Le Control Plane NSX est assuré par les contrôleurs NSX (NSX controller). NSX controller contrôle les switchs virtuels (logical switches) et maintiennent les informations des VMs, ESXi, logical switch et VXLAN.

Les contrôleurs sont déployés dans un cluster par nombre impair afin d’assurer une haute disponibilité. Une panne d’un des contrôleurs ne doit pas impacter le trafic dataplane.

 

Management Plane :

Le management plane NSX est assuré par l’appliance NSX Manager qui est le premier composant NSX à déployer dans votre vCenter. Il fournit le point unique pour configurer l’environnement NSX et communique avec les REST API.

 

Consumption Platform :

La plateforme de consommation est accessible directement via vSphere Web Client. Elle permet de configurer et administrer NSX. D’autres plug-in existent pour vCAC, vCloud Director et Open Stack ainsi que les REST API.

 

Services NSX

 

Logical Switches :

Les switch logiques créés des domaines de broadcast virtuels permettant de séparer des VMs. Ceci est l’équivalent dans un réseau physique aux VLANs. Un switch logique est distribué. Il permet de faciliter la mobilité d’une VM sans les contraintes de la couche 2 physique (VLAN).

 

Logical Routers :

Les routeurs logiques permettent de router les informations entre les domaines de broadcast créés par les logical switches. NSX permet de faciliter les échanges Est-Ouest et donc d’effectuer des communications VM à VM directement sans sortir de l’infrastructure virtuelle. Les routeurs logiques permettent également le traffic Nord-Sud qui permet aux VMs de communiquer avec le réseau physique par exemple.

 

Logical Firewall :

Les Firewall logiques fournissent des mécanismes de sécurité tout comme des firewall dans un réseau physique. Les composants Distributed Firewall des Firewall logiques permettent de segmenter le datacenter virtuel à travers des objets vCenter (Datacenter, VM, etc), à travers des utilisateurs, des ESXi, etc comme on peut le faire dans un réseau physique à travers des IP, VLAN, etc. Le composant Edge Firewall permet de créer des DMZ basées sur les IP/VLAN, de faire du NAT, du VPN, etc. Enfin pour monitorer l’activité réseau entre vos machines, la fonctionnalité Flow Monitoring vous permettra d’auditer votre trafic réseau.

 

Autres services : Logical Virtual Private Networks, Logical Load Balancer, Service Composer et NSX Extensibility.

 

NSX : Lab Design

 

Dans ce deuxième article sur NSX, nous présentons rapidement les prérequis et le design de Lab que nous souhaitons utiliser.

Nous avons installé la version 6.2 compatible avec vCenter 5.5. Voici les pré-requis hardware recommandés par VMware :

 

Pré-Requis :

 

 

Évidemment dans le cadre d’un lab, vous pouvez réduire nettement les ressources CPU/Mémoires du composant NSX Manager.

Les ports requis pour NSX Manager :

 

 

Chaque composant de NSX ayant une appliance dispose de VMware Tools pré-installés. Ne pas essayer de les mettre à jour.

 

Schéma du LAB NSX

 

Voici le schéma que j’ai défini pour mon LAB NSX.

 

 

  • Un cluster de management comprenant esxi-mgmt (version 5.5)
  • Un cluster Edge comprenant esxi-edge (version 5.5)
  • Deux clusters compute : A et B comprenant respectivement esxi-computea et esxi-computeb (version 5.5)
  • Un contrôleur de domaine faisant office de DC, DNS et de routage entre l’esxi de management et les esxi de compute.
  • Un vCenter 5.5
  • 6 VMs Linux dans 3 sous réseaux différents
  • 1 VMs sur le réseau extranet

 

Ci-dessous un aperçu de ma configuration au niveau vCenter :

 

 

Un aperçu côté dVS :

 

 

Tableau récapitulatif Objet / IP :

 

Objet IP
Esxi-mgmt 192.168.1.2
Esxi-computea 192.168.10.1
Esxi-computeb 192.168.10.2
Esxi-edge 192.168.1.3
Nsx-mgr 192.168.1.50
DC 192.168.1.254
192.168.10.250
192.168.20.250
vCenter 192.168.1.210
Controller1 192.168.10.10
Controller2 192.168.10.11
Controller3 192.168.10.12
VTEP1 192.168.10.20
VTEP2 192.168.10.21
VTEP3 192.168.10.22
DLR-INTRA-0 192.168.1.150
172.16.50.254
172.16.100.254
172.16.150.254
192.168.30.254
192.168.30.154
EDGE-GATEWAY-ALBAN-0 192.168.20.200
192.168.30.200

Installation NSX Manager

Déployer l’OVA

NSX Manager est le composant de management centralisé de NSX et fonctionne en tant qu’appliance hébergée sur un ESXi. VMware recommande d’installer NSX Manager sur un cluster de management dédié et séparé des clusters (Compute) que NSX va manager. Un NSX Manager est lié à un seul vCenter. NSX Manager requiert plusieurs connections dont le vCenter, les ESXi et les instances NSX Edge. Les composants NSX peuvent communiquer à travers différents LAN.

NSX Manager doit avoir l’heure synchronisé avec tous les ESXi, le vCenter et les composants VMware de votre infrastructure. Utilisez de préférence un serveur NTP pour tous les éléments.

Télécharger votre appliance OVA : https://my.vmware.com/web/vmware/details?productId=417&downloadGroup=NSX-V-612

Il vous faudra une clé pour pouvoir télécharger l’appliance.

Une fois votre OVA récupéré, déployez le dans votre cluster de management :

Une fois votre appliance démarrée, attendez la fin du chargement de celle-ci et loguez-vous via votre navigateur sur l’url https://ip-appliance . Loguez-vous avec le compte admin et le mot de passe spécifié dans le déploiement de votre ova :

Allez dans View Summary. Vérifiez que les services sont bien en running :

 

 

Enregistrer le vCenter avec NSX

Cliquez ensuite sur Manage en haut à gauche et allez dans NSX Management Service :

 

Cliquez sur Edit et renseignez l’IP ou le FQDN de votre serveur vCenter, un login et mot de passe. Acceptez le certificat :

L’enregistrement est terminé. Connectez-vous ensuite sur votre vCenter via le Web Client. Vous devez voir l’onglet Networking & Security.

Assignez une licence à NSX

Depuis le vSphere Web Client, cliquez sur administration puis Licenses et allez dans l’onglet Solutions. Cliquez sur Assign a new licence key et renseignez votre licence NSX :

NSX : Mise en place du Control Plane / Control Cluster

Le cluster de contrôleurs (controller cluster) est le composant responsable du management du switching et routing au niveau des hyperviseurs. Il est composé de plusieurs contrôleurs qui gèrent les Logical switches. Le fait d’utiliser un controller cluster pour gérer les VXLAN basés sur des switchs logiques permet d’éliminer le besoin du multicast sur votre infrastructure physique. Par conséquent, il n’est plus nécessaire de créer des groupe multicast, d’activer PIM routing ou l’IGMP Snooping sur vos switchs physiques et vos routeurs.

Pour fonctionner de cette manière, veillez à sélectionner « Unicast » lors du déploiement de vos switchs logique.

VMware recommande d’avoir au minimum un cluster de 3 contrôleurs et d’en avoir toujours un nombre impair (3, 5, 7, etc).

Pour les déployer, depuis le vSphere Web Client, cliquez sur Networking & Security et allez dans la partie Installation. Dans NSX Controller nodes, cliquez sur le signe + vert :

 

Le NSX Controller Cluster doit être déployé sur un cluster de compute ou un cluster edge et non pas sur le cluster de management. Renseignez les différentes informations concernant le déploiement des contrôleurs puis dans IP Pool, cliquez sur Select et créer le pool pour le déploiement des contrôleurs :

Les IP de vos contrôleurs doivent être joignables par le NSX Manager et les IP de management des ESXi qui communiqueront avec les NSX Controllers.

Les IP des contrôleurs seront utilisées dans l’ordre de déploiement  de chaque contrôleur :

Validez le déploiement du premier contrôleur.

Dans vCenter, vous devez voir le déploiement du premier contrôleur :

Une fois l’appliance démarrée, vous voyez bien que l’IP du contrôleur est la première de votre pool :

Déployez les 2 autres contrôleurs de la même manière : (Mes contrôleurs ont comme numéro 5, 6 et 7 car j’ai rencontré des problèmes de communication avec le NSX Manager aux déploiements des premiers. Lors d’un échec, NSX Manager incrémente le nombre pour les prochains déploiements).

Contrôler le statut du controller cluster

Une fois vos contrôleurs déployés, connectez-vous en SSH sur chacun d’entre eux (login : admin / mdp : celui défini au déploiement) et tapez la commande ci-dessous :

Show control-cluster status

 

Vous devez voir à la ligne « Join status » : Join complete

Déployer les modules VIB sur les ESXi

Préparer les clusters pour la virtualisation du réseau

Cette étape consiste à préparer les clusters et donc les ESXi pour NSX en installant plusieurs composants software dans les ESXi. Identifiez les clusters sur lesquels installer les modules. Si vous utilisez vSphere Update Manager dans votre environnement, il sera nécessaire de le désactiver le temps de la préparation des clusters : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053782

Lors de la préparation des Cluster, plusieurs composants sont installés :

  • UWA (User World Agent) : Il deviendra un service appelé netcpa que vous pouvez contrôler avec la commande /etc/init.d/netcpad status. Il fait le lien entre les contrôleurs NSX et le module kernel de l’ESXi sauf pour le Distributed Firewall. Il log dans /var/log/netcpa.log les logs des clusters compute et edge.
  • 3 Kernel Modules :
    • VXLAN VIB : Communique avec les NSX Controller à travers UWA
    • Distributed Logical Router VIB : Communique avec les NSX Controller à travers UWA
    • Distributed Firewall VIB : Communique directement avec le NSX Manager à travers le service vsfwd

Avant de préparer vos ESXi, assurez-vous que tous les ESXi soient attachés au vDS qui sera utilisé par NSX. C’est un pré-requis.

Pour préparer vos clusters, depuis Networking & Security, allez dans la partie Installation, puis l’onglet Host Preparation :

Vous devez voir la liste des clusters. Cliquez sur Install pour les clusters que vous souhaitez rattacher à NSX. Vous verrez dans votre vCenter plusieurs tâches se lancer correspondant notamment au service netcp (UWA) et aux VIB Distributed Logical Router, VXLAN et Firewall :

Faites ceci, pour tous les clusters que vous souhaitez préparer :

Configurer les VXLAN

Suite à l’étape précédente de déploiement des modules VIB et de préparation des clusters, vous voyez depuis votre vSphere Web Client dans la colonne VXLAN le mot “Configure”.

Avant toute chose, petit rappel de ce qu’est un VXLAN. VXLAN (Virtual Extensible LAN) permet de créer un réseau de couche 2 transitant dans UDP sur un réseau de couche 3 existant (notre réseau physique). La trame VXLAN est allongée de 24 bits permettant de créer jusqu’à 16 millions de VLANs différents.

Oui la trame est allongée d’environ 50 octets en IPv4 et 100 octets en IPv6. C’est pourquoi la taille MTU de 1500 habituel doit être augmentée pour pouvoir faire passer ces trames sinon vous risquez d’avoir une fragmentation élevée qui aura un impact sur les performances réseaux.

La VTEP (VXLAN Tunnel End Point) est l’élément qui permet l’encapsulation et la désencapsulation des paquets VXLAN. Un VMKernel port groupest créé sur chaque ESXi de façon automatique lorsque nous préparons les ESXi pour VXLAN.

Sur le schéma ci-dessous, c’est la partie bleue qui nous intéresse, elle représente les différents composants utilisés pour VXLAN : Les VIB, le portgroup et le vmk sur chaque ESXI. Ces trois éléments représentent le VTEP.

Il est nécessaire de configurer VXLAN pour chaque cluster qui participera au réseau logique du vDS NSX. Ici nous allons configurer les paramètres VTEP comme la taille MTU, le teaming, etc. La taille de MTU sera ici à 1600 dans notre LAB.

Depuis l’étape précédente, dans la colonne VXLAN, cliquez sur Configure. Modifiez la taille MTU, précisez l’ID de vlan si nécessaire, dans mon cas le traffic sera non taggué, créer un Pool pour les VTEP (Le pool correspond au IP des VMkernel créé sur chaque ESXi) et choisir la teaming Policy. Il est important de bien choisir la bonne policy pour le teaming pour éviter une perte de packet puis validez :

Vous verrez les tâches ci-dessous dans votre vCenter :

Un VMkernel est créé sur le ou les ESXi du cluster préparé et les IP sont pris dans le pool VTEP dans l’ordre :

Faites ceci pour tous les clusters à préparer. Allez dans l’onglet Logical Network Preparation :

Vous devez voir pour chaque ESXi des clusters préparé les informations renseignées pendant la configuration du VXLAN.

Segment ID et Transport Zone

 

Assigner un Segment ID Pool

Segment ID Pool

Segment ID est l’équivalent des ID de VLAN pour les VLAN. Cela va permettre de séparer les réseaux logiques et définir les VNI (VXLAN Network Identifier). Ici nous allons allouer un pool au NSX Manager. Cela va permettre de déterminer le nombre de VXLAN gérer par le NSX Manager dans votre domaine NSX. VMware débute les segments ID à 5000 (pour qu’il n’y est pas de confusion avec les VLANs). Nous allons donc prendre un pool de 5000 à 5100 dans notre Lab.

Dans l’onglet précédent « Logical Network Preparation », cliquez sur Edit et renseignez le pool de Segment ID :

Ici, nous n’activons pas le multicast.

Créer une Transport Zone

Lorsque vous créer une zone de transport, vous devez choisir son mode de réplication (multicast, unicast, hybrid) et sélectionnez les clusters faisant partie de cette Zone de transport. Il est intéressant d’avoir plusieurs zones de transport dans un environnement multi tenants ou pour fournir un niveau d’isolation supplémentaire au niveau du control plane. Ici nous créons une seule zone de transport.

Je vous invite à lire cet article pour en savoir plus sur la zone de transport : https://telecomoccasionally.wordpress.com/2014/12/27/nsx-for-vsphere-understanding-transport-zone-scoping/

Depuis l’écran précédent, allez dans la partie Transport Zones et cliquez sur le + vert. Donnez un nom, choisir le mode de réplication, ici unicast, et sélectionnez les clusters faisant partie de votre zone de transport :

Validez pour créer votre zone de transport.

 

 

 

 

 

 

 

 

 

 

 

 

 

Source