Architecture Description Language (ADL)

Télécharger le fichier original (Mémoire de fin d’études)

Le Cloud Computing

Généralités et Définition

Face à l’augmentation continuelle des coˆuts de mise en place et de maintenance des systèmes informatiques, les entreprises externalisent de plus en plus leurs ser-vices informatiques. Elles confient leur gestion (des services informatiques) à des en-treprises spécialisées (que nous appelons fournisseurs). L’intérˆet principal de cette stratégie réside dans le fait que l’entreprise ne paie que pour les services eﬀective-ment consommés. En eﬀet, une gestion interne de ces services par l’entreprise ne serait pas complètement amortie, en particulier lorsque les besoins d’utilisation va-rient. Le développement de ce mode de fonctionnement a et´ favorisé par plusieurs facteurs tels que l’évolution et la généralisation des accès internet, l’augmentation de la puissance des ordinateurs et des réseaux informatiques. Le Cloud Computing se situe dans cette orientation récente.
Devant le manque de consensus sur la définition de la notion de Cloud Compu-ting, nous reprenons la définition proposée par CISCO [? ] : ”le Cloud Computing est une plateforme de mutualisation informatique fournissant aux en-treprises des services à la demande avec l’illusion d’une infinité des ressources”. Dans cette définition, nous retrouvons quelques similitudes avec les plateformes connues comme les grilles de calcul ou encore les centres d’héberge-ment. Il est présent´ dans la littérature comme une évolution de ces infrastructures d’hébergement mutualisées. En guise d’exemple, prenons l’évolution proposée par [? ] (figure 2.1) qui est largement citée dans la littérature. D’après [? ], le cloud computing est le fruit d’une évolution pouvant ˆetre présentée en 5 phases :
– Elle débute avec les Fournisseurs d’Accès Internet (FAI 1.0). Ils ont pour but de mettre en place des moyens de télécommunication afin d’assurer le raccor-dement des personnes ou entreprises au réseau internet.
– La seconde phase est l’orientation des FAI vers l’hébergement de pages web (FAI 2.0). Cette phase marque un grand bond dans le développement d’inter-net.
– La troisième phase (FAI 3.0) est la possibilité qu’oﬀrent les FAI a` héberger des applications métiers des entreprises.
– Une connaissance des besoins applicatifs des entreprises permettent aux FAI de faire évoluer leur domaine d’intervention. Ils mettent en place des plate-formes de génération d’applications a` la demande. Il s’agit des ASP (Appli-cation Service Provider) dont les ”Software as a Service” (section 2.1.5.2) sont des dérivés : c’est le FAI 4.0.
– La généralisation des pratiques précédentes, la prise en compte de nouvelles pratiques et l’intégration des principes que nous présentons dans les sections suivantes donnent naissance au cloud computing.
Suivant cette évolution, nous présentons dans la section suivante notre point de vue concernant la position du cloud computing par rapport aux plateformes d’hébergement mutualisées comme les grilles [? ] (grid5000 [? ], Globus [? ]).
N.B : Dans ce document, nous utilisons l’acronyme ”CC” pour désigner la tech-nologie Cloud Computing et le terme ”cloud” pour parler d’une plateforme de Cloud Computing.

Cloud vs Grilles

Introduites pour la première fois dans les années 90, les grilles de calcul situent la mutualisation au cœur de leur technologie. De mˆeme, la mutualisation est au cœur de la technologie du CC. La question que nous nous posons : ”A quel niveau se situe la diﬀérence entre le cloud et les grilles (si elle existe) ?”. Autrement dit, le terme ”Cloud Computing” n’est-il pas une autre appellation de ”Grid Computing”? Après consultation de la littérature, nous ne trouvons qu’une étude sérieuse consacrée entièrement a` cette comparaison ([? ]). Le constat global de [? ] est proche du nˆotre. D’un point de vue technologique nous n’identifions pas de réelle diﬀérence entre les plateformes de grille et de cloud. Cependant, l’ouverture du cloud aux utilisateurs de diﬀérents niveaux (pas toujours des informaticiens comme dans les grilles) et éventuellement son caractère commercial sont les potentielles diﬀérences que nous identifions. De plus, dans les environnements de grilles, les applications (appelées le plus souvent job) s’exécutent généralement sur une durée limitée (mˆeme si celle-ci peut ˆetre illimitée comme dans le cloud). Comme nous le présentons dans la section 3, ces diﬀérences rendent la gestion et l’utilisation des plateformes de cloud plus complexes que dans les grilles.
Somme toute, nous considérons que la technologie de cloud computing utilise la technologie de grille à laquelle elle associe les principes d’ouverture au public, de facturation, et d’hébergement durable. Dans la section suivante, nous détaillons ces diﬀérents principes.

Principes

Nous avons enonc´ dans la section précédente quelques principes fondamentaux du cloud. Ces principes lui permettent de se démarquer des plateformes d’héber-gement classiques (grille, data center, centre d’hébergements). Les plus importants d’entre eux sont la mutualisation et la facturation des ressources a` l’usage :
La mutualisation. C’est la pratique qui consiste à partager l’utilisation d’un ensemble de ressources par des entreprises (ou entités quelconques) n’ayant aucun lien entre elles. Les ressources peuvent ˆetre de diverses natures : logicielles ou maté-rielles (machines, équipements réseau, énergie électrique). Cette pratique dépend du désir des entreprises de délocaliser leurs services informatiques vers des infrastruc-tures de cloud.
Reposant sur les technologies de grilles, le cloud doit cependant faire face aux problèmes liés a` son exploitation et utilisation. Il s’agit des problèmes classiques tels que la sécurité, la disponibilité, l’intégrité, la fiabilité et l’uniformité d’accès aux données.
L’allocation et facturation à la demande. Contrairement aux centres d’hé-bergement web classiques dans lesquels le paiement se fait à l’avance sous forme de forfait, le cloud propose une facturation à l’usage. Cette dernière peut ˆetre implémen-tée de deux fa¸cons. La première consiste a` facturer à l’entreprise la durée d’utilisation d’un ensemble de ressources quelque soit l’utilisation eﬀective. Par exemple, soit r l’ensemble des ressources réservées par l’entreprise. Soient t1 et t2 respectivement l’instant de début et de fin d’utilisation des ressources. Soit Cu le coˆut d’utilisation d’une ressource durant une unité de temps. Ainsi, le coˆut total d’utilisation de l’en-semble des ressources r est : Cr=(t2-t1)*Cu*r . Quant à la deuxième fa¸con, elle est beaucoup plus fine que la première. Elle consiste a` facturer les véritables instants pendant lesquels les ressources ont eté utilisées. En partant des mˆemes paramètres que précédemment, soit T={tu1,tu2,. . . ,tun} avec tui ∈[t1 ;t2], 1≤i≤n, l’ensemble des unités de temps pendant lesquelles les ressources ont et´ réellement utilisées. Dans ce cas, le coˆut total d’utilisation de l’ensemble des ressources r est : Cr=Cu*r* n tui. i=1
A la lumière de ces pratiques, nous montrons dans quelle mesure les conséquences de l’utilisation du cloud peuvent ˆetre bénéfiques à la fois pour le fournisseur et pour les entreprises qui y ont recours.

Bénéfices

Les retombées des principes du cloud sont bénéfiques a` la fois pour son fournis-seur, les entreprises délocalisant leurs infrastructures et plus largement pour la na-ture (au sens écologique). Globalement, ils assurent aux deux premiers une meilleure rentabilit´. De plus ils permettent à l’entreprise de se concentrer sur les tˆaches de production autres que la maintenance de systèmes informatiques.
Pour le fournisseur
Les bénéfices du fournisseur sont uniquement dˆus au fait de la mutualisation des ressources. En eﬀet, après son investissement dans la mise en place des infra-structures pour le cloud, il fait payer aux entreprises la marge nécessaire pour sa rentabilisation. Comme pour une entreprise disposant d’une plateforme interne, il paie pour les frais d’administration de l’ensemble. Cette dépense peut ˆetre amortie par facturation aux entreprises. En plus de cette marge, il benéficie des coˆuts de réutilisation des ressources. En eﬀet, compte tenu de la non appartenance des res-sources aux entreprises, elles (les ressources) leurs sont facturées a` chaque usage. La mˆeme ressource peut ainsi faire l’objet de plusieurs facturations.
Pour l’environnement
A l’ère de l’écologie et des politiques de réduction de la consommation energé-tique, l’investissement dans les plateformes de cloud représente un geste envers la nature. La mutualisation de ressources (telle que pratiquée dans le cloud) accompa-gnée par la délocalisation des infrastructures d’entreprise vers les clouds permettent de réduire les consommations energétiques. Pour illustrer cette aﬃrmation, reprenons l’étude [? ] réalisée par le groupe ”WSP Environment & Energy (WSP E&E)”1 pour le compte de Microsoft à propos de la plateforme de cloud Azure [? ]. Cette étude est résumée dans sa conclusion : ”Moving business applications to the cloud can save 30 percent or more in carbon emissions per user.”. Elle montre que la délocalisation des applications Microsoft Exchange Server 2007 [? ] des entreprises vers le cloud Microsoft Azure permet de réduire d’au moins 30% les émissions CO2 par utilisateur de chaque entreprise. Cette réduction s’explique par deux facteurs. D’une part, la délocalisation permet de réduire le nombre et la taille des infrastructures informa-tiques en service. Ceci implique donc une réduction de la consommation energétique (donc moins de rejet de CO2). D’autre part, le fournisseur Microsoft implante dans son cloud des techniques d’utilisation eﬃcace de ressources. Pour l’entreprise
C’est elle la première gagnante de cette technologie. Elle réalise des bénéfices en argent et en flexibilité dans sa capacité à s’agrandir.
La réduction des coˆuts. Le recours au cloud permet a` l’entreprise d’ˆetre fac-turée à l’usage, en fonction de ses besoins. Pour avoir une idée du gain réalisé, reprenons cette observation de Michael Crandell du groupe RightScale [? ] à propos du cloud d’Amazon [? ] : ”Le coˆut a` pleine charge d’un serveur sur Amazon se situe entre 70$ et 150$ par mois alors qu’il s’élève a` 400$ en moyenne par mois s’il était héberg´ par l’entreprise en interne”. Plusieurs raisons expliquent cette diﬀérence de coˆut. En eﬀet, une gestion interne de l’infrastructure implique l’achat des matériels, l’aﬀectation du personnel (et donc du coˆut salarial qu’il induit) pour la gestion de l’infrastructure et divers moyens de production mis en place pour le fonctionnement de l’ensemble (électricité, locaux, etc). Le partage de ressources tel que pratiqué dans le cloud permet au fournisseur de répartir ces coˆuts entre plusieurs entreprises.
La réduction des gaspillages. Les infrastructures gérées en interne sont sou-vent sous-utilisées, alors que l’infrastructure d’un cloud mutualise l’ensemble de res-sources pour un grand nombre d’entreprises. La mutualisation consiste a` mettre à la disposition de plusieurs utilisateurs une base commune de ressources. Elle per-met ainsi d’augmenter le taux d’utilisation de ces ressources. En eﬀet, les ressources n’étant pas dédiées à un seul utilisateur, elles pourront servir a` d’autres en cas de besoin.
La flexibilit´ et accès aux ressources large échelle. L’entreprise peut aug-menter la capacité de son infrastructure sans investissement majeur. En eﬀet, grˆace a` l’allocation dynamique (à la demande) des ressources qu’oﬀre le cloud, il suﬃt de souscrire a` de nouvelles ressources et celles-ci sont directement allouées. De plus, l’entreprise est libre de ses allées et venues car les contrats d’utilisation sont limités dans le temps (autour de l’heure). Ainsi, l’entreprise peut augmenter ou réduire son infrastructure à sa guise a` moindre coˆut et dans un délai réduit. Rappelons que le cloud oﬀre ainsi à l’entreprise une possibilité d’accéder à une quantité de ressources dont elle ne pourrait se l’oﬀrir en interne. Elle peut dorénavant envisager des ap-plications large échelle sans se soucier de l’obtention des équipements. A ce sujet, on observe quelques dérives avec des groupes qui acquièrent un grand nombre de ressources dans les clouds a` des fins criminelles (décryptage de clé de sécurit´ ou dénis de service en sont des exemples) 2.
Notons que cette flexibilit´ dépend du type de cloud considér´ (section suivante). Par exemple, l’augmentation de ressources dans un cloud de type entreprise ne sera pas aussi rapide que dans un cloud de type fournisseur de services. Dans le premier cas, la décision est prise de fa¸con collégiale (entre toutes les entreprises intervenantes) et peut donc prendre un temps considérable. A l’opposé, dans le second cas, l’opération se réalise dans l’immédiat.

Classification

Avant de présenter les diﬀérents types de cloud pouvant ˆetre développés, nous établissons dans un premier temps quelques critères de classification :
• La raison de développement (business model ). C’est la raison qui justifie la mise en place de la plateforme. Elle peut ˆetre commerciale, scientifique ou communautaire.
• Le niveau de services. C’est l’ambition du cloud a` fournir aux entreprises une plateforme proche ou pas de leurs attentes.
• L’accessibilit´. Le cloud peut ˆetre accessible par tous (”cloud public”) ou res-treint a` un public particulier (”cloud privé”). Contrairement aux deux premiers, nous ne développons pas celui-ci étant donné sa simplicité de compréhension.

Par raison de développement

L’utilisation du CC ne se limite pas uniquement aux entreprises a` caractère commercial. En fonction des raisons de sa mise en place, nous distinguons quatre catégories de plateformes de CC a` savoir :
Cloud d’Entreprises. Dans cette catégorie, nous retrouvons des entreprises de petites et de moyennes tailles disposant chacune de peu de ressources et de moyens de maintenance de leurs infrastructures. Elles se regroupent donc autour d’un projet de cloud afin de mutualiser leurs capacités. La plateforme qui en découle est privée, c’est-à-dire accessible uniquement par les entités des diﬀérentes entreprises. Cette plateforme a` l’avantage d’ˆetre de petite taille et d’accès restreint à des utilisateurs connus. Ainsi, les problèmes de sécurit´ sont réduits et l’administration peut ˆetre spécialisée. Les groupes Amazon EC2 [? ] (via le ”Virtual Private Cloud ”), VMware [? ] ou encore VeePee [? ] oﬀrent par exemple des solutions de clouds privés.
En comparaison avec les technologies existantes, cette catégorie est identique aux clusters privés. Cloud Gouvernemental et Recherche Scientifique. Pour des raisons de recherche et de développement, des instituts de recherche mettent sur pied des en-vironnements de cloud. Leur développement est encourag´ et financé par des gou-vernements. L’accès est exclusivement réserv´ aux personnes exer¸cant dans le mˆeme domaine de recherche, ou appartenant aux instituts de recherche associés, ou ayant une dérogation précise. Ces plateformes sont pour la plupart orientées projets. Seules les avancées scientifiques obtenues par les groupes de recherche qui l’utilisent per-mettent de valoriser la plateforme.
D’un point de vue technologique, d’objectif et d’utilisation, aucune diﬀérence n’est notable avec les grilles scientifiques comme grid5000 [? ].
Cloud pour Réseaux Sociaux et Jeux. Le développement des réseaux so-ciaux et des jeux en ligne nécessite de plus en plus de grandes quantités de ressources. Cette nécessit´ est due à la croissance presque exponentielle d’utilisateurs. De plus, l’essence de ces environnements est la mise en commun d’un certains nombre de don-nées et de connaissances (donc de ressources). Dans ce contexte, le développement d’une plateforme similaire au cloud devient une évidence pour optimiser l’utilisa-tion des ressources et faciliter le partage de données. En eﬀet, elles sont considérées comme plateforme de cloud a` cause de leur recours aux principes de développement de celui-ci.
L’ouverture de ces plateformes à tous et le nombre important d’utilisateurs pour-raient constituer un handicap pour leur gestion. Or n’hébergeant qu’une seule ap-plication (celle du fournisseur), leur gestion est spécialisée et moins complexe. Elles sont comparables aux clusters/griles privés. Les plateformes comme celles du réseau social facebook [? ] ou des jeux en ligne zynga [? ] font partie de cette catégorie.
Cloud pour Fournisseurs de Services. C’est le modèle le plus répandu. Une entreprise, appelée fournisseur, met a` la disposition d’autres (appelées clients) une plateforme d’exécution d’applications et assure le service informatique inhérent. Il s’agit d’un modèle ouvert a` tout public et à caractère commercial. La plateforme héberge tous types d’applications et l’accès à ces applications est ouvert aux utili-sateurs externes. Les défis de sécurit´ et d’administration (que nous détaillons dans la section 2.1.6) sont importants dans ce modèle. La plateforme de CC Amazon Elastic Compute Cloud (EC2) fait partie de ce cette catégorie. Sachant que cette catégorie peut regrouper les autres, les contributions que nous apportons dans cette thèse s’adressent a` cette catégorie de cloud. Notons que quelque soit le modèle de développement considéré, la plateforme qui en découle peut également ˆetre classée selon son niveau d’utilisation (section suivante). Notons qu’il existe des communautés de développement logiciels autour de ces catégories de cloud. Elles fournissent des briques logicielles permettant de construi-re/enrichir une plateforme de cloud. Très souvent, il s’agit d’entreprises dont le but est de fidéliser ses clients (futurs propriétaires de plateformes de cloud). Les logiciels sont présentés à ces derniers comme une valeur ajoutée de l’évolution d’un produit existant (comme un système d’exploitation). Ce développement est le plus souvent pratiqué par des communautés de logiciels libres (plateforme Ubuntu Enterprise Cloud [? ] ou Eucalyptus [? ]) ou encore par des grands groupes de développement de logiciels spécialisés (Oracle Cloud Computing [? ]).

Par niveau de service

En fonction du niveau d’abstraction qu’oﬀre le cloud aux entreprises, nous iden-tifions dans la littérature trois catégories de plateformes de CC (figure 2.2(a)) :
Infrastructure as a Service (IaaS). C’est le niveau de service le plus bas. Le cloud fournit des ressources matérielles aux entreprises (capacité de traitement, de stockage, etc.). L’accès a` ces ressources peut ˆetre direct ou virtuel (section 2.2). On retrouve dans cette catégorie les plateformes comme Amazon Elastic Compute Cloud (EC2) [? ] et IELO Cloud [? ].
Platform as a Service (PaaS). Il s’agit d’un niveau d’abstraction au-dessus de l’IaaS dans lequel le cloud fournit une plateforme applicative de programmation. Elle permet à l’entreprise de programmer des applications facilement administrables dans le cloud. Elle oblige l’entreprise d’une part a` maˆıtriser l’API du PaaS et d’autre part a` ré-implémenter ses applications suivant cet API. Google App Engine [? ] et Windows Azure [? ] sont des exemples de PaaS.
Software as a Service (SaaS). Ici, le cloud fournit directement les applica-tions correspondants aux attentes des entreprises. Les tˆaches d’administration sont assurées par le cloud ; l’entreprise n’a pas grand chose à eﬀectuer. Très spécialis´ (par l’application qu’il fournit), ce type de cloud est le moins répandu. Les clouds pour réseaux sociaux et jeux (présentés précédemment) font partie de cette caté-gorie. Comme exemple de plateforme SaaS, nous pouvons citer Rightscale [? ] ou encore CORDYS [? ].
Cette classification est la plus répandue dans la littérature. Dans le but d’éviter tout malentendu, nous proposons dans le paragraphe suivant, une vision simplifiée du cloud. Cette présentation est proche des clusters/grilles qui sont technologiquement identiques au cloud.
Notre vision. Sans entrer en contradiction avec la présentation précédente, nous considérons toute plateforme de cloud comme une plateforme a` deux niveaux (figure 2.2(b)) :
• Abstraction et mutualisation des ressources. Ce niveau correspond exactement a` l’IaaS dans la vision classique. Nous y retrouvons donc a` la fois les ressources et les applications permettant leur abstraction et mutualisation.
• Les applications des entreprises et celles utiles à l’exploitation du cloud. Il s’agit aussi bien des applications du SaaS, des applications développées à partir d’un PaaS, que de celles issues ni du PaaS ni du SaaS. Pour aller plus loin, nous considérons le PaaS comme une application s’exécutant sur l’IaaS. De ce fait, il a le mˆeme statut que les autres applications. L’un des défis du cloud est l’isolation de ces diﬀérentes applications.

Challenges

Le CC n’est pas une révolution technologique en soit mais constitue une orien-tation vers un mode de gestion des infrastructures informatiques des entreprises. Ce-pendant, l’idée d’héberger plusieurs applications d’utilisateurs diﬀérents pose quelques défis que doit surmonter le cloud. Il s’agit de l’isolation, l’administration, l’interop´-rabilité et la portabilité des applications entre plusieurs plateformes.

Isolation

La mutualisation de ressources dans le cloud (comme dans toutes les infrastruc-tures) implique la mise en place de divers mécanismes (sécurité, comptage de res-sources, conflit d’accès, etc). Le plus important de ces derniers est la gestion des conflits/interférences d’accès entres les utilisateurs. Une réponse idéale pour la mise en place de la mutualisation est l’isolation. Nous regroupons sous ce terme plusieurs types d’isolation à savoir : l’isolation des ressources, l’isolation d’espaces utilisateurs, l’isolation des performances et l’isolation des défaillances.
• L’isolation des ressources (ou encore partitionnement) garantit au client l’exclusivit´ d’accès à un ensemble de fractions (”morceaux”) de ressources du-rant toute sa présence dans le cloud (malgré la mutualisation). Le client a l’illusion d’ˆetre le propriétaire et considère l’ensemble comme des machines en-tières. Cette isolation permet d’éviter les situations de famine aux applications du client (situation dans laquelle une application attend indéfiniment une res-source détenue par une autre). De plus, elle permet au fournisseur du cloud d’identifier et de compter les utilisations de ressources pour chaque utilisateur. Ce décompte servira par la suite à la facturation.
• L’isolation d’espaces utilisateurs donne a` chaque client du cloud l’illusion d’ˆetre le seul utilisateur. Rien ne doit le laisser présager la présence d’autres utilisateurs ou applications. Illustrons cela à travers l’exemple d’un cloud four-nissant des environnements Linux. Dans cet environnement, chaque client peut accéder en mode super utilisateur (root sous Linux) aux machines lui appar-tenant. Cependant, l’exécution de la commande ps -aux (aﬃchage de la liste des processus) par exemple ne doit présenter que les processus démarrés par l’utilisateur en question.
• L’isolation des performances permet au cloud d’assurer le non monopole des ressources globales du cloud par un seul client. Prenons l’exemple des ressources réseaux pour illustrer cela. Une utilisation intensive de la bande passante sur le cloud par une application cliente peut aﬀecter l’ensemble du réseau et ainsi avoir un impact sur les autres utilisateurs.
• L’isolation des défaillances permet d’assurer la non violation des espaces utilisateurs dans le cloud. Il comprend également le défi de sécurit´. En tant que centre d’hébergement d’applications multi-utilisateurs, le cloud doit garan-tir l’intégrit´ de chaque espace utilisateur vis-à-vis des autres. Ainsi, aucune action malveillante réalisée par un client ne doit altérer ni le fonctionnement du cloud ni celui des applications appartenant à d’autres clients. Cet objectif est d’autant plus important que la plupart des utilisateurs du cloud sont non identifiables. Il s’agit des utilisateurs des services hébergés par les entreprises dans le cloud.
La prise en compte de ce défi a et eﬀectuée grˆace à l’introduction des techniques de virtualisation (section 2.2) dans l’implémentation du cloud.

Table des matières

1 Introduction
2 Le cloud
2.1 Le Cloud Computing
2.1.1 Généralités et Définition
2.1.2 Cloud vs Grilles
2.1.3 Principes
2.1.4 Bénéfices
2.1.5 Classification
2.1.5.1 Par raison de développement
2.1.5.2 Par niveau de service
2.1.6 Challenges
2.1.6.1 Isolation
2.1.6.2 Administration
2.1.6.3 Interopérabilité et Portabilité
2.2 Isolation par la virtualisation
2.2.1 Définition et Principes
2.2.2 Objectifs
2.2.3 Bénéfices pour les entreprises
2.2.4 Classification
2.2.5 Synthèse
3 Administration dans le Cloud
3.1 Administration niveau IaaS
3.1.1 Allocation de ressources
3.1.2 Déploiement
3.1.3 Configuration et Démarrage
3.1.4 Reconfiguration
3.1.5 Monitoring
3.2 Administration niveau Entreprise
3.2.1 Construction de VM et Déploiement
3.2.2 Allocation de ressources
3.2.3 Configuration et Démarrage
3.2.4 Reconfiguration
3.2.5 Monitoring
3.3 Synthèse : système d’administration autonome pour le cloud
4 Administration Autonome
4.1 Définition
4.2 Objectifs
4.3 Bénéfices pour les entreprises
4.4 Classification
4.5 Synthèse
5 TUNe
5.1 Historique
5.2 Principes
5.2.1 Architecture Description Language (ADL)
5.2.2 Wrapping Description Language (WDL)
5.2.3 Reconfiguration Description Language (RDL)
5.3 Choix d’implantation
5.4 Expérimentations et Problématiques
5.4.1 Applications cluster
5.4.2 Applications large échelle : cas de DIET
5.4.3 Applications virtualisées
5.4.4 Cloud
5.5 Synthèse et nouvelle orientation
6 Orientation générale
6.1 Caractéristiques
6.1.1 Uniforme
6.1.2 Adaptable
6.1.2.1 Adaptation des comportements
6.1.2.2 Extensibilité
6.1.3 Interopérable et Collaboratif
6.1.4 Synthèse
6.2 Approche générale et Modèle Architectural
6.2.1 Approche Générale
6.2.2 Modèle Architectural
6.2.3 Prise en compte des caractéristiques
6.3 Synthèse
7 Etat de l’art
7.1 SAA
7.1.1 Rainbow
7.1.2 Accord
7.1.3 Unity
7.1.4 Synthèse
7.2 SAA pour le cloud
7.2.1 OpenNebula
7.2.2 Eucalyptus
7.2.3 OpenStack
7.2.4 Microsoft Azure
7.2.5 Autres plateformes de cloud
7.3 Synthèse
8 Contributions : TUNeEngine
8.1 Modèle détaillé de TUNeEngine
8.1.1 Soumission de commandes et Collaboration
8.1.2 Construction du SR
8.1.3 Déploiement
8.1.4 Configuration, Démarrage
8.1.5 Réconfiguration
8.2 Le formalisme `a composants Fractal
8.3 Implantation de TUNeEngine
8.3.1 Le composant TUNeEngine
8.3.2 Soumission de commandes et Collaboration
8.3.3 Construction du SR
8.3.4 Déploiement
8.3.5 Exécution de programmes d’administration
8.4 Synthèse
9 Contributions : application au Cloud
9.1 Un IaaS simplifié : CloudEngine
9.1.1 Vision globale : CloudEngine-TUNeEngine, Application-TUNeEngine- CloudEngine
9.1.2 RepositoryController
9.1.3 VMController
9.1.4 VLANController
9.1.5 ResourceController
9.1.6 MonitoringController
9.1.7 Scheduler
9.2 Utilisation de CloudEngine
9.2.1 Construction et enregistrement de VM
9.2.2 Administration d’applications
9.3 Reconfiguration d’applications et de CloudEngine
9.3.1 Réparation de VM
9.3.2 Consolidation de VM et Scalabilité de serveurs
9.3.2.1 Exécution d’applications statique
9.3.2.2 Exécution d’applications variables
9.4 Synthèse
10 Expérimentations
10.1 Environnements d’expérimentation
10.1.1 L’IaaS
10.1.2 Les applications entreprises : RUBIS
10.1.3 Les métriques
10.2 évaluations
10.2.1 Réparation de VM
10.2.1.1 Réparation non collaborative
10.2.1.2 Réparation collaborative
10.2.2 Scalabilité et Consolidation
10.2.2.1 Scalabilité
10.2.2.2 Consolidation
10.2.2.3 Scalabilité et Consolidation simultanées
10.3 Synthèse
11 Conclusion et perspectives
11.1 Conclusion
11.2 Perspectives
11.2.1 Perspectives `a court terme
11.2.2 Perspectives `a long terme