Paysage des infrastructures IaaS et Edge Computing 

Télécharger le fichier pdf d’un mémoire de fin d’études

Préhistoire du calcul utilitaire : les grilles de calcul

Le calcul utilitaire prend sa source au début des systèmes à temps de calcul partagé [15] qui apparaissent au début des années 60. En 1961, John McCarthy est le premier à envi-sager le calcul utilitaire, lors d’un discours à l’occasion du centenaire du MIT en 1961 :
If computers of the kind I have advocated become the computers of the fu-ture, then computing may someday be organized as a public utility just as the telephone system is a public utility… The computer utility could become the basis of a new and important industry. – John McCarthy, 1961 Quand le premier nœud ARPANET est mis en place en 1969, Leonard Kleinrock imagine que la mise en réseaux d’ordinateurs pourrait conduire à l’apparition d’une infor-matique utilitaire, où la consommation de ressources informatiques se ferait à la demande, de la même manière que des ressources telles que l’eau et l’électricité sont consommées. L’analogie va plus loin puisque de la même manière qu’il existe des réseaux de centrales électriques formant des grilles électriques, on verrait l’apparition de grilles de calcul com-posées de centres de production de ressources informatiques.
L’avènement de la micro-informatique au cours des années 80 permet la démocrati-sation du calcul informatique : le commun des mortels accède à une puissance de calcul jusque là réservée aux grandes organisations. Les micro-ordinateurs étant certes moins puissants que les superordinateurs, leur faible prix fera qu’ils se répandront à une très grande vitesse, et leur mise en réseaux ouvre la voie vers des infrastructures reposant sur des micro-ordinateurs dont le potentiel de puissance de calcul rattrape celui des superor-dinateurs. Le projet Condor est lancé en 1984 dans le but de fédérer des ressources de calcul éparpillées sur plusieurs micro-ordinateurs, permettant à ses utilisateurs d’exécuter des tâches à distance [16].
Au cours des années 90, les ordinateurs personnels (Personal Computer – PC) connaissent un immense succès et sont progressivement interconnectés via Internet, ce qui amène l’ap-parition du paradigme de “Desktop Grid” : celui-ci consiste en la distribution de calculs sur une fédération de micro-ordinateurs connectés à Internet, chaque ordinateur héber-geant un intergiciel (middleware) qui reçoit des tâches ; ces tâches représentent des cal-culs, et sont ensuite exécutées en exploitant la puissance de calcul inutilisée des ordina-teurs faisant partie de la fédération. Ce paradigme a connu un certain succès au cours des années 90 avec des projets comme SETI, BOINC, et a inspiré le récent système BITCOIN.

Avènement du Cloud Computing

Les années 90 voient l’essor du réseau mondial Internet ainsi que l’apparition des pre-miers sites web possédant une audience mondiale. Certains d’entre eux vont voir leurs bases d’utilisateurs croître à des niveaux nécessitant la mise en place d’infrastructures ca-pables de distribuer l’énorme charge de travail incidente sur un grand nombre de serveurs web, chargés de répondre aux requêtes des utilisateurs. Les premiers centres de données font leurs apparitions et vont regrouper des ordinateurs absorbant la charge de travail des gros sites web. Cette concentration d’ordinateurs permettra de mettre en place des économies d’échelle sur les équipements électriques, le refroidissement et le personnel. Plus ces centres de données sont gros, plus les économies d’échelle sont conséquentes. Certaines entreprises vont mettre en place leurs propres centres de données dédiés à l’hé-bergement de leurs services, tandis que d’autres entreprises feront le choix de sous-traiter l’hébergement de leurs services dans des centres de données appartenant à des entreprises spécialisées dans l’hébergement. Rapidement émergera le modèle de “Cloud Computing”, qui connaitra un essor ininterrompu depuis la fin du 20e siècle.

Résumé

L’informatique moderne nait entre les deux guerres mondiales, alors que la notion de cal-cul se développe et les premiers ordinateurs font leur apparition. En 1947, le transistor est inventé, ce qui engendrera une croissance continue de la puissance des ordinateurs. Jusque dans les années 1960s, le modèle des super ordinateurs centralisés domine. En 1969, l’agence ARPA finance le projet ARPANET qui vise à mettre en place un réseau d’ordi-nateurs à l’échelle des USA, ce réseau sera inauguré en 1971. La perspective de mettre en réseau les ordinateurs, comme on a mis en réseau les centrales électriques, laisse présa-ger que le calcul deviendrait une ressource utilitaire comme l’électricité ou le téléphone : celui-ci serait produit à distance et consommé à la demande. De cette vue de l’esprit dé-coulera le modèle des grilles de calcul. Ainsi l’avènement de la micro-informatique bon marché va permettre de connecter un nombre élevé d’ordinateurs grâce à des réseaux, et ces ordinateurs seront mis à la disposition des utilisateurs. Ce modèle connaitra un certain succès dans les années 1990. Au début du 21e siècle, le succès des grilles de calcul et du réseau Internet inspirera le modèle de Cloud Computing.

Qu’est-ce que le Cloud Computing ?

Dans le chapitre précédent nous avons vu comment progressivement l’informatique est passée de calculs effectués sur un seul super-ordinateurs à des traitements distribués sur des réseaux de machines, permettant d’accéder à toujours plus de puissance. Dans ce cha-pitre nous détaillons le modèle de Cloud Computing qui permet à des demandeurs en ressources informatiques d’y accéder à la demande. Ce modèle a rencontré un fort succès et est utilisé par de nombreux acteurs très divers, aboutissant à une multitude de visions de ce qu’est le Cloud Computing. Ainsi nous commençons ce chapitre par la difficulté à donner une définition qui satisfait toutes les visions précédemment évoquées. Ensuite, nous nous intéressons aux efforts de classification des incarnations de ce modèle, en nous attardant particulièrement sur la classification SPI et ses dérivées. Enfin, nous terminons sur la couche basse de la classification SPI en mettant notamment l’accent sur les as-pects architecturaux des principaux gestionnaires d’infrastructures de Cloud Computing, en cherchant à identifier ce qu’ils peuvent avoir en commun.

La difficulté de définir le Cloud Computing

L’essor des services à l’échelle du Web ainsi que les besoins pour traiter des données de plus en plus complexes ont conduit au succès du paradigme de Cloud Computing où des fournisseurs exposent une collection de ressources informatiques (calcul, stockage, capacité réseau, . . . ) au moyen d’Internet, permettant aux clients de les consommer à distance. Ces ressources informatiques sont facturées sur le mode du Payez au fur et à mesure ce que vous consommez (Pay As You Go), c’est-à-dire que l’utilisateur ne paie que les ressources qu’il utilise sur une durée donnée [17], soit le même mode de facturation des ressources utilitaires (électricité, eau, gaz, . . . ). Ce modèle privilégie des relations de sous-traitance où un acteur peut déléguer l’hébergement de ressources informatiques ou de services à un tiers, en s’accordant avec lui sur un niveau de service à respecter, moyennant des pénalités financières en cas de non-respect. Ainsi le client peut limiter les coûts d’acquisition et d’entretien matériel et logiciel de ses services, mais aussi d’externaliser une partie des risques liés à l’infrastructure aux fournisseurs. Rapidement, des services de Cloud Computing s’appuient sur d’autres services, ce qui aboutira à des architectures de services de plus en plus complexes. Netflix en est un exemple, car ses utilisateurs consomment des vidéos qui leur sont distribuées en tirant avantage de l’infrastructure d’Amazon. Bien qu’Amazon et Netflix soient deux acteurs du Cloud Computing, ils four-nissent des services de natures différentes.
Bien que le Cloud Computing s’appuie sur une vision proche de celle des grilles de calcul, ces deux modèles divergent sur un certain nombre de points. En premier, une grille de calcul mise sur l’agrégation de ressources issues de plusieurs organisations afin de pro-poser une infrastructure commune plus grande, tandis que le modèle de Cloud Computing fait souvent l’impasse sur cette notion de partage en privilégiant des infrastructures im-pliquant un seul fournisseur : ainsi l’infrastructure reste isolée des autres infrastructures appartenant à des fournisseurs tiers. Tandis que les acteurs impliqués dans les grilles de calculs ont fait un grand effort pour encourager la mise en place et l’adoption de standards pour favoriser l’interconnexion de plusieurs grilles de calcul afin de proposer l’accès à une quantité de ressources plus importante, les tentatives pour aboutir à une standardisation concertée des acteurs du Cloud Computing sont restées infructueuses, conduisant plutôt à l’adoption de normes considérées comme standard “de facto” telles que l’API de plate-forme Amazon.
Malgré ces quelques différences, le modèle des grilles de calcul et le modèle du Cloud Computing se rejoignent sur le fait qu’ils visent à faciliter la mise à disposition pour l’uti-lisateur de collections de ressources informatiques issues de l’agrégation d’ordinateurs hé-térogènes connectés en réseau. Ces similarités conduisent à une certaine confusion quand il s’agit de qualifier ce qui appartient à la catégorie des grilles de calcul et ce qui fait partie du domaine du Cloud Computing. De la même manière que les grilles de calcul, les infrastructures de Cloud Computing sont utilisées par des acteurs techniquement très variés de l’informatique (virtualisation, réseaux, stockage, . . . ) ou par des acteurs issus d’autres disciplines que l’informatique et appliquant les infrastructures à leurs disciplines (étude énergétique, économie, sociologie, . . . ).
Une étude [18] a mis en évidence que cette particularité expliquerait l’absence d’une définition claire et unanimement admise de ce qu’est le Cloud Computing par ses propres acteurs. Ce phénomène prend sa source dans le fait qu’il englobe un large spectre d’appli-cations, rendant difficile une définition en termes généraux permettant de toucher tout ce qui appartient au Cloud Computing. Un acteur du Cloud Computing aura naturellement tendance à fournir une définition colorée par sa propre sensibilité, expliquant la multitude de définitions relevées par les auteurs. Proposant de résoudre cette absence d’une définition communément acceptée du Cloud Computing, [18] a proposé de reprendre la multitude de définitions et d’en agréger les élé-ments qui faisaient consensus pour avoir une définition générale suffisamment large pour satisfaire toutes les sensibilités du Cloud Computing :
Clouds are a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically reconfigured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a payper-use model in which guarantees are offered by the In-frastructure Provider by means of customized SLAs – Définition fournie par les auteurs de [18]. Cette définition est intéressante, car elle met l’accent sur le concept de “contrat de garantie de la qualité de service” (Service Level Agreement – SLA), ce qui souligne l’im-portance de la sous-traitance dans le modèle de Cloud Computing. Ainsi, tout le modèle semble reposer sur le fait qu’un client va consommer les ressources d’un fournisseur, et ce même fournisseur garantira une qualité de prestation à la hauteur des moyens investis par le client. Il est courant pour un service logiciel hébergé dans le Cloud d’impliquer plusieurs niveaux de sous-traitance sur plusieurs niveaux de sous-traitance. Dropbox en est un exemple, car ses utilisateurs délèguent à Dropbox le stockage de leurs fichiers qui à son tour a délégué l’hébergement de son infrastructure de stockage à Amazon.
Face à l’abondance et à la variété des relations de sous-traitance dans le Cloud Com-puting, certains ont tenté d’établir une classification étudiant les relations de dépendance qui pouvaient exister entre les fournisseurs de services et leurs clients, en rapprochant les services ayant des caractéristiques proches. De plus, il est courant que les services à haut niveau d’abstraction sous-traitent une partie des fonctions à bas niveau d’abstraction à d’autres services. Ces éléments ont conduit à un besoin de classification fournissant des critères pour classer les services de Cloud Computing, et ainsi regrouper dans un même ensemble les services partageant des caractéristiques semblables. Une telle classification pourrait permettre une meilleure compréhension du paysage du Cloud Computing (ac-teurs, services, technologies, . . . ) et ainsi de permettre la discussion entre des acteurs de contextes différents, qu’ils soient académiques ou issus de l’industrie, et quelques soient leurs points d’intérêts (scientifique, technique, économique, . . . ).
La classification la plus connue est la classification SPI qui classe un service parmi trois couches (Software, Platform et Infrastructure) en fonction du degré d’abstraction qu’il introduit à l’utilisateur. Bien qu’il existe d’autres classifications dérivées telles que UCSB-IBM et la classification de Jackson [19], seule la classification SPI sera détaillée dans cette partie.

SPI : un modèle en couche pour le Cloud Computing

La classification SPI [20] propose de situer un service de Cloud Computing au sein de trois couches Infrastructure, Platform, Software, cet ordre correspondant à un degré d’abstraction croissant de l’infrastructure sous-jacente. Dans ce modèle, les services ap-partenant aux couches supérieures font abstraction des fonctions relevant des couches inférieures : cela correspond à une observation de la réalité où il est courant qu’un service s’appuie sur d’autres services appartenant à des couches plus basses dans la classification. La suite de cette partie décrit les différentes couches constitutives du modèle SPI, allant des couches d’abstraction les plus hautes vers les plus basses, permettant ainsi de mettre en évidence le rôle des couches proches de l’infrastructure.
• Software as a Service (SaaS)
La couche haute Software as a Service (SaaS) regroupe des services rendus accessibles aux utilisateurs finaux au moyen d’un client léger (application web, application mobile, client bureau, . . . ). Ces services sont hébergés à distance : La majeure partie de leur code source (en particulier la partie métier), est exécutée à distance sur les infrastructures des fournisseurs de services.
Les avantages d’un tel modèle de service sont nombreux, comme le fait que la com-plexité liée au déploiement d’un service ainsi que sa maintenance sont masquées à l’utili-sateur final. Les exigences en matière de matériel informatique sont aussi plus basses, car une partie de l’exécution du service est délocalisée sur l’infrastructure distante apparte-nant au fournisseur. L’utilisateur final bénéficie d’une garantie de qualité de service sans avoir à investir dans du matériel informatique spécialisé et performant, et en cas de pannes le contrat de garantie prévoit les indemnités que le fournisseur versera à l’utilisateur.
L’exécution de la partie métier du service se faisant sur l’infrastructure du fournisseur de service, il est possible de mettre à jour le code du service sans que l’utilisateur ne le voie, ce qui permet d’avoir un rythme de mises à jour du service plus important sans que cela soit préjudiciable pour l’expérience de l’utilisateur. Cependant, toutes les données des utilisateurs se trouvant sur l’infrastructure, en cas d’intrusion celles-ci se retrouvent exposées, de même qu’en cas de panne de l’infrastructure, il est fréquent que le service devienne totalement inaccessible pour les utilisateurs.
Les exemples connus de SaaS sont le service de messagerie Gmail (Google), le réseau social Facebook et l’outil de gestion de la relation client (CRM) Salesforces.
• Platform as a Service (PaaS)
La couche intermédiaire Platform as a Service regroupe des services qui ciblent les concepteurs de services logiciels. Les fournisseurs de PaaS fournissent des plates-formes logicielles aux concepteurs de service, qui sont livrées avec des interfaces de programma-tion dédiées (API) pouvant accueillir et exécuter des services de Cloud Computing. En utilisant les services de la couche PaaS, le travail des concepteurs est simplifié, car une grande partie de la complexité liée à la prise en main des aspects liés à l’infrastructure est masquée derrière l’API exposée par le fournisseur PaaS. De cette manière, le processus de développement d’un service logiciel est simplifié, car un concepteur qui utilise une plate-forme PaaS ne fait que fournir du code source au fournisseur PaaS, qui en retour s’occupe de le déployer sous la forme d’un service, et de le rendre accessible aux utilisateurs au moyen d’un client léger.
Bien que le modèle de service PaaS réduise la complexité lors du développement d’un service, le code source développé doit néanmoins répondre à des contraintes dictées par les choix technologiques du fournisseur PaaS, telles que le support d’un nombre limité de langages de programmation, l’obligation d’utiliser certaines bibliothèques ou certains serveurs de bases de données. Ces contraintes sont souvent nécessaires pour garantir au fournisseur de PaaS une intégration plus facile entre les services des utilisateurs et les technologies utilisées par son infrastructure, rendant plus aisé l’hébergement de ceux-ci.
Enfin, bien que les éléments techniques composant les couches inférieures (notam-ment la partie utilisant une plate-forme PaaS, cette dernière est capable de faire des ajustements concer-nant les quantités de ressources qui lui sont allouées, afin de rester adaptées à la charge de travail du service qu’elle héberge. De même, il est courant que les fournisseurs PaaS proposent des interfaces logicielles (APIs) à leurs utilisateurs, permettant à ces derniers de modifier les paramètres associés à l’environnement d’exécution, notamment la puissance de calcul allouée à un service.
Parmi les principaux fournisseurs de ressources PaaS, figurent des acteurs comme Amazon (Amazon Web Service), Google (App Engine), Microsoft (Azure) et Salesforce (Heroku).
• Infrastructure as a Service (IaaS)
La couche basse Infrastructure as a Service (IaaS) regroupe les services qui four-nissent des ressources de calcul sous la forme de machines virtuelles (VMs) aux utilisa-teurs. Ces machines virtuelles sont hébergées sur des serveurs physiques localisés dans des centres de données (datacenters) appartenant au fournisseur IaaS. L’utilisation des techniques de virtualisation procure notamment l’avantage de pouvoir consolider le degré d’utilisation des serveurs physiques en hébergeant plusieurs VMs sur un même serveur physique, ce qui permet d’améliorer le taux de rentabilité d’une infrastructure. De plus, les techniques de virtualisation permettent d’avoir des propriétés d’isolation empêchant les interférences entre des machines virtuelles appartenant à différents utilisateurs.
Lors de la fourniture d’une machine virtuelle, l’utilisateur a les mêmes possibilités d’utilisation que s’il avait affaire à une machine physique. Ainsi, il peut y déployer un système d’exploitation (OS) parmi ceux proposés par le fournisseur IaaS (certains four-nisseurs laissent la possibilité d’installer un OS personnalisé), modifier les fichiers de configuration du serveur et y installer ses logiciels et les bibliothèques de son choix.
Il est courant que le fournisseur IaaS propose, en complément de l’approvisionnement en machines virtuelles, des services additionnels tels que la fourniture et l’hébergement d’images pour machines virtuelles, des ressources de stockage supplémentaires, des fonc-tions liées à la communication inter-VMs comme les réseaux virtuels, ou des garanties supplémentaires concernant la qualité de service (QoS) fournie pour l’hébergement de VMs.
Enfin, les infrastructures IaaS ont été popularisées sous le terme de “Cloud” (nuage), et les déploiements IaaS sont fréquemment classifiés en fonction de leurs degrés de sou-veraineté et de la nature des restrictions d’accès aux utilisateurs extérieurs au fournisseur IaaS :
• Cloud public (Public Cloud) : Un Cloud public est une infrastructure IaaS per-mettant l’accès à tout utilisateur, qu’il appartienne ou non à l’organisation proprié-taire de l’infrastructure. Les usages de l’infrastructure sont facturés par le proprié-taire. Ce type de déploiement correspond aux fournisseurs IaaS commerciaux tels qu’Amazon avec son service EC2 (Elastic Compute) ou au service de VPS (Virtual Private Server) proposé par OVH.
• Cloud privé (Private Cloud) : Un Cloud privé est une infrastructure IaaS apparte-nant à une organisation et dont l’accès est limité aux membres de cette organisation.
Ce type de déploiements est généralement propre à une entreprise. Dans le cas de certains Private Cloud où les ressources venaient à manquer pour satisfaire les be-soins des utilisateurs, il y a la possibilité de déléguer le surplus de demandes à des infrastructures tierces publiques : on parle alors d’Hybrid Cloud.
• Cloud communautaire (Community Cloud) : Un Cloud communautaire est une infrastructure IaaS ouverte à une communauté d’utilisateurs : à partir du moment où un utilisateur est membre de l’organisation en charge de l’infrastructure, celui-ci peut exploiter les ressources de l’infrastructure communautaire. Ce modèle reprend de nombreux aspects du modèle de grille de calcul communautaire, et on le re-trouve fréquemment dans le cadre des infrastructures IaaS dédiées à une utilisation scientifique. Ce modèle est à mi-chemin entre les Cloud privés et les Cloud publics.

IaaS : La couche basse du Cloud Computing en détail

La couche Infrastructure as a Service du modèle de Cloud Computing a connu un fort succès au cours des années 2000s : de nombreux acteurs ont développé leur propre solu-tion et des projets de logiciels libres ont émergé permettant à des institutions de mettre en place leurs propres plates-formes IaaS. Chacune de ces solutions reposent sur les prin-cipes de programmation, qui étaient à la mode au moment où elle a émergé, comme les architectures à bases de services web (Eucalyptus), l’utilisation de communications à base d’échanges de messages sur un bus (OpenStack, CloudStack, OpenNebula) ou l’utilisa-tion d’une structure hiérarchique pour organiser ses nœuds de calcul (Eucalyptus). Toutes les solutions IaaS s’accordent néanmoins sur l’usage de la virtualisation comme moyen de fournir en toute flexibilité des ressources de calculs à leurs utilisateurs.

La virtualisation : la pierre angulaire du modèle IaaS

La virtualisation [21] est une technique permettant de simuler le comportement d’une ressource physique au moyen d’un logiciel. Les machines virtuelles, apparues dans les années 1960s, sont l’application des techniques de virtualisation aux ordinateurs. Une ma-chine virtuelle est un programme qui simule un ordinateur complet qui hébergera un sys-tème d’exploitation classique et bénéficiera des mêmes fonctionnalités (CPU, stockage, réseau, . . . ) qu’un ordinateur physique. Une machine virtuelle n’étant qu’un programme informatique, celle-ci est hébergée sur une machine physique (sur certains matériels, il est possible de faire fonctionner une machine virtuelle dans une autre machine virtuelle).
Un des principaux avantages des machines virtuelles est qu’elles permettent une abs-traction du matériel chargé de l’hébergement, ce qui ouvre la voie à l’exécution de services informatiques sur du matériel hétérogène. De plus, elles permettent d’assurer l’isolation entre des processus exécutés au sein de plusieurs machines virtuelles étanches, ce qui est une base pour établir des propriétés de sécurité entre services appartenant à différents clients d’un même fournisseur d’infrastructure. Enfin, le fait que plusieurs machines vir-tuelles puissent être exécutées au sein d’une même machine physique ouvre la voie aux mécanismes de consolidation [22] permettant d’augmenter le taux d’utilisation des ma-chines physiques.
Bien que les machines virtuelles soient la technique de virtualisation la plus popu-laire au sein des systèmes IaaS, elles nécessitent l’installation d’un système d’exploita-tion complet par machine virtuelle. Des techniques alternatives, à l’empreinte sur l’hôte plus légère, ont connu un certain essor, comme les conteneurs (Containers) dont l’usage s’est popularisé. Les conteneurs tirent parti des mécanismes d’isolation entre les proces-sus (via chroot) des systèmes d’exploitation modernes pour donner l’impression que des services sont exécutés sur des systèmes d’exploitation différents, alors qu’ils sont en fait exécutés dans des environnements différents, mais sur le même système appartenant à l’hôte. Grâce au succès du projet Docker [23], les conteneurs ont considérablement gagné en visibilité, et commencent à être pris en compte par les gestionnaires IaaS alors qu’ils étaient jusqu’alors utilisés par les fournisseurs PaaS.

Vers une définition d’une architecture commune pour les sys-tèmes IaaS ?

De nombreux projets de gestionnaires IaaS ont émergé au début du 21e siècle. Bien que ces projets se soient reposés sur les technologies qui étaient en vogue au moment de leur démarrage (SOA, RPC, services web, . . . ), ceux-ci ont beaucoup de points communs ar-chitecturaux. Un premier élément expliquant ces similarités architecturales est que ces gestionnaires remplissent des fonctions qui sont très proches : exploiter une infrastruc-ture fournissant de la puissance de calcul sous la forme de machines virtuelles. Le second élément expliquant ces similarités architecturales est que la plate-forme Amazon EC2 dominant le marché des infrastructures de Cloud Computing, ses APIs se sont imposées comme des standards de facto, inspirant ainsi ses concurrents. De nombreux gestionnaires IaaS utilisent pour la plupart des terminologies proches (instances, compute nodes, avai-lability zones) de celles d’Amazon EC2, principalement pour des raisons de compatibilité (pour éviter de verrouiller l’utilisateur sur Amazon EC2 et de changer de plate-forme) et ne pas réinventer la roue. Ainsi, leurs architectures logicielles ont été composées autour de la gestion des mêmes ressources que celles fournies par Amazon (machines virtuelles, réseaux, stockage, . . . ), en gardant à l’esprit les fonctions assurées par la plate-forme Amazon EC2.
Sur la même lancée que la plate-forme Amazon EC2, les projets communautaires vi-sant à fournir des gestionnaires d’IaaS permettant de déployer des infrastructures privées de Cloud Computing (Clouds privés) ont eux aussi connu un succès important. Leur étof-fement en ce qui concerne leurs fonctions et leur rapide adoption permettent d’envisager un futur où les centres de données seront semblables à des infrastructures IaaS privées [24], et où chaque aspect d’un centre de données sera géré par le gestionnaire IaaS. Les systèmes IaaS étant appelés à devenir de plus en plus complexes, des auteurs ont proposé l’idée d’avoir une architecture de référence [25] pour les systèmes IaaS où les fonctions devant être assurées par un gestionnaire d’infrastructure seraient clairement identifiées, et associées chacune à un composant dédié comme présenté dans la figure 2.1.

Table des matières

I Introduction 
II Contexte de la thèse 
1 Avènement de l’informatique utilitaire
1.1 Début de l’informatique moderne
1.2 Premières mises en réseau d’ordinateurs
1.3 Préhistoire du calcul utilitaire : les grilles de calcul
1.4 Avènement du Cloud Computing
1.5 Résumé
2 Qu’est-ce que le Cloud Computing ?
2.1 La difficulté de définir le Cloud Computing
2.2 SPI : un modèle en couche pour le Cloud Computing
2.3 IaaS : La couche basse du Cloud Computing en détail
2.3.1 La virtualisation : la pierre angulaire du modèle IaaS
2.3.2 Vers une définition d’une architecture commune pour les systèmes IaaS ?
2.3.3 Revue des principaux systèmes IaaS
2.4 Résumé
3 Paysage des infrastructures IaaS et Edge Computing
3.1 Splendeur et décadence des mégas centres de données
3.2 Fédérations de nuages
3.2.1 Bursting (Cloud hybride)
3.2.2 Broker
3.2.3 Aggregated
3.2.4 Multitier
3.3 Du modèle d’Edge Computing au Fog Computing
3.4 Comparaison des trois modèles de Cloud Computing
3.5 Résumé
4 Infrastructures IaaS massivement distribuées avec OpenStack
4.1 Passage à l’échelle d’OpenStack
4.2 Distribution à plat
6 Table des matières
4.3 Distributions hiérarchiques
4.3.1 Cells
4.3.2 Cascading OpenStack / Tricircle
4.4 Résumé
III Contributions de la thèse 
5 Discovery : vers une infrastructure IaaS massivement distribuée
5.1 Un réseau de nanos centres de données dans les points de présence
5.2 Le LUC-OS : un gestionnaire IaaS massivement distribué
5.3 Adapter OpenStack pour utiliser les bases de données non relationnelles
5.4 Résumé
6 Support des bases clé/valeur dans Nova
6.1 Accès aux bases de données dans Nova
6.2 Vers un support des bases de données clé/valeur dans Nova
6.3 Rome : un ORM pour bases clé/valeur
6.3.1 Interfaces logicielles inspirées par SQLAlchemy
6.3.2 Représentation des données et marshalling
6.3.3 Support des opérations de bases : création, sélection, modification, suppression
6.3.4 Support des jointures et des relations
6.3.5 Les sessions : implémentation à base de verrous distribués
6.3.6 Implémentation au-dessus de REDIS
6.3.7 Optimisations
6.4 Validation sur Grid’5000
6.4.1 Impact de l’utilisation de REDIS par rapport à MySQL
6.4.2 Scénarios multisites
6.4.3 Compatibilité avec les fonctions avancées de Nova
6.4.4 Premiers essais autour de la localité dans Nova
6.5 Résumé
7 Prise en compte de la localité réseau : le cas de DVMS
7.1 Contexte
7.1.1 Ordonnancement de machines virtuelles pair-à-pair
7.1.2 DVMS : ordonnancement dynamique de machines virtuelles
7.1.3 Overlay network et prise en compte de la localité
7.2 Contributions
7.2.1 Réseau d’overlay prenant en compte la localité
7.2.2 PeerActor : Une brique de base pour abstraire les réseaux d’overlay
7.3 Validation expérimentale sur Grid’5000
7.4 Résumé
8 Contributions à VMPlaceS : un simulateur pour algorithmes de placement de machines virtuelles
8.1 VMPlaceS, un simulateur s’appuyant sur SimGrid
8.2 Fonctionnement de VMPlaceS
8.3 Validation expérimentale de VMPlaceS
8.3.1 Précision des simulations
8.3.2 Comparaison de trois algorithmes de placement
8.4 Travaux connexes
8.5 Résumé
IV Conclusions et perspectives 
9 Rappel des contributions
10 Perspectives
10.1 Perspectives à court terme
10.1.1 Rome
10.1.2 VMPlaceS et DVMS
10.2 Perspectives à long terme
V References

Télécharger le rapport complet