En direct de Barcelone jour 1 !

 

Que retenir du jour 1 de l’OpenStack Summit de Barcelone ?

Prenez un café et 5 minutes pour vous mettre à jour des faits marquants de la journée retenus par l’équipe d’Objectif Libre présente à Barcelone:
faites une pause OpenStack !TasseVintage

 

Au menu aujourd’hui :

 

Keynotes

« Bom dia ! » – introduction par Mark Collier

Pour l’ouverture officielle du Summit, la foule se presse dans l’immense auditorium du Forùm au son de “we go to Barcelona”. L’ambiance est plantée pour la semaine.

 

 

Mark Collier de la Fondation OpenStack est aux commandes de cette 1ère Keynote et présente des informations générales et quelques statistiques :newlogo

  • 4 nouveaux Sponsors « Gold » : China Mobile, 99Cloud, T-System and citynetwork
  • Le nouveau logo OpenStack, résolument Flat Design
  • 2 phrases à retenir:
    • “A versatile, reliable platform for the WORK THAT MATTERS”
    • “The World runs on OpenStack”
  • Et quelques chiffres :
    • Si des entreprises de toute taille s’appuient sur OpenStack, 75% d’entre elles font tourner des clouds de +1000 coeurs
    • Top 4 des usages d’OpenStack :Infrastructures IT, Fonctions de virtualisation NFV, Stockage et applications business. Le fait principal reste cependant la grande diversité des usages d’OpenStack.
    • L’adoption des conteneurs se fait 3 fois plus vite que s’est faite l’adoption d’OpenStack.
  • Mark rappelle également l’intérêt et l’importance accordée au modèle Open Source d’OpenStack : ouverture du code, de la communauté, du développement et de la conception du logiciel.

 

 

Enfin, il donne un aperçu des nouvelles fonctionnalités Newton, 14ème release OpenStack:

  • Multi-tenant networking
  • Passthrough Vlans
  • Mutable configurations
  • Vlan-aware VMs

Le maître-mot semble être “network on demand” : une idée qui semble simple… autour de laquelle les 2000 contributeurs annoncés de Neutron vont pouvoir travailler.

 

Cas d’usage #1 – Banco Santander, BigData

Les choix de départ de la Banco Santander pour construire leur cloud sont les suivants : Automatisation, Open Source, approche hybride et analyse big data en temps réel.

Ils utilisent OpenStack comme un enabler technologique, et ont fait le cheminement suivant :

  • Etape 1 : comprendre !
  • Etape 2 : développer des capacités de Self Service pour faciliter le déploiement des Vms
  • Etape 3 : migrer les worksloads spécifiques.

Ils ont déployé leur OpenStack sur 8 régions et utilisent Cloudera pour le Big Data (tout de même 1,8Pb de données).

L’intervention se termine en soulignant l’importance de l’Open Source dans leur stratégie pour rester sur une politique d’innovation primordiale.

Conclusion : OpenStack est un atout pour faire face aux challenges rencontrés dans le secteur bancaire.

 

Cas d’usage #2 : Sky UK, Media Broadcasting

Les raisons de leur choix d’OpenStack : équilibre coût / rapidité de déploiement, flexibilité, limitation du shadow IT et gestion multi-organisations.

Quelques chiffres assez impressionnants sur leur infrastructure :

  • 2 datacenters
  • 4 availability zones
  • +80 tenants (développement, tests et production)
  • des centaines d’applications hébergées
  • 7000 noeuds
  • 400 utilisateurs internes
  • 400 TB de stockage sur Ceph – dont les set top box de tous les utilisateurs de SkyQ !

En terme d’usages, les applications hébergées sont encore très larges : monitoring d’entreprise, Video streaming analyse, OTT NFT (??), analyse des données voix, développement d’outils, confluence / jira, Nexus, ….

Sky envisage maintenant la migration Kilo -> Liberty -> Mitaka ainsi que le passage de nouvelles applications sur OpenStack (transcodage Video, plus de Big Data, …) ainsi que le déploiement de nouveaux modules : Ironic, Magnum, Barbican et Sahara.

 

Cas d’usage #3 : NFV – démo par la Foundation et OPNFV

La démonstration commence par donner quelques repères sur la sacro-sainte règle des « 5-9 » des opérateurs : la disponibilité souhaitée de 99.999% correspond à moins de 5,5 minutes d’indisponibilité par an – soit moins de temps qu’il n’en faut pour terminer un café.

La criticité étant établie, la démo peut commencer pour montrer comment on peut construire un réseau respectant cette disponibilité à partir d’OpenStack.

Les composants clé utilisés : Nova, AODH, Congress et Vitrage.

Démonstration : un appel est passé en live… bonne qualité, pas de latence. Et l’appel est volontairement coupé – et logiquement, la conversation aussi.

Paramétrage fait sur OpenStack pour permettre la prise en charge sans coupure de ce type de panne, la démonstration est relancée. Nouvel appel, nouvelle conservation, nouvelle coupure volontaire du câble… et cette fois-ci, sans effet sur la conversation qui peut continuer.

Belle démonstration qui montre comment OpenStack s’adresse aux opérateurs pour supporter la qualité de service nécessaire aux applications synchrones critiques.

 

Super User Award

Les critères cette année étaient les suivants : innovation, maturité, niveau de contribution auprès de la communauté et impact business.

Les finalistes en quelques chiffres :

  • 151 utilisateurs actifs, 4k recherches, 5 achats par seconde, … : mercado libre
  • 513 patches, 2381 lignes de code,s, 9 bueprints, ont raccourci leur cycle de release de 1,5 ans à 1 mois : China Mobile
  • 100k instances en prods, 530k instances générées chaque mois : OVH
  • 17760 CPUs, 1756 bare metal serveurs, 1PB of Swift Storage : Internap

Et c‘est China Mobile qui remporte le Super User Award : nos félicitations au gagnant et aux 12 concurrents.

Pour en savoir plus : http://superuser.openstack.org/awards

 

Cas d’usage #4 : Recherche scientifique

Tim Bell du CERN vient donner quelques chiffres pour montrer la progression de leur OpenStack en version 2016, 2 ans après Paris
Et les chiffres donnent toujours autant le vertige :

  • 1 billion de collisions par seconde ! Avec le besoin de les analyser toutes.
  • 160PB de données stockées au CERN.
  • 190K cores
  • 90% des computes du CERN sont virtualisé
  • +5000 VMs ont migré depuis leur ancienne infrastructure

 

C’est ensuite le Dr Bolton de l’univertité de Cambridge qui présente le projet SKA, reposant sur OpenStack, dans une intervention qui nous ramène au Big Bang !

Un projet mené avec des contraintes de coûts, d’utilisation d’énergie très fortes et un contexte très complexe qui poussent à l’efficacité.

 

Les chiffres de calculs ne sont pas, eux, à l’économie :

  • On parle bien de 0,5 Exaflots de compute
  • 400Gbytes/s à calculter
  • 4000 million de tâches
  • 1.3 ZettaBytes de production de données intermédiaires
  • 1 Petabyte par jour de données scientifiques produites

 

Le Dr Calleta de Cambridge University clôt la matinée en expliquant le choix d’OpenStack pour l’application au domaine Santé.

Les enjeux sont plus rationnels : accessibilité, flexibilité et sécurité.

Et OpenStack apporte ici de la simplicité d’utilisation et de partage, en réduisant le “Time to Science” et en augmentant la capacité d’innovation.

 

Conférences et ateliers

The Path to Becoming an AUC (Active User Contributor)

Par Maish Saidel-Keesing,Cisco et Shamail Tahir d’IBM
                                

Bonne nouvelle pour les membres actifs non techniques de la communauté !                                

Cette année, un nouveau comité fait son apparition dans la communauté OpenStack, le “Active User Committee”.
Il a été créé pour aider (et non remplacer) l’actuel comité d’utilisateurs (UC). 
A l’instar du comité technique qui fait la distinction entre les contributeurs techniques(ATC), et les membres “core” des projets (APC), le comité d’utilisateurs aura désormais une désignation supplémentaire pour ses membres les plus actifs.
L’objectif de ce nouveau comité est de permettre aux utilisateurs les plus actifs dans la communauté OpenStack d’être mieux reconnus. Ces derniers, sans forcément écrire de code, peuvent être très engagés dans OpenStack mais n’avaient pas de désignation spécifique. C’est maintenant chose faite.  
Pour devenir “Active User Commitee”, il faut avoir à un des rôles suivants :
  • Organisateur d’un groupe officiels d’utilisateurs OpenStack        
  • Membre actif d’un working groupe        
  • Modérateur d’un meetup Ops        
  • Contributeur de Superuser        
  • Modérateur sur AskOpenStack
Ce comité étant relativement récent, les avantages d’en faire partie sont encore discutables mais cela pourrait être un pass offert au prochain OpenStack Summit.
Côté statistiques, il y a pour le moment 255 personnes dans ce comité, et le tiers d’entre elles étant contributeurs techniques sur les projets officiels.
Si vous voyez le logo “AUC” sur un badge, vous savez désormais ce que c’est.

Simplify day 2 Operations

Par RackSpace

Craton est le projet de fleet management made in Rackspace.
Les challenges de Craton sont nombreux :
  • Faciliter l’inventaire et la gestion des métadonnées
  • Rendre une infrastructure auto-réparante
  • Fournir des méthodes simples et reproductibles pour dérouler les tâche courantes d’administration
  • Garder la trace de tous les actions qui affectent l’infrastructure
Codé en Python 3, le projet bénéficie de l’expérience de Rackspace sur la gestion d’un cloud d’envergure : (autour de 10000 nodes).
Le fonctionnement de la solution Craton s’articule atour de quatre axes :
  • L’application automatique des patterns de remédiation (par exemple le redémarrage automatique d’un service en défaut)
  • L’automatisation des tâches courantes d’opération, comme la montée de version d’un serveur (évacuation, mise à jour)
  • La présentation synthétique des événements d’infrastructure (par exemple : host down) et des actions de remédiation
  • La fourniture d’un service de base de données hiérarchique accessible via une API REST
L’API REST permet de définir des variables d’environnements sur-chargeables à différents niveaux de la hiérarchie du cloud : Région, Cell, Host.
Craton n’est pas encore un projet big tent mais il y a fort à parier que le projet saura séduire de nombreux cloud-providers dans le futur.

Migration de nova-network vers neutron au CERN

Ricardo Rocha du CERN nous fait part de son retour d’expérience sur la migration du plugin nova-network vers neutron.
Pour rappel, le CERN gère une plateforme OpenStack depuis juillet 2013 pour leurs besoins de recherche (accélérateur de particules). 
Aujourd’hui, la plateforme du CERN en quelques chiffres :
  • 2 datacenters
  • 190 000 coeurs
  • 4 millions de VMs créées
  • 300 millions d’instances créées par heure
  • 2400 utilisateurs
L’ensemble des services du CERN sont isolées via les adresses IP,  nova-network suffit dans leurs cas d’usage.
Avec nova-network, il n’y a pas de réseaux d’overlay, les instances sont directement accessibles (pas d’IP privées et de floatings IPs).
Nova-network sera déprécié et amené à disparaître au profit de neutron.
L’enjeu est de migrer sur Neutron en imitant le fonctionnement de nova-network (pas de routeur, pas de floating ips, firewalls…). 
Pour cela, le CERN va utiliser le fonctionnement flat du ML2 plugin (ce plugin fait l’interfaçage entre les API de Neutron et le plugin réseau implémenté) et choisir LinuxBridge comme plugin réseau.
Il n’existe pas de procédure officielle pour migrer de nova-network vers neutron. Cependant, il y a eu quelques retours d’expériences (ebay, nectar).
Leur plateforme OpenStack implémente les cells. C’est une fonctionnalité de nova qui permet de segmenter les contrôleurs et les computes nodes. L’idée est de faciliter la scalabilité de la plateforme.
La migration a donc été réalisée au niveau de chaque cellule.
Les actions suivantes on été effectuées:
  • par cellule : nova a été configuré pour utiliser neutron
  • par hyperviseur : reconfigurer chaque agent nova-compute et déployer LinuxBridge
  • pour chaque VM : il a fallu créer un port neutron
Bref, un travail de longue haleine. Neutron a été déployé pour la première fois en octobre 2015 et depuis juin 2016, c’est le plugin par défaut même s’il reste encore nova-network dans certaines cellules (cells).
Durant cette migration, il y a eu un impact sur certaines VM existantes, quelques difficultés aussi sur l’agent DHCP et les métadonnées (qui permet de faire le lien antre une IP et une machine).
Pour le futur, le CERN réfléchit à utiliser Neutron plus traditionnellement (floating ips, routeurs virtuels…) ou même implémenter une solution SDN.

Monasca, nouveautés et annonces 

Par HPE
L’agilité du cloud permet de répondre aux problèmes actuels de manières rapides et sécurisées.
En effet, l’utilisation de techniques comme le blue-green sont rendues possible grâce à l’élasticité des plateformes de cloud Openstack. Nonobstant ces qualités, la question du monitoring de ces environnements reste ouverte : comment collecter efficacement les métriques des machines virtuelles tournant sur le cloud ? quelle valeur accorder aux métriques d’une instance étant restée allumée 45min par rapport à une instance allumée depuis 200 jours ? etc.
Ce sont ces questions qu’essaye d’adresser Monasca, projet de la Big Tent. Nous ne débattrons pas ici des choix techniques faits par le projet mais parlerons simplement des améliorations / nouveautés et annonces faites aujourd’hui à l’OpenStack Summit de Barcelone.
Quelques chiffres pour la version Newton :
  • 28 compagnies ont contribué au projet avec en tête HPE.
  • + de 500 commits
  • + de 90 contributeurs
Les 3 principaux contributeurs travaillent chez HPE : on comprend que le projet est majoritairement porté par HPE.
Du côté des nouveautés de cette version, on notera :
  • une fonction group-by pour augmenter les performances et éviter d’avoir plusieurs requêtes unitaires à faire
  • une fonction count pour pouvoir extraire le résumé de certaines alarmes
  • l’ajout d’un système de plugins pour les notifications (slack, hipchat et jira)
  • un plugin datasource pour grafana
  • la création de monasca-transform-engine pour la consolidation des données
  • la création de monasca-analytics
  • développement de l’api pour la gestion des logs
Les annonces pour la suite : essentiellement la gestion de nouveaux backends pour le stockage des données (cassandra, elasticsearch, etc.)
Enfin, nous noterons l’utilisation de zanata (projet open source pour la gestion des traductions) qui permet une traduction simple et efficace de Monasca.
Pour conclure: Monasca est un projet vivant, qui continue son évolution et maintient son rythme de développement.
Des problèmes de performances ont été corrigés et de nouvelles features sont apparues. L’ajout de la gestion des logs évitera la mise en place d’une énième brique pour manipuler ces derniers. Cela rejoint la mouvance actuelle de faire de l’alerting à partir des logs applicatifs et non plus à partir des limites physiques des machines (virtuelles ou non) devenues trop éphémères pour un alerting efficace.

Open Container : Quoi de neuf coté conteneurs ?

par Daniel Krook (IBM), Jeffrey Borek (IBM), Sarah Novotny (Google)

Depuis ces 6 dernières années d’existence, OpenStack évolue et se tourne de plus en plus vers les solutions de conteneurs applicatifs. Magnum, Nova, Heat, Murano, Kuryr ou encore Kolla, chacun de ces projets de la Big Tent travaille sur le sujet des conteneurs.

Pourquoi utiliser des conteneurs en remplacement des machines virtuelles ?
Il faut tout d’abord comprendre que les conteneurs et les machines virtuelles ne fonctionnent pas sur le même modèle:  ce serait comme comparer l’achat d’une maison (VM) à la location d’un appartement (Conteneur).
Alors que les machines virtuelles possèdent leur propre kernel / OS / matériel émulé, les conteneurs ont une base identique (kernel, stockage,…etc…). Ce mécanisme permet aux conteneurs de se lancer plus rapidement qu’une machine virtuelle.
En 16 ans, les conteneurs ont fortement évolué, profitant de l’apport d’un grand nombre de contributions :
  • Jails (1999, FreeBSD)
  • VServer (2001, GNU/Linux)
  • Zones (2004, Solaris)
  • cgroups (2006, Google)
  • namespaces (2008, RedHat)
  • LXC (2008, IBM)
  • Docker (2013, Docker)
Deux fondations Linux se dédient à l’évolution des technologies de conteneurs : OCI et CNCF. Leur principale mission est de participer activement à la gouvernance, l’incubation et l’évolution des technologies de conteneurs actuelles.
OCI participe au regroupement des technologies de conteneurs (Docker et Rocket), afin de les unifier de permettre aux utilisateurs d’exécuter leurs applications conteneurisées sans se préoccuper de la technologie utilisée.
CNCF se focalise sur la portabilité des applications Cloud sur les conteneurs. La fondation soutient principalement le projet Kubernetes (porté par Google), mais également les projets Prometheus et OpenTracing.
Quelles sont les possibilités de collaboration entre les technologies de conteneurs et OpenStack ?
  • Les conteneurs sur OpenStack. L’exemple type est Magnum, le projet de déploiement automatisé d’une infrastructure de conteneurs sur OpenStack. Dans le cas, OpenStack est une base nécessaire pour le déploiement d’un cluster Kubernetes.
  • Les conteneurs sous OpenStack. On cherche ici à conteneuriser les divers services d’OpenStack. Kolla et Kolla-Kubernetes sont justement les projets de déploiement d’OpenStack dans des conteneurs Docker.
  • Les conteneurs et OpenStack. Les deux technologies sont dans ce cas entremêlées. Kuryr est un exemple de mise en application : machines virtuelles et conteneurs sont réunis sur un même réseau.
Les fondations OCI et CNFC cherchent à aider le développement des conteneurs et leur intégration dans OpenStack, au même titre que la fondation OpenStack contribue au développement des solution de IaaS.
En savoir plus :

Big Data and machine learning on OpenStack with nova-lxd

par: Andrew McLeod et Rayn Beisner – Canonical

 

Question: est il possible de déployer facilement une application complète de big data (hadoop, spark, bus de données, etc) dans un environnement cloud en gardant les performances du déploiement natif ?

Pour apporter une première réponse, des ingénieurs de Canonical ont utilisé leurs outils maison (MAAS, Juju, LXD) pour tester plusieurs types de déploiement de Hadoop/Spark et comparer les différentes solutions:
  • déploiement JuJu + MAAS pour définir des résultats natifs de référence
  • déploiement JuJu + Openstack/Nova + LXD
  • déploiement JuJu + Openstack/Nova + KVM
  • déploiement JuJu + cloud public
 
LXD, pour ceux qui ne connaîtraient pas, est un hyperviseur de conteneurs basé sur LXC offrant une expérience utilisateur proche de l’utilisation de machines virtuelles classiques (en comparaison avec Docker).
Grâce à l’intégration de LXD dans Nova, il est plus facile de basculer de machine virtuelle à conteneurs au sein de la même infrastructure de cloud et donc de profiter a priori d’une performance proche du déploiement natif.

Pour comparer les différents modes de déploiements, 3 calculs type ont été exécutés sur chacun d’entre eux:

  • une applicationde machine learning de type détection de fraud bancaire avec Apache Spark
  • benchmark « terasort » avec Apache Hadoop
  • benchmark « gigasort » avec Apache Hadoop
 
Les résultats sont conformes aux prévisions: quel que soit le type de calcul, le déploiement sur nova-lxd est de loin celui qui offre les meilleures performances. Les résultats sont d’autant plus vrais sur les benchmarks hadoop où les I/O disque sont fortement mis à contribution lors de la phase de réduction.
 
Ces premiers résultats sont très encourageants et ouvrent des perspectives intéressantes en terme de mutualisation des infrastructures cloud et bigdata (voir HPC).
 
En savoir plus :

Track Ops

Le ‘Track Ops’ rassemble les opérateurs d’OpenStack et permet d’échanger sur les sujets « chauds » du moment.

Une de ces Tracks est dédiée à la sécurité.

Point de vue opérateur : la sécurité

Fernet token

Le passage à l’authentification par jeton fernet ne se fait pas de manière transparente: une fois le format fernet activé, les anciens jetons d’authentification sont immédiatement invalides.

Utilisez toujours un mécanisme de caching pour les tokens Fernet : la génération et l’utilisation de ces tokens sont gourmandes en ressources.

Par contre, l’utilisation des token Fernet est au moins aussi (et souvent plus) performante que les autres format de token, et ils ne chargent pas la base de données.
Ce format sera probablement le format par défaut sur la version Ocata.

Un article sur le format et l’utilisation de ces tokens est en approche sur notre blog… Stay tuned !

 

Moyen de défense

Une bonne pratique souvent oubliée est l’analyse statique de code.
Les équipes sécurité d’OpenStack ont mis au point l’outil bandit qui permet de faire de l’analyse statique de code Python.  Le speaker résume ainsi : « cet outil n’est sans doute pas parfait mais c’est le meilleur qui existe ».
L’intégration de cet outil aux processus d’intégration continue permet d’améliorer le niveau de sécurité (et de maturité) du code. Certains projets OpenStack (comme Barbican) ont intégré bandit à leur processus de validation.

En savoir plus : https://github.com/openstack/bandit

 

 

policy.json

La gestion des roles et de leur droit dans les fichiers policy.json est assez douloureuse : difficile à mettre en œuvre, impossible de revenir en arrière, pas de gestion de fenêtre temporelle pour les autorisations.

Des réflexions sont en cours pour améliorer ces points mais le débat reste ardu car les fonctionnalités demandées par la sécurité sont rarement utiles à d’autres services. Les priorités sont donc très discutées.

Parmi les roles souvent déployés par les opérateurs, on retrouve:

  • opérateur (droit d’utiliser la CLI, de redémarrer les services mais pas de suppression)
  • audit (lecture seule de toutes les données)
  • responsable de tenant (pour gérer les utilisateur du tenant)

Sécurité des conteneurs2 conseils pour améliorer/conserver le niveau de sécurité des conteneurs:

  • Ne pas désactiver apparmor/SELinux
  • Limiter les appels systèmes autorisés par les containers

 

Structure dans OpenStack

Security Project : https://wiki.openstack.org/wiki/Security
Vulnerability Management team : https://security.openstack.org/