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

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.