Distributed File
System Service
Dario Agostinone
Introduzione

Fornire la possibilità di gestire un file system remoto
 Creare/Rimuovere cartelle
 Creare/Rimuovere file
 Accedere in lettura/scrittura

Obbiettivi :


Garantire l’accesso ai file anche a fronte di guasti del sistema
Problematiche affrontate :



Coordinazione
Replicazione
Accesso Concorrente
Il Problema

Gestione del file system in un contesto distribuito:


Visione trasparente rispetto all’allocazione delle risorse
Problemi di consistenza, esempio
 Creare un file in una cartella esistente
 Gestione univoca dei nomi

Accesso e modifica dei file:



Gestione della concorrenza
Gestione delle sessioni di modifica
Fasi di sviluppo

Definizione dell’architettura logica :
 DFSS
 FRS


Scelte progettuali
Implementazione del prototipo
DFSS
Responsabilità

Gestione delle cartelle
 Creazione
 Rimozione
 Gestione dei file
Client


Caratteristiche:




Accettazione e validazione
delle richieste
Sistema totalmente distribuito
Utilizzo di un intermediario per l’accesso ai file
Gruppo dei servitori dinamico
Client:


Richiesta di servizi DFSS
Richiesta di registrazione come server del
servizio
FRS
Responsabilità:





Gestione della memorizzazione
dei file
Accesso concorrente
Gestione dei proxy
Caratteristiche:



Sistema centralizzato
Insieme di repository
Client:


DFSS
Nuovo repository
Utilizzo del servizio




Client effettua la richiesta ad un Service Manager DFSS
Attesa sincrona non bloccante, tramite Callback
La richiesta viene validata ed inserita in coda
Ogni server gestisce una lista contenente l’intero File
System



Validazione senza interpellare gli altri server
Ogni operazione di creazione/rimozione richiede un
aggiornamento di tutti i server
Chiamata al FRS in modo trasparente all’utente
Coordinazione


Ogni Service Manager conosce tutti gli altri
Comunicazione tramite scambio di messaggi


Ordinamento causale tramite vector clock
Ogni Service Manager ha una coda di messaggi
associata
Gestione delle richieste
• Aggiornamento, messaggi inviati in modo
asincrono
• Nelle operazioni di accesso ai file, la risposta
al cliente viene gestita direttamente da FRS
Funzionamento FRS
1. Arrivo di una richiesta da parte di
un service manager
2. Viene creato il file sui due
repository
3. Viene creato il descrittore
4. L’ID viene inviato come risultato
dell’operazione

Ad ogni file è associato un descrittore, contenente :




ID del file
Repositories in cui è memorizzato
Stato
Numero di processi in lettura
Gestione delle sessioni

Ad ogni accesso al file è associata una sessione
Lettura
 Scrittura
 La sessione inizia quando il Client ottiene il proxy
 Termina al suo rilascio


Ottenimento del proxy:
1. Arriva una richiesta dal DFSS
2. Accesso al descrittore del file
3. Creazione del proxy
4. Invio del proxy al cliente
Gestione della concorrenza


Lettura concorrente, scrittura esclusiva
Stati di un file :




Lettura :

FREE, accettata solo se non vi sono processi in scrittura in attesa
LOCK, richiesta accodata

ZOMBIE, richiesta rifiutata


Free
Lock
Zombie
Scrittura :

FREE, accettata se non vi sono processi in lettura sul file
LOCK, richiesta accodata

ZOMBIE, richiesta rifiutata

Tolleranza ai guasti (1)


Memorizzazione dei dati durante l’esecuzione
Tolleranza del livello DFSS :


Il servizio replicato su tutti i server
Gestione della riattivazione di un server
1. Il nuovo server contatta un
server già appartenente al
servizio
2. Il server aggiunge localmente il
nuovo nodo
3. Avverte gli altri server del nuovo
server aggiunto
4. Avvia l’apprendimento
5. Il nuovo server potrà gestire
nuove richieste solo al termine
dell’apprendimento
Tolleranza ai guasti (2)

FRS, servizio centralizzato




Server centrale replicato
Memorizzazione dati in esecuzione su memoria stabile comune
Controllo tramite messaggi ad HOC
Memorizzazione dei file :




Memorizzazione su due repository diversi
Accesso in lettura sempre sul primo, cambio in caso di guasto
Scrittura su entrambe le copie
In caso di errori di inconsistenza fra le due copie si sceglie quella
più recente
Tolleranza ai guasti (3)

Gestione delle sessioni

Lettura
 Guasto del client : rieffettua la richiesta, timeout da parte del proxy per
liberare la risorsa
 Guasto del repository, redirezione sul secondario

Scrittura , operazione atomica
 Guasto del client : perdità di tutte le modifiche, time out del proxy per
liberare la risorsa
 Guasto del repository : si continua scrivendo solo sull’altro

Esecuzione monitorata dal Repository Server tramite informazioni di
log
Visione dettagliata (1)

Service Manager (DFSS)
DFSS Service Manager
Queue Manager
• Politiche gestione della coda
Call Manager
• Gestione delle richieste
Message Manager
• Gestione dei Messaggi
Group Manager
• Conoscenza del gruppo
Data Manager
• Memorizzazione dei dati
Visione dettagliata (2)

Repository Server
• Persistenza dei dati
Data Manager
Resource Manager
• Gerstione dei descrittori dei
file
• Gestione della coda
Queue Manager
Execution Monitor
• Controlla l’esecuzione dei
proxy tramite log
Prototipo



Implementato con Java RMI
Implementazione di un semplice client
DFSS




Coda FIFO delle richieste
Vector Clock -> Hashtable
Persistenza implementata senza memoria stabile
FRS



ID di un file = al path del file
Intermediari implementati come oggetti remoti che accedono ai file
richiesti, che eseguono all’interno dei Repository
Repository Server senza gestione dei guasti
Conclusioni

Vantaggi
Sistema robusto
 Buon grado di scalabilità


Svantaggi


FRS, possibile collo di bottiglia
Sviluppi futuri
Gestione della QOS
 Multiutenza
 Protezione


Critiche personali