Molto vicino al modello concettuale appena descritto.
Nella rete non si fa distinzione fra macchine client e server.
Fornisce una buona trasparenza degli accessi e della locazione (un unico namespace per tutti i client).
Supporta piattaforme hardware e software eterogenee (SUN Solaris, Microsoft, Linux, MAC-OS).
L’implementazione dei server è senza stato (stateless): le procedure di ripristino sono semplici ed efficienti.
Il livello di prestazione dipende dal protocollo di caching.
NON sono supportati meccanismi di migrazione dei file e directory.
Modulo aggiunto al kernel UNIX.
Rende trasparenti gli accessi a file system diversi.
Distingue fra diversi file system locali e quelli remoti.
Gestisce il v-node, una sorta di i-node che specifica se il file è locale o remoto:
Un insieme di invocazioni RPC che definiscono le regole di interazioni tra client e server.
Per motivi di efficienza e trasparenza, client e server sono integrati nel kernel.
Ad ogni richiesta di accesso ad un file, il server deve verificare i permessi dell’utente.
Il protocollo Sun RPC richiede che il client invii con la richiesta anche le proprie informazioni di autenticazione.
Nell’implementazione più semplice tale approccio è poco sicuro:
L’operazione di mounting di un sott’albero remoto viene realizzato da un apposito servizio, denominato Mount Service, fornito da un processo daemon a livello utente.
In ogni computer vi è un file speciale (/etc/exports) contenente tutti i filesystem locali che possono essere esportati, e un access list indicante quali host possono montare un dato filesystem.
Viene fornito un apposito comando (nfs_mount) il quale comunica con il servizio di mounting di un host remoto utilizzando il protocollo di MOUNT.
Si utilizza il Mount Service, a cusi occorre specificare
La richiesta di mounting viene istradata al server.
Il server controlla nella lista di esportazione (/etc/export) se la macchina che la richiede è abilitata a montare quella directory.
Il server restituisce al client una file handle per accedere al filesystem remoto montato.
Il filesystem montato su /usr/distr sul client è in pratica il sottoalbero /home/pippo nel Server 1.
Il sottoalbero /home/pippo/docs del Server 1 corrisponde al sottoalbero /home/utente nel Server 2.
Il Server 1 è un client per il Server 2.
In NFS, i nomi non possono essere tradotti direttamente dal server, perché un nome potrebbe “attraversare” uno o più mount point, e dunque risultare diverso tra client e server.
I nomi sono risolti iterativamente dal client:
Ad esempio, per risolvere /usr/distr/docs/verbali/DocA.txt occorre effettuare le sguenti operazioni di lookup
In caso di server failure il client sarà forzato ad attendere il completamento della procedura di ripristino del server.
Il client ha la responsabilità di attuare le procedure di rispristino (più delicato; la responsabilità è spostata ai programmatori dell’applicazione).
L’Automounter è un processo lato client che:
Localizza il mount point richiesto nella tabella.
Manda un probe a tutti i server che detengono quel mount point.
Aggancia (con nfs_mount) il filesystem del primo server che risponde.
Dato un mount point A, replicato sui server S1, S2 e S3, si può ottenere replicazione trasparente al client (solo in lettura) aggiungendo le entry <A,S1>, <A,S2> e <A,S3> alla tabella dell’automounter.
Ciò fornisce anche un certo grado di fault-tolerance e load balancing.
Di fondamentale importanza per conseguire un livello di prestazioni comparabile con file system locale.
Sono adottate due strategie, una per il lato server (server caching) ed una per il lato client (client caching).
Il caching lato server è molto simile a quello adottato nel filesystem Unix.
I blocchi letti dal disco sono memorizzati in un’apposita memoria cache assieme alla directory che contiene il file.
Se una richiesta è indirizzata ad un blocco che è già presente in cache si evita l’accesso al disco.
Nei file-system convenzionali (ad es. UNIX) vengono adottate due tecniche:
Per prevenire un’eventuale perdita dei dati dovuta ad improvvisi outage, i sistemi UNIX eseguono un operazione di sync, per eseguire il “flushing” della cache, ogni 30 secondi.
I server NFS utilizzano il meccanismo di caching offerto dal SO per gli altri file.
Non ci sono problemi di consistenza.
Occorre garantire ai client remoti che eseguono una write, che l’operazione di scrittura sia persistente anche in caso di crash del server.
Write-through. Quando un client richiede una scrittura di un blocco, il server la esegue sul disco prima di dare un ack al client.
Commit operation. I blocchi scritti sono mantenuti in cache dal server (miglior tempo di risposta). I blocchi scritti in una “sessione” verranno salvati su disco solo quando il client invoca un’operazione di commit.
L’obiettivo è di ridurre le richieste ai server facendo caching dei risultati di alcune operazioni.
La problematica è delicata in quanto nel sistema potrebbero esistere più copie dello stesso file non allineate tra loro.
NFS impone ai client di interrogare (polling) il server per capire se il file in cache sia up to date oppure no.
Per effettuare la validazione dei blocchi viene utilizzato un meccanismo basato su timestamp.
Ad ogni blocco della cache lato client sono associati due timestamp:
Un blocco nella cache lato client è valido al tempo T se il valore Tm registrato lato client è uguale a quello lato server, ovvero se la differenza (T-Tc) è minore di un intervallo Tf (denominato freshness interval):
(T-Tc < Tf) OR (Tmclient = Tmserver)
La scelta del parametro Tf deve derivare da un giusto compromesso tra consistenza ed efficienza.
viene garantita la consistenza a scapito dell’efficienza, poiché comporta una grossa mole di informazioni scambiata tra client e server.
In Solaris, Tf viene scelto in maniera adattiva:
Poiché i client NFS non possono determinare se un file in una dato istante sia condiviso, essi devono eseguire la procedura di validazione ad ogni accesso.
La prima parte della procedura può essere valutata senza dover accedere al server.
Si accederà al server solo se T-Tc≥Tf.
L’accesso al server consiste in una richiesta di getattr per ottenere il valore di Tmserver.
Se la procedura restituisce false, il blocco in cache sarà invalidato, forzando il client a richiederne una copia aggiornata al server.
Per ridurre il traffico dovuto alle richieste getattr si utilizzano le seguenti strategie:
La procedura di validazione non garantisce lo stesso livello di consistenza dei file fornita dal file system locale.
Da uno studio sui file system Unix, si è riscontrato che le applicazioni non dipendono in maniera critica dalla sincronizzazione degli update (è statisticamente improbabile che due client vogliano accedere allo stesso blocco in un periodo di tempo molto vicino).
Chiaramente tale ipotesi non vale per i database distribuiti …
Quando un blocco contenuto nella cache lato client viene modificato, il blocco verrà marcato come “dirty”.
La scrittura dei blocchi “dirty” verrà aggiornata sul server in maniera asincrona, cioè quando il file sarà chiuso oppure quando sarà invocata una “sync” lato client.
Diversi studi hanno dimostrato che le prestazioni di NFS sono comparabili, ed in certi casi superiori, a quelle di un file system convenzionale.
Tali studi hanno anche individuato quali sono i “colli di bottiglia” di NFS:
Altri studi di misure sul campo dei file system hanno però dimostrato che le write su un FS rappresentano soltanto il 5 % degli accessi totali.
1. Caratterizzazione dei sistemi distribuiti
2. Modelli di sistemi distribuiti
3. Tempo e sincronizzazione nei Sistemi Distribuiti
4. Stato globale nei Sistemi Distribuiti
5. Problemi di consenso nei sistemi distribuiti
7. Algoritmi di mutua esclusione nei sistemi distribuiti
8. Algoritmi di elezione nei sistemi distribuiti
10. Il Network File System di SUN Microsystems
11. AFS (Andrew File System) e GFS (Google File System)
12. Transazioni e controllo di concorrenza
13. Transazioni
15. Affidabilità (dependability) dei sistemi software distribuiti
16. Affidabilità dei sistemi software distribuiti
17. Software Faults
18. Classificazione e analisi dei difetti software