Summit OpenStack à Tokyo : jour 1

Publié le
par Adrien Cunin, Pierre Freund, Jean-François Taltavull, Romain Guichard, Kevin Lefevre
dans OpenStack
⭠ Retour à la liste des articles

Osones vous propose de vivre le Summit OpenStack 2015 de Tokyo ! Au programme de ce dossier spécial :

En avant Tokyo !

Deuxième OpenStack Summit en Asie, le troisième en dehors de l'Amérique du Nord, c'est parti pour Tokyo ! Au programme : célébration de la sortie récente de Liberty, des dizaines de conférences et surtout les sessions de préparation pour la prochaine version, Mitaka.

Osones est présent toute la semaine pour suivre et participer à cette semaine majeure dans l'écosystème OpenStack.

OpenStackSummit Tokyo

Cette première journée (oui, mardi) a débuté par la traditionnelle keynote de Jonathan Bryce, directeur exécutif de la fondation, juste après l'introduction effectuée par le leader du groupe d'utilisateurs Japonais. Ce summit à Tokyo est le plus gros des summits hors Amérique du Nord en terme de participants.

Deux annonces principales à retenir : * L'introduction d'une certification OpenStack en 2016, plus de détails sont à venir. * Le Project Navigator, interface permettant de parcourir des informations sur chacun des projets : notamment des données issues du dernier User Survey ainsi que les tags définis par la communauté pour décrire de manière factuelle et objective chacun des composants.

Les Superuser Awards ont cette fois-ci récompensé l'équipe de NTT et nous avons eu l'occasion d'écouter plusieurs utilisateurs significatifs d'OpenStack comme Yahoo! Japan qui fait reposer sur son infrastructure OpenStack des services aussi critiques que la communication de crise lors des séismes.

Côté développeurs, on a débuté ce summit avec les sujets nécessitant l'implication de tous les projets. Ainsi les sessions "cross-projects" de ce mardi se sont concentrées sur les tags, le support de Python 3 ou encore les problématiques des utilisateurs de service ainsi que du rôle admin au sein de Keystone.

L'Ops summit, qui offre aux opérateurs de cloud OpenStack un espace de discussion et l'opportunité de discuter directement avec les développeurs, a débuté en parallèle.

Découvrez nos quelques focus ci-dessous, en attendant la journée de demain !

Développer pour OpenStack sans "devstack" -> OSA (OpenStack with Ansible)

La conférence est dirigée par Miguel Grinberg (Rackspace, développeur Heat)

OpenStack with Ansible

Jusqu'à présent, un développeur OpenStack n'avait pas vraiment d'autre choix que d'installer devstack dans une VM. Inconvénient : avec devstack, on obtient un OpenStack complet et fonctionnel certes, mais monolithique et rigide. Les différents services ne sont pas cloisonnés et il est quasiment impossible de les gérer (configuration, mise à jour,...) indépendamment les uns des autres. Heureusement, il existe aujourd'hui une alternative très intéressante qui permet d'installer un OpenStack complet avec les différents services proprement rangés dans des conteneurs Linux (LXC). Le déploiement est orchestré par des playbooks Ansible tout prêts que l'on télécharge à la volée depuis github.com. Il suffit d'une commande "git clone", d'un peu de conf et de customisation sous "vi" et le tour est joué : chaque service OpenStack est installé dans son propre conteneur ! Magique et surtout bien plus souple pour le développeur. Il faut tout de même prévoir une VM équipée de 16 Go de RAM et 80 Go de stockage.

Et pour le moment, OSA se limite au déploiement des services "core". Démo en ligne

Tricircle

Le sujet de cette conférence était initialement "Multisite OpenStack - Deep Dive" et traitait donc en conséquence des problématiques rencontrées lors du déploiement d'une infrastructure OpenStack en multi-site.

Le postulat de base était que ce "multi-site" implique une hétérogénéité forte, les différences peuvent porter sur le stockage, le réseau, les versions des API utilisées, les performances etc. La solution présentée pour répondre à ce besoin est Tricircle. Plusieurs projets ont déjà abordé ce point sous différentes approches, depuis 2 ans de développement, Tricircle pose les bases suivantes :

  • Un réseau L2 et/ou L3 cross-site
  • Un seul dashboard
  • Un seul service d'identity
  • Une API OpenStack (ça paraissait assez évident ^^)
  • De préférence, une activité est-ouest importante

Le premier point peut être rapidement levé si on pense à traiter chaque problématique. Dans le cas d'un partage du L2, il faut penser à 2 choses, un IPAM afin de gérer correctement son plan d'adressage et une manière de partager les security groups entre les sites. Dans le cas d'un routeur, on doit s'assurer de la résilience de celui ci, il en faut donc un sur chaque site. Cela permet aussi de raccourcir les trajets lorsque deux instances d'un même site doivent dialoguer au travers d'un routeur situé sur un autre site. Ce point vient valider la partie "trafic est-ouest". Plusieurs routeurs effectuant la même tâche exige que ceux ci partagent la même IP (ou alors il faudrait attendre la fin des baux DHCP pour redonner les nouvelles default gateways) ainsi que la même MAC (ou alors il faudrait attendre que les enregistrements ARP expirent). Quant aux firewalls, ceux ci ne posent finalement pas beaucoup de problèmes puisqu'il suffit juste de synchroniser les règles de filtrage.

Le point le plus complexe est celui concernant l'utilisation d'un dashboard unique. Ce dashboard doit faire parti d'une infrastructure OpenStack et ainsi se comporter comme un master vis à vis des OpenStack déployés. Pour relier ces deux parties, un adaptateur agit comme un proxy, agrège les ressources des différentes sites OpenStack pour montrer à l'utilisateur sur un dashboard unique, l'ensemble des ressources disponibles. Ces ressources peuvent être présentées comme bon le semble à l'administrateur. Cet adaptateur permet aussi d'abstraire l'hétérogénéité potentielle des sites OpenStack en ne prenant en compte que les ressources pouvant etre consommées et non l'infrastructure sous-jacente.

Concernant le service d'identity, il faut se reposer sur des fonctions de SSO ou de fédération d'identités, deux choses désormais accessibles avec Keystone v3.

Il existe encore beaucoup de points nécessitant d'etre adressés, on pourra parler notamment des ID (de réseau notamment) qui sont forcément différents d'un site OpenStack à l'autre. On évoquera aussi la présence de certaines ressources (image, routeur, network etc) sur un site OpenStack mais pas sur un autre et de la capacité du cloud à provisionner rapidement dans un bunch complet ces "oublis" plutot que de les créer individuellement ; cette hétérogénéité amène à définir une instances par les services auxquelles elle devra/doit avoir accès.

Dans l'ensemble ces projets sont relativement intéressants car m^eme si les usecases sont finalement assez peu nombreux, ils montrent néanmoins la capacité d'OpenStack à aller loin. Monter un cloud unique soulève déjà à l'heure actuelle un nombre important d'interrogation et il est fort à parier qu'avec l'augmentation du nombre de services disponibles au sein du projet que la complexité de ceux comme Tricircle augmentent proportionnellement.

OpenStack Project Navigator - Comment mesurer la qualité d'un projet OpenStack ?

Lors de la première Keynote de ce summit, Jonathan Bryce a annoncé la création du project navigator, nouvelle rubrique du site openstack.org. Cette nouvelle section permet d'avoir une meilleur visibilité de l'état d'avancement des différents projets de la "Big tent" OpenStack. Seront indiqués entre autres le niveau de maturité et d'adoption de chaque projet par la communauté.

Mais comment gérer ces nouvelles métriques comme l'adoption ou la maturité ? Si l'adoption peut être mesurée de manière statistique via les enquêtes auprès des utilisateurs, selon quels critères objectifs peut-on mesurer une maturité technique ? Voici quelques métriques, ajoutées sous forme de tags aux projets, que l'on retrouvera pour chaque projet.

Jour 1 en réseau !

Évolution de Neutron : Un routeur distribué, du BGP et une intégration avec Docker

Des sessions autour de Neutron se sont succédées au cours de la journée. Le résumé ci-dessous est condensé, pour plus de détails sur les sessions Neutron, c'est ici sur un article dédié.

Dans un premier temps, il a été question de l'évolution du routeur distribué de Neutron qui pour le moment nécessite encore un nœud réseau pour certains types de trafic, notamment le DHCP et le source NAT des instances n'utilisant pas de floating IP.

L'utilisation d'un nœud dédié difficilement scalable peut créer un SPOF ainsi qu'affecter les performances réseau globales. Le but est de supprimer complètement le nœud réseau et donc de distribuer les services restant sur les nœuds compute.

La session rappelait les principes de fonctionnement de Neutron, avec et sans routeur distribué pour ensuite discuter des différentes options afin de supprimer totalement la nécessité d'un nœud réseau. Les solutions seront proposées lors des sessions de design summit cette semaine pour Mitaka M1.

La seconde session concernait l'implémentation du protocole BGP afin de faciliter les déploiements de Neutron, notamment le routage des floating IP, des sous-réseaux des tenants et l'utilisation de Neutron en tant que BGP Peer avec l'infrastructure réseau hors Cloud.

L'utilisation de BGP permettrait entre autre de:

  • Supprimer les associations statiques de floating IP à un réseaux 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.
  • Faciliter l'utilisation d'IPv6 ou les floatings IP n'ont plus vraiment de sens en utilisant la solution de routage directe ci-dessus.
  • Faciliter l'évolution du DVR.

Ce sont les points de départ du projet qui commenceront à partir de Mitaka. D'autres conjonctures ont été faites pour un futur plus lointain sur les cas utilisation potentiels de BGP:

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

Le dernier point abordé lors de la dernière session était l'unification de Neutron avec Docker. Depuis la version 1.9i, Docker a dissocié la libnetwork de docker core et propose un système de plugins réseau. C'est ici qu'intervient Kuryr, un projet OpenStack dans la "Big Tent". Kuryr réalise l'interface entre l'API Docker et celle de Neutron pour offrir aux conteneur 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éseau Neutron a eu lieu.

Le dernier 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. Kuryr réalise l'interface entre l'API Docker et celle de Neutron pour offrir aux conteneur les même possibilités que les instances Nova avec Neutron. Le projet est prometteur mais certains points sont laissés en suspend, notamment l'adressage 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.

Adrien Cunin
Pierre Freund
Jean-François Taltavull
Romain Guichard
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/ !

Association francophone des utilisateurs d'OpenStack'

Adrien Cunin Pierre Freund Jean-François Taltavull Romain Guichard Kevin Lefevre

⭠ Retour à la liste des articles

Découvrez les derniers articles d'alter way

Découvrez les technologies d'alter way