Vous êtes sur la page 1sur 88

Architecture des Systèmes Distribués:

Principes
p et p
paradigmes
g

Mastère 1 Info Décisionnelle


Décisionnelle, ISSAT
ISSAT, 2017/2018

Mr JMAL Mohamed Wassim Mahmoud Ghorbel


Email:wassim.jmal@gmail.com

1 Architecture logicielle distribué Mr JMAL


Référence du cours
` Livre:
` Distributed Systems; Principles and paradigms (2nd Edition)
` Auteurs:
` Andre S.Tanenbaum
Andrew S Tanenba m et Maarten van
an Steen
` Lien pour télécharger le livre:
http://www.distributed
http://www distributed-systems
systems.net/index.php?id
net/index php?id=distributed-systems-
distributed systems
principles-and-paradigms
`

2 Architecture logicielle distribué Mr JMAL


Objectifs
` Comprendre les principes de base des systèmes distribués d’un
point de vue architectural et fonctionnel

` Dé
Découvrir
i des
d exemples
l d systèmes
de è di ib é réels
distribués é l et leurs
l
utilisation

` Avoir une idée sur quelques axes de recherche en relation avec les
systèmes distribués

3 Architecture logicielle distribué Mr JMAL


Mini Projets
Mini-Projets
` Travail demandé: Définition, recherche, état de l’art, outils et
applications,
li i d
domaines
i d’ ili i
d’utilisation
` Livrable: rapport de 15 pages max (sans plagia) et présentation de
10 minutes.
minutes
` Sujets:
` 1)) Cluster computing
p g ((Grappe
pp de Calcul))
` 2) Grid computing (Grille de calcul)
` 3) Cloud computing
` 4) Location-based service
` 5) Sensor network (réseau de capteurs)
` 6) Système P2P (peer to peer)
` 7) Content Delivery Network
` 8)) Web services
` Tout autre sujet en relation avec les systèmes distribués
4 Architecture logicielle distribué Mr JMAL
Plan
` I) Introduction
` II) Architecture
` III) Processus
` IV) Communication
` V) Synchronisation
` VI) Consistance et réplication
` VII) Système distribué orienté objet
` VIII) Système de fichier distribué
` IX)) Système
y distribué orienté service
` X) Système distribué orienté coordination

5 Architecture logicielle distribué Mr JMAL


Chapitre I
Introduction

6 Architecture logicielle distribué Mr JMAL


Système Distribué: Définition
` Un système distribué est un logiciel qui garantie:
` Une collection d’ordinateurs indépendants apparaissant à ses utilisateurs
comme un seul système cohérent.
` Deux aspects apparaissent:
` 1) ordinateurs indépendants
` 2) seul système cohérent Î middleware.

7 Architecture logicielle distribué Mr JMAL


Système Distribué: Objectifs

` Disponibilité des ressources


` Transparence de la distribution
` Ouverture et interopérabilité
` Scalability (passage à l’échelle réelle)

8 Architecture logicielle distribué Mr JMAL


1) Disponibilité des ressources
` Objectif principale des systèmes distribués:
` Permettre à des utilisateurs et des applications d’accéder et de partager
des ressources distantes avec une façon contrôlée et efficace:
` Imprimantes, ordinateurs,
Imprimantes ordinateurs services de stockage,
stockage bases de données,
données fichiers,
fichiers
pages web, etc.
` Le ppartage
g de ressources facilite la collaboration et l’échange g
d’information (succès de l’internet)
` Î permet l’expansion des entreprises géographiquement tout en
restant connectéé : téléconférence,
élé fé messagerie
i électronique,
él i édi i
édition
collaborative, etc.

9 Architecture logicielle distribué Mr JMAL


2) Transparence de la distribution
Transparence Description
Accès Cacher les différences entre la représentation et les mécanismes
d’invocation
Localisation Cacher où se trouve l’objet
Migration Cacher à un objet la capacité d’un système de changer sa
localisation (celle de l’objet)
Relocalisation Cacher à un client la capacité d’un système de changer la
l
localisation
li ti d’ d’un objet
bj t auquell lle client
li t estt lié
Réplication Cacher le fait qu’un objet ou son état pourrait être répliqué (copié)
et que cette réplique (copie) se trouve dans une autre localisation
Concurrence Cacher le fait qu’un objet peut être partagé par plusieurs
utilisateurs compétitifs.
Échec Cacher l’échec et la récupération éventuelle d’un objet
Persistance Ne pas savoir si un objet est en mémoire ou sur le disque dur
` Note:
` La
L transparence ded la
l distribution
di ib i est un objectif
bj if agréable,
é bl mais
i l’atteindre
l’ i d en
est une autre histoire.
10 Architecture logicielle distribué Mr JMAL
Degré de transparence
` Observation:
` Cibler une transparence totale de la distribution s’avère trop
demander:
` Les utilisateurs peuvent être localisé dans des continents différents
` Cacher complètement les échecs des réseaux et des nœuds est
théoriquement et pratiquement impossible.
impossible
` On ne peut pas distinguer un ordinateur lent d’un autre en échec
` On n’est jamais sûr qu’un serveur a déjà exécuté une opération juste avant son
plantage
l ou non.
` La transparence totale coûte en performance, risquant ainsi la
distribution du système
y
` Garder les caches web exactement à jour avec les serveur
` Mettre à jour immédiatement toutes les répliques d’une donnée modifiée

11 Architecture logicielle distribué Mr JMAL


3) Ouverture des systèmes distribués
` Système distribué ouvert:
` Être capable d’interagir avec des services fournis par d’autres
systèmes ouverts sans tenir compte de l’environnement sous-
j
jacent:
t
` Systèmes devant être conformes avec des interfaces bien définies
` Systèmes devant supporter la portabilité des applications
` Systèmes devant inter-opérer facilement
` Accomplir ll’ouverture
ouverture (Openness):
` Au moins, rendre le système distribué indépendant de
l’hétérogénéité
g de l’environnement sous-jacent:
j
` Matériel
` Plateformes
` Langages
12 Architecture logicielle distribué Mr JMAL
4) Scalability (passage à ll’échelle)
échelle)
` Observation:
` Plusieurs développeurs de système distribué utilisent l’adjectif
«scalable» sans dire pourquoi leur système l’est.
` Scalability:
` Au moins concernant trois aspects:
` Nombre d d’utilisateurs
utilisateurs et/ou de processus (taille)
` Distance maximale entre les nœuds (géographique)
` Nombre de domaines administratifs (administrative)
` Observation:
` La plupart des systèmes considèrent seulement la scalabilité en taille.
Î fausse solution: serveurs puissant.
` De nos jours, le défit se trouve dans la scalabilité géographique et
administrative
administrative.

13 Architecture logicielle distribué Mr JMAL


Techniques de scalabilité
` Modèle 1: Cacher les latences de communication:
` Éviter les attentes de réponses; faire autre chose:
` Utiliser les communications asynchrones
` Utiliser des récipients (processus) séparés pour les réponses entrantes
` Problème: pas toutes les applications pouvant satisfaire ce modèle.

14 Architecture logicielle distribué Mr JMAL


Techniques de scalabilité (suite)
` Modèle 2: distribution:
` Partitionner les données et les calculs (traitements) à travers
plusieurs machines, exemple:
` Déplacer les calculs chez les clients (ex.Applet
(ex Applet Java)
` Décentraliser les services de nommage (ex. DNS)
` Décentraliser les systèmes
y d’information

15 Architecture logicielle distribué Mr JMAL


Techniques de scalabilité (suite)
` Modèle 3: Réplication/caching
` Rendre des copies des données disponibles sur différentes
machines:
` Réplication
Ré l d serveurs de
des d fichier
f h et de d bases
b d données
de d é
` Miroirs de sites web
` Cache web (dans les navigateurs et/ou les proxy)
` Cache de fichier (sur les serveurs et les clients)
` Dans les réseaux,, redondances de liens pphysiques
y q entre routeurs et
Switchs et agrégation des liens.

16 Architecture logicielle distribué Mr JMAL


Scalabilité: le problème
` Observation:
` Appliquer les techniques est facile, excepté pour une chose:
` Avoir des copies multiple (cachées ou répliquées) mène à des
incohérences: modifier une copie rend une copie différente au reste des
copies
` Toujours maintenir les copies cohérentes requiert une synchronisation
globale
l b l à chaque
h modification
df
` La synchronisation globale limite les solutions large-scale

` Observation:
` Si on peut tolérer des incohérences,
incohérences on peut réduire le besoin d
d’une
une
synchronisation globale, mais tolérer des incohérences dépend des
applications

17 Architecture logicielle distribué Mr JMAL


Développer des systèmes distribués: Pièges
` Observation:
` Plusieurs systèmes distribués sont inutilement complexes à cause
d’erreurs devant être révisées auparavant.
` Il y a plusieurs fausses suppositions commises par les développeurs
de systèmes distribués:
` Le réseau est fiable
` Le réseau est sure
` Le réseau est homogène
` La topologie ne change pas
` Le délai d’attente est nul
` La bande passante est infinie
` Le coût du transport est zéro
` Il y a un seul administrateur

18 Architecture logicielle distribué Mr JMAL


Types des systèmes distribués

` 1) Systèmes de calcul distribués


` Distributed Computing Systems DCS
` 2) Systèmes d’information distribués
` Distributed Information Systems DIS
` 3) Systèmes pervasives distribués
` Distributed Pervasive Systems DPS

19 Architecture logicielle distribué Mr JMAL


1) Système de calcul distribué DCS
` Plusieurs systèmes distribués sont configuré pour un calcul de haute
performance.
performance
` Exemple de DCS:
` 1)) Grappe
pp de Calcul ((Cluster Computing):
p g)
` Essentiellement, un groupe de systèmes finaux connectés ensemble à
travers un LAN:
` Homogène:
H è même
ê OS matériel
OS, é i l identique
id i (é i l )
(équivalent)
` Un seul nœud gestionnaire

20 Architecture logicielle distribué Mr JMAL


1) DCS: Grid computing
` 2) Grille de calcul (Grid computing):
` Beaucoup de nœuds localisés partout dans le(s) réseau(x)
` Des nœuds Hétérogènes
` Dis ersés à travers
Dispersés tra ers plusieurs
l sie rs organisations
r anisati ns
` Peuvent facilement s’étendre à un WAN (Wide Area Network)

` Note:
` Pour
ou pe permettre
ett e laa co
collaboration,
abo at o , les
es ggrilles
es dee ca
calcul
cu ut utilisent
se t
généralement les organisations virtuelles. Il s’agit de groupement
d’utilisateurs autorisant l’allocation de leur ressources à la grille.

21 Architecture logicielle distribué Mr JMAL


1) DCS: Cloud computing
` 3) Cloud computing:
` Informatique en nuage (dans les nuages) ou dématérialisée
` Fait la distinction entre 4 niveaux:
` Hardware (Matériel): processeurs,
r cesse rs routeurs,
r te rs systèmes
s stèmes d’alimentation
d’alimentati n et
de refroidissement
` Infrastructure: déploiement de techniques de virtualisation. Évolue
autour de l’allocation et de la gestion des équipements virtuels de
stockage et des serveurs virtuels (ou machine virtuelles VM).
` Plateforme: fournie une abstraction de haut niveau pour le stockage et le
traitement. Exemple: le système de stockage Amazon S3 offre une API pour
stocker et organiser les fichiers à stocker.
` A li i
Application: application
l actuelles,
ll comme la
l suite MS Office,
Off O l
Oracle
(SGBD), messagerie.
` Avantage: payement à ll’utilisation
utilisation

22 Architecture logicielle distribué Mr JMAL


1) DCS: Cloud computing (suite)
` Cloud computing: IaaS, PaaS et SaaS

SaaS
S ft
Software as
a Service
PaaS
Platform as a
Service
IaaS
Infrastructure
as a Service

23 Architecture logicielle distribué Mr JMAL


2) Système d’information
d information distribué DIS
` La plupart des organisations ont des systèmes d’information distribués
riches
i h en applications
li i en réseaux:
é
` L’interopérabilité entre ses applications/traitement est difficile
` Exemple de DIS:
` 1) Système de traitement de transaction:
` Dans les applications utilisant les BD: une opération sur une BD est
réalisée sous forme d’une transaction

` Note:
` La transaction forme une
opération atomique

24 Architecture logicielle distribué Mr JMAL


2) DIS: Système de Traitement de transaction
` Modèle:
` Une transaction est une collection d’opérations sur l’état d’un objet (ex.
BD) satisfaisant les propriétés suivantes:
` Atomicity (Atomicité): Toutes les opérations doivent soit 1)réussir soit
2)échouer, toutes. Quand la transaction échoue, l’état de l’objet reste
inaffecté.
` Consistency (Cohérence): La transaction doit établir une transition d’état
valide durant son exécution, y compris l’état « invalide » ou « intermédiaire ».
` Isolation: Les transactions concurrentes ne doivent pas ss’interférer,
interférer, se
chevaucher.T1 et T2 concurrentes:T1 Avant T2 ou T1 Après T2.
` Durability (Durabilité): après l’exécution d’une transaction, ses effets
( h
(changements) ) sur l’objet
l’ bj sont permanents.

` Ces propriétés sont souvent désignées par ACID

25 Architecture logicielle distribué Mr JMAL


2) DIS: Moniteur de traitement de transaction
` Observation:
` Dans plusieurs cas, la donnée impliquée dans une transaction est
répartie à travers plusieurs serveurs.
` Un moniteur de traitement de transaction (TP Monitor) est
responsable de la coordination de son exécution.

26 Architecture logicielle distribué Mr JMAL


2) DIS: Intégration d’Application
d Application Entreprise
` 2) Intégration d’Application Entreprise:
` Les apps sont devenues plus sophistiquées et séparées en composants
indépendant (séparation BD/traitement).
` Besoin d
d’intégration:
intégration: communication directe entre application

` Solution:
` Middleware de
communication:
` Remote Procedure Call
(RPC)
` M
Message-Oriented
O d
Middleware (MOM)
BD BD BD

27 Architecture logicielle distribué Mr JMAL


3) Système distribué pervasive DPS
` Nouvelle génération de systèmes distribués dans lesquels des nœuds
sont petits,
i mobiles,
bil et souvent embarqués.
b é
` Quelques besoins:
` Changement du contexte: le système fait part d d’un
un environnement dont
les modifications d’état doivent être prises en compte.
` Composition Ad-hoc: chaque nœud peut être utilisé de manière différente
par différents utilisateurs. besoin de configuration facile.
` Partage par défaut: les nœuds viennent et partent, fournissant des services
et informations partageable.
` Trois type de DPS:
` Ubiquitous
q computing
p g system:
y Home system,
y smart system
y
` Mobile computing system: Mobile Health care system, Location-based
service.
` S
Sensor network
t k (réseau
(é d capteurs):
de t ) météorologie,
été l i guerre, etc.
t

28 Architecture logicielle distribué Mr JMAL


3) DPS: Ubiquitous computing system
` Caractéristiques:
` Distribution: des équipements en réseau, distribués, et accessibles
d’une manière transparente.
` Interaction: ll’interaction
interaction entre les utilisateurs et les équipements
n’est pas discrète
` Context awareness: le système est conscient/sensible au contexte
de l’utilisateur afin d’optimiser l’interaction.
` Autonomie: les équipements agissent d’une façon autonome sans
l’intervention humaine, et sont ainsi auto-gérable
` Intelligence: le système dans l’ensemble peut accomplir un large
spectre d’actions et d’interactionsÎ prise de décision.
décision

29 Architecture logicielle distribué Mr JMAL


3) DPS: Mobile computing systems
` Ils sont considérés généralement comme un sous-ensemble des UCS
et héritent
hé i d leurs
de l 5 caractéristiques.
éi i
` Caractéristiques typiques:
` Plusieurs types dd’équipements
équipements mobiles: smart phones,
phones télécommandes,
télécommandes
capteurs mobiles, équipements auto, etc.
` Communication sans fil: réseau adad-hoc
hoc
` Équipements avec localisation variable au cours du temps:
` Établir une route entre les équipements
q p ppeut être critique
q ((à cause
des changement de routes)
` Problème d’équipements déconnectés souvent rencontré:
Î problème d’interruption de service (problématique de handover).

30 Architecture logicielle distribué Mr JMAL


3) DPS: Sensor network
` Caractéristiques:
` les nœuds auxquels les capteurs sont liés sont:
` Nombreux (10 – 1000 ou plus)
` Sim le: petite
Simple: etite mémoire,
mém ire petite
etite capacité
ca acité de calcul,
calc l de communication
c mm nicati n
` Souvent alimenté par des batteries (ou même sans batterie)
` Comment organiser une BD de réseau de capteur tout en stockant et
traitant les données:
` a) au niveau du site opérateur b) au niveau des capteurs

31 Architecture logicielle distribué Mr JMAL


Plan
` I) Introduction
` II) Architecture
` III) Processus
` IV) Communication
` V) Synchronisation
` VI) Consistance et réplication
` VII) Système distribué orienté objet
` VIII) Système de fichier distribué
` IX)) Système
y distribué orienté service
` X) Système distribué orienté coordination

32 Architecture logicielle distribué Mr JMAL


Architecture

` 1) Styles architecturaux
` 2) Architecture système
` 3) Architecture vs. Middleware
` 4) Autogestion dans les systèmes distribués

33 Architecture logicielle distribué Mr JMAL


Architecture: définition 1
` Architecture Logicielle (Software):
` Un système distribué est composé de plusieurs composants logiciels
` L’architecture logicielle décrit l’organisation et l’interaction entre ces
composants logiciels.
logiciels
` L’adoption d’une architecture est devenu crucial pour la réussite du
développement d d’un
un Système Distribué.
` Î Style architectural.

34 Architecture logicielle distribué Mr JMAL


Architecture: définition 2
` Architecture système:
` La réalisation d’un système distribué requiert l’instanciation ensuite
l’emplacement des composants logiciels sur des machines réelles
` LL’architecture
architecture système décrit donc ll’emplacement
emplacement des composants
logiciels sur les machines physiques.
` La réalisation dd’une
une architecture peut être:
` Centralisée
` Décentralisée
` Hybride

35 Architecture logicielle distribué Mr JMAL


Style architectural
` Style architectural: décrit une façon particulière de configuration
d’
d’une collection
ll i de d composants et ded connecteurs:
` Composant: c’est un module logiciel avec des interfaces bien
définies, réutilisable et remplaçable.
remplaçable
` Connecteur: c’est le lien de communication, coopération ou de
coordination entre les composants. Ex. message envoyé, flux de
données, RPC Remote Procedure Call (invocation de procédure à
distance).

Connecteur Composant Connecteur

Composant Composant
C
Connecteur

36 Architecture logicielle distribué Mr JMAL


Style architectural
` Les styles d’architecture les plus adaptés aux systèmes distribués:
` 1) Layered Architectures LA: architecture en couche
` 2) Object-Based Architectures OBA: architecture orientée objet
` 3) Data-Centered Architectures DCA: architecture orientée donnée
` 4) Event-Based Architectures EBA: architecture orientée événement

37 Architecture logicielle distribué Mr JMAL


1) LA: architecture en couche
` Idée de base: Les composants sont organisés logiquement sous forme
d couches.
de h
` Un composant de la couche Li est autorisé d’appeler un autre
composant de la couche inférieure Li-1
i 1. le contraire est interdit.
interdit
` Les requêtes vont de haut en bas, les réponses, inversement.

` Style largement adopté par la


communauté réseau ((modèle OSI,,
TCP/IP).
` Ce style
y est utilisé aussi ppour les
systèmes client/serveur

38 Architecture logicielle distribué Mr JMAL


2) OBA: Architecture orientée objet
` Idée de base:
` Ch
Chaque composant correspond d à un objet.
bj
` Chaque connecteur correspond à un mécanisme d’invocation de
procédure ((à distance).
p )
` Les connecteurs peuvent lier
n’importe quel objet à n’importe
quel objet.

` SStyle
l utilisé
ili é aussii largement
l par les
l
systèmes client/serveur
` LA et OBA représentent les plus
important styles pour les grands
y
système logiciel.
g

39 Architecture logicielle distribué Mr JMAL


3) DCA: architecture orientée donnée
` Idée de base: Les composants utilisent des processus qui communiquent
à travers un entrepôt
ô de
d données
d é commun/partagé
/ é (actif
( if ou passif)
if)
` Cet entrepôt peut être de simple fichiers, système partagé, une base de
données etc.
données, etc
` Un composant peut publier (modifier) une donnée, souscrire à une
donnée et en être muni lors de sa modification

` Les systèmes distribués web


sont largement orientés données:
communication à travers
l’utilisation de données partagées
sur le web.

40 Architecture logicielle distribué Mr JMAL


4) EBA: architecture orientée événement
` Idée de base: Les composants utilisent des processus qui communiquent
en se basant sur la propagation des événements à travers bus spécial.
spécial
` Les événements peuvent transporter des données.
` La ppropagation
p g des événements est souvent associée au systèmey
publish/subscribe (publier/s’abonner)
` Les processus sont dit librement ou légèrement couplés
` L notifications
Les f sont fournies
f seulement
l au composants qui y sont
abonnés.

` Ex: Bus Ivy: un bus logiciel qui


permet d'envoyer des messages
textes entre applications
l
` Développé par le Centre d'études
de la navigation aérienne française

41 Architecture logicielle distribué Mr JMAL


Architecture système: 1) Centralisée
` Modèle Client-Serveur basique
` Caractéristiques:
` Des processus offrant des services spécifiques: Serveurs
` Des processus qui utilisent ces services: Clients
` Les clients et les serveurs sont sur des machines différentes
` L clients
Les li suivent
i l modèle
le dèl « requête/réponse
ê /é » pour l’utilisation
l’ ili i
des services.

Client1

Client2

Client3 Server

Clientn

42 Architecture logicielle distribué Mr JMAL


1) Centralisée: Application en couche
` Vue traditionnelle en trois couches:
` IInterface
f utilisateur:
ili contient
i d unités
des i é pour l’interface
l’i f d’
d’une A (graphique)
App ( hi )
` Traitement: contient les fonctions de l’application, sans données
` Donnée: contient les données qque l’utilisateur veut manipuler
p à travers l’App
pp
` Cette répartition en couche existe dans plusieurs DIS en utilisant les techno de
base de données avec les applications concernées

43 Architecture logicielle distribué Mr JMAL


1) Centralisée: architectures N-tiers
N tiers
` 3 couches Î suggère plusieurs possibilités pour la distribution physique,
principalement 2-tiers:
2 tiers:
` Une machine client: implémentant la couche interface utilisateur.
` Une machine serveur: implémentant les couches traitement et donnée.
` Plusieurs variantes de ce type de distribution peuvent exister:
` Selon la distribution des parties composant chacune des 3 couches sur les deux
machines (client ou serveur).
serveur)

44 Architecture logicielle distribué Mr JMAL


1) Centralisée: architectures N-tiers
N tiers
` 1-tiers: tout sur la même machine
` 2-tiers: une machine pour le client et une machine pour le serveur
(traitement et donnée)
` 3 tiers: chaque couche sur une machine
3-tiers:
` N-tiers: un client sur une machine, un serveur sur une autre
machine, mais le serveur peut être un client d
d’un
un autre serveur, etc.

45 Architecture logicielle distribué Mr JMAL


2) Architecture décentralisée
` Les architectures client/serveur N-tiers sont la conséquence directe
d la
de l division
di i i d’un
d’ système
è en 3 couches:
h
` User Interface, processus et données
` Î Distribution verticale: placement logique de différents composants
(fonctionnels) sur différentes machines.
` Les entités sur les machines différentes ne sont pas équivalentes (d’un
point de vue fonctionnel): client d’un coté, serveur d’un autre
` Distribution horizontale: entités équivalentes sur des machines
différentes: système paire-à-paire
paire à paire (Peer to Peer) P2P:
` Chaque entité/nœud agit comme client et serveur en même temps: servent
` La communication entre les processus de ces entités/nœuds est symétrique

46 Architecture logicielle distribué Mr JMAL


2) Architecture décentralisée
` L’organisation de ces nœuds forme un réseau superposé de
communication:
i i
` Système P2P structuré: nœuds organisés selon une structure de donnée
distribuée bien spécifique
p q
` Système P2P non-structuré: nœuds organisés au hasard
` Système P2P hybride: quelques nœuds sont sélectionnés selon une
manière
iè bien
bi organisée
i é (super-peer)
( )
` Dans tous les cas (généralement), il s’agit de réseaux superposés où
les données sont routées à travers des connections établies entre
les nœuds (multicast applicatif)

47 Architecture logicielle distribué Mr JMAL


2) Système P2P structuré
` Nœuds organisés sous forme d’un réseau superposé selon une
procédure
éd dé
déterministe:
i i
` Un anneau logique, hyper-cube logique
` DHT Distributed Hash Table
` Le système fournie une opération de recherche lookup(key) qui va
router efficacement la requête de recherche vers le nœud concerné.

Chord system
48 Architecture logicielle distribué Mr JMAL
2) Système P2P structuré: DHT
` Distributed Hash Table DHT: table de hachage distribuée
` une technologie permettant l'identification et l'obtention d'une information
dans un système réparti, comme certains réseaux P2P.
` LL'ensemble
ensemble de la table de hachage est constituée virtuellement par tous ses
constituants distribués sur tous les éléments du réseau, qui en possèdent
chacun une partie.
` LLa DHT permet d’éviter
d’é i d’ i un serveur centralisé
d’avoir li é quii contient
i un
répertoire géant contenant la liste de toutes les données ainsi que leurs
emplacements.
p Ce répertoire
p ne ppeut ppas être installé en entier sur
chaque nœud.
` Fonctionnement : Un pair veut publier/retrouver une donnée v,
caractérisée par une clé k:
` Il calcule l’adresse du pair qui doit stocker v, à l’aide de la fonction de
hachage h (la même pour tous les pairs) appliquée à k
` Il se connecte au pair cible pour transférer/récupérer la donnée v.
49 Architecture logicielle distribué Mr JMAL
2) Système P2P non-structuré
non structuré
` Dans un système P2P non-structuré, les nœuds sont organisé d’une
f
façon aléatoire.
lé i
` Chaque nœud maintient la liste de ses voisins: vue partielle du réseau.
` Chaque nœud P sélectionne un nœud Q de sa vue partielle
` P et Q échangent des informations et échangent leurs vues partielles
respectives

` L’opération de recherche d’information lookup(key) ne se fait plus d’une


façon déterministe,
déterministe mais elle se fait d
d’une
une autre façon:
` 1) par inondation
` 2) par une marche aléatoire

50 Architecture logicielle distribué Mr JMAL


Recherche non structurée
` Inondation (Flooding):
` 1) nœud u envoi une requête de recherche à tous ses voisins.
` 2) Un voisin répond ou transmet cette requête à ses voisins.
` Variations possible:
` Inondation limitée: préciser le nombre max de transfert (TTL) de
requête de recherche.
` Inondation probabilistique: transférer seulement avec une certaine
probabilité.
` M h aléatoire
Marche lé t i (Random
(R d Walk):
W lk)
` 1) u sélectionne aléatoirement un voisin v de sa vue partielle.
` 2) sii v a la
l réponse,
é alors
l il répond,
é d sinon,
i v sélectionne
él ti aléatoirement
lé t i t
un autre voisin.
` Variation: Marche aléatoire parallèle: fonctionne efficacement avec
les données répliquées.
51 Architecture logicielle distribué Mr JMAL
Super nœud
Super-nœud
` Parfois, il est plus utile de sélectionner certains nœuds pour faire un
travailil spécifique:
é ifi ce sont les
l super-nœuds
d (superpeers)
( )
` Exemples:
` Nœuds qui maintiennent les indexes (utile pour la recherche)
` Nœuds contrôlant l’état du réseaux
` Nœuds capable
p d’installer les connexions de nouveaux nœuds au réseau

52 Architecture logicielle distribué Mr JMAL


3) Architecture hybride
` Une combinaison d’une architecture client/serveur et de P2P.
` 1) Système de serveur de bord (Edge-server System):
` Souvent utilisé pour les CDN (Content Delivery Network)
` 2) Système distribué collaborative: exemple BitTorrent
` Système P2P de téléchargement de fichier
` 3) Skype:

53 Architecture logicielle distribué Mr JMAL


Plan
` I) Introduction
` II) Architecture
` III) Processus
` IV) Communication
` V) Synchronisation
` VI) Consistance et réplication
` VII) Système distribué orienté objet
` VIII) Système de fichier distribué
` IX)) Système
y distribué orienté service
` X) Système distribué orienté coordination

54 Architecture logicielle distribué Mr JMAL


Introduction au thread
` Processeur: fournit un ensemble d’instructions avec la capacité
d’ é
d’exécuter automatiquement
i une série
é i de
d ces instructions
i i
` Processus: c’est un processeur logiciel, la gestion des processus dans
un système dd’exploitation
exploitation permet ll’ordonnancement
ordonnancement des tâches.
tâches
` Thread: c’est un processus miniature avec un contexte dans lequel
une série d’instruction peuvent être exécutée.
` Enregistrer un contexte du thread implique arrêter son exécution actuelle
et enregistrer toutes les données requises au redémarrage de l’exécution
du thread.
thread
` Î chaque processus est constitué d’un ou plusieurs thread.
` La création et la destruction des threads est moins couteuse
(performance) que pour les processus.

55 Architecture logicielle distribué Mr JMAL


Concept du thread
` L’introduction des threads dans un système amène de nombreux avantages,
mais introduit aussi certains problèmes.
problèmes
` Concept du thread:
` C’est un sous-processus,
p il est dépendant
p du pprocessus
` Il permet le parallélisme, la combinaison parallélisme/séquentiel
` Ne nécessite pas un nouvel espace d’adressage (celui de son processus)
` S exécution
Son é ti estt séquentielle.
é ti ll
` Il existe 3 modèles pour les multi-thread:

Sy

Sy
Sy

Thread Thread Thread

ystème

ystème
ystème

Processus Processus Processus

Thread spécialisé
avec file d’attente
d attente

Queue de demande Queue de demande Queue de demande

Répartiteur / travailleur Le groupe ou équipe La pipeline

56 Architecture logicielle distribué Mr JMAL


Changement de contexte
` Contexte du processeur: collection minimale de valeurs stockées dans
l registres
les i d’
d’un processeur utilisées
ili é pour l’exécution
l’ é i d’
d’une série
éi
d’instruction (registre d’adresse, compteur de programme…)
` Contexte du processus: collection minimale de valeurs stockées dans les
registres et la mémoire utilisées pour l’exécution d’une série
d’instruction (ex. contexte du processeur, état)
` Contexte du thread: collection minimale de valeurs stockées dans les
registres et la mémoire utilisées pour l’exécution d’un thread (ex.
contexte du thread)
` Le changement du contexte d’un processus est généralement plus
coûtant car il requiert
q l’implication
p du système
y d’exploitation
p SE ((le
noyau).
` Le changement du contexte d’un thread peut être fait entièrement
indépendamment du SE.
57 Architecture logicielle distribué Mr JMAL
Thread et systèmes distribués
` Client web multithread (navigateur):
` Permet de cacher les latences du réseaux (délais):
` Le navigateur scanne la page HTML téléchargé et trouve que d’autres fichiers
doivent être téléchargés.
téléchargés
` Chaque fichier est téléchargé par un thread séparé, chacun fait une requête
HTTP bloquante.
` Au fur et à mesure que les fichiers se téléchargent, le navigateur les affiches.
` Appel de requête/réponse multiple à d’autres machine (RPC)
` Un client
U li f i plusieurs
fait l i appels
l en même
ê temps, chacun
h par un thread
h d séparé.
é é
` Il attend ensuite que tous les résultats soient retournés.
` Note: si les appels se font vers différents serveurs,
serveurs on peut avoir une
accélération linéaire.

58 Architecture logicielle distribué Mr JMAL


Thread et systèmes distribués (Suite)
` Amélioration des performances:
` Le démarrage d’un thread est moins cher qu’un nouveau processus.
` Avoir un serveur mono-thread limite son déploiement à échelle réelle.
` Cacher les latences réseau en réagissant à la prochaine requête alors que la
précédente est en cours de traitement.
` Meilleur structure: Thread Thread
répartiteur
é tit T
Travailleur
ill
` La plupart des serveurs ont une Processus Serveur
grande demande en I/O. Utiliser des
appels bloquants bien faits
simplifieront la structure générale
` Les programmes multithread Operating System
Requête
tendent à être petit et facile à entrante
comprendre grâce à son flux de control simplifié

59 Architecture logicielle distribué Mr JMAL


Virtualisation de système
` La virtualisation est «l’ensemble des technologies matérielles
et/ou
/ logicielles qui permettent de faire
f f
fonctionner sur une
seule machine physique plusieurs systèmes d’exploitation et/ou
plusieurs applications,
applications séparément les uns des autres,
autres comme
s’ils fonctionnaient sur des machines physiques distinctes».
` La virtualisation consiste à intercaler une couche dd’abstraction
abstraction
entre un client et un fournisseur au sens large du terme.

60 Architecture logicielle distribué Mr JMAL


Historique
` Les débuts de la virtualisation remontent au milieu des années 60
sur la
l plate-forme
l f d superordinateurs
de di ( i f
(mainframe)) d’IBM
` les machines virtuelles étaient appelées des pseudo-machines.
` 1974: Les chercheurs Gerald J.J Popek et Robert P.P Goldberg,
Goldberg ont
posé les bases de la virtualisation dans leur article «Formal
Requirements for Virtualizable Third Generation Architectures»,
publié dans Communications of the ACM en juillet 1974.
` 1998: Naissance de Vmware
` 1999:VMware
1999 VM W k i 10
Workstation1.0
` 2001: hyperviseur ESX .
` 2008: Microsoft lance son hyperviseur Hyper-V pour tenter de
contrer la position dominante de VMware sur le marché de la
virtualisation.

61 Architecture logicielle distribué Mr JMAL


Définition formelle
` La virtualisation permet d’exécuter plusieurs systèmes
d’ l i i sur un seull ordinateur
d’exploitation di
` Chaque système d’exploitation « invité » est installé dans une machine
virtuelle (VM).
( )
` La virtualisation permet ainsi de « détacher » la VM de toutes
dépendances de son « hôte »
` Donc cette définition "formelle"
" " de la virtualisation fait référence à
l’abstraction physique des ressources informatiques. En d’autres
termes, les ressources physiques allouées à une VM sont abstraites à
partir de leurs équivalents physiques: on parle de disques virtuels,
interfaces réseau virtuelles, réseaux locaux virtuels, commutateurs
virtuels,
i l processeurs virtuels,
i l mémoire
é i virtuelle…
i ll
` Il existe de nombreux types de virtualisation: d’application, de plate-
forme de réseau,
forme, réseau de stockage…
stockage

62 Architecture logicielle distribué Mr JMAL


Virtualisation et Machine Virtuelle VM
` La virtualisation est devenu de plus en plus importante:
` Le matériels change plus rapidement que les logiciels.
` Facilité de la portabilité et de la migration de code.
` Isolation des composants échoués ou attaqués (contaminé par virus).
virus)
` La virtualisation consiste à faire fonctionner sur un seul ordinateur
plusieurs OS comme s’ils fonctionnaient sur des ordinateurs distincts.
p

63 Architecture logicielle distribué Mr JMAL


Motivation de la virtualisation
` 1) Consolidation des serveurs et optimisation de l’infrastructure: La
virtualisation
i li i permet d’accroître
d’ î considérablement
idé bl l taux d’utilisation
le d’ ili i
des ressources en regroupant des ressources communes et en sortant
du schéma «une application
pp = un serveur ».

64 Architecture logicielle distribué Mr JMAL


Motivation de la virtualisation (suite)
` 2) Réduction des coûts: on peut réduire le nombre de serveurs et la
quantité de matériel informatique nécessaire Æ diminution des frais
immobiliers et des besoins en alimentation et en ventilation.
` 3) Augmentation de la flexibilité et de l’efficacité: nouvelle manière de
gérer l’infrastructure informatique et peut aider les administrateurs
informatiques à consacrer moins de temps aux tâches répétitives, telles
que le pprovisionnement, la surveillance et la maintenance.
q
` 4. Disponibilité accrue des applications et amélioration de la continuité
d’activité: rétablissement rapide de service en cas d’interruptions non
programmées Sauvegarde et déplacement en toute sécurité des
programmées.
environnements virtuels entiers sans interrompre le service.
` 5) Amélioration de la gestion et de la sécurité des postes de travail:
Déploiement, gestion et surveillance des environnements de postes de
travail sécurisés auxquels les utilisateurs finaux peuvent accéder
localement ou à distance, avec ou sans connexion réseau, à ppartir de
presque tous les ordinateurs de bureau, portables ou de poche.
65 Architecture logicielle distribué Mr JMAL
Architecture de la virtualisation
` La virtualisation peut se réaliser sur différents niveaux dans un système
i f
informatique:
i
` Interface entre hardware et software: instructions machines
` Interface entre hardware et software: instructions machines invoquées par
des processus privilégiés comme des processus du SE
` Interface des appels système offerts par un SE
` La virtualisation est fortement dépendante des interfaces offerte par les
différents composants du système.

66 Architecture logicielle distribué Mr JMAL


Processus de VM vs Moniteur de VM
` Processus VM: un programme est compilé sous forme de code portable, qui
sera exécuté ensuite par le système runtime (ex.
(ex JVM)
` Moniteur VM: une couche logicielle séparée imitant l’ensemble des
instructions matériels Î un SE complet et ses applications pourront être
supportés (ex.Vmware,VirtualBox).

a) Processus VM avec plusieurs instances b) Moniteur de VM avec plusieurs


de systèmes runtime et d’applications
’ instances de SE et d’applications
d applications

67 Architecture logicielle distribué Mr JMAL


La virtualisation de serveur
` La virtualisation des systèmes permet à plusieurs instances de
systèmes dd’exploitation
exploitation (OS) de ss’exécuter
exécuter simultanément sur un
seul hôte physique.
` Chaque OS s’exécute sur une MV (appelé des fois ordinateur virtuel) et
f
fonctionne
i comme s’il
’il était
é i sur un ordinateur
di physique.
h i
` Avec la virtualisation, l’OS invité accède à l’architecture matérielle
par l’intermédiaire d’un noyau
p y système
y très léger
g nommé
hyperviseur.
` L’hyperviseur agit comme un arbitre entre les systèmes invités. Il
attribue du temps processeur et des ressources à chacun,
chacun redirige
les requêtes d’entrées/sorties vers les ressources physiques, veille au
confinement des invités dans leurs propres espaces.
` Il existe deux types d’hyperviseur:
` Hyperviseur de type 1
` Hyperviseur de type 2

68 Architecture logicielle distribué Mr JMAL


Notions de base

Sys Sys Sys Systèmes virtualisés exécutés par


invité invité invité l’hyperviseur

Système / configuration gérant les


Hyperviseur interactions des machines virtuelles avec le
matériel physique

Système hôte Système accueillant l’hyperviseur sur la


machine physique qui va « virtualiser » un
Matériel ou plusieurs autres systèmes

Rq: Dans la plupart des cas, l’hyperviseur et le système hôte sont


« fusionnés »

69 Architecture logicielle distribué Mr JMAL


Différentes techniques de virtualisation
` On distingue 3 catégories de solutions de virtualisation:
` L’isolation ou cloisonnement :
` Séparation forte entre différents contextes logiciels sur un même noyau de
ll’OS
OS (ressemble au principe de session par utilisateur).
utilisateur)
` La virtualisation complète (hyperviseur de type 2):
` Utilisation d’un noyau
y hôte légerg au dessus de l’OS hôte p
permettant de faire
tourner des systèmes d’exploitations natifs.
` La virtualisation est dite complète lorsque l’OS invité n'a pas conscience
d'être
d être virtualisé.
virtualisé Il n
n'aa donc pas besoin d
d'être
être adapté.
adapté
` La para-virtualisation (hyperviseur de type 1):
` La para
para-virtualisation
virtualisation évite dd'utiliser
utiliser un OS hôte complet pour faire la
virtualisation.A la place, un noyau très léger de l’OS hôte est utilisé.
` L’OS invité a conscience d’être virtualisé donc il doit être adapté.
` Les performances sont bien meilleures en para-virtualisation qu'en
virtualisation complète.
70 Architecture logicielle distribué Mr JMAL
Virtualisation: avantages/inconvénients
` Avantages:
` Meilleur utilisation du matériel
` Indépendance du matériel:
` Séparation
Sé i ded l’évolution
l’é l i du d matériel/logiciel
é i l/l i i l
` Virtualisation des systèmes obsolètes
` Isolation: sécurité
` Clonage: copie de sauvegarde, test avant production
` Migration: transfert à chaud (enregistrement de ll’état
état d
d’exécution)
exécution)
` Inconvénients:
` Performances: partage de ressources Æ dégradation
` Disponibilité: panne serveur Æ arrêt de plusieurs VM
` Administration:
` Multiplication des serveurs (virtuels) Æ nouveaux outils d’admin
71 Architecture logicielle distribué Mr JMAL
Autres point à étudier
` Code mobile, migration de code

72 Architecture logicielle distribué Mr JMAL


Plan
` I) Introduction
` II) Architecture
` III) Processus
` IV) Communication
` V) Synchronisation
` VI) Consistance et réplication
` VII) Système distribué orienté objet
` VIII) Système de fichier distribué
` IX)) Système
y distribué orienté service
` X) Système distribué orienté coordination

73 Architecture logicielle distribué Mr JMAL


Communication

` 1) Fondamentaux: communication réseau


` 2) Remote procedure Call (RPC)
` 3) Message-Oriented Middleware (MOM)
` 4) Data
D streaming
i

74 Architecture logicielle distribué Mr JMAL


1) Fondamentaux: Modèle OSI
` Modèle standard pour faciliter la communication entre système.
` Indépendance des couches Æ problématiques différentes
` Communication basée seulement sur des messages

Applications distribuées

Couche Middleware

Couche Transport

Couches Basses

75 Architecture logicielle distribué Mr JMAL


Couche transport
` La couche transport fournie les moyens de transport actuels pour la
plupart
l d systèmes
des è di ib é
distribués
` Plusieurs protocoles de transport:
` Transmission Control Protocol TCP: orienté-connexion,
orienté connexion fiable et
communication à base de flux.
` Universal Datagram Protocol UDP: communication non-fiable (best-
effort).
` Real-time Transport Protocol RTP: basé sur UDP, utilisé pour le transfert
de données en temps réel (Voix sur IP,Vidéo conférence, etc.)

76 Architecture logicielle distribué Mr JMAL


Couche middleware
` Le Middleware est créé pour fournir un ensemble de services et
protocoles
l quii peuvent être
ê utilisés
ili é par plusieurs
l i applications.
li i
` Peut être vu comme service intermédiaire distribué dans la
communication applicative (niveau application)
` Un middleware propose:
` Un riche ensemble de p protocoles de communication
` Pliage/dépliage (Marshaling, sérialisation) de données
` Protocoles de nommage pour faciliter le partage de ressources
` Protocoles de sécurité pour protéger les communication
` Mécanismes de scalabilité comme la réplication ou le caching
` Ce quii reste
C t estt considéré
idé é comme desd protocoles
t l spécifiques
é ifi selon
l
les besoins de l’application distribuée qui le requiert.

77 Architecture logicielle distribué Mr JMAL


Types de communication

ddleware
Mid
` Persistance:
` C
Communication
i i persistante:
i l message est stocké
le ké dans
d l middleware
le iddl
tant qu’il n’est pas délivré (récepteur pas actif)
` Communication transitoire ((éphémère):
p ) le middleware supprime
pp le
message si le récepteur n’est pas actif au moment de l’envoi.
78 Architecture logicielle distribué Mr JMAL
Types de communication (2)
` Synchronisation:
` Communication asynchrone: l’émetteur continue son exécution
immédiatement après avoir soumis son message
` Communication synchrone: ll’émetteur
émetteur est bloqué jusqu
jusqu’àà ce qu
qu’ilil soit
notifié de l’acceptation de sa requête.
` Au moment de la soumission de la requête
q
` Au moment de la livraison de la requête
` Après le traitement de la requête
` Discrétion:
` Communication discrète: communication à l’aide de message formant
une unité
ité complète
lèt de
d données
d é
` Communication streaming: la communication implique l’envoi de
plusieurs messages ordonnés dans le temps ou par leur rang.
rang

79 Architecture logicielle distribué Mr JMAL


2) Remote procedure Call (RPC)
` Appel de procédure à distance
` Objectif: rendre les systèmes distribués comme un seul logiciel local.
` Permet à des services distant d’être invoqué comme des procédure:
` Transparence de
T d localisation,
l li i
` Transparence d’implémentation du serveur,
` Langage de programmation.
programmation
` Cacher la communication réseau entre l’appelant et l’appelé

80 Architecture logicielle distribué Mr JMAL


2) Remote procedure Call (RPC): Principe
public class ProgramCalculMain{
public static void main(String[] args) {
Calculator calcul= new Calculator();
int somme = calcul.add(5,5);
}
}

Machine
Package

ProgramCalculMain Remote Calculator


Procedure Call int add(int a, int b)
Void main()
int multiply(int a, int b)

Machine 1 Résea
Réseau Machine 2

81 Architecture logicielle distribué Mr JMAL


Mode réalisation de RPC
` Il existe plusieurs approche pour la réalisation du RPC:
` 1) Approche par migration:
` Migration du code et des données de la procédure distante, amenés sur le
site client pour y être exécutés
` 2) Approche par mémoire partagée:
` La p
procédure est installée dans une mémoire p
partagée
g répartie
p ((réellement
sur le serveur)
` 3) Par appel léger (lightweight RPC):
` Client et serveur sur la même machine (deux processus locaux) Æ inutile
de passer par la couche réseau et transport: utilisation de segment de
mémoire partagé
p g
` 4) Par messages:
` Deux messages à échanger entre client et serveur: requête et réponse

82 Architecture logicielle distribué Mr JMAL


Réalisation RPC par messages: Principe
public class ProgramCalculMain{
public static void main(String[] args) {
Calculator calcul= new Calculator();
int somme = calcul.add(5,5); } }

Code Machine 1 Machine 2 Code


client serveur
Client (appelant) Serveur (appelé)
Exécution
Résultat Appel RPC Appel local Résultat

Souche Souche
client Déballage
g Emballage appel Déballage Emballage serveur
résultats Envoi (proc., Requête résultat
param.)
Réponse Requête Requête Réponse Module
Module comm.
comm. serveur
client Envoi message Réception message
Réception message Envoi message
Réseau

83 Architecture logicielle distribué Mr JMAL


Réalisation RPC par messages
` Très nombreuse terminologie dans ce cas :
` Souches (Stubs),Talons, Squelettes (Skeletons)
` C’est le premier modèle RPC implémenté
` Il supporte l’hétérogénéité
l’hé é é éi é des
d langages
l d programmation
de i
` Mode supporté de transmission d’argument: transmission par valeur
` Définir une syntaxe abstraite des données échangées:
` facile à générer pour un développeur d’application
` Utile pour générer les souches client et serveur automatiquement
` les souches fabriquent la syntaxe de transfert en réalisant l’alignement
(emballage/déballage) des paramètres dans les messages.
` Définition de langages de syntaxe abstraite adaptés aux appels de
procédure distante : ‘Interface Definition Language’ (IDL)

84 Architecture logicielle distribué Mr JMAL


IDL: Interface Description Language
` La définition d’une interface RPC spécifie les caractéristiques des
procédures
éd f
fournies
i par une serveur visible
i ibl pour des
d clients
li
` Une interface contient la liste des signature des procédure:
` Nom de la procédure
` Noms et Types de chacun de ses arguments (paramètres)
` Chaque
q argument
g peut être spécifié
p p comme pparamètre d’entrée, sortie
ou entrée/sortie
` Compilateur d’interface: Conçu pour produire des composants
pouvantt être
êt combinés
bi é avec les
l programmes client
li t ett serveurs
` Composants générés:
` Souche client,
client souche serveur,
serveur opération d
d’emballage
emballage et de déballage,
déballage etc.
etc

85 Architecture logicielle distribué Mr JMAL


Exemple de compilation IDL
Interface definition

Client Server
IDL Compliler
Sk l
Skeleton Sk l
Skeleton

Cl
Client code
d Cl
Client stub
b H d file
Header fl S
Server stubb S
Server code
d

Language Language
Compliler Compliler

Client Server
application application

86 Architecture logicielle distribué Mr JMAL


Exemple
public class ProgramCalculMain{
public static void main(String[] args) {
Calculator calcul= new Calculator();
int somme = calcul.add(5,5); } }

import java.rmi.*;
public interface Calculator extends Remote {
public int add(int a, int b) throws RemoteException;
public int sub(int a, int b) throws RemoteException;
public int mul(int a, int b) throws RemoteException;
public int div(int a, int b) throws RemoteException;
}

87 Architecture logicielle distribué Mr JMAL


Exemples d’IDL
d IDL et de format RPC
` SUN ONC/RPC
` XDR eXternal
Xt l Data
D t Representation
R t ti
` OSF DCE
` IDL DCE - Format NDR Network Data Representation
p
` OMG CORBA
` IDL Corba - Format CDR Common Data Representation, Protocole
IIOP
` SUN Java RMI
` Langage
g g JJava - Protocole JJRMP JJava Remote Method Protocol
` Microsoft – DCOM
` MIDL Microsoft IDL - DCOM Protocole ORPC Object RPC Format
NDR
` WS-SOAP
` WSDL Web Services Definition Language
g g - XML

88 Architecture logicielle distribué Mr JMAL