Au bureau, en déplacement ou sur un transat, l’équipe Osones profite de l’été pour vous proposer des “cahiers de vacances” : des retours concis et illustrés de nos conférences favorites durant l’#OpenStackSummit de Boston.

On continue notre tournée estivale avec un focus sur Neutron !

Vous pourrez également retrouver nos focus sur OpenStack-Ansible, Heat et Cinder.

Qu’est-ce que Neutron ?

Aujourd’hui déployé sur 95% des Clouds OpenStack à travers le monde, Neutron est un NaaS pilotable via API, permettant la gestion des infrastructures multi-tenants et scalables. Neutron est donc la brique haut niveau qui gère toutes les fonctions réseau d'OpenStack. Mais attention, gérer ne veut pas dire que Neutron s'occupe seul de cette tâche : le service délègue ses actions à des plugins.

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 service central de Neutron (neutron-server) reçoit les différentes actions à réaliser par les APIs comme la création d’un réseau privé, d’un port… Il utilise ensuite la messaging queue pour transmettre les ordres à tous les services dont il a besoin (notamment ses agents). Cette architecture qu’on retrouve dans beaucoup de services d’OpenStack permet à l'ensemble d'être scalable, robuste et modulable.

Vous pouvez par ailleurs avoir plus d’informations sur Neutron dans notre dossier dédié.

Un point sur les sous projets de Neutron

La conférence revient sur les sous-projets les plus récents de Neutron :

- Les sous-projets "backends"

• MidoNet

Midonet est une couche d’abstraction entre votre IaaS et le réseau de votre hardware. Networking-midonet, un ensemble de plugins Neutron et de drivers spécifiques à MidoNet, vous permet de profiter de features avancées que propose ce backend de Neutron, tel que des L2 gateways, des Firewall, du routing dynamique, du Load Balancing et il supporte le “Tap-as-a-Service“, un service OpenStack de monitoring réseau relativement récent.

https://github.com/openstack/networking-midonet

• OpenDaylight

C’est un des premiers contrôleurs SDN pilotables par Neutron. Après un certain nombre d’itérations, Networking-odl vous propose les plugins et drivers permettant d’intégrer OpenDaylight et ses fonctions à Neutron. Il propose par exemple les drivers ML2 et le plugin L3 permettant la communication entre les ressources L2 et L3 de l’API Neutron et le backend OpenDaylight.

https://github.com/openstack/networking-odl

• OVN

Plus récent, Open Virtual Network (OVN) est un projet proposé par l’équipe d’OpenVSwitch (OVS) assez similaire à OpenDaylight. Parmi les fonctions à remarquer, OVN peut proposer l’intégration d’orchetrateurs de conteneurs, notamment Kubernetes.

https://github.com/openstack/networking-ovn

• BaGPipe

Initiative d’Orange Telecom, BaGPipe propose des drivers ML2 pour isoler vos projets à l’aide de VPN BGP (Border Gateway Protocol - le protocole de routage standard couramment utilisé sur Internet pour échanger des informations de routage et d’accessibilité entre plusieurs réseaux).

https://github.com/openstack/networking-bagpipe

- Les sous-projets "APIs"

• BGPVPN

Ce projet propose une API et un framework pour inter connecter des VPN BGP/MLPS aux réseaux, routeurs et ports Neutron d’OpenStack. Cette API s’implémente avec les drivers OVS, OpenDaylight, OpenContrail et Nuage.

https://github.com/openstack/networking-bgpvpn

• Dynamic Routing

Dynamic Routing est un moyen de contourner la limitation de routes statiques.

https://github.com/openstack/neutron-dynamic-routing

• Firewall as a Service

Neutron FWaaS est un modèle de sécurité zero-trust (à opposer à des security groups) permettant d’appliquer des policies via API.

https://github.com/openstack/neutron-fwaas

• Service Function Chaining

SFC est une API qui permet la définition de port chains. Le concept de service chaining est issue de NFV : le service chaining qui consiste à "chaîner" plusieurs fonctions réseaux afin d'en réaliser une plus complexe.

https://github.com/openstack/networking-sfc/

Neutron : en route vers Pike

La conférence présente ensuite les blueprints Neutron en cours pour Pike :

• Oslo Versioned Objects, permettant les rolling upgrades et les notifications push.
• Multiple Port Bindings, aidant à résoudre les soucis des migrations à partir de multi backends.
• Security group logging, permettant aux opérateurs API de logger ACCEPT/DROP pour les security groups.
• Quota Usage API, affichant plus de détails sur l'utilisation du quota en tps réel
• RBAC rules for domains, fait par Kourosh Vivan de l’équipe Osones pour couvrir le besoin d'un de nos clients qui souhaite partager un réseau externe uniquement à un domaine particulier.
• Un nouveau framework pour les petits plugins, offrant des checks de diagnostic.
• QoS Ingress Rule support, une extension du framework QoS pour supporter les restrictions de bande passante ingress.
• Enfin, les Community Goals : support de Python 3 et support du WSGI.

Les visions pour Queens - la prochaine release qui devrait suivre à Pike - sont encore très vagues et il est surtout question des fonctionnalités. Le processus pour demander une nouvelle fonctionnalité est le suivant : faire un RFE avec un rapport de bug et expliquer en un paragraphe ce qu'on souhaite, ensuite les développeurs se réuniront pour discuter de l'implémentation (au PTG, au Summit...).

Vous pouvez retrouvez la conférence dont sont tirées ces informations sur Youtube :

Aller plus loin avec Neutron

Introduction à Neutron, le NaaS d'OpenStack

RDV la semaine prochaine pour un nouvel article de notre série estivale sur l'OpenStack Summit de Boston, et d'ici là sur Twitter !