OpenStack Day France

Pause Cloud & DevOps
spéciale OpenStack Day Paris

Aujourd’hui, la Pause est dédiée à notre retour sur l’OpenStack Day Paris, organisé par l’association OpenStack-fr et qui s’est déroulé le 21 novembre.

L’occasion de faire une pause et de suivre l’actualité OpenStack, résumée pour vous en français par les consultants d’Objectif Libre présents sur place.

Prenez un café et quelques minutes : faites une pause !

Au menu :

  • Keynote OVH
  • Retour d’expérience d’une migration Liberty vers Mitaka
  • L’intégration du GPU dans Nova
  • Retour d’expérience sur l’évolution d’une plateforme OpenStack

Keynote OVH

Jean-Daniel Bonnetot, product marketing chez OVH, a présenté quelques chiffres sur la plateforme OpenStack mise en place au sein du groupe :

  • Plus de 100 Po de fichiers stockés dans Swift
  • 190 000 instances actives sur leur cloud public
  • 650 000 instances démarrées par an, 200 000 VM sur leur offre de cloud privé

Les projets d’évolution de la plateforme d’OVH sont nombreux. L’arrivée de Heat devrait permettre aux utilisateurs de la plateforme d’automatiser le déploiement d’infrastructure. Les fonctionnalités de télémétrie (Ceilometer, Aodh) permettront de faire du scale automatique basé sur des métriques. Le composant de base de données « as a service » est actuellement en cours de test par l’hébergeur. Le Cloud d’OVH devrait s’étendre avec l’ouverture de zones aux États-Unis mais également en Asie et en Océanie.

Enfin, lors de sa conférence, OVH a rappelé le rôle qu’il tenait au sein de la communauté OpenStack en précisant qu’il fournit une partie des machines permettant aux développeurs d’effectuer les tests d’intégration sur le projet OpenStack.


Retour d’expérience d’une migration Liberty vers Mitaka

Lors de cette session, Frédéric Gillouard et Denis Gougeon, respectivement architecte logiciel et architecte infrastructure et réseau chez Arkea Crédit Mutuel, nous détaillent la migration de leur cloud de Liberty vers Mitaka.

La plateforme est composée de trois machines contrôleurs en haute disponibilité et de huit hyperviseurs. Les composants utilisés par leur plateforme sont les services standards d’OpenStack. A cela s’ajoutent des modules de TripleO ainsi que le composant Designate permettant de faire du DNS as a service.

Pour effectuer la migration, la question de faire un rolling upgrade ou de créer une nouvelle plateforme s’est posée. La contrainte était d’avoir le minimum d’interruption de service. La solution du rolling upgrade a été écartée à cause du temps d’indisponibilité inévitable et d’un rollback a priori complexe. De plus, dans la version Liberty, le rolling upgrade était encore considéré comme expérimental. Le choix de créer une nouvelle plateforme a donc été privilégié. De nouvelles machines physiques ont été installées, la nouvelle plateforme est composée de seize hyperviseurs accumulant 8 To de RAM et 32 To de disque.

 Les deux plateformes OpenStack fonctionnaient donc indépendamment et les équipes pouvaient migrer leurs applications vers la nouvelle plateforme sans coupure. La migration se faisait simplement en dés-associant une floating IP de l’application sur l’ancienne plateforme pour associer la même floating IP sur la nouvelle plateforme. L’interruption de service était ainsi minime pour les utilisateurs finaux.


L’intégration du GPU dans Nova

La conférence d’OVH met en lumière les problématiques d’un hébergeur de grande envergure sur l’utilisation du GPU (carte graphique) dans la cadre d’un cloud public OpenStack. La conférence, très technique, reprenait point par point les différentes questions que l’hébergeur s’est posées pour son POC.

Tout d’abord, Julien Cornuwel nous rappelle que les GPU sont beaucoup plus performants que le CPU dans le cadre de calculs parallélisés. En effet, le GPU ayant 100 fois plus de cœurs qu’un CPU, il sera plus efficace pour effectuer du traitement d’image, du Machine Learning et du cloud gaming. Ce gain en performance se traduit aussi par une consommation électrique plus importante et surtout par de la chaleur supplémentaire à dissiper. Il faut donc, pour un hébergeur, concevoir des salles capables de supporter ce type de matériel.

L’hébergeur met en avant une autre problématique : comment assurer l’intégrité du GPU dans un environnement cloud ? En effet, la mise à disposition de GPU au sein de machines virtuelles se fait grâce au GPU passthrough. L’utilisateur a donc un accès direct au GPU et peut modifier le firmware. Cela soulève un vrai problème puisque l’utilisateur pourrait rendre le GPU totalement inutilisable ou utiliser un firmware qui ferait consommer au GPU plus d’énergie. La solution choisie a été de mettre une couche entre la carte graphique et l’utilisateur pour contrôler les actions possibles sur le GPU.

L’implémentation technique est réalisée en utilisant la technologie PCI passthrough de KVM. Nova et libvirt ont été patchés pour permettre l’ajout de fonctionnalités utiles pour optimiser l’utilisation du GPU dans le cadre de la virtualisation avec KVM.


Retour d’expérience sur l’évolution d’une plateforme OpenStack

Cette conférence, présentée par Cedric Morandin d’Amadeus, nous explique leur déploiement d’OpenStack et les évolutions qui ont été apportées sur la plateforme.

Le premier déploiement de la plateforme s’est fait en version Juno sous RHEL, en utilisant Neutron, Ceph et KVM. La plateforme était composée de trois contrôleurs en haute disponibilité et de dix hyperviseurs. La plateforme accueillait 500 VMs. À cette échelle, des ralentissements réseau ont commencé à se faire sentir au niveau d’iptables.

La migration vers Liberty a été effectuée en vue d’utiliser Ironic dans un contexte de multi-tenants. C’est pour cette raison que l’équipe a décidé d’utiliser le SDN Nuage Networks pour assurer la partie réseau d’OpenStack. Ironic est utilisé principalement pour faire des tests de non-régression de performance sur les applications. En effet, la mutualisation des ressources qui est faite sur l’hyperviseur ne permet pas de donner des résultats de tests suffisamment fiables et l’utilisation d’une machine physique est plus appropriée à cet usage. Le second besoin d’Ironic était pour les application telles qu’OpenShift ou encore les bases de données noSQL. L’argument avancé est qu’il n’est pas nécessaire de faire de la virtualisation pour des applications capables de fonctionner en haute disponibilité nativement.

Le déploiement d’Ironic avec Nuage Networks ne supporte pas les méta-data via le réseau, les floating ips ou de NAT. Pour assurer le fonctionnement des méta-data, Nova est configuré pour envoyer les méta-data via une partition. Le second point soulevé par ce retour d’expérience est la connectivité externe des machines baremetal qui est assuré par une VM, le SDN n’étant pas capable de router le trafic sortant dans ce contexte. Le dernier problème soulevé sont les quotas qui sont partagé entre les machines virtuelles et les machines physiques.

Le second objectif de la plateforme était de pouvoir faire démarrer 300 VM et 150 volumes en moins de 2 minutes. Pour réussir à atteindre ces performances, les équipes d’Amadeus ont modifié le code de Cinder pour l’optimiser. En plus de ce test, Rally est utilisé pour effectuer des tests de performance sur les différentes fonctionnalités de la plateforme. Le cluster est composé aujourd’hui d’une trentaine de nœuds faisant tourner un millier d’instances.