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 » 9.File System Distribuiti


Sommario

  • Introduzione ai file systemdistribuiti
    • Caratteristiche e struttura: File System locali
    • Tipi di file e operazioni
    • Evoluzione
    • Requisiti: affidabilità
    • Modello astratto di DFS
  • Esempi di file systemdistribuiti:
    • Network File System di SUN
    • Andrew File System
    • Google File System

File System distribuiti

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.

File System distribuiti

Un DFS deve garantire:

  • persistenza e distribuzione di dati (File Service) ad un molteplicità di applicazioni clienti in esecuzione su nodi di una rete
  • consistenza tra copie multiple degli stessi dati
  • livelli di performance ed affidabilità paragonabili a quelli di file system locali

In letteratura, i file system distribuiti che emulano le funzionalità di un file system locale sono denominati basic file system.

Modelli architetturali

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.

Proprietà dei sistemi di memorizzazione dati


Caratteristiche di un file system

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

  1. la persistenza
  2. il recupero
  3. un meccanismo di naming
  4. la condivisione e la protezione

Un FS fornisce alle applicazioni un’interfaccia unica per la gestione dei file.

Struttura di un file system gerarchico


Operazioni su file

  1. Creazione
  2. Lettura
  3. Cancellazione
  4. Apertura – open(Fi): cerca sul disco la directory che contiene la entry Fi, e carica tale entry in memoria (Tabella dei file aperti)
  5. Scrittura
  6. Riposizionamento nel file – file seek
  7. Chiusura – close(Fi): trasferisce il contenuto della entry Fi in memoria sul file directory su disco

Quasi tutti i FS forniscono un’interfaccia conforme allo standard POSIX

Operazioni su file

Tipicamente le operazioni di un file System sono implementate nel kernel come System call

Tipicamente le operazioni di un file System sono implementate nel kernel come System call


File

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

Directory

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.


Metadati

Tutte le informazioni associate ad un file necessarie per una corretta gestione
I metadati includono:

  • attributi di un file
  • directories
  • altre informazioni necessarie al file system

Protezione dell’accesso

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 (owner): l’utente che ha creato il file;
  • Gruppo: il gruppo di utenti a cui il proprietario appartiene;
  • Permessi (permissions): il tipo di operazioni che il proprietario, i membri del suo gruppo o gli altri utenti possono compiere sul file.

Proprietario, gruppo e permessi iniziali sono assegnati dal sistema al file al momento della sua creazione. Il proprietario potrà successivamente modificare tali attributi.

Organizzazione fisica

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.

Evoluzione storica dei file system distribuiti

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.

Evoluzione storica dei file system distribuiti

I requisiti sono cambiati nel tempo grazie soprattutto all’evolversi delle tecnologie

I requisiti sono cambiati nel tempo grazie soprattutto all’evolversi delle tecnologie


Requisiti di un DFS

  • Transparency
  • Efficiency
  • Security
  • Heterogeneity
  • Consistency
  • Concurrency
  • Replication
  • Reliability

Requisiti di un DFS

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.

Requisiti di un DFS

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.

Requisiti di un DFS

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.

Requisiti di un DFS

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:

  • aumenta la scalabilità, in quanto al crescere del numero di client, il carico di accesso ad un gruppo di file può essere condiviso tra più server
  • aumenta la tolleranza ai guasti, poiché, in caso di un guasto di un server un’applicazione client può riferirsi ad un copia del file mantenuta da un server differente.

Affidabilità

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.

Affidabilità

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.

Affidabilità

Per tollerare failurenei server in maniera semplice e poco costosa, viene fatta l’assunzione che i server siano “stateless”.

  • I server esportano i file senza creare informazioni di stato
  • Non troveremo alcuna lista con informazioni su chi ha aperto un file (questo vuol dire che i controlli dei permessi vengono attuati ad ogni accesso → Assenza di sessione)

Vantaggi

  • Recupero da un crash veloce ed efficiente. Ad es. il reboot di un server
  • Protocollo di ripristino semplice

Svantaggi

  • Informazioni di stato mantenute in altre parti del sistema (ad esempio l’esistenza separata di un protocollo di MOUNT)

Modello concettuale di DFS


Meccanismo di naming e grouping

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

Flat file service

Implementa operazioni sul contenuto dei file. È responsabile della generazione degli UFID

Implementa operazioni sul contenuto dei file. È responsabile della generazione degli UFID


Flat file service

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

Directory service

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

Directory service


Client Module

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.

Confronto con file system UNIX

L’interfaccia del flat file service differisce da quella UNIX soprattutto per i meccanismi di fault tolerance.

  • È possibile utilizzare la semantica at-least-once poiché tutte le operazioni, tranne Create, sono idempotenti (in caso di Create vengono creati nuovi file per ogni chiamata)
  • L’interfaccia non richiede che i server memorizzino informazioni di stato (server stateless).

Controllo degli accessi

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.

I materiali di supporto della lezione

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

  • 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