OpenStack Summit Tokyo 2015 Jour 1 : Focus sur Neutron

Publié le 28/10/2015

par Kevin Lefevre

dans OpenStack

⭠ Retour à la liste des articles

Cet article fait partie du dossier spécial OpenStack Summit 2015 :

Jour 1 : Focus sur Neutron

Des sessions autour de Neutron se sont succédées au cours de la journée. J'ai assisté à 3 sessions sur neutron:

Évolution du routeur distribué (DVR) (Takanori Miyagishi, Hanzhang Shi)
Fonctionnalités de routage dynamique avec BGP (Vikram Choudhary, Jaume Devesa, Ryan Tidwell)
Intégration de Neutron et Docker libnetwork avec Kuryr (Mohammad Banikazemi, Phil Estes)

Vers un DVR vraiment distribué

Le routage sur Neutron a suivi de nomeuses évolutions au fur et à mesure des différentes releases d'OpenStack. Depuis Juno, les routeurs virtuels des tenants sont distribués sur les nœuds compute, facilitant la scalabilité et la tolérance de panne.

Au cours de cette première session, nous avons fait un tour d'horizon des différentes évolutions du routeur Neutron pour ensuite se focaliser sur les évolutions de Liberty ainsi que sur la roadmap de Mitaka et les difficultés rencontrées afin de réaliser un routeur complètement distribué et de se débarrasser complètement du nœud réseau.

Dans la suite de l'article, on distingue 6 types de flux:

Direction	Flux
Est - Ouest	Instance vers une instance de même sous-réseau
Est - Ouest	Instance vers une instance d'un sous-réseau diffèrent
Est - Ouest	Instance vers DHCP
Est - Ouest	Instance vers service de metadata
Nord - Sud	Instance avec Floating IP
Nord - Sud	Instance en source NAT

Neutron sans DVR

Avant Juno et l'apparition du DVR, le trafic était centralisé au sein d'un nœud dédié aux fonctionnalités réseaux, créant un SPOF et difficilement scalable bien qu'il soit possible d'atteindre un certain niveau de haute dispo avec des solutions comme HAproxy, Keepalive et VRRP pour les vRouter.

Si l'on reprend la grille de trafic précédente, la majorité du trafic réseaux passe par le nœud réseau.

Direction	Flux	Utilise le noeud réseau
Est - Ouest	Instance vers une instance de même subnet	NON
Est - Ouest	Instance vers une instance d'un sous-réseau different	OUI
Est - Ouest	Instance vers DHCP	OUI
Est - Ouest	Instance vers service de metadata	OUI
Nord - Sud	Instance avec Floating IP	OUI
Nord - Sud	Instance en source NAT	OUI

5/6 des flux transitent par le noeud réseau.

Depuis Juno : Neutron avec DVR

Depuis Juno les services L3-agent et metadata-agent ont été distribués sur les noeuds compute. Seule le source nat et l'agent DHCP restent sur le noeud réseau.²

Direction	Flux	Utilise le noeud réseau
Est - Ouest	Instance vers une instance de même subnet	NON
Est - Ouest	Instance vers une instance d'un sous-réseau different	NON
Est - Ouest	Instance vers DHCP	OUI
Est - Ouest	Instance vers service de metadata	NON
Nord - Sud	Instance avec Floating IP	NON
Nord - Sud	Instance en source NAT	OUI

2/6 des flux transitent par le nœud réseau.

Discussions depuis Liberty

Le DVR est déjà prèsque complètement distribué, les discussions se tournent vers les deux derniers services encore centralisés : le DHCP et le source NAT.

Distribution de l'agent L3 Source NAT

La distribution du source NAT présente des difficultés. Le comportement par défaut est actuellement qu'un vRouter dispose d'une IP de source NAT donc de multiple routeurs impliquent de multiples IP de source NAT.

L'objectif est de trouver une solution scalable qui limite le nome d'IP consommées tout en gradant un niveau de securité entre les tenants. Plusieurs idées ont été évoquées lors des discussions :

Comportement par défaut : 1 IP de SNAT par vRouteur. Le routeur étant distribué le nome d'IP consommées pour un tenant serait de Nb vRouter x Nb Compute. Ce qui ne passe pas du tout à l'échelle sauf pour les déploiements de petite taille.
Une IP de SNAT par nœud compute : pose des problèmes de sécurité sur le fait de partager une même IP entre différents tenants. Le nome d'IP consommées pour un tenant serait de Nb Compute.
Une IP de SNAT par nœud compute par tenant : les vRouter d'un même tenant sur un même compute utilisent la même IP de SNAT. Cette solution est un compromis entre le comportement par défaut et la solution précédente. C'est cette solution qui sera supportée par les speakers pour Mitaka car elle ne nécessite pas de nouveau matériel et offre toujours la possibilité d'utiliser le nœud réseau centralisé dans le cas de déploiements de petite taille.
Annonce via BGP : les pools de SNAT des tenants sont annoncés via BGP aux upstream routeur. Cette fonctionnalité n'est pas implémentée dans Neutron. Une session spéciale sur l'implémentation de BGP dans Neutron a eu lieu dans la même journée et est détaillée dans la suite de l'article.

Distribution de l'agent DHCP

Pour le moment, l'implémentation de la haute disponibilité au niveau du DHCP est réalisée par l'utilisation de plusieurs agents DHCP au sein du nœud réseau fonctionnant en actif/actif.

Avec cette configuration, on rencontre les problèmes suivants dans le cas de passage à l'échelle.

Consommation des IP : 1 IP par service.
Consommation des ressources : namespace, mémoire, processeur.
Le trafic de management du nœud réseau peut être impacté.
Dans le cas de gros déploiements, certaines instances ne parviennent pas à récupérer un bail DHCP.

Une idée évoquée à été piochée dans nova-network avec par exemple l'utilisation d'un service DHCP par nœud compute. Ce service gérerai DHCP et dnsmasq uniquement pour les instances présentes sur le nœud. Cette solution est facilement passable à l'échelle puisque par exemple pour 10 instances et 3 réseaux diffèrents par instances (sur un nœud compute), seulement 30 namespaces sont necessaires.

Mitaka Roadmap

Les spécifications sont en cours de validation pour Mitaka 1 pendant les designs summit de cette semaine. Des changements suivront ensuite pour l'implémentation dans OVS et finalement le driver ML2 ainsi que les autres plugins.

Neutron : implémentation de BGP

La deuxième session Neutron portait sur l'implémentation d'un protocole de routage dynamique dans Neutron. Pourquoi BGP ? Pour sa simplicité, ses fonctionnalités en terme de configuration et son fonctionnement en TCP contrairement aux autres protocoles de routage tels que IS-IS ou OSPF. De plus la notion d'AS et la séparation de plan de contrôle et du plan de donnée permettent un flexibilité en terme de design aussi bien au niveau du Cloud qu'au niveau de l'infrastructure réseau sous-jacente.

Actuellement dans Neutron le routage du trafic se fait de manière classique, par l'ajout de routes statiques. Par exemple, dans le cas des pools de floatings IP, une intervention sur l'infrastructure réseau est souvent nécessaire.

L'utilisation de BGP permet entre autres de:

Supprimer les associations statiques de floating IP à un réseau particulier. Neutron pourrait les annoncer de manière dynamique à l'infrastructure réseau existante.
Faire du routage direct des sous-réseaux des tenants tout en s'assurant qu'il n'y ait pas d'overlapping d'adresses. Ce modèle supprime le complexité liée au NAT.
Faciliter l'utilisation d'IPv6 oú les floatings IP n'ont plus vraiment de sens. En utilisant la solution de routage directe ci-dessus, les IPv6 sont directement annoncées au réseau upstream.
Faciliter l'évolution du DVR. C'est une des solutions envisagées afin de réaliser un routeur Neutron complètement distribué :
- Annonce des IP des serveur (/32) avec pour next-hop l'IP du nœud compute.
- Pour réduire la consommation des IP, les IP des next-hop peuvent être des IP de lien local.
- Un problème se pose, comment agréger les tables de routage (/32 x nome d'instances).

Ce sont les points de départ du projet qui commenceront à partir de Mitaka. Dans un premier temps, Neutron annoncera uniquement ses routes mais n'apprendra pas de l'infrastructure. D'autres conjectures ont été faites pour un futur plus lointain sur les cas d'utilisation potentielle de BGP:

Utilisation de MPLS/BGP comme un overlay pour le trafic inter-tenant.
L3VPN et L2VPN basés sur BGP et MPLS.

Draft de l'architecture

Sur le contrôleur : neutron-server avec un plugin de service BGP qui communique avec des dr-agent (dynamique routing agent)
Sur les nœuds compute ou nœuds dédiés : Neutron BGP routing agent qui supporte plusieurs implémentations de BGP, par exemple Quagga ou BIRD.

Unification du réseau entre les conteneurs et les instances

Le point abordé lors de la dernière session était l'unification de Neutron avec Docker. Depuis la version 1.9 Docker a dissocié la libnetwork de docker core et propose un système de plugins réseaux. C'est ici qu'intervient Kuryr, un projet OpenStack Big Tent. Kuryr réalise l'interface entre l'API Docker et celle de Neutron pour offrir aux conteneurs les mêmes possibilités que les instances Nova avec Neutron.

Au cours de la session, une démonstration de la communication entre des containers et des instances sur le même réseaux Neutron a eu lieu.

Le projet est prometteur mais certains points sont laissés en suspend, notamment comment adresser le réseau des conteneurs Docker s'exécutant dans des instances ? C'est un cas fréquent d'utilisation afin d'assurer une isolation supplémentaire. D'autre sessions détaillant le fonctionnement de Kuryr ont lieu aujourd'hui (jour 2) et feront l'objet d'un article dédié.

Kevin Lefevre

Rejoignez vous aussi la conversation !

Questions, remarques, suggestions... Contactez-nous directement sur Twitter sur @osones !
Pour discuter avec nous de vos projets, nous restons disponibles directement via contact@osones.com !
Enfin, la communauté Francophone d'OpenStack vous attend sur http://openstack.fr/ !