OpenStack Summit Berlin

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

Jour 1

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
  • Intégration continue à grande échelle avec Zuul
  • Doubler les performances réseaux avec vSwitch
  • Automatisation des applications stateful avec les opérateurs Kubernetes
  • oslo policy 101
  • Un état des lieux de OpenStack et Ceph dans l’edge computing
  • Etat des lieux de Cinder et de Keystone
  • Service Réseau avancé de Load Balancer

Bonne lecture

Keynote

Dans la tradition des OpenStack Summits, Jonathan Brice ouvre la keynote inaugurale et annonce la couleur : cette édition sera placée sous le signe de l’Open Infrastructure, comme probablement les prochaines puisqu’il a été question d’Open Infrastsructure Summit.

Avant de détailler le concept, il donne quelques chiffres issus d’une large enquête menée par la Fondation sur l’impact de l’Open Source, auprès des communautés mais également en dehors du monde de l’Open Source. Pour 81% des répondants, l’Open Source gagne de plus en plus d’importance ces dernières années.

Les raisons ?

  • Flexibilité et contrôle. L’Open Source ouvre des possibilités avec un impact positif sur le business. Illustration : plus de 75 clouds publics tournent sur OpenStack dans le monde.
  • Une vraie inter-opérabilité
  • Les possibilités accrues d’intégration
  • Les capacités d’innovation : l’Open Source permet d’innover rapidement, voire plus rapidement que le marché

Revenons au concept d’Open Infrastructure. Tout part du constat que les besoins ont changé, et ces changements impactent les infrastructures : l’explosion des données, les nouveaux besoins au niveau des terminaux, etc. L’infrastructure devient « Software designed » et se doit d’être nativement prête pour le cloud afin de supporter les applications de nouvelle génération (AI, machine learning, conteneurs, Edge computing…).

L’enjeu devient donc de garantir que ces couches successives soient toutes « ouvertes » afin de conserver les bénéfices de l’Open Source à tous les niveaux.

Le slogan pour cette édition : « OpenInfra starts with OpenStack.« .

 

Nicolas Barcet de RedHat explicite ce positionnement : l’Open Infra se trouve à l’intersection d’OpenStack et de Kubernetes, et cette complémentarité est mise en avant comme « un jeu à somme non-nulle ». Un point à relever sur son intervention : RedHat propose d’accélérer le rythme des releases d’OpenStack pour passer à 1 par trimestre et innover plus vite. A suivre…

Quelques chiffres sur la contribution sont donnés pour continuer :

  • 70k commits sur OpenStack cette année
  • Sur Rocky en particulier:
    • 182 commits par jour
    • l’équipe cite 328 000 lignes modifiées et souligne les contributions croissantes de la part d’opérateurs de plateformes
Une tendance à souligner également : on constate de plus en plus de « petits déploiements », entre 10 et 100 nœuds, voire même en-dessous de 10 nœuds. OpenStack n’est plus réservé aux « grandes architectures », tout ça grâce à l’outillage qui permet de faciliter les déploiements. Sur ce point précis, nous vous invitons à découvrir notre Build & Lifecycle Manager.
Parmi les speakers-sponsors qui se succèdent sur la suite de la keynote, faisons un focus sur l’intervention de T. Carrez, de la Fondation, et de A. Fiocco d’OVH, qui apportent  quelques chiffres sur le cloud provider français.

OVH en quelques données, c’est (à date) :

  • du cloud bare metal privé ou public
  • 28 datacenters à travers le monde
  • 360k serveurs
  • 1,4M clients
  • 260k instances en production
  • 150PB de stockage physique sur Swift
  • 1 234 k instances démarrées chaque mois

Le dernier upgrade (Juno -> Newton) a duré 4h, sans interruption de service pour les clients.

A. Fiocco annonce parmi les nouveautés un « managed k8s » et un « Hadoop database managed », tout cela tournant, bien sûr, sur OpenStack.

Il insiste ensuite sur quelques différenciants : OVH construit ses propres services dans ses propres usines, assemble ses serveurs ; les datacenters sont refroidis à l’eau (et non grâce à la climatisation) ; ils sont très attentifs à la transparence et à la réversibilité pour leurs clients, et bien sûr l’Open Source est au cœur de leur stratégie.

La conférence se termine par les remerciements à la communauté pour la qualité des développements.


Continuous Integration at scale running a Zuul CI cloud

Zuul est le projet d’Intégration Continue (CI) d’OpenStack. Il est utilisé par plusieurs acteurs majeurs tels que WikiMedia, Openlabs, OpenStack…

Son rôle est d’exécuter des jobs sur des VMs (appelées nodes) mises à disposition par Nodepool, un autre projet du scope OpenInfra. Ces nodes sont fournis par 16 cloud providers à travers le monde pour le développement d’OpenStack. Fait amusant, la CI de Zuul est gérée par… Zuul !

Cette présentation concernait le déploiement et le passage à l’échelle (scaling) de Zuul sur des machines Baremetal suite à la mise à disposition de machines par packet, un provider baremetal.

Pour être intégrées à Nodepool, celles-ci sont (dé-)provisionnées via Terraform, puis les composants élémentaires d’Openstack (Nova, Neutron, Glance..) y sont installés afin de permettre la création de nodes. En cas de problème sur une machine baremetal, Nodepool reçoit l’ordre de ne plus y créer de nodes (mauvais MTU, VM détruites consommant toute la RAM…). La durée de vie moyenne d’une node étant d’environ 2h, les machines baremetal sont rapidement dé-provisionnées.

En ce qui concerne le monitoring du cloud de CI, Nodepool fournit des KPI (Key Performance Indicators) plutôt intéressants tels que : le Time To Ready (temps nécessaire au démarrage d’une node/provisionnement d’une machine baremetal), le nombre d’erreurs lors de la création de nodes…


Doubler les performances vSwitch

[Note préalable pour bien comprendre la suite de l’article : NUMA = Non-Unified Memory Access.]

Chaque carte réseau, processeur et barrette de mémoire est connecté à un port NUMA particulier.
La communication entre des CPU/cœurs, la mémoire ou encore le réseau peut se faire entre deux NUMA différents par le biais d’un lien cross-numa. Cette communication inter-numa ralentit les communications et donc influe sur les performances.
Lorsque l’on souhaite de la performance, spécifiquement dans le domaine du SDN/NFV, il faut donc que les vCPU (pCPU) des instances soient sur le même port NUMA que la mémoire physique, de même que les cartes réseaux utilisées.

Pour répondre à cette problématique, différentes solutions sont possibles avec trois types de réseaux différents :
– Kernel vHost (virtio) : performances modérées et très haute flexibilité
– Userspace vHost (dpdk) : hautes performances et relativement flexible
– SR-IOV: très hautes performances, mais non flexible

La solution proposée lors de la conférence :
Pour les meilleures performances, utiliser SR-IOV. Ceci passe par une configuration de nova et neutron. Nova va permettre d’affecter des affinités inter-instances (placement) et d’effectuer du CPU pinning (forcer l’exécution sur un core particulier). Neutron va lui permettre l’association entre les interfaces physiques et donc permettre d’associer plusieurs NIC du même NUMA dans un bond par exemple. La configuration L3 permettra elle de définir l’IP et l’interface à utiliser pour le trafic.

Problématiques à traiter pour les prochaines versions d’OpenStack :

  • Eviter de se faire prendre des ticks CPU par l’hôte lui-même
  • La live migration ne fonctionne pas avec du CPU pinning et un contexte NUMA, mais cela devrait être corrigé dans nova d’ici quelques mois
  • Difficile à comprendre et débugger
  • Mettre des flags NUMA pour suivre ce qui se passe dégrade très fortement les performances

Automating Stateful Applications with Kubernetes Operators

Présentation par Marek Jelen (@marek_jelen) et Jorge Morales (@jorgemoraiespou) de RedHat.
La conférence part d’un constat simple : il est facile de mettre à l’échelle une application stateful, sachant qu’une application stateful a les besoins suivants :
  • Re-dimensionnement des noeuds
  • Reconfiguration
  • Mise à jour (application des patchs de sécurité qui sont critiques pour une application)
  • Sauvegarde
Les opérateurs Kubernetes permettent de manager l’ensemble de ces points dans un cluster Kubernetes (installation, configuration, gestion du cycle de vie de l’application).
Comment cela fonctionne-t-il ? En étendant les API de Kubernetes à l’aide des Custom Resource Definition et en développant un Application-Specific controller, ce dernier se chargeant d’implémenter les différentes méthodes (création, configuration…) de l’application.
La présentation était axée sur « l’operator-framework » SDK permettant de développer ses propres opérateurs k8s.
La présentation s‘est conclue par une démonstration de operator-framework de la création du CRD et différents exemples de code, pour finir par une démonstration de déploiement de l’operator etcd.

oslo.policy101

La conférence est une introduction à la gestion des droits d’accès des utilisateurs aux composants OpenStack.
Une fois OpenStack installé, le user admin est créé. Par la suite, il  est possible d’ajouter plusieurs utilisateurs avec différents droits d’accès, en lecture ou en écriture.
Pour cela, chaque service OpenStack possède un fichier nommé policy.json. Ce fichier est composé de plusieurs règles.
Pour bien comprendre les fichiers d’accès : un utilisateur a un rôle pour exécuter une action sur un objet.
Dans un 1er temps, il faut récupérer un token auprès de keystone pour s’authentifier sur la plateforme.
Une fois le token validé, dès qu’un utilisateur exécute une requête API, chaque service d’OpenStack appelle son fichier de contrôle situé dans /etc/<service>/policy.json 
Les notions d‘authentification et d’autorisation sont différentes : l‘authentification permet à un utilisateur d’accéder à des ressources alors que l’autorisation définit ce qu’on peut faire avec ces ressources. Ce fichier a son propre langage et est écrit en json ou yaml. Nous pouvons retrouver le fichier par défaut dans le code du composant.
Chaque règle se définit par une ligne de ce type: « <target> » : « <rule> » avec :
  • rule : la définition des conditions donnant droit à l’exécution
  •  target : l’objet et la méthode (list, get, create, …) concernés
Prenons par exemple la création d’un service avec keystone par l’utilisateur admin : « identity:create_service »: « rule:admin_required »
Si on veut tester des règles, on peut récupérer la policy par défaut du composant via la commande suivante : oslopolicy-policy-generator –namespace SERVICE NAME
ou avec la documentation : oslsopolicy-sample-generator –namespace SERVICE NAME
Une fois la policy modifiée avec nos propres règles, on peut tester ce fichier directement via la commande oslopolicy-checker.
oslopolicy-checker –policy /etc/keystone/policy.yaml –access ~/memberjson
oslopolicy-checker –policy /etc/keystone/policy.yaml –access ~/admin.json –rule volume:delete
Pour plus d’information sur le sujet des policy : https://docs.openstack.org/security-guide/identity/policies.html

Cinder Project Update

La présentation est un état des lieux et du futur de Cinder, le projet de gestion de volumes d’Openstack, présenté par Jay Bryant.
Cinder a profité de +150 contributions durant le cycle Rocky. Parmi les principales évolutions apportées :
  • Évolutions des drivers supportés (cf. la release note, lien en fin d’article pour plus d’informations)
  • QoS basée sur la taille des volumes
  • Retours sur la fonctionnalité de multi-attach de cinder :
    • Supportée depuis la microversion 3.50 de l’API
    • Attention, le backend de stockage doit supporter l’attachement en R/W sur plusieurs nœuds !
    • L’activation du multi-attach passe par le flag –multi-attach lors de la création du volume
    • Documentation de la fonctionnalité Actif/Actif de Cinder
    • Support du transfert des volumes AVEC les snapshots associés
    • Comportement par défaut inchangé
Pour en apprendre plus, la release note Rocky de Cinder est disponible ici –> https://docs.openstack.org/releasenotes/cinder/rocky.html#relnotes-13-0-0-stable-rocky

Et pour Stein ?

  • Support de l’actif/actif pour tous les services Cinder
  • Driver de backup générique pour sauvegarder des volumes de n’importe quel driver
  • Support de la suppression différée pour les volumes RBD
  • Support du iSCSI pour Ceph : sera très utile pour Ironic
  • Report des « capabilites » des différents drivers, pratique pour avoir une liste précise des fonctionnalités actuellement supportées. Et comme la majorité des projets Openstack : portage de Cinder sur le StoryBoard

Keystone Project Update

Une présentation succinte qui dresse  un état des lieux et évoque le futur de Keystone, le projet de gestion de l’identité d’Openstack.
Voici les ponts importants à retenir.
D’abord, pour la version Rocky, quelques changements ont été présentés : 
  • Création de oslo.limit, facilitant le calcul des quotas dans Keystone
  • L’API unified limit a été améliorée
  • paste[Deploy] a té supprimé 
Ensuite, on nous a présenté les grandes lignes du travail fait dans la vesrion Stein. En voici les points importants : 
  • lamélioration des policies par défaut
  • la mise en place d’un système d’authentification multi-facteurs (MFA)
Nous avons également eu une présentation des pistes pour la prochaine release :
  • Gestion multi-site
  • Une meilleure approche des upgrades
  • Un nettoyage du code (policies)
  • un proxy pour l’identity provider
Enfin, les initiatives cross-project:
  • Un effort continur d’être fait pour obtenir une convention de nommage des policy names
  • les rôles par défaut
  • l’adoption de limites unifiées

Pushing OpenStack and Ceph to the Edge, un état des lieux aujourd’hui

Le cloud distribué fait partie intégrante du standard 5G.
Le Edge Computing prépare à des cas d’usages variés : maisons connectées, voitures d’aujourd’hui et de demain, IoT…
Les contraintes sont assez lourdes : latence, bande passante, autonomie, scalabilité, déconnexions.
La question est donc : comment bénéficier des avantages technologiques d’OpenStack et de Ceph pour diminuer ces contraintes ?
Quelques éléments de réponse :
  • L’hyper convergence : mutualiser des rôles compute et de stockage par exemple
  • Déploiement en microservices
Les outils mis à disposition pour cela sont :
  • OpenStack TripleO
  • Ceph
Et l’architecture envisagée  :
  • Un plan de contrôle centralisé (Région)
  • des sites (PoP) au plus près du ‘edge’

Cela permet d’optimiser l’utilisation du matériel et de diminuer les latences. En effet les services et ressources sont au plus près de l’utilisateur final.

En guise de conclusion : OpenStack et Ceph permettent déjà de faire des choses, la version Stein d’OpenStack proposera des outils intéressants, mais il reste des contraintes : 

  • cinder Actif/Actif (cf. article sur Cinder)
  • glance-api : nécessité de gérer un cache d’images Glance au plus près du ‘Edge’ par ex.
  • Gérer les cas de déconnexion : prévoir une synchronisation ponctuelle de metadatas

 


Advanced Networking Sevices LBaaS

Présenté par AVI Networks
Quelques bases
La présentation a commencé par quelques rappels sur les principes du Load-Balancer-aaS mais aussi sur les applications qui ont un fort intérêt au Load-Balancer
  • Forte tolérance au pannes
  • Possibilité de se baser sur la géolocalisation de l’utilisateur (Geolocalisation based LB)
Mais pour mettre cela en place, certains défis doivent être relevés. En particulier :
  • Session persistante
  • Terminaison SSL
  • Limitation de bande passante
  • Authentification des utilisateurs
La fonctionnalité de Load balancer as a service à une longue histoire avec Openstack. Aujourd’hui le projet est sorti de Neutron et s’appelle Octavia, devenu le projet officiel d’Openstack.
Octavia :
  • Support de l’UDP en Rocky
  • Des statistiques sur tous les listeners
  • Des quotas sur les objets

Enfin la présentation a comparé le fonctionnent d’Ocatvia en utilisant comme backend HAproxy et  AVI

Octavia avec HAproxy :
Un processus HAproxy par Pool/VIP
  • tourne sur une VM (ou 2 si actif/passif)
  • limité pour la scalabilité
Octavia avec AVI:
  • Tous les composants d’Openstack passent par l’API AVI 
  • AVI crée automatiquement les Service Engine qui interconnectent les instances avec les contrôlleurs AVI
  • Possibilité d’avoir différents Service Engine (sur des tenant différents) afin de renforcer l’isolation
Conclusion:
Bien sur la conclusion de la présentation met en avant les intérêts de AVI, qui permet de fonctionner en Actif/Passif ou en Actif/Actif et de faire de l’auto scaling sur les LoadBalancers
  • ex:   si le  CPU> 80% ou Capacité disponible < 10% → Scale up 
AVI est 100% Manageable avec une API REST et propose une intégration avec Horizon afin de pouvoir avoir une vision end to end et une remontée de logs.
Ce projet semble complet mais malheureusement n’est pas OpenSource 🙁