Souvent considéré comme le point faible d'OpenStack, le NaaS d'OpenStack est un vrai frein au déploiement de cloud à grande échelle. Nous allons, dans ce premier article, expliquer le fonctionnement de Neutron et comprendre comment cette solution peut utiliser des technologies très différentes.

Qu'est-ce que Neutron ?

Neutron est la brique haut niveau qui gère toutes les fonctions réseau d'OpenStack. Il fournit un NaaS (Network as a Service) à la couche supérieure (Nova). Mais attention, gérer ne veut pas dire que Neutron s'occupe seul de cette tâche, Neutron délègue les actions à des plugins que nous verrons plus tard.

Pour fonctionner, Neutron a besoin d'une base de données et d'un service de messaging queue. Les réseaux, les sous-réseaux, les ports et les security groups sont stockés dans la base de données. Le système de messaging queue permet à Neutron de recevoir les ordres et de les transmettre à tous les services dont il a besoin (dont ses agents).

Il est important de comprendre que Neutron sera toujours présent dans un cloud OpenStack, peu importe les choix qui ont été faits pour l'implémentation de la couche réseau.

Un peu d'histoire

A l'origine, le NaaS était géré par un composant de Nova appelé nova-network et était capable d'utiliser LinuxBridge pour construire un flat network uniquement.

Avec la sortie de la release Folsom d'OpenStack, fin 2012, le service Quantum est sorti. Quantum a apporté beaucoup de nouveautés par rapport à nova-network comme le support des overlapping IP sur des réseaux L2 différents ou le multi-routeurs. (liste complète). A partir de la release Havana d'OpenStack (fin 2013), Quantum a dû changer de nom et est devenu Neutron.

Le rôle du NaaS sur OpenStack

Le Network as a Service sur OpenStack sert à fournir une connectivité aux instances hébergées dans le cloud. Neutron prend en charge la connectivité L2 et L3 des instances. Le niveau L2 est le transport des paquets dans le même réseau. Le niveau 3 gère le routage des paquets entre différents réseaux et les fonctions avancées comme dans certains cas le LB. Dans un cloud, on parle de deux types de trafic :

• Le East-West: c'est le trafic entre les instances appartenant au cloud.
• Le North-South: c'est le trafic du cloud vers l'extérieur.

Afin de répondre à ce besoin, le rôle de la brique réseau d'OpenStack est de configurer un socle réseau "façon cloud", c'est-à-dire avec les problématiques suivantes :

• trafic cloisonné entre les réseaux, les projets (apellés parfois les tenants)
• configuration à la volée du réseau, routage dynamique
• gérer les règles de sécurité du trafic de facon spécifique à un projet ou une instance (security group).

La scalabilité qui permet de redimensionner le service en fonction de la demande est un point également important dans le cloud.

Pour répondre à ces problématiques, le SDN est la solution !

Parlons SDN

Le SDN, pour Software Defined Network, est la philosophie qui veut que le réseau soit géré de manière dynamique en respectant des règles définies globalement.

Schématiquement, l'intelligence du réseau est déportée des équipements réseaux vers un élement que l'on appelle contrôleur SDN.

Ce contrôleur SDN tient un Northbound application programming interface (API) qui lui permet de dialoguer avec les services ou les applications à travers le réseau et un Southbound application programming interface (API) qui lui permet de dialoguer avec les switchs et les routeurs du réseau.

Le Northbound API permet de dialoguer avec les plates-formes d'automatisation comme OpenStack à travers le plugin Neutron adapté. Ce Northbound API introduit un niveau d'abstraction pour la couche applicative qui permet à l'applicatif de ne pas connaître et comprendre le niveau réseau.

Le Southbound API permet d'effectuer les changements de configuration sur les équipements reseau. Les protocoles utilisés peuvent être par exemple :

• Openflow
• Open vSwitch Database Protocol (OVSDB)
• NETCONF
• Locator/Identifier Separation Protocol (LISP)
• Border Gateway Protocol (BGP)
• Path Computation Element Communication Protocol (PCEP)
• Simple Network Management Protocol (SNMP)

- Les grandes familles de solutions SDN

Les solutions se divisent en deux familles :

• la première utilise le principe de l'encapsulation (GRE ou VXLan) qui permet de construire un réseau superposé avec les avantages (matériel réseau standard) et les inconvénients de cette technique (flux pas toujours optimisés, débit utile diminué).
• la seconde famille pilote des équipements physiques pour segmenter les réseaux des projets. Ces solutions sont plus chères à mettre en place car elles reposent sur une infrastructure réseau compatible SDN. On trouve beaucoup de solutions propriétaires comme Nuage Networks de Alcatel Lucent ou Cisco ACI. Il existe aussi des solutions open source comme OpenDaylight ou OpenContrail.

Revenons à Neutron

Comme vu précédemment, Neutron est un composant haut niveau qui est capable d'interagir avec beaucoup de solutions sous-jacentes. Il est composé de plusieurs services qui sont deployés sur plusieurs noeuds de l'infrastructure OpenStack.

- Neutron server

C'est le service principal, il fournit les API réseau. Il utilise la base de données pour son fonctionnement et un service de messaging queue pour les communications inter-services du cloud et vers ses agents (voir ci-dessous).

- Les plugins Neutron

Ce sont des éléments qui s'ajoutent au service principal neutron server. Ils utilisent une grande variété de technologies pour répondre à certaines requêtes API qui ne seront plus gérées par le service initial.

Certains plugins basiques utiliseront iptables, et d'autres s'interfaceront avec les solutions SDN physiques. Les plugins accèdent également au service de messaging queue.

Il existe deux catégories de plugins, les cores et les services. Les cores plugins gèrent la connectivité L2 et les IP des instances; les services plugins gèrent quant à eux le NFV (Network Function Virtualization) comme le FWaaS et le LBaaS.

Exemples de plugins Neutron :

• ML2
• L3 router
• FWaaS

Modular Layer 2 plugin

Il s'agit d'un plugin important introduit dans la release Havana d'OpenStack (fin 2013). Il permet à Neutron d'utiliser une grande variété de technologies réseau pour la couche L2. Ce plugin supporte différents types de réseaux au travers d'un type driver: * local * flat * vlan * gre * tunnel * vxlan.

Ce type driver valide la configuration des réseaux L2 et alloue le réseau niveau cloud. Ensuite, un mechanism driver applique cette configuration sur le réseau L2. Voici une liste non exhaustive de mechanism driver :

• Arista
• Bigswitch
• Brocade
• Brocade MLX ICX
• Cisco
• Freescale
• L2 population
• OpenDaylight
• OpenFlow Agent
• OpenvSwich
• LinuxBridge
• PLUMgrid
• Tail-f NCS
• SR-IOV

- Les agents Neutron

Les agents se trouvent sur chaque compute node (serveurs qui hébergent les instances). Le choix des agents dépend des plugins qui sont utilisés; certains plugins n'auront pas besoin d'agents. Parmis les agents, le DHCP et le L3 sont particuliers, ils n'ont pas besoin d'être présents sur tous les compute nodes.

Exemples d'agents Neutron:

• neutron-dhcp-agent
• neutron-l2-agent
• neutron-l3-agent
• neutron-metering-agent
• neutron-lbaasv2-agent

L2 agent (ou équivalent)

Présent sur tous les compute nodes, cet agent est responsable de la segmentation des réseaux dans le cloud. Il s'occupe donc de la connexion et de la sécurisation des interfaces virtuelles. Il dialogue avec la solution SDN pour mettre en place les flux. Il existe autant de L2 agents qu'il existe de technologies supportées par OpenStack.

L3 agent (pas toujours présent)

Présent sur des noeuds dédiés au réseau, il s'occupe du routage des réseaux dans les projets cloud. Il s'occupe également de certaines fonctions comme le FWaaS et le VPNaaS (en communiquant avec le plugin adapté).

DHCP agent (pas toujours présent)

Présent sur des noeuds dédiés au réseau, il s'occupe du DHCP pour les réseaux dans les projets cloud sur lesquels il est activé.

Conclusion

Voila, j'espère que cet article vous a aidé à comprendre le fonctionnnement de Neutron. Comme nous l'avons vu, Neutron est hautement personnalisable et s'adapte à beaucoup de technologies SDN. Dans les prochains articles, je détaillerai les architectures Neutron les plus répandues en les comparant afin de choisir la plus adaptée à votre besoin.

Kourosh VIVAN