Marco Lapegna » 19.I Sistemi Operativi distribuiti - parte sesta

Esempi di File system distribuiti

I più noti esempi di File System Distribuiti sono:

• Network File System (NFS): è il frutto di un progetto del 1984 della SUN Microsystems che aveva l’obiettivo di permettere l’accesso ai dischi remoti come se fossero dischi locali;
• Andrew File System (AFS): è un file system distribuito sviluppato nel 1983 alla Carnegie Mellon University come parte di un progetto per un sistema distribuito. Prende il nome da Andrew Carnegie e Andrew Mellon fondatori dell’università.

Nonostante la loro larga diffusione hanno caratteristiche molto diverse tra loro.

Network File System (NFS)

NFS permette a calcolatori con sistema Unix (ma non solo), che compongono un sistema distribuito, di condividere file, directory od un intero file system utilizzando il modello ad accesso remoto, come se si fosse in presenza di un unico file system logico

Ogni server esporta una o più directory per far accedere i client da remoto.

I client accedono alle directory montandole come parte del proprio file system.

E’ possibile far integrare tra loro f.s. eterogenei, sfruttando un protocollo per la rappresentazione dei dati (external data representation – XDR).

NFS

La versione 2 prevedeva che i server non dovessero conservare memoria degli accessi degli utenti (servizio senza stato). Eventuali meccanismi di blocco delle risorse (Lock) dovevano essere implementati esternamente al protocollo.

La versione 3 introdusse il supporto per il trasporto delle informazioni per l’utilizzo di NFS su una WAN sebbene in maniera poco semplice ed efficiente.

La versione 4 venne influenzata dall’AFS e includeva miglioramenti nelle prestazioni, aggiungeva un supporto migliorato alla sicurezza e introduceva un protocollo che teneva conto dello stato dei client.

NFS definisce due protocolli:

1. per il montaggio delle directory;
2. per l’accesso ai file e le directory.

Protocollo per il montaggio

Un client, per montare un directory, invia una rischiesta al server, specificando pathname e permessi per montare la directory.

Se il pathname è valido e la directory è esportata, il server restituisce al client un file handle con le informazioni sul file system, il disco, gli inode della directory e la sicurezza.

Il server mantiene una lista delle directory correntemente esportate e montate dai client (/etc/exports).

Alcune versioni di Unix supportano l’Automount, che permette di montare automaticamente al boot le directory.

Automount gestisce la replicazione dei file mediante server alternativi ridondanti.

Protocollo per l’accesso a file e directory

Il protocollo offre un insieme di RPC che permettono:

• ricerca di un file in una directory;
• lettura di un insieme di elementi di una directory;
• lettura e scrittura di un file;
• accesso agli attributi di un file.

Le versioni 2 e 3 non mantengono informazioni di stato ed ogni richiesta contiene tutte le informazioni per completare l’operazione.

Non sono necessarie le istruzioni di open e close.

Implementazione di NFS

NFS deve far parte del kernel?

Non necessariamente: (ad es. in Windows 3.0, Win 95, primi MacOS, PocketPC era implementato come libreria utente).

Per Unix è però vantaggioso implementare NFS nel kernel:

• stesse chiamate di sistema per l’accesso locale e remoto (non c’è bisogno di ricompilare l’applicazione);
• maggiore efficienza nella gestione della cache;
• maggiore efficienza nell’accesso agli i-node.

Andrew File System – AFS

AFS è’ un File System distribuito che permette la condivisione di file tra macchine UNIX su reti LAN e WAN utilizzando il modello upload/download.

Obiettivo del progetto: fornire a studenti e docenti della Carneige Mellon Univ. un ambiente Unix-like con un unico file system condiviso.

AFS è scalabile. E’ possibile connettere migliaia di workstation.

Solitamente si tengono distinte le workstation dai server per migliorare le prestazioni.

AFS supporta varie versioni di Unix (AIX, HP-UX, Ultrix, SUN-OS,…).

AFS: architettura

I client sono presentati con uno spazio dei nomi partizionato: uno spazio dei nomi locali e uno spazio dei nomi globali.
Su ogni client, lo spazio dei nomi visibili ai programmi utente appare come un albero UNIX tradizionale, con l’aggiunta delle directory /afs e /cache:

• la directory /cache contiene i file remoti posti nella cache;
• la directory /afs contiene i nomi delle workstation remote, raggruppate in cellule, sotto cui si trovano i rispettivi file system;
• i file system remoti sono montati in /afs; le altre directory e file sono strettamente locali e non condivisi.

Le cellule

Introdotte in AFS 3.

Cellula = gruppo di ws geograficamente vicine (ad es. ws di uno stesso dipartimento o universita’) e amministrate in comune.

Più cellule possono coprire un territorio molto vasto → scalabilità di AFS a migliaia di ws anche molto distanti geograficamente.

AFS: idea di base

Assunzione 1: i file sono usati molto in lettura e poco in scrittura.

Assunzione 2: la maggior parte dei file è piccola.

Idea: fare in modo che ogni utente lavori il più possibile localmente e interagisca il meno possibile con il resto del sistema.

• All’apertura di un file, Venus cattura la open e trasferisce tutto il file sul disco locale.
• Il file descriptor si riferisce al file locale.
• Tutte le operazioni di read e write sono sul file locale.
• Alla chiusura del file Venus trasferisce l’intero file sul server.

Semantica

Venus scarica un file nella directory /cache locale.

Read e write locali.

Alla chiusura il file viene trasferito sul server.

Se nel frattempo un altro processo accede al file le modifiche non sono visibili.

AFS usa una semantica di sessione

Le modifiche sono visibili agli altri processi solo dopo la chiusura del file.

Il caching

Il Cache Manager è un processo che gira sulle macchine client e gestisce la cache locale.

Dopo la chiusura, il file viene trasferito sul server, ma rimane anche nella cache locale in modo da evitare successivi download in caso di altri utilizzi.

Che succede se il file nel frattempo è stato modificato da un altro processo?

Due approcci

1. verifica della coerenza iniziata dal client (AFS 1);
2. verifica della coerenza iniziata dal server (AFS 2 e 3).

Differenze

Verifica iniziata dal client (AFS1):

• ogni volta che Venus trova e apre un file nella cache locale contatta il server per assicurarsi della validità del file;
• vengono generate molte richieste al server anche quando il file non è stato modificato.

Verifica iniziata dal server (AFS2 e AFS3):

• il server tiene traccia dei file che i client hanno nelle proprie cache;
• ogni volta che un file viene chiuso (e scaricato sul server), il server comunica ai client di invalidare la copia del file in loro possesso;
• in caso di nuovo utilizzo i client scaricano la nuova copia nella cache;
• minore comunicazione tra client e server.