En direct d’Austin, jour 4 – dernière édition !

openstackQue retenir du jour 4 de l’OpenStack Summit de Austin ?

Prenez un café et 5 minutes pour vivre avec nous les faits marquants de la dernière journée du Summit, vue par l’équipe d’Objectif Libre présente sur place:
faites une pause OpenStack !TasseVintage

 

Au menu aujourd’hui :

 

Bonne lecture !

Rolling Your Own Kubernetes Clusters on OpenStack with Ansible and Terraform

Solinea a été consulté par plusieurs clients pour déployer du Kubernetes.

Ils ont regardé les choix possibles:

  • En local via Docker sur du vagarant : une solution a priori pas encore capable de tourner en production ou avec des charges utilisateurs.
  • Une solution TurnKey : donc sans contrôle ou maîtrise réelle de qui se passe.
  • Une solution d’un cloud très particulier chez Google ou Amazon, qui n’était pas la volonté du client.
  • Bare metal via des outils classiques de déploiement : se pose la question du cloud provider et de la maintenance de l’ensemble.
  • Magnum mais le projet n’était pas encore complètement adopté, hors quelques tests par les providers.

 

Rien d’existant ne convenait vraiment pour les clients de Solinea.
La demande pour les conteneurs est pourtant réelle : cf. les derniers user survey, c’est bien l’attente prioritaire des utilisateurs d’OpenStack.

 

Contrairement à Magnum, Heat est très utilisé et répandu : Solinea a donc  décidé de baser le déploiement à partir de Heat ou d’une technologie avec une logique proche – qui s’avérera être Terraform.

 

IMG_20160428_152120574_HDR.resized

 

Au final, ils utilisent seulement 2 templates Terraform :

  • 1 pour le déploiement de l’infrastructure OpenStack
  • 1 pour créer un inventaire utilisable par Ansible

Le choix d’Ansible était évident : c’est le choix majoritaire chez les clients de Solinea.

Restait à choisir le playbook à utiliser, entre 2 solutions distinctes :

  • 1 créé par la Communauté mais sans support de Ubuntu et présentant quelques limitations.
  • Kubespray Kargo, choix également Open Source et présentant un spectre de support plus large.
    C’est ce choix qui a été retenu.

Terraform a pour sa part été choisi car le client de Solinea était déjà opérationnel dessus (ce n’était pas le cas pour Heat) et cela permettait d’utiliser un cloud provider avec une technologie différente.

Le fonctionnement final est opérationnel, bien que pas encore parfait du fait de l’évolution permanente de K8s. Le fonctionnement d’éléments est parfois instable… par exemple, la démo n’a pas fonctionné.

 

Il sera sans doute intéressant dans l’avenir d’investir plutôt dans Magnum si l’adoption du projet progresse.

 

Monitoring Swift ++ (ELK, Zabbix, Prometheus & Grafana)

Lors de cette session, Adam Takvam (SwiftStack) et Martin Lanner (SwiftStack) nous ont exposé les éléments clés pour monitorer la solution de stockage objet Swift.
Ils nous ont rappelé que Swift est un système de stockage objet dont les caractéristiques sont les suivantes:
  • Système distribué
  • Système résiliant grâce à la réplication des données
  • Pas de point de défaillance unique
  • Système d’auto-guérison
Swift est donc une solution avec une forte résilience qu’il est néanmoins primordial de surveiller. 
Leur approche pour monitorer Swift se base sur 3 « triplés » de solutions:    
  • ELK (Elasticsearch, Logstash, Kibana)
  • Zabbix
  • Prometheus & Grafana
Swift est capable de gérer ses propres données. L’approche de surveillance peut suivre différents modèles:
  • L’approche agent permet de recueillir les métriques à l’aide des solutions suivantes :

    • Logstash
    • Prometheus Node
    • Agent Zabbix
    • Nagios NRPE
  • L’approche agrégation permet d’agréger les métriques en provenance des agents à l’aide des solutions suivantes :

    • Nagios
    • Zabbix
    • Elasticsearch
  • L’approche visualisation permet de « grapher » les données au sein d’une interface web à l’aide des solutions suivantes :

    • Kibana
    • Grafana
  • L’approche alerte permet de déclencher une alerte lorsque le seuil acceptable de la métrique est dépassé, avec :
    • AlertManager
    • PagerDuty
 
La stratégie de monitoring peut ensuite se définir en 2 sous-parties :
  • Les métriques
    • L’utilisation du système (CPU, mémoire, I/O, réseau, temps de réplication)
    • La performance et la latence
    • Les erreurs 
    • Les pannes  
  •  Le cycle de vie de la surveillance
    • La mesure
    • Le reporting
    • Le seuil
    • L’alerte        

IMG_20160428_101729.resized

Ont ensuite été exposés différents exemples de monitoring pouvant être faits avec les outils ci-dessous:
  • ELK, outil d’aide de prise à la décision
  • Prometheus, outil qui permet de mesurer la croissance des données et de données des tendances
  • Zabbix, qui permet de mesurer la saturation du réseau, les état de la charge CPU et la quantité de mémoire utilisée    

IMG_20160428_102528.resized

 

En conclusion : même si la solution Swift offre des mécanismes de résilience intéressants, il reste fondamental de la moniter afin d’anticiper la quantité des données qui seront stockées dans les jours et mois à venir. Il est aussi important de pouvoir surveiller l’activité du stockage objet afin de prévenir en amont une défaillance potentielle et par conséquent une indisponibilité des objets du serveur Swift.

 

A l’aide de tous ces mécanismes de surveillance et d’aide de prise à la décision, il est aisé de faire de la maintenance préventive et curative et de rendre le cluster Swift totalement disponible 24/24 et 7/7.

 

Du nouveau pour DVR – Distributed Virtual Routers dans Neutron

DVR est une fonctionnalité de Neutron qui permet aux instances de communiquer entre elles et vers l’extérieur sans passer le nœud de réseau.

 

Dans l’architecture traditionnelle, avec le plugin OpenvSwitch pour Neutron, la communication entre les réseaux privées et vers l’extérieur est réalisée sur le network node.
Cette architecture centralisée peut poser problème et implique de mettre de la haute disponibilité.

 

Avec DVR, le routage est réalisé au niveau des computes nodes, ce qui implique que les compute node aient une patte vers l’extérieur.
Les computes nodes partagent les informations de routage, ce qui permet de ne pas perdre l’ensemble de la connectivité en cas d’un nœud de défaillant.

Nous pouvons penser qu’il n’y a pas plus besoin de network node dans DVR : ce n’est pas le cas.

Les instances qui n’ont pas d’IP flottantes (ip public) et qui veulent communiquer vers l’extérieur iront sur le nœud de réseau. Celui effectuera du SNAT pour ces instances (IP privée => IP public).

 

Si le nœud de réseau est défaillant, il n’y a pas de SNAT. Comment pallier à ce problème?

 

Swaminathan Vasudevan,  Adolfo Duarte et Hardik Italia de HPE ont présenté une nouvelle fonctionnalité proposée dans Mitaka, la dernière version d’OpenStack, le SNAT HA pour le DVR.

 

Le routeur virtuel responsable du SNAT dans le network node sera répliqué dans un ou plusieurs autres nœuds de réseau.
Le routeur sera actif sur un des nœuds et passif sur les autres.
Un réseau spécifique pour ces routeurs sera mis en place pour les paquets VRRP, paquets générés par Keepelived pour élire le routeur actif et les routeurs passifs.

 

Cette fonctionnalité SNAT HA ne fournit pas de haute disponibilité pour les autres services du network node. A noter également que le passage d’une architecture réseau vers ce mode de fonctionnement n’est pas supporté.

 

Dans la roadmap, nous pouvons citer la compatibilité avec Ipv6 et BGP.

 

En savoir plus:

 

Octavia et la nouvelle implémentation du LoadBalancer-as-a-Service

 

Il y a quelques années, le projet neutron ajoutait du Load-Balancer-as-a-service, c’est-à-dire la possibilité de créer des objets en charge de cette fonctionnalité.
Le projet, dans sa première implémentation, se basait sur HAProxy uniquement et connaissait des limitations, comme par exemple l’écoute sur un seul port.
L’an dernier, une seconde implémentation (LBaaS V2) a vu le jour avec un design repensé qui permet désormais d’autres solutions de LBaaS. A noter que la solution est stable depuis Mitaka.

 

HAproxy est toujours là et on trouve également des solutions reconnues du marché comme A10 ou F5.

 

Et puis il y a Octavia.

Octavia est un nouveau projet OpenStack, réalisé en grande partie par la même équipe que LBaaS v2, avec une en particulier la volonté de mieux gérer la charge.

 

Les ressources LBaaS sont exécutées sur les nodes réseaux, Octavia pour sa part utilise des instances nova dédiées avec une utilisation plus raisonnable des ressources – le Load Balancer pouvant être gourmand  en consommation CPU, notamment pour la gestion du SSL.

 

L’architecture de Octavia utilise de nombreux composants OpenStack :

    • Nova pour les compute driver
    • Barbican pour le driver des certificats
    • Neutron pour le network driver

 

Le reste de l’architecture de Octavia est assez similaire à l’architecture des composants classiques : API, utilisation de AMQP, de DB, et un grand souci de modularité avec une utilisation de nombreux drivers.

 

octavia-architecture.resized

 

L’octavia worker est en charge du dispatching des actions.
Le Health manager est un simple heartbeat sur tous les membres des différents pools pour savoir ceux qui sont encore actifs.
Le Housekeeping manager vérifie le status des instances Amphora, Amphora étant le composant qui  pilote le load-balancer.

Il existe pour le moment une seule implémentation de Amphora (HAProxy) mais d’autres drivers sont en cours de réalisation, que ce soit pour du LoadBalancer logiciel (A10, NGINX) ou du matériel (F5).

 

Octavia va donc devenir l’abstraction de manipulation des LoadBalancers, comme c’est le cas pour neutron avec le réseau par exemple.

 

Plusieurs options de Haute Disponibilité sont présentes dans Octavia, à plusieurs niveaux.

Les instances amphora peuvent être lancées en STANDALONE (et donc relancées après un certain temps, souvent 1 minute) ou en mode ACTIF/PASSIF (le ACTIF/ACTIF étant prévu pour Newton). Les instances peuvent bénéficier de placement « intelligent » sur des groupes d’anti-affinités pour ne pas mettre toutes les instances du load-balancer sur un même compute.

 

A noter enfin : Octavia propose certaines options intéressantes, comme la gestion de la terminaison SSL ou du traitement L7, qui en font une solution vraiment attractive !

 

Les coulisses des développeurs OpenStack

 

La journée a été marquée par un très grand nombre de sessions design pour les développements de la prochaine version (Newton). Voici des éléments que notre équipe a retenus.

 

Du coté de Horizon, la release Mitaka avait été marqué par l’apparition de la version en AngularJS, tout en conservant la version précédente. Ce changement assez fort de technologie s’est accompagné d’importants changements d’apparence. Il a donc été décidé de faire évoluer la version en django pur afin de reproduire le comportement de la nouvelle version en AngularJS.

Un reproche régulièrement remonté à Horizon est sa lenteur sur des gros environnements à cause du nombre élevé de ressources à afficher. La pagination va donc être améliorée pour n’afficher que résultats après filtrage.

 

Du coté des sessions Telemetry, il a été décidé de retirer la partie événements de Ceilometer pour en faire un projet indépendant (comme ce fut le cas pour l’alarming avec Aodh).

L’expérimentation de Gnocchi pour la documentation a porté ses fruits et désormais tout le projet Telemetry va inclure sa documentation dans son code, pour si possible l’auto-générer.