Retour sur l'OpenStack Day france 2017

 Ce rassemblement est également une très bonne occasion pour discuter du projet, de son évolution et récupérer de bonnes idées, auprès de professionnels du domaine toujours prompts à partager leurs connaissances.

Voici un retour des différentes conférences auxquelles j’ai eu la chance d’assister.

Toward Fog/Edge deployments - Evaluating OpenStack WANwide with EnOS (INRIA)

Openstack n’a pas été conçu à l’origine pour fonctionner de manière étendue entre des datacenters très éloignés. La plupart des déploiements ont lieu soit au sein d’un seul et même datacenter, soit sur plusieurs datacenters en profitant d’une interconnexion de bonne qualité de type fibre noire (fibre dédiée, que l’entreprise cliente allume elle même) ou lien fibre géré par un opérateur tiers. La contrainte principale qui explique cette réticence à déployer OpenStack sur un large périmètre est évidemment la latence ; on pourrait également citer la baisse de fiabilité globale du réseau avec l’augmentation de la distance entre deux salles.

Il est ainsi aisé de comprendre pourquoi les déploiements exploitant des réseaux non exclusifs comme Internet sont presque introuvables (sans parler bien sûr des problématiques de sécurité). Cependant, le besoin de proximité avec les clients de services en ligne est bien présent. Cette proximité réduit les problématiques de capacité et de latence des accès réseau vis-à-vis du service proposé. Elle nécessite cependant une élasticité plus accrue des déploiements, l’objectif étant que la donnée soit présente au plus proche des clients à travers le monde, mais aussi que les traitements soient effectués en périphérie du réseau. Ce sont ces deux objectifs auxquels tentent de répondre respectivement les principes du Fog computing et de l’Edge computing.

Envisager le déploiement d’une infrastructure OpenStack à ce point répartie, au-dessus d’Internet, nécessite de savoir comment les différents composants réagiront dans un contexte à forte latence et à forte instabilité réseau. C’est à cette problématique que les ingénieurs de Inria, Ronan-Alexandre Cherrueau en tête lors de cette présentation, répondent en développant EnOS un outil en python permettant de déployer OpenStack dans un environnement local (le déploiement reposant en grande partie sur Kolla), puis de lancer des tests de performances en batterie, en simulant des latences et une fiabilité réseau amoindrie. Le logiciel embarque également tout le nécessaire pour obtenir facilement la métrologie nécessaire pour interpréter les résultats efficacement (grafana inside).

Essential tools of an OpenStack contributor (Red Hat)

En tant que contributeur à OpenStack (en particulier à TripleO et à Kolla), Martin André de RedHat est venu partager un ensemble de bonnes pratiques et d’outils pour participer au projet. Il a rappelé l’utilité des canaux IRC au sein de la communauté, dont les archives se trouvent sur http://eavesdrop.openstack.org/. S’il existe de nombreuses manières de contribuer au projet, cette présentation était logiquement plus destinée aux développeurs. On peut noter à cet effet quelques commandes git bien utiles :

• git commit --amend - reprend l’édition du dernier commit effectué en cas d’oubli
• git rebase --interactive - qui peut s’avérer bien pratique
• git cherry-pick -x - qui permet d’inscrire automatiquement dans le message de commit de quel commit proviennent les changements qui ont été appliqués
• git stash - permet d’effectuer des modifications sans risque d’impacter le code ou l’historique, les changements sont effectués dans un répertoire de travail à part et peuvent être annulés à tout moment
• git review - issu de la communauté OpenStack, permet de pousser des changements dans gerrit, l’outil de code review utilisé par la communauté, depuis git

Il a également été rappelé que tout le nécessaire pour mettre en place la complétion bash des commandes OpenStack côté client se trouvent sur le site officiel. L’utilisation d’autres outils est encouragée : Kolla pour le déploiement d’OpenStack en local ou dans un environnement réduit (avec en particulier le dev mode), l’utilisation de tox et de testr pour les tests unitaires, de flake8 pour vérifier sa syntaxe et son code style avant un git review, le dashboard gerrit du projet qui regorge d’informations, ou bien l’utilisation de gertty pour récupérer ces informations dans votre terminal. Il est également recommandé de consulter http://zuulv3.openstack.org/ qui indique l’état du pipeline de déploiement alimenté par gerrit. La communauté dispose également de codesearch, d’un ELK pour la centralisation et la consultation des logs et d’elastic-recheck. Elastic-recheck permet aux contributeurs de signaler simplement un bug, identifié depuis les logs, encouru lors de tests effectués par le système d’intégration continue de la communauté. Les raisons de la mise en place de cet outil sont parfaitement expliquées ici.

Demystifying Identity Federation (SUSE)

La mise en place de Keystone, le service de gestion des identités d’OpenStack, en mode fédération, permet aux utilisateurs d’accéder au service en utilisant des identifiants de services extérieurs (depuis un LDAP, un Active Directory ou un serveur RADIUS par exemple). Cette fonctionnalité, qui existe depuis longtemps mais reste difficile d’accès, permet également de fournir du SSO aux utilisateurs du provider de cloud ou du cloud privé, entre OpenStack et d’autres services en ligne. De plus, Keystone peut également être la source de vérité (Identity Provider) pour un autre service Keystone, ce qui a notamment une vraie valeur ajoutée dans le contexte d’un déploiement multi-datacenter comprenant plusieurs déploiements OpenStack indépendants (si l’on souhaite que l’authentification des utilisateurs reste unique). Colleen Murphy, core reviewer sur Keystone et développeuse sur le Cloud de Suse, a profité de l'événement pour expliquer les principes fondamentaux de Keystone et de la fédération. De nombreux schémas très efficaces et quelques démonstrations de configuration méritent d’être vus dans la vidéo à paraître sur le site de l’OpenStack day. En attendant d’avoir accès à la vidéo, les slides sont disponibles ici et il peut être intéressant de se frotter à la configuration d’une fédération de Keystone en s’équipant du plugin saml tracer sous Firefox (le protocole SAML 2.0 étant la base des mécanismes de fédération de Keystone).

OpenStack NFV: go-live! (Red Hat)

La Network Function Virtualization ou NFV consiste à virtualiser des éléments réseau, classiquement présents sous forme d’équipements physiques dédiés. Lorsque l’on ajoute à cette méthode, l’automatisation apportée par une solution IaaS, les possibilités sont décuplées. La plupart des opérateurs travaillant sur le sujet des Virtualized Network Functions, ou VNF, se tournent vers OpenStack, certainement du fait de sa modularité, de l’importance de sa communauté et des projets qui naissent dans le domaine. La quatrième session à laquelle j’ai eu droit fut un tour d’horizon du domaine par Frank Baudin de RedHat. Je vais tenter de résumer ici son propos. La première technologie présentée est Single Root Input Output virtualization ou SR-IOV. Cette spécification consiste à partitionner les ressources PCI Express, couramment pour permettre, pour une seule carte réseau physique, l’utilisation de multiples interfaces réseau virtuelles disposant d’une bande passante garantie et d’une plus grande souplesse en terme de configuration. Cette technologie est de plus en plus répandue sur les nouvelles gammes de serveurs proposées par les constructeurs et ouvre le champs des possibles en terme de fonctions réseau virtualisés à hautes performances.

Il est difficile de ne pas parler d’OpenVSwitch lorsque l’on parle de réseaux virtuels. Cette solution est aujourd’hui très répandue et est notamment utilisée avec Neutron, en mode DVR. Le seul reproche que l’on puisse lui faire, dans un contexte de haute densité et de très fort trafic, est justement d’être une solution entièrement logicielle. L’overhead CPU sur les serveurs hôtes peut donc être important si le cas d’usage nécessite le traitement d’un grand nombre de paquets par seconde. Une option présentée lors de cette présentation est l’implémentation d’ovs-dpdk. Comme son nom l’indique cette implémentation d’OpenVSwitch tire parti des performances permises par le framework DPDK (Data Plane Development Kit).

Pour rappel, le projet DPDK propose des librairies permettant d’obtenir des performances accrues au niveau du data plane sous FreeBSD ou Linux. Le data plane, dans un équipement réseau, correspond aux fonctions réseau chargées de transmettre “bêtement” les trames ou les paquets, en se référant strictement aux instructions transmises par le control plane, soit l’intelligence de l’équipement. Dans le cas d’un serveur Linux équipé de DPDK, l’accélération du data plane est permise par une réduction du nombre de cycles CPU nécessaires pour envoyer et recevoir des paquets (dans un équipement réseau taillé pour la performances, les fonctions de transmission des paquets sont assurées par des ASICs et ne sollicitent pas le CPU qui fait partie du control plane), ainsi que par la technique du fast-path, qui consiste à traiter le paquet exclusivement en userland pour éviter les allers-retours onéreux avec le noyau. Le couplage de ces deux technologies est donc très intéressant car il permet d’allier la souplesse et les fonctionnalités d’OpenVSwitch à la performance, exceptionnelle dans un contexte de virtualisation, apportée par DPDK.

Depuis OpenStack Queens il semble également possible de décharger OpenVSwitch par le matériel, pour des performances toujours plus importantes. Lors de cette présentation a également été cité FD.io, un projet concurrent de DPDK, qui semble mériter le détour.

Cold Storage with Swift (OVH)

Le stockage dans le cloud, comme beaucoup de choses, est payant. Alors pour permettre à leurs utilisateurs de stocker leurs données froides (dont l’accès n’est pas récurrent ou fréquent) à moindre coût, OVH a mis en place une offre de stockage froid, basée sur Swift. C’est Xavier Lucas, ingénieur DevOps chez OVH qui s’est chargé de présenter les spécificités de ce projet.

Le premier chantier fut d’implémenter l’erasure code sur des données poussées dans Swift. L’erasure coding permet de garantir la sécurité de la donnée, tout en limitant l’overhead de stockage induit, à un seuil respectable (on estime à environ 25% l’overhead moyen nécessaire à l’erasure coding) . Ceci est plus satisfaisant que les techniques basées sur la réplication pure et simple de la donnée, qui nécessitent de disposer au minimum de deux fois l’espace de stockage nécessaire pour la stocker.

Sur ce nouveau service un objet envoyé dans Swift est découpé en segments. Chaque segment est encodé avec la librairie python PyECLib, il en résulte plusieurs segments (voir le fonctionnement de l’Erasure code). Chaque serveur de stockage objet ajoute les segments qui lui parviennent dans une archive dédiée. Lorsque l’on souhaite récupérer les données stockées, celles ci sont décodées, toujours avec PyECLib, au niveau du serveur proxy, en amont des serveurs objet.

Un autre chantier intéressant fut le développement de Swift Virtual FileSystem. Comme son nom l’indique cet outil open source permet de simuler un système de fichiers au dessus de l’API Swift. Ceci permet aux utilisateurs une plus grande souplesse en ce qui concerne leur usage du service de stockage.

Du métal à OpenStack (Osones)

Dans une infrastructure OpenStack, le déploiement initial, la gestion des mises à jour et des extensions de l’architecture sont le nerf de la guerre. Les solutions permettant de gérer le déploiement logiciel des composants nécessaires se font de plus en plus nombreux et de plus en plus efficaces. On peut par exemple citer OpenStack-Ansible, Kolla, TripleO, et Fuel, seulement pour les outils communautaires (les distributions packagées d’OpenStack embarquant classiquement leur propre outil de déploiement, qu’il soit basé sur un l’un de ceux que nous avons cité, ou non). Cependant, ces outils ne permettent pas d’automatiser le provisionnement des serveurs physiques, ni de les répertorier dynamiquement, ce qui représente un manque conséquent si l’on veut gérer automatiquement l’intégralité du processus de déploiement.

Ces problématiques trouvent une réponse avec des outils comme Foreman, Cobbler ou MAAS (l’objet de cette présentation). Romain Guichard d’Osones a montré durant ce slot la pertinence de l’utilisation du couple OSA (OpenStack-Ansible) et MAAS (Metal As A Service). En effet, grâce à l’API de MAAS, écrire un script d’inventaire dynamique permettant de récupérer les données relatives aux serveurs physiques provisionnés est chose facile. OSA se basant intégralement sur Ansible, il suffit alors d’alimenter son inventaire en se basant sur ce script. L'interopérabilité des deux solutions semble parfaite.

Conclusion

Ce fut ma deuxième participation à l’OpenStack day. Cette édition fut riche de contenu et de découvertes, comme l’édition précédente. Je recommande à quiconque s’intéresse de près ou de loin à OpenStack ou plus globalement au domaine du cloud d’y participer. Merci aux organisateurs et aux intervenants et à l’année prochaine !