Ce cours introduit les systèmes répartis. Il met l'accent sur les propriétés, les problèmes et les modèles de répartition.

1. SYSTÈMES RÉPARTIS
heithem.abbes@gmail.com2015-16

2. Introduction au systèmes
répartis

3. Système centralisé
4
 Tout est localisé sur la même machine
 1 processeur : une horloge commune
 1 mémoire centrale : un espace d’adressage
commun
 1 système d’exploitation
 Gestion centralisée des ressources
 Etat global du système facilement reconstiuable
 Accès local aux ressources

4. Emergence du réparti
 Evolution technologique
 machines
 de plus en plus performantes avec une baisse des
prix
 Équipement réseau
 de plus en plus rapides
5
 Regroupement des machines
 Puissance de calcul et de stockage
 Moins de centralisation : accès multiples + partage
de ressources
 Flexibilité : facilité d’extension du système (matériels,
logiciels)

5. Systèmes répartis (1/3)
 "Un ensemble de machines connectées par un
réseau, et équipées d’un logiciel dédié à la
coordination des activités du système ainsi
qu’au partage de ses ressources."
6
 "Un système réparti est un système qui
s’exécute sur un ensemble de machines sans
mémoire partagée, mais que pourtant
l’utilisateur voit comme une seule et unique
machine."
« Coulouris et al. »
« Tanenbaum »

6. Systèmes répartis (2/3)
7
 Types de ressources
 Calcul
 Stockage
 Electronique
 capteur, satellites, scanneurs, …
 Architecture
 Plusieurs processeurs  plusieurs horloges
 Plusieurs mémoires  pas de mémoire partagée
 Réseau d’interconnexion et de communication

7. Systèmes répartis (3/3)
 Fonctionnement collaboratif: des traitements
coopérants sur des données réparties pour
réaliser une tâche commune
 La coopération entre les processus correspond à la
communication entre eux et la synchronisation de
leurs évolutions.
 La répartition peut concerner les données comme
les traitements (tâches).
8

8. Caractéristiques (1/2)
9
 Absence d’état global
 Pas de référence spatiale commune à cause de
l’absence (dans la majorité des cas) d’une
mémoire partagée
 Pas de référence temporelle commune à cause
de l’existence de plusieurs processeurs ayant
chacun sa propre horloge
 Existence d’un réseau
 non géré par le système d’exploitation
 le comportement du système réparti dépend de
l’état du réseau

9. Caractéristiques (2/2)
10
 Architecture matérielle
 Multi-processeurs à mémoire
partagée
 Clusters (grappes) d’ordinateurs
 Ordinateurs puissants (serveurs
dédiés) et indépendants
 Ordinateurs PC en réseau
 Architecture logicielle (système)
 Entités logicielles séparées
s’exécutant en parallèle

10. Exemples
 Commerce électronique
 Partage de fichiers (P2P)
 Réseaux sociaux
11
 Grilles informatiques
 Ensemble de ressources hétérogènes et
dé-localisées
 Cloud Computing (Informatique en
nuage) :
 Accès via le réseau, à la demande et en
libre-service, à des ressources virtualisées
et mutualisées

11. Tolérance aux pannes
 Un système réparti doit tolérer la panne des machines :
 Une machine tombe en panne
 Une machine envoie des informations erronées
 Une machine n’est plus atteignable (problème réseau)
Hétérogénéité
 Comment s’affranchir des différences matérielles et
logicielles des ressources du système ?
 Sources d’hétérogénéité
 machines (architecture matérielle)
 systèmes d'exploitation
 langages de programmation
 protocoles de communications
Propriétés
12

12. Sécurité
 Confidentialité, Intégrité : Droits d’accès, Pare-Feu
 Non-répudiation (s'assurer qu’un contrat signé via
internet, ne peut être remis en cause par l’une des
parties)
 Authentification
 Identification des applications partenaires
 Messages authentifiés
Disponibilité
 Prêt à l’utilisation et toujours disponible
Transparence
 Propriété fondamentale : Tout cacher à l’utilisateur
 La répartition doit être non perceptible : une ressource
distante est accédée comme une ressource locale
 Cacher l'architecture et le fonctionnement du système
Propriétés
13

13. Passage à l’échelle (scalability) :
 paramètre primordial pour la durabilité du
système et sa capacité d’évolution en fonction
des besoins
 un système réparti doit montrer une capacité
acceptable de passer à l’échelle:
 Ce qui marche pour un utilisateur, marchera-t-il pour
des milliers (voir des millions) ?
 Ce qui marche pour un site, marchera-t-il pour des
milliers ?
 Ce qui marche pour un objet, marchera-t-il pour des
millions ?
Problèmes
16

14. Nommage et accès
 Comment identifier les ressources distantes et les
retrouver?
 Système centralisé: nommage géré par le système
d’exploitation (adressage).
 Système réparti: utilisation d’annuaires et de
services de nommage
Intégration de l’existant
 Connexion sur toutes les ressources d’une
entreprise
 Interopérabilité des applications
Problèmes
17

15. Déploiement des applications
 Comment installer tous les composants logiciels
de l’application sur les différentes machines?
 La modification d’un service ou l’ajout d’un autre,
nécessite la recompilation, et/ou redéploiement
de l’application?
 Est il possible de reconfigurer automatiquement
le redéploiement ?
Problèmes
18

16. Applications réparties19

17. Système vs application
20
 Système : gestion des ressources communes et de
l’infrastructure, lié de manière étroite au matériel sous-
jacent
 Système d’exploitation : gestion de chaque élément
 Système de communication : échange d’information
entre les éléments
 Caractéristiques communes : cachent la complexité du
matériel et des communications, fournissent des
services communs de plus haut niveau d’abstraction
 Application : réponse à un problème spécifique,
fourniture de services à ses utilisateurs (qui peuvent
être d’autres applications).

18. Modèles de répartition
21
 Modèle Client/Serveur
 Modèle de communication par messages
 Modèle de communication par événements
 Modèle à mémoire partagée
 Modèle à base de composants
 Modèle à base d’agents mobiles
 Modèle orienté service

19. Modèle Client/Serveur
22
 Client : processus demandant l’exécution d’une
opération à un autre processus
 Serveur : processus accomplissant une opération
sur demande d’un client, et lui transmettant le
résultat
 Modèle Requête/Réponse :
 Requête : message transmis par un client à un serveur
décrivant l’opération à exécuter
 Réponse : message transmis par un serveur à un
client suite à l’exécution d’une opération, contenant le
résultat de l’opération
 Mode de communication synchrone
 Le client envoie la requête et attend la réponse.
 Emission bloquante

20. Modèle de communication par messages
(1/2)
23
 Une application produit des messages (producteur)
et une application les consomme (consommateur)
 Le producteur (l’émetteur) et le consommateur
(récepteur) ne communiquent pas directement
entre eux mais utilisent un objet de communication
intermédiaire (boîte aux lettres ou file d’attente)
 Communication asynchrone :
 Les deux composants n'ont pas besoin d'être
connectés en même temps grâce au système de file
d'attente
 Emission non bloquante: l’entité émettrice émet son
message, et continue son traitement sans attendre que
le récepteur confirme l'arrivée du message
 Le récepteur récupère les messages quand il le
souhaite

21. Modèle de communication par messages
(2/2)
24
 Adapté à un système réparti dont les éléments
en interaction sont faiblement couplés :
 éloignement géographique des entités
communicantes
 possibilité de déconnexion temporaire d’un
élément
 Deux modèles de communication :
 Point à point: le message n’est lu que par un seul
consommateur. Une fois lu, il est retiré de la file
d'attente
 Multi-points : le message est diffusé à tous les
éléments d’une liste de destinataires

22. Modèle de communication par événements
25
 Mode de communication asynchrone et anonyme
 indépendance entre le producteur et les (consommateurs d’un événement
 Concepts de base
 Evénement = changement d'état survenant de manière asynchrone (par
rapport aux clients)
 Réaction = exécution d’une opération prédéfinie liée à l’événement
 Modèle Publish/Subscribe (par abonnement) :
 les applications consommatrices des messages s'abonnent à un topic
(sujet)
 Les messages envoyés à ce topic restent dans la file d'attente jusqu'à
ce que tous les abonnées aient lu le message
 Deux modes de consommation :
 « Mode Pull » - réception explicite : les consommateurs viennent
prendre régulièrement leurs messages
 « Mode Push » - délivrance implicite : une méthode prédéfinie est
attachée à chaque type de message et elle est appelée automatiquement
à chaque occurrence de l’évènement. La réception d'un événement
entraîne l'exécution de la réaction associée
 Exemple : surveillance des systèmes

23. Modèles à mémoire partagée
26
 Objectif:
 Replacer le programmeur dans les conditions d’un
système centralisé :
 utiliser un espace mémoire commun pour les
communications
 Avantages:
 transparence de la distribution pour le développeur
 efficacité de développement (utilisation des
paradigmes usuels de la programmation concurrente)
 Inconvénient:
 Complexité de mise en œuvre efficace d’une mémoire
partagée distribuée

24. Modèle à base de composants
27
 Composant : module logiciel autonome et
réutilisable
 possède des entrées/sorties déclarées pour
permettre les connexions entre plusieurs composants
 possède des propriétés déclarées permettant de
configurer le composant
 Objectif: Simplifier la conception et le
développement des applications :
 Réutilisabilité
 Indépendance
 autonomie

25. Modèle à base d’agents mobiles
28
 Code mobile : programme se déplaçant d’un
site à un autre sur le réseau
 Exemple : une applet incluse dans une page
HTML et qui s’exécute sur la machine qui
télécharge la page.
 Avantages de la mobilité :
 minimiser les communications effectuées pour les
échanges
 amener le code aux données plutôt que le contraire
 Agent mobile : entité logicielle
 peut se déplacer d'une machine à une autre sur
réseau
 s'exécute sur une machine et peut arrêter son

26. Modèle orienté service
29
 Un modèle d'interaction basé sur la notion de
service
 Un service est un composant logiciel exécuté
par un producteur à l'attention
d'un consommateur
 Une nouvelle vision dans la conception des
applications réparties

27. Middleware30

28. Motivations
31
 L’interface fournie par les systèmes
d’exploitation et de communication est encore
trop complexe pour être utilisée directement
par les applications:
 Hétérogénéité (matérielle et logicielle)
 Complexité des mécanismes (bas niveau)
 Nécessité de gérer la répartition
 Solution
 Introduire une couche logicielle intermédiaire
(répartie) entre les niveaux bas (systèmes et
communication) et le niveau haut (applications) :
c’est l’intergiciel ou Middleware

29. Middleware
33
 Un middleware (ou intergiciel) permet le
dialogue entre les différentes entités d'une
application répartie
 Représente l’élément le plus important de tout système
réparti
Site 1 Site 2

30. Middleware - Fonctions
34
 Masquer l’hétérogénéité (machines,
systèmes, protocoles de communication)
 Fournir une API (Application Programming
Interface) de haut niveau
 Permet de masquer la complexité des échanges
 Facilite le développement d'une application
répartie
 Rendre la répartition aussi invisible
(transparente) que possible
 Fournir des services répartis d’usage courant

31. Services du middleware
35
 Communication
 permet la communication entre machines mettant
en œuvre des formats différents de données
 prise en charge par la FAP (Format And
Protocol)
 FAP : pilote les échanges à travers le réseau :
 synchronisation des échanges selon un protocole de
communication
 mise en forme des données échangées selon un
format connu de part et d'autre

32. Middleware
36
 Nommage
 permet d'identifier la machine serveur sur laquelle
est localisé le service demandé afin d'en déduire
le chemin d'accès.
 fait, souvent, appel aux services d'un annuaire.
 Sécurité
 permet de garantir la confidentialité et la sécurité
des données à l'aide de mécanismes
d'authentification et de cryptage des informations

33. Types de middleware
37
 Middleware RPC (Remote Proceedure Call)
 RPC de SUN
 Middlewares orientés objets distribués
 Java RMI, Corba
 Middlewares orientés composants distribués
 EJB, Corba, DCOM
 Middlewares orientés messages
 JMS de Sun, MSMQ de Microsoft, MQSeries de IBM
 Middlewares orientés sevices
 Web Services (XML-RPC, SOAP)
 Middlewares orientés SGBD
 ODBC (Open DataBase Connectivity), JDBC de Sun
 Middlewares transactionnels
 JTS de Sun, MTS de Microsoft

34. Communications38

35. Présentation
39
 Elément fondamental d’un système réparti
 Plusieurs systèmes séparés physiquement
 Reliés par un réseau
 Définit leur interconnexion
 Leur permet de communiquer entre eux

36. Outils de communication
40
 Problématique
 Réaliser un service réparti en utilisant l’interface de
transport (TCP, UDP)
 Mise en œuvre
 Bas niveau
 Utilisation directe de la couche transport
 Sockets : mécanisme universel de bas niveau, utilisable
depuis tout langage (exemple : C, Java)
 Haut niveau
 Utiliser les services offerts par les middlewares (Services plus
complexes
 Appel de procédure à distance (RPC), dans un langage particulier ;
exemple : C
 Appel de méthode à distance, dans les langages à objets ;
exemple : Java RMI

37. le réseau vu de l’utilisateur
41
 Schéma Client/Serveur
 Machines différentes : client demande un service
fournit par un serveur sur une autre machine
 Un service est souvent désigné par un nom symbolique (email,
http://..., telnet, etc.).
 Ce nom doit être converti en une adresse interprétable par les
protocoles du réseau.
 La conversion d’un nom symbolique (http://www.google.com) en
une adresse IP (216.239.39.99) est à la charge du service DNS

38. le réseau vu de l’utilisateur
42
 Le serveur (machine physique) peut comporter différents services:
 L’adresse IP du serveur ne suffit pas,
 il faut préciser le service demandé au moyen d’un numéro de port, qui
permet d’atteindre un processus particulier sur la machine serveur.
 Un numéro de port comprend 16 bits (0 à 65 535).
 Les numéros de 0 à 1023 sont réservés, par convention, à des
services spécifiques.
 Exemples :
 22 : ssh, 23 :telnet (connexion à distance)
 80 : serveur web, 25 : mail, 21: FTP