File System Distribuiti

Transcript

Sistemi di memorizzazione e alcune proprietà
File System Distribuiti
Replicazione dei dati: gestione e manutenzione di un insieme di copie dei dati
condivisione
Motivazioni:
persistenza
cache/repliche
consistenza
distribuite
Esempio
-
disponibilità
Memoria principale
Sì
Sì
Sì
1
RAM
-
tolleranza ai guasti
File system
Sì
M
Sì
1
UNIX file system
-
prestazioni
File system distribuito
M
M
M
M
Sun NFS
Web
M
M
M
Sì
Web server
Memoria condivisa distribuita
M
Sì
M
M
Ivy (DSM)
Emula le funzionalità di un file system non distribuito
Oggetti remoti (RMI/ORB)
M
Sì
Sì
1
CORBA
Specifica di interfacce
Magazzino di oggetti permanenti
M
M
Sì
1
Gestione della eterogeneità
Sistema di memoria peer-to-peer
M
M
M
D
CORBA Persistent
Object Service
OceanStore
Un file system distribuito permette di memorizzare ed accedere a file remoti come
se fossero locali
Meccanismi di controllo di accesso ai dati e condivisione dei dati
Modello architettura di un f.s.d.
Tipi di consistenza
1: esattamente una copia. M: garanzia media D: garanzia debole
Casi di studio: NFS (Sun network File System), AFS (Andrew File System), CODA
S. Balsamo A.A. 2005-2006 - Università Ca’ Foscari di Venezia
SD12.2
Requisiti di un file system
Moduli del file system
Sistemi monoutente:
monoprogrammato: consistenza dello spazio dei nomi
interfaccia per le applicazioni
mapping nome testuale ->indirizzo fisico
integrità
multiprogrammato: + controllo della concorrenza
Un file system gestisce
- l’organizzazione, memorizzazione e accesso a file
- la gestione dei nomi
- la condivisione e la protezione dei file
Sistemi multiutente multiprogrammato: + sicurezza, protezione dei dati (e.g. Unix)
Un file system è organizzato in moduli
Ogni file contiene dati e un insieme di attributi
Sistema distribuito:
+ interfaccia per gli utenti
trasparenza
tolleranza ai guasti (disponibilità)
Uso di tecniche di progettazione dei sistemi distribuiti
caching
replicazione
trasferimenti a blocchi (granularità)
crittografia
SD12.3
Modulo Directory :
Associa i nomi di file a IDs
Modulo File :
associa ID a file particolari
Modulo Controllo Accesso:
Controlla il permesso delle operazioni richieste
Modulo Accesso al File:
Letture o scritture di dati o attributi di file
Modulo Blocchi:
Accede e alloca blocchi di dischi
Modulo periferiche:
operazioni I/O su disco e buffering
SD12.4
1
Struttura dei record di attributi di file
Operazioni dello UNIX file system
Lunghezza File
filedes = open(name, mode)
filedes = creat(name, mode)
Timestamp di creazione
Apre un file esistente con dato name.
Crea un nuovo file con un dato name.
Entrambe le op. restituiscono un rif. a descrittore di file
con mode è read, write o entrambi
Chiude il file aperto filedes.
Read timestamp
Write timestamp
status = close(filedes)
count = read(filedes, buffer, n)
Timestamp dell’attributo
count = write(filedes, buffer, n)
Reference count
Proprietario
pos = lseek(filedes, offset,
whence)
Tipo di file
status = unlink(name)
List di controllo degli accessi
SD12.5
status = link(name1, name2)
Rimuove il file name dalla struttura della directory. Se il file
non ha altri nomi, è cancellato
Aggiunge un nuovo nome (name2) ad un file (name1).
status = stat(name, buffer)
Restituisce gli attributi del file name nel buffer.
SD12.6
Requisiti di un file system distribuito
Architettura del file service
Nei f.s. non distribuiti le funzioni sono solitamente eseguite da funzioni di libreria
per l’I/O e dal supporto del s.o., incluse le informazioni sullo stato dei file.
Requisiti di un f.s.d.
trasparenza di accesso uso di interfacce omogenee
di locazione modificabilità e indipendenza dalla locazione
di mobilità
di prestazioni variazioni del carico
di scalabilità
concorrenza
replicazione
per requisiti di prestazioni e affidabilità
eterogenteità
piattaforme (hw e s.o.) diverse
consistenza
semantica e gestione delle replicazioni
tolleranza ai guasti tolleranza di errori di accesso, uso di op. idempotenti
serventi stateless, per ripristinare il servizio senza stato
sicurezza
controllo della autorizzazione all’accesso
efficienza
Trasferice n bytes dal file rif. da filedes al buffer.
Trasferice n bytes dal file rif. da filedes dal buffer.
Entrambe le op. restituiscono il numero di bytes trasferiti
realmente e avanzano il puntatore read-write
Spostano il punt. read-write all’offset (relativo o assoluto,
in base a whence).
SD12.7
Modello architetturale per f.s.
componenti:
modulo cliente
modulo servente: flat file service
modulo servente: directory service
Client computer
Programma Programma
Applicativo
Applicativo
Server computer
Directory service
Flat file service
Modulo cliente
Interfaccia per l’accesso ai dati
Mapping fra nomi testuali e UFID
Operazioni sul contenuto del file
UFID Unique File IDentifier
SD12.8
2
Operazioni del servizio flat file
Read(FileId, i, n) -> Data
— throws BadPosition
Write(FileId, i, Data)
— throws BadPosition
Create() -> FileId
Delete(FileId)
GetAttributes(FileId) -> Attr
SetAttributes(FileId, Attr)
Operazioni del directory service
Se 1 ≤ i ≤ Length(File): legge una sequenza fino ad n pos.
da un file a partire dalla posizione i e restituisce in Data.
Se 1 ≤ i ≤ Length(File)+1: scrive una sequenza di Data in un
file, dalla posizione i, e se necessario estende il file.
Crea un nuovo file di lunghezza 0 e restituisce un UFID
Elimina il file
Restituisce gli attributi del file
Imposta gli attributi del file
Lookup(Dir, Name) -> FileId
— throws NotFound
Cerca il nome testuale della directory e restituisce
UFID, se esiste, altrimenti una eccezione
AddName(Dir, Name, FileId)
— throws NameDuplicate
Se Name non è nella directory vi aggiunge (Name, File)
e aggiorna il record di attributo del file
Se Name è già nella directory: eccezione.
UnName(Dir, Name)
— throws NotFound
Se Name è nella directory: rimuove Name
Se Name non è nella directory: eccezione
GetNames(Dir, Pattern) -> NameSeq
Restituisce tutti i nomi della directory Dir che corrispondono
alla espressione regolare Pattern
Note:
Operazioni idempotenti (eccetto create)
Interfaccia per possibile uso di server senza stato
SD12.9
Architettura NFS
Client computer
UNIX
system calls
Architettura NFS
Server computer
identificatori di file: file handle derivati dall’i-node di Unix
Filesystem ID
i-node number del file
Programma Programma
applicativo
applicativo
Virtual file system
Local
Remote
Altri
file system
i-node generation number
I clienti NFS sono integrati nel nucleo
Nucleo UNIX
UNIX
file
system
SD12.10
NFS
client
Accesso ad NFS con semplici chiamate di sistema
Virtual file system
NFS
server
NFS
protocol
Un solo cliente serve tutti processi sulla u.e. ed usa una sola cache
UNIX
file
system
Sicurezza uso della chiave da parte di servente NFS per autenticare i clienti NFS
il servente senza stato verifica che il cliente si autorizzato ogni volta
varie versioni
Protocollo NFS: comunicazione client-server basata su Sun RPC su TCP oppure UDP
Trasparenza per l’accesso a file remoti per clienti in sistemi Unix o altri
Interfaccia identica per diversi file system locali e remoti
Eterogeneità: progetto indipendente dal s.op. (e.g. Windows, MacOs, Unix, Linux,…)
SD12.11
SD12.12
3
Operazioni del server NFS
1/2
Operazioni del server NFS
lookup(dirfh, name) -> fh, attr
Restituisce il file handle e attributi del file name nella directory
dirfh
create(dirfh, name, attr) ->
newfh, attr
Crea un nuovo nome di file nella directory dirfh con attributi attr e
restituisce il nuovo file handle e gli attributi
2/2
symlink(newdirfh, newname, string) Crea un record newname nella directory newdirfh di tipo
-> status
link simbolico con valore string. Il server non interpreta la
string ma crea un file link simbolico
readlink(fh) -> string
Restituisce la stringa associata al symbolic link file
identificato da fh.
remove(dirfh, name) status
Elimina il file name dalla directory dirfh.
getattr(fh) -> attr
Restituisce gli attributi del file fh
mkdir(dirfh, name, attr) ->
newfh, attr
Crea una nuova directory name con attributi attr e restituisce il
nuovo file handle e attributi
setattr(fh, attr) -> attr
Pone gli attributi (mode, user id, group id, size, access time e
modify time di un file). Porre la dimensione a 0 tronca il file
rmdir(dirfh, name) -> status
Cancella la directory name vuota dal padre dirfh.
Errore se la dir. non è vuota.
read(fh, offset, count) -> attr, data
Restituisce fino a count bytes di dati da un file iniziando a offset
e restituisce gli ultimi attributi del file.
readdir(dirfh, cookie, count) ->
entries
write(fh, offset, count, data) -> attr
Scrive count bytes di dati nel file iniziando a offset. Restituisce gli
attributi del file dopo la write
Restituisce fino a count bytes di record di directory dalla directory
dirfh. Ognuno ha il nome di un file, un file handle, e un opaque
pointer al record successivo, detto cookie, che è usato in successive
chiamate readdir per iniziare a leggere dal punto seguente
Se il valore del cookie è 0, legge dall’inizio.
statfs(fh) -> fsstats
Restituisce informazioni del file system (es. dimensione blocchi, no. di
blocchi liberi) che contiene il file fh.
rename(dirfh, name, todirfh, toname) Modifica il nome del file name nella directory dirfh in toname nella
-> status
directory todirfh.
link(newdirfh, newname, dirfh, name) Crea un record newname nella directory newdirfh riferito al
-> status
file name nella directory dirfh
SD12.13
File systems locale e remoto accessible su un cliente NFS
SD12.14
File systems locale e remoto accessible su un cliente NFS
Per usare un f.s. remoto si usa il processo mount service disponibile su ogni servente NFS
Ogni server ha il file di configurazione
/etc/export
con la lista dei f.s. esportabili
Ogni cliente monta un f.s. remoto con mount indicando il
- nome del server,
- i percorsi nei f.s. locale (dove montare) e remoto (dove si trova) delle directory
Server 1
Client
(root)
(root)
export
...
bob
usr
nfs
Remote
people
big jon
vmunix
Server 2
(root)
mount
...
Remote
students
x
staff
mount
users
jim ann jane joe
Note:
Il file system montato a /usr/students nel cliente è in realtà un sottoalbero a /export/people nel Server 1;
il file system montato a /usr/staff nel cliente è in realtà un sottoalbero a /nfs/users nel Server 2.
SD12.15
SD12.16
4
Caching in NFS: servente
Caching in NFS: cliente
Le implementazioni di NFS sfruttano una cache sia nel client che nel server
Caching nel cliente
Caching nel server
- Il cliente trattiene in cache i risultati delle operazioni di lettura e scrittura
-> riduce il numero di richieste spedite al server
Per il server, la cache funziona come di consueto
- blocchi di files appartenenti ai filesystem esportati sono trattenuti in memoria
-> diminuisce il tempo di risposta al client per richieste consecutive dello stesso blocco
Possibile problema:
esistenza di versioni differenti dello stesso file in nodi diversi della rete
Consistenza in scrittura:
Due meccanismi per garantire la consistenza
(le operazioni di scrittura di un cliente possono non venire propagate immediatamente nel
server e alle copie trattenute in cache da altri clienti)
Write Through
i blocchi vengono scritti su disco quando il server riceve la richiesta di scrittura da un client
Soluzione:
assegnare al cliente la responsabilità di verificare la consistenza
dei dati nella sua cache
nota:
Write Back
ad ogni accesso ad un file condiviso occorre verificare la
condizione di validità della cache
i blocchi non vengono subito scritti su disco al ricevimento della richiesta di scrittura.
NFS versione 3, usa questo tipo di cache, implementa una nuova primitiva commit( ) con la
quale il client può chiedere la scrittura di tutti i blocchi in cache
SD12.17
SD12.18
Caching in NFS: cliente
Andrew File System
Caching nel cliente
- Sviluppato nel 1983 da Carnegie Mellon University e IBM AFS
condizione di validità della cache
ogni elemento nella cache del cliente ha
Tc
tempo dell'ultima validazione
Tm
tempo dell'ultima modifica
- come NFS, consente alle applicazioni l'accesso a file system remoti, senza bisogno
di ricompilazioni
(T-Tc < t)
Il tempo trascorso dall'ultima
validazione non deve superare
un dato valore t
∨
- AFS rispetto a NFS pone maggiore enfasi sulla scalabilità
( Tm(server) = Tm(client) )
- diverse scelte implementative e architettura rispetto ad NFS.
Il tempo dell'ultima modifica registrata dal server
deve coincidere con
il tempo dell'ultima modifica registrata dal cliente
- caratteristiche principali:
- i file vengono trasferiti interamente dai server ai clienti in un unica operazione
(in AFS-3, file più grandi di 64K vengono trasferiti in blocchi di 64K)
Prestazioni di NFS
Limitazioni alle prestazioni su server NFS
- frequente uso di getattr(), per ricevere da ogni cliente per validare la propria cache,
controllando il tempo dell'ultima modifica nel server.
- limite dell’efficienza delle operazioni di scrittura sul server, a causa del write-through
SD12.19
- i clienti mantengono nella cache locale copie dei file (interi) ricevuti dai server
SD12.20
5
Distribuzione dei processi nell’Andrew File System
Workstations (Clienti)
Venus
Componenti di Andrew File System
Servers
AFS è formato da due componenti
Programma
utente
Nucleo UNIX
Venus è un cliente operante a livello utente su ogni workstation
Vice
Vice è un server, operante a livello utente
Nucleo UNIX
Venus
Programma
Il filesystem di ogni workstation è diviso in due parti
Network
utente
Nucleo UNIX
- la parte locale è visibile localmente, e non viene condivisa
- la parte condivisa è memorizzata su un server, e può esistere in varie copie
parziali sparse nelle cache dei cliente
Vice
Venus
Programma
utente
Nucleo UNIX
I file condivisi si trovano sempre nella sottodirectory /afs
Nucleo UNIX
Scalabilità
obbiettivo principale di AFS
diminuire la comunicazione cliente-servente
Trasferimento dei file in un’unica operazione
Uso di caching dei file ricevuti nei clienti
CODA: evoluzione di AFS
SD12.21
Spazio dei nomi di file visto dai clienti di AFS
Funzionamento di Andrew File System
Filesystem di ogni workstation è composta da
f.s. locale visibile solo localmente
f.s. condiviso memorizzato su un servente con eventuali copie nelle cache dei clienti
i file condivisi sono nella sottodirectory /afs ed è un sottoalbero del servente Vice
Locale
SD12.22
Condiviso
/ (root)
Funzionamento di AFS
- Quando un processo su una WS cliente apre un file remoto, e non ne esiste una copia
nella cache locale, il file viene localizzato e ne viene richiesta una copia La copia viene
memorizzata nel file system locale alla WS
- Successive operazioni di lettura/scrittura del processo agiscono sulla copia locale
- Quando il processo chiude il file, se la copia locale è stata modificata, questa viene
rispedita al server.
La copia locale alla WS viene mantenuta, per eventuali successive richieste.
Note:
tmp
bin
. . .
vmunix
- I file raramente aggiornati, o utilizzati in lettura/scrittura da un solo utente, possono rimanere
validi a lungo nella cache dei cliente
afs
- La cache locale di ciascuna WS può essere molto capiente (risiede sul disco locale)
bin
- L'implementazione di AFS si basa su alcune considerazioni sul presunto utilizzo dei file in UNIX:
- La maggior parte dei file sono piccoli
- Operazioni di lettura sono molto più frequenti di operazioni di scrittura
- L'accesso sequenziale è quello comunemente usato
- La maggior parte dei file vengono modificati da un solo utente
- I file vengono usati in burst
Symbolic
links
- I database tipicamente non hanno queste caratteristiche
=> non si prestano bene ad essere condivisi tramite AFS
SD12.23
SD12.24
6
Intercettazione delle chiamate di sistema in AFS
Consistenza della cache in AFS
1/2
Workstation
Quando un modulo Vice (server) fornisce un file a Venus (cliente), invia anche una
callback promise
Programma
utente
UNIX file
system calls
operazioni
su file remoti
promessa da parte del server a ricontattare il cliente nel caso il file venga modificato
da parte di altri client
Venus
Ad ogni file nella cache dei cliente è associato il callback
che può avere due stati
Valid: Il server non ha ancora comunicato modifiche al file, che quindi è da ritenersi valido
Cancelled: Il server ha richiamato, comunicando di invalidare la copia locale del file perchè è stata
modificata
UNIX kernel
UNIX file system
Quando un server riceve la richiesta di modifica di un file, manda un avviso a tutti i clienti ai quali ha
promesso un callback
Local
disk
=> a differenza di NFS, i server AFS non sono stateless
Quando è necessario un file non in cache si recupera e la copia memorizzata nel f.s. locale del cliente
Operazioni del processo utente solo sulla copia locali
Solo alla fine se necessario, si invia il file modificato al server
SD12.25
2/2
Una volta contattato dal server, il cliente provvede a porre il callback associato a quel file come
cancelled
Implementazione delle chiamate di sistema a file in AFS
Processo utente
Tolleranza ai guasti
Quando una WS riparte dopo un crash, deve cercare di mantenere la maggior parte del
contenuto della propria cache
open(FileName,mode)
Nucleo UNIX
Se FileName è nello
spazio condiviso passa
la richiesta a Venus
Potrebbe aver perso alcuni dei callback da parte dei server
⇒la cache va rivalidata
(Ri)validazione della cache
Venus manda una cache validation request contenente
- il file da validare
- la data di ultima modifica, come risulta dal cliente
Se il server verifica che non ci sono state modifiche a partire dalla data indicata dal
cliente, il file (e relativo callback) viene validato
Altrimenti, il callback viene posto a cancelled.
Apri il file locale e
restituisci il descrittore
In ogni caso, ciascun cliente deve rivalidare un callback una volta trascorso un certo intervallo
di tempo senza ricevere notifiche dal server
Nota:
questo meccanismo di consistenza si applica solo durante le operazioni di open( ) e close( ).
=> è possibile che clienti diversi tentino di modificare lo stesso file, con risultati inconsistenti
=> i programmi utente devono adottare strategie per garantire la consistenza delle operazioni.
read(FileDescriptor,
Buffer, length)
write(FileDescriptor,
Buffer, length)
close(FileDescriptor)
SD12.27
Venus
Controlla la lista di
file nella cache e se
non c’è una callback
promise valida
manda una richeista
del file al server Vice
relativo
Poni una copia del file
nel f.s. locale, poni il
nome nella lista della
cache locale e
restituisci il nome
locale a Unix
rete
Vice
Trasferisci una copia del
file e callback promise alla
workstation. Log la c.p.
Esegui un normale read
Unix sulla copia locale
Esegui un normale write
Unix sulla copia locale
Chiudi il file locale e
notifica a Venus
(In linea con la semantica delle operazioni standard UNIX sui file, che di default non forza alcuna verifica della concorrenza)
SD12.26
Se la copia locale è
stata modificata,
mandane copia al
servente Vice,
responsabile del file
Sostituisci il contenuto
del file e manda una
callback a tutti gli altri
clienti che hanno una
callback promise sul file
SD12.28
7
Componenti dell’interfaccia del servizio Vice
Fetch(fid) -> attr, data
Store(fid, attr, data)
Restituisce gli attributi ed eventualmente il contenuto del file
con id. fid e registra una callback promise
Aggiorna gli attributi e (event.) i contenuti del file specificato
Create() -> fid
Crea un nuovo file e registra una callback promise
Remove(fid)
Elimina il file specificato
SetLock(fid, mode)
Pone un lock il file o directory specificata, com mode
condiviso o esclusivo. I locks non cancellati scadono dopo 30 min.
ReleaseLock(fid)
RemoveCallback(fid)
Rilascia il lock del file o directory specificata
Informa il server che un processo Venus ha rimosso un file dalla
cache
Da un server Vice ad un processo Venus: cancella la
callback promise sul file specificato
BreakCallback(fid)
SD12.29
8

File System Distribuiti

Transcript

Documenti analoghi

Philip Roth and Jewish

Lucidi Introduzione agli elaboratori

Attività di ricerca dell`Università Ca` Foscari di Venezia

Università. A Ca™ Foscari si impara la lingua dei segni

MODULO PER LA RICHIESTA DI ADESIONE Confosteopatia Cod

summer intensive course of armenian

Aron Rodrigue (Stanford University) Reflections on the History and

Giovani senza futuro. La storia di Priscilla