virtualisation des réseaux en environnement vsphere avec nsx

JRES 2017 - Nantes 1/15

Virtualisation des réseaux en environnement vSphere avec NSX

Julien Cabessut Université Toulouse Jean Jaurès

5 allées Antonio Machado

31058 Toulouse

Résumé

Basée sur l'expérience acquise dans le cadre du projet de Cloud privé de l'Université Fédérale de Toulouse

Midi-Pyrénées (UFTMiP), cette présentation a pour objectif de faire un tour d'horizon du concept de

virtualisation des réseaux tel qu'il est implémenté par VMware. Je me focaliserai sur la version NSX-V

dédiée aux hyperviseurs ESXi, en la comparant brièvement avec la version NSX-T (pour hyperviseurs

KVM) et les technologies similaires proposées par d'autres solutions (OpenStack Neutron, Cisco ACI).

En première partie, j’expliquerai le fonctionnement général de cette plateforme et la façon dont elle

s'intègre dans un environnement vSphere. Je m’attarderai sur le concept de VXLAN et de VTEP

permettant l'abstraction de la couche réseau physique. Je détaillerai les avantages et inconvénients de cette

solution en termes d'implémentation et d'exploitation, en comparaison avec les réseaux traditionnels.

La deuxième partie se focalisera sur la sécurité, présentant les notions de micro-segmentation et de sécurité

contextuelle apportées par le pare-feu distribué. Nous verrons en quoi ce composant permet d'améliorer la

segmentation par rapport aux solutions historiques : pares feux périmétriques ou VLAN privés.

J’expliquerai également son intérêt dans un contexte de provisionnement de machines virtuelles en

association avec vRealize Automation.

Je terminerai par la description d'un composant essentiel de l'architecture NSX : l'Edge Service Gateway,

routeur périmétrique à la frontière des réseaux physiques et virtuels, en détaillant les différents services

qu'il permet d'implémenter sur les réseaux virtualisés (filtrage, NAT, VPN, routage et haute-disponibilité).

La conclusion présentera le bilan de deux ans d'exploitation de VMware NSX sur un environnement de

production.

Mots-clefs

Réseaux, virtualisation, NSX, vmware, vsphere, micro-segmentation, sdn.

1 Introduction

Le Cloud Privé de l’UFTMiP est une infrastructure communautaire d’hébergement de machines virtuelles,

sur un modèle IaaS/PaaS, s’appuyant sur des équipements répartis dans les datacenters de 3 établissements.

L’ensemble des fonctions de virtualisation est basé sur la solution vSphere de VMware.

Le modèle architectural est de type stretch-cluster : les ressources des 3 datacenters sont vues comme un

cluster unique, géré par un seul vCenter. La réplication synchrone du stockage repose sur la technologie

LiveVolume de DELL. L’interconnexion entre les sites est assurée par le réseau métropolitain REMIP.


Figure 1 - Architecture stretch-cluster du Cloud UFTMiP

L’administration et l’interconnexion des équipements d’infrastructure sont effectuées au travers de réseaux

« traditionnels ». A contrario, les réseaux accessibles aux machines virtuelles sont entièrement virtualisés

grâce à la solution NSX.

La plateforme NSX est une implémentation propriétaire par VMware du concept de Software Defined

Networking (SDN). Il en existe deux versions : la première, NSX-V, est spécifique aux hyperviseurs ESXi

et totalement intégrée dans l’environnement vSphere. La seconde version, baptisée NSX-T, est destinée

aux environnements multi-hyperviseurs (ESXi et KVM) et vise à promouvoir l’intégration de NSX dans

les infrastructures basées sur OpenStack.

Les fonctionnalités proposées sont quasiment identiques pour les deux versions, la différence se situant

dans la façon dont elles s’interfacent avec les systèmes sous-jacents. Cette présentation se focalisera sur

NSX-V, qui est utilisée dans le cadre du Cloud Privé de l’UFTMiP.

NSX est en concurrence avec d’autres solutions proposant des fonctionnalités similaires. Parmi celles-ci,

on peut citer la plateforme ACI (Application Centric Infrastructure) de Cisco, qui implémente le SDN avec

une philosophie centrée sur les applications, en proposant un niveau d’abstraction élevé. On notera qu’elles

partagent un défaut commun : celui d’être VMware exclusive pour NSX-V, et d’être Cisco hardware-

dependant dans le cas d’ACI.

Le module Neutron d’OpenStack permet lui aussi de virtualiser et orchestrer de nombreux services réseau

dans une infrastructure Cloud, en présentant l’avantage d’être une solution libre et très modulaire grâce à

l’utilisation de plugins.

2 Concepts fondamentaux

2.1 Abstraction matérielle

La virtualisation des réseaux repose sur la même philosophie que la virtualisation système : elle consiste à

ajouter une couche d’abstraction entre le matériel et le logiciel afin de simuler un ou plusieurs équipements

physiques. Dans le cas de NSX, l’administrateur va créer des switches logiques afin d’y connecter les


interfaces réseau des VM, et des routeurs logiques distribués pour interconnecter ces switches et assurer

le routage des flux IP.

Les réseaux ainsi créés sont appelés overlay. De la même façon qu’un processeur virtuel a besoin d’un

processeur physique pour exécuter une instruction, un switch logique a besoin d’un équipement réseau

physique pour transporter les données entre les hyperviseurs. Le réseau physique auquel sont connectés les

serveurs est appelé underlay.

Figure 2 - Réseaux underlay et overlay

Nous allons voir comment les différents composants de la plateforme NSX interagissent entre eux et avec

le réseau physique pour permettre le bon fonctionnement de ces réseaux virtualisés.

2.2 VXLAN, VTEP et Logical Switches

Le principe d’abstraction repose sur le protocole VXLAN (RFC 73481). Suite à l’installation de NSX,

chaque hyperviseur dispose d’une interface IP nommée Virtual Tunnel Endpoint (VTEP) qui lui permet de

créer des tunnels vers les autres hyperviseurs de son cluster. Le trafic de niveau 2 entre les VM hébergées

sur des hôtes distincts est encapsulé dans des paquets UDP par l’hyperviseur source, puis transporté sur le

réseau physique jusqu’à l’hyperviseur destinataire, qui effectue alors l’opération inverse et délivre la trame

L2 à la VM de destination.

Chaque paquet VXLAN est marqué par un identifiant (VNI) qui correspond au switch logique auquel est

connectée la VM de destination.

La gestion du plan de contrôle des VXLAN par NSX sera expliquée dans la section suivante.

1 https://tools.ietf.org/html/rfc7348

https://tools.ietf.org/html/rfc7348


Figure 3 - Encapsulation L2 dans un tunnel VXLAN

Ce mode de transmission présente plusieurs avantages :

Les équipements réseau qui interconnectent les hyperviseurs n’ont pas connaissance des

adresses MAC des machines virtuelles. Le plan de contrôle du réseau physique ne gère que

les adresses VTEP des ESX.

Les équipements physiques n’ont pas connaissance des VXLAN. Ceux-ci sont gérés par

NSX, limitant les opérations de configuration sur le réseau physique.

Les paquets VXLAN, correspondant au niveau 3 du modèle OSI, peuvent être routés. Ceci

permet d’étendre un même segment de niveau 2 (le switch logique) entre plusieurs

datacenters :

Figure 4 - Routage des paquets VXLAN


L’encapsulation augmente la taille des trames qui circulent sur le réseau physique. Il est nécessaire de

modifier la valeur MTU de tous les équipements qui interconnectent les serveurs du cluster. Les

configurations utilisant des valeurs MTU standards ne sont pas supportées par VMware. Cette contrainte

est à prendre en compte si l’interconnexion dépend d’opérateurs qui ne proposent pas cette modification.

2.3 Routeur logique distribué (DLR)

Dans un environnement vSphere traditionnel, le routage est assuré par des équipements physiques. Cela

présente un inconvénient de taille : le trafic remonte la plupart du temps jusqu’au cœur de réseau, qui

effectue le routage, avant d’être à nouveau acheminé jusqu’à l’ESX de destination.

Figure 5 - Routage avec vSphere traditionnel

NSX permet d’améliorer ce fonctionnement en confiant les décisions de routage directement aux

hyperviseurs. Le trafic entre les différents VXLAN est donc limité aux ESX et aux switches auxquels ils

sont connectés. Si les deux VM sont hébergées par le même hyperviseur, le trafic est traité localement par

le CPU, permettant une réduction considérable de la latence.

Figure 6 - Routage avec le DLR NSX


Cette implémentation du routage au sein du réseau virtualisé illustre les notions de trafic est-ouest, entre

les VM hébergées, et de trafic nord-sud qui désigne les flux entrants et sortants du datacenter.

L’autre avantage du DLR est de proposer un nombre d’interfaces presque illimité : il est possible de

connecter jusqu’à 999 switches logiques à un même routeur logique.

2.4 Contrôleurs et Logical Control VM (LCVM)

Le plan de contrôle est entièrement géré de façon logicielle et assuré par les contrôleurs NSX.

Il s’agit d’appliances déployées lors de l’installation, recensant l’ensemble des informations sur le

périmètre réseau virtualisé : tables MAC et ARP des switches logiques et des hyperviseurs, adresses IP des

VM, relations entre les tunnels et les interfaces VTEP, tables de routage. Les contrôleurs sont synchronisés

en temps réel avec les hyperviseurs.

Un autre composant essentiel du plan de contrôle est la Logical Control VM du routeur distribué. Pour

chaque instance de routeur virtuel déployée sur l’environnement, NSX crée une VM qui permet la

configuration du routeur et communique avec les contrôleurs NSX et les hyperviseurs afin de synchroniser

les informations. Dans les configurations utilisant du routage dynamique (BGP ou OSPF), la LCVM assure

le peering avec les routeurs voisins. La LCVM ne participe pas au data plane : les flux est-ouest ne transitent

pas par cette appliance et restent gérés par les hyperviseurs.

Figure 7 - Plan de contrôle NSX

2.5 NSX Manager

Le composant d’administration de la plateforme est le NSX Manager. Il s’agit, là aussi, d’une appliance

qui centralise la configuration de l’ensemble du réseau virtualisé et assure la communication et la

synchronisation avec le vCenter. Il propose une API REST qui permet d’administrer tous les composants

de la plateforme NSX et d’automatiser certaines tâches.

Les administrateurs NSX peuvent également accéder aux fonctions de configuration et de supervision de

la plateforme au travers du client web vSphere. L’intégration complète de NSX au client vSphere est l’un

des points forts de la solution NSX-V.


Figure 8 - Intégration du NSX Manager au client vSphere

2.6 Edge Service Gateway (ESG)

Le dernier élément, quasiment indispensable, de l’infrastructure NSX est l’Edge Service Gateway. C’est

une appliance déployée par l’administrateur NSX, qui participe simultanément au data plane et au control

plane. Elle se situe à la frontière entre le réseau virtualisé et le réseau traditionnel. L’ensemble des flux

nord-sud des machines virtuelles transite par l’ESG.

Son positionnement particulier dans l’architecture lui permet d’implémenter de nombreuses

fonctionnalités relevant des couches 3 à 7 du modèle OSI : NAT, DHCP, DNS, Load-balancer, et d’autres

services avancés que je détaillerai dans la dernière partie de cette présentation.

3 Sécurité et micro-segmentation

L’installation de NSX déploie sur les hyperviseurs un troisième module : le pare-feu distribué (DFW). Si

les composants présentés jusqu’ici ne font que virtualiser des fonctionnalités déjà existantes sur les réseaux

physiques, le pare-feu distribué permet une nouvelle approche de la problématique de sécurité concernant

les datacenters virtualisés.

3.1 Une DMZ pour chaque VM

Dans un réseau traditionnel, les machines connectées sur un même segment réseau peuvent communiquer

entre elles sans restriction. Le premier stade du filtrage s’effectue au niveau des routeurs du cœur de réseau,

entre les différents VLAN, sous la forme d’ACL. Il faut remonter jusqu’aux pares feux périmétriques

sécurisant les différentes zones (LAN / DMZ) pour bénéficier d’une possibilité de filtrage évolué, ou tout

au moins stateful.

On peut limiter ce problème en utilisant des VLAN privés (PVLAN). Cette technologie, disponible sur la

plupart des switches d’entreprise et sur les vNetwork Distributed Switches vSphere, permet de restreindre

le trafic de niveau 2 entre des ports et/ou des groupes de ports situés dans un même VLAN. Suffisants dans

plusieurs cas de figure, les PVLAN restent toutefois limités au niveau 2, et peuvent s’avérer complexes à

mettre en œuvre et à gérer sur le long terme.

Le Distributed Firewall apporte une réponse plus adaptée à ce problème, en positionnant un firewall dédié

derrière chaque interface réseau des machines virtuelles. L’ensemble des flux issus des interfaces réseau


d’une VM ou à destination de celles-ci transitent par l’instance de pare-feu qui lui est associée, et sont sujets

aux règles de filtrage définies par l’administrateur.

Si la politique de filtrage consiste à bloquer tout ce qui n’est pas explicitement autorisé, nous arrivons à une

situation où, par défaut, toutes les machines virtuelles du datacenter sont isolées les unes des autres,

quelle que soit leur proximité sur le réseau. Cette configuration originale est qualifiée de micro-

segmentation.

Figure 9 - Particularités de la micro-segmentation

Quelques éléments clés sur ce module :

Il est géré par le noyau des hyperviseurs. L’utilisation directe des ressources CPU des serveurs

permet d’atteindre des performances proches de la capacité maximum du lien (« line-speed »).

En conséquence, les performances globales du pare-feu à l’échelle du datacenter augmentent

proportionnellement à la quantité d’hyperviseurs.

Il s’applique sur les couches 2 à 4 du modèle OSI. Il est possible d’écrire des règles de filtrage

basées sur des adresses MAC, des adresses IP, et des ports source ou destination.

Il est stateful. Ceci est généralement perçu comme un avantage, mais peut provoquer des

comportements inattendus dans une situation où une VM disposant de plusieurs interfaces

réseau génère du routage asymétrique qui sera bloqué par le firewall (on parle d’expérience !)

L’administration du pare-feu distribué s’effectue au travers d’une interface dédiée dans la

partie Networking & Security du client web vSphere.


Figure 10 - Interface utilisateur du pare-feu distribué

Le pare-feu distribué est indépendant des fonctions de virtualisation présentées en première partie. Il

s’applique par défaut à toutes les VM des hôtes protégés, qu’elles soient connectées à des switches logiques

(VXLAN) ou à des groupes de ports standards (VLAN).

3.2 Particularités de la micro-segmentation

Une question revient fréquemment à propos du pare-feu distribué : quel niveau de confiance lui accorder,

sachant qu’il est entièrement logiciel et embarqué sur les hyperviseurs ? L’expérience montre que certaines

techniques dites de VM escape peuvent aboutir à la compromission d’un ou plusieurs hôtes. Dans ces cas-

là, on peut considérer, dans l’absolu, que le pare-feu distribué n’est plus fiable et que toutes les VM voisines

qu’il protégeait sont désormais vulnérables.

Il est important de préciser que cette fonctionnalité seule ne doit pas être considérée comme une sécurité

suffisante, et ne permet en aucun cas de s’affranchir des méthodes traditionnelles de protection. Il faut

la considérer comme un niveau de protection supplémentaire s’appliquant sur un périmètre qui jusque-là

ne bénéficiait que de possibilités limitées en termes de contrôle des flux. Le Cloud UFTMiP utilise par

exemple le pare-feu distribué, le pare-feu des ESG pour chaque tenant ET des pare-feux périmétriques

communs à toute l’infrastructure.

L’utilisation efficace de ce module impose une gymnastique intellectuelle qui n’est pas naturelle pour

quiconque est habitué aux pares-feux traditionnels, la notion d’interfaces entrantes et sortantes distribuées

sur les VM NIC étant différente des situations habituelles.

3.3 Utilisation des objets vSphere

Le DFW, géré par le NSX Manager synchronisé avec le vCenter, a connaissance des conteneurs vSphere.

Ceci offre la possibilité d’écrire des règles de filtrage dont les objets source et/ou destination sont

inventoriés dans le vCenter.

Voici quelques règles imaginaires illustrant ce cas de figure :

1. La VM nommée « coriolis » peut initier des connexions vers la VM nommée « doppler » sur le

port 443.


2. Les VM connectées au switch logique « webservices » peuvent initier des connexions vers celles

du switch logique « databases » sur les services Oracle, MSSQL et PostgreSQL.

3. Les VM des hôtes « ESX-15 » et « ESX-22 » peuvent échanger des requêtes ICMP.

L’avantage d’une règle utilisant de tels objets est le suivant : en cas de modification par l’administrateur

système de l’adresse IP d’une VM, il n’est pas nécessaire de modifier les règles de filtrage la concernant.

Attention toutefois : dans le cas où une VM est supprimée puis restaurée avec son nom initial (lors de la

restauration d’une sauvegarde par exemple), son identifiant vCenter est modifié et la règle de filtrage

devient inopérante. La correction nécessite une intervention manuelle, et dans l’intervalle la VM concernée

se retrouve isolée du reste du réseau. On parle d’expérience…

3.4 Filtrage est-ouest et nord-sud

Nous avons vu que le pare-feu distribué apportait une protection appréciable sur les flux est-ouest. Quid de

sa relation avec l’Edge Service Gateway, qui effectue pour sa part le filtrage nord-sud ? Prenons un exemple

concret : l’écriture d’une règle autorisant une VM à effectuer librement des requêtes DNS vers Internet.

Elle aura par défaut la forme suivante :

Source : VM « X »

Destination : « Any »

Service : « DNS-UDP »

Action : « allow » (avec l’option « log »)

Direction : out

Appliquée à : Distributed Firewall

Publiée en l’état, elle autorisera les connexions sortantes sur le port 53. Ce flux sera toutefois bloqué par le

pare-feu de l’ESG en sortie du réseau virtualisé. Pour éviter de réécrire manuellement la même règle sur

l’interface de l’Edge, il est possible d’ajouter l’ESG dans le champ « Appliquée à ». Ainsi, le NSX Manager

va automatiquement propager les règles nécessaires sur les hôtes ET sur l’Edge spécifiée.

Figure 11 - Périmètre d’application des règles de filtrage est-ouest et nord-sud


3.5 Sécurité contextuelle

L’utilisation combinée du pare-feu distribué et du NSX Manager permet d’implémenter une autre approche

de la sécurité, basée sur la notion de groupes de sécurité et de politiques de sécurité associées. Le terme

de sécurité contextuelle, qui n’apparaît pas dans le jargon VMware, semble adapté pour décrire la logique

mise en œuvre. Il est représenté dans l’interface vSphere sous le nom de Security Composer.

3.5.1 Security groups

Un groupe de sécurité NSX est un ensemble d’objets vSphere regroupés en une même entité. Il peut être

constitué de façon manuelle par l’administrateur (en ajoutant, par exemple, des VM spécifiques dans un

groupe nommé « serveurs web »), ou géré de façon dynamique par le NSX Manager.

Si la gestion manuelle existe déjà sur la plupart des pare-feux traditionnels, la gestion dynamique constitue

le véritable intérêt de la fonctionnalité. Elle est basée sur des conditions définies par l’administrateur et

s’appuie sur des attributs spécifiques des machines virtuelles. Prenons quelques exemples :

Les VM dont le nom commence par « db-srv » sont membres du groupe « Serveurs de bases

de données »,

Les VM dont le système d’exploitation contient « Windows 2012 » sont membres au groupe

« Serveurs Windows »,

Les VM sur lesquelles on a positionné l’attribut de sécurité « critique » sont membres du

groupe « Serveurs critiques ».

Il est également possible de combiner plusieurs conditions :

Les VMS associées à l’entité « switch_logique_production » ET dont le nom commence par

« web-srv » ET dont le système d’exploitation contient « linux » ET sur lesquelles est

positionné l’attribut « critique » sont membres du groupe « Serveurs web critiques Linux en

production ».

Figure 12 - Groupes de sécurité dans le Security Composer

Un groupe de sécurité peut contenir simultanément des objets dynamiques et des objets gérés

manuellement. Ce mélange des genres peut amener à une complexité excessive et causer des

comportements inattendus, mais il existe toutefois un cas de figure où il est intéressant : l’exclusion.

L’administrateur peut, par exemple, spécifier que les VM nommées « web-srv-temp18 » et « web-srv-

temp19 » ne seront pas intégrées automatiquement au groupe précédemment cité, même si elles satisfont à

toutes les conditions définies.


Les conditions sont constamment vérifiées par le NSX Manager : si l’administrateur supprime l’attribut

« critique » sur une des VM membres du groupe cité en exemple, elle en sera automatiquement retirée au

bout de quelques secondes.

Il est possible d’intégrer l’authentification Active Directory dans les critères d’appartenance à un groupe.

Ainsi, un utilisateur connecté à une VM Windows pourra automatiquement obtenir pour cette machine des

autorisations de flux spécifiques à son statut.

Les groupes de sécurité ainsi créés peuvent être utilisés manuellement dans les règles du pare-feu distribué,

en tant que sources, destinations, ou encore pour limiter le périmètre d’application de certaines règles. Ils

montrent tout leur potentiel lorsque l’administrateur les associe à des politiques de sécurité.

3.5.2 Security policies

Une politique de sécurité est constituée par un ensemble de mécanismes (ou services) que l’administrateur

va assigner à un groupe de sécurité, et qui vont s’appliquer à toutes les machines virtuelles membres du

groupe en question.

Ces services se répartissent en trois catégories :

Les services Endpoint, fournis par des éditeurs tiers (Antivirus par exemple),

Les règles de filtrage du pare-feu distribué,

Les services d’inspection réseau.

Nous nous focaliserons ici sur la partie filtrage.

Pour le Cloud privé de l’UFTMiP, nous avons créé des politiques correspondant aux différents templates

pouvant être provisionnés par un utilisateur. vRealize Automation positionne des attributs de sécurité sur

les VM ainsi déployées, qui sont automatiquement intégrées à des groupes de sécurité, sur lesquels sont

ensuite appliquées des politiques de sécurité autorisant certains flux réseau.

Par exemple, une VM « CentOS » acceptera automatiquement les connexions SSH entrantes. Si c’est un

template « CentOS + MySQL », une autre politique de sécurité autorisera les connexions TCP sur les ports

3306 et 5432, sans nécessiter l’intervention des administrateurs réseaux.

Les règles de filtrage générées par les politiques de sécurité sont visibles dans l’interface d’administration

du pare-feu distribué, dans une section dédiée.

3.5.3 Exemple d’utilisation avec des produits tiers

Associée à des produits tierce partie, la sécurité contextuelle permet d’automatiser des mécanismes de

protection évolués, comme le proposent certains pares-feux périmétriques haut de gamme.

Par exemple, une politique de sécurité « Scan antivirus » peut déclencher des analyses sur toutes les VM

membres d’un groupe « desktop Windows ». En cas de détection d’une menace, l’antivirus va positionner

un attribut de sécurité « VirusFound » sur la VM, ce qui la fera automatiquement changer de groupe de

sécurité pour intégrer un groupe « Quarantaine ».

Sur ce groupe « Quarantaine » sera appliqué une politique « nettoyage et quarantaine » qui déclenchera un

nettoyage de la VM tout en bloquant les connexions vers des adresses autres que celle du serveur Antivirus

centralisé.

Une fois le nettoyage effectué, le module antivirus va retirer l’attribut « VirusFound » et la VM rejoindra

automatiquement son groupe de sécurité initial : « desktop Windows », retrouvant par la même occasion sa

connectivité d’origine.

Les possibilités offertes par le Service Composer étant virtuellement illimitées, il convient d’effectuer un

consciencieux travail préparatoire avant de se lancer dans l’aventure, afin de définir le plus tôt possible les

comportements attendus et la stratégie à mettre en œuvre.


4 Edge Service Gateway

L’Edge Service Gateway (ESG) est un composant essentiel de tout déploiement NSX. Elle permet, à

minima, d’effectuer la transition entre le réseau virtualisé et les réseaux physiques en liaison montante. En

fonction de l’architecture cible et des ressources disponibles, l’administrateur peut déployer plusieurs

instances d’ESG. Le modèle choisi pour le Cloud UFTMiP est appelé multi-tenancy, avec une ESG par

tenant.

Figure 13 - Architecture logique multi-tenants du Cloud UFTMiP

C’est la seule appliance de la plateforme NSX participant au data plane : il est important de considérer que

l’ensemble des flux qui la traversent sont gérés par les vCPU et les interfaces réseau de sa machine virtuelle.

Il existe quatre dimensionnements possibles qui doivent être choisis avec soin en fonction du trafic véhiculé

et des services que l’on souhaite implémenter.

4.1 Routage

L’ESG est avant tout un routeur. À ce titre, elle participe au plan de contrôle et gère l’adjacence avec les

routeurs voisins (généralement top of rack). Elle dispose de dix interfaces utilisables pour la liaison

montante et les liens vers le réseau interne, et permet d’implémenter du routage statique et dynamique

(eBGP, iBGP, et OSPF).

4.2 Haute-disponibilité

L’ESG peut être déployée selon deux modèles différents en fonction des besoins : en mode HA

(actif/passif), ou en mode ECMP (actif/actif) pour assurer la répartition de charge et augmenter la bande

passante.

En mode ECMP, jusqu’à 8 ESG peuvent être actives simultanément, mais la plupart des services stateful

sont indisponibles. Seuls le routage et le forwarding sont possibles en raison de la nature asymétrique des


flux. Les architectures ECMP garantissent un temps de convergence quasiment immédiat en cas de

défaillance d’une appliance.

Le mode HA déploie deux appliances par instance d’ESG : une active et une passive. Les deux VM sont

constamment alimentées et échangent un heartbeat. Si l’ESG passive détecte une défaillance du heartbeat,

elle passe en mode actif et démarre l’ensemble de ses services configurés. Le temps de convergence varie

en fonction du type de routage et des timers utilisés.

4.3 Firewall

L’ESG embarque un firewall dédié aux flux nord-sud. À l’instar du pare-feu distribué, il est stateful et

administré via l’interface de gestion de l’Edge dans le client vSphere. Ce firewall et le pare-feu distribué

peuvent être utilisés indépendamment ou de façon conjointe. L’utilisation de plusieurs ESG dans le cadre

du Cloud privé permet de gérer la politique de filtrage de façon distincte pour chaque tenant, pour s’adapter

aux politiques de sécurité propres aux établissements membres.

4.4 VPN

L’ESG peut être utilisée comme terminaison VPN de niveau 2 et 3. L’utilisation de tunnels de niveau 3 est

possible en IPSec ou en SSL. Ces deux services sont distincts et indépendants.

Dans le cadre du projet UFTMiP, nous utilisons des tunnels IPSec pour interconnecter les réseaux de

campus des établissements membres avec leurs tenants correspondant sur le Cloud. Les administrateurs de

VM et les responsables du maintien en condition opérationnelle peuvent ainsi accéder de façon transparente

au périmètre réseau qui leur est affecté.

Le service VPN SSL est disponible pour les administrateurs en mobilité. Une interface web gérée par l’ESG

permet de télécharger un package d’installation client prêt à l’emploi, pour les plateformes Windows, OSX

et Linux.

Ces deux services VPN ont été utilisés avec succès par des endpoints utilisant le client libre Openvpn, ou

en association avec des firewalls Stormshield, Palo Alto et Fortinet.

5 Conclusion

L’expérience acquise sur NSX durant ces trois années de mise en œuvre et d’exploitation peut se résumer

de la façon suivante :

5.1 Avantages

Facilité de déploiement et de dimensionnement de l’infrastructure réseau virtualisée

Simplification des opérations de configuration sur les équipements physiques

Optimisation des ressources

Gestion centralisée grâce à l’intégration au client vSphere

Automatisation via l’API REST ou l’interaction avec vRealize

Micro-segmentation et sécurité contextuelle

5.2 Inconvénients

Coût des licences

Solution propriétaire

Learning curve

Exploitation des logs


Complexification des opérations de diagnostic

Ergonomie de l’interface utilisateur vSphere (règles de filtrage)

Manque de maturité de la solution (bugs, stabilité de certains services)

5.3 Si c’était à refaire ?

S’il fallait ne retenir que deux recommandations à l’attention des collègues intéressés par la plateforme, ce

seraient les suivantes :

Tout d’abord : formez-vous avant même de commencer à réfléchir à l’intégration de NSX à votre

architecture existante ou au déploiement d’une nouvelle infrastructure. La solution est complexe en termes

de technologies et de fonctionnalités, et il est nécessaire d’en avoir une excellente vision d’ensemble avant

de prendre la moindre décision.

VMware fournit des supports de documentation très détaillés sur NSX, qui seront indispensables lors de

des phases de design, d’installation et de configuration. L’équipe du Cloud s’est formée sur le tard, et nous

sommes ainsi passés à côté de certaines possibilités d’optimisation qui ont été compliquées à mettre en

œuvre une fois la plateforme en production.

Ensuite : expérimentez, maquettez. Tous les protocoles implémentés par NSX sont standards, et si votre

expérience préalable d’administrateur réseau vous suffira amplement à comprendre et appréhender les

mécanismes mis en œuvre, il en sera autrement pour la partie implémentation et configuration. L’utilisation

du client vSphere ou de l’API du NSX Manager ne sont pas « naturelles ». En outre, la relative jeunesse de

la plateforme confère à son interface d’administration quelques bugs et comportements originaux, qui sont

heureusement contournables… une fois qu’on en a fait l’expérience.

Le choix de NSX pour l’infrastructure du Cloud UFTMiP, il y a maintenant 3 ans, était sans aucun doute

un pari risqué. Nous avons parfois payé le prix de cette décision, en termes de bugs, de comportements

inattendus ou mal compris, et de problèmes de stabilité.

Il faut toutefois souligner les efforts considérables de VMware en matière d’accompagnement, de support

et de développement. Leur investissement dans ce produit semble démontrer une réelle ambition sur le long

terme, loin du simple effet de mode.

À mon sens, la plupart des inconvénients de NSX sont liés à son manque de maturité, et ses avantages

résident dans sa philosophie. Si elle ne constitue évidemment pas une solution idéale dans tous les

environnements, cette plateforme mérite d’être étudiée avec attention.

Quelles que soient les technologies implémentées en matière de système, de stockage ou de réseau, il

semble inconcevable que les datacenters Cloud de demain puissent se dispenser de virtualiser tout ou partie

de leurs infrastructures. Que chacun fasse son choix, en espérant surtout qu’à la fin il n’en restera pas

qu’un !

virtualisation des réseaux en environnement vsphere avec nsx

Documents