Modèle en couches du cloud computing

Le cloud computing est défini par un modèle en couches comportant trois niveaux : le SaaS (Software as a Service), le PaaS (Platform as a Service) et l’IaaS (Infrastructure as a Service). La figure 1.2 décrit succinctement ce modèle en couches. Le niveau SaaS correspond à une application (web souvent) utilisée par un client final à travers une interface graphique. La responsabilité du client se limite à la gestion des données entrées dans son application, tandis que le fournisseur de SaaS gère tout le reste (infrastructure, mises à jour de l’application, etc.). Dropbox (service de stockage et partage de fichiers en ligne), Microsoft Office 365 (suite bureautique en ligne), SAP (connue pour son progiciel de gestion intégré), Google Apps (incluant le service de messagerie Gmail et d’autres outils) sont des exemples de SaaS. Le niveau PaaS définit des interfaces de programmation (APIs) et offre un environnement de développement et de déploiement d’applications, permettant aux développeurs de s’affranchir des considérations de bas niveau.

Le client est donc responsable de l’installation et de la gestion des applications qu’il déploie, tandis que le fournisseur de PaaS prend en charge la gestion de l’infrastructure, l’automatisation des ressources à allouer, les systèmes d’exploitation virtualisés ainsi que des programmes permettant la prise en charge du PaaS. Google App Engine (supportant le langage Python et Java) et Microsoft Azure (supportant certains langages de la famille .NET) sont des exemples de PaaS. Enfin, à la base de ce modèle en couche, se trouve le niveau IaaS, qui offre généralement la possibilité de louer des machines virtuelles, que le client peut ajuster à ses besoins. Ce dernier est alors responsable de l’installation des systèmes d’exploitation et des applications, tandis que le fournisseur d’IaaS s’assure de la gestion des machines virtuelles, ainsi que du matériel sous-jacent. Amazon EC2, RackSpace Cloud et GoGrid sont des exemples de fournisseurs d’IaaS.

Avantages et inconvénients

D’après Sosinsky (2011), les avantages du cloud computing sont nombreux. Tout d’abord, la présence d’un service à la demande permet aux clients d’être autonomes et d’activer des machines virtuelles sans passer par un tiers. Ces derniers bénéficient également d’une élasticité qui, dans le cas des offres d’IaaS, par exemple, leur permet d’adapter la quantité des ressources allouées à leurs besoins. L’usage de chaque type de ressource (processeur, mémoire, espace disque, etc.) est d’ailleurs automatiquement mesuré séparément par le fournisseur de cloud, ce qui permet de facturer la consommation au juste prix. Comme les infrastructures sont maintenues par des fournisseurs spécialisés qui améliorent continuellement leur efficacité et offrent leurs services à un nombre croissant de clients, les prix sont de plus en plus compétitifs. Parallèlement, les clients peuvent externaliser partiellement leur service informatique pour en assouplir la gestion. Ils s’affranchissent également d’une importante part des coûts liés à la gouvernance des technologies de l’information, en raison de l’absence d’infrastructure et d’employés pour les gérer.

Les offres de cloud computing sont toujours accompagnées d’une qualité de service définie par un SLA. Ces clauses sont plus facilement garanties par les fournisseurs grâce à leur expérience et leur gestion avancée de la haute disponibilité, à travers les techniques de basculement (failover) en cas de panne et au balancement de charge (load balancing). Dans le cas du SaaS, les clients bénéficient automatiquement des dernières mises à jour de leurs logiciels. De la même manière pour le PaaS, les environnements d’hébergement des applications sont automatiquement mis à jour. Néanmoins, le cloud comporte aussi des inconvénients. De nombreuses entreprises ont envisagé la migration de leurs applications vers une infrastructure infonuagique, mais cette étape de transition est souvent périlleuse. Dans le cas du SaaS, les applications sont certes conçues pour être personnalisées mais cela n’atteint pas le degré de personnalisation des logiciels développés sur mesure pour les besoins spécifiques d’une entreprise. Par exemple, dans le cas d’un progiciel de gestion intégré (ou ERP en anglais) offert en tant que SaaS, si celui-ci n’inclut pas une fonctionnalité requise pour une entreprise, seul le fournisseur de SaaS peut accepter de l’intégrer, s’il en a la possibilité. Cela est d’autant plus difficile avec des logiciels propriétaires lorsqu’ils ne sont pas conçus de façon modulaire. Toutefois, comme le souligne Buyya et al. (2011), le défaut majeur du cloud est incontestablement la sécurité des informations hébergées. Certes, les clients ont un contrat qui définit des règles de confidentialité avec les fournisseurs, mais cela n’est pas suffisant. C’est d’ailleurs une des raisons qui a poussé la création de cloud privés. Ce problème est d’autant plus vrai lorsque les informations sont réparties sur plusieurs centres de traitement de données (datacenters) localisés dans des pays différents. Chaque gouvernement a des lois différentes vis-à-vis du respect de la confidentialité et cela peut être problématique pour les entreprises possédant des données privées.

Les différentes catégories Depuis 1970, avec la naissance des jeux vidéo sur les bornes d’arcade, puis leur apparition sur consoles (de salon ou portables) sans oublier leur distribution sur ordinateurs, les catégories de jeux vidéo se sont énormément diversifiées aussi bien grâce à la créativité des concepteurs de jeux vidéo qu’aux progrès techniques (puissance des cartes graphiques, processeurs, contrôleurs, Internet haut-débit, etc.). Mais comment catégorise-t-on les jeux vidéo? La classification des jeux vidéo est faite selon plusieurs critères et fait essentiellement appel au bon sens. Un jeu vidéo peut en fait appartenir à une ou plusieurs catégories simultanément, et il n’est pas rare de trouver de nombreux jeux hybrides. On distingue toutefois plusieurs modes de classification que l’on peut combiner. En voici une liste non exhaustive :

• selon le thème, les émotions, le type d’action et les objectifs que le jeu cherche à susciter chez le joueur : jeux d’aventure, de stratégie, de course automobile, d’épouvante/horreur, de rôle (RPG ou Role Playing Game), de tir à la première personne (FPS ou First Person Shooter), de réflexion (énigmes, puzzles, etc.), jeux éducatifs, jeux sérieux, simulateurs professionnels (pour l’armée), etc;

• selon les contrôleurs utilisés : plutôt que d’utiliser une souris, un clavier ou une manette, un jeu peut faire appel à des contrôleurs plus spécifiques qui améliorent l’ergonomie et l’expérience du joueur, comme les simulateurs de vols professionnels. Il en est de même pour la réalité augmentée (usage de caméras, capteurs), le jeu sur terrain réel avec téléphone intelligent doté d’un GPS, etc. De nos jours, les contrôleurs évolués se sont considérablement démocratisés. C’est le cas par exemple de ceux dont le but est de susciter le mouvement physique chez le joueur, comme la Wiimote de Nintendo utilisant accéléromètres et capteurs gyroscopiques pour la retranscription de mouvements, le Wiifit pour faire du sport chez soi, ou encore le Kinect de Microsoft pour la détection et la reconnaissance de mouvement et d’image avec caméra. Cela permet de créer une interaction plus intéressante et novatrice avec le monde virtuel;

• nombre de joueurs dans une partie : En général, la plupart des jeux multijoueurs se jouent entre 2 et 64 joueurs, tandis que les MMOGs (Massively Multiplayer Online Games) peuvent héberger plusieurs milliers de personnes simultanément. On parle de MMORPG pour désigner un RPG (Role Playing Game) massivement multi-joueurs et MMOFPS pour désigner un jeu de tir à la première personne massivement multi-joueurs.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
CHAPITRE 1 REVUE DE LITTERATURE
1.1 Présentation du cloud computing
1.1.1 Définition
1.1.2 Modèle en couches du cloud computing
1.1.3 Différents types de cloud computing
1.1.4 Avantages et inconvénients
1.2 Introduction à la virtualisation
1.2.1 Définition
1.2.2 Techniques de virtualisation de machines
1.2.3 Avantages
1.2.4 Inconvénients
1.3 Introduction technique aux jeux vidéo
1.3.1 Les différentes catégories
1.3.2 Principe de fonctionnement
1.3.2.1 Une organisation modulaire
1.3.2.2 La boucle principale
1.3.3 Le moteur de rendu
1.3.4 Le moteur physique
1.3.5 Jeux en ligne multi-joueurs
1.3.5.1 Architecture
1.3.5.2 Problèmes associés à la latence
1.4 Présentation du cloud gaming
1.4.1 Principe
1.4.2 Avantages et inconvénients
1.4.3 Travaux antérieurs liés au cloud gaming
1.5 Gestion dynamique de ressources en environnement infonuagique
1.5.1 Présentation du problème du bin packing
1.5.1.1 Définition
1.5.1.2 Heuristiques
1.5.1.3 Lien avec la consolidation
1.5.2 Travaux antérieurs sur les approches orientées vers le dimensionnement dynamique
1.6 Conclusion du chapitre
CHAPITRE 2 ARCHITECTURE PROPOSÉE
2.1 Objectifs
2.2 Présentation des entités et des phases
2.2.1 Vue générale
2.2.2 Description des phases
2.2.2.1 Phase de publication des substrates
2.2.2.2 Phase de découverte des substrates
2.2.2.3 Phase de négociation d’une composition
2.2.2.4 Phase d’activation d’une composition
2.2.2.5 Phase de service d’une composition
2.3 Modèle d’information
2.3.1 Diagramme Entité-Association
2.3.2 Exemple de démonstration
2.4 Conclusion du chapitre
CHAPITRE 3 PROTOTYPE TEMPS RÉEL
3.1 Objectifs
3.2 Définition du principe d’un benchmark
3.3 Principe de fonctionnement
3.3.1 Workflow de l’application
3.3.2 Architecture du prototype monolithique (MOBB)
3.3.3 Architecture du prototype orienté substrates (SOBB)
3.4 Scénarios de tests de performances
3.4.1 Tests sans virtualisation
3.4.1.1 Protocole expérimental
3.4.1.2 Résultats de MOBB et SOBB en conditions normales
3.4.1.3 Influence de la latence du réseau
3.4.1.4 Influence de la quantité de modules
3.4.2 Tests avec virtualisation
3.4.2.1 Protocole expérimental
3.4.2.2 Résultats de MOBB
3.4.2.3 Résultats de SOBB
3.5 Conclusion du chapitre
CHAPITRE 4 ALGORITHME DE DIMENSIONNEMENT DYNAMIQUE DE RESSOURCES PROPOSE
4.1 Objectifs et contributions
4.2 Hypothèses de l’algorithme
4.3 Présentation de l’algorithme
4.3.1 Pseudo-code sélectif
4.3.1.1 Méthodes de la classe ScalingAlgorithm
4.3.1.2 Méthodes de la classe Consolidator
4.3.1.3 Méthodes de la classe PM
4.3.1.4 Méthodes de la classe Application
4.3.2 Documentation sélective
4.3.2.1 Classe Application
4.3.2.2 Classe Process
4.3.2.3 Classe ScaleEntry
4.3.2.4 Classe Zone
4.3.2.5 Classe PM
4.3.2.6 Classe VM
4.3.2.7 Classe ScalingAlgorithm
4.4 Conclusion du chapitre
CHAPITRE 5 ANALYSE DES RESULTATS EN ENVIRONNEMENT SIMULE
5.1 Présentation de l’environnement de simulation
5.2 Scénarios de tests de performances
5.2.1 Protocole expérimental
5.2.2 Scénario de base
5.2.2.1 Résultats détaillés
5.2.2.2 Synthèse de 100 simulations
5.2.3 Influence du nombre d’applications
5.2.4 Influence de la quantité initiale de ressources allouées
5.2.5 Influence de la taille de la fenêtre de la moyenne glissante
5.2.6 Efficacité de la consolidation
5.2.6.1 Scénario de base sans consolidation
5.2.6.2 Scénario de base avec consolidation
5.2.6.3 Scénario de base sans consolidation, avec allocation initiale de type round robin
5.2.6.4 Scénario de base avec consolidation, avec allocation initiale de type round robin
5.3 Conclusion du chapitre
CONCLUSION
ANNEXE I Vue schématique des modules d’un jeu vidéo
ANNEXE II Exemples de workflows de boucles principales
ANNEXE III Principe du three way handshake
BIBLIOGRAPHIE