Pause Cloud & DevOps

Pause Cloud & DevOps – édition spéciale OpenStack Summit Denver 2019

Jour 2

Vous n’êtes pas à Denver pour assister à l’OpenStack Summit, à votre grand regret ?

Pour cette édition, Objectif Libre s’est déplacé en force pour vous permettre de suivre le Summit comme si vous y étiez !

Au menu : de l’Open Infrastructure.

  • Conteneur use-cases et développement du Cloud au CERN
  • Blizzard avec son autoscaling sur le jeu OverWatch
  • Reconnaissance faciale avec OpenStack
  • Octavia project asistéupdate
  • Scaling OpenStack infrastructure
  • Nova versioned notifications – the result of a 3 year journey
  • Where would open source be, after Commons Clause

Bonne lecture !


Container use-cases and developments at the CERN cloud

La conférence débute par un bref retour sur l’évolution de l’utilisation d’OpenStack au sein du CERN, suivie des traditionnels chiffres concernant leur infrastructure: Environ 300 000 coeurs, 200 instances démarrées par heure, plus de 34000 instances actives, et un peu moins de 2000 nodes magnum.

On a ensuite assisté à une présentation des differents cas d’utilisation de conteneurs au sein du CERN: « batch processing » (traitement de données), machine learning, CI/CD…

Au CERN, les clusters Kubernetes sont déployés grâce à Magnum, un projet OpenStack permettant de déployer des orchestrateurs de conteneurs (notamment Docker Swarm, Kubernetes et Apache Mesos).

Les clusters Magnum sont composés de plusieurs types de ressources OpenStack: Instances (virtuelles ou bare-metal), réseaux neutron, groupes de sécurité, volumes cinder, load-balancers… Ces resources sont créées grâce à Heat, le composant d’orchestration.

Le CERN recommande d’utiliser Magnum pour les raisons suivantes:

  • Le composant permet de fournir des clusters « on premise », à la manière de GKE ou d’AKS.
  • Il rend les conteneurs faciles d’accès pour les nouveaux utilisateurs.
  • Il permet de contrôler l’OS utilisé.

Il est cependant nécessaire de s’attarder sur les points suivants lorsqu’on décide d’administrer un service proposant des conteneurs:

  • Le design du réseau: Par défaut Magnum créé un réseau privé par cluster et assigne des addresses ip flottantes aux nodes. Il faut également prendre en considération les LBaaS pour les clusters multi-master.
  • Il est bien souvent nécessaire de fournir un registry d’images, car le Docker Hub pose des problèmes de latence.

La présentation se conclut par une liste de fonctionnalités à venir sur différents projets:

 


Blizzard avec son autoscaling sur le jeux OverWatch

Blizzard, éditeur de jeux vidéos depuis plus de 25 ans nous présente les enjeux et les solutions pour scaler automatiquement les serveurs qui permettent de faire tourner Overwatch, un FPS massivement multijoueur.
Les enjeux : 
Les méthodes traditionnelles de mise à l’échelle (scale up) sont peu pertinentes pour Blizzard. En effet, les connexions à ces serveurs sont statefull et on ne peut pas couper un serveur sans déconnecter les joueurs présents. Il faut donc un mécanisme de drainage des connexions existantes, ce qui n’existait pas. 
Blizzard utilise OpenStack depuis 2012 et l’idée d’utiliser les outils propres à OpenStack a émergé. Ils ont néanmoins commencé par utiliser les fonctionnalités fournies pas AWS.
Heat : 
Heat ne répondant pas vraiment à leur besoin, ils se sont tournés vers d’autres outils OpenStack : Senlin.
Senlin :
Senlin est utilisé pour gérer des clusters de serveurs de jeux. Blizzard a développé des outils ‘maison’ qui calculent la charge dans un cluster donné, et a défini des seuils. Lorsque ces seuils sont atteinds, d’autres VMs sont démarrées dans le cluster et contribuent àfaire baisser la charge globale. Le cas inerse est également traitée, lorsque la charge diminue suffisamment, des VMs sont arrêtées et supprimées, laissant la possibilité à d’autres clusters de profiter des ressources ainsi libérées.
Pour conclure :
Les gains ont été importants : Ils ont noté une réduction globale de l’utilisation des ressources matérielles de l’ordre de 40%. Avec cette stratégie cloud, inédite dans le monde des serveurs de jeux vidéos, le cluster est capable très rapidement d’absorber une montée en charge imprévue. 
À noter que Blizzard contribue activement au développement de Senlin.

Reconnaissance faciale avec OpenStack

Cette conférence a été présentée par Erwan Gallen et Sylvain Bauza, RedHat.
La reconnaissance faciale (RF) est à définir. Il ne faut pas confondre avec :
  • détection faciale : carré autour des visages comme pour identifier des personnes sur Facebook
  • classification faciale : détection d’âge ou d’émotions
  • manipulation faciale : ajout de filtre sur un visage comme sur Snapchat
C’est une science informatique avant tout qui permet d’identifier des personnes via des multiples points détectés sur les visages.
Grâce à une base de données d’images de visages, l’IA permet d’apprendre les traits d’une personne.
C’est en résumé une identification et vérification de visage comme on peut retrouver sur le verrouillage de nos téléphone portable.
Alors pourquoi ? Parce que les réseaux sociaux comme Flickr, Facebook ont eu besoin de cet outil mais avant tout la sécurité dans les aéroports.
Cela n’est pas nouveau :
  • 1964: création de points dans une base de données sur un visage
  • 2012: le projet AlexNet gagne le concours de RF
  • 2014: DeepNet est le premier algorithme de RF basé sur AlexNet
La RF utilise l’accélération matérielle. Il existe plusieurs types de Hardware comme Neural compute stick 2 ou Coral.
Sur OpenStack on peut utiliser les vGPU avec Nvidia (Tesla T4/V100)
Pourquoi OpenStack:
  • Possibilité de tout gérer via une seule API
  • Contrôle de l’utilisation Hardware par des contrôle d’accès
2 types d’utilisations des GPU sur OpenStack : 
  1. Gpu Passthrough : Pas très bien car c’est une carte Graphique par instance (1:1)
  1. Virtual GPU : Release Queens. Allocation à la demande (1:N) et équipement managé seulement par le compute.

Demo Time :

Une instance avec utilisation de CPU pour la RF : apprentissage de la base de données d’image en 3 images par seconde.
Une instance avec l’utilisation de vGPU : apprentissage de la base de données d’image en 153 images par seconde.
Pour conclure, on peut dire que les avancées en termes de vGPU sont utiles à tous les domaines et est en constante évolution suivant les besoins que nous auront dans le futur.

Octavia update

Octavia est le projet officiel de LBaaS (LoadBalancer as a Service), remplaçant du composant neutron-lbaas aujourd’hui déprécié.
Ce projet utilise des images nommées Amphora, conçues pour exécuter un répartiteur de charge (HAProxy) controlable par API par les services d’Octavia.

Updates pour Stein

  • Flavor Octavia : permet pour un administrateur de donner le choix du mode de balancing (simple ou actif/passif) au utilisateurs.
  • L7 policy : donne la possibilité de définir des règles L7 basées sur des informations d’authentification du client TLS
  • Activation de l’authentification par certificat règle via les L7 policy, les administrateurs peuvent attribuer des droits suivant le certificat
  • Tag : ajout de l’option Tag permettant retrouver les instances amphora
  • Octavia-lib : ajout d’un module python pour octavia qui permet d’intégrer plus facilement les drivers à l’API Octavia.

Updates prévus pour Train

  • L’équipe d’Octavia travaille conjointement avec l’équipe de neutron faciliter la transition de neutron-lbaas vers Octavia.
  • En effet neutron-lbaas est déprécié, seuls les bugs seront corrigés jusqu’à son retrait total d’OpenStack.
  • Elle va ajouter un contrôle d’accès sur les VIP que donne Octavia à l’instance Amphora et ajoutera plus de log concernant cette dernière.

Les souhaits de l’équipe pour le futur

  • Plus de health checks
  • Conteneuriser Amphora
  • Amélioration des notifications
  • Permettre un mode Active/Active avec de l’autoscaling
Beaucoup de nouvelles features qui vont se faire attendre par un grand nombre de personnes.

Scaling OpenStack infrastructure

Jonathan Roll (AT&T) nous présente son retour d’expérience sur la mise à l’échelle d’une plateforme OpenStack.

La ligne directrice : « Begin with the end in mind ».

Il nous explique les points clés pour la mise en place d’une plateforme pérenne :

  • Performance, efficacité ou coût : généralement, seulement 2 de ces cibles peuvent être atteintes
  • Anticiper les tendances & changements avant qu’ils ne se produisent
  • Anticiper les demandes des utilisateurs finaux

Jonathan nous rappelle qu’il ne suffit pas juste de mettre la plateforme à l’échelle, mais également d’y penser de façon intelligente.

La suite de la conférence se résume à décrire les différents risques à anticiper.

Théoriquement, les risques évoluent proportionnellement au temps/scale de la plateforme. En réalité, les impacts des risques surviennent bien plus tôt, et freinent ou bloquent la mise à l’échelle de la plateforme.

Sans gestion de risques, on atteint une « barrière » du succès à un moment ou un autre.

Les risques & leurs solutions sont ensuite explicités tout au long de la conférence.

Les fondements

  • Mauvais voire peu de pré-requis –> Établir une relation entre les clients et les développeurs
  • Pas de discussion/mauvaise communication avec les utilisateurs finaux –> Augmenter la qualité de la spécification du besoin
  • Pas de vue sur le long terme –> Avoir une phase de début de projet dédiée aux prérequis
  • Manque de spécification géographique –> Définir des milestones

La préparation

  • Problèmes de financement –> Affiner la crédibilité du projet, le définir dans le temps et expliciter les coûts
  • Manque de logistique –> S’assurer d’une clarté avec les fournisseurs/partenaires
  • Aucune assurance sur la maturité des sites de déploiement –> Avoir une vision claire de la temporalité du projet
  • Pas de plateforme de validation –> Pas de chocolat.

L’exécution

  • Soucis d’installation –> Rester simple (KISS), la complexité est l’ennemi de la rapidité pour le scalling
  • Pas de tests réels :
    • Soucis de validation
    • Erreurs lors de la mise en production
    • Pas de plateforme d’intégration pour tester la non-régression

    –> Mettre en place un système d’intégration & déploiement continue selon une démarche DevOops

Le reste

  • Mauvaise compréhension des besoins –> Avoir continuellement des feedback
  • Pas de gestion des inconnues / « surprises » non-anticipées –> Pas de panic(), il est quasiment impossible de prédire ce risque, vous devez l’accepter.

La conclusion de la conférence : « Comment peut-on réussir lorsqu’on ne sait pas où l’on va ? »

Pour notre part, nous nous attendions à une conférence avec un minimum de retours techniques, ce ne fut malheureusement pas le cas. La conférence reste cependant intéressante car les notions abordées s’appliquent de manière générique à la grande majorité des projets.


Nova versioned notifications – the result of a 3 year journey

Présentation de la fonctionnalité des notifications versionnées dans Nova par Balazs Gibizer (Ericsson)

Le cas d’utilisation

Détecter qu’un compute n’est plus disponible.

Actuellement, nova ne notifie pas le statut de services.

Les specs

Cette nouvelle interface doit être :

  • Documentée (aucune doc actuellement, on ne sait pas comment sont formées, quelles données)
  • Versionnée (actuellement aucun moyen de savoir si entre 2 versions de notifications quelque chose à changé)
  • Testée (pas de vrais tests actuellement)

L’idée a vraiment été appréciée durant le summit de Tokyo, surtout concernant les specs très détaillées.

L’implémentation

Presque 2 ans de travail ! Après 5 versions openstack et plus de 90 commits, la nouvelle interface est enfin implémentée.

La démo

Démo en live sur une DevStack :

  • Lancement d’une instance
  • Utilisation d’un petit script python pour forwarder les notifications versionnées sur une web socket.
  • On remarque bien les notifications (très détaillées) décrivant chaque étapes de création/suppression de l’instance

La conclusion

  • Peut-on maintenant supprimer l’ancienne interface de notification ? Non !

Beaucoup de projets consommant les anciennes notifications ont maintenant très peu de contributeurs, le travail pour s’adapter à ces nouvelles notifications n’est actuellement pas envisageable.

  • Était-ce une perte de temps ? Non, la nouvelle interface apporte de nombreuses fonctionnalités, mais actuellement aucun projet ne l’utilise.
  • Et notre use case ? Il est maintenant rempli!

Surement l’une des conférences les plus représentatives de l’esprit communautaire d’OpenStack : pourquoi cette fonctionnalité, quels use cases, quels retours de la communautés, des exemples, et un regard objectif sur son utilité actuellement. Merci au speaker.

Slides : https://bit.ly/versioned
Code de la démo : https://github.com/gibizer/nova-notification-demo


Where would open source be, after Commons Clause

Fred LI & Jianfeng JF Ding nous parlent de l’avenir des projets open source dans un monde dirigé par les clouds publics.

De nombreux outils sont aujourd’hui revendus par des clouds publics sous forme de services managés : Redis, MongoDB, Postgres, Elasticsearch,..etc… Plusieurs de ces outils ont adapté leur licence avec la Commons Clause.

Pour rappel, la Commons Clause est une condition applicable à une licence existante, ajoutant une clause de restiction à la vente. Pour plus d’information : https://commonsclause.com/

Les speakers nous présentent plusieurs cas concrets :

  • Redis :
    • d’une licence AGPL vers une licence Apache2 modifiée par la Commons Clause, août 2018
    • d’une licence Apache2 modifiée par la Commons Clause vers la license RSAL (Redis Source Available License), février 2019
  • MongoDB : d’une licence AGPL vers une licence SSPL (Server Side Public License)

On en vient ensuite à l’explication des différents business models autour de l’open source :

  • Fonctionnalités payés (redis, mysql)
  • Donations (hadoop)
  • Partenariat publicitaire (Mozilla)
  • SaaS (wordpress, gitlab)
  • Support & Service (RHEL, ubuntu)
  • Hardware Platform Enabling

Explication de l’écosystème autour des outils open source, 3 modèles actuellement :

  • Un outil propriétaire utilise des outils open source (en dépendance)
  • Un outil propriétaire revend un outil open source, en y ajoutant des fonctionnalités
  • Un outil propriétaire revend plusieurs outils open source, en y ajoutant des fonctionnalités

La conclusion : bien choisir son business model, et sa méthode de contribution aux outils open source.