12
mai

En direct de Boston jour 4 (et fin) !

Que retenir du dernier jour de l’OpenStack Summit de Boston ?

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 à Boston:
faites une pause OpenStack !

 

Au menu aujourd’hui :TasseVintage

Scheduler wars : la nouvelle API placement

Le service placement, devenu obligatoire sur un déploiement Nova Ocata, est encore assez méconnu. Jay Pipes, un des core développeurs de Nova, a expliqué les tenants et aboutissants de ce nouveau service.

Les problèmes

L’API placement tente de régler 4 problèmes :

  • les ressources nova sont suivies de manière incohérente
  • le reporting n’est pas correct pour certaines ressources (par exemple pour l’espace disque des nœuds compute)
  • les informations mêlent données qualitatives et quantitatives, ce qui rend leur utilisation difficile
  • les données de disponibilité et d’utilisation sont mélangées

L’API placement

C’est une API REST utilisée uniquement de manière interne pour le moment. A l’avenir certains éléments seront exposés aux utilisateurs.

Cette API offre une vue globale des ressources, utilisables et consommées.

Pour le moment, le code est attaché à Nova mais il deviendra autonome à terme.

Nouveau modèle de données

De nouveaux types de données ont été créés pour gérer les ressources :

  • resource classes : des éléments pouvant être comptés. Soit standard (vCPUs, RAM), soit custom.
  • traits : décrit un provider de ressource. Soit standard (HW_CPU_X86, STORAGE_DISK_SSD), soit custom. Les flavors seront associées à ces traits.
  • resource providers : inventaire de resource classes, avec optionnellement des traits.
  • inventories
  • allocations
  • aggregates

Développement futur

  • suppression des boucles de retry dans le scheduler nova
  • scheduling plus efficace
  • réduction du code sur les nœuds compute
  • réduction du nombre de messages vers le conductor et le scheduler

 

L’API placement devrait résoudre un bon nombre de soucis de scheduling et d’incohérences au niveau des quotas.

 


Securing OpenStack Clouds and Beyond with Ansible

Session intéressante sur l’automatisation de la sécurité dans OpenStack.

On en parlait dans notre précédent billet, et nous ne sommes pas les seuls à le penser: pour diminuer la complexité de la sécurité, il faut adopter la même approche que le devops et automatiser les contrôles.

 

Le but du projet OpenStack Ansible Security est d’appliquer automatiquement les meilleurs pratiques de sécurité dans OpenStack, tout en s’assurant de ne rien « casser ».

Le playbook s’appuie sur le standard STIG, traduit les règles XML en roles Ansible tout en désactivant celles dérangeantes pour OpenStack. Beaucoup de documentation et de tests fonctionnels sont mis en place pour s’assurer de ne rien casser.

 

Un de intérêts majeurs du playbook est la possibilité d’utiliser le playbook en stand-alone pour vérifier le niveau de durcissement de vos instances Linux (RedHat, Centos et Ubuntu).
Un cas d’utilisation évoqué est la création de golden images durcies dans Glance.

Un autre intérêt : lancer le playbook en mode audit read-only pour vérifier le niveau de sécurité de vos infrastructures.

Le playbook est inclus dans OpenStack Ansible depuis Mitaka et est activé par défaut dans Newton.

 

Pistes d’amélioration:

  • Intégration Suse, Amazon linux & RM
  • Intégration avec ARA pour produire des rapports d’audit

 


Comparing the Barbican and Vault Security Models

Le sujet était très attendu. La session vise à comparer des gestionnaires de secrets OpenStack Barbican Vs Hashicorp Vault.

Les deux gestionnaires sont open source et bénéficient de fonctionnalités intéressantes. Alors : lequel choisir ?

Voici quelques éléments à considérer :

  • La configuration de Vault est plus simple : pas besoin de base de données ou de bus de communication. On sent l’héritage d’OpenStack pour Barbican
  • Barbican ne peut pas détecter les altérations de ses informations dans la base de données
  • Vault dispose d’un nombre de plugin pour l’authentification/autorisation, mais rien de natif avec Keystone
  • Barbican fait de scaling horizontal alors que Vault déporte cette problématique sur le backend de stockage
  • Aucun des deux ne gère la réplication des données, c’est à vous de le faire
  • Le support HSM dans Vault est uniquement présent dans la version entreprise payante

Conclusion : si vous utilisez uniquement un environnement OpenStack, visez plutôt Barbican, et pour tout le reste il y a Vault.

 

A noter cependant : des développements intéressants sont en cours et pourraient faire évoluer cette conclusion :
– Vault comme backend de Barbican
– Keystone comme backend d’authentification/autorisation pour Vault

 


Monitoring et Analyse MultiCloud avec Gnocchi et Ceilometer

Cette conférence animée par Nubeliu est en fait une présentation du travail réalisé à la création d’un outil de monitoring et d’analyse multi-clouds (OpenStack, AWS, Azure et VMWare) avec Gnocchi et Ceilometer.
La conférence a commencé par présenter Gnocchi et son API : Gnocchi est la base de données time series issue du projet OpenStack ; Objectif Libre travaille beaucoup avec sur le projet CloudKitty). Alejandro Comisario a vanté les mérites de vitesse de la solution.
Une fois cette architecture exposée, il a présenté leur solution (Rocket) qui permet d’aller au-delà des métriques d’OpenStack en proposant une remontée de métriques venant VMware, AWS et Azure.

Les métriques sont stockées via Ceilometer dans Gnocchi, permettant d’avoir une seule source d’informations dans la plateforme de Nubeliu. Ces liaisons sont réalisées par des collecteurs, qui seront open sourcés prochainement. NDLR : à partir de là, il est possible de faire du chargeback/rating ou capacity planning avec CloudKitty.

Le but de la présentation est de montrer le monitoring et l’analyse analytique d’infrastructure. L’IHM est basée sur Horizon et plutôt agréable, mais n’est, elle, pas open-sourcée.

 


Ceph Project Update

Comme à chaque Summit, Sage Wail vient faire un état des lieux de Ceph et des prochains développements.

La prochaine version stable qui devrait être là d’ici cet été, et cela semble vraiment prometteur.

Au menu de luminous :

Rados

  • Bluestore est le backend de stockage par défaut: grosse amélioration de performances (x2 sur un HDD, x1.5 sur un SSD)
  • Disponibilité de la compression à la volée, de la vérification de checksum et de l’erasure coding sur les pool RBD
  • Un nouveau composant : ceph-mgr pour décharger les monitors de certaines fonctionnalités comme la gestion de métriques (pg-stats)
  • Ceph-mon redevient scalable
  • Une nouvelle API REST (Super nouvelle !) et d’un dashboard web intégré
  • Une nouvelle implémentation du messager réseau pour améliorer les performances
  • Les OSDs sont équilibrés automatiquement par la gestion des poids
  • Apparition de classe de matériel dans CRUSH (HDD, SSD,…)
  • Amélioration des performances (peering/recovery, fast failure detection)

RadosGW

  • Fédération multi-cluster
  • Stockage des métadonnées possible dans ElasticSearch
  • Nouvelle passerelle NFS
  • Compression à la volée
  • Chiffrement (suivant l’api S3)
  • Sharding automatique de l’index des bucket (quand il grossit)

Ceph-FS

Ceph FS est stable et « production ready » !
Gestion des multiples démons MDS (avec la gestion de sous arborescence dédié à un démon)

La version suivante : Mimic

Mimic :  « Google it, this cephalopod is amazing ». Nous vous laissons découvrir l’animal auquel il est fait référence…

La roadmap est la suivante :

  • Focus sur les performances, la facilité de gestion et la QoS
  • Amélioration des métriques dans ceph-mgr : possibilité d’envoyer les métriques (Prometheus), analyse prédictive de pannes, identification de matériel lent…
  • Déduplication
  • Gestion processer ARM
  • Disponibilité de cache client

 


Des VMs disponibles en quelques secondes

Un titre prometteur… et une conférence à la hauteur ! Le speaker a expliqué sa façon de fonctionner pour rendre disponibles des VMs en environ 3 secondes top chrono.

Le nombre d’étapes nécessaires lors de la création d’une VM rend souvent le processus de création plus long qu’il ne devrait l’être pour le boot d’une simple VM : appels d’API, scheduling, prise en main par libvirt et enfin boot de la VM.

La société Chinac a fait le choix de réduire au maximum ce temps de traitement, en ce focalisant sur l’optimisation du lancement de la VM (et non des appels d’API & scheduling).

Le principe de base ? Une VM en assemblage d’un certain nombre de ressources (CPU, Mémoire, disques, NIC). En l’état actuel, OpenStack ne supporte pas l’attachement à chaud des ressources CPU et mémoire, et c’est ce que Chinac propose de supporter pour accélérer la création des VMs.

 

Leur mode de fonctionnement diffère légèrement de celui d’OpenStack :

  1. Demande de création d’une VM avec une image et un flavor spécifiques
  2. Lors de la création de la VM, c’est un live upgrade d’une VM pré-existante qui est effectué. Lors de cette opération, des ressources supplémentaires sont attachées
  3. Modification des informations spécifiques à la nouvelle VM obtenue (hostname, utilisateurs, mots de passes…)

 

Fin de la présentation avec une démonstration en direct, et qui fonctionne ! Une VM est effectivement disponible en à peine 3 secondes.

Actuellement, le code produit pour cette fonctionnalité reste privé chez Chinac, mais d’après leur speaker il sera très vite proposé à la communauté.

 


Kolla project update

Le projet Kolla propose de déployer OpenStack dans des conteneurs.

Le projet se décompose en 2 parties :

  1. Le projet core Kolla : build des images Docker
  2. Les projet de déploiement : kolla-ansible et kolla-kubernetes

 

Nouveautés Pike Kolla :

  • Encore + de nouvelles images (et donc de projets intégrés à Kolla)
  • Des images poussées sur DockerHub quotidiennement : les versions stables et l’upstream

 

Nouveautés Pike Kolla-ansible :

  • + de rôles, donc + de projets supportés
  • Amélioration des tests : tests d’upgrade et tests multinodes
  • Documentation : Michal Jastrzebski a insisté sur le fait que la solution manquait de documentation en terme de cas d’utilisations et de tutoriels. Un appel est lancé à toute personne ayant testé kolla-ansible (production ou tests) pour remonter les éventuels bugs ou améliorations à apporter

 

Nouveautés Pike Kolla-kubernetes :

  • Utilisation du package de templating k8s HELM
  • Travail sur l’architecture microservices, et utilisation de « chart » (équivalent de package pour HELM) pour facilité les déploiements
  • Amélioration des tests (tests multinodes principalement)
  • Facilitation des upgrades de sécurité et du passage d’un OpenStack existant à kolla-kubernetes.