La technologie Cloud Computing
PaaS
Plateforme en tant que service est un environnement de développement et de déploiement complet dans le cloud, avec les ressources nécessaires pour vous permettre de fournir n’importe quel service, de la simple application cloud aux applications d’entreprise sophistiquées [19]. Il qualifie les services de Cloud computing qui offrent un environnement à la demande pour développer, tester, fournir et gérer des applications logicielles [16]. Vous faites l’acquisition des ressources dont vous avez besoin auprès d’un fournisseur de services cloud, avec un paiement à l’utilisation, et vous y accédez via une connexion Internet sécurisée. PaaS est conçu pour permettre aux développeurs de créer rapidement des applications web ou mobiles sans avoir à se préoccuper de la configuration ou de la gestion de l’infrastructure de serveurs, de stockage, de réseau et de bases de données nécessaire au développement .
Exemple : Google Apps, Microsoft Azure. Tout comme IaaS, PaaS comprend l’infrastructure, à savoir les serveurs, le stockage et les composants réseau, mais aussi les intergiciels17 (Middleware), les outils de développement, les services d’aide à la décision (BI, Business Intelligence), les systèmes de gestion de bases de données, etc. Le PaaS est conçu pour prendre en charge l’intégralité du cycle de vie de l’application web : conception, test, déploiement, gestion et mise à jour. Le PaaS permet d’éviter les dépenses et problèmes liés à l’achat et à la gestion de licences logicielles, de l’infrastructure sous-jacente aux applications et du middleware ou des outils de développement et autres ressources. Vous gérez les services et les applications que vous développez, et le fournisseur de services cloud se charge en général du reste.
Serverless
Se chevauchant avec PaaS, l’informatique serverless se concentre sur la création de fonctionnalités applicatives sans perte de temps en lien avec la gestion permanente des serveurs et de l’infrastructure requis à cette fin. Le fournisseur de Cloud se charge de la configuration, de la planification de la capacité et de l’administration du serveur à votre place. Les architectures Serverless sont hautement scalables et basées sur des événements. Elles n’utilisent des ressources que quand une fonction ou un déclencheur spécifique s’activent. L’architecture serverless est un modèle dans lequel le fournisseur de services Cloud est responsable de l’exécution d’un morceau de code en allouant de manière dynamique les ressources. Et il ne facture que la quantité de ressources utilisées pour exécuter le code. Le code est généralement exécuté dans des conteneurs sans état pouvant être déclenchés par divers événements, notamment des requêtes http, des événements de base de données, des services de file d’attente, des alertes de surveillance, des téléchargements de fichiers, etc. le code envoyé au fournisseur de Cloud pour l’exécution est généralement sous la forme d’une fonction. Par conséquent, serverless est parfois appelé « «Functions as a Service » ou « FaaS ».
Les avantages
Le Cloud Computing peut permettre d’effectuer des économies, notamment grâce à la mutualisation des services sur un grand nombre de clients. Certains analystes indiquent que 20 à 25 % d’économies pourraient être réalisées par les gouvernements sur leur budget informatique s’ils migraient vers le Cloud Computing. Comme pour la virtualisation, l’informatique dans le nuage peut être aussi intéressante pour le client grâce à son évolutivité. En effet, le coût est fonction de la durée de l’utilisation du service rendu et ne nécessite aucun investissement préalable (homme ou machine). L’« élasticité » du nuage permet de fournir des services évolutifs et peut permettre de supporter des montées en charge. Inversement, le fournisseur a la maîtrise sur les investissements, est maître des tarifs et du catalogue des offres et peut se rémunérer d’autant plus facilement que les clients sont captifs. A titre d’exemple, une entreprise possédant une boutique en ligne pourra facilement mettre en oeuvre des serveurs supplémentaires pour faire face à un pic d’activité très limité dans le temps, tel que la période de Noël ou des soldes, puis les supprimer après coup. Cela lui reviendra certainement moins cher que si elle avait dû acheter et gérer toute l’année une infrastructure informatique capable d’absorber cette charge importante mais éphémère. L’abonnement à des services de Cloud Computing peut permettre à l’entreprise de ne plus avoir à acquérir des actifs informatiques comptabilisés dans le bilan sous forme de CAPEX18 et nécessitant une durée d’amortissement. Les dépenses informatiques peuvent être comptabilisées en tant que dépenses de fonctionnement. La maintenance, la sécurisation et les évolutions des services étant à la charge exclusive du prestataire, dont c’est généralement le coeur de métier, celles-ci ont tendance à être mieux réalisées et plus rapidement que si elles étaient sous la responsabilité du client (principalement lorsque celui-ci n’est pas une organisation à vocation informatique)
La topologie DCell
De la même manière que BCube, DCell est défini de manière récursive et utilise des serveurs et des mini-commutateurs pour le transfert de paquets. Le module principal de cette topologie est DCell0 qui, en tant que BCube0, est composé d’un commutateur connecté à n serveurs. Un DCell1 est construit en connectant n + 1 réseaux DCell0 et un DCell0 est connecté à toutes les autres cellules DCell0 par un lien d’un de ses serveurs à un serveur d’un autre DCellO. Un réseau DCell1 est illustré à la figure suivante. Notez que la communication à l’intérieur d’une cellule est effectuée localement à l’aide d’un commutateur, comme indiqué dans la communication entre le serveur 2 et le serveur 3 à partir de DCell00.
La communication entre les serveurs de cellules différentes est effectuée directement, par exemple entre le serveur 1 dans DCell02 et le serveur 2 dans DCell03, ou en utilisant une combinaison de serveurs et de commutateurs. Ce dernier est indiqué dans la communication entre le serveur 1 de DCell01 et le serveur 1 de DCell04. Notez que dans un DCell, à la différence du BCube, les commutateurs sont connectés uniquement aux serveurs de son même DCell et la connexion entre différents réseaux DCell se fait toujours à l’aide de serveurs. Pour construire un DCellk, il faut n + 1 réseaux DCellk − 1. Chaque serveur dans un DCellk a k + 1 liens. Sur chaque serveur, le premier lien (lien de niveau 0) est connecté au commutateur de son DCell0 et le deuxième lien connecte le serveur à un noeud de son DCell1, mais dans un autre DCell0. Généralement, la liaison de niveau i d’un serveur le connecte à un autre DCelli-1 situé dans le même DCelli. La procédure de construction d’une DCell est plus complexe que celle d’un BCube et est exécutée par un algorithme proposé par Guo et al. La capacité DCell en nombre de serveurs peut être évaluée de manière récursive, en utilisant les équations suivantes: gk = tk − 1 +1 et tk = gk × tk − 1, où gk est le nombre de réseaux DCellk − 1 dans un DCellk, k est le nombre de serveurs dans un DCellk. Un réseau DCell0 est un cas particulier dans lequel g0 = 1 e t0 = n [53].
|
Table des matières
Remerciement
Dédicace
Liste des figues
Liste des tableaux
Liste des abréviations
Introduction générale
Chapitre 1 Le Cloud Computing
1.Introduction
2.La naissance du Cloud et son évolution
3.La technologie Cloud Computing
3.1. Définition
3.2. Caractéristique du Cloud
4..Modèles de déploiement
4.1. Cloud publique
4.2. Cloud privé
4.3. Cloud hybride
4.4. Cloud communautaire
5.Les différents types de Cloud
5.1. IaaS
5.2. PaaS
5.3. SaaS
5.4. Serverless
5.5. DWaaS5.
5.6. DaaS
5.7. STaaS (Storage as a Service)
6.Les avantages
7.Exemple sur les domaines d’utilisations du Cloud
8.Le Cloud & La robotique
9.Les limites de Cloud
Conclusion
Chapitre 2 La consommation d’énergie & les topologies
1.Introduction
2.Les Data Centers
3.Définition de la consommation d’énergie
4.Comment calculer la consommation d’énergie
5.Raisons de la consommation élevée d’énergie des Data Center
6.La virtualisation
6.1. Techniques de virtualisation
6.2. Les avantages de la virtualisation
6.3. Les inconvénients de la virtualisation
7.La migration
Les avantages de la migration
8.Les topologies
8.1. Définition
8.2. Les types
9.Le SLA
Conclusion
Chapitre 3 Implémentation et Simulation
1.Introduction
2.Langage et environnement de développement
2.1. Le langage de programmation Java
2.2. L’environnement de développement
2.3. Le simulateur CloudSim
2.3.1. Définition
2.3.2. L’architecture du CloudSim
3.Réalisation de l’application
3.1. La partie Présentation
3.2. La partie Fonctionnement
3.3. Persistance
4.Résultats obtenues
5.Comparaison
Conclusion
Conclusion générale
Référence Bibliographie
Annexe
Télécharger le rapport complet