OpenStack Hall

Jour 3 – et dernier jour

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.

  • Mistral – Project update
  • Masakari Project Update
  • Octavia – Project update
  • Kata containers – project update
  • Cinder volume encryption
  • Are you secrets secure?
  • Science Demonstrations: Pre-emptible Instances at CERN and Bare Metal Containers for HPC at SKA
  • Ceph data services in a multi and hybrid cloud world

Bonne lecture !

 


Mistral – Project update

Présenté par Adriano Petrich de RedHat

Mistral est le projet de Workflow as a Service. Il permet aux utilisateurs de définir des actions personnalisées, déclenchées par des événements.

Nouveautés Rocky:

  • Ajout des service d’exécution d’événements et de notification :
    • Utile pour l’exécution de longs workflows
    • Supporte uniquement les webhooks
  • Nouvelles actions pour divers projets (Tacker, Vitrage, Manila, Qinling & Zun)
  • Améliorations :
    • Cache des définitions des actions (moins de requêtes en BDD)
    • Meilleure gestion du RPC et des connexions aux BDD
    • Gestion des std.email, cc, bcc et formatage html
  • Résilience et administration :
    • Ajout de mécanismes de détection d’actions en erreur
    • Ajout d’un paramètre « force » pour la suppression des exécutions en erreur
  • Généralisation des namespaces aux workbooks

Prévisions pour Stein:

  • Importantes améliorations des performances et de la gestion de la mémoire (gain x2 pour certaines exécutions en parallèle)
  • Analyse de workflows en erreur
  • Fin de l’implémentation du nouveau scheduler (amélioration du scale-out de Mistral)
  • Arrêt « propre » des services mistral engine (amélioration du scale-down de Mistral)
  • Amélioration de la résilience de Mistral face aux pannes d’infrastructure
  • Et enfin, amélioration de la documentation

Et pour la suite ?

  • Rendre Mistral plus stable, mieux distribué et plus performant
  • Intégrer Mistral avec des technologies externes telles que Kubernetes ou Ansible (AWX)
  • Gérer la problématique de « blocking-mode », déprécié par oslo.messaging.

Aucune question dans l’assemblée, la présentation était claire et complète.


Masakari Project Update

Maskari offre la possibilité aux utilisateurs de mettre en place de la haute disponibilité sur les computes et instances.
Si une erreur survient – un crash, un nœud qui devient non disponible – Masakari rétablit la disponibilité en migrant les instances suivant la configuration choisie.
Les instances en erreurs ne seront, elles, pas migrées.
Nouvelles fonctionnalités sur Rocky
  • Interface Masakari avec Horizon
  • Plugin Ansible
  • Refonte du workflow sur les méthodes de récupération
  • Ajout de la fonction db_purge
  • Ajout du reload sur le service de Masakari
A venir pour Stein:
  • Implémentation des notifications sur les événements
  • Utilisation de la commande STONITH qui permet d’éteindre un noeud compute par le biai de SSH, IPMITools et autres
  • Développement du support d’Ansible
  • Déprécier le client Masakari
  • Mettre à disposition une DevStack pour installer Masakari et lancer les moniteurs dans un environnement multi-nœuds

Octavia – Project update

Présenté par Carlos Goncalves et German Eichberger
Nouveautés Rocky:
  • Possibilité d’ajout de drivers tiers compatibles API v2
  • Support du protocole UDP
  • Ajout de membres « backup » dans les pools
  • Dashboard Octavia :
    • Ajout d’en-tête HTTP
    • Mise à jour du statut d’un load balancer automatique (« Pending create » → « Active »)
  • Réduction de la taille des images Amphora (base Ubuntu)
  • Gestion automatique des ACLs dans Barbican lors de l’utilisation de certificats
  • Outils d’aide à la migration neutron-lbaas (cf. Article « LBaaSv2 to Octavia » Jour 2)
Prévisions pour Stein:
  • Gestion des gabarits
  • Mise en place du standard « CADF » (Cloud Auditing Data Federation)
  • Support des politiques « REDIRECT_PREFIX » (L7)
  • Authentification par certificat client
  • Amélioration des ciphers TLS et protocoles supportés
  • Re-chiffrement à la volée des backend (« Backend TLS re-encryption »)
  • Plus de tests sur IPv6, UDP et TLS-offload
Et pour la suite ?
  • Support de l’actif/actif, avec auto-scaling !
  • Health-monitor:
    • Vérification de contenu
    • Support de plus de protocoles
  • Intégration avec le FWaaS d’OpenStack
  • Fin de vie de neutron-lbaas (Septembre 2019)

Pour terminer, l’équipe Octavia présente les travaux inter-projets actuellement en cours :

  • Amphora dans les conteneurs (intégration avec le projet Zun)
  • Support du FWaaS (avec Neutron)
  • Travail avec Keystone sur l’intégration des rôles par défaut (RBAC)
La séance se conclut sur une question concernant le support de plusieurs zones de disponibilité dans Octavia :
  • Octavia ne souhaite pas jouer le rôle du scheduler Nova
  • Un patch est cependant disponible, à tester.

Kata containers – project update

Ce « project update » a été présenté par Samuel Ortiz (intel), aidé par Xu Wang (HyperHQ)

Qu’est-ce que Kata containers ?

L’objectif principal du projet kata containers est de permettre de démarrer des conteneurs dans un environnement sécurisé et plus précisément d’améliorer l’étanchéité des pods.
Pour cela, une VM est bootée avec un kernel optimisé servant à exécuter l’ensemble des conteneurs du pod. Kata conteneurs gère plusieurs types de conteneurs et ne se limite pas à Docker. Le kernel utilisé est un kernel linux classique permettant de lancer les conteneurs disponibles sur les hub sans modifications, contrairement aux solutions basées sur de l’unikernel. Kata est actuellement en version 1.3.

Qu’est-ce que NEMU ?

Pour optimiser la sécurité des VMs, QEMU a été ré-écrit afin de minimiser les vecteurs d’attaques. NEMU est compatible avec QEMU et ne comporte que les fonctionnalités nécessaires à l’exécution des VMs kata ; beaucoup ont donc été retirées. NEMU peut être utilisé avec toutes les architectures courantes en production, et peut remplacer QEMU sur ces usages. Il est donc utilisable avec OpenStack ou dans un environnement Kubernetes.
Quatre axes ont été présentés.

1. Sécurité

La sécurité étant au cœur du projet kata, elle reste un point important d’amélioration continue.

  • La technologie seccomp (filtrage des appels systèmes) a été implémentée pour la version 1.4.0
  • NEMU arrivera en version 1.4.0 également
  • La virtualisation matérielle de génération aléatoire est arrivée en version 1.3.0

2. Complexité/Opérabilité

  • VSOCK a été implémenté en version 1.2.0. vSock facilite la communication entre les machines virtuelles et leur hôte
  • Le ‘distributed tracing’ arrivera lui en version 1.4.0. Il s’agit de surveiller l’activité générée par une requête sur l’ensemble des composants d’une application
  • La mise à jour à chaud (live upgrade), toujours en développement, est prévue pour la version 1.5.0. Cette fonctionnalité est très demandée par les différentes utilisations en production
  • Containerd-shim v2 est également en développement et devrait être présent en 1.5.0. Shim fait partie de l’interface entre kube et les conteneurs. La version 1 oblige la création de deux conteneurs dédiés à cet usage par pod lancé. Ceci crée une surconsommation de ressources et un ajout de complexité ayant un impact direct sur la sécurité (vecteurs d’attaques). Containerd-shim v2 permet de n’avoir qu’un seul conteneur shim par pod. Cela diminue donc drastiquement l’empreinte de shim sur le système.
3. Performance
Un des challenges de cette solution réside dans la minimisation de l’empreinte qui peut être engendrée, essentiellement en terme de RAM et de temps de boot.
  • Les templates de VMs ont été introduits en version 1.2.0. Ces templates de VMs sont des « snapshots » de VM en cours de démarrage. Lancer d’autres VMs depuis ces templates permet d’améliorer le temps de démarrage. Le temps de démarrage d’un container dans kubernetes annoncé est de l’ordre de la vingtaine de secondes, alors qu’une VM kata est de l’ordre de la seconde. L’overhead dans ce cas est donc minime par rapport au temps de kubernetes.
  • Le TC mirroring arrivera en version 1.4.0. Cette fonctionnalité permettra d’améliorer la couche réseau entre les conteneurs et l’hôte hébergeant les VMs kata.
  • NEMU arrivera en version 1.4.0. Même si l’objectif premier de NEMU réside essentiellement dans la simplification de QEMU pour des raisons de sécurité, cette simplification amène un gain de performances. Les VM sont démarrées avec moins de périphériques et ont donc moins d’actions liées à effectuer.
4. Multi-architecture 
Bien que kata conteneurs ait été créé par Intel (essentiellement HyperHQ), il est important pour le projet de ne pas effectuer un vendor locking sur les architectures Intel. Depuis la première version du projet, l’architecture ARM 64bit est maintenue et complètement supportée par la communauté. Le support de l’architecture PPC64 est été ajouté en version 1.1.

Cinder volume encryption

Dans cette présentation, Cinder propose de parler de la nouvelle feature qui a été implémentée concernant la protection des données, suite à une forte demande des utilisateurs et entreprises.
Le fonctionnement actuel : 
  • L’utilisateur demande une création de volume
  • Cinder crée le volume, ajoute les informations dans sa base de données et ajoute la clé de chiffrement.
Comment insérer cette clé ?
Jusqu’à présent (Queens), Cinder utilisait un manager de configuration de clé.
Avec Rocky, le projet offre la possibilité d’intégrer Barbican pour la gestion des clés avec l’aide de son manager de clé Castellan.
Eric Harney indique des bugs sur cette partie, qui sont cependant en cours de résolution, voire résolus pour certains.
Pour rappel, Barbican est un projet OpenStack permettant la gestion des secrets.
Cinder a mis en place un chemin de migration des clés de la base de donnée de Cinder à celle de Barbican et a ajouté de nouvelles métadonnées sur les volumes.
Nouveauté aussi avec Cinder sur Rocky :
  • Le support de Ceph RBD
  • Intégration du chiffrement avec les images Glance

Are your secrets secure?

Par Dave McCowan (Cisco) et Ade Lee (Red Hat et PTL de Barbican)
Barbican est le composant qui permet de gérer des secrets dans OpenStack.
Pourquoi utiliser un gestionnaire de clé comme Barbican ?
  • Pour stocker des mots de passe (passphrases)
  • Pour stocker des clés de chiffrement
  • Pour stocker des certificats TLS/SSL
  • Pour récupérer des logs d’accès au niveau des clés (qui a utilisé quelle clé ?)
  • Pour générer des clés de chiffrement « fortes »
  • Pour fournir une interface à du matériel de stockage (Hardware Security Module)
Barbican permet d’adresser ces différents besoins.
Le talk s’est ensuite concentré sur les différents besoins en terme de conformité :
  • GDPR : droit à l’oubli 
  • ANSSI : séparer les clés d’administration et la gestion du stockage
  • Les critères communs : chiffrement fort et journaux d’accès
Pour répondre à tout ces besoins, Barbican s’intègre avec un backend. Une liste des backends disponibles a été énumérée lors du talk :
  • SimpleCrypto : Par défaut, un hash est utilisé dans la configuration et les secrets chiffrés avec ce hash sont stockés en base de données. Ce backend ne répond en aucun cas aux différents critères de sécurité cités plus haut, mais est facile à déployer.
  • PKCS#11 : Recommandé ; les secrets sont toujours stockés en base de données et PKCS répond à tous les critères de conformité. Néanmoins ce backend est compliqué à déployer et coûteux.
  • SGX : Solution développée par Intel, les secrets sont également stockés en base de données, le code de ce backend n’est pas présent dans les dépôts du projet et n’est donc pas testé par la CI d’OpenStack. Pour contourner ces problèmes, l’utilisation de PKCS#11 est une bonne alternative, et du travail est en cours pour la prochaine release (Stein).
  • KMIP : Premier backend où les secrets ne sont pas stockées en base de données. L’inconvénient de ce backend est qu’il n’est plus maintenu.
  • Dogtag : Ce driver répond aux critères de conformité quand il est couplé à un HSM, néanmoins il peut être utilisé sans HSM sur CentOS/RHEL.
  • Vault : Un des derniers plugins qui a vu le jour et qui commence à disposer d’un bon niveau d’intégration dans Barbican ; il permet d’utiliser en backend la solution d’Hashicorp vault. Le plugin devrait être amélioré pour la release Stein.
Le talk s’est conclu sur le fait que l’utilisation de simple_crypto est mieux que rien – « better than nothing ». Cependant, pour disposer d’un niveau de sécurité acceptable et répondre aux différents critères de conformité, un HSM est nécessaire.

Science Demonstrations: Pre-emptible Instances at CERN and Bare Metal Containers for HPC at SKA

Présenté par Belmiro Moreira, John Garbutt et Theodoros Tsioutsias

Le CERN essaye de faire revivre le Bigbang afin de comprendre exactement ce qu’il s’est passé. C’est entre autres pour cela que le Large Hadron Collider (LHC) a été conçu. En 2024, ses capteurs seront remplacés par d’autres, plus performants. Ceux-ci induiront un volume de données environ 10x plus important.

D’autre part, le Square Kilometre Array (SKA), le plus grand téléscope du monde, rencontre des problématiques similaires. En effet, il est prévu que celui-ci génère environ 148To de données à la seconde (!).

Cela nécessite d’optimiser l’utilisation de l’infrastructure existante. Pour répondre à ce besoin, deux solutions ont été présentées via une démonstration vraiment wunderbar:

  1. Les instances pré-emptibles, qui seront détruites en cas de manque de ressources (équivalent aux spot instances EC2).
  2. Les conteneurs sur baremetal, via Magnum, Ironic et Manila.

Les conteneurs baremetal peuvent être utilisés avec des composants OpenStack non modifiés. En revanche, deux modifications ont été nécessaires pour les instances préemptibles :

  • Un nouvel état a été ajouté à Nova lors de la création d’instances : PENDING. Celui-ci signifie que l’instance sera créée une fois les ressources libérées.
  • Un orchestrateur, nommé Aardvark, a été développé. Il fonctionne de la manière suivante :
    • Une instance ne peut pas être créée. nova-scheduler envoie une notification « No valid host » sur la file RabbitMQ
    • L’instance passe dans l’état PENDING
    • Aardvark intercepte la notification, et termine un nombre d’instances préemptibles adéquat.
    • Une fois les ressources libérées, Aardvark notifie Nova afin de reconstruire l’instance en état PENDING

Cerise sur le gâteau, cette mécanique fonctionne également pour le redimensionnement d’une instance.

Nous vous invitons absolument à regarder la vidéo des démos lorsque celle-ci sera disponible :
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22438/science-demonstrations-preemptible-instances-at-cern-and-bare-metal-containers-for-hpc-at-ska


Ceph data services in a multi and hybrid cloud world

Présenté par Sage Weil, Ceph Project Leader
Sage Weil, Ceph Project Leader, nous a rappelé les fondamentaux de Ceph : un système de stockage unifié, basé sur RADOS.
Le rythme des nouvelles sorties est désormais fixé à 9 mois, ce qui promet des implémentations rapides des nouvelles fonctionnalités.
La présentation a détaillé les efforts actuels pour répondre à ces 5 scénarios futurs :
  1. tiers multiples (SSDs, HDDs par ex.)
  2. mobilité
  3. reprise d’activité
  4. stretch : co-existence de données sur plusieurs sites
  5. compatibilité avec des cas d’usage ‘edge’

Stockage en mode bloc

 Au niveau du stockage en mode bloc (RBD), plusieurs possibilités existent à l’heure actuelle :

  • disposer de plusieurs tiers
  • depuis la dernière version stable de Ceph (nautilus), migrer un pool d’un tiers à un autre en live. Exemple : passer d’un pool HDD à un pool SSD Erasure Coding sans perte de service
Ceph peut répondre à un cas d’usage relatif à la mobilité des utilisateurs, et donc des applications : elles peuvent bouger alors que les données, elles, doivent rester accessibles partout. On a donc la possibilité d’utiliser un ‘stretched pool’ – un pool extensible. Cela nécessite néanmoins une bande passante importante sur un lien WAN et une latence la plus faible possible.
Ce pool étendu, multi-sites, peut également servir de manière transitoire pour migrer à chaud des données entre plusieurs pools, qui eux sont mono-sites.
Ce mode de fonctionnement (mode étendu) ouvre des possibilités. Malheureusement, elles dépendent de facteurs qui peuvent lui nuire. Comment à la fois disposer d’une bande passante importante, à faible latence, couvrant des lieux éloignés ? C’est quasi-impossible.
Il faut donc trouver d’autres approches. Continuons !
Il est possible de répliquer des pools de manière asynchrone. Si un pool n’est plus accessible, un backup est disponible et permet la reprise d’activité rapide, en ne perdant que les dernières écritures (quelques secondes). Notons qu’OpenStack prend cela en charge de mieux en mieux à chaque nouvelle version depuis Ocata, mais il reste des points problématiques notamment pour les volumes multi-attachés.
Des points de blocage existent également avec les outils d’orchestration IaaS. Il est en effet difficile de re-provisionner une application sur un nouveau site car il faut définir ce processus comme une partie à part entière de la stack (outils, workflows). La couche de stockage ne peut pas assumer ce processus à elle seule.

Stockage en mode fichier

Qu’en est-il du stockage en mode fichiers ? Permet-il de répondre à l’ensemble des questions posées ?
CephFS est capable de s’étendre (stretch), tout comme RBD, mais avec les mêmes limites, voire plus : latences, bande passante, notamment pour les process MDS. Pour la reprise d’activité également, des solutions existent : les snapshots, qui vont pouvoir garantir l’intégrité des données, mais là aussi il y aura un problème de synchronisation des données en ‘temps non-réel’. C’est acceptable dans certains cas, pas dans d’autres : les bases de données supporteront-elles ce mode-là ? [SPOILER : probablement pas !]
Pour garantir la mobilité, plusieurs cas d’usage sont envisagés :
  • Migration à froid (stop, move, start). Temps de perte de service énorme, accès exclusif préservé.
  • Pré-staging (on réplique les données pendant que l’appli tourne, on l’arrête pour copier les dernières données et on la fait reprendre sur le nouveau site). Moins de temps de perte de service. Accès exclusif préservé.
  • Actif/Actif temporaire : on active la réplication bidirectionnelle pour pouvoir démarrer l’appli sur un site supplémentaire. Lorsque la réplication est terminée, on stoppe l’appli sur le site initial et on désactive la réplication.
  • Haute disponibilité : réplication bidirectionnelle et application disponible sur plusieurs sites.
Dans ces cas, les problèmes se posent sur la réplication bidirectionnelle. Dans un scénario idéal, les applis sont coopératives et n’écrivent pas les mêmes données en même temps; malheureusement, dans la quasi-totalité des cas, c’est le dernier qui écrit qui gagne…

Stockage en mode objet

Il faut là encore trouver une autre solution. Pourquoi ne pas utiliser le stockage objet ? 
Sur le papier, le stockage objet propose nativement des accès en mobilité (HTTP, cache, proxies, CDN) et sa scalabilité horizontale est également un avantage.
Pour le créateur de Ceph, l’avenir sera fait de stockage objet. Pour autant, les stockages en mode fichier et bloc ont encore de beaux jours devant eux. Les cas d’usagse où les données ont besoin d’accès exclusif, les applicatifs en mode fichiers, avec des besoins en performances, sont encore légion. Cependant, les données de nouveaux modèles applicatifs résideront dans les objets : vidéo-surveillance, imagerie médicale, données du génome, photos de chats (sic).
Un modèle de fédération des gateway rados (RGW) émerge. Un découpage est proposé, permettant de répliquer efficacement différents pans de données, regroupées ainsi : Zones, ZoneGroup, Namespace. Des ZoneGroup peuvent ainsi être étendues (stretched) sur plusieurs clusters.
Pour bénéficier d’une disponibilité active/active, les données ainsi réparties sont par exemple accessibles en NFSv4. D’autres plugins existent :
  • elasticsearch
  • synchronisation cloud (réplication d’un bucket RGW sur du S3)
  • Archive : réplication de toutes les écritures d’une zone sur une autre en préservant les versions
  • pub/sub : souscription aux événements (une notification lorsqu’un PUT est intercepté par exemple)
Dans un environnement cloud, pour le moment ce type de réplication est géré du cluster RGW vers le cloud; Sage Weil prédit le contraire pour demain.
Pour répondre à la problématique du tiering pour RGW, des solutions existent : on peut créer plusieurs pools pour une zone RGW, un pool rapide servant les « heads » des objets afin d’en accélérer la recherche. On peut également définir une politique de tiering vers un stockage objet externe (typiquement, du S3). Plus tard, on imagine bénéficier du chiffrement des données et de la compression par exemple.
Sage résume sa vision présente et future du stockage objet : RGW sert de gateway sur un cluster RADOS, permettant de rediriger les requêtes des clients vers la bonne zone, propose une réplication au niveau de la zone. Plus tard, RGW servirait de gateway vers un maillage de sites avec un gain sur les performances, pourrait rediriger ou servir de proxy pour acheminer les requêtes vers la bonne zone, avec éventuellement du cache au niveau d’un proxy local. Enfin, la réplication pourrait être gérée plus finement, au niveau du bucket.
Enfin, nous abordons la problématique du ‘edge’. Ses contraintes obligent à re-définir le stockage : clusters plus petits, avec une architecture variée (aarch64), des liens WAN instables…
Pour satisfaire ces besoins émergents, encore une fois RGW semble être l’outil le plus prometteur : des zones locales peuvent absorber les requêtes et la réplication peut s’opérer lorsque le lien le permet. Il faut également réfléchir à des moyens de cacher certaines données localement. 
Conclusion
Le stockage de données est en constante évolution. Ceph apporte déjà quelques solutions aux défis de demain (multi-cluster). Les efforts sont ciblés sur le stockage objet, RGW deviendrait la gateway d’un réseau fédéré de sites de stockage, piloté à l’aide de politiques de placements des objets, de migration des données. Kubernetes peut éventuellement remplir certaines fonctions d’orchestration d’une telle architecture. À suivre !
Pour en savoir plus, guettez la mise en ligne de la présentation et des slides associés :