Pause Cloud & DevOps

Pause Cloud & DevOps – édition spéciale OpenStack Summit Denver 2019

Jour 3

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

  • Openstack and Ceph – Better Together!
  • Magnum project Update
  • Loadbalancers : new features
  • Self-healing on network failures with Vitrage, Mistral and Heat
  • Designate project update
  • Cloudkitty project update

Bonne lecture !

Openstack and Ceph – Better Together!

Il s’agissait d’une session de discussion autour de Ceph et son intégration avec OpenStack. Nous allons donc passer en revue les différents points qui ont été abordés pendant cette discussion.

D’abord en ce qui concerne les méthodes de déploiement, la quasi-totalité des participants utilise ceph-ansible. Quelques personnes déploient toujours avec ceph-deploy, outil en passe d’être déprécié.

Retour d’expérience sur le déploiement et/ou la conversion de Filestore à Bluestore : Pour quelques personnes présentes, des soucis de performances ont été remontés. Il faut absolument déporter la partition WAL/RocksDB sur un autre disque

En ce qui concerne le tuning et les performances, pas mal d’avancées portées par les disques NVMe.
Les disques NVMe offrent des performances en IOs très importantes. On peut maintenant allouer plusieurs OSDs par disque physique. C’est prévu dans le playbook ceph-ansible (osds_per_device). Prévoir 3 vCPU par OSD avec 4 OSDs par disque NVMe.
Beaucoup de participants indiquent utiliser les fonctionnalités NUMA. Il s’agit d’allouer des zones de mémoire à des CPU. On peut ainsi allouer des CPUs à des OSDs et obtenir des gains de performances très importants.

Un dernier point soulevé lors de la session concerne la conteneurisation des différents process de Ceph. Cela fonctionne très bien mais pour beaucoup les conteneurs n’apportent pas de simplicité particulière.

Magnum project Update

Magnum, c’est quoi ?

Magnum fournit une API qui permet la création de clusters de containers. Magnum bénéficie des outils OpenStack pour par exemple la gestion des droits d’accès (Keystone) ou bien la gestion des secrets (Barbican)
Pour créer un cluster, on utilise un template dans lequel on spécifie notamment la flavor, la distribution utilisée, et le pilote réseau. On paramètre ensuite le nombre de master nodes et de worker. Les clusters sont déployés comme des stacks Heat.

Magnum est compatible avec 3 opérateurs de cluster : Kubernetes, Swarm et Mesos. Il permet leur installation sur un certain nombre de systèmes d’exploitation : fedora-atomic, CoreOS, Ubuntu et Centos.
Les déploiements de clusters se font sur des machines virtuelles ou bien sur des noeuds Bare Metal. Magnum dispose également de fonctionnalités de scaling (up et down)

Du côté des utilisateurs, on peut distinguer 2 groupes :

  • operators : gèrent les templates
  • users : créent les clusters à partir des templates

project update

Voici les points qui ont été abordés :

Amélioration des APIs :

  • ajout d’une commande pour redimensionner le cluster (cluster resize)
  • possibilité de renommer les cluster-templates
  • utilisation possible d’un champ hidden dans le cluster-template
  • Health status : Magnum demande régulièrement les informations à Kubernetes sur son état de santé

Cluster resize pour supprimer un node spécifique du cluster

Gestion de nodegroups : permet le déploiement et la gestion de clusters hétérogènes en les regroupant (machines GPUs, machines physiques, différentes flavors, etc…)

Autoscaling : si un pod ne peut pas être schedulé, l’autoscaler provisionne des nouveaux nodes à la volée

Des Add-ons pour les controlleurs Ingress sont désormais disponibles :

  • traefik
  • octavia
  • nginx

Upgrades des clusters : 2 méthodes : in place ou node replacement. C’est en cours de finalisation.

Objectifs pour Train :

  • finaliser nodegroup integration
  • améliorer les process d’upgrade de cluster
  • rotation des secrets

Objectifs pour la suite : python3 et l’upgrade checker framework (comme sur les autres projets OpenStack)

Loadbalancers : new features

Octavia est le projet de load balancer pour OpenStack et non ce n’est pas pas un projet Neutron ! Fondé en Juno.
Les nouveautés depuis plusieurs cycles sont présentées:

Depuis Rocky

  • Backup members : L’ajout des backup members permet de faire un retour d’une page statique au lieu d’une erreur 503 lorsque tous les membres d’un pool non backup ne peuvent pas être utilisés. Ces « sorry servers » peuvent être dans une autre région ou un autre cloud !
  • Listener Timeouts : plusieurs listener timeouts ont été rajoutés pour permettre aux utilisateur de définir différents types de timeout (comme « timeout_client_data  » timeout de l’inactivité d’u frontend ou « timeout_member_connect » sur l’inactivité d’un membre). Ils sont utiles pour des connexions/sessions longues par exemple
  • Providers drivers : permet d’utiliser des backend différents pour le moteur de load blancing. Actuellement : amphora, octavia et ovn (qui est en développement).
  • UDP Protocol load balancing: L’ajout de load balancer pour des requêtes UDP est important pour l’IoT. Un nouveau système de health monitor est également suivi. Le suivi de session est possible en fonction de l’adresse SOURCE_IP . Pour ce load-balancer un nouveau type de monitor (UDP-CONNECT a été rajouté. Attention il n’est pas possible de mélanger les membres IPv4 et IPv6 ici.
  • Dashboard amélioré: les informations d’états sont mises à jour en temps réel. Des panneaux (tabs) ont été ajoutés pour faciliter la navigation entre les objets

Depuis Stein

  • Custom Flavors : La possibilité de créer des custom flavors pour les load-balancer, demandée depuis longtemps a été implémentée en Stein. Cela était nécessaire pour permettre à chaque driver d’exposer un ensemble de « capabilities » qui seront configurées dans les flavors.
    Pour réaliser cela un mécanisme de profil a été rajouté, avec la définition des capabilities à l’intérieur. Puis la flavor va être créée en liant la flavor à ce profil.
  • TLS client authentication a été rajouté. C’est bien sûr utile pour l’IoT mais aussi pour des applications pour permettre la validation des certificats clients par le LB lors des requetes sur la VIP. Certaines règles L7 ont été rajoutées en rapport avec cette fonctionnalité. Il est également possible de rajouter des headers relatifs au SSL qui peuvent être passés aux membres du LB pour leur indiquer l’état de la connexion.
  • TLS backend est une fonctionnalité qui permet des connexions TLS vers les membres du pool. L’ensemble des éléments de certification sont stockés dans un dépôt de type Castellan comme Barbican.
  • Object Tags, permettent de définir des labels sur les objects des load balancers. Les tags étant ensuite utilisés pour filtrer les résultats retournés par l’API (limiter au BLUE ou GREEN par exemple)
  • L7 Policy REDIRECT_PREFIX permet aux utilisateurs de rediriger vers une URL différente sans changer le PATH ou diriger des requêtes HTTP vers HTTPS par exemple..

Self-healing on network failures with Vitrage, Mistral and Heat

Cette conférence nous est présentée par Ifat Afek, Rico Lin et Danny Lahav.

Ils nous montreront comment les projets Vitrage, Mistral et Heat peuvent permettre de déployer une application « self-healing ».

Définitions des projets Openstack utilisés

Vitrage : permet d’analyser la root cause d’un incident.
Mistral : permet la création de workflows, déclenchés en fonction d’événements.
Heat : permet de manipuler des ressources OpenStack sous forme de template.

Mise en situation

Après l’explication des différents composants utilisés, ils nous proposent une démonstration

Une perte de la connectivité réseau est simulée sur un compute suite à un incident sur une carte réseau.

Mais avant cela, nous devons déployer une infrastructure minimaliste pour la démo.
Pour cela, ils utiliseront une stack Heat qui contient une instance , un template Vitrage et un
Workflow Mistral.

Dans le template Vitrage, il est indiqué qu’en cas de problème réseau, on exécutera le workflow Mistral
qui permettra de migrer l’instance dans un autre compute.

Lors de la simulation de la panne, Zabbix (solution de monitoring) remonte une alarme et déclenche une alerte dans Vitrage.

root cause:
L’instance est injoignable –> le compute a perdu le réseau –> la carte eno3 est défaillante.

L’événement étant remonté à Mistral par Vitrage, l’action qui suit est la migration de l’instance.

Résultat:
L’instance est de nouveau joignable.

Évidemment, l’instance est de nouveau mais pas le compute. Il reste alors à solutionner le problème du compute par l’administrateur.

En résumé

Il est facile de créer ses propres scénarios. Il n’y a pas besoin d’apprendre un nouveau langage.
L’utilisation de Vitrage permet d’identifier rapidement la root cause d’un problème.
Ainsi grâce a l’utilisation de la triplette Vitrage-Heat-Mistral, nous pouvons aisément créer une infrastructure « self-healing ».

Designate

Designate est le composant OpenStack pour le DNSaaS.
Ce projet a débuté en 2012 et a été intégré dans HP Public Cloud en 2013 puis dans la release Liberty.
Graham Hayes (PTL du projet ) nous présente les différentes fonctionalités sur Rocky et sur les prochaines releases.

Rocky :

  • Support de python3

Stein :

  • Fix de problème avec Python3.7
  • Résolution de problèmes de base de données concernant les DeadLock
  • Modernisation de l’utilisation de oslo messaging

Train :

  • Support de l’IPv6
  • Support WSGI pour designate-api
  • Partage de zone

Concernant le partage de zone, il sera possible de donner 3 types de droits :

  • READ
  • WRITE
  • SUBZONE

Ce dernier type de droits, subzone, permmetera aux projets de créer des sous-zone DNS sans modifier les zone principale.

Pour Graham Hayes, cette convention sera la dernière pour lui en tant que PTL du projet.
Il lance un appel aux developpeurs ou autres personnes pour contribuer au projet Designate afin de faire vivre le crocodile qui le représente.

Cloudkitty project update

Luka Peschke de Objectif Libre nous présente les évolutions inclues dans la derinère version et celles prévues pour les prochaines.

Rappel

Cloudkitty est le projet officiel de Chargeback as a Service d’OpenStack. Pour résumer, Cloudkitty :

  • Récupère les métriques depuis Gnocchi/Monasca/Prometheus
  • Définit et applique des politiques de prix sur les données collectées
  • S’intègre avec Horizon & Grafana
  • Peut-être utilisé en dehors de l’écosystème OpenStack
  • Ne fait pas de facturation.

Stein

Cloudkitty a connu de nombreuses améliorations dans la dernière version d’OpenStack :

  • Découverte des scopes avec gnocchi
  • Stockage v2 & intégration à Grafana avec le nouveau backend Influxdb
  • Amélioration du fetcher Prometheus : support de l’authentification, des certificats, …etc..
  • Amélioration du dashboard Horizon : pas d’améliorations visibles par l’utilisateur, mais une meilleure organisation côté developpement (ex : dépendances JS)
  • Refactoring de la documentation
  • Création de l’API v2 : elle permet entre autre de facilement créer ses propres endpoints. Elle est uniquement compatible avec le backend de stockage v2.

Train

  • Découverte des scopes avec prometheus
  • De nouveaux endpoints dans l’API v2 : gestion des reports, du « summary » et du reset de l’état
  • Un second backend de stockage v2 : probablement de Elasticsearch, mais rien n’est encore fixé. Note : durant le onboarding, l’option Cassandra a été soulevée.
  • Focus sur la communauté :
    • Forcer l’usage de specs pour toute nouvelle feature
    • Meetings IRC

Au delà de Train

  • L’API v1 sera entièrement migrée en v2
  • Ajout d’un nouveau module de rating qui supportera les ensembles de règles
  • Toujours plus tourné vers la communauté

We need your help !