Swappa : Uni / Sistemi Operativi - File system distribuiti
Creative Commons License

Torna alla pagina di Sistemi Operativi


 :: Appunti 2.0 ::

File system distribuiti

L'ambiente distribuito

Nel capitolo precedente abbiamo definito i sistemi distribuiti come un insieme di computer debolmente collegati da una rete di comunicazione. Un file system distribuito (DFS) è un'implementazione distribuita di quello classico centralizzato, ed è caratterizzato dalle seguenti entità:

Un DFS può quindi essere considerato come un file server, poiché fornisce attraverso la rete i servizi di accesso e uso dei file ai client. Notare che le macchine possono essere indistintamente sia server che client, l'importante è che il sistema appaia come dotato di un unico file system centralizzato; la dispersione di servizi e risorse deve essere del tutto trasparente agli utenti.
Teoricamente andrebbe esteso il principio di trasparenza anche alla rapidità di accesso ai servizi, ma questo è un obiettivo più difficile da garantire a causa dei tempi e delle esigenze computazionali della comunicazione lungo una rete.

Il DFS controlla un gran numero di dispositivi di memorizzazione, in ognuno dei quali si possono individuare le unità componenti del file system distribuito, ovvero il più piccolo gruppo di file che si possa memorizzare su una macchina e che deve risiedere esclusivamente in essa.

Attribuzione dei nomi e trasparenza

L'attribuzione dei nomi su disco locale fornisce agli utenti un'astrazione del file che nasconde i dettagli di come e dove è stato memorizzato. In un DFS trasparente viene aggiunto un nuovo livello di astrazione nascondendo anche l'host su cui è localizzato in rete.

Le strutture di attribuzione dei nomi

In un DFS realmente trasparente dovrebbe essere garantita sia la trasparenza della locazione (non si hanno informazioni sull'effettiva locazione fisica del file) che l' indipendenza della locazione (il nome di un file non deve cambiare nemmeno se viene fisicamente spostato). Quest'ultimo requisito non è spesso assicurato poiché sono pochi i sistemi che supportano una reale migrazione dei file; si parla in questi casi di file system di rete.

Su file system realmente distribuiti (come ad esempio l'AFS) potremmo avere client senza dischi che fanno intero affidamento al server sia per accedere ai dati che per avviare il sistema operativo (previa esecuzione di un protocollo speciale memorizzato su ROM). In questo modo si risparmia sì sui dischi, ma a prezzo di una maggiore complessità di avvio e di prestazioni inferiori rispetto ai mappaggi locali.

Gli schemi di attribuzione dei nomi

Per l'attribuzione dei nomi abbiamo tre approcci principali, i primi due per file system di rete e l'ultimo per il DFS:

Tecniche di implementazione

L'implementazione dell'attribuzione trasparente dei nomi richiede una mappatura tra il nome del file e la locazione associata; per mantenere più semplice la gestione, i file vengono spesso aggregati in unità componenti e trattati in quanto tali.

Per aumentare la disponibilità delle informazioni cruciali per la mappatura vengono adottate tecniche come la replica e la cache locale (o entrambe), che possono essere migliorate con l'uso di identificatori di file indipendenti dalla locazione per essere costantemente aggiornate.

Accesso remoto ai file

Quando un utente chiede di accedere a un file remoto in un file system di rete, il trasferimento dei dati richiesto avviene con l'uso di un meccanismo di servizio remoto generalmente implementato con una RPC. Tale sistema prevede la copiatura locale in cache e il conseguente aggiornamento, quindi il salvataggio in remoto.
In un DFS queste operazioni vengono trattate mediante meccanismi di servizi locali, eventualmente eseguiti in remoto in modo trasparente.

Schema di base per l'uso della cache

L'uso della cache assicura prestazioni ragionevoli riducendo sia il traffico di rete che gli accessi I/O al disco. Il concetto è che se i dati richiesti non sono già al suo interno, allora bisogna ricopiarli dagli originali contenuti sul server. Si cerca cioè di mantenere in queste memorie veloci le informazioni richieste più spesso, accelerando di conseguenza i tempi di servizio.

E' di fondamentale importanza garantire la coerenza della cache in caso di modifica dei dati, o potrebbero avvenire accessi a dati inconsistenti. Ne vanno perciò studiate la locazione e le politiche di aggiornamento più appropriate, e non ultimo vanno valutate attentamente le sue dimensioni: più la cache è grande più RAM viene richiesta e maggiori sono gli oneri per garantirne la coerenza, ma allo stesso tempo maggiore è la probabilità che contenga il file di interesse.

Locazione della cache

Dove memorizzare la cache? Se viene collocata su disco avremo maggiore affidabilità e dimensione e memorizzazioni non volatili, se invece viene messa su RAM diventa molto più veloce e può essere implementata su client senza memorie secondarie.

Politica di aggiornamento della cache

Le politiche di aggiornamento della cache indicano come comportarsi in seguito a modifiche sulle copie, ed hanno un effetto critico sulle prestazioni e affidabilità del sistema.

La politica più semplice è la scrittura immediata (write-through), in cui la scrittura avviene contemporaneamente su cache e su disco. E' estremamente affidabile ma ha prestazioni in scrittura molto basse.
Un'alternativa è la scrittura ritardata, in cui vengono disaccoppiate le scritture rapide su cache e quelle lente in memoria di massa. Le scritture diventano così molto più veloci a prezzo di una minore affidabilità.
Una variante dell'ultima politica è la scrittura in chiusura che ricopia il file dalla cache al disco solo quando viene chiuso. E' una strategia vantaggiosa se i file vengono mantenuti aperti a lungo e aggiornati di frequente.

Coerenza

Abbiamo due metodi per verificare la validità dei dati in cache. Il primo è la verifica iniziata dal client, che ad ogni accesso o a intervalli di tempo regolari controlla che i dati locali siano coerenti con quelli principali sul server. Il secondo è la verifica iniziata dal server, che registra i file che vengono posti in cache dai vari client, e se le modalità d'accesso richieste potrebbero minare la coerenza (ad esempio la scrittura da parte di almeno uno dei due) vengono fatti partire i controlli.

Confronto tra i servizi con cache e quelli remoti

Vediamo i pro e i contro dell'utilizzo della cache:

File server con e senza stato

Lo stato di un file server è l'insieme delle informazioni che caratterizzano l'uso di un file aperto. In un file con stato il client per accedere a un file deve effettuare prima una open(), dopodiché riceve dal server un identificatore univoco di connessione che viene mantenuto per tutta la sessione. Ha prestazioni maggiori grazie al mantenimento delle informazioni in memoria centrale, facilmente accessibili grazie agli identificatori.

Un file server senza stato evita di richiedere e mantenere informazioni di stato, quindi soddisfa ogni richiesta in modo indipendente. Ha prestazioni minori ma è più semplice da realizzare e reagisce meglio ai guasti.

Replica dei file

La replica dei file su diverse macchine è una ridondanza utile sia per aumentare la disponibilità del servizio che le prestazioni, dato che selezionare una replica in un server vicino per soddisfare una richiesta di accesso comporta un tempo di servizio più breve.

La gestione della replica non è indipendente alla locazione perché la disponibilità di una di esse non può e non deve essere influenzata dalle altre. Inoltre, i suoi dettagli dovrebbero essere mantenuti trasparenti agli utenti di alto livello, o diventerebbe più problematico garantirne la consistenza.

Il problema principale delle repliche è legato al loro aggiornamento, che in teoria dovrebbe riflettersi automaticamente su tutte le istanze per mantenerle coerenti, ma che difficilmente avviene perché comporta una notevole riduzione delle prestazioni.


Torna alla pagina di Sistemi Operativi

(Printable View of http://www.swappa.it/wiki/Uni/SO-FileSystemDistribuiti)