OpenStack Summit Boston : jour 2

Publié le
par Romain Guichard, Adrien Cunin, Pierre Freund, Jean-François Taltavull, Kevin Lefevre, Kevin Messy, Léo Georgel, Kourosh Vivan
dans OpenStack
⭠ Retour à la liste des articles
thumbernail OpenStack


Osones vous fait vivre l’OpenStack Summit de Boston comme si vous y étiez !

OpenStack Summit Boston : deuxième journée


OpenStack Summit Boston

Comme à chaque summit, nous ramenons dans nos valises les meilleurs pratiques sur OpenStack, et vous invitons à vivre l’OpenStack Summit de Boston comme si vous y étiez ! L'article dédié à la première journée de l'OpenStack Summit de Boston est déjà disponible sur le blog en suivant ce lien !

Deuxième jour, deuxième Keynote

9h00 : comme hier, c’est dès 9h que cette deuxième conférence retransmise sur internet commence. Cette fois-ci, c’est Mark Collier, COO de la Fondation OpenStack, qui ouvre la cérémonie sur le sujet de l’infra as code, baptisé “Home of Open {Composable} Infrastructure”. L'OpenSource y est célébré : dans tous les domaines, l'OpenSource reste vu comme la meilleure façon de résoudre des problèmes compliqués au niveau mondial. Ce que l'on retrouve dans l'IA ou le Machine Learning, avec les projets OpenSources Tensorflow (Google), Caffe1 (Facebook), ou encore Torch de Facebook/Twitter/Google. Tout cela est rendu possible grâce à deux caractéristiques : ils sont "composables" (peuvent travailler avec des projets indépendants) et "cloud native" (ils reposent sur le Cloud).

C'est dans cette optique de services "composables" que s'articulent les services OpenStack tels que Swift, Ironic, Neutron, Cinder et Keystone. Disponible en standalone depuis la release Kilo, Ironic n’a, par exemple, jamais cessé de perfectionner son support de Neutron au fil des releases. Au point qu’il est à présent possible d’utiliser directement Ironic avec Neutron. Nous avons eu l'occasion de voir une démonstration en direct : Ironic - une API et des plug-ins destinés à manager et provisionner des serveurs physiques - et Neutron sur du BareMetal.



Les conteneurs n'ont bien entendu pas été en reste, puisque Kendal (Upstream Developer Advocate de la Fondation OpenStack) et John (SolidFire, ancien PTL Cinder) ont déployé Cinder comme un service indépendant à l’aide de Docker. Le but de la manœuvre est de montrer la facilité avec laquelle ce service peut-être utilisé en standalone, en profitant de la maturité des nombreux backends (80) proposés par Cinder pour être perçu comme un plugin FlexVolume par Kubernetes.

Autre démo de la Keynote : Alex Polvi (CEO de CoreOS, Inc.) et Spencer Kimball (CEO de Cockroach Labs). Spécialement connu dans l'écosystème Docker, CoreOS est un OS orientés conteneurs qui peut tourner sur toutes les plateformes (Bare Metal et Cloud). CockroachDB quant à lui est un moteur de base de données OpenSource, conçu pour palier les faiblesses des bases SQL lorsque celles ci scalent (et donc se rapprocher du comportement de bases NoSQL) tout en gardant la possibilité d'effectuer des traitements à l'aide du langage SQL (ce que ne permettent pas les bases NoSQL). Autre point intéressant, Cockroach embarque des fonctions de clustering natives. Comme au Summit d'Austin, 20 proud openstack operators (IBM, Suse, RedHat, EasyStack etc) sont montés sur l'estrade pour monter l'interopérabilité des cloud OpenStack. Chacun d'entre eux, à l'aide d'un playbook Ansible, à déployé une stack Kubernetes ainsi que plusieurs pods Cockroach sur ce même Kubernetes. Les pods Cockroach étaient autoconfigurés pour rejoindre le cluster de Spencer Kimball ce que nous avons pu constater en direct, sans effet démo cette fois !



Enfin, cette Keynote se termine avec deux guests : Brian Stevens, depuis peu CTO de Google Cloud Plateform venu défendre la place du libre dans sa nouvelle entreprise, et Edward Snowden (en duplex évidemment...), qui revient sur les défis qu'impliquent l'informatique as a service et dont la vidéo est disponible ci-dessous.



Conférences

Votre Cloud est fantastique ! Pourquoi ne pas y faire tourner toutes vos applications ? (Jacob Rosenberg, Bloomberg)

Cette question en apparence naïve est posée par Jacon Rosenberg, un "early adopter" OpenStack de l'agence de presse Bloomberg.

S'il est évident que les nouvelles applications candidates à être hébergées dans le cloud doivent être concues dans le respect des règles connues sous le nom de "12 facteurs" (https://12factor.net), comment faire pour résorber l'incontournable dette technique et migrer les applications "legacy" ? Une approche brutale et exhaustive consistant à vouloir tout adapter au sein d'un immense chantier ? Sûrement pas: c'est simplement impossible et ce serait le meilleur moyen d'aller dans le mur !

La bonne méthode est d'entrer dans une logique incrémentale qui consiste à adapter les applications petit à petit, avec comme fils conducteurs :

  • augmenter la dose d'ingénierie (le "build") et dimininuer celle d'opérations (le "run")
  • automatiser tout ce qui arrive dans le cloud
  • moderniser les applications en douceur en identifiant les fonctionnalités pouvant être implémentées sous forme de micro-services
  • moderniser leur packaging et agiliser leur déploiement en adoptant, par exemple, une technologie de type "conteneur"
  • évaluer de façon réaliste le bénéfice que l'on peut en attendre avant de décider de faire monter une application legacy dans le cloud

Voilà pour les aspects techniques. Mais le plus gros du travail se situe du côté des ressources humaines. Il s'agit là de faire tomber les cloisons de l'entreprise. Les cloisons physiques qui empêchent le rapprochement "géographique" de personnes qui jusqu'à présent travaillaient loin les unes des autres, mais aussi et surtout les cloisons immatérielles liées à la culture, aux processus et aux outils. Les personnes doivent apprendre à utiliser les nouvelles technologies et les nouvelles approches introduites par le cloud. Le cas échéant, il va même falloir les aider à apprendre. Il en va de la réussite du projet ! Un des moyens qui peut aider à "embarquer tout le monde dans le cloud" est de partager les mesures et les données opérationnelles. En résumé, il est capital de se donner les moyens de gérer et piloter la transformation afin de la réussir !

The challenge of OpenStack Performance Optimization for 800 nodes in a single region

Il s'agit d'une retour sur les problème rencontrés par T2 Cloud, leader sur le marché chinois du cloud OpenStack. En chine chaque année, les gens se deplacent massivement pour le "spring festival", cet événement représente un défi énorme pour la "china railway corporation". Le cloud de T2 Cloud est à la hauteur avec une volumétrie de 100K vm sur plus de 600 computes sur une unique région.

Le premier problème vient de la base de données. Dans le déploiement T2 Cloud, la BDD est un galera avec 3 masters synchrones derrière une VIP haproxy en round robin. Lorsque le cloud est fortement chargé, plusieurs services peuvent essayer de toucher à la même ligne. Alors le second service recoit un DeadLock. Pour éviter cette erreur, la soution la plus simple est de ne taper que sur un serveur et de mettre les autres en backup dans haproxy. Mais cette solution n'est pas satisfaisante. Alors T2 Cloud à analysé le type de demandes que font les services OpenStack. Il en ressort que les services font majoritairement des "select" (en moyenne 73%) donc des lectures. Ils ont donc placé un MyCat entre le haproxy et les mariaDB, le rôle de MyCat est donc d'envoyer les requêtes en écriture sur un seul serveur et de repartir seulement les lectures sur l'ensemble des serveurs MariaDB. Cette solution a demandé une petite modification du comportement de SQLalchemy qui par defaut concidère toutes ses transactions comme des écritures. Pour le futur, les équipes de T2 Cloud travailleront sur la fonctionnalité group replication.

Ensuite, T2 Cloud a parlé d'un problème avec la population agent L2 de neutron. Deux problèmes peuvent apparaitre:

  • Lorsque un port est modifié, l'information est remonté par l'agent L2 du compute concerné au neutron plugin. Celui-ci à travers le L2 population agent met à jour le fdb et transmet l'info à tous les agent L2 des computes. Donc pour chaque modification de port, un message est envoyé à chaque compute (le T2 cloud en a plus de 600)
  • Avec X instances sur Y computes, un restart entraine X requetes sur la DB et X*Y messages rabbit.

La solution de T2 Cloud est de revoir le fonctionnement du L2 pop agent, en utilisant un cache mémoire pour le FDB plutot que la DB et d'utiliser un 0MQ pour les messages de type fanout (broadcast à tous les computes), plus d'info voir le blueprint de L2 pop (https://wiki.openstack.org/wiki/L2population_blueprint)

T2 Cloud est également revenu sur les problèmes avec la gestion des tokens UUID de Keystone. L'utilisation de memcache aide beaucoup mais n'est pas suffisante. L'utilisation de token UUID n'est plus conseillé, nous recommandons comme la documentation officielle, d'utiliser les tokens fernet qui n'ont pas besoin de persistance.

Make OSA work for you

Session présenté par le PTL (Project Technical Lead) de OSA (OpenStack-Ansible) Andy McCrae, ingènieur chez Rackspace, la session commence par un rappel d'une slide passée à la première keynote :

General Electric à deployé un OpenStack avec OSA, la remarque des équipes techniques : "This plateform must be made of awesome."

Le PTL rappel la ligne directrice du project: "No fancy just something that work and best for production deployment.". Voila le ton est donné, OSA se veut comme la solution déploiement d'OpenStack. Andy rappel que OSA était la première solution de deploiement dans la documentation officielle (https://docs.openstack.org/project-deploy-guide/newton/). Un gros travail a été effectué sur la documentation pour Pike avec l'apparition d'une section "operations guide" (https://docs.openstack.org/developer/openstack-ansible/operations-guide/index.html), et plus d'informations sur les etapes nécessaires pour préparer les hosts.

Andy McCrae rappelle que OSA est hautement personnalisable, l'utilisation des containeurs LXC n'est pas obligatoire. Le deploiement peut se faire sur une VM, un container ou sur un serveur physique. Et chaque brique de OSA peut être prise indépendament du reste. Il est possible par exemple de ne deployer que cinder et keystone.

Les playbooks Ceph sont ceux du projet officiel, leur utilisation est possible avec ceux de OSA. Le travail éffectué par l'équipe porte sur l'utilisation de ceph par cinder si ceph est disponible, la gestion des variables pour le rôle Ceph et l'ajout de test pour verifier le fonctionnement de l'ensemble.

Stockage local avec Kubernetes, Michelle Au @ Google

Il existe actuellement deux types de stockage disponibles pour Kubernetes (k8s) : ephemeral et persistent

Ces deux types sont les exactes parallèles du stockage éphémère sur OpenStack (stockage sur les computes gérés par Nova) et les volumes Cinder. Selon les cas d'utilisation, le stockage éphémère se révèlera particulièrement utile pour des applications stateless ou pour du caching. Le stockage persistent sera la solution retenue pour la plus grande majorité des applications non cloud native pour stocker la data utile ou des configurations.

Le stockage local se situe à mi chemin entre ces deux types. C'est un stockage local au node k8s sur lequel tourne un pod mais ce stockage n'est pas strictement lié au pod et ne sera pas perdu si le pod est détruit.

Pourquoi en aurions-nous besoin ?

Les avantages sont assez nombreux :

  • meilleurs performances
  • réduction des coûts d'une infra SAN
  • economie sur la bande passante
  • du stockage local "gratuit" est fourni chez beaucoup de cloud providers

A contrario, un pod ayant besoin d'accéder à ce type de stockage se retrouvera cantonné à un node donné (celui sur lequel se trouve le stockage). Cette affinité va à l'encontre du principe de k8s qui vise à scheduler nos workloads auto-magiquement. Le node en question devient un SPOF du service rendu par le pod et ce service perd donc mathématiquement en disponibilité. Néanmoins, la persistence reste un besoin puisque l'on aimerait ne pas à reconstruire son cache par exemple.

Dernier use case et cas d'utilisation surement un des plus pertinents : les datastore distribués. Des applications comme Ceph ou GlusterFS n'ont pas besoin d'avoir un stockage externe redondé, ils assurent eux même cette redondance au niveau applicatif et demandent justement de disposer d'un stockage le moins cher et le plus rapide possible.

Pour effectuer cette configuration, k8s dispose d'HostPathVolume. Néanmoins si notre pod se retrouve schédulé sur un autre node, il ne pourra accéder à son stockage et échouera à démarrer. On peut imaginer tricher et forcer le scheduling du pod sur le node disposant du stockage local. Comme dit précédemment cela va à l'encontre de la philosophie de k8s et rend ce pod non agnostique des nodes. La solution vient avec les Persistent Volume Claim. On défini au préalable un PVC et sur notre pod, au lieu d'associer un HostPath à notre volume, nous lui faisons "claim" sur notre PVC. Cette méthode est très proche de ce que nous faisons dans le monde OpenStack lorsque nous souhaitons disposer de volumes Cinder sur nos computes nodes. Avec cela, notre pod redevient agnostique de son environnement et peut être déployé n'importe où, pour peu que la storage class utilisée par le PVC existe sur le cloud considéré.

Sessions Forum

Feedback opérateurs OpenStack-Ansible

Session plutôt généraliste qui intéressera tous les utilisateurs de la solution de déploiement d'OpenStack basée sur Ansible, c'est-à-dire OpenStack-Ansible (OSA).

Les discussions, modérées par le PTL (Program Team Lead) d'OSA ont notamment couvert les sujets suivants :

  • Mises à jour majeures d'OpenStack

Peu de retours dans le salle, mais ils sont généralement positifs. La question est posée des mises à jour N à N+2 ou N à N+3, c'est-à-dire la possibilité de sauter des versions dans le processus de mise à jour. Des travaux sont en cours dans le dépôt openstack-ansible-ops.

  • Actions de maintenance classiques automatisables

Quelles sont les tâches que les opérateurs de clouds déployés avec OSA réalisent aujourd'hui ? Nous avons évoqué la question du nettoyage des anciens environnements virtuels Python lorsque des mises à jour mineures sont déployées. C'est encore une fois dans le dépôt openstack-ansible-ops que des playbooks Ansible répondant à ces problématiques ont leur place.

  • Installations complètement offline

Et oui, certaines contraintes peuvent mener à devoir réaliser des déploiements d'OpenStack avec OSA sans aucune connexion internet directe. Et bien malgré quelques points perfectibles, cela fonctionne !

  • Documentation

Le projet OpenStack-Ansible met un fort accent sur la documentation, preuve en sont les deux personnes travaillant sur le sujet à plein temps. C'est ainsi qu'OSA fut la première méthode de déploiement documentée. Aujourd'hui cette documentation est complétée par les avancées sur la documentation opérateurs. Il reste du chemin à parcourir notamment pour ne pas dupliquer le travail réalisé avec la documentation opérateurs générique OpenStack. Nous avons suggéré l'idée de documenter les bonnes pratiques de gestion de patches locaux, autant au sein même des rôles Ansible que dans les composants OpenStack déployés.

  • Intégration de rôles Ansible non OSA

Ce point est déjà une réalité notamment avec l'intégration dans OpenStack-Ansible de rôles Ansible permettant le déploiement de Ceph et développés à l'extérieur du projet OpenStack. Certains utilisateurs seraient intéressés par de la documentation sur le sujet, qui leur faciliterait l'intégration de rôles supplémentaires dans leur déploiement local.

  • "Feedback loop"

Autrement dit, est-ce que les échanges entre développeurs et utilisateurs d'OSA (donc les opérateurs) fonctionnent correctement et permettent d'avancer dans la bonne direction. D'une part, cette session montre que la réponse est plutôt oui ! Et nous partageons avec la salle qu'OSA est un projet OpenStack particulièrement à l'écoute de ses utilisateurs, notamment au travers de la réactivité des développeurs aux questions et suggestions remontées sur le channel IRC #openstack-fr@Freenode.

Distributed SNAT with DVR

C'est un sujet évoqué depuis longtemps puisque nous en avions dejà parlé au summit de Tokyo. Comme vous vous en doutez, on se retrouve aujourd'hui pour discuter d'une potentielle solution puisqu'elle n'a toujours pas été trouvée.

Pourquoi distribuer le SNAT ? Parce que c'est pour le moment le seul SPOF réseau d'un déploiement Neutron avec Open vSwitch. Même si il y a eu des améliorations concernant la HA : il est possible de répartir les agents Neutron SNAT sur différents noeuds réseaux et ainsi mitiger le SPOF, les noeuds réseaux constituent potentiellement un goulot d'entranglement.

Distribuer le SNAT permet de palier à ces deux problèmes mais ajoute beaucoup de complexité à Neutron :

  • Un routeur Neutron dispose uniquement d'une IP externe.
  • Augmente de maniere exponentielle le nombre de floating IP necessaires à son fonctionnement.

En effet, il faudrait l'équivalent de : (Nb de routeur / tenant ) * le nombre de computes sur lesquels le tenant dispose d'instances. De plus, si l'on ajoute à cela les potentielles migration d'instances entre noeuds compute, les instances changeraient d'IP de SNAT à chaque migration. Pour limiter la consommation d'IP il existe une spécificaiton : Les Service Subnet qui permettraient de limiter la consommation d'IP externe des routeurs des tenants. Mais cela ne règle pas vraiment le problème.

D'autres alternatives ont été évoquées comme par exemple avoir des nodes pool, c'est à dire des pool de SNAT alloués aux computes nodes.

Toujours pas consensus, attendons de voir quellle direction prend le projet Neutron, sachant que Neutron OVS + DVR n'est plus la méthode presentée par defaut dans le guide déploiement OpenStack et que beaucoup de nouveaux déploiements utilisent maintenant Neutron + Linux Bridge qui lui n'utilise pas de DVR.

OpenStack Summit : l'âge de raison, par Pierre Freund

Osones participe depuis maintenant 3 ans et demi aux différents Summits OpenStack. Nous avons commencé par Hong Kong, puis Atlanta, Paris, Vancouver, Tokyo, Austin, Barcelone pour finir par Boston. Nous avons connu la période "folle". Les sponsors ne lésinaient pas sur les moyens. Les particpants étaient invités tous les soirs à une ou plusieurs soirées. De quelle soirée va-t-on se souvenir après le Summit : celle d'HP, qui a pendant plusieurs summits réalisé de sombtueuses soirées, de RedHat ou de Mirantis ? Les sponsors se livraient à une bataille sans-merci pour séduire les participants pour notre plus grand bonheur.

Cette période conïncide avec la période "juvénile" d'OpenStack. Le produit était en plein développement. Les projets se mutlipliaient, les entreprises privées s'engoufraient dans le projet. C'était à celui qui se placerait le plus vite et le plus fort. Nous avons par exemple vu arriver en force de RedHat, qui occupe sans doute aujourd'hui la place de leader.

Aujourd'hui OpenStack est un jeune adulte, responsable et stable. Les investissements démesurés de certaines entreprises comme HP sont aujourd'hui bien plus modestes. Petit stand, petite équipe, aucune soirée. La raison de se ralentissement tient en 3 lettres : ROI (Return On Investment). Le retour sur investissement d'OpenStack côté distributeurs n'est pas là. Le marché de l'IaaS est plus lent que prévu. Et les summits ne sont pas forcément les événéments les plus générateurs de business. Les investissement de ces grosses entreprises n'ont peut être pas baissé, mais ont sûrement été ré-affectées à d'autres événéments, moins techniques et plus commerciaux.

OpenStack a gagné en maturité, dans son code et dans les esprits. La fougue de la jeunesse a laissé place à la sérénité. OpenStack est mature, pérenne. Si cela a pour conséquence une baisse de fréquentation des summits et moins d'openbars, nous nous en contenterons, car le combat est gagné.

Une journée au Summit à préparer OpenStack Day France 2017

Quoi de mieux qu’un Summit OpenStack pour discuter de la préparation d’un OpenStack Day. Nous avons aujourd’hui en tant que membre organisateur de l’OpenStack Day France discuté avec l’équipe marketing de la Fondation sur notre avancement et nos besoins. Nous avons évoqué l’idée de mettre à disposition des ressources types (web site - prospectus de sponsoring - charte de l’événement) pour facilité le travail des organisateurs d’OpenStack Days et homogénéiser les différents événements à travers le monde. Nous avons aussi profité de cette journée pour se réunir avec les membre du board de l’association OpenStack-Fr, présents à Boston, afin de prendre certaines décisions sur l’édition OpenStack Day France 2017 actuellement en préparation (qui aura lieu le 21 Novembre 2017). Cette journée nous a également permis de faire le tour des stands de la marketplace pour communiquer sur notre événement et commencer à soliciter des sponsors ainsi que des speakers.

La suite du dossier OpenStackSummit Boston :

⭠ Retour à la liste des articles

Découvrez les derniers articles d'alter way

Découvrez les technologies d'alter way