Le Network File System de Sun (NFS)


Network File System de Sun (NFS)

NFS = système de fichiers distribué.

Idée de base = pouvoir partager entre plusieurs clients et serveurs hétérogènes un même système de fichiers.

Une machine peut être à la fois client et serveur.

Un serveur NFS exporte ses directories pour qu'elles soient accessibles par des clients.

Si une directory est exportée, c'est tout le sous-arbre qui est exporté.

Liste des directories exportées dans /etc/exports.

Architecture

Un client qui veut accéder à une directory distante doit la monter dans sa propre hierarchie.

Une station cliente sans disque (diskless) peut faire "comme si" elle avait un disque en montant des systèmes distants.

Une station avec un disque local aura une hierarchie en partie locale et distante.

Pour les programmes du client pas de différence entre fichiers locaux ou distants.

Si deux clients ont monté la même directory, ils en partagent les fichiers.

simplicité de NFS.

Protocoles

NFS doit supporter des systèmes hétérogènes (clients DOS utilisant des processeurs Intel, serveurs tournant sur Sun Sparc, ...).

clients et serveurs utilisant différents OS et différentes machines.

Il est impératif de définir une bonne interface client/serveur.

Avantage d'une interface clairement définie : possibilité d'écrire de nouveaux clients et serveurs compatibles.

2 protocoles sont définis.

1 protocole pour le mounting et 1 protocole pour la directory et l' accès aux fichiers.

Mounting

Soit C le client et S le serveur.

C envoie à S un chemin d'accès (le nom de la directory à monter) et demande la permission de monter la directory chez lui.

L'endroit où C va monter la directory n'est pas important pour S.

Si le chemin d'accès est correct et si la directory se trouve dans /etc/exports, S renvoie un file handle à C.

Le handle est composé :

Pour lire ou écrire dans la directory montée, il faut utiliser ce handle.

Un client peut monter des directory sans intervention humaine.

Ces clients ont un fichier /etc/rc shell script qui contient les commandes de mount et lancé automatiquement au boot.

C'est le static mounting.

Les versions récentes de Sun Unix ont l' automounting :

Des directory distantes sont associées à des directories locales, mais elles ne sont pas montées, et leurs serveurs ne sont pas contactés au boot.

La première fois qu'un client accède à un fichier distant, les serveurs sont contactés. Le premier qui répond gagne.

Automounting vs Static mounting

Avantages de l'automounting sur le static mounting :
  1. si un des serveurs NFS nommé dans /etc/rc est down difficile de mettre en route le client ;
  2. dans le static mounting, on ne contacte qu'un serveur pour chaque directory, alors qu'on peut en contacter plusieurs dans le automounting tolérance aux fautes.
Inconvénient : tous les serveurs "alternatifs" pour une même directory doivent être cohérents surtout utilisé pour des systèmes de fichiers read-only.

Directory et accès aux fichiers

2ème protocole.

Les clients envoient des messages pour manipuler des directories, lire et écrire des fichiers et leurs attributs (taille, date de modification, propriétaire, etc.).

Tous les appels systèmes sont pris en charge par NFS sauf OPEN et CLOSE.

OPEN et CLOSE ne sont pas utiles :

Si le serveur crashe aucune info sur les fichiers ouvert est perdue (puisqu'il n'y en a pas).

Un serveur NFS est stateless.

Problèmes

Un fichier Unix peut être ouvert et verrouillé (locked) pour empêcher les autres processus de l'utiliser.

Fichier fermé verrous relachés.

NFS est stateless, on ne peut pas associer de verrous à l'ouverture d'un fichier.

Il faut un mécanisme externe à NFS pour gérer le verouillage.

NFS utilise quand même le système de protection Unix (bits rwx pour le owner, group et world).

MAIS : le serveur NFS croit toujours le client pour valider un accès.

Que faire si le client ment ?

Utilisation de la cryptographie pour valider les requêtes.

Problème : les données, elles, ne sont pas cryptées.

Les clés sont gérées par le NIS ( Network Information Service, ou yellow pages)

Implémentation

La couche VFS maintient une table pour chaque fichier ouvert.

Chaque entrée est un v-node (virtual i-node). On indique si le fichier est local ou distant.

Exemple : la séquence < MOUNT, OPEN, READ >.

MOUNT

MOUNT : Le kernel a la main :

OPEN

OPEN : Côté serveur, rien n'est créé.

READ

READ : Les transferts se font normalement 8ko / 8ko, même si moins d'octets sont demandés.

Automatiquement, dès que le client a reçu les 8ko demandés, une nouvelle requête de 8ko est envoyée.

C'est le read ahead.

WRITE

Les transferts se font aussi 8ko / 8ko.

Tant que les données écrites sont < 8ko, elles sont accumulées localement.

Dès que le client a écrit 8ko, les 8ko sont envoyé au serveur.

Quand un fichier est fermé, ce qui reste à écrire est envoyé au serveur.

Utilisation du caching :

les clients ont 2 caches : attributs et données.

problèmes de cohérences.

Cohérence du cache

Pas de solution "propre" : on essaie de réduire le risque au maximum, mais sans l'éviter tout à fait.
Retour au sommaire.