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

• OpenStack Summit Tokyo 2015 Jour 1
• OpenStack Summit Tokyo 2015 Jour 1 : Focus sur Neutron
• OpenStack Project Navigator - Comment mesurer la qualité d'un projet OpenStack ?
• OpenStack Summit Tokyo 2015 Jour 2
• OpenStack Summit Tokyo 2015 Jour 2 : Le projet Kuryr
• OpenStack Summit Tokyo 2015 Jour 3

Deuxième journée de summit, deuxième série de keynotes. Cette fois-ci avec Mark Collier, COO de la fondation, en chef d'orchestre. Ce début de matinée a été l'occasion de faire un petit focus sur le réseau : Neutron a été le projet le plus actif dans Liberty. Ainsi, Kyle Mestery, ex-PTL de Neutron, a pris la parole pour présenter le projet Kuryr qui vise à rapprocher les mondes Neutron et Docker. Encore un peu de travail sur la démonstration en direct... (ce sont les risques du métier), mais à suivre en tout cas !

Aujourd'hui, c'est la journée Heat

J'aime bien Heat, donc je vais aux sessions. Et comme je vais aux sessions, j'apprends plein de choses. Le projet Heat a le mérite de rester à taille humaine, avec une équipe restée stable depuis plusieurs années. Difficile en revanche de résumer dans un article ce que l'on peut comprendre lorsque l'on se rend à une session design et qu'on ne comprend pas plus de la moitié des informations (c'est déjà beaucoup). Il est possible de se rendre compte des points de blocage, qui a priori peuvent paraître minimes pour un utilisateur, mais qui soulèvent beaucoup de problématiques lorsque l'on ouvre le capot.

La matinée s'est portée sur la documentation, afin de remettre au clair ce qui doit être dans le wiki ou la documentation. Il a été évoqué l'idée de fournir aux utilisateurs des "snippets" utilisables afin qu'ils puissent rapidement prendre en main une nouvelle ressource. La création de templates d'applications complètes fournies dans la documentation a également été évoquée.
Certaines parties de la documentation grandissent de façon exponentielle. Ce genre de session permet de mettre tout le monde d'accord sur un nouveau découpage éventuel de certaines pages de la documentation, en l'occurrence celle qui liste les ressources Heat.

L'après-midi s'est portée sur le retour Dev ↔ Ops, avec quelques points très bloquants évoqués, comme l'abandon de ressource en cas de blocage. On peut prendre pour exemple un sous-réseau démarré par Heat, mais qu'une instance externe utilise. La majorité de la conf s'est portée sur le bug #1466694.

Comment réaliser un « OpenStack Day »

Une petite session de 15 minutes sur l'organisation d'un événement local de type « OpenStack Day ».

En vrac, voici quelques retours des organisateurs :

• Il faut être très solide financièrement. Beaucoup d'argent à avancer pour payer les fournisseurs, avant de recevoir l'argent des sponsors ou des participants.
• Il est préférable d'avoir une personne organisatrice dédiée et si possible possédant des notions de droit.
• Il faut diversifier un maximum les sponsors et les medias, qui peuvent être de tailles différentes, locaux ou internationaux et de différentes branches. Les offres de type Bronze/Silver/Platinium fonctionnent très bien, les sponsors sont habitués à ce genre d'offres. L'offre Platinium peut par exemple permettre de proposer des talks prioritaires.
• Démarrer par une keynote est une bonne pratique, avec de préférence un invité spécial (rare). Les speakers rares ont souvent un emploi du temps chargé et il faudra prévoir bien à l'avance ces conférences.
• Il faut alterner entre keynotes, workshops, sessions débutants et sessions avancées. La plupart du temps, les petites salles sont pleines et les grosses sales sont vides et il est très difficile de prévoir l'affluence. De plus, il faut prévoir environ 10 % de conférences annulées et préparer les remplaçants en conséquence.
• Chose très importante, la plupart des conférenciers n'auront pas d'adaptateur pour se connecter à l'écran. C'est un fait.
• Il est important de trouver un partenaire media, qui fera le plan media 2 à 4 semaines avant l'événement. Il faut aussi prévoir les « goodies » et cadeaux.
• Enfin, il ne faut pas hésiter à inviter gratuitement les étudiants et professeurs, en prenant contact avec les universités et les écoles.

L'organisation des groupes d'utilisateurs locaux

Suite à cette session concernant l'organisation des OpenStack Days, une autre session a permis d'élargir la discussion sur le sujet des groupes d'utilisateurs locaux.

Les "user groups" font de la communauté OpenStack ce qu'elle est : ils organisent meetups et autres workshops dans des dizaines de pays à travers le monde. C'est pourquoi la fondation a lancé le portail Groups afin de coordonner les initiatives. Plus récemment, la notion de user group officiel a été introduite, il suffit de remplir quelques conditions. Les user groups officiels devraient alors être reconnus comme tel sur le portail, et bénéficier d'avantages comme des goodies et autres accessoires pour les événements locaux.

De la même manière, les OpenStack days doivent suivre un certain nombre de règles pour s'appeler ainsi et donc utiliser la marque.

Plusieurs sujets annexes ont été abordés puisque la salle était remplie d'organisateurs de user groups ainsi que d'ambassadeurs. On peut citer le besoin de speakers pour les événements locaux : sur ce sujet, la fondation répond qu'elle a commencé depuis plusieurs summits à collecter des informations sur les speakers prêts à parler également lors d'événements locaux. Reste à exploiter ces données !

Encore un peu de réseau

Haute disponibilité des services Neutron

Aujourd'hui j'ai assisté à une session plus classique sur la HA dans Neutron et notamment celle utilisée dans les solution packagées telles que RDO ou Suse Cloud.

Ces solutions sont souvent en décalage avec les releases upstream. Dans le cas de RDO et Suse Cloud, il s'agit de Juno.

Dans un premier temps, les speakers ont discuté de la haute disponibilité des API fournies par le service Neutron server.

Rien de bien nouveau, les API sont stateless et il est possible de réaliser un load balancing actif/actif facilement scalable, par exemple avec HAProxy. Lors d'une panne d'un nœud API, le trafic est rerouté vers un nœud fonctionnel par HAProxy.

Pour assurer la redondance d'HAProxy, il est possible d'utiliser des solutions basées sur Keepalived avec par exemple pacemaker et corosync.

Si un nœud HAproxy tombe, pacemaker bascule la VIP vers un nœud fonctionnel.

C'est l'implémentation classique de la HA pour les API Neutron.

En ce qui concerne la haute disponibilité des services Neutron assurés par l3-agent, le protocole DHCP supporte la HA "by design" grace au broadcast. Une course s'instaure entre les services DHCP serveur, et le service gagnant met à jour le bail.

La suite est valable dans le cas de l'utilisation de noeuds réseaux dédiés, sans routeur distribué.

Pour les vRouters :

• Avant Juno :
  • Le basculement se fait par une tâche de la crontab qui vérifie l'état des routeurs toutes les 60 secondes et les replanifie si besoin. Cette méthode peut être très lente et n'est clairement pas scalable.
• Depuis Kilo :
  • Il y a une HA en mode actif/passif par défaut se basant sur Keepalived et VRRP.

Dans le cas de l'utilisation de DVR (Distributed Virtual Router), la majorité des services sont distribués et en haute disponibilité, à l'exception du service DHCP et du source NAT comme mentionné dans [l'article d'hier].

Un nouveau projet : Gluon

Pour la seconde session de la journée, j'ai tenté l'aventure avec quelques conférences exotiques traitant de nouvelles problématiques.

Gluon est un nouveau projet qui a pour objectif de servir d'interface entre le service compute (Nova) et le service network (Neutron).

Le postulat de départ est le suivant : Neutron suit un design précis et offre uniquement des ports de niveau 2. Le workflow par défaut est :

• création d'un réseau
• création d'un sous-réseau
• création d'un port dans un sous-réseau

Il est cependant possible de nécessiter des services de niveau 3, mais ils sont implémentés par des tierces parties. Par exemple le L3VPN et le L3 avec Calico.

Nova a une forte intégration avec Neutron et il ne semble aujourd'hui pas possible de supprimer complètement Neutron. D'où le concept d'interface entre Nova et Neutron. De plus Neutron fonctionne très bien dans son domaine d'application : provisionner des niveaux 2.

L'objectif de Gluon est de permettre à Nova d'utiliser différents backends (Neutron ou un autre backend fournissant du niveau 3 ou du service chaining par exemple).

Il est même possible d'avoir des backends en dehors du domaine Cloud, par exemple de terminer un tunnel VPN ou un MPLS sur un port du Cloud. Une instance peut potentiellement avoir plusieurs ports dans des backends différents.

Un des avantages en terme d'intégration est la segmentation des fonctionnalités de Neutron. Un projet comme Gluon permettrait à Neutron de continuer sur sa roadmap sans subir des "changes" ou des "features requests" qui ne sont pas en accord avec sa philosophie. Ces "changes" pourraient être implémentés sous forme de backend indépendamment de Neutron.

Les inconvénients se trouvent essentiellement dans l'effort de développement à fournir, par exemple:

• Nova s'attend à ce qu'un port dispose forcément d'une IP, ce qui peut ne pas être le cas selon les backends.
• Certains composants d'OpenStack s'attendent également à ce qu'un port ait forcément une IP associée même si ce port n'est attaché à aucune instance.

Projet Kuryr

Kuryr est un projet Big Tent ayant pour but de connecter, d'un point de vue réseau, les conteneurs Docker aux instances OpenStack. Kuryr se présente comme un plugin réseau de Docker se connectant à Neutron afin d'étendre ses fonctions aux conteneurs. Kuryr est développé à +50% par Midokura et l'ensemble des contributeurs rassemble plus d'une dizaine d'entreprises. Ses développeurs travaillent en collaboration avec les équipes de Neutron, Magnum et Kolla.

Le principal problème soulevé est qu'à l'heure actuelle, le modèle "classique" mis en place consiste à monter des overlays networks par dessus des overlay networks (un pour Neutron, un pour Docker). Cette double encapsulation induit de la complexité, une perte de performances, des problèmes de troubleshooting et une incapacité à respecter un SLA. La maturité de Neutron a fait mûrir l'idée qu'il ne fallait pas réinventer la roue et utiliser l'API Neutron comme moyen unique pour gérer ses réseaux ainsi que tirer parti des services offerts par Neutron comme le LBaaS, le FWaaS et le VPNaaS.

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/ !**