Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Stefano Russo » 10.Il Network File System di SUN Microsystems


Caratteristiche

Molto vicino al modello concettuale appena descritto.
Nella rete non si fa distinzione fra macchine client e server.

  • Ogni nodo può avere contemporaneamente sia il ruolo di client sia quello di 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.

Modello architetturale


VFS (Virtual File System)

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:

  • se è locale, il v-node contiene l’indice del file locale (ad esempio, l’i-node nel caso di UNIX);
  • se è remoto, il v-node contiene il file handle, ovvero un id univoco di un file su tutta la rete dato dalla ennupla: <FileSystemID, i-node number, i-node generation number>

Protocollo NFS

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.

Failure handling:
timeout and re-issue

Failure handling: timeout and re-issue


Operazioni


Controllo degli accessi ed autenticazione

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:

  • basterebbe effettuare una RPC call sostituendo le informazioni di autenticazione associate per accedere con determinati permessi ad un certo file
  • vengono utilizzati protocolli di autenticazione basati su crittografia (ad es. Kerberos)

Mounting

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.

Il protocollo di MOUNT: schema esemplificativo

Si utilizza il Mount Service, a cusi occorre specificare

  • il nome della directory remota e
  • la macchina su cui si trova.

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.

Mounting – esempio

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.


Traduzione dei nomi nelle operazioni di lookup

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:

  • ogni parte del nome che fa riferimento ad una directory remota è trasformata in un file handle attraverso un lookup
  • il file handle ottenuto viene utilizzato in un successivo lookup, fino a risolvere l’intero nome del file.

Traduzione dei nomi nelle operazioni di lookup

Ad esempio, per risolvere /usr/distr/docs/verbali/DocA.txt occorre effettuare le sguenti operazioni di lookup

Ad esempio, per risolvere /usr/distr/docs/verbali/DocA.txt occorre effettuare le sguenti operazioni di lookup


Hard Mounting e Soft Mounting

  • Quando un processo accede ad un file in NFS che è “hard-mounted”, il processo verrà sospeso finché la richiesta di accesso non viene eseguita (NFS client continua a riprovare finché non la richiesta non viene servita).

In caso di server failure il client sarà forzato ad attendere il completamento della procedura di ripristino del server.

  • Quando un processo accede ad un file in NFS che è “soft-mounted”, in caso di fallimento del server (timeout) l’operazione di accesso fallisce.

Il client ha la responsabilità di attuare le procedure di rispristino (più delicato; la responsabilità è spostata ai programmatori dell’applicazione).

Automounter

L’Automounter è un processo lato client che:

  • mantiene una tabella <mount point remoto, server NFS>;
  • quando il client tenta di risolvere un nome incluso in uno dei mount point remoti.

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.

Replicazione read-only

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.

NFS: Caching

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

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

Server caching

Nei file-system convenzionali (ad es. UNIX) vengono adottate due tecniche:

  1. Lettura anticipata (read-ahead). Si tratta di una tecnica di “prefetching” dei blocchi dal disco in modo da anticipare i successivi accessi;
  2. Scrittura-ritardata (delayed-write). Quando un blocco risulta modificato (da una scrittura) non viene effettuata subito la riscrittura sul disco. Solo quando il blocco viene scaricato dalla cache (a favore di altri blocchi) avviene l’aggiornamento sul disco.

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.

Server caching

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.

Server caching

Write-through. Quando un client richiede una scrittura di un blocco, il server la esegue sul disco prima di dare un ack al client.

  • In questo modo sono garantiti la persistenza delle scritture e l’indipendenza dei fallimenti.

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.

  • In tal modo si evita il degrado delle performance dovuto a server che ricevono molte richieste di scrittura.

Client caching

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.

Client caching

Ad ogni blocco della cache lato client sono associati due timestamp:

  • Tm: istante di tempo in cui il blocco è stato modificato dal server l’ultima volta
  • Tc: istante di tempo in cui il blocco è stato validato l’ultima volta

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)

Scelta del freshness interval

La scelta del parametro Tf deve derivare da un giusto compromesso tra consistenza ed efficienza.

  • Tf=0 indica una soluzione del tipo one-copy

viene garantita la consistenza a scapito dell’efficienza, poiché comporta una grossa mole di informazioni scambiata tra client e server.

  • Tf=∞ indica una soluzione che garantisce la massima efficienza ma nessuna garanzia di consistenza.

In Solaris, Tf viene scelto in maniera adattiva:

  • file: da 3 a 30 secondi in base alla frequenza di modifica
  • directory: da 30 a 60 secondi in base alla frequenza di operazioni concorrenti.

Operazioni di lettura

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.

Operazioni di lettura

Per ridurre il traffico dovuto alle richieste getattr si utilizzano le seguenti strategie:

  • ogni qualvolta si accede al server per richiedere il Tm, quest’ultimo verrà applicato a tutti i blocchi del file presenti in cache (Tm è relativo al file, non al blocco)
  • il Tm di un file può essere inviato assieme ai risultati (ack) di ogni accesso al file (tecnica di piggybacking)
  • l’adozione di un algoritmo adattivo per la configurazione del valore Tf.

Client caching: considerazioni

La procedura di validazione non garantisce lo stesso livello di consistenza dei file fornita dal file system locale.

  • Esiste una finestra di vulnerabilità in cui gli update “recenti” di un file non sempre sono visibili a tutti i client.

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 …

Client caching: operazioni di scrittura

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.

NFS: Considerazioni finali

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:

  • utilizzo frequente dell’operazione di getattr per prelevare i timestamp
  • inefficienza delle operazioni di write.

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.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93