Le réseau dans OpenStack : Neutron

Introduction

Cet article a pour objectif de présenter OpenStack et en particulier le module qui est chargé du réseau : Neutron. Cette présentation n’est pas exhaustive, il s’agit d’un simple tour d’horizon pour comprendre le fonctionnement global de Neutron, et à travers celui-ci comprendre de manière plus générale celui d’OpenStack

Le projet OpenStack

OpenStack est une suite logicielle qui permet de gérer une plateforme de cloud computing. C’est à l’origine un projet open-source lancé conjointement par l’hébergeur américain Rackspace et la NASA en 2010. Son but est de permettre à n’importe quelle entreprise de gérer son cloud, qu’il soit public ou privé. Aujourd’hui c’est un système reconnu et utilisé par nombre d’acteurs du cloud, notamment les deux clouds souverains français (financés à hauteur de 75 millions d’euros par l’état) que sont Numergy et CloudWatt

OpenStack est composé de plusieurs modules qui remplissent chacun un rôle. On peut citer parmi les plus importants :

• Nova : gestion des machines virtuelles
• Cinder : gestion des volumes de stockage
• Horizon : interface web de paramétrage
• Neutron (auparavant nommé Quantum) : gestion du réseau

Ces modules ont pour but de présenter une API générique indépendante du type de ressource qui doit être gérée. Elles peuvent être appelées par Horizon dans le cas d’une configuration utilisant la Web GUI native ou bien par toute autre application capable d’interagir avec ces API comme par exemple le module d’orchestration Heat, la GUI Aurora créée par Paypal ou bien encore une application maison.

Neutron : Le module réseau

Le réseau étant un sujet de prédilection ici, prenons le cas de Neutron pour comprendre l’architecture modulaire d’OpenStack

Neutron a pour but de :

• connecter les machines virtuelles en reproduisant une infrastructure réseau virtuelle (architecture multi-tiers par exemple)
• isoler les clients entre eux
• éventuellement, apporter les services réseaux supplémentaires (Firewall, Load Balancer, VPN …)

Pour cela, OpenStack défini plusieurs abstractions pour l’infrastructure réseau

• Port : C’est la représentation des cartes réseau des VM, aussi appelées Virtual NIC ou vNIC
• Network : C’est un segment virtuel de niveau 2, c’est à dire un domaine de broadcast (typiquement  un VLAN, mais peut également être un tunnel GRE ou un VxLAN)
• Subnet : c’est un plan d’adressage, en principe on a un subnet pour un network, mais comme sur une infrastructure physique, il est possible de créer plusieurs subnets par network
• Router : un routeur virtuel, capable de router entre les subnets et d’effectuer de la NAT pour sortir sur Internet
• Floating IP : une IP sur un réseau (network) externe qui pointe sur un port. C’est donc la NAT externe de notre VM

Cette couche d’abstraction va permettre de créer une infrastructure réseau sans se préoccuper des technologies utilisées. En effet l’API ne définit que les moyens de gérer ces abstractions, et non pas leur implémentation qui est définie au niveau des plugins. En ce qui concerne le réseau, le plugin ml2 (modular layer 2) gère l’implémentation de la configuration réseau. C’est un plugin modulaire sur lequel on peut greffer différents drivers correspondant soit à des types de réseau (VLAN, GRE, VxLAN) soit à des mécanismes (c.à.d. des implémentations spécifiques, par exemple pour Cisco ou VMWare). Cela lui permet de gérer de nombreuses implémentation différentes, que ce soit pour des switches virtuels tels que Open vSwitch, linux bridge, hyper V, ou des switches physiques, et en plus d’être facilement extensible (si l’on veut introduire un nouveau type de réseau ou si un constructeur/éditeur veut ajouter le support pour ses équipements, seule la partie driver est à écrire)

Architecture du plugin ML2

Prenons un exemple concrêt pour illustrer le fonctionnement, avec l’architecture suivante :

• Des “Compute Nodes” : ce sont les hyperviseurs qui hébergent les VM. Ils possèdent le plugin agent ML2 capable  de gérer le switching virtuel (OpenvSwitch, Linux Bridge, Cisco Nexus 1000v …)
• Un “Network Node” : il sera chargé de la connectivité L3 (routage, NAT, DHCP …). Il possède également un plugin agent pour le switching, mais surtout un agent l3 pour la partie routage.
• Un “Cloud Controller Node” : c’est le serveur qui présente l’API externe et qui communique avec tous les agents
• Un routeur physique servant de passerelle vers Internet

Infrastructure OpenStack

Regardons comment créer cette infrastructure à partir de la ligne de commande de notre serveur Neutron :

Création de nos deux segments réseaux :

neutron net-create net100
neutron net-create net200

Création d’un réseau IP pour chaque vlan

neutron subnet-create net100 10.10.100.0/24 --name subnet100
neutron subnet-create net100 10.10.200.0/24 --name subnet200

Création du routeur virtuel

neutron router-create router1

création d’une interface dans les deux réseau des VM

neutron router-interface-add router1 net100
neutron router-interface-add router1 net200

création de l’interconnexion vers le réseau public

neutron net-create public --router-external=True
neutron subnet-create public 172.16.1.0/24
neutron router-gateway-set router1 public

Conclusion

Le cloud est devenu depuis quelques années le projet strategique dans beaucoup de DSI. OpenStack est un outil qui permet justement d’adresser ce besoin. C’est un projet qui est très actif, bien que encore jeune, et continue d’évoluer très rapidement grâce à son architecture modulaire. Son statut open source et le soutien d’acteurs majeurs du secteur IT permettent la publication de versions majeures tous les 6 mois et lui assurent une certaine pérennité. De quoi séduire tout ceux qui veulent se lancer dans les nuages.