OpenStack Summit Vancouver 2018

Pause Cloud & DevOps – édition spéciale OpenStack Summit Vancouver 2018

Jour 4 et dernier jour !

Vous n’avez pas pu venir à Vancouver pour assister à l’OpenStack Summit et vous souhaitez savoir ce qui est annoncé/présenté d’important ? Les consultants d’Objectif Libre sur place vous racontent.

Au menu : du cloud, de l’Open Source, du stockage, du réseau, de l’Open Infrastructure… tout ce qui fait OpenStack.

  • Keystone in the context of Fog/Edge Massively Distributed Clouds
  • Containers on Baremetal and Preemptible VMs at CERN and SKA
  • Bringing Istio to Openstack
  • How to implement FaaS in OpenStack for public cloud
  • Project Updates

Bonne lecture !

Pour lire le retour du jour 1 : https://olib.re/20180522-pause-openstack-summit-1

Pour lire le retour du jour 2 : https://olib.re/20180523-pause-openstack-summit-2

Pour lire le retour du jour 3 : https://olib.re/20180524-pause-openstack-summit-3

Keystone in the context of Fog/Edge Massively Distributed Clouds

Adien LEBRE, Marie DELAVERGNE et Ronan-Alexandre CHERRUEAU, nous font un retour très concret sur la mise en application du edge computing pour Keystone.

Les intervenants provenant du milieu de la recherche (inria), ils ont su apporter méthodologie et clarté à cette conférence.

Objectifs

Étude de l’impact d’un des challenges du edge computing (latence multi-site) sur un composant OpenStack : Keystone.

Pourquoi utiliser Keystone comme exemple ? Entre autres en raison de la simplicité de mise en œuvre pour les benchmarks.
Cependant, le cas des autres composants sera également pris en compte pour la suite des tests.

Keystone

Qu’est-ce que Keystone ?

  • Une API
  • Une base de données

Le principal challenge est de pouvoir distribuer la base de données sur l’ensemble des macro/nano datacenters portant le service Keystone, tout en subissant les latences du WAN (~150ms).

La suite de la conférence fait donc l’état des différentes solutions pour distribuer le SGBD dans de telles conditions.

Solutions

Trois solutions sont étudiées :

Opt 1 : MariaDB centralisé

  • Toutes les API Keystone sont connectées à la BDD centralisée
  • Simplicité de mise en place

Les points négatifs ?

  • C’est un SPoF (centralisé…)
  • Non résilient aux problèmes réseaux

Opt 2 : Galera & Mariadb – Réplication multi-masters :

  • Transactions synchrones
  • Read/Write sur toutes les instances de Galera
  • HA

Les points négatifs :

  • Transactions synchrones : dépendantes de la qualité de la bande passante
  • Scalabilité : toutes les instances Galera doivent valider la transaction

Opt 3 : CockroachDB (CRDB) Géo-Distribué

  • K/V store avec une interface SQL
    • Tables séparées en « ranges »
    • Ranges géo-distribués sur les différentes instances
  • Contrairement à Galera, il suffit d’avoir la confirmation de la transaction par seulement 2 instances.

Le point négatif : la localisation des données est importante, attention aux latences qui ralentissent les commits.

Tests & résultats

Les speakers ont utilisé Juice pour la simulation de l’environnement Edge OpenStack, les tests sont quant à eux exécutés par Rally.

De nombreux cas sont testés :

  • Légères charges à faibles et hautes latences
  • Hautes charges à faibles et hautes latences
  • Les tests Rally :
    • Génération de token
    • Création d’utilisateurs
    • Mise à jour de mot de passe
    • etc.
  • Nombre d’instances de la solution testée : 3, 9 & 45

Ce que nous en retiendrons :

  • Galera supporte très mal les hautes charges
  • CRDB supporte très mal les latences

Cependant, plusieurs améliorations sur la location des données avec CRDB permettent de palier aux problématiques de latences.

Questions

  • Mode distribué de PostgreSQL ? Le driver PostgreSQL n’est actuellement plus supporté par OpenStack, donc pas de test sur cette solution.
  • Type de Token ? Fernet bien sûr, par défaut depuis Pike.

Nous vous invitons à regarder la vidéo du talk, pour y retrouver les nombreux résultats des tests et les explications associées.

 

Containers on Baremetal and Preemptible VMs at CERN and SKA

Cet article vient compléter le fishbowl « pre-emptible instances » du jour 2.

A ce jour, le CERN possède le plus gros déploiement OpenStack du monde (+600 000 cœurs et +2 Po de RAM). Le Square Kilometer Array, ou SKA, le plus grand projet de télescope jamais construit, nécessitera des infrastructures d’une amplitude similaire. À cette échelle, l’optimisation des ressources est cruciale : une perte d’1 à 2% des performances représente déjà un coût énorme.

Pour le SKA, les conteneurs baremetal permettraient d’éviter la baisse de performances due à la virtualisation. De plus, ils démarrent rapidement, ce qui est adapté à l’observation d’événements. Ils facilitent également les cycles de développement et de déploiement. Au CERN, ces conteneurs baremetal sont orchestrés via Magnum et Ironic. Kubernetes et docker swarm sont les deux backends supportés par Magnum. Depuis Queens, Fedora Atomic est utilisé pour les VM et le baremetal.

En ce qui concerne les instances pré-emptibles, quelques précisions ont été apportées concernant le service Reaper. Celui-ci a pour rôle d’orchestrer les instances pré-emptibles : il les supprime lorsqu’il y a un besoin de ressources, et toutes les instances de ce type ont un Time To Live (TTL), une durée de vie maximale.

Le workflow est le suivant:

  • nova-scheduler rencontre une erreur « No valid host ». L’instance à créer est mise en état PENDING et un signal est envoyé au service Reaper.
  • Reaper sélectionne et supprime des instances pré-emptibles.
  • Une requête est envoyée à nova-api, et l’instance qui n’avait pas pu être créée auparavant est reconstruite.

À la fin de la conférence, une question a été posée sur la manière dont Reaper sélectionne les instances à supprimer. La réponse a été la suivante : on peut imaginer un système de policies, avec différentes priorités entre les instances pré-emptibles. D’autres facteurs peuvent également jouer, comme la durée depuis laquelle l’instance a été créée. Cependant, le choix est totalement aléatoire pour le moment.

 

Bringing Istio to Openstack

Par Timothy Swanson et Arvind Somya
Après un premier talk en début de semaine sur le déploiement d’une application à l’aide d’Istio sur deux cloud providers, nous avons assisté aujourd’hui à un second talk sur Istio mais 
uniquement lié à OpenStack.
Pour rappel, Istio est une solution de service mesh qui a les composants suivants :
  • Envoy : un proxy qui est présent dans chaque pod applicatif (sidecar container)
  • Pilot : le Control Plane pour les proxy ; il les configure et leur communique leurs règles de routage
  • Citadel : fournit les certificats et les clés à tous les pods pour sécuriser le control plan et les échanges entre les applications
  • Mixer : composant qui s’occupe de la télémetrie
Lors de ce talk, une démonstration de déploiement d’application a été faite. Dans un premier temps, le backend d’un des services était migré vers une base de données MySQL conteneurisée. Ensuite une nouvelle instance OpenStack a été créée et le backend a été migré d’un MySQL conteneurisé vers un MySQL installé dans une instance OpenStack.

How to implement FaaS in OpenStack for public cloud

Cette partie synthétise le contenu de plusieurs sessions sur la journée.

Pour commencer : qu’est-ce que le FaaS ?

Pour beaucoup, le FaaS (Function as a Service) serait la prochaine évolution des conteneurs.

L’idée est de permettre aux développeurs de passer le moins de temps possible sur la gestion/utilisation de l’infrastructure, pour pouvoir se concentrer sur le fonctionnel.
Il existe énormément de projets/solutions/produits qui font déjà cela, mais aucun sur OpenStack. C’était une demande pour des clients de Catalyst (Public Cloud Provider en NZ), dont les développeurs se sont attelés à la tâche. Ils ont commencé par regarder les projets Open Source, mais rien ne leur convenait.

Architecture

L’architecture est assez classique :

  • qinlin-ap gère les requêtes utilisateurs et communique vers keystone et la base de données
  • qinling-engine maintient les ressources sous-jacentes nécessaires
  • les workers sont en deux parties pour le téléchargement des paquets (des fonctions)
  • les runtimes où seront exécutées les fonctions

Où la fonction est-elle exécutée ? VM ou container ?

Les conteneurs semblent le bon endroit car :

  • Moins d’overhead
  • Une très bonne et simple gestion via leurs orchestrateurs. K8s est le backend par défaut. K8s étant en plus proposé via Magnum et semble donc un bon choix
  • Les fonctions aujourd’hui sont exécutées dans Kubernetes, et déployées via Magnum
  • Une attention particulière doit être portée à la sécurité (comme pour tout ce qui fonctionne en cloud public)

Quelques points de vigilance plutôt ops

Et la sécurité dans tout ça ?

  • Il est nécessaire de proposer des fonctions de type image
  • Il faut autant que possible bien gérer les séparations  (K8s RBAC, Quota, Network Policy, Pod security)
  • Il faut aussi assurer le maximum d’isolation des conteneurs avec de la virtualisation
  • Pourquoi ne pas regarder maintenant Kata et gVisor ?

Comment monitorer et débuguer l’exécution des fonctions ?
Un monitoring concentré sur la classe de CPU et la mémoire permet d’avoir un premier élément mais n’apporte rien sur la performance, qui n’est pas couverte pour le moment (contrairement à des solutions de certains public cloud comme X-Ray de AWS Lambda ou Retrace de Azure Functions). Il est toujours possible d’exécuter localement mais ça n’est pas l’idéal. Il faut aussi pouvoir quantifier le nombre d’appel pour savoir ce qui sera fait.

Que manque-t-il ?

Les fonctionnalités suivantes manquent aujourd’hui :

  • Gestion des Logs
  • Gestion de la facturation
  • Standardisation des événements
  • Fonctions stateful (pour le moment uniquement des fonctions stateless)
  • Orchestration des fonctions

Les points qui seront abordés dans Rocky sont les suivants :

  • Amélioration de la documentation
  • Suite du travail de versionning
  • Sécurisation de la connexion avec K8s
  • Capacité à limiter les ressources

Au-delà de Rocky

  • Doc, doc, doc !
  • Capacité d’envoyer une notification de l’usage pour permettre la facturation par exemple
  • Création d’alias de fonction et de tag pour les fonctions (utile pour regrouper des fonctions pour le paiement)
  • Intégration dans Horizon
  • Mécanisme de gestion des erreurs
  • Autoscaling plus poussé (pour avoir plusieurs algorithmes par exemple)
  • Intégration de CloudEvent
  • Intégration de plateformes Serverless

Qinling est pleinement un projet OpenStack

Il s’intègre bien avec les autres !

  • Mistral pour l’orchestration de larges quantités de fonctions
  • Aodh est un très bon endroit pour exécuter des fonctions du fait de sa capacité à exécuter des requêtes HTTP à partir de ses alarmes
  • Swift pour la gestion des swift code function
  • Magnum qui permet de déployer l’environnement K8s qui sert de base Qinling

Pour finir nous avons eu deux démos LIVE qui illustrent l’intérêt de Qinling – suffisamment rare pour être souligné !

Function execution autoscaling

Après la mise en place d’une simple fonction (un classique « hello world » en python), une démonstration de la scalabilité automatique des workers qinling a été faite, où, automatiquement, de nouveaux workers sont ajoutés en fonction du nombre de fonctions à exécuter. L’association fonction-workers a une durée de vie de 5 minutes par défaut, mais il est  possible de forcer ce détachement (ce qui peut par contre impliquer un temps de traitement supplémentaire lors de l’appel initial).

Function versioning

Le versionnement des fonctions a été mis en évidence, en partant de la fonction « hello world » créée au préalable, puis en la modifiant pour créer une nouvelle version. La démonstration a porté sur la possibilité de pouvoir exécuter n’importe quelle version de la fonction, mais également de pouvoir faire du management des versions (et ainsi en supprimer de l’histoire disponible). Ce genre de traitement est très utile lors d’une phase de migration, et offre de nombreuses possibilités (blue/green, canary, …).

 

Project Updates

La majorité des projets OpenStack proposent une présentation de leur actualité : ce sont les sessions « project update ».

Durant cette journée, l’infra a particulièrement retenu notre attention.

Infra

Par Clark Boylan, OpenStack Foundation.

Cette session commence par le remerciement des fournisseurs d’infrastructure cloud, à savoir :

  • CityCloud
  • Internap
  • Limestone Network
  • Linaro
  • Ovh
  • Rackspace
  • Vexxhost

Les éléments importants à noter sur le dernier cycle (Queens) sont les suivants :

  • Support multi-architecture
    • amd64/x86-64
    • arm64/aarch64
  • Ajout du support UEFI pour image-builder
  • Storyboard
    • De plus en plus de projets de migration
    • Accès aux stories privées pour les équipes
    • Sensibilisation en interne afin de trouver de nouvelles fonctionnalités
  • Zull !
    • Zull v3 était la priorité pour l’équipe
    • Intégration dans Github (pour les tests)
    • Zull a maintenant son propre dépôt
    • Fonctionnalités en V3 :
      • Écriture des jobs dans un langage plus familier (Ansible)
      • Gestion des secrets
      • jobs sur multi-nœuds en natif
    • Documentation:

La conférence a continué sur les prévisions pour les prochaines versions (à partir de Rocky) :

  • Gestion de configuration qui doit être modernisée et mise à jour
  • Gerrit 2.15
  • Amélioration des bots IRC due à la limitation de freenode
  • Support multi-architectures :
    • Devrait être plus simple à utiliser
    • Pas d’ajout de nouvelle architecture mais stabilisation des actuelles

 

La seule chose qu’il nous reste à vous dire : See you in Berlin !