Système Distribué à

Grande Echelle

Année universitaire : 2023-2024

1- Introduction
Les réseaux d’ordinateurs sont partout. Internet en est un, tout comme les nombreux réseaux
dont il est composé. Réseaux de téléphonie mobile, réseaux d’entreprise, réseaux d’usine,
réseaux de campus, réseaux domestiques, réseaux embarqués - tout cela, à la fois séparément
et en combinaison, partagent les caractéristiques essentielles qui en font des sujets pertinents
pour étude sous la rubrique systèmes distribués.

La taxonomie de Flynn est une classification des architectures d’ordinateur, proposée par
Michael Flynn en 1961, les quatre catégories définies par Flynn sont classées selon le type
d’organisation du flux de données et du flux d’instructions.

• SISD (unique flux d’instructions, unique flux de données) Il s’agit d’un ordinateur
séquentiel qui n’exploite aucun parallélisme, tant au niveau des instructions qu’au
niveau de la mémoire. Cette catégorie correspond à l’architecture de von Neumann.

• SIMD (unique flux d’instructions, multiples flux de données) Il s’agit d’un ordinateur
qui utilise le parallélisme au niveau de la mémoire, par exemple le processeur
vectoriel.

• MISD (multiples flux d’instructions, unique flux de données) Il s’agit d’un ordinateur
dans lequel une même donnée est traitée par plusieurs unités de calcul en parallèle. Il
existe peu d’implémentions en pratique. Cette catégorie peut être utilisée dans le
filtrage numérique et la vérification de redondance dans les systèmes critiques.

• MIMD (multiples flux d’instructions, multiples flux de données) Dans ce cas,

plusieurs unités de calcul traitent des données différentes, car chacune d’elles possède
une mémoire distincte. Il s’agit de l’architecture parallèle la plus utilisée, dont les
deux principales variantes rencontrées sont les suivantes :

– MIMD à mémoire partagée (fortement couplées) Les unités de calcul ont

accès à la mémoire comme un espace d’adressage global. Tout changement
dans une case mémoire est vu par les autres unités de calcul. La
communication entre les unités de calcul est effectuée via la mémoire globale.

– MIMD à mémoire distribuée (faiblement couplées) Chaque unité de calcul

possède sa propre mémoire et son propre système d’exploitation. Ce second cas
de figure nécessite un middleware pour la synchronisation et la
communication.
En fait ces systèmes qui font l’objet de notre cours qui sont les systèmes
distribués. Un système MIMD hybride est l’architecture la plus utilisée par les
superordinateurs. Ces systèmes hybrides possèdent l’avantage d’être très
extensibles, performants et à faible coût.
2- Notions de système distribué

Selon Tanenbaum, un système réparti est un ensemble d’ordinateurs (ou processus)

indépendants qui apparaît à un utilisateur comme un seul système cohérent. Les ordinateurs
peuvent garder leur autonomie et être regroupés dans un même lieu ou dispersés sans que cela
ne soit visible de l’extérieur par un utilisateur. Du fait que l’ensemble des ordinateurs forment
un système en entier, la défaillance d’un ordinateur peut avoir un impact négatif le
fonctionnement du système et introduire des incohérences. En prenant en compte cet aspect,
un système distribué peut être défini comme "un système qui vous empêche de travailler si
une machine dont vous n’avez jamais entendu parler tombe en panne. S’il existe moult
définitions dont nous ignorons le nombre, on peut dire que les principaux objectifs des
systèmes répartis sont de faire coopérer plusieurs ressources dans l’optique de partager des
tâches, de faire des traitements parallèles, etc . Ainsi, un système distribué peut être vu
comme une application qui coordonne les tâches de plusieurs équipements informatiques
(ordinateurs, téléphones mobile, PDA, capteurs...).

Cette coordination se fait le plus souvent par envoi de messages via un réseau de
communication qui peut être un LAN (Local Area Network), WAN (Wide Area Network),
Internet, etc.

Les systèmes distribués peuvent être classés de différentes manières et dans trois classes ont
été essentiellement identifiées à savoir les systèmes de calcul distribué (Distributed
Computing Systems), les systèmes d’information distribués (Distributed Information
Systems) et les systèmes pervasifs distribués (Distributed Pervasive Systems). Cette
classification est axée essentiellement sur les domaines applicatifs des systèmes distribués
plutôt que sur leur organisation interne (répartition géographique et support de
communication) et les spécificités des ressources (hétérogénéité, stabilité des ressources, etc.).
Pourtant, l’organisation et les caractéristiques des ressources sont des éléments essentiels qui
permettent de bien prendre en compte les besoins spécifiques des applications en termes de
performance. Ce faisant, nous avons fait un classement qui s’appuie plus sur l’organisation et
les caractéristiques des ressources.

• la grappe d’ordinateur (Cluster) : c’est un ensemble d’ordinateurs connectés par un

réseau LAN rapide et fiable pour assurer la disponibilité. Les ressources quasi-
homogènes (même système d’exploitation, logiciels quasi-similaires) sont sous le
contrôle d’un seul noeud appelé noeud maître ;

• la grille informatique (Grid) : c’est une collection d’ordinateurs hétérogènes

réparties sur différents sites maintenus par plusieurs organisations. Les sites sont reliés
par un réseau WAN et chacun d’entre eux contient plusieurs ressources informatiques
administrées de manière autonome et uniforme ;

• les systèmes pair-à-pair (peer-to-peer (P2P)) : c’est un ensemble d’ordinateurs

appelés pairs, qui s’accordent à exécuter une tâche particulière. Les ressources peuvent
être des ordinateurs ou des assistants personnels interconnectés via Internet, ce qui
rend le système beaucoup plus flexible mais aussi moins fiable et stable ;
 • cloud : du point de vue système, le cloud est un ensemble d’ordinateurs (ressources)
stockés sur de vastes grilles de serveurs ou de data centres. Les ressources du cloud
sont mutualisées à travers une virtualisation qui favorise la montée en charge, la haute
disponibilité et un plan de reprise à mondre coût.

• les réseaux de capteurs (Sensor Network) : c’est une collection de micro-ressources

informatiques (micro-capteur ou système embarqué) reliées le plus souvent par un
réseau sans fil en vue de collecter, d’échanger et de transmettre des données (en
général environnementales) vers un ou plusieurs points de collecte, d’une manière
autonome.

3- Les propriétés requises des systèmes distribués

Un système réparti doit assurer plusieurs propriétés pour être considéré comme performant.
Nous citerons dans cette section les plus communes : la transparence, le passage à l’échelle, la
disponibilité et l’autonomie.

• Transparence
La transparence permet de cacher aux utilisateurs les détails techniques et
organisationnels d’un système distribué ou complexe. L’objectif est de pouvoir faire
bénéficier aux applications une multitude de services sans avoir besoin de connaître
exactement la localisation ou les détails techniques des ressources qui les fournissent.
Ceci rend plus simple, le développement des applications mais aussi leur maintenance
évolutive ou corrective. Selon la norme (ISO, 1995) la transparence a plusieurs
niveaux :
– accès : cacher l’organisation logique des ressources et les moyens d’accès à
une ressource ;

– localisation : l’emplacement d’une ressource du système n’a pas à être connu ;

– migration : une ressource peut changer d’emplacement sans que cela ne soit
aperçu ;

– relocalisation : cacher le fait qu’une ressource peut changer d’emplacement

au moment où elle est utilisée ;

– réplication : les ressources sont dupliquées mais les utilisateurs n’ont aucune
connaissance de cela ;

– panne : si un nœud est en panne, l’utilisateur ne doit pas s’en rendre compte et
encore moins de sa reprise après panne ;

– concurrence : rendre invisible le fait qu’une ressource peut être partagée ou

sollicitée simultanément par plusieurs utilisateurs.
Le parcours de cette liste montre qu’il n’est pas évident d’assurer une transparence
totale. En effet, masquer complètement les pannes des ressources est quasi impossible
aussi bien d’un point de vue théorique que pratique. Ceci est d’autant plus vrai qu’il
n’est pas trivial de dissocier une machine lente ou surchargée de celle qui est en panne
ou dans un sous-réseau inaccessible.

• Passage à l’échelle
Le concept de passage à l’échelle désigne la capacité d’un système à continuer à
délivrer avec un temps de réponse constant un service même si le nombre de clients ou
de données augmente de manière importante. Le passage à l’échelle peut être mesuré
avec au moins trois dimensions :

i) le nombre d’utilisateurs et/ou de processus (passage à l’échelle en taille) ;

ii) la distance maximale physique qui sépare les noeuds ou ressources du système
(passage à l’échelle géographique) ;

iii) le nombre de domaines administratifs (passage à l’échelle administrative). Le

dernier type de passage à l’échelle est d’une importance capitale dans les grilles
informatiques car il influe sur le degré d’hétérogénéité et donc sur la complexité du
système.

Pour assurer le passage à l’échelle, une solution coûteuse consiste à ajouter de

nouveaux serveurs puissants (plusieurs dizaines de CPU) pour garder le même niveau
de performance en présence de fortes charges. Ce type de passage à l’échelle est plus
connu sous le nom de Scale Up. Le problème avec cette solution est que si le système
est sous-chargé les ressources consomment de l’énergie inutilement et ne servent à
rien. D’autres solutions moins chères consistent à utiliser plusieurs machines moins
puissantes (d’un à deux CPU par machine) pour faire face aux pics des charges, on
parle alors de Scale Out. Trois techniques peuvent être utilisées pour favoriser le
passage à l’échelle à faible coût.

La première technique consiste à ne pas attendre la fin d’une tâche pour commencer
une autre si elles sont indépendantes. Cela permet de cacher la latence du réseau ou la
lenteur d’une ressource. Ce modèle de fonctionnement est appelé modèle asynchrone.

La deuxième technique consiste à partitionner les données et les stocker sur plusieurs
serveurs. Ceci permet de distribuer la charge applicative et de réduire le temps de
traitement global des tâches. Il est aussi possible d’effectuer certains traitements aux
niveaux des clients (Java Applets).

La troisième technique est l’utilisation de la réplication et/ou des mécanismes de

cache. L’accès à des informations stockées dans un cache réduit les accès distants et
donne de bonnes performances aux applications de type web. La réplication, quant à
elle, permet une distribution des traitements sur plusieurs sites permettant ainsi une
amélioration du débit du traitement.

Cependant, l’utilisation de ces techniques présente quelques inconvénients. En effet, le

partitionnement et la distribution d’un traitement nécessitent des mécanismes de
contrôle plus complexes pour intégrer les résultats et assurer leur cohérence. En plus,
garder plusieurs copies d’une même donnée (caches ou répliques) peut entraîner des
incohérences à chaque fois que l’on met une copie à jour. Pour éviter ce problème, il
faut penser à faire des synchronisations, ce qui est souvent contradictoire avec la
première technique de passage à l’échelle à savoir faire de l’asynchronisme.

En conclusion, les besoins de passage à l’échelle et de cohérence sont en opposition,

d’où la nécessité de trouver des compromis en fonction des besoins des applications
cibles.

• Disponibilité
Un système est dit disponible s’il est en mesure de délivrer correctement le ou les
services de manière conforme à sa spécification. Pour rendre un système disponible, il
faut donc le rendre capable de faire face à tout obstacle qui peut compromettre son bon
fonctionnement. En effet, l’indisponibilité d’un système peut être causée par plusieurs
sources parmi lesquelles nous pouvons citer :

– les pannes qui sont des conditions ou évènements accidentels empêchant le système,
ou un de ses composants, de fonctionner de manière conforme à sa spécification ;

– les surcharges qui sont des sollicitations excessives d’une ressource du système
entraînant sa congestion et la dégradation des performances du système ;

– les attaques de sécurité qui sont des tentatives délibérées pour perturber le
fonctionnement du système, engendrant des pertes de données et de cohérences ou
l’arrêt du système.

Pour faire face aux pannes, deux solutions sont généralement utilisées.

La première consiste à détecter la panne et à la résoudre, et ce dans un délai très

court. La détection des pannes nécessite des mécanismes de surveillance qui
s’appuient en général sur des timeouts ou des envois de messages périodiques entre
ressources surveillées et ressources surveillantes. Cette détection, outre la surcharge
qu’elle induit sur le système, ne donne pas toujours des résultats fiables. En effet, avec
l’utilisation des timeouts, à chaque fois qu’un timeout est expiré, la ressource
sollicitée, ne pouvant être contactée ou n’arrivant pas à envoyer une réponse, est en
général suspectée d’être en panne. Par conséquent, une simple variation de la latence
du réseau ou de la surcharge d’une ressource peut entraîner l’envoi et/ou la réception
d’une réponse en dehors du timeout et donc conduire à des fausses suspicions. Par
ailleurs, une fois la panne détectée, il faut des mécanismes de résolution efficace pour
arriver à la cacher aux clients. Cette tâche est loin d’être triviale car il existe plusieurs
types de pannes et chacune d’entre elle requiert un traitement spécifique (voir chapitre
suivant).

La deuxième solution consiste à masquer les pannes en introduisant de la réplication.

Ainsi, quand une ressource est en panne, le traitement qu’elle effectuait est déplacé sur
une autre ressource disponible. La réplication peut être aussi utilisée pour faire face à
la seconde cause d’indisponibilité d’un système (surcharge du système). Pour réduire
la surcharge d’une ressource, les tâches sont traitées parallèlement sur plusieurs
répliques ou sur les différentes répliques disponibles à tour de rôle (tourniquet). Une
autre technique qui permet de réduire la surcharge d’une ressource consiste à
distribuer les services (ou les données) sur plusieurs sites et donc de les solliciter de
manière parallèle. Le partitionnement des services ou des données permet d’isoler les
pannes et donc de les contrôler plus simplement.

Enfin, la gestion de la dernière source d’indisponibilité nécessite des politiques de

sécurité sur l’accès et l’utilisation des ressources. Ces politiques ont pour objet la mise
en œuvre de mécanismes permettant de garantir les deux propriétés suivantes : la
confidentialité et l’intégrité des ressources ou informations sensibles. La
confidentialité permet de protéger les accès en lecture aux informations, alors que
l’intégrité permet de protéger les accès en écriture. S’il existe une seule politique de
sécurité pour l’ensemble des ressources, la sécurité est dite centralisée, dans le cas
contraire, elle est dite distribuée et permet à chaque partie du système d’avoir sa
propre politique.

Il est à noter qu’une politique de sécurité distribuée permet plus d’hétérogénéité et

s’adapte à des systèmes comme les grilles informatiques mais nécessite des
mécanismes plus complexes.

• Autonomie
Un système ou un composant est dit autonome si son fonctionnement ou son
intégration dans un système existant ne nécessite aucune modification des composants
du système hôte. L’autonomie des composants d’un système favorise l’adaptabilité,
l’extensibilité et la réutilisation des ressources de ce système. Par exemple, une
ressource autonome peut être remplacée avec une autre ressource plus riche en termes
de fonctionnalités, ce qui étend les services du système. Le changement du pilote
d’accès à une base de données ODBC par un pilote JDBC illustre bien cette notion
d’autonomie et son impact dans le fonctionnement d’un système, puisqu’aucune
modification ne sera effectuée au niveau du SGBD.

L’une des motivations de maintenir l’autonomie est que les applications existantes
sont difficiles à remplacer car d’une part, elles sont le fruit d’une expertise développée
pendant plusieurs années et d’autre part, leur code n’est pas souvent accessible, i.e. les
 SGBD tels que Oracle, SQL Server, Sybase, etc. Pourtant, il est indispensables de
s’appuyer sur les applications existantes car les clients ont leurs préférences et ne sont
pas nécessairement prêts à confier leur traitement à une nouvelle application ou de
stocker leurs données sur un SGBD nouveau qui ne présente pas les mêmes garanties
qu’un système connu, fiable et maintenu. Une solution pour garder l’autonomie d’une
application ou d’un SGBD est d’intégrer toute nouvelle fonctionnalité supplémentaire
et spécifique à une application sous forme d’intergiciel.

Cependant, l’implémentation de l’intergiciel introduit de nouvelles surcharges en

ajoutant une couche de plus à l’accès aux données. A cela, s’ajoute que l’intergiciel
devient indispensable au fonctionnement du système et peut devenir très rapidement
source de congestion s’il est partagé par plusieurs applications. Pour minimiser ces
impacts négatifs, l’intergiciel doit être conçu de tel sorte qu’il soit toujours disponible
et non surchargé. La complexité de son implémentation doit être contrôlée afin de
minimiser le coût de sa traversée. Pour ce faire, il faut éviter de concevoir un
intergiciel très générique à destination de plusieurs applications au profit d’un
intergiciel ad-hoc.

4- Etude de quelques systèmes distribués

Dans cette section, nous étudions trois catégories de systèmes distribués à savoir les systèmes
pair-à-pair (P2P), les grilles informatiques et le cloud. Le choix d’étudier ces trois catégories
est fortement tributaire de leur caractère très hétérogène et leur besoin de passage à l’échelle,
que nous avons privilégié. L’étude met l’accent sur les architectures et les mécanismes
permettant d’assurer la disponibilité, le passage à l’échelle et la transparence et l’autonomie.

4.1. Systèmes P2P

Comme nous l’avons mentionné ci-avant, le terme P2P fait référence à une classe de systèmes
distribués qui utilisent des ressources distribuées pour réaliser une tâche particulière de
manière décentralisée. Les ressources sont composées d’entités de calcul (ordinateur ou
PDA), de stockage de données, d’un réseau de communication, etc. La tâche à exécuter peut
être du calcul distribué, du partage de données (ou de contenu), de la communication et
collaboration, d’une plateforme de services, etc. La décentralisation, quant à elle, peut
s’appliquer soit aux algorithmes, soit aux données, soit aux métadonnées, soit à plusieurs
d’entre eux. L’une des particularités des systèmes P2P est que tous les noeuds (pairs) sont en
général symétriques, c’est à dire qu’ils jouent à la fois le rôle de client et de serveur. En
particulier, les systèmes de partage de fichiers permettent de rendre les objets d’autant plus
disponibles qu’ils sont populaires, en les répliquant sur un grand nombre de noeuds. Cela
permet alors de diminuer la charge (en nombre de requêtes) imposée aux noeuds partageant
les fichiers populaires, ce qui facilite l’augmentation du nombre de clients et donc le passage
à l’échelle en taille des données.

Les pairs sont organisés autour d’une architecture qui peut être centralisée ou non. Dans
l’architecture centralisée, un noeud joue le rôle de coordinateur central (serveur, ou index
central) et gère soit les partages, soit la recherche, soit l’insertion d’informations et de
nouveaux noeuds. Cependant l’échange d’informations entre noeuds se passe directement
d’un noeud à l’autre. D’aucun considèrent que de telles architectures ne sont pas pair-à-pair,
car un serveur central intervient dans le processus. Par contre d’autres arguent que ce sont
bien des systèmes pair-à-pair car les fichiers transférés ne passent pas par le serveur central.
Néanmoins, c’est une solution fragile puisque le serveur central est indispensable au réseau.
Ainsi, s’il est en panne ou non accessible, tout le réseau s’effondre. En plus, le système n’est
pas transparent puisque les noeuds ont besoin de savoir à tout moment l’emplacement de
l’index et sont sensibles à tout changement de celui-ci. Un exemple de solution P2P
centralisée est Napster, qui utilise un serveur pour stocker un index ou pour initialiser le
réseau.

Pour faire face à ces insuffisances, une architecture distribuée s’impose, puisqu’un noeud
pourrait solliciter plusieurs serveurs en même temps. Le système est ainsi plus robuste mais la
recherche d’informations est plus difficile. Elle peut s’effectuer dans des systèmes
décentralisés non-structurés, comme Gnutella. Dans ce système, la recherche se fait par
propagation de la requête aux voisins jusqu’à trouver les résultats, ce qui nécessite dès lors un
nombre de messages élevé, proportionnel au nombre d’utilisateurs du réseau (et exponentiel
suivant la profondeur de recherche).
Dans les systèmes décentralisés structurés, une organisation de connexion et de répartition des
objets partagés est maintenue entre les noeuds. Souvent cette organisation est basée sur les
tables de hachage distribuées, permettant de réaliser des recherches en un nombre de
messages croissant de façon logarithmique avec le nombre d’utilisateurs du réseau.

Une autre solution possible est l’utilisation de « super-pairs », noeuds du réseau choisis en
fonction de leur puissance de calcul et de leur bande passante, réalisant des fonctions utiles au
système comme l’indexation des informations et le rôle d’intermédiaire dans les requêtes.
Cette solution que l’on retrouve dans Kazaa, rend le système un peu moins tolérant aux
pannes que les systèmes complètement décentralisés et englobe un peu l’idée de client-
serveur entre pairs et super-pairs.

Comme tous les noeuds sont au même niveau avec les architectures complètement distribuées,
celle-ci offrent plus de transparence dans l’organisation et la localisation des ressources que
les architectures centralisées ou semi-centralisées (super-pairs). Les systèmes P2P soulèvent
plusieurs problèmes bien qu’ils facilitent le passage à l’échelle et la disponibilité des
ressources avec un faible coût.

Il faut noter en premier lieu que les noeuds du système sont totalement autonomes et donc
qu’ils peuvent choisir de partager ou non leur CPU et leur capacité de stockage. Cette
autonomie leur confère aussi le choix de rejoindre ou quitter le système à tout moment. Cela a
pour effet de compromettre la capacité de calcul totale et réelle du système mais aussi la
disponibilité des ressources (informations, capacité de stockage, etc.).

En second lieu, le système de communication utilisé est de faible bande passante (en général
Internet), ce qui peut créer une surcharge du système et une latence plus élevée que dans les
clusters. Enfin, l’absence d’infrastructures de contrôle sur les systèmes P2P rend ces derniers
moins pratiques pour prendre en compte certains types d’applications qui exigent une grande
qualité ou des services transactionnels. Néanmoins, les systèmes P2P sont devenus
incontournables aujourd’hui dans le domaine du partage de fichiers, de la recherche
d’information et de la collaboration.

4.2. Les grilles informatiques ou grid

Le terme anglais grid désigne un système distribué d’électricité. Initialement, le concept de

grille partait du principe d’un tel système : les ressources d’un ordinateur (processeur,
mémoire, espace disque) étaient mises à la disposition d’un utilisateur aussi facilement que
l’on branche un appareil électrique à une prise électrique. Une grille informatique est une
infrastructure virtuelle constituée d’un ensemble de ressources informatiques potentiellement
partagées, distribuées, hétérogènes, délocalisées et autonomes. Une grille est en effet une
infrastructure, c’est-à-dire des équipements techniques d’ordre matériel et logiciel. Cette
infrastructure est qualifiée de virtuelle car les relations entre les entités qui la composent
n’existent pas sur le plan matériel mais d’un point de vue logique.

D’un point de vue architectural, la grille peut être définie comme un système distribué
constitué de l’agrégation de ressources réparties sur plusieurs sites et mises à disposition par
plusieurs organisations différentes. Un site est un lieu géographique regroupant plusieurs
ressources informatiques administrées de manière autonome et uniforme. Il peut être composé
d’un super-calculateur ou d’une grappe de machines (cluster).
Contrairement aux systèmes P2P, une grille garantit des qualités de service non triviales, c’est
à dire qu’elle répond adéquatement à des exigences (accessibilité, disponibilité, fiabilité, ...)
compte tenu de la puissance de calcul ou de stockage qu’elle peut fournir.

Il existe plusieurs projets de grilles qui ont été mis en place aussi bien à des échelles
nationales qu’internationales : la grille expérimentale française Grid’5000, la grille de calcul
scientifique nord-américain TeraGrid, la grille chinoise CNGrid, la grille Asie-Pacifique
ApGrid, etc.

Les grilles informatiques sont caractérisées par une forte hétérogénéité et une grande
dynamicité. En effet, les machines d’une grappe sont reliés par un réseau gigabits alors que
les sites sont liés par un réseau WAN, dont la latence peut aller jusqu’à 100 millisecondes. De
là, nous pouvons noter une différence importante de la latence entre deux machines d’un
même site et celle entre deux machines de deux sites. En outre, chaque site est administré de
manière autonome et par conséquent les politiques de sécurité varient d’un site à l’autre. Un
autre exemple d’hétérogénéité relève de la composition interne d’un site. Chaque site est libre
de choisir le type de processeur de ses machines (Intel, AMD, IBM, ...), la capacité de
stockage et le réseau d’interconnexion entre machines (Gigabit Ethernet, Infiniband, ...). Enfin
l’infrastructure d’une grille est composée d’un nombre important de sites et de machines qui
sont susceptibles de tomber en panne à tout moment.

A cela s’ajoute le fait que de nouveaux sites peuvent être ajoutés ou retirés de la grille sans
trop impacter le fonctionnement de la grille. De par leur hétérogénéité, leur gestion
décentralisée et leur taille, les grilles sont des infrastructures très complexes à mettre en
œuvre.

La transparence n’est assurée qu’à moitié parce qu’il faut avoir une information précise des
ressources dans un site pour pouvoir distribuer les tâches convenablement. Cependant à
l’intérieur d’un site, la machine qui effectue concrètement la tâche n’est pas connue en
général.

4.3- Le cloud computing

Le cloud est un concept plus récent dont une définition unanime tarde à voir le jour. Cette
divergence découle des principes considérés par les chercheurs pour définir le cloud. En effet,
certains auteurs mettent l’accent sur le passage à l’échelle et la mutualisation de l’usage des
ressources alors que d’autres privilégient le concept de virtualisation ou le business model
(collaboration et pay-as-you-go).

Cependant, il est unanimement reconnu que le cloud permet l’utilisation de la mémoire et des
capacités de calcul des ordinateurs et des serveurs répartis dans le monde entier et liés par un
réseau, tel Internet.

Les ressources sont en général logées dans des data centres qui sont géographiquement
distribués dans l’optique de garantir le passage à l’échelle et la disponibilité. Avec le cloud,
les utilisateurs ne sont plus propriétaires de leurs serveurs informatiques mais peuvent ainsi
accéder de manière évolutive à de nombreux services en ligne sans avoir à gérer
l’infrastructure sous-jacente, souvent complexe. C’est pourquoi, on peut considérer le cloud
comme une extension des ASP. Les applications et les données ne se trouvent plus sur
l’ordinateur local, mais dans un nuage (cloud) composé d’un certain nombre de serveurs
distants interconnectés au moyen d’une excellente bande passante indispensable à la fluidité
du système. L’accès au service se fait par une application standard facilement disponible, la
plupart du temps un navigateur Web. Les service offerts par le cloud sont nombreux parmi
lesquels nous avons :

– Infrastructure as a service (IaaS) : c’est un service qui donne à l’utilisateur un

ensemble de ressources de traitement et de stockage dont il a besoin à un instant précis
pour effectuer ses tâches ;

– Platform as a Service (PaaS) : ce service, en dehors de fournir une infrastructure

virtuelle, assure aussi la plateforme logicielle pour que les applications de l’utilisateur
puissent tourner ;

– Software as a Service (SaaS) : c’est une alternative de toute application locale. Un

exemple de ce cas est l’utilisation en ligne de la suite bureautique de Microsoft
Office.
Pour assurer ces services qui varient d’un utilisateur à un autre, l’architecture des
clouds est composée à son niveau le plus basique d’une couche logique composée
d’un ensemble de machines virtuelles et d’une couche physique composée de data
centres. Ainsi, plusieurs machines virtuelles peuvent être démarrées dynamiquement
sur une seule machine physique pour satisfaire les besoins de plusieurs services. Les
data centres qui regroupent les machines physiques sont en général répartis sur des
sites géographiquement distants afin d’assurer une haute disponibilité. En plus cette
répartition permet aussi d’assurer un niveau de performances élevé en branchant un
utilisateur sur le site le plus proche de son emplacement afin de réduire les délais de
communication.

La mutualisation du matériel permet d’optimiser les coûts par rapport aux systèmes
conventionnels et de développer des applications partagées sans avoir besoin de
posséder ses propres machines dédiées au calcul. Comme pour la virtualisation,
l’informatique dans le nuage est plus économique 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).

Notons également que l’élasticité du nuage permet de fournir des services évolutifs et
donc de supporter les montées de charges. Par exemple, Salesforce.com, pionnier dans
le domaine de l’informatique dans le nuage gère les données de 54 000 entreprises, et
leurs 1,5 millions d’employés, avec seulement 1 000 serveurs (mars 2009). De plus,
les services sont extrêmement fiables car basés sur des infrastructures performantes
possédant des politiques efficaces de tolérance aux pannes (notamment des répliques).
Grâce à ses avantages, on assiste aujourd’hui à une multiplication rapide d’entreprises
 qui proposent des solutions cloud parmi lesquelles figurent : Amazon, IBM,
Microsoft, Google, etc.

Cependant, le problème fondamental reste d’une part la sécurisation de l’accès à

l’application entre le client et le serveur distant. On peut aussi ajouter le problème de
sécurité générale du réseau de l’entreprise : sans le cloud computing, une entreprise
peut mettre une partie de son réseau en local et sans aucune connexion (directe ou
indirecte) à internet, pour des raisons de haute confidentialité par exemple ; dans le cas
du cloud computing, elle devra connecter ces postes à internet (directement ou pas) et
ainsi les exposer à un risque d’attaque ou a des violations de confidentialité.

5- Exemple d’utilisation des systèmes distribués à large échelle

Les systèmes à large échelle tels que les P2P ou les grilles peuvent être utilisés pour concevoir
et réaliser différentes classes d’applications.

– Communication et collaboration. Cette catégorie inclut les systèmes qui fournissent

des infrastructures pour faciliter la communication et la collaboration en temps réel
(ex. Skype, MSN, Yahoo, Groove) ;
– Calcul distribué. Ce type d’application permet le partage de ressources CPU en
divisant et répartissant le travail sur plusieurs machines. Seti@home, le projet de
recherche d’une intelligence extraterrestre de l’université de Californie et de Berkley
d’une part et Folding@Home, le projet de calcul réparti étudiant les protéines de
l’université de Standford d’autre part sont des illustrations de ce cas d’application.

– Support de service internet. Un nombre considérable d’applications basées sur les

systèmes P2P ont été développées pour supporter les services sur internet. Parmi les
exemples de ce type d’applications, nous pouvons citer les systèmes de multicast P2P
publish/subscribe ou les applications de sécurité et d’antivirus.

– Système de Base de données. Les sytèmes distribués sont également utilisés pour
concevoir des bases de données distribuées. Par exemple, Local Relational Model,
PIER utilisent des architectures P2P pour stocker et exploiter des données.

– Distribution et gestion de contenu. Elle constitue la charnière centrale des

utilisations que l’on peut faire avec les systèmes distribués. Elle couvre une variété
d’applications allant du simple partage de fichiers direct aux systèmes sophistiqués qui
fournissent des supports de stockage distribué, une technique d’indexation et de
localisation efficace et enfin des procédures de mises à jour. Google File System
(GFS), Hadoop Distributed File System (HDFS) sont des exemples de support de
stockage distribués avec un mécanisme d’indexation efficace. Un autre avantage
majeur de cette classe d’applications est qu’elle donne aux utilisateurs la possibilité de
publier, de stocker et de gérer leur contenu de manière assez efficace.