Sponsors OpenStack Summit

Jour 2

Vous n’êtes pas à Berlin 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.

  • Keynotes
  • Etat des lieux de Cyborg, Cloudkitty et Heat
  • Un Cloud OpenStack complètement Open Source : maintenant et plus tard
  • Provisionning de stockage dynamique à base de partages Manila/CephFS sur Kubernetes
  • « Spectre/meltdown at ebay classified group » ou comment patcher et rebooter 80 000 Cores
  • Migration LBaaS vers Octavia                         
  • L’odyssey de Zuul et autres outils OpenStack chez LeBonCoin

Bonne lecture !


Keynote

Pour ce 2ème jour, c’est Mark Collier qui ouvre la keynote, par quelques annonces :

  • la version après Stein s’appellera Train
  • le prochain Summit sera le 1er Open Infrastructure Summit et se déroulera à Denver du 29 avril au 1er mai
  • le suivant sera en Chine, au 4ème trimestre 2019

La remise des Community Contributor Awards est l’occasion de faire un appel aux contributions avec la mise en avant des ressources et programmes mis à disposition des nouveaux contributeurs.

Mark Shuttleworth intervient en milieu de Keynote pour revenir sur les ambitions de Canonical autour d’OpenStack – après un aparté un peu provocant sur le rachat de RedHat par IBM. Un engagement à retenir de son intervention : la version 18.04 d’Ubuntu sera supportée 10 ans.

La Keynote se clôture par la remise du Super User Award à City network – bravo à eux ! Nous sommes pour notre part ravis de nos échanges autour d’OpenStack avec leurs équipes à Stockholm.

Nouveaux projets

Le principe de « Big Tent » a été abandonné au profit du nouveau processus de « projets pilotes » : les projets sélectionnés en projets pilotes entrent en incubation durant 18 mois, avant de passer en statut « confirmé ».

4 projets pilotes ont été lancés ces 12 derniers mois : Airship, Katacontainers, StarlingX et Zuul.

Airship sert à manager des datacenters en utilisant des conteneurs et kubernetes comme base, et permet de déployer un cloud OpenStack avec Helm.
La roadmap est dévoilée pour Rocky et Stein et elle inclut, entre autres : l’orchestration « batteries incluses », le déploiement multi-sites, la résilience, l’intégration d’Ironic pour le provisionning du bare-metal, le support multi-OS…
 
AT&T présente une démonstration de déploiement de 5G utilisant OpenStack, networkcloud, openstack-helm et airship. La session est établie avec un présentateur à distance qui explique que la 5G est assurée par une VM dans OpenStack. Sur scène, la VM en question est « tuée » en direct, et avec « presque » zéro interruption. Plutôt convaincant !
Zuul est un projet d’intégration continue – cf. les articles sur le sujet pour plus de détails sur le projet.
Quelques slogans donnent le ton : « si ce n’est pas testé, on peut considérer que c’est cassé. » ou encore « Le cloud c’est fait pour l’automatisation, les humains pour la créativité. »
Parmi les utilisateurs, citons Ansible, leboncoin, BMX et bien sûr OpenStack.
Tobias Henkel de BMW donne ensuite son retour sur l’utilisation de Zuul, notamment dans le développement des fonctionnalités des systèmes de conduite autonome.
StarlingX est un projet qui permet de rconfigurer les technologies « cloud » pour du Edge Computing.
Intel, sur scène, détaille les nombreuses applications du Edge Computing (NFV, applications médicales, réalité virtuelle, jeux…). S’ensuit une présentation de Nemu, un hyperviseur de cloud.
Pour en savoir plus : https://github.com/intel/nemu
Pour finir avec les nouveaux projets, c’est la présentation du fonctionnement de kata containers. Après une présentation du système de conteneurisation « standard » (cgroups, namespaces, …), présentation de l’architecture Kata : des VMs très légères, qui implémentent le standard CRI (container runtime interface). Kata s’intègre nativement avec l’outillage existant, en particulier docker et kubernetes.
En 1 an, le projet est fier d’avoir « scalé » les contributeurs, les architectures et les fonctionnalités.

Démonstrations

Pas de bonne keynote sans bonne démo !
La 1ère démo concerne une application de reconnaissance vocale « live » tournant sur OpenStack, utilisant les GPUs.  Un comparaison est faite entre la même application tournant sur des CPUs et des GPUs, utilisant les mêmes APIs de traduction – et les performances sont nettement en meilleures avec des GPUs.
La 2ème démonstration utilise le projet Cyborg. Il s’agit d’utiliser une application tournant sur OpenStack pour de la reconnaissance faciale des émotions à partir d’une vidéo. Plutôt intéressant. Voir ci-dessous pour des détails sur le projet.

Cyborg – Project Update

Le projet Cyborg est né de discussions issues des exigences des opérateurs télécoms. Aujourd’hui, il existe une forte demande pour pouvoir supporter l’accélération matérielle, et Cyborg répond à cette problématique en l’intégrant à OpenStack.
Cyborg a connu une très forte croissance des contributeurs en 4 ans, et le projet est passé de 1 contributeur (Pike) à plus de 40 aujourd’hui, représentant une grande diversité de sociétés.
Les évolutions de Rocky
  • Contrôle au niveau des accès et gestion des quotas sur les ressources
  • Support de nombreux constructeurs
  • Standardisation des APIs pour le management des ressources
  • Programmation ‘FPGA bitstreams’ au travers de l’API
  • Meilleure gestion des librairies et des paquets
  • Fonctionne avec nova placement API (encore au stade expérimental)
  Les évolutions à venir dans Stein
  • Intégration complète avec Nova (travail en cours avec les équipes de nova)
  • Finalisation de l’intégration avec l’API placement
  • Intégration de nouveau drivers (Xilinx FPGA driver – Huawei NPU)
 Dans la Roadmap pour Train
  • Intégration avec Neuron via un plugin ML2
  • Intégration avec  Kubernetes

CloudKitty – Project Update

Le projet CloudKitty a été présenté par le PTL Luka Peschke – d’Objectif Libre.
CloudKitty est né dans l’air de la release Kilo et est un projet OpenStack officiel depuis 2015.
Le projet permet la valorisation de clouds via des métriques de gnocchi, monasca et prometheus. Une intégration à Horizon ainsi qu’à Grafana via le backend de stockage InfluxDB est disponible.
Le projet CloudKitty a maintenant besoin de plus de contributeurs et de feedbacks pour pouvoir grandir.
CloudKitty sur Rocky:

  • Consolidation du projet
  • Suppression du collecteur Ceilometer
  • Refonte du client
  • Possibilité d’utiliser CloudKitty  hors OpenStack
Roadmap prévue (Stein et releases ultérieures):
  • Gros focus sur la communauté et les community goals
  • Stockage v2
  • Api v2, basée sur Flask

Pour en savoir plus sur CloudKitty.


Heat – Project update

Présenté par Rico Lin et Zane Bitter.
Heat est l’outil d’orchestration des composants OpenStack et le projet continue son ascension auprès des utilisateurs OpenStack, en intègrant de plus en plus de nouvelles fonctionnalités.
Les nouveautés Rocky :
  •  De nouvelles propriétés pour Zun et Neutron
  •  De nouveaux attributs pour Nova et Neutron
  • L’ajout d’une nouvelle ressource Delay
  • La possibilité d’exécuter un template heat stockée dans un conteneur Swift (plus besoin de fichier en local)
Le projet a supprimé l’interaction de Heat avec Ceilometer et a remplacé certaines ressources par d’autres comme pour les ressources Magnum.
Heat innove et a pour roadmap :
  • L’amélioration de l’autoscaling et de l’autohealing
  • L’amélioration de la documentation
  • L’amélioration des notifications
Comme de trop nombreux projets, Heat a besoin de contributeurs afin d’améliorer ses services et de proposer des nouveautés pour la communauté.

Fully Open Source Smart OpenStack Cloud: NOW and BEYOND                         

La conférence était présentée par Ash Bhalgat de Mellanox, Franck Baudin de RedHat et Mark Iskra de Nuage.
                                                                                
Ash a commencé par effectuer une présentation du statut actuel des telcos.  Historiquement, depuis les années 80, les infrastructures étaient monolithiques. Depuis 2007, la virtualisation du réseau a fait son entrée dans le monde des télécoms.  Aujourd’hui, les infrastructures sont un mélange de solutions ‘software-defined’ (en tant que service) permettant une forte souplesse et automatisation, et de solutions matérielles pour la performance.
                                                                                                       
Franck Beaudin a enchaîné sur la partie technique de la présentation.  Concernant la virtualisation du réseau, il existe aujourd’hui plusieurs solutions :
  • OVS : largement utilisé dans le contexte SDN, qui offre une grande souplesse mais qui n’est pas performant lors d’une utilisation importante (débit faible, utilise beaucoup de CPU, pertes de paquets …)
  • DPDK : offre de bonnes performances car très proche du matériel, mais n’apporte pas la souplesse attendue d’une solution ‘software-defined’
  • ASAP² (Accelerated Switching & Packet Processing) : il s’agit de l’offload OVS dans les smartNICs. Cette technologie consistant a reléguer un maximum d’opérations dans les cartes réseaux est à la croisée des deux mondes.
Cette dernière solution repose essentiellement sur OVS, le principe étant que l’hyperviseur ‘offload’ un maximum de traitements vers les cartes réseau. les VM traitent alors directement avec la carte réseau. Pour effectuer ceci, le premier paquet est traité par l’OVS kernel et ovs-switchd. OVS va ensuite ‘offloader’ au besoin. Dans le cas d’un offload, c’est l’ eSwitch (dans la smartNIC) qui traitera les paquets par la suite.
                                                                                                       
Ceci permet, contrairement à DPDK, de bénéficier de l’accélération matérielle de la carte sans aucun usage de CPU et offre donc un gain de performance par rapport à DPDK, de l’ordre de x8 à x10 et x20 par rapport à de l’OVS vanilla. A noter : ASAP² est entièrement Open Source, bien intégré à la communauté Linux et aux environnements industriels, et bénéficie d’un support communautaire complet (OVS, openstack, Linux)
                            
Pour arriver à un tel fonctionnement, il a été nécessaire de modifier un grand nombre de logiciels.  Il a fallu commencer par implémenter les solutions techniques dans le kernel Linux, puis dans OVS, quelques modifications dans QEMU, puis libvirt, effectuer le packaging par les distributions linux, puis dans les solutions de SDN, dans les outils de déploiement d’openstack (ici tripleo) et enfin l’intégrer dans les distributions openstack (eg RDO)
                                                                                
Tout ceci permet grâce à l’ajout d’un « binding-profile » avec une capability « switchdev » sur le port neutron correspondant :                                             
 
$ openstack port create my-port –vnic-type=direct –network bar –binding-profile ‘{« capabilities »:[« switchdev »]}’
 
Le démarrage de l’instance se faisant de manière classique :                     
 
$ openstack server create –flavor f1 –image i1 –nic port-id=my-port vm1            
 
Mark a ensuite effectué une démonstration en utilisant Nuage.
 
Et après ?
Les principales fonctionnalités maintenant attendues pour l’évolution de cette technologie sont le port mirroring, VF LAG (HA), la QoS, Connection tracking, l’intégration dans les VNF propriétaires.

Dynamic Storage Provisioning of Manila/CephFS Shares on Kubernetes

Par Ricardo Rocha et Robert Vasek du CERN
Cette présentation commence par un petit tour d’horizon du Container Storage Interface (CSI), qui est encore actuellement en version Alpha. Son objectif est de fournir des standards pour gérer le stockage utilisé par les conteneurs, notamment dans les orchestrateurs. La version 1.0.0 de CSI est annoncée pour la fin du mois.
Le CERN est un gros (si ce n’est pas le plus gros) consommateur de Ceph. Et logiquement, Ceph est une des solutions privilégiées pour fournir du stockage aux pods dans un cluster Kubernetes (à ce jour, environ 10 000 clients CephFS au CERN).
Actuellement, le composant cloud-provider-openstack permet de faire interagir  Kubernetes avec OpenStack en passant par Manila pour créer des systèmes de fichiers partagés utilisés par le cluster.
La suite du talk s’est concentrée sur les benchmarks effectués par le CERN sur ceph-csi (driver CSI pour Ceph) et le provisionner Manila. Les tests du CERN ce sont avérés concluants et la solution est déjà en production.

« Spectre/meltdown at ebay classified group » ou comment patcher et rebooter 80 000 Cores

Pour rappel, les failles Spectre et Meltdown ont affecté un grand nombre de processeurs, en laissant à un attaquant la possibilité de lire des espaces de mémoire arbitraires d’un hyperviseur, y compris depuis des VMs.
Un cas d’usage chez Ebay Classifieds Group
Une time-line de 6 mois a été définie pour patcher l’ensemble des machines, en 2 phases : évaluation puis développement (interventions sur les différents environnements/régions).
La phase d’évaluation a permis d’identifier les paquets à mettre à jour : le kernel Linux, qemu-kvm et le BIOS. L’objectif de l’équipe était d’assurer la stabilité, quitte à prendre plus de temps que prévu. Il a également fallu prévoir la reconstruction de toutes les images cloud et patcher les kernels. CentOS/Redhat ont été les premiers à fournir le patch, puis Ubuntu a suivi.
Compte tenu de toutes les tâches à accomplir, un besoin d’automatisation a émergé. L’équipe a choisi Ansible pour une raison principale : le regroupement de tâches en rôles.
Quelques exemples :
  • Rôles OpenStack : enable-nova-compute, start-vms, stop-vms
  • Rôles Hardware : reset-idrac, restart-compute
  • Rôles Updates : update-os, upgrade-bios
  • Rôle spécifique : meltdown-specter-checker. Ce rôle vérifie si l’hôte est vulnérable aux failles.
L’équipe a choisi un workflow qui oblige à arrêter les instances. En effet, des tests ont été réalisés avec des instances migrées en ‘live’ et certaines applis ne le supportaient pas.
L’upgrade des BIOS s’est révélé compliqué, avec beaucoup de problèmes avec des iDrac. Certaines d’entre elles ne répondaient plus, il a été nécessaire de faire l’upgrade à la main en dernier recours.
Les tests préalables ont été effectués sur une sélection d’utilisateurs. À noter : l’équipe a refusé de patcher toute l’infra en une seule fois.
Le premier datacenter ayant bénéficié du patch a été Dusseldorf, au rythme d’une zone par semaine. Quelques problèmes sont apparus sur des clusters ElasticSearch, mais globalement ce fut un succès. Des problèmes ont été rencontrés lors de la campagne de patch sur le 2ème datacenter, dus aux iDracs.
L’équipe n’a pas constaté d’impact sur les performances des hyperviseurs.
Pour conclure, l’équipe a loué les possibilités d’Ansible pour l’automatisation dans ce genre de cas, a insisté sur les besoins de maintenance ciblée et a conseillé de réaliser des opérations de redémarrage des clusters le plus souvent possible.

Migration LBaaS to Octavia

German Eichberger et Carlos Goncalves nous présentent les opportunités de migration du LBaaSv2 vers Octavia.
Pourquoi migrer ?
LBaaSv2 est le composant historique de Load Balancer as a Service, entièrement géré par Neutron. Il est cependant déprécié depuis Queens (février 2018), et sera totalement supprimé en septembre 2019 (version en U).
Son successeur : Octavia, API indépendante de gestion des load balancers, matérialisée (par défaut) par des VMs minimales (Amphora –> HAProxy).
Comment migrer ?
La team Octavia propose à ses utilisateurs plusieurs processus de migration.

Plusieurs outils sont mis à disposition pour couvrir la majorité des use-cases :

  • Octavia provider driver : spécification du driver Octavia dans la configuration Neutron.
    • Permet d’activer le driver Octavia dans neutron. À noter que plusieurs services provider peuvent être spécifiés, permettant un chevauchement LBaaSv2/Octavia.
    • Configuration : neutron.conf –> service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
  • Neutron-proxy :
    • L’ensemble des requêtes LBaaSV2 sont acceptées par neutron-api, puis redirigées sur l’API Octavia
    • Configuration : neutron.conf –> remplacer le plugin « lbaasv2 » par « lbaasv2-proxy »
  • L7 redirect :
    • Utilisation d’un proxy externe (par exemple HAProxy) en amont de l’API neutron
    • Configuration : rediriger les requêtes « :9696/v2.0/lbaas » (endpoint neutron LBaaSv2) vers « :9876/load-balancer/v2.0 » (endpoint Octavia)
De plus, un outil a été développé pour migrer les load balancer « LBaaSv2 » existants vers Octavia: « nlbaas2octavia » (https://github.com/openstack/neutron-lbaas/tree/master/tools/nlbaas2octavia)
La présentation de l’outil est accompagnée d’une démo (vidéo), qui migre avec succès un lbaasv2 (haproxy) vers  Octavia. La migration paraît rapide, à tester !
Le mot de la fin : « Migrate soon, migrate today, migrate NOW 🙂 »

Zuul and other OpenStack tools at Leboncoin: the odyssey

Durant la 1ère partie de cette présentation, Thierry Carrez est revenu sur l’histoire de Zuul et de la CI OpenStack. À l’origine, celle-ci était basée sur Bazaar pour la gestion de code source, Launchpad pour la code review et Tarmac, un outil développé par l’équipe infrastructure d’OpenStack permettant d’effectuer quelques vérifications élémentaires sur chaque commit. Peu après, Jenkins a été utilisé pour exécuter des jobs de tests et post-intégration.

Par la suite, Bazaar a été remplacé par Git. Gerrit est venu remplacer Launchpad et a permis de gérer la fusion de branches Git. Tarmac n’a plus été utilisé, et Jenkins servait pour les jobs de test et post-fusion.

Enfin, Zuul est arrivé en remplaçant de Jenkins. Zuul permet de faire du speculative gating (tester ensemble plusieurs patchs inter-dépendants) et d’exécuter des jobs de post-intégration.

Aujourd’hui, la devise est « Nothing should ever be merged by a Human », et les outils suivants sont utilisés pour automatiser le plus de choses possibles :

  • Nodepool : permet de gérer un pool de VMs (appelées nodes) pour les mettre à la disposition de Zuul. Plusieurs drivers existent pour nodepool: OpenStack, Azure, EC2…
  • Reno : génère des releasenotes à partir de fichiers yaml
  • Sphinx : génère de la documentation à partir de fichiers rst

Durant la seconde partie de la présentation, l’équipe Leboncoin a commencé par présenter leurs chiffres clés:

  • 28 millions d’utilisateurs uniques par mois
  • 27 millions d’annonces
  • 5ème site le plus visité de France, après Google, Facebook, Youtube et Wikipedia

L’équipe a ensuite détaillé la manière dont Zuul, Gerrit, Nodepool et OpenStack sont déployés chez Leboncoin. Nodepool est utilisé pour construire les images cloud de la CI et pour gérer les nodes sur OpenStack, Zuul est utilisé pour l’intégration des branches et les jobs post-intégration (documentation, release notes…) et Gerrit est utilisé pour la code review. Aujourd’hui, plus de 17000 reviews et 20000 déploiements sont réalisés tous les mois chez Leboncoin.