Un file system distribuito (DFS) è un sistema distribuito che consente ai computer in una rete la memorizzazione di e l’accesso a file remoti alla stregua di quelli locali.
Un DFS deve garantire:
In letteratura, i file system distribuiti che emulano le funzionalità di un file system locale sono denominati basic file system.
I DFS rappresentano una classe di sistemi di memorizzazione di dati (Storage Systems).
Vengono applicate apposite strategie di caching dei dati, per migliorare le prestazioni dei programmi.
Un file system è quella parte di un sistema operativo responsabile per la gestione e l’organizzazione dei file. In particolare, gli obiettivi di un FS sono quelli di garantirne
Un FS fornisce alle applicazioni un’interfaccia unica per la gestione dei file.
Quasi tutti i FS forniscono un’interfaccia conforme allo standard POSIX
Contengono sia dati sia attributi.
I dati consistono in sequenze di byte accessibili dalle funzioni di read e write.
Gli attributi sono delle informazioni che descrivono il file (tipo, lunghezza, data ultima modifica, proprietario, valore del file pointer, lista per il controllo degli accessi).
Al fine di gestire un elevato numero di file, un FS è strutturato in directory, cioè in un insieme di nodi contenenti informazioni su tutti i file.
Una directory è un file speciale creato con l’obiettivo di risolvere le corrispondenza tra il nome del file in formato testuale e il suo identificativo interno.
Tutte le informazioni associate ad un file necessarie per una corretta gestione
I metadati includono:
L’accesso ai file va consentito soltanto agli utenti autorizzati, mediante uno schema di permessi di accesso.
Con riferimento ai sistemi UNIX, a ciascun file (normale, speciale o directory) sono associati alcuni attributi:
Proprietario, gruppo e permessi iniziali sono assegnati dal sistema al file al momento della sua creazione. Il proprietario potrà successivamente modificare tali attributi.
Ogni disco può essere organizzato in più partizioni, ognuna delle quali può avere un proprio file system.
Ogni disco ha uno speciale settore (Settore 0), denominato MBR (Master Boot Record), che viene utilizzato per il bootstrap. L’MBR contiene inoltre la tabella delle partizioni del disco.
Il sistema operativo suddivide ogni partizione in blocchi. La dimensione di un blocco è in genere maggiore di quella del settore del disco (ogni blocco consiste di un certo numero di settori consecutivi).
Ogni blocco contiene un insieme di settori contigui.
Nel 1980 fu realizzato il primo prototipo di un file system distribuito denominato Cambridge File System (CFS), da Birrel e Needham:
“We would wish a simple, low-level, file server in order to share an expensive resource, namely a disk, whilst leaving us free to design the filing system most appropriate to a particular client, but we would wish also to have a vailable high-level system shared between clients.”
Gli obiettivi erano dunque quelli della trasparenza (rispetto alla locazione, all’accesso, alla mobilità) e dell’efficienza (il DFS doveva garantire livelli di prestazioni comparabili con quelli non distribuiti). La consistenza era di tipo one-copy.
Trasparenza
Dell’accesso
Le applicazioni client sono ignare della distribuzione dei file. Viene utilizzata una sola interfaccia per l’accesso ai file (sia per file locali sia per file remoti). Tale proprietà garantisce che i programmi realizzati per funzionare con file locali, funzionino, senza modifiche, anche per l’accesso a file remoti.
Della Locazione
Le applicazioni clienti si riferiscono ad uno spazio uniforme dei file. I file, o gruppi di file, possono essere rilocati senza che sia necessario cambiare il loro pathname.
Della mobilità
Le applicazioni client e le tabelle di amministrazione di sistema non devono essere cambiate quando i file sono spostati.
Di performance
Le performance delle applicazioni client devono essere soddisfacenti fintanto che il carico sul servizio varia in no specifico range.
Di scala
Il servizio deve poter essere espanso, sia per carico che per dimensioni della rete.
Efficienza: Un DFS dovrebbe offrire potenza espressiva e prestazioni comparabili con quelle dei file system convenzionali.
Sicurezza: In un DFS è necessario autenticare le richieste, e proteggere i contenuti di richieste e risposte.
Eterogeneità: Le interfacce del servizio devono essere definite in maniera tale che client e server possano essere implementati su diversi sistemi operativi e hardware (openness).
Consistenza: L’uso di replicazione e caching può compromettere la semantica “one-copy” dei file system convenzionali. Apposite tecniche vanno considerate nel proggetto di un DFS per avvicinarsi a tale semantica.
Concorrenza: Le modifiche ad un file apportate da un client non devono interferire con gli accessi o modifiche fatte da altri client, che accedono simultaneamente allo stesso file.
Replicazione. In un DFS che supporta la replicazione, più copie di uno stesso file possono risiedere in differenti nodi del sistema. Ciò può comportare due benefici:
Affidabilità. Un DFS spesso costituisce un parte importante di un sistema distribuito. Risulta essenziale che un DFS continui a fornire i suoi servizi anche all’occorrenza di un guasto di uno o più link della rete, oppure di in uno o più server.
Le scelte progettuali di un DFS sono pesantemente vincolate dal livello di affidabilità dei servizi forniti.
Per tollerare communication failures transienti, la semantica dovrebbe essere “at-most-once” (difficile da realizzare).
Con l’ipotesi che tutte le operazioni fornite siano idempotenti, è possibile adottare un paradigma “at-least-once” (di più facile realizzazione), in questo modo richieste duplicate non altereranno lo stato di un server.
Per tollerare failurenei server in maniera semplice e poco costosa, viene fatta l’assunzione che i server siano “stateless”.
Vantaggi
Svantaggi
Ogni file è identificato da un id univoco (Unique File Identifier – UFID).
I file di un server possono essere collezionati in gruppi (file groups).
Un server gestisce più gruppi di file. I gruppi possono essere spostati tra più server ma un file non può mai cambiare gruppo.
Anche i gruppi hanno un identificatore univoco, generalmente composto dalla coppia <IP_address, date>.
Non fornisce operazioni per l’apertura e la chiusura di un file.
Le operazioni di lettura e scrittura includono la posizione dalla quale leggere o scrivere.
Le operazioni di accesso sono tutte idempotenti (ad eccezione della create). In tal modo è possibile utilizzare la semantica “at-least-once” (il client può ripetere l’operazione fino a quando non riceve un ack dal server).
Le operazioni ben si prestano all’implementazione di un server senza stato (stateless).
Gestisce la corrispondenza tra i nomi (testuali) dei file e gli UFID (lookup operation).
Ogni directory è realizzata mediante un file speciale che contiene tutti UFID dei file in essa contenuti.
È possibile realizzare strutture gerarchiche (o a grafo aciclico) così come nei file system convenzionali
Il modulo client è in esecuzione su ogni macchina client integrando ed estendendo le operazioni del flat file service e del directory service.
Fornisce una singola interfaccia ai programmi di livello utente in esecuzione sulle macchine client.
L’interfaccia del flat file service differisce da quella UNIX soprattutto per i meccanismi di fault tolerance.
Il controllo dei diritti di accesso viene effettuato dal server: alla richiesta si allega l’informazione relativa all’identità dell’utente.
Ciò deve essere effettuato per ogni richiesta del client: se il server conservasse informazioni sugli accessi dei client non sarebbe più stateless.
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
G. Coulouris et al.: Distributed Systems: Concepts and Design (Cap. VIII), IV ed., 2005
Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google File System. SOSP ’03
G. Coulouris et al.: Distributed Systems: Concepts and Design (Par. 21.5.1), V ed., 2011