Post-Doc : Evaluation et Analyse comparative des performances des protocoles de communication internes dans OpenStack F/H

Description de l'offre

about the role

Effectuer un travail de recherche sur l'évaluation et l'analyse comparative des performances des protocoles de communication internes dans OpenStack.

Vous trouverez ci-dessous la description du contexte de ce travail de recherche.

La mission et les principaux objectifs scientifiques seront précisés sous le titre "Entité".

Contexte global du sujet de l'étude et état de l'art (bibliographie)

Avec le découplage entre le logiciel et le hardware qu'autorise le SDN et NFV, les équipements réseaux tendent à se banaliser et les fonctions réseaux migrent dans le Cloud. A terme, ces fonctions virtualisées dans le Cloud seront logées dans des serveurs « éclatés » et mutualisés, permettant un gain en matière d'agilité. Ce Cloud distribué pourra accueillir également les fonctions et applicatifs des clients. Se pose alors la question de la solutions techniques que va adopter Orange pour piloter ce cloud massivement distribué. Si l'utilisation d'OpenStack pour le pilotage d'un cloud centralisé (un data center) ou faiblement distribué (une dizaine de Points de présence) ne pose pas de question, son utilisation pour le pilotage de ce cloud massivement distribué (jusqu'à quelques milliers de noeuds) soulève d'importantes questions qui sont encore à résoudre. Parmi les questions les plus importantes celle consistant à identifier et quantifier le comportement que va avoir OpenStack, comme il est aujourd'hui, lorsqu'il sera utilisé en tant que tel pour piloter un cloud massivement distribué au sein du réseau de l'opérateur. La question se pose en particulier par rapport au bus de communication interne d'openstack. Dans les déploiements Openstacks, un bus de communication interne (RabbiMQ) est utilisé pour l'échange des messages de contrôle entre noeuds de contrôle et de calcul. Lorsqu'on a un Cloud massivement distribué et que l'on va partager ce bus entre l'ensemble des noeuds gérés par OpenStack (de l'ordre de centaines à des milliers de PoPs) ce bus peut représenter un goulot d'étranglement potentiel avec des impacts sur le fonctionnement global du système (impact négatif sur le temps nécessaires pour déployer, modifier ou supprimer des ressources). Cependant, jusqu'à présent, aucune étude n'a confirmé ou infirmé ces propos. D'un côté, lors d'échanges récents avec ATT dans le cadre d'un partenariat Orange/ATT, nous avons appris qu'ATT a décidé de déployer des instances d'Openstack indépendantes sur plusieurs PoPs (de l'ordre de 160) chacun ayant un bus local (et donc pas de partage de ce bus au niveau du réseau); selon ATT, un bus de communication à travers le WAN est très problématique et n'est absolument pas calibré pour un déploiement opérationnel. D'un autre côté, en réponse à un RFP très récent lancé par OBS (RFP VIM), Redhat a accepté de déployer Openstack sur plusieurs PoPs (8 à la cible) avec un bus de communication interne partagé à travers le WAN, quant à Mirantis, il a refusé cette architecture et a insisté sur le déploiement d'un Openstack indépendant par PoP à cause justement de cette problématique du bus. La question de savoir si le déploiement d'Openstack supportera ou non l'impact du WAN sur RabbitMQ représente donc un besoin essentiel à la fois interne à Orange et externe (au niveau de la communauté OpenStack et de plusieurs partenaires dont AT&T et Red Hat).

about you

Compétences scientifiques et techniques :

OpenStack,

Etude et analyse de performance

Protocole publish/subscribe en particulier RabbitMQ/ZéroMQ/Qpid

Système Linux

Performance TCP

Développement logiciel, en particulier en python

additional information

Qu'est ce qui fait la valeur ajoutée de cette offre ?

Valoriser les outils mis à disposition, le contexte, le sujet, l'innovation, la participation à des projets collaboratifs…

department

Objectifs scientifiques-résultats attendus

Le premier objectif du post doc sera de caractériser de façon fine l'impact du WAN sur le comportement du bus de communication interne d'OpenStack, RabbitMQ, dans un environnement de cloud massivement distribué. Un précédent post doc a déjà réalisé le travail d'identification de la matrice de Traffic RabbitMQ (quels messages sont échangés entre quels composants d'OpenStack). Il s'agira ici de s'appuyer sur cette matrice de Traffic pour réaliser 1) des simulations permettant d'identifier les impacts potentiels du WAN sur les performances de l'échange des messages RabitMQ (typiquement en jouant sur la simulation des délais réseaux entre les différents composants OpenStack, les coupures de liens, les fenêtres TCP..) et 2) valider les résultats des simulations sur les plateformes physiques OpenStack disponbles dans l'équipe. Pour cette deuxième phase, une première version d'un générateur de trafic RabbitMQ a été développé par le précédent postdoc, il s'agira d'augmenter cet outil avec les évolutions nécessaires permettant de réaliser les scénarios de simulation que le postdoc va identifier. Dans la phase simulation et test, le postdoc réalisera également les différents tuning possible des paramètres RabbitMQ pour identifier si des optimisations sont possibles pour améliorer les performances du système. Les sources des problèmes constatés, que ce soit lors des simulations ou des tests fonctionnels, devront être identifiées clairement, par exemple, chercher si des pertes de messages RabbitMQ est imputée aux performance TCP suite à des coupures de lien ou au serveur RabbitMQ (le serveur qui sert de relais pour les messages entre les différents noeuds).

En fonction des résultats de cette premère phase, la deuxième phase peut consister soit à l'exploration d'une piste alternative pour l'implémentation du bus de communicaion interne d'OpenStack en cas de problèmes dures à résoudre avec RabbitMQ (par exemple ZéroMQ, ou qpid). Il s'agira ici de réaliser les mêmes simulations et test fonctionnels avec cette alternative et réaliser une analyse comprative des deux solutions. Si par contre, au travers des différents tuning possible des paramètres RabbitMQ, les résultats en termes de performance du système sont satifaisants, le postdoc pourra partager ces résultats avec la comunauté OpenStack, et en particulier nos partenaires direct sur le sujet (AT&T, Red Hat) en vue d'une publication externe.

contract

Post Doc