Soutenance mémoire
LES ARCHITECTURES ET TECHNOLOGIES A L’ORIGINE DU CLOUD COMPUTING
Le Cloud Computing est la cinquième génération de l’architecture informatique, et comme chaque génération, celle-ci ne déroge pas la règle puisqu’elle veut révolutionner l’IT (Information Technology) d’entreprise dans l’intégralité du modèle. C’est une vaste ambition mais impossible sans l’existence des quatre autres générations antérieures.
En effet, la première génération voyait le jour en 1970, baptisait « MainFrame ». Peu après, l’ère du système distribué a commencé. L’architecture Client/Serveur apparait en 1980. L’augmentation du nombre d’utilisateurs et de la quantité d’informations sur internet accélérait la standardisation de l’architecture Web en 1990. Ce dernier basculait vers le domaine commercial et entrainait la naissance de l’architecture orientée service ou SOA (Service Oriented Architecture) en 2000. A part, les architectures informatiques, la technologie de virtualisation et le système Grid sont aussi des piliers du Cloud Computing. Tout au long de ce chapitre, nous allons détailler ces architectures et technologies à l’origine du Cloud Computing.
Architecture Client/Serveur (C/S)
On parle de C/S quand il s’agit d’un système constitué de plusieurs ordinateurs distants reliés par un réseau, et voulant s’inter-échanger des données, selon une certaine hiérarchie, en parlant un même langage communément appelé protocole. Dans cette soi-disant « hiérarchie », celui qui effectue la requête est appelé le client, tandis que celui qui retourne une réponse à cette requête est appelé le serveur [2].
Interface utilisateur
Les clients accèdent à l’ensemble du système grâce à l’interface utilisateur. Toute application d’entreprise intégrant un environnement client-serveur doit être munie d’une interface utilisateur, techniquement appelée Graphical User Interface (GUI). Elle dispose des éléments d’affichage permettant de montrer les réponses aux requêtes émises par l’utilisateur.
Applications
Ce module de l’architecture renferme l’ensemble de tous les traitements effectués par le système. Cela englobe l’analyse, le traitement et l’exécution des requêtes utilisateur. La répartition des tâches entre le client et le serveur concernant le traitement diffère d’un type d’architecture C/S à l’autre. On peut rencontrer diverses possibilités:
➤ L’architecture un-tiers
➤ L’architecture deux-tiers
➤ L’architecture trois-tiers
Les données
Cette dernière partie de l’architecture a pour rôle de stocker les données de manière structurée et de les fournir à tout ce qui en demande. Les logiques de données, utilisées à la lecture, la création, la suppression, la mise à jour des données (CRUD, Create Read Update Delete), sont ses interfaces à tout système extérieur. En outre, cette opération, tout à fait indépendante du traitement, peut être gérée par un Système de Gestion de Base de Données (SGBD) comme Oracle, MySQL, SQL Server, ou autres.
Les middlewares
Les middlewares sont des entités intermédiaires qui assurent la communication entre les différentes entités de l’architecture, c’est-à-dire l’interface utilisateur-application et applicationdonnées. Cette communication est, en fait, assurée grâce à un protocole commun entre les deux entités. De surcroît, le middleware assure aussi la présentation de ces données dans les formats appropriés à chaque entité pour permettre un dialogue efficace entre eux.
Architecture un-tiers
Dans une architecture C/S un-tiers, la partie dédiée à l’interface utilisateur n’est présente que chez la machine cliente. De ce fait, tout le reste, (c’est-à-dire les applications, les données et même la logique de présentation) est centralisé dans le serveur. Le client, dépourvu de toute opération de traitement, est donc appelé client passif. C’est le cas qu’on rencontre dans les MainFrames qui sont des gros ordinateurs dotés d’une performance assez élevée et qui effectuent le stockage et le traitement des données à eux seuls.
Architecture deux-tiers
C’est une architecture C/S de première génération dans laquelle on trouve la partie stockage de données centralisée sur un serveur. Le serveur n’est donc constitué que d’un serveur de données, tandis que le client se charge non seulement des opérations de traitement mais également de la présentation des données. Dès lors, le client est appelé client lourd, et les seules communications entre lui et le serveur consistent en l’envoi direct des requêtes de données au SGBD et l’acquisition des données retournées.
Architecture trois-tiers
Dans ce type d’architecture, c’est la partie application qui est décomposée en deux subdivisions, telle que la plus grande est effectuée au niveau du serveur, notamment dans un serveur d’applications. Tous les logiques métiers y sont déployés, et c’est au serveur d’applications d’effectuer les requêtes et l’acquisition de données depuis le SGBD (ou autre système de stockage) du serveur de données. Seule une petite partie du traitement est effectuée au niveau du client. Comme middleware, on rencontre le RPC (Remote Procedure Call) dans l’architecture trois-tiers. Ce dernier assure la communication entre le client, le serveur et les éventuels intermédiaires. Contrairement à l’architecture C/S de données développée précédemment, cette architecture présente l’avantage d’être plus aisée à mettre à jour, car le logique métier centralisé au niveau du serveur peut être modifié sans aucune intervention nécessaire au niveau des clients.
Architecture n-tiers
L’architecture n-tiers ou multi-tiers est orientée vers la distribution d’application entre de multiples services. D’une manière explicite, une application est exécutée par plusieurs composants logiciels différents. Néanmoins, elle n’implique pas une mise en œuvre de plusieurs niveaux intermédiaires, mais une répartition des applications tout en gardant les trois niveaux de l’architecture distribuée.
La distribution d’application est aperçue au niveau des serveurs intermédiaires, c’est-à-dire, une application (ou un service) se trouvant dans un serveur peut solliciter une ou plusieurs autres sur un ou plusieurs serveurs différents. Ces derniers peuvent en faire de même à leur tour, et ainsi de suite.
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE 1 LES ARCHITECTURES ET TECHNOLOGIES A L’ORIGINE DU CLOUD COMPUTING
1.1 Introduction
1.2 Architecture Client/Serveur (C/S)
1.2.1 Modèle général
1.2.1.1 Interface utilisateur
1.2.1.2 Applications
1.2.1.3 Les données
1.2.1.4 Les middlewares
1.2.2 Architecture un-tiers
1.2.3 Architecture deux-tiers
1.2.4 Architecture trois-tiers
1.2.5 Architecture n-tiers
1.2.6 Avantages
1.2.7 Inconvénients
1.3 La technologie Web
1.3.1 Définitions
1.3.2 Historique du Web
1.3.3 Les différents types de ressources du Web
1.3.4 Conception
1.3.4.1 Universalité
1.3.4.2 Décentralisation
1.3.5 Avantages
1.3.6 Inconvénients
1.4 Architecture Orientée Service (SOA)
1.4.1 Définition
1.4.2 Les éléments dans une SOA
1.4.3 Avantages
1.4.4 Inconvénients
1.5 Système GRID
1.5.1 Définition
1.5.2 Principes de base du Grid Computing
1.5.3 Les différents types de Grid Computing
1.5.3.1 Grille de calcul
1.5.3.2 Data grid (Grille de stockage)
1.5.4 Avantages
1.5.5 Inconvénients
1.6 Virtualisation
1.6.1 Définition
1.6.2 Les techniques utilisées en virtualisation
1.6.2.1 L’isolation
1.6.2.2 L’émulation
1.6.3 Les différents types de virtualisation
1.6.3.1 Virtualisation d’application
1.6.3.2 Virtualisation des données
1.6.3.3 Virtualisation de la présentation
1.6.3.4 Virtualisation de réseau
1.6.3.5 Virtualisation de plateforme
1.6.4 Avantages
1.6.5 Inconvénients
1.7 Conclusion
CHAPITRE 2 CONCEPT DU CLOUD COMPUTING
2.1 Introduction
2.2 Définitions
2.2.1 Cloud Computing
2.2.2 Datacenter
2.3 Historique
2.4 Caractéristiques
2.4.1 Accès réseau universel
2.4.2 Mise en commun de ressources
2.4.3 Service mesurable et facturable
2.4.4 Flexibilité
2.4.4.1 Cas d’un datacenter classique
2.4.4.2 Cas d’un Cloud Computing
2.5 Modèles de déploiement
2.5.1 Cloud privé
2.5.2 Cloud publique
2.5.3 Cloud hybride
2.5.4 Cloud communautaire
2.6 Différents types de service Cloud
2.6.1 Infrastructure as a Service : IaaS
2.6.1.1 Définition
2.6.1.2 Caractéristiques
2.6.1.3 Exemples
2.6.2 PaaS: Platform as a Service
2.6.2.1 Définition
2.6.2.2 Caractéristiques
2.6.2.3 Exemples
2.6.3 SaaS: Software as a Service
2.6.3.1 Définition
2.6.3.2 Caractéristiques
2.6.3.3 Exemples
2.6.4 Récapitulation graphique
2.7 Sécurité
2.7.1 Sécurité des données
2.7.1.1 Protection et récupération des données
2.7.1.2 Intégrité des données
2.7.1.3 Chiffrement lié aux données
2.7.1.4 Données du Cloud accessibles aux autorités d’un pays
2.7.1.5 Changement de fournisseur
2.7.2 La sécurité logique
2.7.2.1 La sécurité des serveurs virtuels
2.7.2.2 Sécurisation des accès
2.7.2.3 Sécurisation de l’administration
2.8 Avantages
2.8.1 Avantages du Cloud public
2.8.2 Avantages du Cloud privé
2.9 Inconvénients
2.9.1 Inconvénients du Cloud public
2.9.2 Inconvénients du Cloud privé
2.10 Conclusion
CHAPITRE 3 ETUDE DE PERFOMANCE DE CALCUL ET DE TRANSFERT DE DONNEES D’UN SYSTEME INFORMATIQUE
3.1 Introduction
3.2 Processeur (Central Processing Unit)
3.2.1 Description
3.2.2 Notion d’opération élémentaire et FLOPS (Floating Point Operations Per Second)
3.2.3 Capacité de calcul théorique et puissance maximale
3.2.4 Evolution de capacité de calcul d’un système informatique
3.2.5 Répartition de charges
3.2.5.1 Ordonnancement statique
3.2.5.2 Ordonnancement dynamique
3.3 Disques de stockages
3.3.1 Mode de lecture/écriture sur un disque de stockage
3.3.2 Notion d’IOPS (Input/Output Operations Per Second)
3.3.3 Disque dur (Hard Disk Drive)
3.3.3.1 Description
3.3.3.2 Latence de rotation (?????????)
3.3.3.3 Temps de recherche d’une piste (??????????)
3.3.3.4 Temps d’accès
3.3.3.5 Temps de transfert (??????????)
3.3.3.6 Temps d’opération E/S (??/?)
3.3.4 Disque électronique (Solid-State Drive)
3.3.4.1 Description
3.3.4.2 Techniques utilisées
3.3.4.3 Tableau comparatif
3.3.5 RAID (Redundant Array of Independent Disks)
3.3.5.1 Description
3.3.5.2 Les différentes types de systèmes RAID
3.3.5.3 Critères d’évaluation d’un RAID
3.3.5.4 RAID-0
3.3.5.5 RAID-1 : mirroring
3.3.5.6 RAID-3 et RAID-4
3.3.5.7 RAID-5
3.3.5.8 Capacité, fiabilité et performance des systèmes RAID standards
CONCLUSION GENERALE
