SlideShare une entreprise Scribd logo

Exposé de SE Systemes distribués

C'est un exposé de système distribué

Exposé de SE Systemes distribués

1  sur  32
Télécharger pour lire hors ligne
INF803 / SYSTEME D’EXPLOITATION
SYSTEMES DISTRIBUES
Travail réalisé par :
Matricule Nom et prénoms
CM_UDS_15SCI2290 YOUSSOUF SALEH GAO
Supervisé par :
Dr KENGNE T. VIANNEY
Année académique 2016/2017
M1:R&SD Page 2
INTRODUCTION......................................................................................................................3
I. PRESENTATION DE SYSTEME DISTRIBUE............................................................4
1. Définition .......................................................................................................................... 4
2. Les avantages d’un système distribué.................................................................................. 4
3. Critères d’un système distribué ........................................................................................... 5
4. Inconvénient des systèmes distribués................................................................................... 6
5. Sécurité des systèmes distribués .......................................................................................... 7
I. ARCHITECTURE DES SYSTEMES DISTRIBUES.....................................................7
1. Architecture matérielle ....................................................................................................... 7
2. Architecture logicielle : les systèmes d’exploitation............................................................13
3. Architecture des applications distribuées.............................................................................17
II. COMMUNICATIONS DANS LES SYSTEMES DISTRIBUES ................................20
1. Les sockets.......................................................................................................................20
2. La communication synchrone ...........................................................................................20
3. Les RMI (JAVA)..............................................................................................................21
4. CORBA...........................................................................................................................22
III. SYSTEMES DE FICHIERS DISTRIBUES .................................................................22
1. Objectifs des systèmes de fichiers distribués .......................................................................22
2. Le service de fichiers.........................................................................................................23
3. La sémantique du partage des fichiers.................................................................................25
4. L’implémentation des systèmes de fichiers répartis .............................................................26
5. Les mécanismes de cache ..................................................................................................27
6. La cohérence du cache.......................................................................................................28
7. La duplication (Réplication)...............................................................................................29
8. La modification des fichiers...............................................................................................30
CONCLUSION ........................................................................................................................31
Bibliographie ............................................................................................................................32
M1:R&SD Page 3
INTRODUCTION
Durant les années 40, le monde a connu l’apparition des premiers ordinateurs (des gros
calculateurs centralisés et très coûteux). La naissance des micros ordinateurs peu chers et
facile à interconnecter en début des années 80, a fait naître de nouveaux concepts tel celui du
système distribué. De nos jours, les machines multiprocesseurs se vulgarisent, les réseaux
locaux sont utilisés dans presque tous les laboratoires d’informatique, quant aux réseaux à
grande distance, ils arrivent à s’infiltrer dans la plupart des foyers permettant un accès aisé à
de gigantesques bases de données et beaucoup d’autres services.
Pour comprendre les systèmes distribués, nous allons présenter dans les sections suivantes les
systèmes distribués d’une manière générale, ensuite nous présenterons son architecture, le
mode de communication et enfin les systèmes des fichiers distribués.
M1:R&SD Page 4
I. PRESENTATIONDU SYSTEME DISTRIBUE
1. Définition
Un système distribué est une collection d’ordinateurs indépendants qui apparaissent à
l’utilisateur comme un seul système cohérent.
Dans cette définition ressortent deux aspects :
 Le premier est de nature matérielle, il s’agit de l’autonomie des ordinateurs où chacun
peut exécuter des tâches en concurrence (au même moment) avec les autres.
 Le second fait référence au logiciel qui laisse apparaitre le système distribué comme
une seule entité cohérente. C’est un aspect qui suppose une interconnexion des
ordinateurs moyennant un réseau de communication physique.
La motivation principale des systèmes repartis est l’amélioration du partage des ressources
c'est-à-dire les ressources disponibles dans un ordinateur donné peuvent être utilisées par un
autre et vice versa.
Naturellement, ce partage des ressources entre tâches concurrentes introduit des problèmes
souvent désignés par « Problèmes de concurrence ». Ces problèmes existent aussi dans les
systèmes centralisés multitâches (systèmes multiprocesseurs ou monoprocesseur avec partage
de temps). Cependant, dans un système distribué, les problèmes de concurrence se trouvent
accentués par le fait que la gestion des ressources n’est pas centralisée et la nécessité d’opérer
des communications entre ordinateurs, ce qui exigent des techniques de gestion plus
sophistiquées.
La communication dans les systèmes distribués s’opère entre entités physiques ou logiques et
se base sur la possibilité d’échange de messages qui est toujours supportée par le réseau
physique d’ordinateurs. L’échange entre deux systèmes de gestions de fichiers est un échange
entre entités logiques. Il en est de même pour la communication entre applications où
l’échange s’opère entre entités logiques appelées processus.
Dans un système distribué, les ordinateurs peuvent tomber en pannes indépendamment les uns
des autres. De même, les lignes de communication physiques peuvent être défaillantes. Mais
au de-là des aspects matériels, les tâches exécutés sur chaque ordinateur peuvent être échoués.
Ces pannes d’ordre physique ou logique peuvent avoir un effet local plus ou moins étendu.
Lorsqu’une application fait intervenir plusieurs composants où chacun s’exécute sur un
ordinateur séparé, il incombe au concepteur de cette application d’anticiper les différentes
pannes qui peuvent arrivées et prévoir des mécanismes pour la poursuite de la coordination et
l’atteinte de l’objectif visé.
2. Les avantages d’un système distribué
 Coût : un rapport Performance/Prix des Micro-processeurs meilleur que celui des
Supercalculateurs
 Partage et mise à disposition : Partager des ressources et des services disponibles
(exemple : les systèmes d'exploitation répartis qui permettent de mettre en place un
service de gestion de fichiers partagés et répartis)
M1:R&SD Page 5
 Répartition géographique : Mettre à disposition des usagers les moyens informatiques
locaux en même temps que ceux distants de leurs collègues (exemple: un système de
réservation d'hôtel répartis en différents pays, compagnies ou agences ou encore un
système bancaire avec ses agences régionales et son siège social)
 Puissance de calcul : Paralléliser les algorithmes de calcul avec des environnements
d'exécution spécifique comme PVM (Parallel Virtual Machine) ou MPI (Message
Passing Interface)
 Disponibilité d'un service
 Continuer un service globalement même dégradé.
 Exemple courant: la réplication d'un même service par l'installation de plusieurs
serveurs équivalents.
 Flexibilité
 Par nature modulaire (possibilité d’évolution)
 Continuité de service pendant la maintenance (remplacement d'un nœud)
 l'informatique nomade : portable et points d'accès mobiles sur un réseau réparti
aux frontières floues (Internet)
 Adaptabilité à une forte croissance des besoins informatiques d'une entreprise
3. Critères d’un système distribué
Un bon système réparti est un système qui à l'air centralisé. Afin de simplifier l'effort de
programmation dans une application répartie, il vaut mieux masquer le plus possible les
propriétés délicates de la répartition. Mais, il est difficile d'être transparent sur tous les
aspects.
a. La transparence
Fait pour une fonctionnalité, un élément d'être invisible ou caché à l'utilisateur ou un autre
élément formant le système distribué
Le but est de cacher l'architecture, le fonctionnement de l'application ou du système distribué
pour apparaître à l'utilisateur comme une application unique cohérente
L'ISO définit plusieurs transparences (norme RM-ODP) : accès, localisation, concurrence,
réplication, mobilité, panne, performance, échelle)
 Transparence d'accès : accès à des ressources distantes aussi facilement que
localement et aux données indépendamment de leur format de représentation
 Transparence de localisation : la désignation de la ressource est indépendante de la
localisation de cette ressource.
 Transparence de concurrence : exécution possible de plusieurs processus en
parallèle avec utilisation de ressources partagées (exemple des transactions dans des
bases de données réparties).
 Transparence de réplication : possibilité de dupliquer certains éléments/ressources
pour augmenter la fiabilité (utilisé pour augmenter la tolérance aux faute)
 Transparence de mobilité : c’est une propriété qui consiste à assurer qu’une
ressource peut migrer d’un nœud à un autre sans que les usagers s’en aperçoive c'est-
à-dire déplacer un service dynamiquement vers un serveur moins chargé
 Transparence de panne : le système doit fonctionner qu'un ou plusieurs éléments
tombent en panne.
M1:R&SD Page 6
 Transparence de performance : possibilité de reconfigurer le système pour en
augmenter les performances
 Transparence d'échelle : doit supporter l'augmentation de la taille du système
(nombre d'éléments, de ressources ...) c'est-à-dire l'ajout de nœuds ne doit pas
nécessiter l’arrêt du système.
Un système donné va offrir un certain nombre de transparences : souvent au minimum
transparences de localisation, d'accès et de concurrence.
b. La souplesse
La structure du système doit faciliter son évolution. Pour cela, le noyau doit être le plus petit
possible et assurer quatre services minimum :
 les mécanismes de communication interprocessus
 la gestion de la mémoire
 la gestion et l’ordonnancement des processus
 la gestion des entrées / sorties de bas niveau
Le noyau ne fournit ni système de fichiers, ni les répertoires. Les services que le noyau ne
fournit pas sont implantés par des serveurs de niveau utilisateurs. Pour obtenir un service, un
processus envoie un message au serveur approprié. Il existe une interface bien définie pour
chaque service. On peut implémenter et installer des nouveaux services sans avoir à arrêter le
système ou le réinitialiser avec un nouveau noyau. Le système est donc très souple.
c. La fiabilité
Le système doit rester opérationnel en cas de panne, voire de plusieurs serveurs.
Les fichiers et autres ressources doivent être protégés contre une utilisation abusive.
Il faut assurer une tolérance aux pannes au niveau de l’utilisation des fichiers en introduisant
par exemple des serveurs de fichiers sans état.
d. Les performances
L’exécution des programmes devrait être plus rapide que sur un système monoprocesseur.
Les performances peuvent être mesurées par : le temps de réponse, le débit, le taux
d’utilisation du système, ….
e. Scalability (passage à l’échelle réelle)
Le passage à l’échelle réelle ou scalability concernant au moins trois aspects :
 Nombre d’utilisateurs et/ou de processus (taille) ;
 Distance maximale entre les nœuds (géographique) ;
 Nombre de domaines administratifs (administratifs).
4. Inconvénient des systèmes distribués
Dans un système où la communication s’effectue via un réseau et entre entités différentes, de
nombreux problèmes peuvent naître et créer d’énormes dégâts parmi lesquels :
 Le partage et distribution de données impose mécanismes complexes
 Synchronisation
 Sécurité
 Problèmes inhérents aux communications
 Communications explicites si pas de mémoire partagée
 Lenteur, saturation, perte de messages
 Logiciels de gestion difficiles à concevoir
Publicité

Recommandé

Systeme distribue
Systeme distribueSysteme distribue
Systeme distribueAfaf MATOUG
 
Introduction aux systèmes répartis
Introduction aux systèmes répartisIntroduction aux systèmes répartis
Introduction aux systèmes répartisHeithem Abbes
 
applications-reparties
applications-repartiesapplications-reparties
applications-repartiesmourad50
 
La technologie des systemes distribués 2 ppt2222.pptx
La technologie des systemes distribués 2 ppt2222.pptxLa technologie des systemes distribués 2 ppt2222.pptx
La technologie des systemes distribués 2 ppt2222.pptxkaoutarghaffour
 
Bases de données réparties
Bases de données répartiesBases de données réparties
Bases de données répartiesAbdelouahed Abdou
 
Virtualisation
VirtualisationVirtualisation
VirtualisationTsubichi
 

Contenu connexe

Tendances

Architecture réparties et les services web
Architecture réparties et les services webArchitecture réparties et les services web
Architecture réparties et les services webCHOUAIB EL HACHIMI
 
Introduction aux architectures des SI
Introduction aux architectures des SI Introduction aux architectures des SI
Introduction aux architectures des SI Heithem Abbes
 
Introduction aux réseaux informatiques
Introduction aux réseaux informatiquesIntroduction aux réseaux informatiques
Introduction aux réseaux informatiquessarah Benmerzouk
 
Cloud Computing presentation
Cloud Computing presentationCloud Computing presentation
Cloud Computing presentationSeif Ben Hammouda
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveurAmeni Ouertani
 
Base de données distribuée
Base de données distribuéeBase de données distribuée
Base de données distribuéekamar MEDDAH
 
Architectures n-tiers
Architectures n-tiersArchitectures n-tiers
Architectures n-tiersHeithem Abbes
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)Heithem Abbes
 
eServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementeServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementLilia Sfaxi
 
Introduction au Cloud Computing
Introduction au Cloud Computing Introduction au Cloud Computing
Introduction au Cloud Computing FICEL Hemza
 
Design Patterns
Design PatternsDesign Patterns
Design PatternsKoffi Sani
 
Architecture des Systèmes Logiciels
Architecture des Systèmes LogicielsArchitecture des Systèmes Logiciels
Architecture des Systèmes LogicielsGhazouani Mahdi
 
Ontology concept et applications
Ontology concept et applicationsOntology concept et applications
Ontology concept et applicationsbenouini rachid
 

Tendances (20)

systèmes distribues
systèmes distribuessystèmes distribues
systèmes distribues
 
Architecture réparties et les services web
Architecture réparties et les services webArchitecture réparties et les services web
Architecture réparties et les services web
 
Introduction aux architectures des SI
Introduction aux architectures des SI Introduction aux architectures des SI
Introduction aux architectures des SI
 
Introduction aux réseaux informatiques
Introduction aux réseaux informatiquesIntroduction aux réseaux informatiques
Introduction aux réseaux informatiques
 
Etude de la virtualisation
Etude de la virtualisationEtude de la virtualisation
Etude de la virtualisation
 
Cloud Computing presentation
Cloud Computing presentationCloud Computing presentation
Cloud Computing presentation
 
Présentation cloud computing
Présentation cloud computingPrésentation cloud computing
Présentation cloud computing
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveur
 
Base de données distribuée
Base de données distribuéeBase de données distribuée
Base de données distribuée
 
Base des données réparties
Base des données répartiesBase des données réparties
Base des données réparties
 
Eucalyptus
EucalyptusEucalyptus
Eucalyptus
 
Architectures n-tiers
Architectures n-tiersArchitectures n-tiers
Architectures n-tiers
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)
 
eServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementeServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API Management
 
Introduction au Cloud Computing
Introduction au Cloud Computing Introduction au Cloud Computing
Introduction au Cloud Computing
 
Design Patterns
Design PatternsDesign Patterns
Design Patterns
 
Architecture des Systèmes Logiciels
Architecture des Systèmes LogicielsArchitecture des Systèmes Logiciels
Architecture des Systèmes Logiciels
 
La virtualisation
La virtualisationLa virtualisation
La virtualisation
 
Tp n 1 linux
Tp n 1 linuxTp n 1 linux
Tp n 1 linux
 
Ontology concept et applications
Ontology concept et applicationsOntology concept et applications
Ontology concept et applications
 

Similaire à Exposé de SE Systemes distribués

srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdfSamirAwad14
 
LES RESEAUX INFORMATIQUES.pdf
LES RESEAUX INFORMATIQUES.pdfLES RESEAUX INFORMATIQUES.pdf
LES RESEAUX INFORMATIQUES.pdfssuser18776b
 
Simulation d’un système à temps partagé
Simulation d’un système à temps partagéSimulation d’un système à temps partagé
Simulation d’un système à temps partagéBachir Benyammi
 
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008guest9dd59e
 
Maintenance equipement info dans un environnement reseau
Maintenance equipement info dans un environnement reseau Maintenance equipement info dans un environnement reseau
Maintenance equipement info dans un environnement reseau JennellyHollywood Shookou
 
Cours windows-2003-server
Cours windows-2003-serverCours windows-2003-server
Cours windows-2003-servermbarek_slide
 
Cours6 informatique201801
Cours6 informatique201801Cours6 informatique201801
Cours6 informatique201801wissem hammouda
 
Introduction aux systèmes d-exploitation (2).ppt
Introduction aux systèmes d-exploitation (2).pptIntroduction aux systèmes d-exploitation (2).ppt
Introduction aux systèmes d-exploitation (2).pptMahdiHERMASSI1
 
Chap10 : Outils de Simulation Cas des CAD 3D Concepts de base & fondements.
Chap10 : Outils de Simulation Cas des CAD 3D Concepts de base & fondements.Chap10 : Outils de Simulation Cas des CAD 3D Concepts de base & fondements.
Chap10 : Outils de Simulation Cas des CAD 3D Concepts de base & fondements.Mohammed TAMALI
 
Backdoors et rootkits_avancees
Backdoors et rootkits_avanceesBackdoors et rootkits_avancees
Backdoors et rootkits_avanceesUltraUploader
 
Gestion des threads
Gestion des threadsGestion des threads
Gestion des threadsSana Aroussi
 
Linux et les systèmes embarqués
Linux et les systèmes embarquésLinux et les systèmes embarqués
Linux et les systèmes embarquésStéphane Legrand
 

Similaire à Exposé de SE Systemes distribués (20)

srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdf
 
LES RESEAUX INFORMATIQUES.pdf
LES RESEAUX INFORMATIQUES.pdfLES RESEAUX INFORMATIQUES.pdf
LES RESEAUX INFORMATIQUES.pdf
 
Simulation d’un système à temps partagé
Simulation d’un système à temps partagéSimulation d’un système à temps partagé
Simulation d’un système à temps partagé
 
Cour1
Cour1Cour1
Cour1
 
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
 
Grid computing
Grid computingGrid computing
Grid computing
 
Rapport de fin de stage maintenance info
Rapport de fin de stage  maintenance infoRapport de fin de stage  maintenance info
Rapport de fin de stage maintenance info
 
Maintenance equipement info dans un environnement reseau
Maintenance equipement info dans un environnement reseau Maintenance equipement info dans un environnement reseau
Maintenance equipement info dans un environnement reseau
 
Rapport de fin de stage maintenance info
Rapport de fin de stage  maintenance infoRapport de fin de stage  maintenance info
Rapport de fin de stage maintenance info
 
Cours windows-2003-server
Cours windows-2003-serverCours windows-2003-server
Cours windows-2003-server
 
2-Composants.docx
2-Composants.docx2-Composants.docx
2-Composants.docx
 
Cacti
CactiCacti
Cacti
 
Rapport final-2
Rapport final-2Rapport final-2
Rapport final-2
 
Cours6 informatique201801
Cours6 informatique201801Cours6 informatique201801
Cours6 informatique201801
 
Introduction aux systèmes d-exploitation (2).ppt
Introduction aux systèmes d-exploitation (2).pptIntroduction aux systèmes d-exploitation (2).ppt
Introduction aux systèmes d-exploitation (2).ppt
 
Chap10 : Outils de Simulation Cas des CAD 3D Concepts de base & fondements.
Chap10 : Outils de Simulation Cas des CAD 3D Concepts de base & fondements.Chap10 : Outils de Simulation Cas des CAD 3D Concepts de base & fondements.
Chap10 : Outils de Simulation Cas des CAD 3D Concepts de base & fondements.
 
Backdoors et rootkits_avancees
Backdoors et rootkits_avanceesBackdoors et rootkits_avancees
Backdoors et rootkits_avancees
 
Tiny os_2
Tiny os_2Tiny os_2
Tiny os_2
 
Gestion des threads
Gestion des threadsGestion des threads
Gestion des threads
 
Linux et les systèmes embarqués
Linux et les systèmes embarquésLinux et les systèmes embarqués
Linux et les systèmes embarqués
 

Exposé de SE Systemes distribués

  • 1. INF803 / SYSTEME D’EXPLOITATION SYSTEMES DISTRIBUES Travail réalisé par : Matricule Nom et prénoms CM_UDS_15SCI2290 YOUSSOUF SALEH GAO Supervisé par : Dr KENGNE T. VIANNEY Année académique 2016/2017
  • 2. M1:R&SD Page 2 INTRODUCTION......................................................................................................................3 I. PRESENTATION DE SYSTEME DISTRIBUE............................................................4 1. Définition .......................................................................................................................... 4 2. Les avantages d’un système distribué.................................................................................. 4 3. Critères d’un système distribué ........................................................................................... 5 4. Inconvénient des systèmes distribués................................................................................... 6 5. Sécurité des systèmes distribués .......................................................................................... 7 I. ARCHITECTURE DES SYSTEMES DISTRIBUES.....................................................7 1. Architecture matérielle ....................................................................................................... 7 2. Architecture logicielle : les systèmes d’exploitation............................................................13 3. Architecture des applications distribuées.............................................................................17 II. COMMUNICATIONS DANS LES SYSTEMES DISTRIBUES ................................20 1. Les sockets.......................................................................................................................20 2. La communication synchrone ...........................................................................................20 3. Les RMI (JAVA)..............................................................................................................21 4. CORBA...........................................................................................................................22 III. SYSTEMES DE FICHIERS DISTRIBUES .................................................................22 1. Objectifs des systèmes de fichiers distribués .......................................................................22 2. Le service de fichiers.........................................................................................................23 3. La sémantique du partage des fichiers.................................................................................25 4. L’implémentation des systèmes de fichiers répartis .............................................................26 5. Les mécanismes de cache ..................................................................................................27 6. La cohérence du cache.......................................................................................................28 7. La duplication (Réplication)...............................................................................................29 8. La modification des fichiers...............................................................................................30 CONCLUSION ........................................................................................................................31 Bibliographie ............................................................................................................................32
  • 3. M1:R&SD Page 3 INTRODUCTION Durant les années 40, le monde a connu l’apparition des premiers ordinateurs (des gros calculateurs centralisés et très coûteux). La naissance des micros ordinateurs peu chers et facile à interconnecter en début des années 80, a fait naître de nouveaux concepts tel celui du système distribué. De nos jours, les machines multiprocesseurs se vulgarisent, les réseaux locaux sont utilisés dans presque tous les laboratoires d’informatique, quant aux réseaux à grande distance, ils arrivent à s’infiltrer dans la plupart des foyers permettant un accès aisé à de gigantesques bases de données et beaucoup d’autres services. Pour comprendre les systèmes distribués, nous allons présenter dans les sections suivantes les systèmes distribués d’une manière générale, ensuite nous présenterons son architecture, le mode de communication et enfin les systèmes des fichiers distribués.
  • 4. M1:R&SD Page 4 I. PRESENTATIONDU SYSTEME DISTRIBUE 1. Définition Un système distribué est une collection d’ordinateurs indépendants qui apparaissent à l’utilisateur comme un seul système cohérent. Dans cette définition ressortent deux aspects :  Le premier est de nature matérielle, il s’agit de l’autonomie des ordinateurs où chacun peut exécuter des tâches en concurrence (au même moment) avec les autres.  Le second fait référence au logiciel qui laisse apparaitre le système distribué comme une seule entité cohérente. C’est un aspect qui suppose une interconnexion des ordinateurs moyennant un réseau de communication physique. La motivation principale des systèmes repartis est l’amélioration du partage des ressources c'est-à-dire les ressources disponibles dans un ordinateur donné peuvent être utilisées par un autre et vice versa. Naturellement, ce partage des ressources entre tâches concurrentes introduit des problèmes souvent désignés par « Problèmes de concurrence ». Ces problèmes existent aussi dans les systèmes centralisés multitâches (systèmes multiprocesseurs ou monoprocesseur avec partage de temps). Cependant, dans un système distribué, les problèmes de concurrence se trouvent accentués par le fait que la gestion des ressources n’est pas centralisée et la nécessité d’opérer des communications entre ordinateurs, ce qui exigent des techniques de gestion plus sophistiquées. La communication dans les systèmes distribués s’opère entre entités physiques ou logiques et se base sur la possibilité d’échange de messages qui est toujours supportée par le réseau physique d’ordinateurs. L’échange entre deux systèmes de gestions de fichiers est un échange entre entités logiques. Il en est de même pour la communication entre applications où l’échange s’opère entre entités logiques appelées processus. Dans un système distribué, les ordinateurs peuvent tomber en pannes indépendamment les uns des autres. De même, les lignes de communication physiques peuvent être défaillantes. Mais au de-là des aspects matériels, les tâches exécutés sur chaque ordinateur peuvent être échoués. Ces pannes d’ordre physique ou logique peuvent avoir un effet local plus ou moins étendu. Lorsqu’une application fait intervenir plusieurs composants où chacun s’exécute sur un ordinateur séparé, il incombe au concepteur de cette application d’anticiper les différentes pannes qui peuvent arrivées et prévoir des mécanismes pour la poursuite de la coordination et l’atteinte de l’objectif visé. 2. Les avantages d’un système distribué  Coût : un rapport Performance/Prix des Micro-processeurs meilleur que celui des Supercalculateurs  Partage et mise à disposition : Partager des ressources et des services disponibles (exemple : les systèmes d'exploitation répartis qui permettent de mettre en place un service de gestion de fichiers partagés et répartis)
  • 5. M1:R&SD Page 5  Répartition géographique : Mettre à disposition des usagers les moyens informatiques locaux en même temps que ceux distants de leurs collègues (exemple: un système de réservation d'hôtel répartis en différents pays, compagnies ou agences ou encore un système bancaire avec ses agences régionales et son siège social)  Puissance de calcul : Paralléliser les algorithmes de calcul avec des environnements d'exécution spécifique comme PVM (Parallel Virtual Machine) ou MPI (Message Passing Interface)  Disponibilité d'un service  Continuer un service globalement même dégradé.  Exemple courant: la réplication d'un même service par l'installation de plusieurs serveurs équivalents.  Flexibilité  Par nature modulaire (possibilité d’évolution)  Continuité de service pendant la maintenance (remplacement d'un nœud)  l'informatique nomade : portable et points d'accès mobiles sur un réseau réparti aux frontières floues (Internet)  Adaptabilité à une forte croissance des besoins informatiques d'une entreprise 3. Critères d’un système distribué Un bon système réparti est un système qui à l'air centralisé. Afin de simplifier l'effort de programmation dans une application répartie, il vaut mieux masquer le plus possible les propriétés délicates de la répartition. Mais, il est difficile d'être transparent sur tous les aspects. a. La transparence Fait pour une fonctionnalité, un élément d'être invisible ou caché à l'utilisateur ou un autre élément formant le système distribué Le but est de cacher l'architecture, le fonctionnement de l'application ou du système distribué pour apparaître à l'utilisateur comme une application unique cohérente L'ISO définit plusieurs transparences (norme RM-ODP) : accès, localisation, concurrence, réplication, mobilité, panne, performance, échelle)  Transparence d'accès : accès à des ressources distantes aussi facilement que localement et aux données indépendamment de leur format de représentation  Transparence de localisation : la désignation de la ressource est indépendante de la localisation de cette ressource.  Transparence de concurrence : exécution possible de plusieurs processus en parallèle avec utilisation de ressources partagées (exemple des transactions dans des bases de données réparties).  Transparence de réplication : possibilité de dupliquer certains éléments/ressources pour augmenter la fiabilité (utilisé pour augmenter la tolérance aux faute)  Transparence de mobilité : c’est une propriété qui consiste à assurer qu’une ressource peut migrer d’un nœud à un autre sans que les usagers s’en aperçoive c'est- à-dire déplacer un service dynamiquement vers un serveur moins chargé  Transparence de panne : le système doit fonctionner qu'un ou plusieurs éléments tombent en panne.
  • 6. M1:R&SD Page 6  Transparence de performance : possibilité de reconfigurer le système pour en augmenter les performances  Transparence d'échelle : doit supporter l'augmentation de la taille du système (nombre d'éléments, de ressources ...) c'est-à-dire l'ajout de nœuds ne doit pas nécessiter l’arrêt du système. Un système donné va offrir un certain nombre de transparences : souvent au minimum transparences de localisation, d'accès et de concurrence. b. La souplesse La structure du système doit faciliter son évolution. Pour cela, le noyau doit être le plus petit possible et assurer quatre services minimum :  les mécanismes de communication interprocessus  la gestion de la mémoire  la gestion et l’ordonnancement des processus  la gestion des entrées / sorties de bas niveau Le noyau ne fournit ni système de fichiers, ni les répertoires. Les services que le noyau ne fournit pas sont implantés par des serveurs de niveau utilisateurs. Pour obtenir un service, un processus envoie un message au serveur approprié. Il existe une interface bien définie pour chaque service. On peut implémenter et installer des nouveaux services sans avoir à arrêter le système ou le réinitialiser avec un nouveau noyau. Le système est donc très souple. c. La fiabilité Le système doit rester opérationnel en cas de panne, voire de plusieurs serveurs. Les fichiers et autres ressources doivent être protégés contre une utilisation abusive. Il faut assurer une tolérance aux pannes au niveau de l’utilisation des fichiers en introduisant par exemple des serveurs de fichiers sans état. d. Les performances L’exécution des programmes devrait être plus rapide que sur un système monoprocesseur. Les performances peuvent être mesurées par : le temps de réponse, le débit, le taux d’utilisation du système, …. e. Scalability (passage à l’échelle réelle) Le passage à l’échelle réelle ou scalability concernant au moins trois aspects :  Nombre d’utilisateurs et/ou de processus (taille) ;  Distance maximale entre les nœuds (géographique) ;  Nombre de domaines administratifs (administratifs). 4. Inconvénient des systèmes distribués Dans un système où la communication s’effectue via un réseau et entre entités différentes, de nombreux problèmes peuvent naître et créer d’énormes dégâts parmi lesquels :  Le partage et distribution de données impose mécanismes complexes  Synchronisation  Sécurité  Problèmes inhérents aux communications  Communications explicites si pas de mémoire partagée  Lenteur, saturation, perte de messages  Logiciels de gestion difficiles à concevoir
  • 7. M1:R&SD Page 7  Peu d’expérience ou succès dans ce domaine  Complexité imposée par la transparence  Sans élément central  Gestion du système totalement décentralisée et distribuée  Nécessite la mise en place d’algorithmes plus ou moins complexes 5. Sécurité des systèmes distribués La nature d’un système distribué fait qu’il est beaucoup plus sujet à des attaques.  La communication à travers le réseau peut être interceptée  On ne connaît pas toujours bien un élément distant avec qui on communique Solutions Face à ces problèmes de sécurité, des solutions tel celui:  De la connexion sécurisée par authentification avec les éléments  Du cryptage des messages circulant sur le réseau peuvent toujours être un plus pour ces systèmes dit distribués ou reparti. I. ARCHITECTURE DES SYSTEMES DISTRIBUES On vise par la classification de partage des différents systèmes existants en catégories ou classes de telle sorte à faciliter leur compréhension et à parvenir aux concepts fondamentaux communs à chaque classe. La recherche d’une classification n’est pas une tâche facile car les systèmes distribués sont complexes et variés. Nous proposons dans cette partie une classification à trois niveaux qui reflète la structuration en couche. On repartie, dans le premier niveau, les systèmes distribués en considérant leur caractéristiques matérielles (couche matérielle). Dans le second niveau, les systèmes distribués sont vus sous l’angle des systèmes d’exploitation qui les supportent. Quant au troisième niveau, il s’agit d’étudier les diverses approches de structuration (architecture) des applications distribuées en terme de composants (ou processus) et répartition des rôles. 1. Architecture matérielle D’un point de vu abstrait, un ordinateur, se compose de deux types d’entités essentielles : les mémoires et les processeurs. On peut envisager un système distribué physique comme une collection de mémoires et de processeurs interconnectés de telle sorte à pouvoir communiquer. L’interconnexion peut être faite de diverses façons en utilisant des technologies variées ce qui donne lieu au schéma de classification de la figure ci-après. Quelque soit le système distribué considéré, il est possible de le classer dans l’une des quatre catégories suivantes :
  • 8. M1:R&SD Page 8 Figure 1 : architecture du système distribué Les systèmes à mémoires partagées sont souvent appelés systèmes multiprocesseurs ou machines à couplage fort et les systèmes à mémoires locales, dits systèmes multiordinateurs ou machines à couplage faible, ne partagent pas de mémoires communes mais chaque processeur dispose de sa propre mémoire dont il est le seul à pouvoir y accéder. a. Systèmes multiprocesseurs ou machines a couplage fort Les processeurs est les modules de mémoire (un ou plusieurs) sont connectés à un bus commun de telle sorte que tous les modules de mémoire soient accessibles à n’importe quel processeur. i. Multiprocesseurs à bus (UMA : Uniforme Memory Access) Dans ce cas, tous les processeurs accèdent à la mémoire physique, le temps d’accès à un mot mémoire est identique. Cette mémoire a la propriété d'être cohérente si par exemple le processeur A écrit un mot en mémoire et que le processeur B lit, ce mot quelques temps plus tard, B récupère la valeur qui vient d'être écrite Problème : le bus constitue un goulot d’étranglement qui baisse considérablement les performances si on atteint 4 ou 5 processeurs. Solution : La solution consiste à ajouter une mémoire cache Figure 2 : Multiprocesseurs à bus+ mémoire cache Principe :
  • 9. M1:R&SD Page 9 1. Tous les accès à la mémoire passent par le cache. 2. Si le mot demandé est dans le cache, celui-ci répond lui-même au processeur et aucune demande de bus n'est faite. 3. Le cache conserve les mots mémoire auxquels on a récemment fait accès Problème :  Supposons que deux processeurs, 1 et 2, lisent chacune le même mot dans leur cache.  Puis processeur1 écrit une nouvelle valeur.  Quand processeur2 lit à nouveau ce mot, il lit son ancienne valeur, et non pas la valeur que proceeseur1 vient d'écrire. Conséquence : La mémoire est maintenant incohérente (source d’instabilité du système). Solution : utilisation des caches Espion à écriture immédiate (Snoopy Cache Controler). Principe : A chaque écriture sur une copie, toutes les autres copies présentes dans les autres caches sont mises à jour. Le maintien de la cohérence entre caches se fait par coopération des différents contrôleurs (snoopy : espion du bus). Construire un système multiprocesseur comportant plus de 64 processeurs nécessite une autre technique d'interconnexion. ii. Multiprocesseurs basés Switch ou Multi Processeurs Commutés (UMA : Uniforme Memory Access) Dans les systèmes multiprocesseurs basés Switch, les processeurs et les modules de mémoires sont reliés par un dispositif de communication (réseau) utilisant des Switchs (réseau de commutateurs). Lorsque le commutateur entre un processeur Pr1 et un module mémoire M1 est ouvert, Pr1 peut accéder à M1. Le nombre de Switch peut être important engendrant un coût prohibitif. Pour réduire le cout, il est possible d’envisager des réseaux avec des configurations diverses. Figure 3 : Multiprocesseurs basés Switch ou Multi Processeurs Commutés Avantage : L'intérêt de cette matrice de commutation est que plusieurs processeurs peuvent accéder en même temps à la mémoire. De plus, si deux processeurs veulent accéder
  • 10. M1:R&SD Page 10 simultanément au même module de mémoire, l'une d'entre elles devra attendre que l'autre ait fini c'est-à-dire qu’il faut une file d'attente. Problème : Le nombre de Switch peut être important engendrant un coût prohibitif. Par exemple si on a n processeurs et n modules de mémoire, il faut nxn nœuds de commutation. Donc, dès que n devient grand, ce nombre est trop important. Pour réduire le cout, il est possible d’envisager des réseaux avec des configurations diverses. Solution : Réseau du type Oméga Principe du réseau oméga (multiétage)  Utilisation des commutateurs 2x2 : 2 entrées et deux sorties  chaque commutateur peut relier à n'importe quelle entrée et à n'importe quelle sortie  Pour relier n processeurs à n mémoires, il nécessite log2n étages dont chacun contient n/2 commutateurs 2x2  Le nombre nécessaire de commutateurs est : nxlog2n. Figure 4 : Principe du réseau oméga Remarque : Dans le cas le plus général, un réseau oméga destiné à interconnecter n processeurs à n mémoires nécessite au total n.log2n points de commutation. Lorsque n est grand le gain par rapport à nxn est appréciable mais cependant encore insuffisant. Inconvénient : Temps de propagation  Si n= 1024, on a besoin 10 étages  Avec les UC de 50Mhz, le cycle de calcul est de 20ns  une requête mémoire traverse 20 étages (allé/retour) en 20 ns si le temps de commutation est de 1ns  On doit avoir 10 240 commutateurs à 1ns !!! Conclusion : Le multiprocesseur doit alors comporter 1024 commutateurs à 1 ns, ce qui n'est pas vraiment bon marché. iii. Machines NUMA (Non Uniform Memory Access) Principe :
  • 11. M1:R&SD Page 11  Une partie de la mémoire est associée à une UC.  Chaque UC accède très rapidement à sa propre mémoire locale,  Mais l'accès à la mémoire des autres microprocesseurs est beaucoup plus lent. Exemple 1: multi-processeurs BBN Butterfly Figure 5 : Machines NUMA Les mémoires locales sont adressables par les processeurs distants, elles forment un espace d'adressage global virtuel. Nous pouvons conclure que :  Les multiprocesseurs à bus, y compris ceux qui disposent de caches espions, sont limités par la capacité du bus à environ 64 processeurs.  Les grandes matrices de commutation sont très chères et les grands réseaux oméga sont à la fois chers et lents.  Les machines NUMA nécessitent des algorithmes complexes pour bien placer les logiciels. En somme, construire un gros multiprocesseur fortement couplé à mémoire partagée est difficile et coûteux. b. SYSTEMES MULTIORDINATEURS MACHINES A COUPLAGE FAIBLE Les systèmes à mémoires locales, dits systèmes multiordinateurs ne partagent pas de mémoires communes, mais chaque processeur dispose de sa propre mémoire dont il est le seul à pouvoir y accéder. La construction de ce système est plus simple que celle des systèmes multiprocesseurs. Figure 6 : Systèmes multiordinateurs machines a couplage faible
  • 12. M1:R&SD Page 12 Réseau d’interconnexion: Réseau local, Anneau, Arbre binaire, Etoile, Hypercube, Réseau maillé,... i. Mémoires locales basés bus Les systèmes à mémoires locales basés bus sont construits à partir d’ordinateurs (processeur + mémoire) identiques (on les qualifie de systèmes homogènes). Les processeurs sont reliés par un réseau multiaccès partagé (Tel que Fast Ethernet) et communiquent par diffusion de messages. Bien que la bande passante du réseau soit important (de l’ordre de 100 Mbps), les systèmes ainsi construits ont une invariance à l’échelle limitée (25 à 100 nœuds). Exemple : Réseau d’interconnexion = Réseau Local, LAN (Local Area Network) Figure 7 : Mémoires locales basés bus i. Systèmes mémoire locale basés switchs Les systèmes basés switchs échangent des messages par routage à travers un réseau d’interconnexion pouvant avoir plusieurs topologies, allant des grilles simples aux hypercubes. Les architectures en grilles, souvent présentées sur un seul circuit imprimé, conviennent pour les problèmes à deux dimensions (traitement d’images, théories de graphes, …). Exemple : Réseaux d’interconnexion adaptés aux problèmes bidimensionnels Figure 8 : Topologie en treillis Un hypercube est un cube à n-dimensions où chaque nœud (un processeur) est relié à n autres nœuds processeurs. Les hypercubes conviennent à la résolution de problèmes spécifiques tels que le calcul matriciel. Les systèmes switchs peuvent avoir des configurations très variées allant jusqu’à des superordinateurs massivement parallèles (MPP : Massively Parallel Processors) contenants des milliers des processeurs.
  • 13. M1:R&SD Page 13 Figure 9 : Hypercubes Les systèmes multiordinateurs hétérogènes sont les plus utilisés actuellement. Les ordinateurs peuvent avoir des structures et des performances nettement différentes et sont reliés par des réseaux hétérogènes. Avantages  Modèle plus réaliste que PRAM  Meilleur passage à l’échelle des machines  Pas de problème de cohérence de la mémoire Inconvénients  Plus complexe à programmer ; intervention du programmeur dans le parallélisme  Temps d’accès aux données distantes 2. Architecture logicielle : les systèmes d’exploitation Il existe une relation étroite entre les applications distribuées et les systèmes d’exploitation. Dans un premier lieu, la mise en œuvre des applications distribuées dépendent des systèmes d’exploitation qui gèrent les différentes plateformes matérielles (c'est-à-dire les services qu’ils offrent). Dans un second lieu, les systèmes d’exploitation, eux-mêmes, peuvent être distribués (cas du système d’exploitation Chorus de Sun). On peut diviser les systèmes d’exploitation en deux catégories : Les systèmes fortement couplés et les systèmes faiblement couplés. Dans le premier cas, le système d’exploitation essaye de maintenir une vue globale unique des ressources qu’il gère. Ce type de système à tendance à rendre la répartition physique transparente au niveau des applications. Dans le deuxième cas, on a affaire à une collection de plateformes où chacune dispose de son propre système d’exploitation mais ces derniers coopèrent pour rendre leurs services et leurs ressources disponibles les uns aux autres, il s’agit des systèmes d’exploitation réseau. Notons qu’il est important de signaler que les systèmes d’exploitation constituent, eux aussi, des applications distribuées. Cependant, contrairement à ces dernières, ils sont implantés directement sur les plateformes matérielles et en dépendent fortement. a) Les systèmes d’exploitation distribués On en distingue deux types :
  • 14. M1:R&SD Page 14  Les systèmes des plateformes multiprocesseurs (MPOS) (considérés comme des systèmes repartis particuliers)  Les systèmes d’exploitation multiordinateurs (MCOS). i. Les systèmes des plateformes multiprocesseurs (MPOS) Ils sont conçus pour supporter les hautes performances en utilisant des processeurs multiples. Un des buts des MPOS est de rendre le nombre des processeurs transparents pour les applications. Dans ces systèmes, les processus communiquent via l’utilisation des données situées dans des emplacements de mémoire partagés c'est-à-dire un système dont :  Tous les programmes sont stockés dans la mémoire partagée  Une file d'attente unique des processus exécutable se trouve dans la mémoire partagée  L'ordonnanceur travaille en section critique pour éviter que deux processeurs ne choisissent le même processus à exécuter. La protection de ces emplacements (l'exclusion mutuelle) est faite par des sémaphores ou des moniteurs. Figure 10 : Système basés bu+ cache local + mémoire partagée ii. Les systèmes d’exploitation multiordinateurs (MCOS) Ils ont une structure totalement différente et complexe par rapport aux MPOS. Ceci est dû au fait que les structures de données communes ne peuvent être simplement placées dans une mémoire physique partagée. L’unique moyen de communication est l’envoi de messages. Figure 11 : Les systèmes d’exploitation multiordinateurs La figure ci-haut peut être interprétée comme suit. Chaque nœud du réseau possède un système d’exploitation qui permet de gérer les ressources locales : mémoire, processeur, disque, … . De même, chaque nœud possède un module chargé de la communication entre
  • 15. M1:R&SD Page 15 plateformes (envoi et réception de messages). Sur chaque noyau on greffe une couche commune qui implémente une machine virtuelle capable d’exécuter des tâches parallèles et concurrentes. Cette couche peut faire apparaitre tout le système d’ordinateurs comme une machine multiprocesseur en implémentant une mémoire partagée. D’autres services sont assignés à cette couche : affecter une tâche à un processeur, masquer les pannes matérielles, assurer la transparence à la localisation et la communication interprocessus. La programmation des systèmes MCOS est beaucoup plus difficile que la programmation des systèmes MPOS. La raison est que l’utilisation d’une mémoire partagée avec une protection par sémaphores ou moniteurs est plus simple que la manipulation des messages. Cette constations est derrière la solution qui consiste à créer des MCOS en modifiant les MPOS par l’émulation d’une mémoire partagée virtuelle à partir de la mémoire virtuelle de chaque nœud. Par exemple, on peut utiliser la pagination et avoir une mémoire repartie partagée basée sur la pagination. Les pages sont alors reparties sur tous les nœuds et on maintient une table globale des pages qui indiquent l’emplacement des pages sur les nœuds. C’est essentiellement la pagination classique excepté qu’au lieu d’utiliser le disque local, on utilise la mémoire virtuelle distante. Lorsqu’un processeur génère une référence d’une page qui n’est pas présente localement, un déroutement à lieu, le MCOS cherche la page et la ramène dans la mémoire locale au processeur ayant généré la référence, ce dernier pourra alors continuer son exécution. La figure suivante donne un exemple d’état d’une mémoire partagée virtuelle de 16 pages. Figure 12 : pagination et mémoire repartie partagée basée sur la pagination Des améliorations peuvent être apportées à cette solution si on considère que certaines pages sont accédées uniquement en lecture et peuvent de ce fait être dupliquées. b) Les systèmes d’exploitation réseau Dans ces systèmes, on ne suppose pas que les plateformes matérielles sont homogènes et on ne cherche pas à faire apparaitre l’ensemble comme un seul système. Il s’agit de réseaux où chaque nœud est une plateforme différente sur laquelle s’exécute un système d’exploitation différent. Les systèmes d’exploitation réseau offre divers services :
  • 16. M1:R&SD Page 16  Connexion avec une machine distante. Il s’agit de faire apparaitre une machine comme un simple terminal d’une autre (c'est-à-dire uniquement envoyer et afficher des caractères).  Copie de fichiers d’un nœud à un autre (sans transparence). Une amélioration courante de ces systèmes consiste à créer des serveurs qui cachent la répartition des fichiers sur les différentes machines et offrent un service de recherche et de transfert des fichiers aux machines qui sont alors considérées comme des clients. Figure 13 : Les systèmes d’exploitation réseau Un système d’exploitation réseau présente plusieurs inconvénients :  Manque de transparence (connexion explicite, copie de fichiers d’une machine à l’autre explicitement désignées).  Les machines étant indépendantes, elles sont gérées séparément (l’utilisateur d’une machine A à partir d’une machine B doit avoir un compte sur A et inversement, il faut alors gérer les mots de passes, les comptes et les droits accordés). En contre partie, l’ajout d’une machine peut se faire librement et à tout moment. a. Comparaison des systemes d’exploitations Dans cette partie, nous allons comparer les systèmes d’exploitation utilisés dans le système distribué.
  • 17. M1:R&SD Page 17 Tableau 1 : Comparaison des S.E 3. Architecture des applications distribuées Naturellement, les applications reparties ont plus d’indépendance vis-à-vis des plateformes physiques et peuvent de ce fait être organisées d’une multitude de façons. L’architecture client/serveur et ses variantes constituent actuellement les modèles le plus utilisés dans l’organisation des applications distribuées. Cependant d’autres modèles existent et leur utilisation augmente de jour en jour ; c’est le cas du modèle poste à poste (processus pairs) et ses variantes. Il n’est pas rare dans les applications distribuées que plusieurs modèles soient combinés à la fois pour tirer profit des avantages des uns et atténuer les inconvénients des autres. Dans la suite, nous allons présenter les différents modèles. a. Architecture Client/serveur C’est le modèle le plus utilisé et le plus important. Les processus représentant le système reparti, jouent les rôles de client pour un service et de serveur pour un autre. Dans le modèle Client/serveur, on distingue deux modèles selon que le service est effectué par un ou plusieurs serveurs. Dans ce dernier cas, plusieurs serveurs coopèrent pour exécuter une requête d’un client donnée.
  • 18. M1:R&SD Page 18 Figure 14 : Architecture client/serveur b. Le modèle du mandataire/Cache Un cache est un espace mémoire qui maintient une copie des objets récemment utilisés proches, vis-à-vis du client, que les objets originaux. Un objet reçu est ajouté au cache remplaçant éventuellement un objet existant. Lorsqu’un client demande un objet, le gestionnaire du cache essaye d’abord de le trouver dans le cache et le transmet au client. Si l’objet n’est pas dans le cache, le gestionnaire transmet la demande au serveur qui détient l’objet. Le cache peut être gère par le client lui-même comme il peut être gère par un gestionnaire indépendant dit serveur Mandataire (appelé aussi Proxy). Dans ce dernier cas, le cache peut être utilisé par plusieurs clients. Par exemple, dans le web, les mandataires maintiennent des caches des pages récemment visitées mais avant de livrer une page à un client, le mandataire vérifie au moyen d’une requête spéciale, du protocole HTTP, si la page qu’il a est conforme à l’originale. Les mandataires permettent d’augmenter les performances en diminuant le temps de réponse. Figure 15 : Modèle du mandataire c. Architecture paire-à-paire (Peer To Peer) Dans ce type d’architecture, il n’existe pas de distribution, en termes de clients et de serveurs, entre les composants (processus) d’un système distribué. Les processus jouent des rôles similaires et coopèrent d’égal à égal pour réaliser une activité repartie. Le terme Peer-to-Peer désigne tout simplement où les participants (les pairs) mettent en partage des ressources locales (qui peuvent être des capacités de traitement, des fichiers, des espaces de stockage, des moyens de communication, ...) sans utilisation de serveurs
  • 19. M1:R&SD Page 19 spécifiques. Les participants partagent les ressources locales en établissant des communications directes entre eux moyennant les protocoles TCP/IP. Ainsi, chaque participant est à la fois un client et un serveur. Il est un serveur de ce qu’il possède et souhaite partager et client de ce que les autres mettent à sa disposition. i. Avantages des systèmes Pair-à-pair Bien que l’utilisation dominante, des systèmes P2P, soit actuellement le partage de fichiers, le modèle pair-à-pair va bien plus loin que ce simple partage. En effet, il est possible de décentraliser des services et de mettre à la disposition des autres participants des ressources. Vu que chaque utilisateur d’un réseau pair-à-pair peut proposer des ressources et en obtenir, les systèmes pair-à-pair permettent de faciliter le partage d’informations et rendent la censure ou les attaques des services plus difficiles. En général, les systèmes P2P présentent certains avantages par rapport aux systèmes client- serveur :  Réduction des coûts. Au lieu d’acquérir un nouveau matériel pour construire une infrastructure client-serveur, il est possible d’utiliser les plateformes existantes avec une approche P2P ce qui évite des dépenses supplémentaires et réduit le cout d’administration.  Invariance à l’échelle (passage à l’échelle ou scalability): La distribution/duplication des ressources et services permet de repartir l’information sur l’ensemble du réseau P2P et évite l’apparition de goulots d’étranglements. Ce qui permet une bonne invariance à l’échelle.  Réseaux ad hoc : L’approche P2P est convenable pour les réseaux ad hoc où la connexion est intermittente. L’utilisateur est libre de se connecter ou se déconnecter au réseau pour des durées quelconques. L’approche est convenable pour des applications où un contrôle centralisé n’est pas envisageable. Cas de l’informatique diffuse, l’informatique mobile, …  La fiabilité : Vu que le bon fonctionnement d’un système P2P ne dépend pas d’un participant spécifique mais donne une importance égale à chaque, la fiabilité se trouve améliorée. En effet, la panne d’un nœud n’a pas d’influence sur le système dans son ensemble, ce qui n’est pas le cas lors de la panne d’un serveur dans une architecture client-serveur. Ces avantages font des systèmes pair-à-pair des outils privilégiés pour décentraliser des services devant avoir une haute disponibilité et des coûts de maintenance faibles. Il s’agit des services telsque : la diffusion des données multimédia, la distribution des logiciels et leurs mises à jour, la communication téléphonique et messagerie, la gestion des noms des domaines (DNS)), … ii. Les inconveniénts des systemes P2P L’approche P2P présente des inconvénients importants aussi. En effet, les problèmes de sécurité ou de compatibilité sont plus simples à résoudre dans un système doté d’un serveur central. De même, la disponibilité des ressources n’est pas toujours garantie lorsque les participants aux systèmes P2P sont peu nombreux. La rupture de la connexion par un
  • 20. M1:R&SD Page 20 participant peut rendre une ressource non accessible si elle n’est pas disponible chez d’autres participants. C’est typiquement le cas dans l’échange de fichiers. II. COMMUNICATIONS DANS LES SYSTEMESDISTRIBUES Maintenant que nous connaissons les différentes structures des systèmes distribués, nous abordons les différents mécanismes de communication réparties. Les technologies les plus utilisées aujourd’hui sont les suivantes :  Les Sockets  Les communications synchrones : RPC ou « message passing » des micronoyaux  Les RMI de JAVA  Le bus à objets distribués CORBA Les sockets et les RPC ne permettent pas de gérer directement les différences de modèle mémoire qui peuvent exister entre deux machines différentes. Les RMI sont spécifiques au langage JAVA. Cela impose l’utilisation d’un seul langage sur l’ensemble des hôtes qui désirent utiliser ce procédé. CORBA est indépendant du langage utilisé et des machines d’exécution. Il peut donc faire cohabiter des systèmes parfaitement hétérogènes. Le « message passing » impose d’implanter le même système d’exploitation sur les machines qui utilisent cette technologie. 1. Les sockets Une socket est défini comme l’extrémité d’une voie de communication dans une paire de processus. Ce lien inter processus comporte donc obligatoirement deux sockets. Une socket est construite par concaténation d’une adresse IP et d’un numéro de port. Les sockets sont utilisées dans bon nombre d’applications structurées en « client / serveur ». L’établissement d’une connexion entre deux processus se fait de la manière suivante :  Le serveur crée une socket et se positionne en écoute de demande de connexion.  Un client fait une demande de connexion (création d’une socket locale).  Le serveur accepte la connexion.  Le client et le serveur sont connecté par le tube ainsi crée et peuvent lire ou écrire dans leurs sockets respectives. A partir de cet instant, chaque processus (ou thread) peut être producteur ou consommateur de données. Dans le cas où deux machines communiquent mais possèdent des processeurs dont le modèle mémoire n’est pas le même, il faut prévoir de convertir les données. Une solution élégante est d’utiliser la couche XDR (« External Data Representation »). Cette technique permet de travailler en environnements hétérogènes mais n’est pas simple à mettre en œuvre. 2. La communication synchrone On entend par « communication synchrone » tout procédé qui permet d’exécuter une section de code distante de la même manière que si l’appel était local. L’exécution se fait de façon séquentielle vis à vis du programme.
  • 21. M1:R&SD Page 21 Figure 16 : Communication synchrone 3. RMI (Remote Method Invocation) Le langage JAVA augmente sa pénétration dans les systèmes informatiques distribués. Ce langage a été développé par la société SUN. Les applications (ou « applets ») JAVA s’exécutent sur une machine virtuelle (JVM : « Java Virtual Machine »). Cette technique permet de rendre le code indépendant de la structure matérielle de la machine d’exécution. Un thread peut invoquer une méthode appartenant à un objet distant. Un objet distant est un objet s’exécutant dans une autre JVM. Celle-ci peut très bien se trouver sur la même machine ou être située sur une machine distante. RMI permet, contrairement aux RPC, d’invoquer une méthode distante en passant en paramètres des objets complets. L’invocation de méthodes distantes passe par un système d’assemblage et désassemblage pris en charge par les « stubs » et les « squelettes ». Le « stub » est implanté coté client et crée un paquet contenant le nom de la méthode à appeler ainsi que les paramètres associés. Cet opération est baptisée « assemblage ». Le « squelette » reçoit les demandes venant des « stub ». Il est chargé du désassemblage des paquets et appel la méthode demandée par le client. Enfin il assemble la valeur de retour (ou éventuellement une exception) et la transmet au client. Les stubs et les squelettes sont des entités complètement transparentes pour le programmeur JAVA. Lorsque les paramètres sont des objets locaux, ils sont passés par copie. Cette opération se nomme « sérialisation d’objet ». Si un objet distant est passé en paramètre, le stub client passera la référence sur cet objet. Cela permettra au serveur d’invoquer à son tour des méthodes de l’objet distant. Pour qu’une méthode puisse être invoquée à distance, celle-ci doit être enregistrée dans un catalogue global nommé « RMI registry ». La recherche d’un objet distant se fait par concaténation du nom IP de l’hôte et du nom de la méthode cherchée : « rmi://nom_hôte/nom_méthode ».
  • 22. M1:R&SD Page 22 Cette méthode sous-entend que le programmeur connaît le ou les noms des machines qui exportent des objets. Les méthodes inscrites dans le système RMI peuvent être déclarée « synchronized ». Cela permet de gérer simplement l’accès concurrent de plusieurs threads sur une même méthode. Pour générer le « stub » et le « squelette », il faut utiliser le RMI compilé « RMIC ». Les RMI sont une technologie JAVA vers JAVA. Cela signifie qu’une application distribuée reposant sur les RMI, est forcément développée avec le langage JAVA. 4. CORBA (Common Object Request Broker Architecture) CORBA est un « middleware » (couche logicielle intermédiaire) orienté objets. CORBA signifie: « Common Object Request Broker Architecture ». L’objectif de CORBA est l’intégration d’applications distribuées hétérogènes à partir de technologies objet indépendamment :  des moyens de communication réseaux  des langages de programmation  des systèmes d’exploitation Toutes les requêtes à des objets distants passent par un ORB (« Object Request Broker »). L’ORB d’un client doit trouver l’objet distant dans le système distribué. Il communique avec L’ORB serveur. L’ORB est appelé « bus logiciel ». Comme pour les RMI, les objets s’inscrivent dans un catalogue global au système. Pour pouvoir communiquer avec un objet distant, un client doit au préalable trouver le nom de l’objet dans le catalogue. Un système CORBA fonctionne de la façon suivante : Dès qu’un client a obtenu une référence à un objet distant, toutes les invocations aux méthodes de cet objet passent par l’ORB (via le stub client). Lorsque l’ORB du serveur reçoit une requête, il appelle le « squelette » approprié. Celui ci invoque à son tour la méthode demandée. Des valeurs de retour peuvent être renvoyées par ce même canal de communication. III. SYSTEMES DE FICHIERS DISTRIBUES Les programmes informatiques manipulent des fichiers destinés à rendre persistantes les données traitées. Ces données peuvent être des informations de paramétrage, des résultats de calculs, des traces … Dans un système distribué, il est intéressant de posséder un système de fichiers distribué sur le réseau de façon à répartir l’information sur différents sites. Les différents systèmes de fichiers distribués se regroupent sous le terme SFD (Système de Fichier Distribué ou en anglais Distributed File System). 1. Objectifs des systèmes de fichiers distribués Dans l’idéal, un système de fichiers distribué doit apparaître aux clients comme un système de fichiers centralisé. Le SFD doit savoir localiser les fichiers d’un client et rendre transparent le transport des données lié aux différentes manipulations effectuées sur ces fichiers (lecture, écriture, copie). La transparence peut se situer à plusieurs niveaux parmi lesquels :
  • 23. M1:R&SD Page 23  Transparence d’accès : l’utilisateur ne se soucie pas du format de représentation des données et comment il accède au fichier ;  Transparence de localisation : l’utilisateur ne connaît pas où sont localisés les fichiers ;  Transparence de migration : les fichiers peuvent être déplacés sans modification de leur nom;  Transparence de réplication : l’utilisateur ne connaît pas le nombre de copies existantes ;  Transparence de concurrence : plusieurs utilisateurs peuvent partager en même temps le même fichier. Sur un système de fichiers centralisé, le temps d’accès à un fichier est essentiellement lié au support physique de stockage (le temps de traitement par le processeur local est négligeable face au temps d’accès des disques durs actuels). La performance d’un SFD, en terme de temps de réponse, est liée au réseau d’interconnexion des différents sites d’un système distribué. Pour chaque requête de lecture ou d’écriture, le système local subit le temps de traitement des différentes couches des protocoles utilisés pour la distribution de l’information sur le réseau. Un système de fichiers répartis a généralement deux composants distincts :  Service de fichiers: qui spécifie et gère les opérations sur les fichiers.  Service de répertoires: qui spécifie et gère les opérations sur les répertoires. 2. Le service de fichiers Un fichier est une séquence d’octets qui selon les systèmes a une sémantique particulière. Dans les grands systèmes, les fichiers sont structurés différemment en fonction de leur type. Un fichier a des attributs : propriétaire, taille, date de création, date de modification, droits d’accès, …. Le service de fichiers fournit des fonctions pour accéder à ces attributs. Les fichiers peuvent être créés, lus, modifiés, détruits. Certains systèmes n’autorisent pas la modification de fichiers. Seules les lectures et les créations sont autorisées. Ils sont appelés fichiers immuables. L’accès aux fichiers peut se faire selon deux modèles :  Le modèle chargement déchargement (Upload-download model).  Le modèle à accès distant (Remote access model). a. Le modèle chargement - déchargement L’accès aux fichiers s’effectue en récupérant la totalité du fichier sur le poste du client. Ensuite le fichier est entièrement renvoyé sur le serveur.
  • 24. M1:R&SD Page 24 Figure 17 : Le modèle chargement/déchargement Les avantages :  Simple d’utilisation.  Utilisation locale du fichier.  Le ficher est renvoyé lorsque le client a terminé. Désavantage :  Le traitement est effectué chez le client.  Besoin de ressources (mémoire) plus important.  Transfert entier du fichier même si peu de modifications. b. Le modèle à accès distant L’accès aux fichiers s’effectue au travers de requêtes de type client-serveur. Figure 18 : Le modèle à accès distant Les avantages :  Le traitement est effectué sur le serveur.  Besoin de moins de ressources (mémoire) sur le client. Désavantage : Accès concurrents à gérer. c. Le service de répertoires Le service de répertoires fournit les opérations nécessaires la gestion des répertoires et des sous- répertoires. La syntaxe pour les fichiers et les répertoires est spécifié par ce service (nom des
  • 25. M1:R&SD Page 25 fichiers, longueurs, etc.). Les répertoires dans les systèmes de fichiers répartis sont de structure hiérarchique. 3. La sémantique du partage des fichiers Lorsque deux ou plusieurs utilisateurs partagent le même fichier, une sémantique d’écriture et de lecture (protocole) doit être mise en place. Quatre méthodes coexistent : la sémantique UNIX, la sémantique de session et les transactions. a. La sémantique UNIX Le système assure que l’on obtient dans tous les cas la dernière version (dernière mise à jour) du fichier demandé. C’est-à-dire que la dernière mise à jour a été prise en compte. Dans les systèmes distribués, la sémantique UNIX peut-être implémentée s’il n’existe qu’un seul serveur de fichiers et si les clients ne cachent pas les fichiers. Toutes les lectures et écritures sont traitées séquentiellement par le serveur de fichiers. Par contre avoir un serveur de fichiers unique (centralisé) donne de très mauvaises performances. Il faut que les clients conservent les fichiers dans leur cache. Exemple :  C1 demande le fichier FIC1.  C1 modifie le fichier et le garde dans le cache.  C2 lit le fichier et n’a pas les dernières écritures de C1. Une solution serait de renvoyer immédiatement tous les changements au serveur. C’est une idée simple mais éfficace. Avantage : On est certain d’avoir la dernière mise à jour du fichier. Désavantage :  Son implémentation nécessite la centralisation du serveur de fichier et rend les opérations de lecture-écriture séquentielles.  Les problèmes de latence réseau. b. La sémantique de session Les modifications apportées à un fichier sont renvoyées au serveur à la fermeture du fichier. Seuls les processus locaux voient les modifications. Les machines sont averties d’une modification à la fermeture du fichier. C’est plus performant que la sémantique UNIX, mais cela pose la problématique de la cohérence de l’information si deux fichiers sont modifiés en même temps.
  • 26. M1:R&SD Page 26 c. Les transactions atomiques Pour accéder à un fichier ou à un groupe de fichiers, le processus exécute un BEGIN_TXN et END_TXN. Entre les deux instructions, tout sera effectué de manière indivisible. Cela permet la cohérence d’accès aux fichiers. 4. L’implémentation des systèmes de fichiers répartis Comment sont implémentés les systèmes de fichiers répartis. a. Utilisation des fichiers Les mesures effectuées par différents chercheurs montrent que tous les systèmes de fichiers présentent les similitudes suivantes :  La plupart des fichiers ont de petites tailles (<10Ko).  Les opérations de lecture sont plus courantes que les opérations d’écriture.  Les lectures et les écritures sont séquentielles (accès aléatoires rares).  La plupart des fichiers ont une durée de vie faible.  En moyenne les processus utilisent peu de fichiers.  Il existe différents types de fichiers. b. Structure du système Comment sont organisés en interne les services de fichiers et les services de répertoire. Trois structures peuvent être considérées.  Client-serveur.  Structure services.  Conservation des statuts des clients. a. L’aspect client-serveur Plusieurs approches :  Pas de distinction entre client et serveur. Le logiciel est le même pour tous. Le client qui veut offrir des services de fichiers ou de répertoires peut le faire. Il suffit qu’il export le nom des répertoires sélectionnés.  Le logiciel client et le logiciel serveur sont différents. Ils peuvent néanmoins s’exécuter sur la même machine.  Client et serveur tournent sur des machines séparées. b. Structure services Deux approches :  Un serveur gère les deux services.  Un serveur a la charge des services de fichiers et un autre des services de répertoires. Cette approche est plus flexible, mais génère des problèmes de communication. En effet, ouvrir un fichier oblige l’appel du serveur responsable des services de fichiers et celui qui est responsable des services de répertoire.
  • 27. M1:R&SD Page 27 Le service de répertoire fournit le nom binaire au client qui interrogera ensuit le serveur responsable des services de fichiers. Dans le cas de système de fichiers réparti, les répertoires peuvent être sur des serveurs différents. c. Conservation des statuts sur le client La conservation des informations sur le client permet au serveur de garder la trace de sa connexion avec un client. Deux écoles s’affrontent :  Serveur sans conservation d’états (Stateless server) : le client fait une demande, le serveur y répond et efface toutes les traces de la connexion avec le client.  Serveur avec conservation d’états (Statefull server) : le client fait une demande, le serveur y répond et garde toutes les traces de la connexion avec le client. Dans le cas d’un serveur sans conservation d’états un client ouvre, lit, met à jour et ferme les fichiers. Le serveur ne garde pas d’informations sur le traitement en cours (le client, le fichier ouvert, etc.). Le client doit rajouter toutes les informations nécessaires à ses demandes. Cela augmente la taille des messages. Tandis que dans le cas d’un serveur avec conservation d’états, si le serveur crashe on perd les informations, on ne sait plus qui accédait à quoi. Si c’est le client qui crashe, le serveur conserve des informations non nécessaires. 5. Les mécanismes de cache Quatre lieux de stockage de fichiers, les quatre ayant de propriétés différentes. Le plus évident est de stocker les fichiers sur le disque du serveur. Il n’y aura qu’une seule occurrence du fichier dans le système. Les disques des serveurs sont en principe de taille plus importante. Il nous faudra faire face alors à un problème de performance (temps d’accès au disque lent).On perd du temps à aller chercher le fichier sur le disque du serveur. Afin d’éviter trop d’accès au disque, on va garder dans la mémoire du serveur les fichiers les plus récemment demandés (cache). Le cache serveur est facile à implémenter, mais n’évite pas les accès réseau. Pour éviter les accès réseau, il va falloir implémenter un cache sur le client. Ce cache sur le client va amener la plupart des problèmes de cohérence et d’intégrité. Mais c’est la solution la plus performante. Pour implémenter cette solution, nous avons trois possibilités : 1. Le cache est dans l’espace du processus. 2. Le cache est dans le noyau. 3. Un processus utilisateur spécifique assure la gestion du cache.
  • 28. M1:R&SD Page 28 Figure 19 : Mécanisme d’implantation de cache Fonctionnement : 1. Lorsque le processus se termine, les fichiers modifiés sont renvoyés au serveur. 2. Tous les processus tirent parti du cache dans le noyau. Très intéressant pour les processus qui partagent des fichiers ou utilisent les mêmes fichiers. Par contre le noyau est très fréquemment sollicité. 3. Ne surcharge pas le noyau. Est facile à coder et est modulaire. Mais le bon fonctionnement du cache dépend aussi du CPU (exécution des RPCs entre serveurs et entre processus) et du réseau (transfert et requêtes entre serveurs). Dans tout le cas, une fois le cache mis en place, il faut en assurer la cohérence. 6. La cohérence du cache Le cache client introduit de l’inconsistance et peut aboutir à rendre le système incohérent. Si deux clients lisent simultanément le même fichier et si les deux le modifient, plusieurs problèmes peuvent survenir. Si un troisième lit le fichier il n’obtiendra aucune des deux versions mais la version originale. Un autre problème est le fait que le dernier qui écrira invalidera les modifications de l’autre. La gestion de la cohérence de cache client peut être effectuée selon quatre méthodes ou algorithmes :  Ecriture immediate (Write through).  Ecriture différée (Delayed write ou write back).  Ecriture à la fermeture (Write on close).  Contrôle centralisé (Centralized control). a. Ecriture immédiate Dès qu’une entrée dans le cache est modifiée (fichier ou bloc), la nouvelle valeur est gardée dans le cache mais renvoyée immédiatement au serveur. Un autre client qui lit le fichier voit ainsi la valeur la plus récente. Conséquence : problème de cohérence.
  • 29. M1:R&SD Page 29 Par exemple: - C1 lit le fichier FIC1 et termine, mais FIC1 reste dans le cache. - C2 lit FIC1, le modifie et l’écrit sur le serveur. - C1 lit le fichier FIC1, il l’a dans le cache. Il ne va donc pas le chercher sur le serveur. - La version de FIC1 est obsolète pour C1. Une des façons de régler le problème et de demander au serveur un contrôle sur les dates (ou la version, ou checksum) avant d’utiliser un fichier. b. Ecriture différée Au lieu d’envoyer les informations immédiatement après la modification, le client note les modifications et toutes les x secondes (30 secondes par exemple), envoie en une fois toutes les modifications au serveur. Une demande d’écriture de beaucoup d’informations est généralement plus performante que plusieurs demandes avec moins d’informations. Cette méthode est très efficace si l’on a : Lecture– Modification – Destruction d’un fichier avant l’envoi au serveur. En effet, le serveur n’aura dans ce cas rien à faire. c. Ecriture à la fermeture L’écriture ne se fait qu’à la fermeture du fichier. En fait, il vaudrait mieux attendre 30 secondes après la fermeture pour être certain que le fichier ne va pas être détruit. On ne s’affranchit pas du problème du dernier qui écrit. En fait ce n’est pas pire que dans un système monoprocesseur lorsque deux processus écrivent en même temps. d. Contrôle centralisé C’est une approche totalement différente qui utilise un algorithme centralisé dont le fonctionnement est le suivant :  Les ouvertures de fichier sont demandées au serveur de fichiers.  Le serveur de fichier tient une table à jour en répertoriant qui utilise quoi.  Toutes les demandes de lecture sont acceptées.  Les demandes d’écriture sont rejetées et mises dans une file d’attente.  Le serveur peut envoyer un message pour dire au client d’invalider un fichier de leur cache. Plusieurs algorithmes existent. Mais ont tous un maillon faible (unique point de panne) : le serveur. Avec cet algorithme, plusieurs écritures et lectures peuvent être effectuées concurremment avec des résultats ni meilleurs ni pires que pour un système monoprocesseur. 7. La duplication (Réplication) Les systèmes de fichiers répartis offrent des mécanismes de copie de fichiers.
  • 30. M1:R&SD Page 30 Les raisons de ces fonctionnalités sont :  Augmentation de la sécurité (backup de fichiers). Si un serveur a un problème les données sont sauvegardées (sécurité).  Possibilité d’accéder à un fichier même si le serveur qui l’héberge normalement est arrêté (disponibilité).  Répartition du traitement sur plusieurs serveurs (performance). Trois modes de réplication peuvent être envisagés : 1. La réplication transparente : l’utilisateur peut totalement contrôler la réplication. Néanmoins Le serveur effectue les réplications de manière transparente pour l’utilisateur. 2. La réplication différée : La copie est créée sur un serveur, ensuite (plus tard) elle est dupliquée par celui-ci sur d’autres serveurs. C’est le serveur maître qui a la charge de retrouver les copies. Note : des changements pourraient être effectués sur le fichier avant la copie. 3. La réplication par groupes de communication : Dans ce cas toutes les demandes d’écriture sont faites simultanément sur plusieurs serveurs. Toutes les copies sont créées en même temps. La présence de plusieurs copies du fichier implique qu’à un nom symbolique va correspondre plusieurs noms binaires. 8. La modification des fichiers Ce sont les protocoles à mettre en place pour la modification des fichiers. a. La copie primaire Fonctionnement :  Un serveur est désigné comme étant le serveur primaire. Tous les autres sont secondaires.  Tout changement est envoyé au serveur primaire qui répercute les changements localement, puis envoi les demandes de changement aux serveurs secondaires. Si le serveur primaire est arrêté, il n’y a plus de mises à jour possibles. Une méthode plus robuste doit être considérée. b. Le vote L’idée est que le client doit demander et acquérir la permission de plusieurs serveurs avant de lire ou d’écrire un fichier dupliqué. Algorithme  Un fichier est dupliqué sur N serveurs.  Pour une mise à jour du fichier, N/2+1 serveurs doivent donner leur accord (cette règle peut être adaptée).  Si N/2+1 serveurs sont d’accord, alors le fichier est modifié et son numéro de version incrémenté.
  • 31. M1:R&SD Page 31  Pour lire un fichier, le client doit contacter au moins N/2+1 serveurs et demander le numéro de version.  Si les N/2+1 numéros de version sont identiques, il a la version la plus récente du fichier. CONCLUSION Parvenu au terme de notre travail où il était question pour nous de faire un exposé sur les systèmes distribués. Pour ce faire, nous avons commencé par la présentation de façon générale des systèmes distribues, des architecture des systèmes distribues, des différents types communications dans les systèmes distribues et enfin les systèmes de fichiers distribues.
  • 32. M1:R&SD Page 32 Bibliographie [1] Dr D. Meslati, Systèmes distribués : Principes et concepts, Université de Annaba, [2] Benmoussa Yahia, Systèmes de fichiers distribués étude de cas: NFS Network File System, Université M’hamed Bougara de Boumerdès, [3] Rachid GUERRAOUI, Esther PACITTI, Routage des Transactions dans les Bases de Données à Large Echelle, thèse de doctorat, l’Université Pierre et Marie Curie (Paris VI), 2010, [4] Jacques LAFORGUE, Cours "Systèmes et réseaux répartis" NFP 214, [5] P. SWEID, Cours NFP111 – SAR - Chapitre 01 – Partie01 –Introduction.