Systèmes de gestion de fichiers répartis

implante un service de fichiers.

Protocole de fichiers répartis

Les échanges de requêtes qui transforment des primitives du

service en opérations d’un serveur de fichiers distant.

ENSI

Systèmes et applications répartis

15

Quelques

critères de classification

 Communications : utilisation des messages ou du RPC.

 Serveurs :

avec ou sans état.

mono ou multi processus

 Désignation/nommage : structure de l’espace de noms de

fichiers.

 Sémantique du partage : “Unix”, session, transaction.

 Caches et duplication : caches clients , caches serveurs,

cohérence des caches

 Tolérance aux fautes : duplication, reprise

 Sécurité : modèles d’authentification, de protection …

ENSI

Systèmes et applications répartis

16

Le modèle de transfert de fichiers

 Service de transfert de fichiers complets :

Mode Upload / Download (pré chargement).

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’

ENSI

Systèmes et applications répartis

17

Le modèle de transfert de fichiers

 Cacher localement sur le client tout ou partie du fichier

 Latence réduite

 Serveur moins chargé

 Problèmes de cohérence

ENSI

Systèmes et applications répartis

18

Transfert de fichiers :

avantages /inconvénients

 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)

ENSI

Systèmes et applications répartis

19

Le modèle d’accès distant

Service d’exécution de primitives d’accès aux fichiers

à distance sur le site serveur: Mode ‘Remote Access’

(page à la demande).

Le service définit 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ées sur le site serveur (le système

de fichiers 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’)

ENSI

Systèmes et applications répartis

20

Le modèle d’accès distant

Envoi de toutes les requêtes et leurs paramètres au

serveur

Le fichier reste sur le serveur

Pas de problème de cohérence!

Latence pour chaque opération

Serveur = goulot d'étranglement

ENSI

Systèmes et applications répartis

21

Modèle d’accès distant : Avantages et inconvénients

 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.

ENSI

Systèmes et applications répartis

22

Architecture générique du SGFR

 Le SGFR est composé de :

 Module côté client

 Offre une API pour solliciter le système de fichiers

 Localise le serveur de fichiers

 Module de gestion de noms

 Crée et gère les fichiers dans les répertoires des noms (Structure de

données ou SDD du système)

 Deux modes de désignation : intégré (dans le serveur de fichiers) ou séparé

(serveur de noms)

 Module de gestion de fichiers

 Effectue les opérations sur les fichiers : création, lecture, écriture,

destruction …

 Gère l’accès au bloc de fichiers.

 Module d’accès aux fichiers

 Accès local ou distant

 Module de gestion de cohérence

ENSI

Systèmes et applications répartis

23

Architecture générique du SGFR

ENSI

Systèmes et applications répartis

24

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.

ENSI

Systèmes et applications répartis

25

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 fichiers 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

ENSI

Systèmes et applications répartis

26

Désignation : arborescence de désignation

unique

 La vue logique des fichiers est la même sur toutes les machines. Les

noms sont globaux.

 Les fichiers sont physiquement répartis sur les serveurs.

 Cette solution s'appuie sur des noms internes uniques dans le temps et

dans l'espace (UID).

ENSI

Systèmes et applications répartis

27

Techniques de Résolution des noms : Transformation

du chemin d'accès

 Principe : Chaque machine résoud le morceau de chemin qui la

traverse.

 Un client veut accéder au fichier /a/b/c :

1. Client -> M1 qui reçoit tout le chemin

2. sur M1 :

 - / évalué sur M1 : donne le nom interne "racine", on va sur le disque

 - dans le répertoire racine on trouve le nom interne de "a", on va sur le disque

 - dans le répertoire "a", on trouve une indication telle "b dans ss-arbre sur M2", on passe

/b/c à M2

3. sur M2 : le reste du chemin /b/c/ est évalué de la même façon, /c est passé

à M3

4. sur M3 la fin du nom est résolu et retour du résultat au client

ENSI

Systèmes et applications répartis

28

Techniques de Résolution des noms : Autre variante de la

transformation de chemin d'accès

 Résolution par chaque serveur et retour au client après

chaque étape

L'effort de résolution est supporté surtout par le client.

Solution adoptée par NFS.

ENSI

Systèmes et applications répartis

29

Techniques de Résolution des noms : Méthode

des identificateurs structurés

 Utiliser un identificateur structuré qui identifie une sous-arborescence

qui contient le fichier cible.

 identificateur structuré (is):

 < identif de ss-arbre ; identif de fichier dans le ss-arbre>

 Une table contient sur chaque site la correspondance : nom symbolique <-> id ss-

arb

 La table peut être gérée de différentes façons :

 -> remplissage suivant le principe de résolution par transformation de chemin d'accès

 -> gérée sur chaque site à l'image d'un cache ou accédée sur un serveur de noms

– Exemple :

 Le nom est indépendant de la localisation, quand le fichier migre il suffit

de mettre à jour la table.

ENSI

Systèmes et applications répartis

30

Techniques de Résolution des noms : Méthode des caches de

suggestion ("hints")

 intervient pour la localisation

 améliore la performance si le cache contient une information non

périmée (valide)

 si l'information est invalide, on peut utiliser les techniques

précédentes pour la recharger.

 Solutions utilisées lors d'une résolution de chemin d'accès :

 accès cache de noms côté client sinon requête au serveur de fichiers

(ANDREW)

 accès cache de noms (partie préfixe du chemin) sinon diffusion de la

demande (SPRITE)

 accès cache de noms sinon emploi d'une heuristique (APOLLO-DOMAIN)

 accès cache de noms sinon interrogation d'un serveur de noms

(GRAPEVINE)

ENSI

Systèmes et applications répartis

31

Techniques de Résolutions des noms :

Points d'attachement

 Un point d'attachement est l'association d'une sous-

arborescence à une feuille d'une autre sous arborescence.

 Une table mémorise l'association <feuille ; sous-arbre>

 On parcours la table à chaque fois qu'un chemin d'accès

traverse un point d'attachement.

ENSI

Systèmes et applications répartis

32

Partage de l’accès aux fichiers :

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 où 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 une opération de fermeture,

 des instants quelconques de début et de fin de transaction

ENSI

Systèmes et applications répartis

33

Partage de l’accès aux fichiers :

Les quatre versions

On ne présente en général que quatre versions

1. Sémantique UNIX : chaque opération est

‘’instantanément’’ visible pour tous les autres usagers.

2. Sémantique de session : aucune modification n’est

visible jusqu’à ce que le fichier soit fermé.

3. Fichiers non mutables : aucune modification n’est

autorisée.

4. Approche transactionnelle : toutes les modifications

sont visibles par tous ou par personne.

ENSI

Systèmes et applications répartis

34

Partage de l’accès aux fichiers :

La sémantique Unix : définition

 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.

ENSI

Systèmes et applications répartis

35

Partage de l’accès aux fichiers :

La sémantique Unix : réalisation

Sémantique facile à réaliser en univers centralisé (si les

clients utilisent un seul cache).

Sémantique plus difficile en univers réparti

Besoin de nombreux messages : par exemple si chaque

usager utilise un cache lorsqu’une modification est réalisée les

copies sont invalidées puis modifiées toutes.

Assez simple en réparti: si l’on accède à un seul serveur de

fichiers distant, que les clients n’ont pas de cache. => Le

serveur peut traiter les requêtes en séquence dans l’ordre

temporel.

ENSI

Systèmes et applications répartis

36

Partage de l’accès aux fichiers :

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.

ENSI

Systèmes et applications répartis

37

Partage de l’accès aux fichiers :

Réalisation de la sémantique session

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?

ENSI

Systèmes et applications répartis

38

Partage de l’accès aux fichiers :

Fichiers non mutables ‘Immutables’

Trois opérations seulement sont prévues :

1. Création d’un fichier :

 Par écriture complète du fichier à partir de la mémoire centrale ou

d’un autre fichier.

 Dès que le fichier est créé (qu’il est déclaré partageable il ne peut plus

être modifié par personne).

2. Destruction du fichier.

3. Lecture du fichier.

 Une modification de fichier ne peut être obtenue que par recréation

d’un autre fichier.

ENSI

Systèmes et applications répartis

39

Partage de l’accès aux fichiers :

Fichiers non mutables ‘Immutables’

Solution rare :

Qui correspond néanmoins à un certain profil

d’utilisation (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.

ENSI

Systèmes et applications répartis

40

Partage de l’accès aux fichiers :

L’approche transactionnelle

Délimitation de transactions : comportant ouverture,

fermeture et accès à des fichiers.

Garantie des propriétés transactionnelles ‘ACID’ : 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.

Tolérance aux pannes : validation à deux phases.

ENSI

Systèmes et applications répartis

41

Tolérance aux pannes : serveurs avec ou sans état

(‘stateless’ vs ‘Sateteful’)

Le serveur de fichier conserve ou non des informations

relatives aux opérations des différents clients en activité.

Avantages des serveurs sans état

Pas d’espace mémoire occupé sur le serveur dans des tables.

Pas de limites sur le nombre de fichiers ouverts.

Pas de problèmes liés aux pannes des clients.

Avantages des serveurs avec état

Messages de requêtes courts (informations à transporter).

Meilleures performances en temps d’exécution.

Lecture/écriture en fin de fichier facile.

Gestion du verrouillage possible.

ENSI

Systèmes et applications répartis

42

SGFR

Accès partagé à distance :

Le système de fichiers répartis SUN

NFS

(‘Network File System’)

ENSI

Systèmes et applications répartis

43

NFS : système basique au départ

 Développé par SUN IETF : RFC 1094 (année 1988)

 Prévu pour ressembler au système de fichiers Unix

 Réalisation de la désignation par montage d’arborescences sur

l’arborescence locale.

 Utilise les RPC de Sun

Données codées selon le protocole XDR

Utilisation d’un service de portmapping

 Pas d’état stocké sur le serveur

 Pas ou peu de cache utilisé par le client

Le cache n’est utile que pour les gros fichiers

La sémantique du cache est douteuse sans état sur le serveur

ENSI

Systèmes et applications répartis

44

Généralités NFS :

Architecture de NFS

ENSI

Systèmes et applications répartis

45

Généralités NFS :

Opérations réalisées pour un accès

1. Réception d’un appel système d’accès fichier.

2. Sélection entre traitement local du fichier ou traitement

distant : utilisation de la couche VFS ‘Virtual file System’ qui

appelle soit ‘local file access’ soit ‘NFS client box’.

3. Préparation d’un appel RPC par le client NFS pour faire la

requête (utilisation UDP pour l’efficacité en performances).

4. Réception par le serveur généralement sur le port UDP

2049 mais on peut aussi utiliser un port quelconque alloué

pour la circonstance (port éphémère).

5. Traitement de la requête par le système de fichiers local via

la couche VFS serveur.

6. Transmission de la réponse : résultat de la requête qui est

délivré au client.

ENSI

Systèmes et applications répartis

46

Généralités NFS :

La famille des protocoles NFS

 NFS : Protocole proprement dit de réalisation des accès

distants.

 Mount : Protocole pour le montage d'arborescences distantes

sur l’arborescence locale (permettant la désignation en univers

réparti).

 Lock Manager : Protocole de gestion de verrous pour le

contrôle de concurrence (avec état).

 Network Monitor : Protocole de surveillance du réseau.

 RPC, XDR, PortMapper : protocoles définis dans le cadre du

RPC SUN pour réaliser les communications, faire des

conversions de représentation, déterminer les numéros de

ports utilisés dans les RPC.

ENSI

Systèmes et applications répartis

47

NFS : le protocole de montage

Montage de systèmes de fichiers distants

 Extension : de la notion de montage existant entre systèmes de

fichiers locaux à un montage de fichiers distants.

 Fichier /etc/exports : Définition par le serveur d’une liste des

répertoires qui peuvent être montés à distance sous la forme :

nom de répertoire, liste d’accès des utilisateurs et machines

autorisées à effectuer le montage

 ligne du fichier <dossier partagé> <hôte>(<options>) <hôte2>(<options>)...

 Exemple : /usr client

 Remarque : Le nom d’un répertoire correspond à une sous-arborescence

(pas à un système de fichiers).

 Commande mount : Définition par le client du point où il désire

accrocher l’arborescence distante.

 mount –t nfs nom_serveur:/chemin_serveur /chemin_client

ENSI

Systèmes et applications répartis

48

Systèmes de fichiers répartis NFS :

Exemple de montage distant

Fichier exports /usr client

$ mount –t nfs serveur:/usr /usr

ENSI

Systèmes et applications répartis

49

NFS : Fonctionnement du montage

 Utilisation de trois processus usager (hors système).

 Le processus client de montage

 Le processus serveur de montage (‘Mount daemon’)

 Le gestionnaire de ports pour RPC (‘PortMapper’)

ENSI

Systèmes et applications répartis

50

NFS : Fonctionnement du montage (2)

 Démarrage du serveur de port (PortMapper) quand le site serveur démarre.

 Démarrage du processus serveur de montage.

 (1) Le processus serveur de montage s’enregistre auprès du serveur de port.

 Un client effectue une commande mount : montage d’une arborescence

serveur sur son arborescence locale.

 (2) Le client demande au serveur de ports le numéro de port du processus

serveur de montage.

 (3) Le serveur de port fournit le numéro.

 (4) Le processus client (commande mount) émet un RPC pour obtenir une

poignée file handle du système de fichiers distant.

 (5) Réponse de la poignée.

 (6) Le processus client (commande mount) émet une commande au NFS local

pour associer la poignée et le point de montage local. A partir de ce moment le

NFS local utilisera cette poignée pour accéder à distance au serveur de fichiers

réel.

ENSI

Systèmes et applications répartis

51

Système de fichiers répartis NFS :

Notion de poignée fichier ‘File Handle’

 Quand un client ouvre un fichier : il reçoit une structure de données

concernant le fichier (‘File Handle’).

 Contient essentiellement l’identifiant du fichier pour réaliser l’accès sur le bon

fichier

 Structure ‘opaque’ : le client ne manipule pas la structure.

 Le client doit fournir au serveur cette poignée : pour chaque nouvelle

requête effectuée .

 Exemple Serveur de fichiers UNIX: informations ‘handle’

 Numéro du système de fichiers : ‘filesystem id’.

 Numéro de l’i-node : identifiant interne du fichier dans le fs.

 Numéro de génération : ce numéro change à chaque fois qu’un numéro d’inode

est réutilisé pour un nouveau fichier pour éviter les ambigüités entre fichiers

anciens et nouveaux.

 Eventuellement du bourrage : pour compléter la taille selon les versions (versions

à taille fixe 32 , 64 octets, version à taille variable définie par la longueur).

ENSI

Systèmes et applications répartis

52

Fichiers répartis NFS : Interface virtuelle

VFS ‘Virtual File System’

Interface séparant l’utilisation d’un fichier de son

implantation.

Nouvelle interface d’E/S fichier avec le noyau Unix qui

reçoit toutes les requêtes considérées par VFS comme

génériques.

Réalisation effective des opérations par les différents

systèmes de fichiers (systèmes de fichiers locaux ou

distants).

VFS implante la désignation en réparti par montage

d’arborescence.

ENSI

Systèmes et applications répartis

53

Fichiers répartis NFS : Concepts de

l’interface virtuelle VFS

 Concepts VFS représentés par des structures de données

 Notion de "Virtual File System" (système de fichier virtuel)

Tous les systèmes de fichiers connus sont représentés par des VFS qui

sont identifiés par un ident numérique interne.

Un VFS est un descripteur qui contient un identificateur du système de

fichiers réel et un pointeur sur le V-node sur lequel il est monté.

 Notion de "Virtual node V-node" (fichier virtuel).

Tous les fichiers connus sont représentés par des V-nodes qui sont

identifiés par un identifiant numérique interne.

Un V-node est un descripteur qui contient un pointeur sur le système de

fichiers auquel il appartient et éventuellement sur le système qui est

monté sur ce point.

ENSI

Systèmes et applications répartis

54

Interface virtuelle VFS ‘Virtual File

System’ : opérations VFS

Différentes opérations sur un VFS

struct vfsops {

/ mount file system /

int (*vfs_mount)();

int (vfs_unmount)(); / unmount file system */

int (*vfs_root)();

int (*vfs_statfs)();

int (*vfs_sync)();

int (*vfs_vget)();

/ get root vnode /

/ get fs statistics /

/ flush fs buffers /

/ get vnode from fid /

};

ENSI

Systèmes et applications répartis

56

NFS : sécurité

Support de Kerberos, très contraignant

Authentification basée sur les adresses IP

La sécurité implique l’intégrité du réseau et celle des

administrateurs

ENSI

Systèmes et applications répartis

57

SGFR

Accès partagé avec redondance :

Andrew File System (AFS)

ENSI

Systèmes et applications répartis

58

AFS : Hypothèses de conception

 AFS vise plusieurs dizaines de clients.

AFS vise l'adaptabilité et l'extensibilité.

 Les fichiers sont petits < 10 Ko

 Il y a plus de lectures que d'écritures (6 fois)

 L'accès est souvent séquentiel rarement aléatoire

 Peu de partage entre utilisateurs, quand il y a partage, c'est souvent

un seul utilisateur qui le modifie

ENSI

Systèmes et applications répartis

59

AFS : utilisation d’un cache local

 Utilisation d’un cache côté client

Stocke les fichiers

Les clients cachent des fichiers entiers

Les serveurs transfèrent tout un fichier quand un client fait un

accès sur celui-ci

Stocke les données de répertoire

 Utilisation d’un système de callbacks

Possibilité pour le client d’utiliser sa copie locale,

supposée valide

Callback appelé par le serveur en cas d’invalidation

 Le serveur maintient une connaissance de l’état des caches

des clients.

ENSI

Systèmes et applications répartis

60

AFS : propriétés du cache

Cache persistant

Résiste au redémarrage de la machine

Stocke un numéro de version associé à chaque

donnée

Accès concurrents

Accès en lecture : ne nécessite aucune opération

réseau une fois le fichier dans le cache

Accès en écriture : provoque une demande

d’invalidation de cache par le serveur à tous les

clients pour les données modifiées

ENSI

Systèmes et applications répartis

61

AFS : organisation

Espace de nommage unique : /afs

Domaine administratif : la cellule

Un ou plusieurs serveurs

Zéro ou plusieurs clients accédant aux données

Chaque cellule exporte des volumes montés

sous /afs

Administration du client minimale

Le client contactera de lui-même la cellule pour

trouver un serveur offrant le volume demandé

ENSI

Systèmes et applications répartis

62

AFS : organisation

 Les fichiers respectent le modèle Unix : suite d'octets "plate".

Les fichiers sont regroupés par Volumes, le volume est l'unité de

localisation et de migration. Une partition = +sieurs volumes.

 L'arborescence des fichiers est constituée de volumes reliés par des

points de montage.

 Les répertoires et les fichiers dans l'espace partagé sont identifiés de

façon unique par un fids de 96 bits :

 Il est indépendant de la localisation.

 La résolution des noms est à la charge des clients (Venus) et est faite

morceau par morceau comme dans NFS.

ENSI

Systèmes et applications répartis

63

AFS : localisation et réplication

 La localisation des serveurs contenant un fichier

demandé est stockée dans un annuaire.

Cet annuaire est répliqué sur tous les clients.

Un protocole gère la cohérence des réplicas qui peuvent

parfois ne pas être tout à fait à jour.

 La stratégie de réplication d’AFS est simple et

pessimiste :

Un seul serveur autorise les écritures.

Tous les autres agissent comme des esclaves fournissant les

fichiers en lecture seule.

ENSI

Systèmes et applications répartis

64

AFS :Protocole de gestion de cohérence des

caches

 La cohérence des caches est fondée sur un mécanisme de

"promesse de rappel" :

 Quand un client demande un fichier, le serveur lui fournit une copie

et conserve une "promesse de rappel" avec le nom du client.

 Le client à la réception de son fichier garde un jeton qui a l'état

valide.

 Lorsqu'un client vide son cache, le fichier est recopié sur le

serveur.

 Si d'autres clients ont une copie du fichier dans leur cache, ils sont

rappelés par le serveur.

 Quand un client est rappelé, il met le jeton concerné à invalide.

 Si un programme utilisateur sur le client veut accéder à ce fichier, il

doit demander une copie fraiche au serveur.

ENSI

Systèmes et applications répartis

65

AFS : protocole

Du client vers le serveur

Lecture et écriture des données

Modification de la hiérarchie de fichiers

Gestion des volumes

Verrouillage

Du serveur vers le client

Invalidation du cache

Avec de la sécurité

Gestion de jetons par Kerberos

ACL (Access Control List) fines par répertoire

AFS ne cherche pas à imiter un système de fichiers

local.

ENSI

Systèmes et applications répartis

66

AFS : disponibilité

Premières implémentations développées par CMU

(Carnegie Mellon University)

Implémentation commerciale développée par

TransArc, achetée par IBM, et libérée sous le nom

d’OpenAFS

Implémentation libre : Arla

Implémentation partielle par RedHat dans Linux

depuis le noyau 2.6.10

N’a jamais vraiment pris de succès sauf dans certaines

universités américaines (notamment CMU)

ENSI

Systèmes et applications répartis

67

NFS : une norme qui évolue

 La norme évolue

 NFS v4 : décembre 2000, avril 2003, influencé par AFS et CIFS (Common

Internet File System)

 NFS v4.1 : janvier 2012

 Efficacité

 Regroupement des requêtes

 Système de cache avec invalidation possible

 TCP privilégié pour détecter les ruptures de connexion

 Délégation à des serveurs secondaires

 Accès aux fichiers en parallèle (striping ) et notion de session

 Sécurité

 Simplification du modèle par rapport aux versions précédentes

 Possibilité de chiffrement

 Possibilité d’imposer des contraintes sur le niveau de sécurité requis, côté

client et côté serveur

ENSI

Systèmes et applications répartis

68

SGFR

Système à haute disponibilité :

Goo...