Université des Sciences et Technologies Houari Boumediene

Faculté d’Informatique

Système de gestion des

fichiers répartis
 Introduction
Fichier = Abstraction de mémoire permanente : une séquence de données similaires non interprétées
(items) souvent de taille un octet
• Accès séquentiel : on lit ou écrit des sous séquences d’items sur un pointeur courant.
• Accès aléatoire : accès direct dans le fichier sur une adresse calculée (par exemple en fonction d'une
clé hachée).
• Accès indexé : utilisation d’un index accédé sur une clé pour obtenir une adresse dans le fichier.

Système de fichiers : logiciel dédié à

• La création et la destruction de fichiers
• L’enregistrement d’articles dans un fichier
• La restitution d’articles
• Le nommage
• Le partage
• La protection
 Système de fichiers répartis

Situation : différents systèmes de fichiers attachés à différents hôtes d’un système réparti.
Objectif : Réaliser la transparence des systèmes de fichiers à la répartition.
 Challenges dans un SGFR

• Désignation (nommage, ‘naming’): Construire une désignation (un nommage) uniforme des fichiers
cohérent avec les différents systèmes.
• Localisation: Retrouver dans le systèmes réparti quel hôte gère un fichier.
• Accès distant: Accéder effectivement aux fichiers sur leur site de résidence.
• Concurrence: Gérer les accès concurrents en univers réparti.
• Pannes: Panne des serveurs de fichiers, panne du réseau ->partition du réseau.
• Performances: Assurer des performances acceptables (similaire à l’univers centralisé).
• Hétérogénéité: Des processeurs, des systèmes d’exploitation.
• Extensibilité (‘Scalability’): Fonctionnement dans de grandes configurations.
• Migration: Déplacement des fichiers d’un système à l’autre
• Réplication: Existence de copies multiples des fichiers
 Services et protocoles
Service
• Service d’accès aux données: lecture, écriture aléatoire, écriture en fin de fichier (‘appending’)
• Service de gestion des répertoires : création et destruction de fichiers dans des répertoires.

Serveurs de fichiers
• Un processus distant qui tourne sur une machine distante et implante un service de fichiers.

Protocole de fichier réparti

• Les échanges de requêtes qui transforment des primitives du service en opérations d’un serveur de
fichier distant.
 Transfert de fichiers

Service de transfert de fichiers complets

• Mode Upload / Download.
• Service défini par une opération principale: transférer un fichier (lire à distance et écrire localement un fichier
complet).
• Les accès au fichier sont réalisés ensuite sur le site client.
• Si nécessaire (après modifications) le fichier est retourné sur son site d’origine (le serveur).
• Exemple type : FTP ‘File Transfer protocol’
• Autres exemples : Kermit, UUCP (‘Unix to Unix Communication Program’), FTAM (OSI ‘File Transfer
Access and Management’).
Avantages
• Simplicité très grande.
• Accès au fichier non partagé (sauf sur le site client).
Inconvénients
• Si le volume est très important et si l’accès ne porte que sur une petite partie du fichier, transférer tout le
fichier est inutile.
• Le fichier occupe de la place sur différents sites.
• Si les écritures sont concurrentes => partage des modifications très difficile (techniques d’invalidation ou
réconciliation des versions)
 Le modèle d’accès distant

Service d’exécution de primitives d’accès fichiers à distance

• sur le site serveur: Mode ‘Remote Access’ (page à la demande).
• Le service défini l’ensemble d’opérations sur fichiers (créer, détruire, ouvrir, fermer, lire , écrire,
modifier des attributs etc …).
• Les opérations sont réalisés sur le site serveur (le système de fichier ne s’exécute que sur le site serveur).
• Exemple type NFS : ‘Network File System’
• Autres exemples : AFS (‘Andrew File System’, Coda, Microsoft DFS (‘Distributed File System’)
Avantages
• On ne transfère pas tout le fichier: uniquement ce sur quoi on travaille.
• On n’utilise pas d’espace disque sur le site client.
• Les accès partagés entre clients sont possibles sur le serveur: une seule copie que l’on peut soumettre à
un contrôle de concurrence.
Inconvénients
• Si de nombreuses opérations sont réalisées sur le même article: beaucoup d’échanges inutiles.
• Système de fichiers plus complexe à développer que les outils de transfert complet de fichiers.
Transfert VS Accès à distance
 Désignation : Dépendance ou indépendance des noms à la localisation
Deux idées d’indépendance
• Adressage : le nom d’un fichier (un chemin d’accès) ne comporte aucune indication (directe) sur la
localisation du fichier.
• Migration : le nom d’un fichier n’est pas modifié lorsqu’on le déplace d’un support à un autre (on réalloue
ses blocs).
Exemple de dépendance de la localisation
• Structure des noms : /serveur/rep1/rep2/rep3/Fich
• Le nom d’un fichier comporte celui du serveur de résidence physique du fichier.
• Un fichier ne peut-être déplacé sans changer de nom.
Exemple d’indépendance de la localisation
• Structure des noms : une arborescence unique globale à tous le système réparti /rep1/rep2/rep3/Fich
• Le nom d’un fichier ne donne pas d’informations sur l’emplacement physique du fichier (l’emplacement
est donné par consultation du catalogue).
• Un fichier peut-être déplacé sans changer de nom.
 Désignation : Trois catégories principales de systèmes de désignation

Nom de machine + chemin d’accès local : /machine/chemin_local ou machine:chemin_local

• Les premiers systèmes de fichiers répartis (‘Newcastle Connection’)
Montage : d’un système de fichier distant sur la hiérarchie locale (extension du montage en local).
• SUN NFS
Construction d’un système de nommage complètement nouveau : dans lequel tous les fichiers
reçoivent un nom universel (qui a la même forme pour tous les serveurs et tous les clients).
• Systèmes de fichiers : Chorus, Mach, Amoeba, Apollo
 Problème du contrôle de concurrence

• Terminologie multiple : Contrôle de concurrence, de cohérence, de consistance (‘Consistency

Semantics’)
• Objectif : définir les entrelacements légaux d’opérations lire et écrire (l’instant ou modifications
apportées à un fichier par un usager sont observables par les autres usagers).
• Indispensable : pour prédire le comportement d’un programme qui utilise un fichier lorsque ce fichier
est partagé.
• Délimitation des accès :
• aucune délimitation,
• entre une opération d’ouverture et opération de fermeture,
• des instants quelconques de début et fin de transaction séquence
 Partage de l’accès aux fichiers

Les quatre versions

• Sémantique UNIX : chaque opération est instantanément visible pour tous les autres
usagers.
• Sémantique de session : aucune modification n’est visible jusqu’à ce que le fichier soit fermé.
• Fichiers non mutables : aucune modification n’est autorisée.
• Approche transactionnelle : toutes les modifications sont visibles par tous ou par personne (approche
atomique)
 La sémantique Unix
Définition : une écriture est visible immédiatement par tous les autres usagers qui ont ouvert le fichier (s’ils
effectuent une lecture ces usagers obtiendront la nouvelle valeur écrite).
Autre terminologie : cohérence/consistance atomique, les requêtes sont traitées en séquence dans l’ordre des
dates de leur émission.
réalisation
• si l’on accède à un seul serveur de fichiers
distants, que les clients n’ont pas de cache. =>
Le serveur peut traiter les requêtes en séquence
dans l’ordre temporel.
• Si les clients ont un cache => lorsqu’une
modification est réalisée, la nouvelle copie est
immédiatement partagée au serveur mais cette
solution est inneficace (délais de transmission,
conflit d’accès, besoin de synchronisation des
opérations concurrentes,…).
 La sémantique de session
Définition
• Chaque intervalle entre une ouverture (open) et une fermeture (close) forme une session.
• Les modifications d’un usager sont visibles par lui.
• Tous les autres usagers ayant déjà ouvert le fichier ne peuvent voir ces modifications.
• Lorsqu’un fichier est fermé les modifications deviennent visibles aux autres usagers qui commencent une
session après la fermeture.
Réalisation
• Solution de base
-Chaque utilisateur travaille sur sa propre copie du fichier
(au moins pour ce qui concerne les enregistrements
modifiés).
-Lorsque le fichier est fermé les modifications sont
reportées sur la copie du serveur.
Problème : que deviennent les écritures
générées en parallèle par plusieurs usagers?
Solution=> chaque fichier étant fermé à son tour, sa
valeur est renvoyée au serveur, de sorte que le résultat
final dépend de la requête de clôture la plus récemment
traitée par le serveur
 Fichiers non mutables ‘Immutables’
• Utilisé dans le cas ou on ne nécéssite pas de mise à jour sur les fichiers
Trois opérations seulement sont prévues
• Création d’un fichier :
• Par écriture complète du fichier à partir de la mémoire centrale ou d’un autre fichier.
• Des que le fichier est créé (qu’il est déclaré partageable il ne peut plus être modifié par personne).
• Destruction du fichier.
• Lecture du fichier.
• Une modification de fichier ne peut être obtenue que par recréation d’un autre fichier.
Solution rare
• Pour des fichiers de petite taille en éditeur de texte.
• Qui facilite le partage mais le problème des modifications en parallèle subsiste.
Problème : des fichiers de grande taille souvent modifiés => utiliser en parallèle d’autres systèmes de
fichiers.
Exemple : système réparti Amoeba.
 L’approche transactionnelle

• Les opérations sur les fichiers sont effectuées à travers des transactions c'est-à-dire des opérations
composées qui s’exécutent de manière atomique.
• Délimitation de transactions : comportant ouverture, fermeture et accès à des fichiers.
• Garantie des propriétés transactionnelles : sur les lectures et écritures aux fichiers.
• Transactions sérialisées: tout se passe comme si les transactions (suites d’opérations) avaient été
réalisées en séquence.
• Réalisation : moniteur transactionnel.
• Concurrence entre les accès limitée : si de nombreuses écritures sont effectuées.
 Exemple de quelques systèmes de fichiers

• Un système de fichiers centralisé : NFS

• Un système de fichiers basé sur les clusters:GFS
• Un système de fichiers décentralisée: IVY
• Un système de fichiers pour un environnement mobile
 Architecture centralisée: File Network System NFS

• Crée par Sun Microsystem

• l'un des plus largement déployés pour les systèmes basés sur UNIX.
• Chaque serveur de fichiers fournit une vue standardisée de son système de fichiers local => peu importe
comment ce système de fichiers local est implémenté; Chaque serveur NFS prend en charge le même
modèle.
• NFS est livré avec un protocole de communication qui permet aux clients d'accéder aux fichiers stockés
sur un serveur => des processus hétérogènes exécutés sur différents systèmes d'exploitation et machines
de partager l’accès aux fichiers distribués sur les diverses machines.
• NFS offre un modèle d’accès aux fichiers où les clients bénéficient d'un accès transparent=> Les clients
ignorent généralement l'emplacement des fichiers.
• Le client ne dispose que d'une interface contenant diverses opérations sur les fichiers, mais c’est le
serveur qui est responsable de l'implémentation de ces opérations=> Ce modèle est appelé modèle
d'accès à distance
Fonctionnement
• Un client accède au système de fichiers en utilisant les appels système fournis par son système
d'exploitation local.
• L'interface du système de fichiers UNIX local est remplacée par une interface avec le système de fichiers
virtuels (VFS), qui est une norme pour l'interfaçage avec différents systèmes de fichiers.
• Pratiquement tous les systèmes d'exploitation modernes fournissent VFS.
• Avec NFS, les opérations sur l'interface VFS sont soit transmises à un système de fichiers local, soit
transmises à un composant distinct connu sous le nom de client NFS, qui gère l'accès aux fichiers stockés
sur un serveur distant.
• Dans NFS, toutes les communications client-serveur sont effectuées via des appels RPC.
• Le client NFS implémente les opérations du système de fichiers NFS en tant que RPC sur le serveur. Les
opérations offertes par l'interface VFS peuvent être différentes de celles offertes par le client NFS. L'idée
du VFS est de cacher les différences entre les différents systèmes de fichiers.
• Le serveur NFS est responsable de la gestion des demandes des clients entrants.Les requêtes RPM
unmarshals stub et le serveur NFS les convertissent en opérations de fichier VFS régulières qui sont ensuite
transmises à la couche VFS. Encore une fois, le VFS est responsable de l'implémentation d'un système de
fichiers local dans lequel les fichiers réels sont stockés.
• NFS a pour avantage d’être indépendant des systèmes de fichiers locaux. Peu importe que le système
d'exploitation du client ou du serveur implémente un système de fichiers UNIX, un système de fichiers
Windows,...
 Architecture décentralisée (basée cluster): Google File System GFS
• Souvent utilisés dans le cas des applications parallèles où le nombre des accès peut être très important et où les
fichiers sont volumineux.
• La technique de répartition d’un fichier où le contenu d’un même fichier est distribué sur plusieurs serveurs.
• En distribuant un fichier volumineux sur plusieurs serveurs, il devient possible d'aller chercher différentes parties en
parallèle.
=>une telle organisation ne fonctionne bien que si l'application est organisée de manière à ce que l'accès aux données est
parallèle.

• Un système de fichiers distribués pour de très grands centres de données tels

que ceux utilisés par des sociétés comme Amazon et Google.
• Google a développé son propre système de fichiers Google (GFS).
• Les fichiers Google ont tendance à être très volumineux, allant généralement
jusqu'à plusieurs gigaoctets.
• De plus, les mises à jour de fichiers se font généralement en ajoutant des
données plutôt qu'en supprimant des parties d'un fichier. Aussi, pour Google,
les défaillances de serveurs sont la norme plutôt que l'exception, conduisent à
construire des grappes de serveurs.
Fonctionnement de GFS
• Chaque cluster GFS se compose d'un seul maître avec plusieurs serveurs de blocs.
• Chaque fichier GFS est divisé en blocs de 64 M octets chacun, après quoi ces fragments sont répartis sur ce qu'on appelle les
serveurs de blocs.
• Un maître GFS est contacté uniquement pour les informations de métadonnées (description des données).
• Un client GFS transmet un nom de fichier et un index de tronçon au maître, en attendant une adresse de contact pour le
fragment. L'adresse de contact contient toutes les informations permettant d'accéder au serveur de bloc concerné pour
obtenir le fragment de fichier requis.
• Le Master GFS maintient essentiellement des structures qui lui permettent de localiser le serveur d’une partition.
• Les fragments sont répliqués pour gérer les pannes.
• Le Master GFS ne tente pas de garder un compte précis des emplacements des fragments. Au lieu de cela, il contacte
occasionnellement les serveurs de blocs pour voir quels fragments ils ont stockés. L'avantage de ce schéma est la simplicité.
 Architecture décentralisée basée P2P: IVY
• Il existe des systèmes de gestion de fichiers distribués à base d’organisations entièrement symétriques basées sur la
technologie peer-to-peer. La majorité de ces propositions utilisent un système basé sur une DHT (Distributed Hash table)
pour la distribution des données, combinée avec un mécanisme de recherche basé sur les clés.
• Une DHT (table de hachage distribuée ) permet le stockage et la répartition des données sur le réseau où chaque noeud
est responsable d’une partie des données.
• C’est une structure de données de type (clé, valeur) tel que chaque donnée est associée à une clé.
• La structure de la DHT est associé un algorithme de localisation d’une donnée à partir de la clé. L’espace de stockage
peut être vu comme :
• Un ensemble de blocs de données
• Ou, un ensemble de fichiers
Exemple: Ivy
La couche Ivy:
• Interpréter les blocs comme fichier. Elle offre une interface aux applications et aux utilisateurs.
• Ivy utilise deux types de blocs de données:
• Un bloc de hachage de contenu a une clé associée, qui est calculée comme le hachage sécurisé du contenu du
bloc. De cette façon, chaque fois qu'un bloc est recherché, un client peut immédiatement vérifier si le bon bloc
a été recherché, ou qu'une autre version ou une version corrompue est retournée.
• Des blocs de clé publique, qui sont des blocs ayant une clé publique comme clé de recherche, et dont le
contenu a été signé avec la clé privée associée.

• Opérations de mise à jour:

• chaque utilisateur conserve un journal des opérations qu'il effectue sur les fichiers.
• Les opérations d’écritures sont stockées sur le journal
• Lors de l’exécution des opérations de lecture, le serveur consulte le, journal pour récupérer les dernières
valeurs stockées.
 Un Système de Gestion de Fichiers distribués pour environnement mobiles : CODA

• CODA est un système de gestion de fichiers pour un environnement distribué à grande échelle qui a été adapté aux
utilisateurs mobiles. Il est basé sur le modèle de communication Client/Serveur strict.
• CODA apparaît à l’utilisateur comme un système de fichiers Unix partagé traditionnel. Il fait une distinction entre
les sites serveurs, qui sont des machines physiques sûres et les sites clients qui sont sur des machines dispersées et
qui peuvent être mobiles et déconnectées pour de longues périodes.
• CODA permet à des clients d’accéder aux fichiers stockés dans le cache local tout en étant déconnectés des serveurs.
Le but d'un tel système est d’offrir aux clients la continuité d’accès aux données en cas d’éventuelles déconnexion ou
de pannes. Il permet aux utilisateurs de fonctionner en mode déconnecté.

Partage de fichiers dans Coda : Pour faciliter le partage de fichiers, le système de fichiers Coda utilise un schéma
d'allocation spécial.
• Lorsqu'un client ouvre avec succès un fichier f, une copie entière de f est transférée sur la machine du client.
• Si un client A a ouvert le fichier f pour l'écrire, lorsqu'un autre client B veut également ouvrir f, il échouera. Cet
échec est dû au fait que le serveur a enregistré que le client A a déjà modifié f.
• D'un autre côté, si le client A avait été ouvert pour la lecture, une tentative par le client B d'obtenir une copie du
serveur pour la lecture réussirait. Une tentative d'écriture de B réussirait également.