Cours cloud | OpenStack | Cloud computing\nEnregistrerEnregistrer Cours cloud pour plus tard\n13 vues141 pages\nNumeric Able s\nQuel futur pour le Cloud public ?\nMÉMOIRE PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE\nCOMME EXIGENCE PARTIELLE À L’OBTENTION DE LA MAÎTRISE AVEC MÉMOIRE EN GÉNIE CONCENTRATION : RÉSEAUX DE TÉLÉCOMMUNICATIONS M. Sc. A.\nPAR Hicham ABDELFATTAH\nANALYSE DE PERFORMANCE PAR PLANS EXPÉRIMENTAUX D’INTERGICIELS INFONUAGIQUES; LE CAS D’OPENSTACK\nMONTRÉAL, LE 4 MAI 2016\nHicham ABDELFATTAH, 2016\nCette licence Creative Commons signiﬁe qu’il est permis de diffuser, d’imprimer ou de sauvegarder sur un autre support une partie ou la totalité de cette oeuvre à condition de mentionner l’auteur, que ces utilisations soient faites à des ﬁns non commerciales et que le contenu de l’oeuvre n’ait pas été modiﬁé.\nCE MÉMOIRE A ÉTÉ ÉVALUÉ\nPAR UN JURY COMPOSÉ DE:\nM. Mohamed Cheriet, directeur de mémoire\nDépartement de génie de la production automatisée à l’École de Technologie Supérieure\nM. Abdelouahed Gherbi, président du jury\ndépartement de génie logiciel et des TI à l’École de Technologie Supérieure\nM. Kim Khoa Nguyen, membre du jury\ndépartement de génie électrique à l’École de Technologie Supérieure\nIL A FAIT L’OBJET D’UNE SOUTENANCE DEVANT JURY ET PUBLIC\nÀ L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE\nLes récents progrès dans la technologie de cloud computing ont fourni aux entreprises une oc- casion d’accroître leur proﬁt en se concentrant davantage sur leurs business sans se soucier de l’infrastructure matérielle sous-jacente. D’autre part, les opérateurs de cloud sont confrontés à de nouveaux déﬁs dans la gestion et le maintien de l’installation complexe comprenant une variété de calcul informatisé (computing), du réseau, de l’énergie et de l’infrastructure de re- froidissement, ainsi que les plates-formes de logiciels de cloud.\nPour améliorer leur efﬁcacité, les opérateurs de cloud requièrent des informations pertinentes sur leur infrastructure, en particulier le comportement de la plate-forme de gestion de cloud, que l’on appelle le Cloud Middleware. Une analyse globale de la performance du Cloud Midd- leware permettra d’identiﬁer ses forces et ses limites. Cependant, cette analyse est très difﬁcile en raison du grand nombre de composants du Cloud Middleware, et leurs connexions en silos. Dans cette thèse, nous présentons une approche de proﬁlage basée sur les plans d’expériences pour répondre à ce besoin. Nous évaluons la performance de OpenStack comme un Cloud Middleware basé sur différents scénarios pour déterminer le comportement des composants OpenStack et d’évaluer sa performance.\nNos expériences ont montré que le facteur le plus inﬂuence sur la performance du Cloud est le nombre d’instances créées et en cours d’exécution. Également en changeant les conﬁgura- tions de OpenStack, ce dernier peut supporter une grande quantité de charge allant jusqu’à 800 instances. Nous concluons que la performance d’OpenStack est contrôlée par deux paramètres qui sont corrélés ; le nombre de nœuds de calcul et le nombre de travailleurs à travers les Nova Controller et Neutron serveurs. Par ailleurs, la ressource consommée par OpenStack en termes d’unité centrale de traitement (CPU) augmente avec le nombre d’instances. La version actuelle de OpenStack (IceHouse) ne peut pas supporter plus de 800 instances et le temps nécessaire pour la création d’instances augmente de façon linéaire avec le nombre d’instances.\nVirtualisation, Nuage Informatique, Interlogiciel, proﬁlage, OpenStack, consommation des ressources, Plan d’expériences.\nOPENSTACK ASSESSMENT AS A CLOUD MIDDLEWARE USING DESIGN OF EXPERIMENT APPROACH. APPLICATION : OPENSTACK\nRecent advances in cloud computing technology have provided companies with an opportunity to increase their proﬁt by focusing more on their business with no worries about underlying hardware infrastructure. On the other hand, cloud operators are facing new challenges in ma- naging and maintaining complex facility comprising a variety of computing, network, energy, and cooling infrastructure, as well as cloud software platforms.\nTo improve their efﬁciency, cloud operators require relevant information about their infra- structure, in particular the behaviour of the cloud management platform, so called the cloud middleware. A holistic analysis of cloud middleware performance will help pinpoint on its strengths and limitations. However, such analysis is very challenging due to the large number of cloud middleware components, and their siloed connections. In this thesis, we present a pro- ﬁling approach based on design of experiments to meet this need. We evaluate the performance of OpenStack as a cloud middleware based on different scenarios to determine the behavior of OpenStack components and evaluate its performance.\nOur experiments showed that the most inﬂuencing factor on the performance of the cloud is the number of instances created and running. Also by changing the OpenStack conﬁgurations, it can support a larger amount of workload up to 800 instances. We conclude that the performance of OpenStack is controlled by two metrics that are correlated ; the number of compute nodes and the number of workers across Nova Controller and Neutron servers. Furthermore, resource consumed by OpenStack in terms of CPU increases along with the number of instances. The current version of OpenStack (IceHouse) can not support more than 800 cases and the time required for creating instances increases linearly with the number of instances.\nVirtualization, Cloud Computing, Cloud Middleware, Proﬁling, OpenStack, Re- source Consumption, Design of Experiments.\nAu terme de ce mémoire, je présente mes remerciements les plus sincères à mon encadrant du projet, Monsieur Mohammed Cheriet, Professeur titulaire à l’École de technologie supérieure et Directeur du laboratoire Synchromedia, pour son soutien, ses encouragements et ses orienta- tions précieuses, malgré les occupations et les responsabilités qu’il assume, durant ma période du projet. Ainsi, je souhaite que ce travail soit le modeste témoignage de ma haute considéra- tion et mon profond respect pour mon honorable professeur.\nJe voudrai aussi témoigner mes remerciements, à Monsieur Kim Nguyen, Professeur assis- tant et associé de recherche, au laboratoire Synchromedia, pour son appui et son soutien tout au long de ces deux années, pour ses efforts indéniables aﬁn de nous procurer un meilleur ap- prentissage. Aussi, je tiens à remercier vivement les membres du jury, pour leur de participation à l’évaluation de ce travail.\nMes remerciements s’adressent également aux membres du laboratoire Synchromedia, à mes amis, mes frères et ma sœur qui ont été toujours présents pour moi et qui m’ont toujours sou- tenu et encouragé. Enﬁn, un grand merci à l’ensemble des personnes qui ont participé de près ou de loin à l’élaboration de ce travail.\nÀ vous tous, je dis merci,\n2.1 Nuage informatique\n2.2 Cloud Middleware\nProvisionnement d’une instance\n2.4 Plan d’expérience\n2.5 Travaux connexes\n2.5.1 Travaux connexes sur le monitoring dans le Cloud\n2.5.2 Travaux connexes sur le Cloud Middleware\nLes métriques à superviser\n3.2 Méthode de la collecte de données\n3.2.1 Méthode liée à l’infrastructure\n3.2.2 Choix du plan expérimental\nDéﬁnition de l’objectif et la réponse\n4.2 Environnement expérimental\n4.2.1 Serveur de banc d’essai\n4.2.2 Déploiement du banc d’essai\nDéploiement de OpenStack\n4.3.1 Provisionnement d’une instance\n4.3.2 Plan factoriel complet\n4.4 Résultats Et interprétation\n4.5 Analyse des menaces à la validité\nINSTALLATION DE L’HYPERVISEUR KVM\nINSTALLATION DE COLLECTD\nANNEXE VIII RESOURCE CONSUMPTION ASSESSMENT FOR CLOUD MIDDLEWARE\nCaractéristiques des serveurs hébergeurs du banc d’essai\nNiveaux des variables indépendantes\nCréation et suppression de 100 instances sans modiﬁcation\nCréation et suppression de 100 instances après amélioration\nCréation et suppression de 500 instances sans modiﬁcation\nCréation et suppression de 500 instances après amélioration\nRésumé de la création et la suppression de 100 instances\nRésumé de la création et la suppression de 500 instances\nAnalyse de la Variance pour taux de réussi\nDiagramme des chapitres présentés dans cette mémoire\nDifférent modèle de service ainsi quelque application de chaque service\nAbstraction de la couche du Cloud Middleware\nEUCALYPTUS : Open-Source Cloud Computing Infrastructure An Overview\nOPENNEBULA : Open-Source Cloud Computing Infrastructure -\nOPENSTACK : Open-Source Cloud Computing Infrastructure -\nCloud monitoring : les motivations, les propriétés, les concepts de base et les orientations futures\nNombre de facteurs en fonction du nombre d’essais\nExemple de deux nœuds compute contenant des machines virtuelles appartenant à des multi locataires\nopération de matériel numérique régie par un débit constant de l’horloge\nProcessus de collecte de données pour les mesures de performance\nAlgorithme de la création et suppression des instances et la collecte de données\nMéthode de la collecte des données liée au cloud middleware\nl’organigramme de la méthodologie de travail proposée\nArchitecture abstraite de la topologie\nLes différents composants des services d’OpenStack utilisés\nles étapes nécessaires pour le provisionnement d’une machine\nDiagramme de Pareto pour la variable dépendante du système\nla communication entre le service de Neutron et de la Nova (21 à 23 la ﬁgure 4.3 )\nles différents éléments du neutron associer aux nœuds (controller et compute)\nVariation du CPU basé sur la charge de travail\nVariation du CPU basé sur la charge de travail pour la création et la suppression\nVariation du temps basé sur la charge de travail\nVariation du temps basé sur la charge de travail pour la création et la suppression\nIntegrated Tracing Proﬁling and Debugging\ndeep packet isnspection\nDynamic Host Conﬁguration Protocol\nL’ultime question que les grandes entreprises informatiques se posent tant au niveau des four- nisseurs de services qu’au niveau des opérateurs est : comment peut-on garantir des services toujours disponibles, faciles à manipuler pour les utilisateurs et avec moins d’implication de ces derniers, accessibles partout et en même temps rentables ! ? Ainsi, pour offrir un tel service avec une telle exigence, cela nécessite autant de travail conceptuel que de ressources informa- tiques, unité de calcul et de mémoire, pour acquérir un tel besoin.\nAu début, aﬁn de procurer et garantir un tel service, nous avons besoin des stations dédiées juste pour l’infrastructure qui doivent être en même temps bien structurées, complexes, et inter- connectées pour héberger ces services. De plus, en prenant en considération la consommation d’énergie électrique, la climatisation, la gestion et la maintenance de ces immenses matériels que ces entreprises payent par jour, ces facteurs impactent directement et négativement sur le proﬁt de l’entreprise ou ce que nous appelons le retour sur investissement (RSI) et augmentent le coût total de possession (CTP). D’après une étude qui a été faite par International Data Corporation (IDC) (boursas et al., 2008) nous estimons que les serveurs en entreprise utilisent jusqu’à 15% de la capacité totale de leurs ressources matérielles. Nous tirons de cette étude qu’il y a un grand écart entre l’achet et les retombés de ces serveurs.\nEn contrepartie, le concept de la virtualisation joue un rôle primordial pour remédier et res- treindre cet écart. Cette technologie a un impact remarquable et pertinent dans le domaine de la technologie de l’information et de la communication. Selon Hervé Renault (Directeur Tech- nique Europe du Sud pour VMware), la virtualisation ne s’arrête pas aux serveurs, mais touche également les applications critiques telles que les ERP, les bases de données ou les messageries. Il expose les bénéﬁces de cette évolution majeure à commencer par la réduction signiﬁcative\ndes coûts. (boursas et al., 2010). Avec la virtualisation , nous économisons jusqu’à 60 % sur les coûts d’investissement informatique, 30 % de réduction des coûts opérationnels et 80 % de la facture énergétique.\nToujours dans la même vague d’innovation, d’autres technologies ont émergé : en l’occurrence le nuage informatique (Cloud Computing) qui est un concept d’entreprise, englobant à la fois la virtualisation, la grille informatique, la technologie SOA et bien évidemment d’autres aspects informatiques. D’après la ﬁrme Brocade (Brocade,2012), 60 % des entreprises envisagent une migration vers le nuage informatique depuis l’année 2012. Ce concept permet aux entreprises de se focaliser au cœur du business, avec l’apparition des solutions commerciales, comme EC2 et S3 d’Amazon, Microsoft Azure (Microsoft, 2012). Actuellement, le system du cloud ofﬁce représente 8% de la totalité du marché des ofﬁces et atteindra 33% dans l’horizon de l’année 2017(gartner, 2013). Vu les avantages que le nuage informatique nous offre, de nombreuses entreprises décident d’étendre leurs infrastructures vers le nuage informatique.\nCependant, déployer de nouvelles solutions ou migrer des solutions existantes n’est pas une tâche facile ou négligeable qui se fait en quelques étapes. Par contre, cela est un processus assez complexe vu le grand nombre d’opérations prises en considération : comme l’utilisation de plusieurs services à la fois distribués et répartis dans le réseau, et nécessitant des bases de données d’un middleware et d’autres composants à conﬁgurer.\nPour garantir le bon fonctionnement et déroulement du cloud avec moins de tolérance des erreurs, nous avons recours au monitoring qui est un élément essentiel pour un tel environne- ment comme le Cloud. Le monitoring est un processus ayant pour but de faire le suivi et la gestion du ﬂux de travail qui circule dans le cloud : allant du bas niveau soit l’infrastructure, arrivant au niveau haut soit l’application et en passant par le middleware assure la communica- tion entre les deux extrémités. De plus, le monitoring aide également à évaluer la performance de l’ensemble du cloud à un niveau modulaire.\nL’émergence du concept du cloud computing chaperonne par plusieurs travaux de recherche, dont deux ont collaboré avec ce mémoire. Le projet EcoloTIC de la compagnie de télécom- munications Ericson ayant pour mission de développer une solution intégrale offrant entre autres une architecture de cloud computing pour les différentes technologies avec une basse consommation d’énergie et à faible empreinte de carbone. En effet, cela est réalisé par l’ana- lyse, le contrôle et la connaissance précise de la consommation des ressources aﬁn d’optimiser et d’utiliser ces derniers d’une manière efﬁcace, d’une part, et d’envoyer ces analyses de la per- formance au gestionnaire du cloud qui a pour rôle de manœuvrer le déroulement du système entier , d autre part.\nAussi, le projet CTPD(Cloud Tracing, Proﬁling and Debugging) de l’équipe de recherche sur le LTTng (DORSAL,2013) adapte son outil de traçage du système d’exploitation Linux, pour tracer les différentes communications entrant/sortant du système d’exploitation, des applica- tions et des différentes couches de la virtualisation, que la compagnie Ericson soutient dans ce projet. En développant des méthodologies appropriées dans les environnements du cloud com- puting, ces dernières donneront un plus au projet EcoloTIC par la vériﬁcation des messages circulant dans le système et par la détection des messages d’erreurs.\nCeci donne une idée mature sur la vision et la stratégie des grandes compagnies en inves- tissant sur ces nouvelles approches. Avec le proﬁlage du cloud middleware, en déterminant ces points forts avec ces limitations, notre projet de recherche jouera un rôle assez important dans les deux projets.\nEn effet, le Cloud Computing englobe et utilise plusieurs techniques et technologies à la fois. En outre, le Cloud Computing se base sur plusieurs aspects dont le modèle de service qui lui aussi se décompose en trois modèles, respectivement infrastructure en tant que Service, Plate-forme en tant que Service et Logiciel en tant que Service. Par conséquent, avant de nous\nplonger dans la recherche scientiﬁque, nous sommes censés ﬁxer notre travail de recherche. De ce fait, il est très important de mettre en évidence et de souligner les objectifs de cette recherche en élaborant une stratégie de méthodologie du travail aﬁn de bien proﬁter de cette expérience académique.\nComme dans toute technologie, le Cloud Computing s’appuie sur des modèles architecturaux. Le modèle de service qui nous intéresse le plus, est le modèle infrastructure en tant que service. Nous pouvons dire que ce service est la base ou la première couche inférieure dans le Cloud Computing. Notre recherche sera fondée plus précisément sur le Cloud Middleware qui est, entre autre, une couche sous-jacente permettant de réaliser cette infrastructure du Cloud.\nL’objectif principal de cette présente recherche est de développer une méthodologie de pro- ﬁlage ayant pour but d’évaluer, d’estimer et de calculer la performance du Cloud Middleware d’une manière précise et d’établir une étude pointue de l’impact du Cloud Middleware sur les ressources matérielles utilisées.\nEn effet, ce genre de proﬁlage du Middleware permettra la supervision et la prédiction de sa performance sur des différentes infrastructures. Il nous aidera à mettre le doigt sur la(s) composante(s) du middleware cloud ayant un impact direct sur les ressources physiques utili- sées. Ceci a pour but d’améliorer l’efﬁcacité du Cloud. Car nous avons deux autres services qui s’ajoutent au-dessus de cette couche. Par conséquent, la performance de cette dernière joue un rôle primordial sur la performance de la totalité du cloud computing.\nLe proﬁlage dans le Cloud Middleware est généralement une approche que nous utilisons aﬁn de nous aider à répondre à la question : pourquoi de certaines conditions nous obtenons un tel résultat, cela permet de donner une idée sur l’origine du problème. Aussi, cela nous aide à connaitre et à détecter la limite de saturation ou la dégradation de la performance du système ciblé.\nCeci dit, pour arriver à proﬁler, il faut tout d’abord modéliser le Cloud Middleware en met- tant le point sur les facteurs et les composants du système. Cela est une étape très importante dans le processus du proﬁlage. Ensuite, il faut adopter une méthode pour évaluer les perfor- mances du Cloud Middleware d’une manière précise et efﬁcace et surtout moins couteuse en terme de temps d’évaluation.\nL’objectif principal est traduit en trois sous-objectifs :\nPremièrement, choisir le Middleware souhaité et basé sur des études antérieures. Deuxième- ment, extraire les éléments qui entrent en jeux sur la performance du cloud middleware choisi, ceci sera basé sur les plans d’expérience. Troisièmement, nous illustreront un bilan qui mon- trera l’inﬂuence du cloud middleware sur les ressources physiques du serveur, à savoir CPU et la mémoire RAM. Cela mettra le point sur l’impact du Cloud middleware et sur la performance de ces derniers.\nTrès souvent, nous lions la mauvaise performance au manque des ressources comme (bande passant, stockage, mémoire vive, le cycle de CPU, réseau et autre). Mais, la non satisfaction de la performance est le résidu de plusieurs facteurs.\nNous citons la nature de l’environnement distribué qui peut impacter directement et négati- vement sur la performance du système entier par la défaillance de l’un de ses composants.\nDe plus, ces composants sont eux aussi encapsulés dans différentes couches hétérogènes, à savoir matériel physique, type de virtualisation, type de liaison réseau ou système de ﬁchiers utilisé et autres. De ce fait, l’inﬂuence de cette dernière est remarquable sur la performance de ces types d’environnement. Tout ceci entraîne une mauvaise distribution des processus sur l’ensemble des ressources disponibles.\nÉtant donné un Cloud middleware, nous n’avons pas une connaissance préalable et pratique sur le comportement du système sous une chaine de production. En outre, acquérir un appren- tissage du fonctionnement du système, nous pousse à ramener une étude qui nous permettra de proﬁler le cloud middleware. De ce fait, nous répondons aux questions suivantes :\n1 Déﬁnir une liste appropriée des paramètres de performances : pour toutes les opérations/- requêtes exécutées sur le Cloud Middleware, il est primordiale de déﬁnir précisément et sufﬁsamment l’ensemble des paramètres de la performance du Cloud middleware qui entre en jeux. Le processus du proﬁlage est basé sur cette déﬁnition qui caractérise le système étudié. Alors, quelles sont les métriques de performance nécessaires à prendre en considération qui décrivent un Cloud middleware ?\n2 Collecter des données à moindre coût : aﬁn d’obtenir des résultats précis, l’impact des méthodes utilisées pour la collecte des données doivent être négligeable en terme d’in- ﬂuence sur les paramètres de la performance ciblée. Alors, quel est l’outil le plus adéquat qui garantit que les valeurs extractives sont les plus objectives possibles pour la collecte des données de la performance ?\n3 Modéliser la performance du Cloud Middleware : dans le cas de perturbation ou de dé- gradation des performances des systèmes souvent, nous les joignons à des facteurs qui ne sont pas réels ou qui ne sont pas liés directement aux causes du problème. Ceci revient au manque de connaissance du système ou à la manière de conception de l’étape d’ana- lyse. Alors, de quelle manière pouvons nous extraire les facteurs ou les composants qui impactent directement sur la performance du Cloud Middleware ?\n4 - Calculer l’impact des ressources physiques sur la performance du Cloud Middleware :\nnotons ici qu’il aura toujours une couche physique qui gérera le Cloud Middleware que lui-même manipulera les machines virtuelles créées par ce dernier. Ainsi, le ﬂux de com- munication est très fréquent entre le Middleware et les machines virtuelles. Alors, com-\nment pouvons-nous préciser l’inﬂuence de la couche physique et le niveau de saturation de cette dernière sur la performance du Cloud Middleware ?\n5 - Évaluer le modèle de performance dans un banc d’essai réel : les expériences des modèles de virtualisation ont prouvé que c’est une approche très économique, d’où très rentable en termes de coût aux entreprises. Mais, dans ce cadre-ci, le Cloud midleware basé sur le concept de virtualisation peut-il être lui aussi ﬁable et rentable pour les entreprises ?\nD’autres questions peuvent être soulevées dans la problématique du proﬁlage dans le Cloud Middleware : notamment, la comparaison de performance et l’impact sur le Cloud Middleware entre les deux types de virtualisation soit le type 1 et le type 2 comme XEN et KVM respective- ment. Mais, vu la limite du temps de la maitrise, nous nous limiterons aux questions présentées ci-dessus.\nNotre mémoire s’articule autour de cinq chapitres comme le montre l’organigramme dans la synoptique Fig.1.1.\nChapitre 1 est une introduction générale qui met en évidence le contexte de travail du mé- moire, l’objectif de notre recherche et les problèmes reliés à ce dernier.\nChapitre 2 est une revue littérature qui se compose de quatre sections. Nous commencerons par une introduction. Ensuite, la deuxième section sera consacrée au Cloud computing, nous présenterons les modèles de services et du déploiement aussi, nous ferons un survol sur les différentes architectures du Cloud Middleware existantes ainsi qu’une critique des solutions de ces applications déjà présentes. Puis, la troisième section portera sur le monitoring en général et le monitoring dans le Cloud. Entre autre, nous présenterons les travaux connexes de ce sujet de recherche. Nous clôturerons ce chapitre par une conclusion.\nChapitre 3 se focalisera sur la méthodologie de travail optée pour réaliser ce mémoire. Dans cette partie, nous illustrons les hypothèses et la conception du modèle proposé, nous détaillons les différentes études comparatives basées sur des critères bien structurés qui feront entre autres les réponses aux différentes questions et déﬁs présentés dans le premier chapitre de la partie problématique. Ces études seront utilisées dans la réalisation de ce projet de recherche.\nChapitre 4 illustre un cas d’étude concret du proﬁlage d’un Cloud Middleware, et discute les expérimentations effectuées pour valider notre modèle proposé. Enﬁn, la conclusion de ce tra- vail récapitule le bilan de ce qui est réalisé et les recommandations pour les futurs travaux tant pour les développeurs que pour les utilisateurs du nuage.\nLe dernier chapitre sera dédié à synthétiser le travail réalisé, et à présenter des idées pour des travaux futurs.\nCe chapitre présente une revue de littérature des différents aspects théoriques qui nous mènera à comprendre le problème de ce projet de recherche. En effet, ce chapitre s’appuie autour de quatre sections. D’abords, nous allons mettre le point sur le concept du nuage informatique, ses modèles de service, ainsi, nous présenterons le concept du Cloud middleawre puis, nous introduirons les différences plates-formes du Cloud Middleware existant dans la littérature et étant les plus pertinentes et les plus utilisées ; enﬁn, la dernière partie sera dédiée au proﬁlage en général, nous focaliserons sur le proﬁlage dans le Cloud et nous présenterons les travaux connexes de ce projet.\nLe concept du Cloud computing s’appuie sur la délivrance des ressources informatiques. D’après le NIST1, il déﬁnit « l’informatique dans les nuages » en tant que modèle informatique of- frant des ressources comme (réseaux, serveurs, stockages, applications, services) aux clients en fonction de leurs besoins, ce qui permet l’accessibilité : n’importe où, n’importe quand et par n’importe qui.\nCes derniers peuvent être partagés entre plusieurs clients à la fois et conﬁgurés selon leurs demandes. Cela nous ramène à un autre concept primordial dans le Cloud qui est la virtualisa- tion. La virtualisation permet une gestion optimisée des ressources matérielles, autrement dit, avoir la possibilité d’exécuter plusieurs systèmes virtuels sur une même ressource physique partagée. Avec cette ﬂexibilité, nous pouvons exploiter les ressources le maximum possible avec un effort minimal au niveau client.\nLe nuage informatique est divisé en trois parties à savoir : le fournisseur (Provider), le client (Customer) et l’utilisateur (user).\nLes fournisseurs offrent des services à l’utilisateur ﬁnal en allouant les ressources physiques comme des centres de données de la technologie de virtualisation. Cela permet aux clients de commencer leur activité sans avoir à investir dans le matériel physique pouvant être acquis en le louant des fournisseurs.\nIl existe trois modèles de services Cloud : Software as a Service (SaaS), Platform as a Ser- vice (PaaS) et Infrastructure as a Service (IaaS). Chaque modèle de services en nuage offre un niveau d’abstraction qui réduit les efforts requis par le consommateur de service pour créer et déployer des systèmes.\n2.1.1.1 Infrastructure en tant que Service\nThe National Institute of Standards and Technology déﬁnit IaaS : La capacité fournie aux consommateurs est la capacité du traitement, le stockage, les réseaux et autres ressources in- formatiques fondamentales où le consommateur est en mesure de déployer et d’exécuter le logiciel donné, qui peut inclure des systèmes d’exploitation et d’applications. Le consomma- teur ne gère ou ne contrôle pas l’infrastructure Cloud sous-jacente mais il la contrôle via les systèmes d’exploitation, le stockage et les applications déployées.\nComme OpenStack est une infrastructure en tant que service, il assure le contrôle des grands bassins de calcul, de stockage et les ressources réseau à travers un centre de données, gérées par un tableau de bord ou via l’API OpenStack.\nD’une manière technique IaaS donne un sens de son utilité dans des situations qui sont par-\nticulièrement adaptées dans l’infrastructure de Cloud :\n– lorsque la demande est très volatile ; en tout temps il y a des pointes importantes et des creux en termes de demande sur l’infrastructure ;\n– lorsque la demande est très volatile ; en tout temps, il y a des pointes importantes et des creux en termes de demande sur l’infrastructure ;\n– pour les nouvelles organisations sans capital à investir dans l’infrastructure physique ;\n– lorsque l’organisation est en croissance rapide et le matériel de mise à l’échelle serait pro- blématique ;\n– pour des raisons spéciﬁques, procès où les besoins en infrastructures sont temporaires. Des exemples d’infrastructure en tant que Service, nous trouvons : Amazon web services, rackspace, IBM, Mirosoft, Vmware, etc.\nAvec ce modèle, l’utilisateur s’intéressera plus à la conception et la gestion de ces applica-\ntions, au lieu de s’inquiéter à gérer les centres de données et leur infrastructure. Fig.2.1 page\nThe National Institute of Standards and Technology déﬁnit PaaS : La capacité fournie au consommateur est de déployer les applications sur l’infrastructure Cloud consommatrice créée ou acquise à l’aide des langages de programmation, des bibliothèques, des services et des outils supportés par le fournisseur. Le consommateur ne gère pas ou ne contrôle pas l’infrastructure Cloud sous-jacente, y compris le réseau, serveurs, systèmes d’exploitation, ou le stockage, mais il les contrôle via les applications déployées.\nD’un point de vue pratique, PaaS est particulièrement utile dans toute situation où plusieurs développeurs vont travailler sur un projet de développement ou lorsque d’autres parties ex- ternes ont besoin d’interagir avec le processus de développement. Aussi, PaaS est utile lorsque\nles développeurs souhaitent automatiser les services de test et de déploiement.\nLa popularité de développement logiciel agile, un groupe de logiciels méthodologies de dé- veloppement basées sur le développement itératif et incrémental, permettra également d’aug- menter l’absorption de PaaS car il facilite les difﬁcultés autour de développement rapide et l’itération de logiciels. Fig.2.1 page 15.\nDes exemples de plate-forme en tant que Service : nous pouvons les subdiviser en quatre caté- gories, nous citons :\n– Application frameworks : Google app Engine, CloudBees, IBM luemix, etc ;\n– Big Data & storage : CLOUDANT, Amazon web services, platfora, etc ;\n– Platform integrators : heroku, Joyent, Engine yard, etc ;\n– Turnkey back-end : kinvey, Buddy, etc.\n2.1.1.3 Logiciel en tant que Service\nThe National Institute of Standards and Technology déﬁnit PaaS : La capacité fournie aux consommateurs est d’utiliser les applications du fournisseur fonctionnant sur une infrastruc- ture de Cloud. Les applications sont accessibles à partir de divers périphériques clients par le biais soit d’une interface client légère, comme un navigateur Web (par exemple, le courrier électronique basé sur le Web), ou une interface de programme. Le consommateur ne gère ni ne contrôle l’infrastructure Cloud sous-jacente, y compris le réseau, serveurs, systèmes d’exploi- tation, de stockage, ou même les capacités individuelles d’application, à l’exception possible des paramètres de conﬁguration d’application spéciﬁques à l’utilisateur limité.\nD’une manière technique, SaaS est une méthode de plus en plus rapide pour livrer la tech- nologie. Cela dit, les organisations qui envisagent de passer vers le Cloud, vont envisager les\napplications qu’elles déplaceront à SaaS. Comme tel, il existe des solutions particulières que nous considérons comme candidat pour un mouvement initial au SaaS ;\n– applications où il y a des interactions signiﬁcatives entre l’organisation et le monde extérieur. Par exemple, les logiciels d’email campagne de bulletin (newsletter campaign software) ;\n– les applications qui ont un besoin important pour le Web ou l’accès mobile. Un exemple serait le logiciel de gestion des ventes mobiles ;\n– le logiciel qui peut être utilisé pour un besoin à court terme. Un exemple serait le logiciel de collaboration pour un projet spéciﬁque ;\n– un logiciel des pics de demande de manière signiﬁcative, par exemple l’impôt ou d’un logi- ciel de facturation utilisé une fois par mois. Des exemples de logiciel en tant que Service, nous trouvons : salesforc.com, Amazon.com, microsoft, Google, etc.\nAprès avoir mis le point sur le Cloud computing, dans les sections précédentes, nous allons donner une brève déﬁnition du terme (Middleware) avant d’entamer le Cloud Middleware.\nLe terme Middleware Cloud est un autre composant du nuage. Un logiciel qui est appelé in-\nterlogiciel (Middleware), est utilisé pour intégrer des applications de services et de contenus disponibles sur le nuage. Ce dernier est né avec l’apparition des systèmes distribués et se réfère\nà un ensemble de services standardisés tels que les APIs, les protocoles et les services d’infra- structure.\nCes derniers sont utilisés pour soutenir le développement rapide et pratique des services et des applications distribuées, basé sur le modèle Client/Serveur. Les principales caractéristiques clés du Middleware de nuage sont la gestion des données, l’identité, la sécurité, le service d’héber-\ngement (hosting), de médiation et de gestion, le réseautage, l’interface utilisateur et de portails, la facturation le monitoring et la surveillance. La ﬁgure2.2 illustre que Middleware joue un rôle crucial sur l’intégration et l’interopérabilité des applications et des services fonctionnant sur des appareils informatiques hétérogènes. Il existe différentes solutions du Middleware Cloud,\nà savoir : OpenStack, OpenNebula, Nimbus, Eucalyptus et autre.\nEucalyptus Figure 2.3 était créé et conçu pour répondre au besoin de EC2 Cloud commer- cial. L’interface simple du service Web Amazon EC2 nous permet d’obtenir et de conﬁgurer des capacités avec un minimum d’efforts. Elle fournit un contrôle complet de nos ressources informatiques et nous permet d’exécuter notre application sur l’environnement informatique d’Amazon qui a fait ses preuves. Amazon EC2 réduit le temps requis pour obtenir et démarrer de nouvelles instances de serveurs à quelques minutes, ce qui vous permet de dimensionner rapidement la capacité, de l’augmenter et de la diminuer, au fur et à mesure des modiﬁcations de vos besoins de calcul. Amazon EC2 change l’aspect ﬁnancier de l’informatique en permet-\ntant de ne payer que pour la capacité que vous utilisez effectivement. Amazon EC2 fournit aux développeurs les outils pour construire des applications résilientes tout en évitant les scénarios de défaillance les plus courants (Amazon Web Services, 2015).\nEucalyptus s’appuie sur la décentralisation des ressources autant que possible, comme, le sto- ckage utilisant un système appelé « Walrus » qui imite d’Amazon S3. Ce stockage est séparé en structure et distribué dans le Cloud. Ce mode de stockage permet aux virtuelles machines de s’exécuter indépendamment du nœud compute. Eucalyptus permet d’avoir des groupes mul- tiples (un groupe de contrôleurs et un autre pour les interfaces des utilisateurs).\n2.2.1.1 Provisionnement d’une instance\nL’utilisateur utilise euca2ools pour demander une VM. L’image est chargée du Walrus (sto- ckage virtuel) au nœud cluster Controller (CC) puis vers Node Controller (NC), ensuite un espace de block storage est associé à cette VM. Par la suite, le Node Controller (NC) joint un bridge pour joindre une carte réseau virtuelle (NIC) avec une adresse MAC virtuelle. Enﬁn, la VM est créée et prête à être utilisée, l’utilisateur peut y accéder via protocole SSH Figure 2.3.\nOpenNebula Figure 2.4 se pose plus pour la centralisation et la personnalisation. Ils peuvent\npersonnaliser le ﬁchier de partage du système utilisé pour le stockage des ﬁchiers du OpenNe-\nbula (par défaut ils utilisent NFS pour toutes les images et ﬁchiers en exécution). Il permet la\nmigration des VMs. De plus, le nœud compute requiert peu de ressources au niveau du disque\ndur vu que l’architecture d’OpenNenula est centralisée.\nEn revanche, cet accès à la personnalisation peut affecter la sécurité puisque le ﬁchier du sys-\nOPENNEBULA : Open-Source Cloud Computing Infrastructure - An Overview\ntème NFS ne chiffre aucun traﬁc. Aussi, il exige de l’administrateur et l’utilisateur d’avoir\ndes connaissances préalables pour tirer proﬁt du système et pour ajouter d’autres caractéris-\ntiques par la suite, selon le besoin. Notons aussi que ce genre de Platform est conçu pour un\nnombre moyen d’utilisateurs connectés à ce type de Cloud. Ce genre de Cloud peut aider les\nchercheurs à exploiter d’autres axes de recherche en combinant ce type de Cloud avec d’autres\ntechnologies comme SGE ou Condor.\n2.2.2.1 Provisionnement d’une instance\nPremièrement, l’utilisateur utilise le protocole SSH pour se connecter au nœud de tête (cluster\nNode) pour faire une demande de VM. Deuxièmement, une copie du OS est associée avec une\ntaille de disque à cette VM et conﬁgurée dans le répertoire NFS sur le nœud principal (Frontend\nNode). Troisièmement, le processus Node sur le nœud Frontend utilise ssh pour se connecter\nà un nœud compute dans le cluster Node. Quatrièmement, le nœud compute met en place un\nbridge de réseau pour fournir une carte réseau virtuelle (NIC) avec une adresse MAC virtuelle.\nCinquièmement, les ﬁchiers nécessaires pour le hyperviseur sur le nœud compute seront tirés\ndu NFS puis la VM est prête à l’utiliser. Enﬁn, l’utilisateur peut maintenant se connecter au\nVM via SSH directement.\nOPENSTACK : Open-Source Cloud Computing Infrastructure - An Overview\nOpenStack est une collection de plusieurs composantes open-source qui assure les deux types\nde Cloud « privé et public ». Parmi ses composantes, nous trouvons : OpenStack Compute\n(nommé Nova), OpenStack Object Storage (nommé Swift), OpenStack Image Service (nommé Glance). OpenStack prend de l’existence entre les compagnies grâce à son open source et au support de plusieurs compagnies.\nNova est conçu pour procurer et gérer le réseau virtuel des machines, créer une plate-forme de Cloud computing redondante et évolutive. Pour le Swift, il est utilisé pour créer un objet de stockage redondant et évolutif en utilisant des clusters de serveurs standardisés pour sto- cker des pétaoctets de données accessibles. Ce n’est pas un ﬁchier de système ou système de stockage de données en temps réel, mais plutôt un système de stockage à long terme pour des données plus permanentes ou statiques. Glance garantit la découverte et l’enregistrement. Il associe les ressources nécessaires aux images des disques virtuels via le Service image (nous aurons plus de détails dans le quatrième chapitre).\n2.2.3.1 Provisionnement d’une instance\nL’utilisateur utilise Horizon (dashboard) pour s’identiﬁer et demander une machine virtuelle. Keystone authentiﬁe l’utilisateur et retourne l’entrée de l’instance avec la mise à jour du hôte ID approprié après ﬁltrage lié à ce dernier. Nova prend les informations d’instance de la ﬁle d’attente et obtient les méta-données de l’image. Puis, il alloue et conﬁgure le réseau pour l’instance à une adresse MAC et IP. Ensuite, il obtient l’information de stockage par bloc. Enﬁn, NOVA génère les données pour le pilote de l’hyperviseur et exécute la demande sur l’hyperviseur (via libvirt ou api) Figure 2.5 (plus de détail dans le quatrième chapitre).\nLe pilotage ou monitoring d’un système donné implique la mise en place d’un processus struc- turé aﬁn d’évaluer leur performance. Il consiste à mesurer et à comparer les composantes du système lui même dans différentes circonstances.\nEn effet, quand nous parlons du monitoring, nous soulevons plusieurs questions, à titre d’exemple :\nen quels sens nous nous focalisons pour mesurer la performance ? Comment et quels sont les facteurs adéquats ? Existe-il une base de référence qui aidera à qualiﬁer la performance ? Quelles sont les explications des dérives et quels sont les indicateurs inﬂuents ? (Olivier Baude, 2010) ainsi, d’autres questions peuvent être soulevées et discutées !\nEn réalité, le monitoring touche divers champs de recherche, à savoir : le domaine des sciences et de la technologie, la médecine, l’écologie, les sciences sociétales, l’électronique et le do- maine de l’informatique, ainsi que d’autres aspects de recherche. Dans notre recherche, nous nous intéressons plus au volet de l’informatique.\n2.3.1 Monitoring dans le cloud\nDu point de vu fournisseur ou/et consommateur, le Cloud monitoring est une opération très importante et primordiale. D’un côté, il est un outil clé pour le contrôle et la gestion des infra- structures matérielles et logicielles ; d’autre côté, il fournit d’une manière continue des infor- mations et des indicateurs clés de performance (Key Performance Indicators (KPIs)) comme (disponibilité, délai, qualité service offert par le Cloud, consommation des ressources etc.) pour les plates-formes et les applications. Permettant à ces derniers de mettre en œuvre des méca- nismes visant à prévenir (à la fois pour le fournisseur et les consommateurs).\nEn termes plus généraux, Cloud Computing implique de nombreuses activités pour lesquelles le monitoring est une tâche essentielle, voir ﬁgure 2.6. Dans la suite de cette sous-section, nous allons analyser attentivement les activités qui nous intéressent dans ce mémoire, en soulignant le rôle du monitoring.\nÀ partir de la ﬁgure 2.6 nous avons plusieurs motifs qui nous poussent à faire le monito- ring. Nous allons mettre le point sur trois besoins (facteurs) qui sont utilisés pour analyser la performance du Cloud Middleware, d’une part, et aﬁn de tester Cloud Middleware qui est une couche essentielle dans le concept du Cloud Monitoring d’autre part.\nCloud monitoring : les motivations, les propriétés, les concepts de base et les orientations futures Tirée de Aceto et al. (2013)\nDans le monde de la recherche, l’expérience est le seul moyen aﬁn de valider les approches proposées ou d’arriver à une conclusion constructive. Nous pouvons déﬁnir une expérience comme un test ou une série d’essais dans lesquels les modiﬁcations délibérées sont appor- tées aux variables d’entrée d’un processus ou d’un système aﬁn que nous puissions observer et identiﬁer les raisons des changements qui peuvent être observés dans la réponse de sortie. Les plans d’expériences étaient introduits par le statisticien anglais Ronald A. Fisher dans les années 1930. À ses débuts, les premières modélisations étaient concentrées sur les domaines agricole et médical (chimie). Par ailleurs, à partir des années 80, les plans d’expériences furent une croissance exponentielle, touchant d’autres domaines comme les domaines de génies.\nEn effet, il existe deux classes des plans d’expérience : soit les Plans de surface de réponse (MONTGOMERY, 2001c), soit les plans factoriels (MONTGOMERY, 2001b), souvent leurs facteurs sont des variables continues et discrètes respectivement. Nous nous intéressons à la deuxième classe : les plans factoriels. Cette classe contient deux grandes catégories de plans :\nplans complets et plans factoriels fractionnaires.\nLes plans complets 2 f ont un désavantage si nous considérons que le nombre f est supérieur\nà cinq, ce qui devient inapplicable et inefﬁcient. La ﬁgure 2.7 explique que le nombre d’es-\nsais croit rapidement quand le nombre de facteurs augmente. De ce fait, dans certain cas, nous avons recours à des solutions alternatives comme les plans factoriels fractionnaires (MONT-\nGOMERY, 2001d) aﬁn de minimiser le coût (matériel, matière, personnel\nl’expérimentation. Souvent ces plans sont à deux niveaux 2 f−p . Par exemple, pour un plan\nà six facteurs nous nous rendons à 64 essais, dans le cas où nous négligeons les interactions\n) et le temps de\ntriple et quadra, nous n’appliquons qu’une fraction des essais du plan complet. Si nous voulons la moitie du plan complet, le plan est dit 2 6−1 ou le quart 2 6−2 ou le huitième 2 6−3 etc.\nBien choisir les essais signiﬁe bien sélectionner les facteurs ce qui revient à l’utilisation du\nplan factoriel fractionnaire. Les plans factoriels fractionnaires sont des fractions des plans fac- toriels complets permettant de réduire le nombre d’essais à effectuer : d’où l’économie dans les expériences. Bien que nous réduisons l’espace des essaies, la qualité du résultat n’est pas ga- rantie, mais si nous travaillons dans un cadre de contrôle et si nous choisissons bien les essais, cela peut être bénéﬁque.\nDans cette section, nous mettrons le point sur les travaux connexes que nous jugeons travaux potentiels pour notre mémoire de recherche et qui sont en relation avec notre problématique de recherche ; soit le proﬁlage dans le soul qui englobe les métriques utilisées pour analyser la performance du Cloud, ainsi que son impact sur l’infrastructure du Cloud. Ces travaux tournent autour de l’analyse des performances, en termes de consommation des ressources dans les nuages.\nCette présente sous-section portera une analyse des articles qui ont soulevé la problématique de la performance des applications qui sont hébergées dans le Cloud.\nEn (Shao et al., 2010), les auteurs ont proposé une méthode d’analyse, basée sur la corréla- tion canonique (CCA) aﬁn de proﬁler les applications hébergées dans des machines virtuelles placées dans le Cloud, pour identiﬁer la relation entre les performances des applications et les performances du système (consommation des ressources).\nPuisque les besoins des ressources pour les machines virtuelles exécutant différentes appli- cations sont dynamiques, alors, il est essentiel d’établir une relation entre la performance des applications en cours d’exécution à l’intérieur des machines virtuelles et la charge de travail dans un nœud physique ciblé. En d’autres termes, avant de placer la machine virtuelle sur le nœud physique, les auteurs ont pensé à modéliser une manière de prédiction de performances raisonnables qui aidera à prendre la décision en choisissant le nœud physique du Cloud qui va être cette machine virtuelle avec sa propre application.\nL’idée des auteurs est d’associer un vecteur de poids canonique à chaque facteur qui représente le niveau d’implication (consommation des ressources) lié au système en corrélation avec les performances de l’application.\nLes résultats montrent que le CCA est capable de trouver la relation entre le système et les performances des applications. Aussi, les tests prouvent que la vitesse de l’écriture I/O est le principal facteur qui est responsable de la performance des applications. Ils ajoutent qu’il y a une forte corrélation entre la performance des applications fonctionnant sur les machines virtuelles et les ressources matérielles des nœuds physiques. Ils concluent que les paramètres, avec un poids élevé dans le proﬁl d’application, ont une précision de prédiction élevée pour être facteur clé pour la qualité de la performance.\nNotre critique de cet article sera basée sur le fait que les auteurs se sont focalisés sur l’extrac- tion de la relation entre l’application exécutée sur la machine virtuelle et la couche physique qui sont les ressources matérielles sans prendre en considération quel type de Cloud Middleware est utilisé. Autrement dit, ils ont négligé la présence du Cloud Middleware et que ce dernier\na aussi un impact sur la performance de la totalité du système : soit sur le niveau application, soit sur le niveau matériel. En effet, des travaux comme (Caron et al., 2013) (Laszewski et al., 2012), (Kurup et al.), (Ueda et Nakatani, 2010), (Sempolinski et Thain, 2010) et (Voras et al., 2011) ont adressé le choix du Middleware comme une étape primordiale, car elle inﬂuence sur la performance des applications.De ce fait, la majorité de ces travaux ont favorisé l’utilisation du Cloud Middleware "OpenStack" sur les autres plates-formes (Eucalyptus, Nimbus et Open- Nebula).\nDans (Zabolotnyi et al., 2014) également, les auteurs ont mis en évidence le problème de sur-approvisionnement de l’utilisation des ressources physiques, par les applications, sans les utiliser d’une manière efﬁcace, ce qui engendre des pertes : au niveau ﬁnancier et/ou au niveau de gaspillage des ressources physiques. Aﬁn d’optimiser l’utilisation des ressources, ils ont proposé une nouvelle approche de proﬁlage fondée sur la planiﬁcation des tâches uniformes (qui exigent un nombre de CPU et une capacité de mémoire RAM telles que les applications de traitement d’image satellitaire produisant 1 petabyte (PB) de taille d’image par seconde et qui sont prédéﬁnies par les développeurs avec l’utilisation des ressources non uniformes et les distribuent sur le nuage avec une connaissance préalable des limitations des ressources.\nEn effet, dans cet article, ils ont abordé la question de l’utilisation efﬁcace et de l’élasticité des ressources du Cloud. Habituellement, les tâches exécutées dans le nuage n’utilisent pas les ressources (par exemple, mémoire, CPU ou de bande passante du réseau) d’une manière uniforme. Au lieu de cela, au cours d’exécution de la tâche, l’utilisation des ressources varie, provoquant des pics d’utilisation et des vallées. Aﬁn d’obtenir des temps d’exécution efﬁcaces et prévisibles, les développeurs ont à réserver des ressources en tenant compte de l’utilisation maximale que cette application peut atteindre.\nPour avoir des informations à jour et exactes sur le comportement de l’application dans chaque nœud physique (nuage hôte), l’application est surveillée par un système de proﬁlage spécial. Le proﬁler est en cours d’exécution dans l’application sur chaque nœud de nuage utilisé et\nrecueille les informations nécessaires pour l’extension des décisions. Actuellement, cette in- formation comprend l’utilisation de la mémoire par des sous-processus, en relation avec les tâches exécutées sur ce nœud et l’utilisation du processeur de la machine, aﬁn d’éviter un éventuel chevauchement au niveau de l’agrégation de la charge en cas du pic.\nL’approche consiste en deux phases : préapprentissage de la consommation des ressources en classant les tâches, puis les proﬁls aux besoins des ressources. Après cela, une nouvelle tâche planiﬁée sera associée à la prédiction de l’utilisation des ressources qui est construite par la première étape. Ils comparent deux tâches avec et sans proﬁlage basées sur la planiﬁcation. Les résultats montrent que cette approche pourrait économiser 33 % de mémoire et 1 % de temps pour terminer la même tâche.\nNotre critique de cet article est la suivante : ils se sont concentrés sur un sous-ensemble spé- ciﬁque d’applications Cloud Computing qui consistent à utiliser un ensemble de taches uni- formes dans un ensemble de ressources physiques non uniformes. De ce fait, nous pouvons dire que cette approche ne pourra pas être généralisée pour une application quelconque .Aussi, cette approche vise la troisième couche Cloud Computing qui est la couche application service, ceci ne tient pas en compte qu’il y a aussi une inﬂuence de couche infrastructure qui a pour rôle d’orchestrer, d’acheminer les taches au nœud approprié et surtout de contrôler tous le système du Cloud.\nDans cet article, (Mian et al., 2013), ils examinent le problème de l’approvisionnement des ressources dans un Cloud public aﬁn de traiter l’analyse des données reliées à des charges de travail. Ils ont développé une méthode de provisionnement qui a pour but de déterminer quelle est la conﬁguration la plus rentable pour une charge de travail d’analyse de données. Ils consi- dèrent qu’une conﬁguration rentable est celle de telle sorte que les coûts des ressources soient réduits au minimum, tandis que les Service Level Agreements (SLA) associés à la charge de travail soient au maximum.\nIls ont proposé une formulation du problème de provisionnement basé sur une méthode heu- ristique avec deux variantes ( heuristique gloutonne et heuristique gloutonne adaptée) en vue de déﬁnir un cadre pour résoudre le problème. Ce cadre de travail contient un modèle de coût pour prédire le coût d’exécution d’une charge de travail sur une conﬁguration et un procédé de sélection de conﬁgurations la plus adéquate. Le modèle de coût tient en considération à la fois, les coûts des ressources et les pénalités de SLA. Les demandes et les fréquences de ressources spéciﬁées sont comptabilisées en ﬁl d’attente des modèles de réseaux de machines virtuelles, qui sont utilisés pour prédire la performance.\nCette approche, en matière de provisionnement des charges de travail d’analyse de données d’échantillons, était testée sur la plate-forme Amazon EC2. Les prévisions de coûts de ce mo- dèle pour les charges de travail de l’échantillon sont à 7 % des coûts réels sur EC2. Ils montrent également que cette approche offre plusieurs conﬁgurations rentables pour les charges de tra- vail de l’échantillon que la méthode manuelle provisionnement utilisée par (Vázquez-Poletti et al., 2012) est basée sur l’observation qui négligent plusieurs facteurs comme les frais de stockage ou de communication appliqués à une charge de travail.\nNous ﬁnissons cette première partie de la revue de littérature avec ce dernier article qui traite le sujet d’analyse de la performance du Cloud pour l’utilisation des applications scientiﬁques qui est gourmande en terme de calcul.\nLe Cloud promet d’être une alternative des autres modèles comme grappes, grilles, et les super- ordinateurs. Cependant, la virtualisation peut induire des pénalités de performance signiﬁca-\ntives pour le calcul scientiﬁque, exigeant les charges de travail. Dans ce travail, ils ont présenté une évaluation de l’utilité des services de Cloud Computing actuelle pour le calcul scientiﬁque.\nÀ vrai dire, ils ont choisi EC2 comme banc d’essai, leur travail s’est focalisé sur la question\nsuivante : la performance de nuages, est elle sufﬁsante pour le calcul scientiﬁque ?\nÀ cette ﬁn, leur méthodologie de recherche s’est accentuée sur deux parties, la première est\nle Cloud spéciﬁque, la deuxième est l’infrastructure agnostique. Une caractéristique du nuage est qu’il y a toujours des ressources inutilisées, aﬁn qu’ils puissent être obtenus à tout moment sans temps d’attente supplémentaire. Cependant, la charge d’autres systèmes à grande échelle (grilles) varie au ﬁl du temps, en raison des habitudes de soumission ; nous voulons étudier si de gros nuages peuvent, en effet, contourner le problème de la charge à grande échelle (grilles) qui varie au ﬁl du temps. Ainsi, nous testons la durée d’acquisition des ressources et la libé- ration sur des périodes courtes et longues avec différents types d’instances, aﬁn d’examiner la performance du CPU I/O et la mémoire.\nIls constatent que la performance est reliée au I/O. Les instances de type x.large ont de meilleures performances d’I/O de tous types d’instances. Ceci revient à la taille du cache qui joue un rôle très important, ainsi, plus la taille du cache est grande et plus la performance est meilleure. La principale conclusion est que la performance et la ﬁabilité du nuage testé sont faibles. Et le nuage est insufﬁsant pour le calcul scientiﬁque dans son ensemble, même si elle fait toujours appel aux scientiﬁques qui ont besoin de ressources immédiatement et temporairement.\nD’une part, la majorité des travaux ont porté sur de hauts niveaux, la couche d’application qui est construite sur le haut du modèle d’architecture, en analysant le suivi des performances des applications, en utilisant plusieurs paramètres comme I/O, CPU, RAM, la consommation d’énergie, l’instrumentation code, en extrayant le comportement anormal, à partir de l’histo- rique du log et autres.\nD’autre part, au cours de ces dernières années, plus précisément ces quatre dernières années, plusieurs travaux ont fait le sujet de traiter, d’évaluer et d’analyser le coud Middleware OpenS- tack qui fait notre Middleware choisi par la suite. Vu ses points forts et sa grande utilisation dans la communauté des Cloud libres open-source, nous allons présenté six diffèrents travaux qui ont été menés pour étudier OpenStack sur des aspects variés.\nEn (Corradi et al., 2014), leur but était de présenter une infrastructure de gestion de Cloud ainsi que de fournir des conseils utiles à la communauté OpenStack pour la conception et la mise en œuvre des mécanismes de gestion Nuage de nouveaux.\nL’architecture du Cloud exploite des techniques de virtualisation aﬁn de provisionner plusieurs machines virtuelles (VM) sur le même hôte physique, pour utiliser les ressources disponibles d’une manière efﬁcace. Par exemple, consolider les machines virtuelles dans un nombre mini- mal de serveurs physiques pour réduire la consommation d’énergie de l’exécution. La conso- lidation d’une VM doit examiner d’une manière précise la consommation des ressources en agrégats de co localisé VM, aﬁn d’éviter une baisse des performances et la violation du Ser- vice Level Agreement (SLA).\nEn effet, VM consolidation soulève également plusieurs questions de gestion, car il tend à une exploitation optimale des ressources disponibles, tout en évitant une grave dégradation des performances, en raison de la consommation des ressources co localisée VM. Les auteurs ont proposé une solution de gestion de consolidation des VM pour OpenStack. En outre, ils pro- posent une plate-forme de gestion Cloud pour optimiser la consolidation des VMs en tenant en compte, trois dimensions principales, à savoir la consommation d’énergie (visant à traiter le volet environnemental et économique), les ressources de l’hôte (optimiser les performances d’exécution), et le réseautage (optimiser l’utilisation du réseau de centre de données "bande passante et de latence"). La raison pour laquelle, ils ont abordé les trois aspects à la fois vu que dans leur revue de littérature, chaque problème a été traité indépendamment et en négligeant les autres aspects.\nLeur design de leur infrastructure de gestion cloud se compose de trois éléments (étapes) :\n– première étape : recueillir des données du nuage ;\n– seconde étape : prendre soin d’utiliser les données recueillies pour calculer un nouveau et plus approprié placement VM, si disponible ;\n– troisième étape : calculer le plan de déplacement de VM et appliquer les changements.\nAinsi, l’infrastructure de gestion proposée est constituée d’un composant de surveillance, un placement calcul de gestionnaire, et un actionneur de placement, disposé dans une canalisation où chaque étape exploite la sortie de la précédente. La composante de surveillance rassemble à la fois le système et le niveau de service d’informations sur les ressources utilisées, et les rend disponibles à l’étape suivante.\nLe placement calcul gestionnaire exploite l’information de l’utilisateur SLA surveillance pour vériﬁer si un meilleur placement VM existe ; il contient trois sous-modules pour traiter expli- citement avec l’énergie, les ressources de l’hôte, et le réseau. Enﬁn, si un meilleur placement existe, l’actionneur Placement prend soin d’exécuter les opérations VM plan de migration et de reconﬁguration.\nLeur expérimentation tourne autour de trois exemplaires et études de cas :\n– la première, calculer la consommation de VCPU, vise à souligner la dégradation des per- formances lorsque plusieurs machines virtuelles co-localisées exécutent des tâches de calcul lourd ;\n– la seconde, le fournisseur de serveur HTTP Apache, estime que les VMS hébergent les ser- veurs HTTP Apache ensuite analysent les effets secondaires possibles lorsque de nombreux serveurs Web co-localisés traitent plusieurs demandes entrantes ;\n– la troisième, la communication du réseau vise à souligner les problèmes de performance introduits par la virtualisation lorsque VM effectue des transferts de données très élevés, exemple les services de MapReduce.\nIls concluent que la consolidation VM introduit de nouveaux déﬁs qui doivent être considé- rés par l’infrastructure de gestion Cloud. Bien que la colocalisation des machines virtuelles sur le même serveur physique est toujours recommandée en termes d’économies d’énergie, il\npeut conduire à des effets secondaires de la performance ; ceci dépend strictement du type de service géré. D’une part, les services de calcul sont plus faciles à gérer, car la dégradation de rendement résultante peut être facilement prédite. Dans le cas de surcharge du CPU, toutes les machines virtuelles recevront une bonne quantité de CPU.\nD’autre part, les services de réseau liés sont plus difﬁciles à gérer, car la dégradation de la performance est une conséquence d’un mélange de la charge de CPU et du réseau, où le se- cond affecte également la charge de la CPU du serveur physique. Pire encore, la dégradation des performances en raison de la mise en réseau dépend, vraiment, de la plate-forme de virtua- lisation et des pilotes de périphériques adoptées.\nEn (Xu et Yuan, 2014) évalue la performance du OpenStack plus précisément le composant Quantum. En effet, le réseau virtuel est une partie importante de l’informatique en nuage. Quantum est l’une de la plate-forme de gestion du réseau virtuelle du nuage le plus populaire. Actuellement, la composante Quantum a deux plans de déploiement qui est le plan à un hôte unique et le plan à multi hôtes. Les auteurs ont présenté une analyse du mécanisme du fonc- tionnement de la composante Quantum.\nDans l’article, ils ont introduit le problème de la dissolution du nœud réseau dans le cas du plan à hôte unique. La communication interne et externe de toutes les machines virtuelles dans les nœuds de calcul est réalisée par les nœuds du réseau, de sorte qu’il provoque probable- ment la congestion de nœuds de réseau. Ce qui peut causer le disfonctionnement du réseau, impliquant directement l’effondrement du Cloud. Aﬁn de résoudre les problèmes des scénarios de déploiement à unique hôte, ils ont conçu un ensemble de régimes multi hôtes de OpenS- tack, qui se compose principalement d’un nœud de contrôle et 10 nœuds de calcul, ces nœuds forment trois réseaux, qui sont gestionnaires du réseau, réseaux de données et réseaux externes.\nPour les expérimentations, ils ont créé un réseau virtuel et dix machines virtuelles avec le système d’exploitation du serveur d’Ubuntu dans le OpenStack et veillent à ce qu’ils sont en\nmesure de communiquer, puis déployer des clusters Hadoop sur ces serveurs virtuels. Clus- ters Hadoop se compose d’un nœud maître (gestion des tâches) et plusieurs nœuds esclaves (traitement des données) avec cinq types de données de tailles différentes. Comme métrique de performance, ils ont pris "map time" et "reduce time of Hadoop". Ils ont mis en place trois tests ; le but du premier est d’analyser les performances du réseau sur le nœud physique. L’expérience a prouvé qu’un seul nœud physique a une capacité sufﬁsante pour gérer ces communications. Le deuxième test est de traiter les performances du réseau en mode multi hôtes. Les résultats des expériences montrent que les performances du réseau virtuel du plan multi hôtes ont été grandement améliorées pour comparer le plan hôte unique.\nPar ailleurs, les auteurs de l’article (Callegati et al., 2014b) ont étudié la performance du multi locataire des réseaux virtuels dans les infrastructures de Cloud (OpenStack). En effet, les architectures de réseaux futurs basées sur le Network Fonction Virtualization émergents et le Software Deﬁned Network paradigmes reposeront essentiellement sur les infrastructures de Cloud Computing, en proﬁtant des technologies de virtualisation. La performance des ré- seaux virtuels multi locataire sera alors un élément clé à prendre en considération, lors de la conception de telles architectures basées sur le Cloud Ce dernier apporte de grands avantages en termes de gestion de réseau ﬂexible effectuée au niveau du logiciel et la coexistence possible de plusieurs clients partageant la même infrastructure physique.\nAﬁn d’évaluer la performance du réseau virtuel assurée par OpenStack, il faut que plusieurs lo- cataires soient actifs simultanément. Ils ont déployé un petit banc d’essai comprenant un nœud de contrôleur, un nœud de calcul et un nœud de réseau. Le nœud de calcul fonctionne KVM, et est équipé de 8 Go de RAM et un processeur quad-core permis multi-thread, résultant en 8 processeurs virtuels. Une conﬁguration de Cloud OpenStack a été considérée, l’hébergement de plusieurs locataires d’exécution d’une architecture de réseau virtuel NFV-inspired simple dans le nuage. L’étude de cas considérée est une chaine d’inspection approfondie des paquets "deep packet inspection (DPI)".\nComme métrique de performance, ils ont choisi le taux de paquets et le débit reçus de sources de traﬁc en cours d’exécution dans chaque client VM. Ils ont généré des paquets à taux crois- sant (RUDE,CRUDE tool), pour les différents nombres de locataires activés simultanément. Les résultats montrent que le réseau virtuel n’est pas en mesure d’utiliser toute la capacité physique, même dans le cas d’un seul locataire. Cette pénalité augmente avec le nombre de lo- cataires ( avec la complexité du système virtuel). Aussi, l’augmentation d’une unité du nombre de locataires entraîne une diminution d’environ 10 % de la capacité de réseau utilisable.\nUne autre étude similaire aux (Callegati et al., 2014a) a été menée par les mêmes auteurs qui se sont intéressés à la performance d’OpenStack dans des conditions critiques en évaluant le taux maximum de paquets. Ensuite, ils ont isolé la performance des principaux composants du réseau d’OpenStack et déterminé où se trouvent les goulots de saturation, en spéculant sur les améliorations possibles. Pour cette ﬁn, ils ont construit deux bancs d’essai, à savoir OpenS- tack scénario (utilisant Linux Bridge) et le scénario non-OpenStack (utilisant OVS), avec KVM comme natif de Linux VM Hypervisor. Pour chaque banc d’essai, plusieurs montages expéri- mentaux ont été conﬁgurés (réalisation avec une seule compute Node et avec deux compute Node pour les deux scénarios), où une source de traﬁc envoie des paquets à un taux croissant vers une destination qui mesure le taux de paquet reçu et le débit. L’outil RUDE et CRUDE ont été utilisés pour la génération et la mesure du traﬁc.\nÀ partir des résultats, ils ont conclu que la mise en œuvre du réseau virtuel standard d’OpenS- tack peut montrer les limites de performance signiﬁcative. Et que OVS afﬁche toujours une meilleure performance que Linux Bridge. La performance se dégrade quand nous augmentons la taille des paquets en utilisant Linux Bridge. Cela prouve que la présence de ponts sup- plémentaires (Linux Bridges) dans les nœuds de calcul est une des principales raisons de la dégradation des performances d’OpenStack.\nEn (Scharf et al., 2015) ils présentent une extension d’ordonnancer OpenStack qui permet un placement de réseau courant en prenant en compte les contraintes de bande passante vers et\nà partir des nœuds. Leur solution assure le suivi de l’allocation des ressources de réseau hôte local, et il peut être combiné avec des mécanismes d’application de bande passante telle que la limitation de débit. Ils présentent un prototype qui nécessite du changement dans le logiciel open source OpenStack. L’ordonnancer par défaut ne considère que les ressources de calcul et de mémoire, mais il ne tient pas compte des exigences de bande passante du réseau.\nLa solution la plus simple sur le plan conceptuel est d’améliorer la planiﬁcation d’afﬁnité en considérant la localité. Grâce à la connaissance nœud/rack, le planiﬁcateur tente de placer un ensemble d’instances proches les unes des autres, sur le même nœud ou à l’intérieur du même rack. Mais, cette approche ne donne aucune garantie sur la performance du réseau, et il ne propose aucun moyen de distinguer les différentes exigences en matière de mise en réseau des instances.\nLa bande passante de réseau d’un nœud est allouée par l’ordonnancer de la même façon que les ressources de calcul et de mémoire. Lors du démarrage d’une nouvelle instance, une cer- taine bande passante doit être demandée de la même manière comme CPU virtuel, RAM, etc. Dans ce cas, une instance peut demander une bande passante totale sur l’hôte sans spéciﬁer une matrice de traﬁc plus détaillée. Toutefois, ce modèle ne prend pas en charge les demandes qui garantissent la bande passante de bout en bout, si nous adressons le problème de qualité de service, mais cela n’est pas leur but dans cette recherche.\nL’évaluation des algorithmes et des politiques d’une manière exhaustive directement sur un nuage est impossible, car il implique beaucoup de temps et d’efforts. En (Sitaram et al., 2014) ils ont présenté un simulateur OpenSim des services OpenStack. Il a été développé avec l’in- tention de simuler de nouveaux algorithmes et aussi de permettre une étude de l’utilisateur, du comportement d’une application fonctionnant sous différentes conﬁgurations de déploiement dans un environnement OpenStack. OpenSim est développé au-dessus de CloudSim, et un si- mulateur libre est basé sur les événements.\nUn des principaux objectifs du simulateur OpenSim est d’aider l’utilisateur à comprendre comment un nuage de OpenStack déployé sans entreprendre les processus de déployer dans un monde réel. En outre, il permet également à un utilisateur d’exécuter à plusieurs reprises et de mener une série d’expériences de simulation avec une légère variation des paramètres d’une manière rapide et facile. OpenSim génère également des informations sur le temps de réponse des requêtes, temps nécessaire pour traiter les demandes et d’autres mesures. Les résultats de simulation montrent qu’OpenSim peut modéliser correctement un environnement OpenStack et peut prédire avec précision le débit et le temps de réponse sous différentes charges de travail.\nCe mémoire traite l’impact de la charge de travail sur la performance du Cloud Middleware ainsi que l’impact sur la consommation des ressources physiques. À la différence des autres tra- vaux, nous nous intéressons plus à la performance de Cloud middleawre tel que la performance des applications s’exécute sur ce Cloud Middleware ou s’analyse d’une seule composante du Cloud Middleware.\nDans ce chapitre, nous avons mis le point sur le concept du nuage informatique, qui se po- sitionne actuellement parmi les nouvelles technologies basées sur la virtualisation, le partage des ressources informatiques. Le nuage informatique garantit l’extensibilité et l’élasticité et l’accès à ces ressources à la demande. Aussi, le nuage informatique assure l’exploitation des ressources par un grand nombre d’utilisateurs et sont facturées en fonction de l’utilisation.\nDe plus, nous avons présenté le Cloud Middleware comme un logiciel qui assure l’intégrité des applications des services et du contenu disponibles sur le nuage informatique, ainsi que son utilité dans la gestion des données, la sécurité, le service d’hébergement, le monitoring et d’autres taches. Nous avons illustré trois exemples de Cloud Middleware.\nNous avons clôturé ce chapitre par une revue littéraire des travaux connexes sur les deux as-\npects d’utilisation des applications dans le Cloud ainsi que leur impact sur la consommation des ressources et une revue sur le Cloud Middleware, plus précisément OpenStack pour savoir et analyser les travaux qui ont été faits sur ce dernier.\nAu cours de ce chapitre, nous allons répondre aux problématiques citées dans la section 1.3. Après avoir présenté un aperçu sur monitoring dans le Middleware Cloud dans la section 2.2, le premier bloc de ce chapitre présentera les métriques appropriées décrivant la performance du Cloud Middleware. Ainsi, un outil sera utilisé pour collecter les données à moindre coût. Puis, nous allons modéliser et optimiser la performance du Cloud Middleware d’une manière efﬁcace. Cette solution nous aidera à analyser et calculer l’impact des ressources physiques sur la performance du Cloud Middleware.\nD’une manière générale, nous pouvons subdiviser le Cloud Middleware en trois grandes parties qui déﬁnissent ce dernier ; à savoir, le nœud du contrôleur (Controller Node), le nœud de calcul (Comptue Node) et le nœud du réseau (Network Node). Notre but de cette présente recherche est de proﬁler le Cloud Middleware, mais nous nous intéressons plus précisément au nœud Contrôleur. Dans cette présente section, nous allons déﬁnir toutes les métriques qui sont reliées à la performance du Cloud Middleware, dans le but de répondre à la première question de la problématique soulevée dans la section 1.3.\n3.1.1 Les métriques à superviser\nAﬁn de proﬁler le nœud contrôleur du Cloud Middleware, l’étape du choix des paramètres est cruciale pour baser notre étude. Étant donné un Cloud Middleware, nous avons plusieurs para- mètres qui sont soit contrôlables soit incontrôlables par l’administrateur.\nQuant à notre intérêt, nous avons plus tendance vers le premier critère (contrôlable). Nous rap- pelons ici, que l’importance des objectifs du Cloud Middleware est de nous offrir un ensemble de machines virtuelles appelé instances aux utilisateurs et accessibles de n’importe quel lieu.\nDe cet effet, à chaque instance créée, nous aurons besoin de spéciﬁer les paramètres suivants :\n– utilisateur (user) : Chaque instance créée est utilisée par un utilisateur ;\n– locataire (tenant) : Dans chaque locataire, nous trouvons une ou plusieurs instances qui sont\naccédées par un ou plusieurs utilisateurs ;\n– image : Chaque instance contient un Système d’exploitation ;\n– stockage : Chaque instance a un disque dur attaché ;\n– CPU et RAM : Chaque instance a un nombre de CPU et une capacité de RAM ;\n– réseau : Chaque instance a une adresse IP et une adresse Mac ; pour être accessible de l’ex-\n– instance(s) : Nombre d’instances à créer.\nDans le but de normaliser les expériences, nous avons opté de ﬁxer les paramètres (type image, CPU et RAM) de chaque instance créée au prix d’avoir des résultats objectifs. En échange, nous avons choisi la création et la suppression des instances, comme scénario principal, vu son importance dans le modèle du Cloud Middleware. Car sans les instances, nous ne pourrons rien faire dans un Cloud Middleware. Aussi, il va falloir déterminer s’il existe une relation entre ces trois facteurs (locataire, utilisateur et instance).\nArrivés à ce stade-ci, nous supposons que nous avons bien déﬁni nos facteurs signiﬁcatifs (plus d’explication dans la section 3.2). Maintenant, ce qui nous reste pour compléter la liste appropriée des paramètres de performance, c’est d’identiﬁer les métriques à collecter durant la phase des tests aﬁn de construire une synthèse sur la variation de la consommation des res- sources pendant les différentes charges de travail appliquées. Mais, avant de lister les métriques que nous avons choisies et expliquer pourquoi nous nous sommes limités juste à ces métriques. Nous devons éclaircir le point suivant.\nEn effet, le premier critère, que nous allons utiliser pour tirer une conclusion solide, est le temps et plus particulièrement, le temps d’exécution nécessaire pour accomplir le scénario choisi, ainsi que le temps de réponse (latence). Avec ces deux paramètres, nous pouvons ré- pondre aux questions suivantes :\n– pour une charge de travail donnée, combien de temps prendra-t-il pour exécuter cette re- quête ?\n– combien de temps faut-il pour traiter la requête ?\n– quel est le taux moyen d’exécution des différentes charges de travail ?\nLe choix de ce premier critère a été soulevé comme métrique pour analyser la performance du Cloud Middleware et a été utilisé dans des travaux de recherche antérieurs. Nous trouvons le temps d’exécution parmi toutes les métriques de la performance discutées dans les travaux connexes dans la section 2.3 étant une métrique très importante.\nMis à part le temps nous avons CPU étant une autre métrique qu’il faut prendre en consi-\ndération. En général, la représentation de CPU est sous un pourcentage moyen d’utilisation du\nCPU, ce pourcentage indique le temps d’inactivité du CPU qui a été soustrait de 100 pour cent.\nPar ailleurs, il existe une variété de manières, comment pouvons nous calculer le taux de CPU\nutilisés, nous citons ;\n– CPU Time : le temps passé à exécuter le programme cible sans tenir compte du I/O ou\nl’exécuter d’autres programmes ;\n– User CPU time : Le temps passé à exécuter les lignes de code qui sont "dans" notre pro-\n– Cycles d’horloge : c’est une opération de matériel numérique régie par un débit constant de\nl’horloge (voir ﬁgure) aussi, au lieu de rapporter temps d’exécution en secondes, on utilise\nsouvent les cycles program seconds\n= clock cycles\nclock cycle .\nNous pouvons appuyer notre choix des ces métriques par une revue littérature dans ce domaine\nqui a été présentée dans la section 2.3 "travaux connexes", soit les métriques utilisées pour\nanalyser la performance dans le Cloud Computing en général.\nDe façon plus précise et pointue, le temps d’exécution et CPU ont été déﬁnis étant deux\nmétriques très importantes et sufﬁsantes, décrivant qualitativement la performance du Cloud\nEn résumé, quand nous abordons le sujet du choix des métriques à collecter, plusieurs consi- dérations sont prises en vu : nous devrons sélectionner les métriques basées sur la disponibilité (availability), la précision (accuracy), le coût (cost) et la rapidité (timeliness) avec :\n– disponibilité : Les données doivent être collectées facilement. Autrement dit, elles doivent être faciles à mesurer et linéaires dans ses changements de valeur par le même rapport ;\n– précision : Les données colletées doivent être ﬁables et crédibles, avec calculs exacts et cohérents dans le temps. Cela veut dire que la métrique à répétabilité doit donner la même valeur, à chaque fois que nous faisons la même mesure ;\n– rapidité : Les données doivent être sufﬁsamment rapides pour évaluer la performance ;\n– coût : Il faut avoir un coût minimal pour collecter les données. De plus, il faut avoir sufﬁ- samment de ressources disponibles pour la collecte de ces données.\nNous résumons cette partie, en soulignant les points suivants : premièrement, les métriques à superviser sont la charge de travail du CPU et le temps d’exécution pour compléter un scéna- rio ; deuxièmement, le scénario choisi est la création et la suppression d’un lot de machines virtuelles distribuées sur un ensemble de locataires et d’utilisateurs. Nous résumons le proces- sus de collecte des données dans la ﬁgure suivante :\nNous mettons en évidence que nous pouvons appliquer la même idée de la supervision de la consommation des ressources mais en changeant le scénario. Par exemple, au lieu de faire la création et la suppression des instances, nous nous focalisons sur la performance du Cloud Middleware lors de la migration entre les nœuds compute existants du Cloud et nous choisis- sons quand et comment les migrer. Ou bien, nous utilisons une couche réseau complexe qui nécessite d’isoler les locataires et de faire passer l’instance sur des parts-feu avant de la créer ; puis nous calculons et comparons les résultats aﬁn de comprendre la performance du Cloud dans ce genre de situation, etc.\nEn revanche, pour ces deux exemples que j’ai présentés, je les classe dans deux catégories de deux domaines différents et qui sont interconnectés à la fois ; à savoir le domaine de la\ngestion des ceenter de données et le domaine de la sécurité qui cible ces ceenter de données. Comme nous constat, il existe plusieurs scénarios et plusieurs manières pour déﬁnir la problé- matique et pour donner une approche aﬁn de résoudre le problème.\nPour clôturer cette section, je réponds à une question que le lecteur peut se poser au cours de sa lecture "Pourquoi j’ai choisi la création et la suppression de l’instance, étant mon seul et unique scénario étudié ? Ainsi que, pourquoi me limiter aux trois facteurs et ne pas prendre en considération les types de systèmes d’exploitation à avoir une variété de types des instances à créer ? Puis observer l’impact de ce genre de scénario sur la performance de mon Cloud Middleware."\nL’instance est le seul élément qui interagit avec toutes les couches du Cloud et plus parti- culièrement, le Cloud Middleware. Par conséquent, nous devons nous assurer que l’instance fonctionne correctement sans aucun problème, puis nous pouvons associer à cette instance des charges de travail (tâches) aﬁn d’être exécutées proprement dans le Cloud.\nAvant d’investiguer si mon Cloud midleware peut supporter la migration, gérer, assurer la sé- curité et/ou l’isolation de mes instances. Est-ce que ce Cloud Middleware peut créer une série d’instances proprement dites et pouvant être supprimées par la suite sans aucun problème. Vu que l’approvisionnement d’une machine virtuelle est complexe et doit, nécessairement, passer par une série d’étapes avant d’être prête à l’utilisation ; nous citons l’identiﬁcation de la re- quête, choix du nœud de l’hôte, en nous basant sur le mécanisme d’ordonnancer, de saisir et d’allouer des caractéristiques de l’instance comme CPU/RAM/OS, communication avec l’hy- perviseur pour héberger l’instance etc. (voyons plus de détails dans le quatrième chapitre).\nPar ailleurs, pour répondre à la deuxième question, je me suis limité aux trois facteurs, car je veux savoir est-ce qu’il existe une relation entre ces derniers. De plus, j’ai négligé les autres facteurs comme le choix des divers VCPU, RAM et système d’exploitation qui seront associés à mes instances. Tout simplement, ces facteurs négligés sont, entre autre, des ressources liées\nà mon instance qui seront elles aussi liées à mes ressources matérielles. Ce qui revient à dire que si je veux une capacité à une instance je dois m’assurer d’abord si j’ai déjà sufﬁsamment de ressources physiques. Dans le cas de mon étude, j’envisage de créer le maximum possible d’instances, aﬁn d’observer comment Cloud Middleware (trois facteurs) va se comporter face cette charge. Ainsi, mon intérêt n’est pas focalisé sur la capacité de l’instance à créer.\nIl y a plusieurs raisons pour lesquelles la collecte de données sur des serveurs, des applica- tions est utilisée. La collecte et l’organisation des données peuvent donner certaine crédibilité en prise de décision, concernant l’extension (scaling), le dépannage (troubleshooting) aﬁn de changer la mise à jour ou d’enlever des composants ou modiﬁer les ﬁchiers de conﬁgurations.\nDans ce projet, notre méthode de collecte de données vise deux catégories de données, à sa- voir : des données reliées à l’infrastructure et des données reliées au Cloud Middleware. Ces deux processus de collecte se font en parallèle. Ces deux processus ont pour but de trouver la relation entre les facteurs du Cloud Middleware et de calculer l’impact de ces facteurs sur la performance de l’infrastructure utilisée. Dans ce qui suit, nous allons présenter quelques outils reliés à la collecte de données de l’infrastructure comme la consommation du CPU et le temps d’exécution ; ce qui répondra à la deuxième question de la problématique.\nEn réalité, il existe une variété d’outils qui peuvent être utilisés pour superviser les métriques ciblées dans les systèmes étudiés. Très souvent, ils occupent une certaine partie du processus. Ce genre d’outils peut être ajouté ou combiné (plug-ins) pour créer un système de collecte, d’enregistrement et d’afﬁchage des résultats.\nLa raison primordiale, pour laquelle nous utilisons un outil de collecte de donnée, est en fait assez simple : plus nous avons de données et plus nous serons en mesure de comprendre ce qui\nse passe à un moment donné. Cela nous donne la capacité remarquable, à la décision, avec les données brutes et nous permet de voir à l’avance, si un changement susceptible est ciblé au bon composant. Le suivi des statistiques nous fournit une source supplémentaire d’informations qui peuvent ne pas être présentes dans les logs des applications.\nUne des façons les plus faciles à recueillir des informations détaillées sur un serveur est un démon nommé collecte.\nCollecte peut rassembler des statistiques sur de nombreux composants différents d’un envi- ronnement de serveur. Il permet de suivre facilement les paramètres communs, comme l’utili- sation de la mémoire, la charge CPU, le traﬁc réseau, etc. Cela permet de corréler facilement les événements avec l’état du système cible.\nAu-delà de la collecte d’informations de système standard, collecte dispose également d’un système de plug-in qui étend ses fonctionnalités. Cela signiﬁe que nous pouvons facilement collecter des informations du logiciel comme Apache, Nginx, iptables, memcache, MySQL, PostgreSQL, OpenVPN, et beaucoup plus.\nCollecte fournit un moyen simple d’obtenir des données à partir d’applications pré conﬁgurées et des services communs sur les serveurs. Cela doit être utilisé pour suivre le comportement de l’infrastructure et les services qui sont exécutés sur ce dernier. (Voir l’annexe).\nStatsD est un démon très simple qui peut être utilisé pour envoyer des données à d’autres Gra- phite (c’est une application Web qui permet de visualiser et de concevoir des graphiques qui tracent les données collectées par Stats). L’avantage de cette approche est qu’elle devient tri- viale à construire dans le suivi de stat aux applications et aux systèmes que nous créons.\nStatsD fonctionne en écoute sur une interface pour les paquets UDP simples qui représentent un point de données unique. Cela signiﬁe qu’il peut accepter une grande quantité d’informations d’une manière sans connexion. Il peut alors agréger les valeurs qu’il reçoit et les transmettre à Graphite.\nCe système nous permet d’envoyer les statistiques en grandes quantités sans nous soucier de la croissance de latence de l’application. Le service StatsD permettra de recueillir toutes les données, de les agréger, puis les envoyer sous forme d’un résumé de points de données pour graphite à chaque laps de temps.\nEn raison de ces avantages, il est en fait un bon intermédiaire pour tout type de données en- voyées à Graphite. Mais, le principal moyen que nous pouvons tirer à partir de cet outil est de pouvoir surveiller nos propres applications et les outils que nous créons.\nStatsD est parfait pour cela, car il est un démon d’usage général qui accepte le traﬁc UDP. Il y a beaucoup de différentes bibliothèques, côté client dans divers langages de programma- tion qui peuvent envoyer des données directement à une instance StatsD. Cela signiﬁe que les applications, que nous construisons, peuvent facilement envoyer des données à être suivies.\nNagios Core TM est un système Open Source, l’application de surveillance réseau. Il surveille les hôtes et services que nous spéciﬁons, pour nous avertir quand il y a un changement critique.\nLe core de Nagios a été initialement conçu pour fonctionner sous Linux, il supporte la plu- part des autres distributions Unix.\nParmi les nombreuses fonctionnalités de Nagios, les bases comprennent :\n– la surveillance des services réseau (SMTP, POP3, HTTP, NNTP, PING, etc.) ;\n– le Monitoring des ressources (charge processeur, l’utilisation du disque, etc.) ;\n– le design des simples plug-ins qui permettent aux utilisateurs de développer facilement leurs propres contrôles de service ;\n– les contrôles de service parallélisés ;\n– l’interface Web option pour visualiser l’état du réseau, la notiﬁcation et le problème histoire actuelle, le ﬁchier journal, etc.\nEn effet, il existe d’autres outils qui ont plus au moins les mêmes fonctionnalités des outils ci- tés ci-dessus et sont plus ou moins populaires. Par ailleurs, notre choix de l’outil doit suivre la contrainte suivante ; il faut utiliser un outil qui collecte les données à moindre coût. Autrement dit, il ne faut pas que l’outil utilisé ait un impact sur la performance du système, car en général tous les outils de collecte prennent une partie du processus lors de son exécution.\nDurant mes recherches, je peux dire que les deux outils (logiciels) les plus connus, utilisés et gratuits (open-source) sont Nagios et Collectd.\nConcernant l’outil Nagios, il est recommandé, seulement si, notre vision est de superviser un large et complexe réseau qui se constitue de plusieurs commutateurs (switchs) et routeurs (rou- ters) ; premièrement, nous pouvons comprendre que Nagios est plus dédié au monitoring des réseaux et deuxièmement, nous constatons, implicitement, que Nagios lui aussi a une bonne part des ressources physiques pour qu’il puise être exécuté, aﬁn de collecter les données (mé- triques) souhaitées. D’où, Nagios n’est pas le bon candidat pour collecter nos métriques vu que l’outil que nous voulons utiliser, doit suivre deux contraintes : une collecte précise et à moindre coût (impact négligeable).\nEn contrepartie, nous avons Collectd, mis à part de ce qui a été présenté, nous rajoutons ici\nque Collectd inclut des optimisations et des fonctionnalités, pour gérer des centaines de mil- liers d’ensembles de données. Il est livré avec plus de 90 plug-ins qui varient entre les cas standard allant jusqu’à des sujets très spécialisés et avancés. Il peut être extensible de nom- breuse façons. Dernier point, mais non des moindres : collecte est activement développé et soutenu et bien documenté. Une liste plus complète des fonctionnalités est disponible. Et sur- tout Collectd est une application écrite en C et est conçu pour fonctionner comme un démon, ce qui en fait une application faible en surcharge (overhead) qui est capable de consigner les informations à de courts intervalles, sans impact signiﬁcatif sur le système.\nDe ce fait, nous pouvons dire que le choix du Collectd est une candidate potentielle pour la collecte des données. Mais, puisque nous travaillons dans un environnement LINUX, les ou- tils cités auparavant utilisent tous des fonctionnalités déjà existantes dans le noyau du LINUX. Aussi, nous nous sommes intéressés uniquement aux deux métriques qui sont la consommation du CPU et le temps d’exécution, nous avons opté à écrire notre propre script pour la collecte des données souhaitées comme présenté dans la synoptique suivante.\nEn effet, le script est une combinaison de deux fonctionnalités qui roule à la fois en parallèle. Le premier est le scénario de la création et de la suppression (Add and Drop) des machines virtuelles et le deuxième est la collecte de la charge de CPU et du temps d’exécution qui est causée par la première fonctionnalité. Nous présentons la démarche du processus de chaque fonctionnalité.\nScénario de la création et suppression (Add and Drop) :\n1 saisir les droits d’accès au cloud privé ;\n2 vériﬁer que tous les services du Cloud sont connectés, si un des services n’est pas connecté, nous quittons et nous déboguons pour trouver l’erreur ;\n3 sinon, nous commençons à créer d’abord un ensemble de locataires et d’utilisateurs, les machines virtuelles seront accessibles à ces utilisateurs qui sont associés à ces locataires ;\n4 puis, nous débutons la création des machines virtuelles en suivant le plan d’expérience et le processus de la collecte des données (voir ﬁgure 3.4) ;\n5 si les machines virtuelles ne sont pas créées correctement, nous quittons et nous débo- guons pour trouver l’erreur ;\n6 avant de commencer le processus de suppression des machines virtuelles, il faut vériﬁer que le statut de ces machines est en marche (running), sinon nous passons à la machine suivante ;\n7 si la machine virtuelle est au statut running, nous la supprimons ;\n8 vériﬁer s’il reste d’autre machine virtuelle dans le Cloud ;\n9 si oui revenir à l’étape ;\nsinon quitter l’algorithme.\nDeuxième fonctionnalité la collecte des données :\n1 exécute la commande htop tout au long du processus de la collecte aﬁn de tirer la consom- mation du CPU ;\n2 lancer le minuteur (timer) ;\n3 débuter le scénario de la création et la suppression (Add and Drop) des machines vir- tuelles ;\n4 extraire la variation du CPU chaque seconde ;\n5 agréger les valeurs collectées puis les enregistrer dans un ﬁchier log ;\n6 arrêter le minuteur à la ﬁn de l’algorithme ;\n7 afﬁcher le temps pris pour réaliser la première fonctionnalité.\nCette partie traitera la troisième question de la problématique. Avant de procéder au choix du plan d’expérience le plus adéquat dans notre recherche, nous rappelons que les plans d’expé- riences s’appliquent pour répondre aux exigences de deux grandes catégories de problèmes. La première catégorie de problèmes, auxquels les plans d’expériences peuvent être utilisés pour faciliter le processus des expériences durant la phase des tests, est dite criblage ou tamisage (screening) faisant partie de la famille des plans factoriels fractionnaires. Ce genre d’approche consiste à construire une idée sur l’effet des facteurs (paramètres) qui entre en jeux durant les expériences.\nAutrement dit, nous utilisons le tamisage aﬁn de rafﬁner le nombre des facteurs, dans le cas où nous avons assez de facteurs, et nous n’avons pas une idée claire au préalable sur leurs comportements au sein du système. Ceci se fait par le biais d’une combinaison bipolaire des facteurs retenus, dans le but d’extraire les facteurs les plus inﬂuents ainsi que leurs interactions existantes.\nGénéralement, cette technique est réalisée par le biais des plans factoriels complets à deux niveaux ou par les plans factoriels fractionnaires. Par ailleurs, en ce qui concerne la deuxième\ncatégorie des plans d’expérience, nous les nommons "Plans de surface de réponse". Entre autre, il existe plusieurs plans qui déﬁnissent les plans de surface de réponse (plans Box-Behnken, plans composites centrés et autre). Cette catégorie vise à déterminer d’une façon quantitative les variations de la réponse, vis-à-vis des facteurs d’inﬂuence signiﬁcative.\nPour présenter la technique du sceerning, il existe plusieurs travaux qui sont faits auparavant et sont discutés dans la littérature. Nous illustrons un de ces exemples, en (Srinivasaiah et Bhat, 2005) l’auteur a utilisé un plan à 28 essais pour identiﬁer et mettre en évidence 10 facteurs potentiels qui affectent positivement parmi un ensemble de 21 facteurs sur le comportement du CMOS (Complementary Metal Oxide Semi-conductor). Cela limite le nombre de facteurs à étudier, ce qui implique moins de nombres d’essais.\n3.2.2.1 Déﬁnition de l’objectif et la réponse\nEn se basant sur ce qui précède cette section, nous avons mentionné que la construction du plan d’expérience dépend de façon étroite de l’objectif visé. Cela nous guide à déﬁnir l’objectif de l’étude ainsi que la réponse observée de façon précise.\nDans la section "les métriques à superviser", nous avons déﬁni les facteurs potentiels envers la création d’une machine virtuelle, aussi nous avons expliqué pour quelle raison nous avons choisi le plan de tamisage comme étant notre plan d’expérience adopté. À la lumière de ces données, il nous reste un seul élément à déﬁnir.\nPour compléter l’image globale de l’expérience, nous devons spéciﬁer la valeur résiduelle des effets interaction entre les facteurs cités auparavant (cette grandeur est dite la réponse dans la terminologie des plans d’expériences). De ce fait, la réponse sera sous forme d’un taux de pourcentage de réussite de chaque simulation effectuée. Les modiﬁcations, dans les paramètres des facteurs, engendrent une nouvelle observation dont une variation sur la réponse.\nDans la synoptique ci-dessous, 3.5 nous montrons la méthode de la collecte des données liée\nau Cloud Middleware.\nÀ l’aide de cette méthode, du script pour calculer la consommation\ndu CPU et du temps d’exécution durant les simulations, nous pourrons à la fois déterminer la relation entre les facteurs, extraire le facteur le plus signiﬁcatif, les niveaux de saturation et préciser l’inﬂuence de la couche physique sur la performance du Cloud Middleware. Cela a pour but de répondre à la quatrième question de la problématique qui est le calcul de l’impact des ressources physiques sur la performance du Cloud Middleware.\nPour résumer cette section, après le déploiement du Cloud Middleware, notre la méthodologie proposée consiste à construire un modèle de simulation pour le scénario opté et discuté dans la sous-section précédente, de modéliser les comportements à l’aide de plans d’expériences, d’optimiser le nombre de facteurs (paramètres) inﬂuençables (s’ils existent) par l’entremise des plans factoriels (tamisage) et de calculer l’impact de ces simulations sur l’infrastructure\ndu Cloud Middleware. Une vue globale de la méthodologie est donnée dans le diagramme 3.6 suivant :\n1 déployer OpenStack sur une architecture distribuée ;\n2 déﬁnir les métriques à superviser ;\n3 déﬁnir le plan d’expérience choix ;\nsimuler le scénario de création et la suppression d’un groupe d’instances avec différente charge de travail ;\ncollecter les données puis agréger ces résultats ;\nextraire le facteur le plus signiﬁcatif et formuler l’analyse de la variance ;\névaluer et étudier l’impact du facteur signiﬁant sur les ressources matérielles des serveurs.\nEn guise de conclusion à ce chapitre de la méthodologie de travail, nous avons déterminé les métriques décrivant la performance du Cloud Middleware, soit locataire, utilisateur, instance. Puis, nous avons déﬁni une liste précise des métriques à superviser en phase des tests soit le temps d’exécution et la charge du CPU aﬁn de comprendre l’impact de ces derniers sur l’infrastructure. Et nous avons déﬁni une méthodologie de tests en nous basant sur les plans d’expériences aﬁn de structurer nos tests.\nÀ la lumière des problématiques et objectifs décrits dans les sections 1.2 et 1.3, et la démarche proposée dans le chapitre précédent ; ce présent chapitre portera sur les expérimentations réali- sées, ainsi que les résultats obtenus aﬁn de consolider avec ce qui a été élaboré dans les sections antérieures. Nous avons conçu et implémenté un modèle générique pour proﬁler et évaluer la consommation des ressources matérielles des équipements utilisés.\nDans ce qui suit, nous allons présenter l’environnement expérimental, suivre les différentes étapes de la méthodologie pour atteindre les objectifs du mémoire de recherche et exposer les scénarios exécutés sur le banc d’essai et leurs résultats. Des discussions de ces derniers ainsi que des synthèses de performances seront retenues à la ﬁn de ce chapitre.\nServeur de banc d’essai\nEricsson Server Platform est plus robuste et tolérant aux pannes que toute technologie de ser- veur comparable. Il est extrêmement ﬁable avec une capacité linéairement évolutive, et les ca- ractéristiques en temps réel, ce qui signiﬁe que la transmission a lieu dans un délai minimal et contrôlé. Le logiciel de télécommunications de qualité est activé par TelORB clusterware, qui tourne au-dessus de DICOS et de Linux. Le logiciel intègre la toute dernière dans le système de signalisation no. 7 (SS7) et intégré dans la gestion de nœud, avec le soutien de nombreux protocoles nécessaires à l’interopérabilité entre la plate-forme Télécom Server et des systèmes de soutien des opérations (OSS) (Ericsson, 2015) par ces points forts, nous trouvons :\n– ﬂexibilité - Blade générique qui prend en charge toutes les applications basées X.86 y com-\npris ceux de tiers ;\n– NEBS 3 compatible - cela est essentiel pour fournir haut dans la performance de service\nrequise dans les réseaux de télécommunications, mais aussi de réduire les coûts de mainte-\nnance et de réparation ;\n– nuage prêt - prêt à fonctionner dans un environnement de Cloud Computing avec des fonc-\ntions de contrôle du réseau et de la charge utile virtualisés.\nNotre banc d’essai est réalisé, voir ﬁgure 4.2 qui est une illustration plus détaillée des compo-\nsantes de la ﬁgure dans la synoptique 4.1. Ce banc d’essai déployé suit la topologie de réseau\nen étoile. Cette dernière se constitue de trois serveurs (Ericsson blade GEP-3 blade), dont les\ncaractéristiques techniques sont présentées dans le Tableau 4.1, chacun est attaché au commu-\ntateur avec une liaison directe et d’un débit de 1 GB.\nNous notons, ici, que la technologie de virtualisation utilisée est KVM, voir l’annexe I pour\nUbuntu Server 12.04 x64 TLS\n12CPU x 2GHz\n4.3 Déploiement de OpenStack\nDans cette recherche, nous nous concentrons sur les caractéristiques qui ont l’impact le plus important sur la performance de OpenStack (notons ici que nous avons utilisé la version Ice- House d’OpenStack).\nEn d’autres termes, le but de notre expérimentation est de déterminer la limitation ou gou- lot d’étranglement OpenStack, en créant des instances simultanées dans la limitation de la capacité de matériel, puis savoir s’il existe une corrélation entre le nombre d’instances créées, le nombre de locataires et le nombre d’utilisateurs par locataire, la performance de Cloud en termes du temps nécessaire pour la création des instances et la capacité de CPU utilisé comme expliqué dans chapitre "Méthodologie de travail". Pour observer comment OpenStack gère les demandes simultanées, nous mettons en place un environnement de matériel sous-jacent comme le montre la Figure 4.1.\nNous avons mentionné, dans le chapitre précédent, notre scénario principal qui est simultané- ment, la création et la suppression des instances par la création d’un certain nombre d’instances en parallèle, aﬁn d’étirer notre pile (Stack) au maximum et d’observer la réponse d’OpenStack comment réagira-t-il face à ces requêtes.\nAussi, nous avons mis en évidence, dans le chapitre méthodologie de travail uniﬁé, les ins- tances utilisées ainsi que l’importance de ce point aﬁn d’obtenir des résultats objectifs. Sur ce, nous conﬁgurons nos instances avec une exigence minimale, en utilisant :\n– image : "cirros-0.3.2-x86_64-uec" (Cirros nuage image) ;\n– type (ﬂavor) : m1.nano ;\n– CPU : un seul virtuel CPU (VCPU) ;\n– RAM : 64 Mo.\nJusqu’à présent nous n’avons pas encore expliqué le mécanisme de la création d’une machine virtuelle à l’aide d’OpenStack. La partie suivante met en évidence les étapes nécessaires pour approvisionner une instance. Ces étapes nous aideront à comprendre le mécanisme de la créa- tion d’une instance. Sur ce, cette démarche sera utile pour la suite dans la partie des discussions des résultats. Aussi, les mesures prises pour mettre en place une instance, comme l’illustre\nles étapes nécessaires pour le provisionnement d’une machine virtuelle\nle processus d’approvisionnement, comprennent de nombreuses étapes, numérotées de 1 à 23 aﬁn de construire une instance (voir Figure 4.3). Pendant le processus, le nœud du contrô- leur envoie différentes demandes dans un ordre chronologique, commençant par la vériﬁcation\ndes identiﬁants, terminant par la création des instances sur le nœud compute et passant par la communication entre les composants (nova, Glance et Neutron) via le protocole de communi- cation/messagerie RabbitMQ (voir ﬁgure 4.3).\nDans ce qui suit, nous allons décrire et expliquer chaque transaction (numérotées de 1 à 24) dans Figure 4.3 ci-dessous :\nétape1à2 : la vériﬁcation des identiﬁants : à savoir le tenant et l’utilisateur qui existe dans le tenant, de plus vériﬁer le quota pour savoir si ce dernier a le droit de créer des instances, puis Keystone d’identiﬁer et de générer les informations puis renvoyer haut-token qui sera utilisé pour l’envoi de la demande d’autres composants via l’appel de REST ;\nétape 3 : demande de créer une nouvelle instance via le tableau de bord ou par commande de ligne REST API aux nova-api,\nétape 4 : Nova-api reçoit la demande et l’envoie pour valider auth-jeton (auth-token) et pour accéder à Keystone ;\nétape 5 : Keystone valide le jeton et envoie la réponse avec les rôles et les autorisations ;\nétape 6 : Nova-api interagit avec la base de données de nova (nova-database) ;\nétape 7 : Créer une entrée dans la base de données initiale pour allouer une nouvelle instance ;\nétape 8 : Nova-api envoie la demande à nova-scheduler via de rpc.call pour obtenir l’entrée d’instance avec l’ID d’hôte spéciﬁé ;\nétape 9 : nova-scheduler choisit la demande de la ﬁle d’attente ;\nétape 10 : nova-scheduler interagit avec nova-database pour trouver l’hôte approprié ;\nétape 11 : Renvoie l’entrée de l’instance mise à jour avec l’ID d’hôte approprié ;\nétape 12 : nova-scheduler envoie la demande de rpc.cast à nova-compute pour lancer l’ins- tance sur l’hôte approprié ;\nétape 13 : Nova-compute prend la demande de la ﬁle d’attente ;\nétape 14 : Nova-compute envoie la demande de rpc.call à la Nova-conducteur pour aller cher- cher les informations d’instance telles que l’ID de l’hôte et la saveur (Ram, CPU, disque) ;\nétape 15 : Nova-conducteur reprend la demande de la ﬁle d’attente ;\nétape 16 : Nova-conducteur interagit avec la Nova-base ;\nétape 17 : Retourner les informations d’instance ;\nétape 18 : Nova-compute prend les informations d’instance de la ﬁle d’attente ;\nétape 19 : Nova-compute fait l’appel REST en passant auth-jeton aux glance-api pour obtenir l’image URI par Image ID de glance et de télécharger l’image de stockage d’images ;\nétape 20 : glance-api valide l’auth-token avec keystone ;\nétape 21 : Nova-compute obtient les méta-données d’image ;\nétape 22 : Nova-compute fait l’appel REST-call en passant auth-token au API du réseau pour allouer et conﬁgurer le réseau de telle sorte que la nouvelle instance obtienne une adresse IP ;\nétape 23 : Neutron serveur valide l’auth-token avec keystone ;\nétape 24 : Nova-compute obtient les informations du réseau ;\nétape 25 : Nova-compute fait l’appel REST en passant auth-token à API Volume pour attacher le volume à l’instance ;\nétape 26 : Cinder-api valide l’auth-token avec keystone ;\nétape 27 : Nova-compute obtient l’information de stockage de bloc ;\nétape 28 : Nova-compute génère les données au l’hyperviseur pour l’exécuter via libvirt ou API.\nCes étapes nous aideront à comprendre le mécanisme de la création d’une instance qui est la base de notre scénario. Aussi, cette démarche est nécessaire et utile, pour la suite dans la partie des discussions des résultats.\nDans les statistiques, une expérience factorielle complète est une expérience dont la concep- tion se compose de deux ou plusieurs facteurs, chacun avec des valeurs discrètes possibles aux\n«niveaux», et dont les unités expérimentales prennent toutes les combinaisons possibles de ces niveaux à travers tous ces facteurs. Une telle expérience permet au chercheur d’étudier l’effet de chaque facteur sur la variable de réponse, ainsi que les effets de facteurs sur les interactions avec la variable de réponse.\nNotre plan d’expérience est basé sur l’utilisation du plan de conception de dépistage (tami- sage) pour évaluer et déterminer l’importance de chaque variable indépendante. En effet, nous avons déﬁni les variables indépendantes dans la section 3.1.1 comme suit :\n– nombre d’utilisateurs (user) : chaque instance créée est utilisée par un ou plusieurs utilisa- teur(s) ; voir ﬁgure 4.3 étapes 1-5 ;\n– nombre de projet (tenant) : dans chaque projet, nous trouvons une ou plusieurs instances qui sont accédées par un ou plusieurs utilisateur(s) ; voir ﬁgure 4.3 étapes 1-5 ;\n– nombre d’instances : nombre d’instances que nous pouvons créer. (pour chaque instance le processus se répète voir ﬁgure 4.3 étapes 5-28).\nL’objectif de cette méthodologie adoptée tourne autour de deux points principaux :\n– trouver les relations avec ces paramètres, ainsi que leurs interactions qui ont un effet signiﬁ- catif sur la variable de réponse ;\n– optimiser le nombre des paramètres possibles.\nPour résumer, nous nous sommes préoccupés de l’identiﬁcation qui est facteur à effet impor- tant sur la variable dépendante (taux de réussite %) sur OpenStack. Ce type de plan factoriel complet est souvent utilisé et recommandé comme modèle attribué pour un certain nombre de facteurs moins de (< 5), cela donne des résultats plus précis, car chaque interaction est estimée séparément (MONTGOMERY, 2001e). Trois réplications ont été effectuées pour chaque com- binaison de facteurs, et donc 24 (2 3 ∗ 3), simulations ont été exécutées. À partir de quelques expériences de simulation préliminaires, les plages du domaine expérimental ont été établies, elles sont présentées dans le tableau suivant : Nous avons utilisé Statgraphics comme outil\npour réaliser nos tests aﬁn d’extraire le(s) facteur(s) le plus signiﬁant(s). Entre autre, Statgra- phics est un progiciel statistique qui permet d’effectuer et d’expliquer les fonctions statistiques de base avancées. (Voir annexe pour plus de détail).\nNotons ici que le taux de réussite est présenté dans le chapitre précédent ; se référer au :\n– Nombre de demandes de suppression qui ont été demandées mais non réalisées ;\n– ET, se référer aux cas où les demandes de suppression ne peuvent pas être supprimées, car elles ne sont pas créées en premier lieu.\nSuivant le plan d’expérience et l’algorithme décrit dans le chapitre précédent, nous avons ef- fectué une série de tests.\nLes tableaux représentent un résumé des différents scénarios de la création et de la suppres- sion des machines virtuelles, répétés cinq fois, aﬁn de valider les résultats obtenus (la collecte des métriques). Nous rappelons que nous avons déﬁni quatre critères (Disponibilité, Précision, Rapidité et Coût) voir section 3.1.1.\n– nova.boot_server : se réfère à la création de la machine virtuelle ;\n– nova.delete_server : se réfère à la suppression des machines virtuelles ;\n– min, Avg, max(sec) : se réfèrent au temps pris pour terminer le scénario ;\n– success : se réfèrent au taux de réussite de chaque scénario ;\n– before, after : se réfèrent au cas de changement (déboguer) dans la conﬁguration aﬁn d’amé- liorer la performance du OpenStack s’il y a eu lieu.\nNous expliquons la baisse du taux de réussite dans le tableau 4.3 (success/before) avant d’ef- fectuer un changement dans la conﬁguration d’OpenStack, par le fait qu’OpenStack installe ces composants avec des paramètres par défaut. Il attribue à chaque projet (tenant) un nombre limité d’instances (voir 10 instances au maximum). Pour contourner ce problème, nous avons deux approches à suivre. La première approche est de réguler pour chaque projet (tenant) un nombre d’instances plus que 10, c’est à dire à chaque fois nous faisons un changement, dépen- dant des entrées du scénario (nombre d’instance, utilisateur, locataire). La deuxième approche est de déﬁnir dès le début un nombre illimité d’instances que nous pouvons associer à chaque projet, voir tableau 4.4. Nous remarquons, aussi, une différence d’à peu près de 60 secondes entre deux tests (before/after), cela s’explique par le fait que nous atteignons la limite, OpenS- tack (Nova Controller) rejette toute demande d’ajouter de nouvelles machines virtuelles.\nPour la deuxième catégorie d’essai (création de 500 instances), nous avons opté d’abord pour\nchanger les paramètres du quota d’un nombre précis à un nombre illimité, dans chaque nouveau locataire créé, aﬁn de se passer du problème de la limitation des instances associé à ce dernier. Après le lancement de 500 cas en parallèle, nous observons un taux de réussite en baisse (voir tableau 4.5 (success/before)). En raison du délai d’attente sur nova du nœud de calcul (com- pute nœud), une VIF est mise en place par Neutron, les machines virtuelles n’arrivent pas à\nêtre créées correctement, car elles n’ont pas une adresse IP et une adresse mac à cause de la densité de charge de travail. Cette lacune s’explique par le fait que le nombre de worker de Neutron est limité, ainsi que ces workers sont responsables de traiter les demandes de création des instances et d’allouer les adresses IP et MAC à ces derniers.\nPar ailleurs, avec cette version d’OpenStack (IceHouse) nous avons la possibilité de personna- liser et de modiﬁer le nombre de threads (worker threads) que Neutron peut utiliser, donc nous avons mis à jour Neutron plug-in en modiﬁant ce paramètre, aﬁn d’améliorer sa performance (voir annexe).\nPar défaut, Neutron est conﬁguré pour correspondre à la même conﬁguration que Nova, c’est- à-dire 1 processus par cœur - en utilisant notre propre conﬁguration (en multipliant par 4 le nombre de worker threads). Nous avons mis 48 processus pour chaque composant dans le nœud contrôleur (48 neutron-server processes, 48 nova-api processes, 48 nova-conductor processes) tableau 4.6. Ceci nous a permis de surmonter le problème de délai d’attente de la création de VIF.\nToutefois, il y a une autre solution : modiﬁer en maximisant le nombre de workers par le fait de séparer les deux composants en mettant chacun dans un nœud indépendant. Ceci réduira le fait de partage des ressources physiques, entre les composants du contrôleur et le composant du Neutron.\nOn peut résumer les résultats obtenus sous forme de deux grands tableaux comme suite :\nbefore max (sec)\nbefore Avg (sec)\nbefore min (sec) after\nbefore min (sec)\nAﬁn d’étudier et d’analyser l’effet de chaque variable indépendante (F 1 , F 2 , F 3 ) ainsi que leurs\ninteractions sur le critère de performance (ie taux de réussite), à l’aide de Statgraphics, nous\navons utilisé une analyse multifactorielle de variance (Anova). Le tableau 4.9 montre que le\nmodèle représentant explique plus de 85% de la variabilité observée dans le taux de réussite\n(MONTGOMERY, 2001e). Par conséquent, nous comprenons que le seul facteur principal\nsigniﬁcatif est le nombre d’instances et toute autre interaction à un niveau de conﬁance de 95%\ntableau 4.9. Aussi, la ﬁgure 4.4 illustre les effets des variables indépendantes (F 1 , F 2 , F 3 ), leur\ninteraction et leur effet quadratique sur les variables de réponse (taux de réussite).\nA : Number_of_instances\nB : Number_of_Tenants\nC : Number_of_User\nDonc, nous pouvons conclure de cette expérience qu’OpenStack est stable et qu’il peut suppor-\nter la charge de travail tant qu’il a sufﬁsamment de ressources pour appuyer une telle charge.\nAussi, le seul facteur qui peut inﬂuer sur son rendement est le nombre d’instances créées.\nDe plus, nous avons ﬁxé les deux paramètres (utilisateur et projet) puis nous avons augmenté\ngraduellement le nombre de machines virtuelles à créer, aﬁn de trouver le point de saturation.\nEn outre, nous ne pouvons pas augmenter le nombre d’instances parallèles au-delà de 800,\nparce que la performance diminue d’une manière signiﬁcative et nous perdons la connexion\nentre l’agent neutron et RabbitMQ. Comme par défaut, RabbitMQ gère plus de 1000 connexions simultanées, nous avons découvert que les instances ont été bloquées dans la phase du réseau en attendant pour obtenir une interface virtuelle (VIF). Normalement, lorsque la Nova envoie une requête à Neutron pour attribuer une adresse IP et Mac, Neutron lui-même demande de créer un dispositif Tap (Tap device) (voir ﬁgure 4.5). Mais, après un temps mort sans obtenir VIF, la demande est abandonnée.\nPlusieurs hypothèses se sont présentées pour comprendre d’où vient le problème. Première- ment, nous avons soupçonné que la performance est en baisse à cause de la nature du scénario. Les instances sont créées, simultanées sans aucun temps d’attente pour obtenir la réponse. Ceci peut causer ce genre de dégradation, car l’envoi d’une grande charge à la fois sans attendre la réponse pourrait créer des problèmes de surcadencés (overclock).\nNous avons changé le mode du scénario de constant à en série (en créant un bloc de ma-\nchines virtuelles puis nous attendons quelques secondes avant de lancer le bloc suivant et ainsi de suite) pour voir si c’est le cas ; mais la performance ne s’est pas améliorée. Par conséquent, le problème ne vient pas de la surcadencée.\nDeuxièmement, nous avons pensé qu’avec la création de 800 instances et plus, nous avons déjà atteint la limite des ressources physiques. Ce qui provoque le Overcommitting ou Oversub- scription CPU ratio. Dans notre cas, nous avons 24 cores par serveur avec le Hyperthreading opérationnel. Autrement dit, nous avons en total 72 cores.\n– chaque hôte a deux six processeurs de base et l’hyperthreading est activé, cet hôte a vingt- quatre processeurs physiques CPU (6 cœurs x 2 processeurs x 2 threads par cœur).\nSuivant les descriptions/recommandations d’OpenStack concernant l’allocation des VCPUs aux instances, avec ces caractéristiques matérielles, nous pouvons aller même à 1152 VCPU (Wiki, 2015).\n– ratio d’allocation de CPU est 16 :1. Pour chaque CPU, nous pouvons lui associer 16 VCPUs.\nLa formule appliquée pour le nombre d’instances virtuelles sur un nœud de calcul est (OR * PC) / VC, où :\n– OR est CPU Ratio de surcharge (cœurs virtuels par cœur physiques) ;\n– PC est Nombre de cœurs physiques ;\n– VC est Nombre de cœurs virtuels par instance.\nThéoriquement, nous pouvons aller au-delà de 800 instances puisque, nous associons pour chaque virtuelle machine créée un seul virtuel CPU (VCPU).\nDe plus, nous trouvons dans les ﬁches techniques de la virtualisation comme dans (LOWE, 2015) que l’idéal est d’aller jusqu’à 75% du ratio ce qui revient à créer 864 (1152 * 75%)\ninstances. Même avec cette recommandation, nous n’arrivons pas à allouer plus 800 instances.\nCependant, nous remarquons que la cause provient du par-feu des règles de groupe de sécu-\nrité de Neutron (Neutron security group ﬁrewall) de l’agent Neutron sur le contrôleur. Après la\ncréation d’un dispositif de TAP ( voir ﬁgures 4.5 et 4.6) Nova envoie RPC pour aviser l’agent\nDHCP, aﬁn d’allouer des adresses IP et MAC, puis il notiﬁe Security Group Server.\nCependant, en raison du grand nombre de demandes, agent de Neutron prend plus de temps\nque le temps normal requis pour vériﬁer et mettre à jour les règles iptables de pare-feu. D’où\nune dégradation croissante sur la création des instances.\nEn effet, l’itération avec OpenStack Compute (Nova) est plus spéciﬁque. Lorsque Nova lance\nune instance virtuelle, le service communique avec OpenStack réseau (Neutron) aﬁn de bran-\ncher chaque interface réseau virtuelle à un port particulier Figure 4.6 4.5. Comme le nombre\nde ports par groupe de sécurité par défaut augmente, le nombre d’entrées iptables sur le nœud\nCompute grandit. Pour cette raison, il y a une augmentation progressive du temps nécessaire\npour appliquer les chaines et les règles (chains and rules). Avec cette version de IceHouse, actuellement, nous utilisons une liste de compréhension pour savoir si une nouvelle chaine ou règle correspond à une déjà existante. Et cela affecte le temps de la création VIF qui explique pourquoi nous obtenons des échecs d’activation de l’instance. Cette erreur est un des points à ﬁxer dans les versions avenir d’OpenStack. Parmi les solutions proposées, nous avons :\n– changer Neutron par nova-network ;\n– améliorer la méthode du gestionnaire iptables et modiﬁer les règles ;\n– analyser toute la liste dans le sens inverse pour trouver une entrée correspondante plus rapi- dement ;\n– ajouter une nouvelle méthode qui permet de retourner l’entrée que nous recherchons ;\n– augmenter le délai/temps d’attente au niveau de Neutron ;\n– décomposer l’entité Contrôler et Neutron en deux entités indépendantes aﬁn d’éliminer la possibilité de partages des ressources physiques.\nAﬁn d’évaluer le pourcentage de la charge du processeur et de l’exécution du programme Temps (PET), nous évaluons et analysons la consommation de CPU et le temps moyen néces- saire pour accomplir une tâche en fonction du nombre des instances créées et supprimées après utilisation. Pour évaluer la performance du nœud de contrôleur, tout en créant et en supprimant un ensemble d’instances et pour superviser la consommation de CPU, un nombre d’instances varie de 100 à 800. Les résultats peuvent être vus sur les ﬁgures 4.7 et 4.8 qui montrent que le nombre d’instances affecte de manière signiﬁcative la charge du CPU. La charge de CPU augmente d’une manière graduelle lorsque le nombre d’instances est en dessous de 600, tandis que pour un nombre d’instances plus élevé (au-delà de 700) la charge CPU semble se stabiliser autour de 80%. En outre, il existe une corrélation entre le nombre d’instances et la charge CPU, et il atteint sa charge CPU maximum pour 800 instances. Nous expliquons le fait que le CPU a atteint sa valeur maximale de 85%, vu que nous n’avons pas pu aller au-delà de 800 instances à cause des lacunes citées au cours des discussions.\nDans la deuxième partie de ces tests, le temps d’exécution du programme a été mesuré\npendant les mêmes tests. Les résultats obtenus peuvent être vus sur la ﬁgure 4.9 et la ﬁgure\n4.10 qui montre une forte corrélation entre le temps nécessaire pour réaliser le scénario et le\nnombre d’instances. Dans l’intervalle de 100 à 800, cette fonction augmente d’une manière\nD’après ces résultats obtenus, nous voyons clairement que le processus de provisionnement\nd’une machine virtuelle nécessite plus de temps et de charge de CPU que la suppression, cela\ns’explique que lorsqu’on crée une instance, nous faisons une sorte de collecte de données, à\npartir des différents composants puis nous les présentons à l’hyperviseur pour allouer cette ins-\ntance. Par contre, dans le cas de la suppression nous supprimons cette instance de l’hyperviseur\ndirectement ce qui ne requière pas une grande charge de CPU et du temps pour exécuter cette\nDans cette section, nous présenterons une discussion sur les menaces de validité. En effet, au cours de la réalisation de ce présent mémoire, nous nous sommes mis dans un contexte précis, où nous sommes limités à quelques aspects, aﬁn de bien se focaliser dans la phase des tests et des interprétations. D’où la présence des menaces à la validité des résultats.\nEn effet, les critères de performance du Cloud Middleware ainsi que le banc d’essai, la conﬁ- guration et le scénario pris en considération dans nos expériences, nous ont permis d’atteindre les résultats et les synthèses présentés ci-dessus.\nPar ailleurs, si nous changeons ou nous rajoutons aux facteurs d’entrée (nombre d’utilisateur, nombre de projet et nombre d’instances) d’autres facteurs, comme le type et la taille d’image de l’instance, la capacité de stockage et la précision de la plage d’adresse, ceci conduit à obte- nir des résultats différents de ceux présentés dans la section Résultats et interprétation, et qui a été explique en détail dans le chapitre Méthodologie de Travail.\nDe ce fait, nous pourrons obtenir d’autres facteurs signiﬁcatifs ainsi qu’une existence des dé- pendances entre ces facteurs, ce qui n’était pas le cas dans notre étude. De plus, l’architecture déployée joue aussi un rôle très important. Dans notre étude, nous avons combiné le noeud du controlleur ainsi que le noeud du réseau (Neutron) dans un seul serveur. Si on sépare ces deux noeuds sur deux serveurs indépendants, nous aurons une tendances logarithmique pour la varia- tion du CPU et le temps d’exécution peut être diminué. Mais avec certain nombre d’instances on pourrait avoir le problème de la vériﬁcation du tableau de contrôle sur le noeud Neutron (voir Résultats et interprétation).\nLe partage des ressources physiques entre deux composants assez importants nécessite dès le départ assez de ressources physiques aﬁn de fonctionner au maximum. Ils peuvent inﬂuencer sur la performance d’OpenStack. Nous expliquons le fait d’avoir combiné le noeud Controlleur\net le noeud réseau, à cause du manque des ressources ainsi que nous voulons avoir plus d’un noeud compute possible aﬁn d’héberger le plus d’instances possibles. Avec les caractéristiques matériels que nous avons utilisé, on peut dire que chaque serveur peut contenir plus d’une deux centaines d’instances.\nUn banc d’essai a été déployé pour expérimenter la méthodologie présentée dans le chapitre précédent. Par la suite, deux grandes catégories d’expérimentations ont été exécutées sur ce banc d’essai. La première a pour but d’extraire le facteur signiﬁcatif parmi l’ensemble des facteurs, d’étudier leur impact sur les ressources matérielles : à savoir la charge du CPU et le temps nécessaire pour performer ces bancs d’essai.\nLes résultats ont montré que les trois facteurs, à savoir le nombre des nœuds compute, le nombre de Workers et la capacité du CPU sont des facteurs déterminants pour la performance du OpenStack, alors que le nombre d’utilisateurs et le nombre des projets n’ont pas d’impact signiﬁcatif sur la performance.\nAlors que la migration vers des solutions technologiques basées sur le Cloud aﬁn de minimiser CAPEX/OPEX, plusieurs Cloud Middlewares ont été proposés, mais ces derniers restent en question. En effet, ces Cloud Middlewares étaient présentés aﬁn de maximiser l’utilisation des ressources matérielles et pour plus économiser le coût de déploiement. Par conséquent, cette migration met en question le proﬁlage de la performance du Cloud Middleware ainsi que son impact sur la couche physique.\nNous avons déterminé les métriques décrivant la performance du Cloud Middleware, soit lo- cataire, utilisateur, instance. Puis, nous avons déﬁni le temps d’exécution et le CPU comme métriques à superviser en phase des tests, aﬁn de comprendre l’impact de ces derniers sur l’in- frastructure. Enﬁn, nous avons déﬁni une méthodologie de tests en nous basant sur les plans d’ expériences aﬁn de structurer nos tests.\nLe proﬁlage de la performance du Cloud Middleware étant difﬁcile, ce mémoire répond à une partie de la problématique. Autant que nous sachions, ce travail présente une première initiative au proﬁlage du Cloud Middleware. Les travaux de recherches, dans ce domaine, sont encore à leur début.\nComme discuté dans le deuxième chapitre de ce mémoire, la grande majorité des travaux tourne autour de l’analyse des applications déployées sur le Cloud , en considérant le Cloud Midd- leware comme acquis. Nous avons montré qu’il est possible de proﬁler le Cloud Middleware en se basant sur une méthodologie de travail qui s’accentue sur les plans d’expérience. Nous avons abordé cette problématique de recherche, en traitant les aspects conceptuels d’une telle architecture distribuée ainsi que la gestion des ressources dans ce type d’infrastructures.\nGrâce aux expérimentations, aux résultats obtenus et aux discussions de ce mémoire de re-\ncherche appliquée, nous avons identiﬁé que la performance de OpenStack est contrôlée par deux paramètres qui sont corrélés ; le nombre de noeuds de calcul et le nombre de travailleurs (workers) à travers les serveurs Nova Controller et Neutron. Aussi, le facteur le plus signiﬁcatif est le nombre de machine virtuel. Les ressources consommé par OpenStack en termes d’unité centrale de traitement CPU augmente avec le nombre d’instances créées ainsi que le temps nécessaire pour créer des instances augmente de façon linéaire avec le nombre d’instances.\nPar ailleurs, nous pouvons identiﬁer plusieurs problématiques de recherche que nous propo- sons comme travaux futurs. Parmi ces derniers, nous pouvons citer : agrandir le plan de travail en incluant d’autres facteurs que nous avons considérés comme stables dans nos expériences et aussi investiguer d’autre type de scénarios à savoir : la migration d’un centre de données à un autre en temps réel. Un autre onglet de recherche serait de se concentrer sur l’utilisation d’un autre type d’hyperviseur comme Xen et de faire les mêmes expérimentations aﬁn de voir quel type de virtualisation donne de meilleurs résultats pour les Cloud Middleware.\nPour conclure ce mémoire, nous soulignons que ce dernier a fait l’objet d’une publication d’un article de conférence qui s’intitule : Resource Consumption Assessment for Cloud Middleware publier en EAI International Conference on Smart Sustainable City Technologies en Octobre, 2015. (voire Annexe)\nKVM est un hyperviseur de type 2. Libvirt est un gestionnaire de machines virtuelles. Virt- manager est une interface graphique pour la gestion des machines virtuelles.\nsudo apt-get install qemu-kvm libvirt-bin virt-manager You need to ensure that your username is added to the group libvirtd :\nsudo adduser ‘id -un‘ libvirtd Pour ajouter votre <nom d’utilisateur> pour les groupes :\n$ sudo adduser ‘id -un‘ kvm\nAdding user ’<username>’ to group ’kvm’\n$ sudo adduser ‘id -un‘ libvirtd\nAdding user ’<username>’ to group ’libvirtd’\nFacultatif : Installez virt-manager (interface utilisateur graphique) Si vous travaillez sur un ordinateur de bureau, vous voudrez peut-être installer un outil gra- phique pour gérer les machines virtuelles.\n$ sudo apt-get install virt-manager Pour plus de détail :\nL’installation d’OpenStack via Devstack ; après le téléchargement dû git :\n/home/ubuntu/$git clone https ://git.openstack.org/openstack-dev/devstack Accéder et créer un ﬁchier nommé local.conf pour le nœud de compute. /home/ubuntu/devstack/$ vim local.conf\nADMIN_PASSWORD=systemets ADMIN_PASSWORD=$ADMIN_PASSWORD MYSQL_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD SERVICE_TOKEN=systemlazy\nNOVA_VNC_ENABLED=True NOVNCPROXY_URL="http ://$SERVICE_HOST :6080/vnc_auto.html" VNCSERVER_LISTEN=$HOST_IP VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN\n# Github’s Branch GLANCE_BRANCH=stable/icehouse HORIZON_BRANCH=stable/icehouse KEYSTONE_BRANCH=stable/icehouse NOVA_BRANCH=stable/icehouse NEUTRON_BRANCH=stable/icehouse HEAT_BRANCH=stable/icehouse\nCEILOMETER_BRANCH=stable/icehouse Même chose créer un ﬁchier local.conf pour le nœud contrôleur :\n/home/ubuntu/devstack/$ vim local.conf [[local|localrc]] DEST=/opt/stack LOGFILE=$DEST/logs/stack.sh.log VERBOSE=True OFFLINE=False LOG_COLOR=False SCREEN_LOGDIR=$DEST/logs/screen\n# Credentials ADMIN_PASSWORD=systemets ADMIN_PASSWORD=$ADMIN_PASSWORD MYSQL_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD SERVICE_TOKEN=systemlazy\n# Neutron options Q_USE_SECGROUP=True\nQ_USE_PROVIDERNET_FOR_PUBLIC=True OVS_PHYSICAL_BRIDGE=br-ex PUBLIC_BRIDGE=br-ex OVS_BRIDGE_MAPPINGS=public :br-ex ENABLED_SERVICES=rabbit,mysql,key