Neutron est le composant d’OpenStack prenant en charge le réseau. Il permet de réaliser des réseaux virtuels à l’image de ce que l’on pourrait faire physiquement avec des routeurs, switchs, firewalls, load-balancers et bien d’autres matériels de constructeurs et de technologies différentes. On parle de NaaS pour Networking as a Service. Neutron se repose sur des plugins pour gérer le fonctionnement avancé d’un réseau. Nous allons voir dans cet article quels sont les différents types de plugins qui composent Neutron.
Les différents types de plugin
Les différentes technologies réseaux gérées par Neutron sont portées par de nombreux plugins. Lorsque l’on désire apporter des fonctionnalités plus avancées, il faut déployer le plugin adéquat ou l’activer s’il fait partie des plugins disponibles de base dans l’installation (https://github.com/openstack/neutron/tree/master/neutron/plugins). Dans la liste des plugins intégrés au projet Neutron, se trouve des plugins portés par de grands constructeurs (Cisco, VMware, Microsoft …) qui participent activement aux développements dans Neuton. Ils permettent par exemple de provisionner des services réseaux sur des technologies propriétaires permettant de porter Openstack sur une infrastructure hétérogène.
Monolithique plugin
Un plugin monolithique (monolithic plugin ou encore core plugin) permet de fournir une technologie réseau spécifique dans son cloud avec des fonctions de base. Si l’on souhaite utiliser Open vSwitch sur son installation pour fournir une connectivité aux instances parce qu’on est dans un environnement Linux, on active le plugin openvswitch. Par contre si OpenStack utilise l’hyperviseur hyper V, c’est alors le plugin Neutron hyperv qu’on utilise pour l’aspect réseau.
Dans la configuration de neutron (/etc/neutron/neutron.conf), la ligne core_plugin permet de spécifier le plugin à charger lors du lancement du serveur neutron. Il est impossible de spécifier plusieurs plugins dans ce paramètre, ce qui signifie qu’un seul plugin est utilisable à la fois ! Ce n’est pas vraiment pratique dans le cas où l’installation d’Openstack a lieu dans un milieu hétérogène utilisant plusieurs technologies différentes. C’est pourquoi cette méthode n’est plus recommandée aujourd’hui. On préfère désormais utiliser le plugin ML2 en tant que plugin core.
Le plugin ML2
Le plugin ML2 (Modular Layer 2) est un framework introduit dans la version Havana d’Openstack permettant d’utiliser différentes technologies de couche 2 et de façon simultanée. ML2 devient le point d’entrée et a l’avantage de rendre le développement de nouveaux plugins plus simple grâce à son aspect modulaire et ses drivers.
Au niveau de la configuration, le paramètre core_plugin du fichier neutron.conf est défini en neutron.plugins.ml2.plugin.Ml2Plugin. L’activation de nouveaux plugins se passe dans le fichier de configuration de ML2.
La plupart des anciens plugins monolithiques a été portée sur ML2 via les mechanisms drivers. Par exemple les plugins monolithiques OpenvSwitch et Linuxbridge sont devenus obsolètes depuis la version Icehouse. Ils seront supprimés dans une version future d’Openstack pour laisser place aux drivers ML2 correspondants.
Service plugin
Un service plugin permet d’utiliser des technologies à partir du niveau 3. Après avoir choisi le ou les mechanisms drivers ML2 avec lesquels on souhaite travailler, il faut pouvoir fournir des fonctions de plus haut niveau comme le routage, un service DHCP, du filtrage des flux à l’aide d’un pare-feu, de la répartition de trafic entre plusieurs serveurs (load balancer), de créer des VPNs, etc… Ceci passe par l’intermédiaire de services plugin. Un service plugin peut proposer plusieurs drivers pour s’adapter à différents environnements.
Le service plugin L3_router implémente les fonctionnalités basiques de routage depuis Havana. Auparavant ces fonctions étaient assurées par les plugins core comme OpenvSwitch ou Linuxbridge. Il existe une multitude de services plugin existants.
La configuration passe par le paramètre service_plugins du fichier de configuration Neutron. Ce paramètre définit le type de plugin à mettre en œuvre correspondant à un service (load balancer, vpn, etc…). Ensuite il faut définir le driver à utiliser via le paramètre service_provider car chaque constructeur peut avoir sa propre implémentation. Par exemple pour mettre en place le service de load balancer, il y a plusieurs implémentations disponibles comme haproxy, netscaler ou radware.
Les extensions d’API sont indispensables dans un service plugin pour étendre les possibilités de l’API Neutron. Ils permettent de rendre disponibles les fonctionnalités des plugins chargés par Neutron. Un plugin peut se baser sur plusieurs extensions. Ils sont situées dans le répertoire extensions de Neutron. C’est dans le fichier de l’extension en question que sont définis les attributs de l’API qui peuvent être utilisés lors d’un appel.
La prise en charge d’une extension par un plugin est définie dans la classe principale du plugin en question. Il faut ajouter l’alias de l’extension dans la liste supported_extension_aliases.