Osones vous propose de vivre le Summit OpenStack 2016 d'Austin, Texas !

• Vous pourrez retrouver sur le blog le récit de la première journée de l'OpenStack Summit Austin.

• Enfin, nous avons également mis à jour nos supports de formation OpenStack et Docker. Ces supports sont bien entendu en français, et disponible sous licence Creative Commons BY-SA !

Keynotes

On démarre cette nouvelle journée à nouveau avec quelques keynotes. Ce matin, c'est Mark Collier, COO de la Fondation, qui était à la manœuvre.

Objet de l'intervention de Mark : l'infrastructure, ce qui tombe pas mal pour un OpenStack Summit :-)

Ce que souhaitent les utilisateurs, de plus en plus, c'est une plate-forme leur permettant de manipuler VM, conteneurs et bare metal de manière programmable. Cela ne signifie pas une API commune pour autant ! Mais une plate-forme unifiée fournissant les différentes API nécessaires. "OpenStack as an integration engine".

Puis Mark a présenté sa vision des interactions futures qu'OpenStack pourrait avoir avec d'autres composants en proposant une analogie avec la stack LAMP. La stack LAMP, Linux Apache MySQL/MariaDB PHP, est bien connue. Elle est intéressante car il s'agit de 4 projets (et communautés) différents, qui néanmoins fonctionnent très bien ensemble et sont utilisés de cette manière par de très nombreux utilisateurs. Quelle sera la stack LAMP du cloud ? Nul ne peut le dire à l'heure actuelle, mais lorsqu'il s'agit de conteneurs on ne peut s'empêcher de penser à Docker, Kubernetes, ...

Les conteneurs étaient bien le sujet de la matinée, puisque se sont succédé de nombreux intervenants pour présenter leur l'utilisation d'OpenStack et des conteneurs : Time Warner Cable, LivePerson, ou encore tcp cloud avec une sympathique démonstration d'IoT.

Un Googler ainsi que le CEO de CoreOS ont pris la parole pour une démonstration d'OpenStack tournant dans des conteneurs orchestrés par Kubernetes le tout hébergé sur des machines physiques du cloud provider Packet. Rien que ça !

OVH, dorénavant contributeur au projet et plus récemment donateur d'infrastructure pour la CI d'OpenStack, était également de la partie pour nous présenter son offre de cloud public.

Et enfin, quelques mots de la part du PTL d'OpenStackClient ont permis de rappeler l'importance du travail réalisé de ce côté là. Il s'agit d'un projet client, horizontal (concerne tout OpenStack), et qui a un impact majeur sur l'expérience utilisateur. OpenStackClient progresse rapidement (voyez par exemple l'introduction du support de certaines ressources réseau récemment), mais il y a toujours besoin de contributeurs sachant qu'il faut suivre les fonctionnalités continuellement ajoutées dans les API des différents projets OpenStack.

En aparté, Mark est revenu sur la diversité de ce Summit avec plus de 60 pays représentés ici à Austin.

Ce mardi marque par ailleurs le début du Design Summit (hors Ops), cette première journée étant consacrée aux sessions cross-project. Il s'agit des sessions impactant plusieurs projets (voire tous...) et nécessitant donc la présence de leurs représentants.

Design Summit

Ambassadors Community Report

Comme à chaque Summit, une session est consacrée au bilan et futurs objectifs des ambassadeurs OpenStack.

Quelques points à noter :

• Le nombre de membres depuis Vancouver augmente de 20 à 40% selon les continents.
• 86 user groups de part le monde
• +37% de membres en plus sur les 12 derniers mois
• De nouveaux groupes ont rejoint la liste des groupes officiels : Afrique du Sud, Pakistan, Allemagne (Munich, Frankfurt)

Qu'est-ce qu'un Groupe d'Utilisateurs officiel ? Il faut pour cela remplir 6 conditions :

• Accepter les règles ("Policies")
• Compléter le formulaire de contact de création du groupe
• Le groupe doit être organisé, coordonné, impartial et composé de plusieurs organisations
• Utiliser les canaux de communication respectant certaines règles
• Organiser des réunions régulières, avec un contenu adéquat (et par exemple validé par un ambassadeur)
• Avoir un ambassadeur qui mentor le groupe

Les règles en anglais avec plus de détails ici.

Le User Group de Paris, géré par l'association francophone des utilisateurs OpenStack, fait partie des quelques groupes officiels.

Les conférences

Nathan Reller - I'm having an OpenStack Party, and it's BYOK

Actuellement, OpenStack stocke ses clés et secrets lui-même. Pour des raisons de réglementations (PCI DSS, HIPAA, NIST SP 800-57), et/ou de protection contre le vol de données, il est souvent désirable de centraliser les secrets à un endroit unique. Les grandes organisations ont souvent des solutions déjà déployées, et il serait agréable que OpenStack sache les exploiter.

Le principe du BYOK est que le client, consommateur d'OpenStack, amène ses propres clés et secrets. Une solution serait de les importer dans OpenStack, mais les secrets se trouveraient dupliqués, augmentant ainsi la surface d'attaque d'un potentiel acteur malveillant. Une autre solution serait d'avoir OpenStack demander les secrets aux solutions déjà en place dans l'entreprise.

Le travail de design est en cours.

Comment contribuer à OpenStack lorsque l'on n'est ni un développeur, ni très bon en anglais

Rochelle Grober @ Huawei & Fred Li @ Huawei

L'approche commune n'est pas forcément suffisante :

• Lecture de la documentation officielle : au-delà de sa taille conséquente, on a l'impression de comprendre jusqu'à ce que l'on doive mettre les mains dans le cambouis;
• Vidéos sur YouTube;
• Mailing lists;
• IRC.

Il est nécessaire de s'impliquer socialement :

• Par la participation à des meetups, la rencontre de personnes déjà actives dans la communauté;
• Identifier les aspects complexes d'OpenStack, puis trouver les bons contacts dans la communauté pour obtenir de l'assistance;
• Communiquer sur IRC / les mailing lists / les blogs.

Les personnes ne sachant/pouvant pas développer peuvent quand même participer aux comités :

• Defcore Commitee
• Diversity Commitee
• User Committee : représente les utilisateurs d'OpenStack découpés par affinity groups (large deployment team, telcos, app ecosystem, ..) ou focus group (product workgroup, log group)

Ou encore aux developer projects :

• User experience (où l'on peut représenter les besoins d'un client afin qu'ils soient pris en compte lors des prises de décision)
• Traduction
• Documentation (même si contribuer à la doc n'est pas aisé, reporter un bug si quelque chose n'est pas clair est utile !)
• Training (améliorer les guides)
• Ambassador (lancer ou animer des meetups OpenStack)

Designing for High Performance Ceph at Scale / Comcast

Dans cette présentation, James Saint-Rossy et John Benton ont détaillé leurs points durs rencontrés lors de leurs déploiements. Le benchmarking a été longuement abordé :

• Les IOPS ne sont pas la seule métrique intéressante. Bencher avec des milliers de threads en parallèle peut augmenter les IOPS délivrés, mais si le temps nécessaire à chaque IOPS est de 3 secondes, alors le résultat est inacceptable
• Les outils fio (bloc) et cosbench (objet) ont été utilisés pour le benchmarking
• Il faut vérifier les mesures faites avec les benchs publics pour détecter les aberrations
• Il faut tester le scenario de scale-out. Une plate-forme de production avec 3 fois plus d'OSD ne se comportera pas 3 fois mieux que la plate-forme de tests : ils se sont rendu compte qu'en augmentant la taille du cluster, la performance par node baissait continuellement. Par défaut, la bibliothèque TCMalloc se comporte mal lorsque le cluster grandit. Une variable d'environnement doit être ajoutée et un gain jusqu'à 50% peut être observé. (nb: bug dans ubuntu 1404 qui ignore cette variable)
• Une attention doit être portée au bus QPI entre les sockets CPU qui peut se saturer (12.5Gg/s dans les deux sens) -> mapping/pinning NUMA de façon intelligente. Pinning des soft IRQ sur le bon noeud NUMA à faire également (pour les cartes réseau, HBA & nvme). On peut préférer des machines single socket pour éviter tous ces problèmes
• Les drivers fournis par les constructeurs ont montré pour Comcast une amélioration de 30% des performances par rapport à ceux de leur distribution.
• Comcast a rencontré des problèmes de paquets perdus sur des interfaces 40Gb à cause du flow control (paused frames)
• Les Jumbo frames sont à activer, particulièrement sur le réseau de réplication
• Il est utile également de scanner régulièrement les disques (logs, smart) pour détecter les défaillants qui dégradent drastiquement les performances

Kevin et Aurélien en vadrouille dans le boothcrawl.

Docker et Cinder

John Griffith, ancien PTL Cinder, présentait de nouveau la technologie Docker, confirmant ainsi l'importance de cette dernière dans l'écosystème OpenStack. Au fil des montées de version, Docker est devenu modulaire et extensible via des plugins, notamment pour la partie stockage et réseau. Nous avions présenté Kuryr lors du Summit de Tokyo. Le but de Kuryr est d'intégrer les conteneurs Docker (via un plugin réseau) avec le composant Neutron, afin de disposer des mêmes API et fonctionnalités, tout en évitant les overlays au dessus d'autres overlays (eg. VXLAN in VXLAN). Le point mis en avant est la stabilité de Neutron comparée à celle d'autres solutions.

Il existe actuellement de multiples plugins Docker qui permettent de fournir du stockage persistant pour les volumes Docker : - Flocker (ClusterHQ) : ZFS - Convoy (GlusterFS) : NFS and GlusterFS

Le postulat est que ces solutions sont parfois moins stables que la solution OpenStack, et encore une fois l'idée est de se servir de l'existant (Cinder) pour fournir/abstraire un service de volume à Docker.

Beaucoup de discussions ont pour sujet l'intégration avec des services externes, et notamment créer des couches d'abstractions afin d'intégrer des composants d'OpenStack à d'autres composants externes :

• Kuryr : Neutron et Docker
• Docker Cinder : Cinder et Docker
• Magnum : OpenStack API et Kubernetes

Ces approches sont discutables si l'on considère la stabilité (production grade ?) d'une partie des projets OpenStack. Il semble y avoir un engouement à ajouter des fonctionnalités et des intégrations au détriment de la stabilité.

Pour nous le problème est pris à l'envers : OpenStack tente de s'adapter à des technologies de plus haut niveau (fonctionnant sur un Cloud Provider). Si l'on prend l'exemple de Kubernetes et de Magnum, l'intégration du load balancer Neutron avec le load balancer Kubernetes est un sujet de discussion, mais est-ce vraiment la vocation d'OpenStack d'adresser tous les sujets et cas d'usage ? Toujours avec cet exemple, est-ce qu'OpenStack ne devrait pas se focaliser sur la finalisation d'un LBaaS v2, avec des API standardisées, production ready, pour ensuite laisser des solutions telles que Kubernetes ou Mesos s'intégrer avec les services d'OpenStack et non pas l'inverse ? La question reste ouverte.

OpenStack on top of Docker

La société Time Warner Cable nous a présenté son OpenStack de production fonctionnant dans des conteneurs Docker. En production depuis juillet 2015, le premier service intégré fut Designate, suivi par Heat et Nova. Des projets comme Neutron/OVS, de par leur compléxité, reste difficile à "dockeriser".

Leur projet, analogue au projet Kolla, vise à se servir des avantages des conteneurs Docker, à savoir facilité de distribution, intégration des dépendances, versionnement des images Docker. Debootstrap est utilisé pour construire les images de base qui contiennent toutes les dépendances et créer une image par service OpenStack.

Le déploiement des conteneurs Docker est assuré par puppet-docker. Ils travaillent avec le projet Puppet OpenStack pour ajouter des hooks pour la gestion des services.

De façon à s'affranchir des problématiques réseau liées à Docker, tous les conteneurs sont lancés avec le paramètre --host.

Enfin TWC a expliqué que le choix de ne pas partir avec Kolla avait été guidé par l'inadéquation entre leurs besoins et les features de Kolla, du moins au moment où le projet à été lancé. Bon joueur, TWC a reconnu bien volontiers que Kolla ayant considérablement évolué ouvre ainsi la possibilité d'une éventuelle migration.

Pets vs Cattle, quid des données ?

On ne le répétera jamais assez, le Cloud Computing est avant tout une évolution des usages. Il existe des différences fondamentales entre une application traditionnelle et une application cloud-native. Ces différences ne sont pas à chercher dans le rôle que remplit cette application mais dans la façon dont celle-ci est exécutée sur votre infrastructure. Le Cloud Computing, au contraire de la virtualisation traditionnelle, ne fournit pas de redondance pour ses VM. Cette redondance et cette résilience doivent être gérées au niveau de l'application. Enfin, pour qu'une application soit reconnue "cloud compliant", celle-ci doit pouvoir s'interconnecter avec les autres composants d'une infrastructure cloud : bases NoSQL, stockage objet, load-balancers. Elle doit aussi respecter certains principes de fonctionnement : modularité, stateless, etc.

Il n'est pas toujours possible - voire jamais - de redévelopper complètement une application. Dès lors, comment pouvons-nous gérer une application legacy, ainsi que ses données, et faciliter sa migration dans le cloud ? Les problématiques et solutions exposées ont été présentées par trois membres de l'Entreprise Working Group

Plusieurs stratégies sont avancées :

• Découper son application en modules (séparer la base de données du serveur applicatif et des données);
• Découper son application mais sans séparer toutes les parties. Tous les composants n'ont pas forcément besoin d'être migrés en même temps :
• Migrer son application dans le cloud sans y toucher.

Bien entendu, la dernière proposition revient à faire tourner des "pets" dans une infrastructure prévue pour des "cattle". Il existe actuellement des discussions sur la légitimité de cette pratique.

Concernant les deux premières, quelques bonnes pratiques sont avancées pour simplifier et/ou anticiper les problèmes :

• Continuer à utiliser les bases de données existantes;
• Migrer l'application sans les données est moins risqué;
• Prendre en compte les aspects de copie à chaud;
• Anticiper les down time;
• Concernant la scalabilité, le licensing des applicatifs doit être pris en compte.

Malheureusement des outils comme Trove sont encore trop jeunes pour servir de véritables solutions de DBaaS. Des outils permettant la migration vers le cloud restent encore à inventer et/ou à perfectionner pour avancer sereinement.

Facturation des utilisateurs d'un cloud OpenStack

Objectif Libre : Stéphane Albert, PTL CloudKitty
Nubeliu : Maximiliano Venesio (massimo@nubelio.com)

La facturation à l'usage est un des principaux attraits du Cloud, le fameux "pay-as-you-go" : je ne paie que pour les ressources que j'utilise pendant le temps où je les utilise. Aujourd'hui, la combinaison des technologies Ceilometer, Gnocchi et CloudKitty permet de mettre en œuvre un système de facturation des tenants d'un Cloud OpenStack. Ceilometer et Gnocchi (Time-series Database as a Service) collectent et stockent des séries temporelles de données d'usage. Cloudkitty y applique ensuite les calculs souhaités par l'opérateur du cloud. Il ne reste plus qu'à plaquer une grille tarifaire par dessus tout cela et le tour est joué ! Côté technique, notons que les concepteurs de Gnocchi ont prévu différents backends de stockage, dont Ceph qui s'est révélé le plus performant à l'issue d'une campagne de tests concurrentiels. Pendant ce temps, les développeurs de CloudKitty étendaient l'API de Gnocchi avec des fonctionnalités propres à CloudKitty, la finalisation de cette intégration étant prévue pour la release Newton. Côté références, Nubeliu, une société sud-américaine d'ingénierie spécialisée dans le déploiement de clouds privés motorisés par OpenStack, vient d'intégrer la solution Ceilometer-Gnocchi-CloudKitty dans le portail qu'elle propose à ses clients.

Les Tenants des clouds OpenStack : quels besoins en perspective ?

Ericsson - georgia.carstensen@ericsson.com, fred.karres@ericsson.com, abhijit.sunil@ericsson.com

Trois spécialistes OpenStack membres de la division Consulting de l'entreprise Ericsson nous rappellent que les utilisateurs d'IT traditionnelle viennent au cloud en espérant y trouver en premier lieu élasticité et agilité. Mais d'autres attentes non moins importantes viennent s'ajouter à celles-ci comme par exemple l'émancipation vis-à-vis des aspects bureaucratiques de l'IT traditionnelle, le besoin de communication entre les infrastructures nouvelles implantées dans un cloud OpenStack et les infrastructures legacy, ou bien encore un portail unique d'accueil pour les nouveaux utilisateurs "user friendly" et orienté self-service ("Please, give me a front door !").

Les consultants Ericsson ont également relevé le besoin d'un service de scalabilité prêt à l'emploi ainsi que la possibilité d'upgrader une plate-forme OpenStack "sur place" et sans aucune interruption de service...

Pour finir, les intervenants adressent deux messages forts à la communauté OpenStack :

• "Prenons soin de nos tenants ! Ce sont eux les Clients, ils payent pour les services que nous développons et déployons !".
• "Le succès des tenants dans leur projet de migration vers le Cloud fait le succès d'OpenStack !".

L'équipe de rédaction du blog en action.

• Retrouver le sommaire de ce dossier sur le récit de la première journée de l'OpenStack Summit Austin.
• Le troisième jour de l'OpenStack Summit, c'est par ici !

L'équipe Osones