SYSTÈMES RÉPARTIS

heithem.abbes@gmail.com
Introduction au systèmes répartis
 Système centralisé
3

 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 reconstituable
 Accès local aux ressources
 Emergence du réparti
4

 Evolution technologique
 Machines
 de plus en plus performantes avec une baisse des prix
 Équipement réseau
 de plus en plus rapides

 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)
 Systèmes répartis
6

 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
« Coulouris et al. »
 Systèmes répartis
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
 Caractéristiques
9

 Absence d’état global

 Pas de référence spatiale commune à cause de
l’absence 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
 Caractéristiques
10

 Architecture matérielle
 Multi-processeurs à mémoire partagée
 Clusters (grappes) de serveurs (Data center)
 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
 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
 Modèle Client/Serveur
22

 Client : processus demandant l’exécution d’une opération à un

processus serveur
 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
 Modèle de communication par messages
23

 Producteur : Une application qui produit (émet) des messages

 Consommateur et une application qui les consomme (reçoit)
 Le producteur et le consommateur ne communiquent pas
directement entre eux mais utilisent un objet de
communication intermédiaire : file d’attente (ou boîte aux
lettres)
 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: le producteur émet son message, et continue
son traitement sans attendre que le consommateur confirme l'arrivée du
message
 Le consommateur récupère les messages quand il le souhaite
 Modèle de communication par événements
25

 Modèle Publish/Subscribe
 Editeurs (Publishers) : publient des données sur des sujets
(topic) spécifiques
 Abonnés (Subscribers) : s'abonnent aux sujets qui les
intéressent pour recevoir les données
 Mode de communication asynchrone et anonyme
 Evénement : publication de données sur des sujets
 indépendance entre l’editeur et l’abonnée d’un événement
 Couplage
26

 Couplage fort
 Les composants d'un système sont étroitement reliés les uns aux
autres.
 Les modifications ou remplacements de composants peuvent avoir
des conséquences importantes sur les autres composants
 Client/Serveur est en couplage fort
 Couplage faible
 les composants d'un système sont peu reliés les uns aux autres.
 Les composants peuvent être modifiés ou remplacés sans affecter
les autres composants
 Producteur/consommateur et Publisher/subscriber est en couplage
faible
32 Middleware
 Motivations
33

 L’interface fournie par les systèmes d’exploitation et

de communication est 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 le Middleware (ou
intergiciel)
 Middleware
34

 Un middleware 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
 Middleware - Fonctions
35

 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
 Services du middleware
36

 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
 Middleware
37

 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
 Types de middleware
38

 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, SPRING
 Middlewares orientés messages
 ActiveMQ, Kafka, RabitMQ
 Middlewares orientés sevices
 Web Services (SOAP, Restfull)
 Middlewares orientés SGBD
 ODBC, JDBC
39 Communications
 Présentation
40

 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
 Outils de communication
41

 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 (C, Java)
 le réseau vu de l’utilisateur
42

 Client demande un service fournit par un serveur

 Un service est souvent désigné par un nom symbolique
 https://www.google.com, ftp://repo.tn …
 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 serveur DNS
 le réseau vu de l’utilisateur
43

 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