Upload
gabriele-lombari
View
268
Download
4
Embed Size (px)
Citation preview
Google File System - GFS
Gabriele Lombari - Alessandra ZulloSistemi Operativi Avanzati - Giuseppe Cattaneo
May 23, 2016
Universita degli Studi di Salerno
Table of contents
1. Autori e Contesto Storico
2. Introduzione
3. Architettura
4. Interazioni nel sistema
5. Fault tolerance and diagnosis
6. Performance
7. Performance in Real World Cluster
8. Conclusioni1
Autori e Contesto Storico
Autori (1)
Sanjay Ghemawat
• Laureato alla Cornell University nel 1987;
• Master e Dottorato di Ricerca al M.I.T. rispettivamente nel 1990 e
1995;
• Ricercatore di Google dal 1999 (distributed systems, performance
tools,MapReduce, indexing systems, compression schemes, memory
management, data representation languages, RPC systems e altro).
2
Autori (2)
Howard Gobioff
• Laureato con lode alla Maryland University;
• Ha lavorato per il progetto NASD (1996-1999);
• Nel 1999 e diventato ricercatore di Google (advertising
system,crawling e indexing system);
• Nel 2007 ha fondato la Gobioff Foundation con l’intento di rendere
il mondo un posto migliore, finanziando progetti per l’arte,
l’istruzione e la tecnologia.3
Autori (3)
Shun-Tak Leung
• Laureato alla Washington University;
• E’ stato ricercatore per DEC (Compaq/HP);
• Attualmente ricercatore di Google (Google File System, Digital
Continuous Profiling Infrastructure )
4
Contesto Storico (1)
5
Contesto Storico (2) - AFS
• Progettato a partire dal 1983;
• Si basa su:
• Sicurezza: Autenticazione Kerberos e liste per il controllo degli
accessi a file e cartelle in cache;
• Scalabilita: File scritti e letti in una copia locale; quando
l’operazione e conclusa il file modificato e inviato al server che
tramite il meccanismo di callback notifica il cambiamento a tutti i
client che ne hanno una copia;
6
Contesto Storico (3) - NFS
• Sviluppato da SUN dal 1980 al 1985;
• Basato su RPC (Remote Procedure Call);
• Permette la condivisione di file e directory a host remoti
dichiarandone il punto di montaggio;
• Inizialmente era stateless: i server non memorizzano le informazioni
circa le richieste dei client, ad ogni richiesta tali informazioni devono
essere fornite dai client;
• Qualsiasi macchina puo essere client o server.
7
Contesto Storico (4) - CODA
• Nasce come erede di AFS;
• Aggiunge la possibilita di eseguire le operazioni in modalita
disconnessa migliorando l’affidabilita del sistema;
• A partire dalla versione 2.2 e stato integrato direttamente nel kernel
di Linux.
8
Contesto Storico (5) - Intermezzo
• Ideato da Braam (stesso ideatore di CODA);
• E’ un file system ancora in fase di test;
• Ha le stesse caratteristiche di Coda;
• Cerca di migliorare le prestazioni in fase di sincronizzazione di
operazioni in modalita disconnessa.
9
Contesto Storico (6) - NFSv4
• Influenzato da AFS
• Aggiunta di funzionalita quali autenticazione sicura e integrita dei
dati mediante Kerberos, miglioramento delle prestazioni, file caching,
lock migration;
• Diviene Statefull cioe sono mantenute le informazioni per le richieste
dei client.
10
Introduzione
Introduzione (1)
GFS fu progettato per far fronte alla rapida crescita di dati gestiti da
Google.
Condivide gli obiettivi principali dei suoi predecessori:
• Trasparenza: Le applicazioni client che elaborano i file sono ignare
della loro reale posizione piuttosto fanno riferimento ad un
namespace dei file;
• Scalabilita:Un sistema deve essere in grado di supportare in maniera
efficiente le connessioni di piu client;
• Affidabilita: Vi deve essere la disponibilita immediata dei dati senza
modifiche, alterazioni o errori; se si utilizza il meccanismo di replica
affidabilita significa che i dati devono essere coerenti su tutte le
replice;
• Efficienza: Un DFS deve offrire le stesse prestazioni (se non
migliori) di un file system tradizionale.
11
Introduzione (1)
GFS fu progettato per far fronte alla rapida crescita di dati gestiti da
Google.
Condivide gli obiettivi principali dei suoi predecessori:
• Trasparenza: Le applicazioni client che elaborano i file sono ignare
della loro reale posizione piuttosto fanno riferimento ad un
namespace dei file;
• Scalabilita:Un sistema deve essere in grado di supportare in maniera
efficiente le connessioni di piu client;
• Affidabilita: Vi deve essere la disponibilita immediata dei dati senza
modifiche, alterazioni o errori; se si utilizza il meccanismo di replica
affidabilita significa che i dati devono essere coerenti su tutte le
replice;
• Efficienza: Un DFS deve offrire le stesse prestazioni (se non
migliori) di un file system tradizionale.
11
Introduzione (1)
GFS fu progettato per far fronte alla rapida crescita di dati gestiti da
Google.
Condivide gli obiettivi principali dei suoi predecessori:
• Trasparenza: Le applicazioni client che elaborano i file sono ignare
della loro reale posizione piuttosto fanno riferimento ad un
namespace dei file;
• Scalabilita:Un sistema deve essere in grado di supportare in maniera
efficiente le connessioni di piu client;
• Affidabilita: Vi deve essere la disponibilita immediata dei dati senza
modifiche, alterazioni o errori; se si utilizza il meccanismo di replica
affidabilita significa che i dati devono essere coerenti su tutte le
replice;
• Efficienza: Un DFS deve offrire le stesse prestazioni (se non
migliori) di un file system tradizionale.
11
Introduzione (1)
GFS fu progettato per far fronte alla rapida crescita di dati gestiti da
Google.
Condivide gli obiettivi principali dei suoi predecessori:
• Trasparenza: Le applicazioni client che elaborano i file sono ignare
della loro reale posizione piuttosto fanno riferimento ad un
namespace dei file;
• Scalabilita:Un sistema deve essere in grado di supportare in maniera
efficiente le connessioni di piu client;
• Affidabilita: Vi deve essere la disponibilita immediata dei dati senza
modifiche, alterazioni o errori; se si utilizza il meccanismo di replica
affidabilita significa che i dati devono essere coerenti su tutte le
replice;
• Efficienza: Un DFS deve offrire le stesse prestazioni (se non
migliori) di un file system tradizionale.
11
Introduzione (2)
E stato progettato per rispondere alle seguenti necessita:
1. Fault tolerance;
2. Support for big file;
3. Concorrenza;
4. New consistency model.
12
Introduzione (2)
E stato progettato per rispondere alle seguenti necessita:
1. Fault tolerance;
2. Support for big file;
3. Concorrenza;
4. New consistency model.
12
Introduzione (2)
E stato progettato per rispondere alle seguenti necessita:
1. Fault tolerance;
2. Support for big file;
3. Concorrenza;
4. New consistency model.
12
Introduzione (2)
E stato progettato per rispondere alle seguenti necessita:
1. Fault tolerance;
2. Support for big file;
3. Concorrenza;
4. New consistency model.
12
Architettura
Architettura (1)
Un cluster GFS e composto dalle seguenti componenti1:
1. master (unico) ;
2. chunkservers (molti).
Tali componenti possono interagire con molti client.
1Macchine Linux Commodity
13
Architettura (2)
I file sono suddivisi in blocchi chiamati chunks, di 64MB.
Ogni chunk e identificato da un chunk handle di 64 bit, assegnato dal
master al tempo di creazione, e memorizzato da un chunkserver sul
proprio disco locale.
Ogni chunk e memorizzato con un fattore di replica pari a 3.
14
Architettura (2)
I file sono suddivisi in blocchi chiamati chunks, di 64MB.
Ogni chunk e identificato da un chunk handle di 64 bit, assegnato dal
master al tempo di creazione, e memorizzato da un chunkserver sul
proprio disco locale.
Ogni chunk e memorizzato con un fattore di replica pari a 3.
14
Architettura (2)
I file sono suddivisi in blocchi chiamati chunks, di 64MB.
Ogni chunk e identificato da un chunk handle di 64 bit, assegnato dal
master al tempo di creazione, e memorizzato da un chunkserver sul
proprio disco locale.
Ogni chunk e memorizzato con un fattore di replica pari a 3.
14
Architettura - Master (1)
Il master si occupa di memorizzare i metadati del FS(namespace,
permessi di accesso, mapping dei file in chunk, locazione corrente di ogni
chunk ).
Il master si occupa anche del controllo globale del sistema:
• gestione della localita dei chunk;
• garbage collection dei chunk orfani;
• migrazione dei chunk tra chunkservers.
Inoltre, periodicamente controlla lo stato dei chunkservers tramite dei
messaggi chiamati HeartBeat.
15
Architettura - Master (1)
Il master si occupa di memorizzare i metadati del FS(namespace,
permessi di accesso, mapping dei file in chunk, locazione corrente di ogni
chunk ).
Il master si occupa anche del controllo globale del sistema:
• gestione della localita dei chunk;
• garbage collection dei chunk orfani;
• migrazione dei chunk tra chunkservers.
Inoltre, periodicamente controlla lo stato dei chunkservers tramite dei
messaggi chiamati HeartBeat.
15
Architettura - Master (1)
Il master si occupa di memorizzare i metadati del FS(namespace,
permessi di accesso, mapping dei file in chunk, locazione corrente di ogni
chunk ).
Il master si occupa anche del controllo globale del sistema:
• gestione della localita dei chunk;
• garbage collection dei chunk orfani;
• migrazione dei chunk tra chunkservers.
Inoltre, periodicamente controlla lo stato dei chunkservers tramite dei
messaggi chiamati HeartBeat.
15
Architettura - Master (1)
Il master si occupa di memorizzare i metadati del FS(namespace,
permessi di accesso, mapping dei file in chunk, locazione corrente di ogni
chunk ).
Il master si occupa anche del controllo globale del sistema:
• gestione della localita dei chunk;
• garbage collection dei chunk orfani;
• migrazione dei chunk tra chunkservers.
Inoltre, periodicamente controlla lo stato dei chunkservers tramite dei
messaggi chiamati HeartBeat.
15
Architettura - Master (1)
Il master si occupa di memorizzare i metadati del FS(namespace,
permessi di accesso, mapping dei file in chunk, locazione corrente di ogni
chunk ).
Il master si occupa anche del controllo globale del sistema:
• gestione della localita dei chunk;
• garbage collection dei chunk orfani;
• migrazione dei chunk tra chunkservers.
Inoltre, periodicamente controlla lo stato dei chunkservers tramite dei
messaggi chiamati HeartBeat.
15
Architettura - Master (1)
Il master si occupa di memorizzare i metadati del FS(namespace,
permessi di accesso, mapping dei file in chunk, locazione corrente di ogni
chunk ).
Il master si occupa anche del controllo globale del sistema:
• gestione della localita dei chunk;
• garbage collection dei chunk orfani;
• migrazione dei chunk tra chunkservers.
Inoltre, periodicamente controlla lo stato dei chunkservers tramite dei
messaggi chiamati HeartBeat.
15
Architettura - Master (2)
Dato che il master e unico e stato necessario minimizzare il suo
coinvolgimento all’interno di operazioni di scrittura e lettura.
Ogni client interagisce con il master per ottenere informazioni circa i
chunkservers da contattare; tali informazioni sono memorizzate in cache
per un tempo limitato e utilizzate successivamente per poter comunicare
direttamente con il chunkservers.
16
Architettura - Cache
Ne client ne chunkserver hanno una cache dei file.
• Client (Metadati): La cache lato client offre pochi benefici per il
tipo di applicazione che sfrutterebbe il GFS in quanto esse lavorano
su grandi moli di dati che non possono essere memorizzate in cache,
in tal modo inoltre si semplifica tutto il lavoro in quanto non vi e la
necessita di rendere i dati coerenti;
• Chunkserver: Non e stato implementato nessun meccanismo di
caching sul chunkserver in quanto i file sono memorizzati come file
locali, quindi viene gia sfruttato il caching effettuato dal sistema
operativo (Unix) sottostante.
17
Architettura - Cache
Ne client ne chunkserver hanno una cache dei file.
• Client (Metadati): La cache lato client offre pochi benefici per il
tipo di applicazione che sfrutterebbe il GFS in quanto esse lavorano
su grandi moli di dati che non possono essere memorizzate in cache,
in tal modo inoltre si semplifica tutto il lavoro in quanto non vi e la
necessita di rendere i dati coerenti;
• Chunkserver: Non e stato implementato nessun meccanismo di
caching sul chunkserver in quanto i file sono memorizzati come file
locali, quindi viene gia sfruttato il caching effettuato dal sistema
operativo (Unix) sottostante.
17
Architettura - Cache
Ne client ne chunkserver hanno una cache dei file.
• Client (Metadati): La cache lato client offre pochi benefici per il
tipo di applicazione che sfrutterebbe il GFS in quanto esse lavorano
su grandi moli di dati che non possono essere memorizzate in cache,
in tal modo inoltre si semplifica tutto il lavoro in quanto non vi e la
necessita di rendere i dati coerenti;
• Chunkserver: Non e stato implementato nessun meccanismo di
caching sul chunkserver in quanto i file sono memorizzati come file
locali, quindi viene gia sfruttato il caching effettuato dal sistema
operativo (Unix) sottostante.
17
Lettura di un file (1)
La lettura di un file si scompone nelle seguenti fasi:
• Il client invia al master una richiesta di lettura passando come
parametri il nome del file (file name) e l’indice dei rispettivi chunk
(chunk index);
• Il master risponde passando il chunk handle di ogni chunk associato
al file con la corrispondente locazione;
18
Lettura di un file (2)
• Il client memorizza nella sua cache tali informazioni (chunk handle e
chunk location) associandole al nome del file appena richiesto (file
name);
• Invia una richiesta alla replica piu vicina ad esso, specificando il
chunk handle e i byte da leggere.
19
Dimensioni dei chunk (1)
La dimensione dei chunk e di 64MB, ognuno di essi e replicato su altri
chunkserver.
Il meccanismo di lazy space allocation 2 permette di ridurre il problema
della frammentazione interna.
2Lazy Space Allocation:l’allocazione fisica dello spazio e rimandata il piu a lungo
possibile.
20
Dimensioni dei chunk (2) - Vantaggi
L’utilizzo di blocchi di dimensioni ”grandi” ha i seguenti vantaggi :
• Riduzione richieste: i client effettuano ”minori richieste” al master
per conoscere la locazione del chunk su cui eseguire la
computazione;
• Riduzione overhead della rete: i client eseguono piu operazioni su
un dato chunk riducendo l’overhead sulla rete;
• Riduzione dei metadati: il master deve memorizzare meno
informazioni in quanto si riduce il numero totale di chunk.
21
Dimensioni dei chunk (2) - Vantaggi
L’utilizzo di blocchi di dimensioni ”grandi” ha i seguenti vantaggi :
• Riduzione richieste: i client effettuano ”minori richieste” al master
per conoscere la locazione del chunk su cui eseguire la
computazione;
• Riduzione overhead della rete: i client eseguono piu operazioni su
un dato chunk riducendo l’overhead sulla rete;
• Riduzione dei metadati: il master deve memorizzare meno
informazioni in quanto si riduce il numero totale di chunk.
21
Dimensioni dei chunk (2) - Vantaggi
L’utilizzo di blocchi di dimensioni ”grandi” ha i seguenti vantaggi :
• Riduzione richieste: i client effettuano ”minori richieste” al master
per conoscere la locazione del chunk su cui eseguire la
computazione;
• Riduzione overhead della rete: i client eseguono piu operazioni su
un dato chunk riducendo l’overhead sulla rete;
• Riduzione dei metadati: il master deve memorizzare meno
informazioni in quanto si riduce il numero totale di chunk.
21
Dimensioni dei chunk (2) - Vantaggi
L’utilizzo di blocchi di dimensioni ”grandi” ha i seguenti vantaggi :
• Riduzione richieste: i client effettuano ”minori richieste” al master
per conoscere la locazione del chunk su cui eseguire la
computazione;
• Riduzione overhead della rete: i client eseguono piu operazioni su
un dato chunk riducendo l’overhead sulla rete;
• Riduzione dei metadati: il master deve memorizzare meno
informazioni in quanto si riduce il numero totale di chunk.
21
Dimensioni dei chunk (2) - Svantaggi
L’utilizzo di blocchi di dimensioni ”grandi” con il meccanismo di lazy
space allocation ha i seguenti svantaggi:
• Piccoli file: i piccoli file sono composti da un numero piccolo di
chunk, se non uno. Essi diventano degli hot spot quando molti
client richiedono l’accesso allo stesso file.
Gli hot spot furono scoperti quando GFS fu usato come
batch-queue system: venne scritto un eseguibile come singolo file su
un solo chunk (overload di richieste).
22
Metadati (1)
Il master memorizza in memoria tre tipi di metadati:
1. i file e chunk namespace;
2. il mapping dei file in chunk;
3. la locazione di ogni replica.
Per i primi due vengono loggate le mutazioni mediante operation log
memorizzate sull’hard disk locale e replicate su macchine remote, in tal
modo lo stato del master e sempre aggiornato in maniera semplice e
affidabile.
23
Metadati (1)
Il master memorizza in memoria tre tipi di metadati:
1. i file e chunk namespace;
2. il mapping dei file in chunk;
3. la locazione di ogni replica.
Per i primi due vengono loggate le mutazioni mediante operation log
memorizzate sull’hard disk locale e replicate su macchine remote, in tal
modo lo stato del master e sempre aggiornato in maniera semplice e
affidabile.
23
Metadati (1)
Il master memorizza in memoria tre tipi di metadati:
1. i file e chunk namespace;
2. il mapping dei file in chunk;
3. la locazione di ogni replica.
Per i primi due vengono loggate le mutazioni mediante operation log
memorizzate sull’hard disk locale e replicate su macchine remote, in tal
modo lo stato del master e sempre aggiornato in maniera semplice e
affidabile.
23
Metadati (2)
I metadati sono memorizzati in memoria per rendere le operazioni piu
veloci.
Il master legge lo stato del sistema in maniera piu semplice ed efficiente
effettuando delle scansioni periodiche; tali scansioni sono utilizzate per
implementare meccanismi come ad esempio garbage-collection,
re-replication, migrazione dei chunk.
PROBLEMI: Il master memorizza 64 byte di metadati per ogni blocco
di 64 MB.
24
Chunk location
Il master non tiene traccia sul disco di quale chunkserver memorizza la
replica di un dato chunk, riesce ad ottenere tali informazioni chiedendole
di volta in volta ad un chunkserver.
Il master si tiene aggiornato sullo stato globale del sistema utilizzando
dei messaggi regolati HeartBeat, in questo modo non si ha la necessita di
sincronizzare chunkserver e master evitando problemi quali
fallimenti,riavvii e cosı via.
25
Operation Log
• E’ uno dei punti centrali nel GFS;
• Contiene lo storico dei cambiamenti dei metadati;
• Dato che le operazioni in rete sono critiche, si rende tutto piu
affidabile se le modifiche non sono visibili ai client finquando non
sono persistenti;
• E’ possibile ritornare allo stato iniziale del sistema in qualsiasi
momento, ripristinando i metadati relativi ai vari chunk perdendo al
massimo solo le ultime operazioni di scrittura sul file;
26
Modello di Consistenza (1)
• Atomicita delle mutazioni del file namespace;
• Regione del file: lo stato dipende dal tipo di mutazione effettuata,
e puo essere:
• Consistente: tutti i client vedono lo stesso dato indipendentemente
dalla replica su cui lo leggono;
• Definita: se e consistente e tutti i client vedono la modifica nella
sua interezza;
• Indefinita ma consistente: tutti i client vedono gli stessi dati ma le
modifiche possono non essere state apportate nella loro interezza
(scritture concorrenti e scritture non concorrenti);
• Inconsistente: i client vedono dati differenti poiche dipende dalla
copia da cui li leggono, le copie sono differenti a causa di un
fallimento nella mutazione.
27
Modello di Consistenza (1)
• Atomicita delle mutazioni del file namespace;
• Regione del file: lo stato dipende dal tipo di mutazione effettuata,
e puo essere:
• Consistente: tutti i client vedono lo stesso dato indipendentemente
dalla replica su cui lo leggono;
• Definita: se e consistente e tutti i client vedono la modifica nella
sua interezza;
• Indefinita ma consistente: tutti i client vedono gli stessi dati ma le
modifiche possono non essere state apportate nella loro interezza
(scritture concorrenti e scritture non concorrenti);
• Inconsistente: i client vedono dati differenti poiche dipende dalla
copia da cui li leggono, le copie sono differenti a causa di un
fallimento nella mutazione.
27
Modello di Consistenza (1)
• Atomicita delle mutazioni del file namespace;
• Regione del file: lo stato dipende dal tipo di mutazione effettuata,
e puo essere:
• Consistente: tutti i client vedono lo stesso dato indipendentemente
dalla replica su cui lo leggono;
• Definita: se e consistente e tutti i client vedono la modifica nella
sua interezza;
• Indefinita ma consistente: tutti i client vedono gli stessi dati ma le
modifiche possono non essere state apportate nella loro interezza
(scritture concorrenti e scritture non concorrenti);
• Inconsistente: i client vedono dati differenti poiche dipende dalla
copia da cui li leggono, le copie sono differenti a causa di un
fallimento nella mutazione.
27
Modello di Consistenza (1)
• Atomicita delle mutazioni del file namespace;
• Regione del file: lo stato dipende dal tipo di mutazione effettuata,
e puo essere:
• Consistente: tutti i client vedono lo stesso dato indipendentemente
dalla replica su cui lo leggono;
• Definita: se e consistente e tutti i client vedono la modifica nella
sua interezza;
• Indefinita ma consistente: tutti i client vedono gli stessi dati ma le
modifiche possono non essere state apportate nella loro interezza
(scritture concorrenti e scritture non concorrenti);
• Inconsistente: i client vedono dati differenti poiche dipende dalla
copia da cui li leggono, le copie sono differenti a causa di un
fallimento nella mutazione.
27
Modello di Consistenza (1)
• Atomicita delle mutazioni del file namespace;
• Regione del file: lo stato dipende dal tipo di mutazione effettuata,
e puo essere:
• Consistente: tutti i client vedono lo stesso dato indipendentemente
dalla replica su cui lo leggono;
• Definita: se e consistente e tutti i client vedono la modifica nella
sua interezza;
• Indefinita ma consistente: tutti i client vedono gli stessi dati ma le
modifiche possono non essere state apportate nella loro interezza
(scritture concorrenti e scritture non concorrenti);
• Inconsistente: i client vedono dati differenti poiche dipende dalla
copia da cui li leggono, le copie sono differenti a causa di un
fallimento nella mutazione.
27
Modello di Consistenza (2)
Le operazioni che portano alla mutazione di un file possono essere:
• WRITE: il client specifica l’offset del file (con scritture concorrenti
una regione puo contenere frammenti provenienti da piu client);
• RECORD APPEND: il client specifica solo i dati da scrivere; e il
GFS a specificare l’offset.
In entrambi i casi il GFS non garantisce che non vi siano record
duplicati.
28
Modello di Consistenza (2)
Le operazioni che portano alla mutazione di un file possono essere:
• WRITE: il client specifica l’offset del file (con scritture concorrenti
una regione puo contenere frammenti provenienti da piu client);
• RECORD APPEND: il client specifica solo i dati da scrivere; e il
GFS a specificare l’offset.
In entrambi i casi il GFS non garantisce che non vi siano record
duplicati.
28
Interazioni nel sistema
Interazioni con il sistema
Tutto il sistema e stato disegnato per minimizzare le interazioni con il
master.
Questa ottimizzazione e stata creata tramite l’utilizzo di un meccanismo
chiamato lease.
Vedremo adesso l’utilizzo del concetto di lease applicato ad un
operazione di Mutation.
29
Interazioni con il sistema - Il concetto di lease
Una mutation e un’operazione che porta ad un cambiamento dei
metadati.
La modifica deve essere effettuata su tutte le repliche del chunk.
Il sistema ”affitta”3 un chunk, il quale viene chiamato primary ad un
processo, e solo ad esso.
Il primary esegue tutte le modifiche richieste in un determinato ordine, ed
ogni replica del chunk effettuera le modifiche nello stesso ordine (per
garantire coerenza nei dati).
3Il lease dura tipicamente 60 secondi, ma puo essere esteso in caso di necessita.
30
Interazioni con il sistema - Scrittura (1)
Il processo di scrittura puo essere riassunto in 7 step:
31
Interazioni con il sistema - Scrittura (2)
1. Il client chiede al master quale chunkserver ha il lease del chunk e la
posizione delle repliche;
2. Il master risponde con con l’identita del primary e la posizione delle
repliche. Il client mette in cache i dati per evitare ulteriori contatti
con il master;
3. Il client trasferisce i dati a tutte le repliche. I dati vengono inseriti in
un LRU, dove restano finche non vengono processati o cancellati per
vecchiaia;
4. Una volte che tutte le repliche hanno ricevuto i dati, il client invia
una richiesta di scrittura al primary. Questo processa le richieste di
modifiche, ricevute anche da piu client, assegnando un numero,
crescente, ad ogni modifica ed effettua le modifiche localmente.
32
Interazioni con il sistema - Scrittura (3)
5. Il primary inoltra le richieste di modifica a tutte le repliche.
6. I secondaries rispondono al primary riportando di aver completato
l’operazione;
7. Il primary risponde al client riportando ogni errore riscontrato
durante la modifica. Nel caso in cui su qualche replica vi sia
riscontrato un errore la regione modificata viene segnalata come
inconsistente e la richiesta del client e considerata fallita.
Se la grandezza dei dati da scrivere e superiore a quella di un chunk
l’operazione viene divisa in piu operazioni di scrittura.
33
Flusso dei dati
Si e scelto di disaccoppiare il flusso dei dati da quello di controllo per
ottimizzare l’utilizzo della rete.
Infatti mentre il flusso di controllo si propaga dal client alle repliche
necessarie per l’utilizzo del software, i dati si propagano utilizzando il
meccanismo di pipeling tra i vari chunkserves.
I dati vengono propagati tenendo conto anche della topologia della rete.
34
Atomic Record Append (1)
GFS fornisce un’operazione di append atomica chiamata record append.
Nelle operazioni di scrittura normali e il client a decidere l’offset di
scrittura nel file. In questo caso, invece, il client deve specificare solo i
dati, l’offset viene scelto dal sistema e viene restuito in output.
E’ molto similare all’operazione di srittura di un file su un sitema UNIX in
un file aperto in modalita O APPEND.
35
Atomic Record Append (2)
Il client ”inserisce” i dati all’interno di tutte le repliche dell’ultimo chunk
dei dati.
Quando il primary riceve il blocco di dati da inserire verifica se questo
rientra all’interno della dimensione del blocco. Se cio non e vero riempe il
blocco, e fa compire la stessa azione a tutti i secondary e comunica al
client di dover scrivere in un altro chunk. Altrimenti riceve i dati, li
inserisce nel blocco e comunica ai secondary di intraprendere la stessa
operazione.
Nel caso in cui qualche append fallisce il client riprova la scrittura. Cio
comporta che parte dei dati, o i dati interi, possono trovarsi piu volte
all’interno dei blocchi.
GFS garantisce solo l’atomicita di un’operazione.
36
Snapshot
L’operazione di snapshot permette di effettuare copie di file o di ”folder
tree”.
Per creare uno snapshot viene utilizzata la tecnica del copy-on-write.
Quando il master riceve una richiesta di snapshot:
1. Revoca ogni lease sui chunk;
2. Scrive l’operazione nel log;
3. Duplica i metadati riguardanti i file, o il folder tree, i quali
punteranno ai chunk gia presenti nel GFS;
4. Quando un client effettua una richiesta per un chunk C il master
inoltra la richiesta del client verso un handle C I , e richiede ai
chunkservers che posseggono il chunk C di creare un nuovo chunk
C I .
37
Master operation
Il master esegue tutte le operazioni sul namespace ed inoltre gestisce
tutte le operazioni sui chunks all’interno dell’intero sistema.
In particolare si occupa di:
• Namespace Management and Locking;
• Replica Placement;
• Creation, Re-Replication and Balancing;
• Garbage collection;
• Stale replica detection.
38
Namespace Management and Locking
GFS rappresenta logicamente il namespace con una tabella di ricerca
mappando il percorso completo in metadati.
Ogni nodo nell’albero dei namespace ha associato un read-write lock
Dato che le operazioni del master possono prendere molto tempo, esso
utilizza questi lock per impedire che altri nodi4 possano accedere alle
stesse risorse.
Tipicamente se un operazione coinvolge /d1/../dn/foo viene acquisito il
read-lock su /d1/../dn ed il write-lock o il read-lock sull’intera path.
4Compreso se stesso.
39
Replica Placement
Tipicamente la distribuzione dei cluster GFS e composta da piu livelli.
Esso, infatti, puo essere composto da migliaia di computer disposti su piu
rack. E questi computer risultano accessibili da client, che non
necessariamente sono locati nello stesso rack. Ed inoltre le
comunicazione tra i vari rack possono coinvolgere diversi switch.
E’ quindi molto importante gestire il posizionamento dei chunk in
maniera intelligente. Infatti le policy di posizionamento dei chunk si pone
principalmente due obiettivi:
• Massimizzare l’affidabilita e la disponibilita dei chunk;
• Massimizzare l’utilizzo della banda a disposizione.
Non basta diffondere le repliche dei chunk tra le macchine, ma e
necessario di diffonderli anche tra i vari rack in modo da garantire la
disponibilita dei file anche se uno dei rack e, ad esempio, offline.
40
Creation, Re-replication, Rebalancing
I chunk vengono creati per tre motivi: creation, re-replication e
rebalancing.
Quando il master crea un chunk sceglie dove posizionarli in base a tre
fattori:
• Utilizzo medio del disco del chunkserver;
• Minimizzare il numero di nuove creazioni sullo stesso chunkserver;
• Ottimizzare la diffusione dei chunk tra i vari rack.
Viene effettuata l’operazione re-replication non appena il numero di
repliche scende al di sotto di una soglia fissata. Quando necessario, il
master ”ordina” ad un chunkserver di copiare un chunk da una delle
repliche disponibili.
Inoltre il master periodicamente sposta le repliche per ottimizzare il
carico di lavoro. Operazione chiamata rebalancing.
41
Garbage Collection
Dopo che un file e stato cancellato il GFS non reclama subito lo spazio.
La deallocazione avviene in modo lazy.
Il file inizialmente viene solo rinominato, con un hidden name il quale
contiene anche un timestamp della cancellazione. Il master
periodicamente controlla il file system e se il file e hidden da almeno tre
giorni5 allora viene cancellato dal namespace.
Nei vari messaggi di HeartBeat che vengono scambiati tra master e
chunkserver viene incluso anche un elenco dei chunk disponibili nel
chunkserver. In questo modo il master comunica la necessita di un
eventuale cancellazione di parte dei chunk.
5l’intervallo e configurabile
42
Garbage Collection - Riflessioni
Cosı impletata la garbage collection risulta essere:
• Semplice ed efficace in un ambiente altamente distribuito dove il
fallimento delle componenti sono comuni;
• Le operazioni per liberare spazio vengono effettuate in maniera
completamente batch, ammortizzandone cosı il costo;
• Il tempo che passa tra la cancellazione ”fittizia” e l’effettiva
cancellazione permette di recuperare file cancellati per errore6.
Le uniche problematiche riscontrate con questa modalita riguardano le
applicazioni che creano e cancellano file ripetutamente poiche non hanno
possibilita di riutilizzare lo spazio all’istante.
6E’ possibile recuperare un hidden file semplicemente rinominandolo.
43
Stale Replica Detection
Le repliche possono diventare stantie se il chunk server fallisce o per
qualche motivo perde qualche mutations. Per ovviare a questo problema
il master conserva un chunk version number.
Il version number viene aggiornato ad ogni lease e viene aggiornato sia
sul master che su ogni chunkserver in maniera persistente.
Le stale replica vengono cancellate in un ciclo regolare di garbage
collection.
Inoltre se il master rileva qualche copia stale invia al chunkserver il blocco
aggiornato ed i relativi version number.
44
Fault tolerance and diagnosis
Fault tolerance and diagnosis
In un ambiente cosı altamente distribuito i failure sono la regola e non
l’eccezione. E’ necessario allora avere dei meccanismi che assicurano la
fault tolerance.
In particolare e necessario che siano implementati i concetti di :
• High Availability:
– Fast Recovery;
– Chunk Replication;
– Master Replication.
• Data Integrity.
45
Fast Recovery and Replication
Master e chunkserver sono progettati per salvare il loro stato in modo da
riuscire ad effettuare un avvio molto piu veloce. Il sistema infatti non
distingue il normale spegnimento da quello ”anormale”.
Il sistema e progettato per replicare i chunk in piu rack e su piu
chunkservers. L’utente puo impostare diversi fattori di replica per diverse
porzioni di namespace. Il master ordina le repliche quando e necessario.
Lo stato del master e replicato per affidabilita. Tutti gli operation log
sono replicati su piu macchine. Quando esso si guasta e sufficiente che
l’infrastruttura che monitora GFS avvii un nuovo processo master.
Comunque i master ”ombra” forniscono accesso in sola lettura.
46
Data integrity
Per garantire l’integrita dei dati viene utilizzato il checksumming, grazie
al quale e possibile riconoscere la corruzione dei dati salvati.
Dato che sarebbe improponibile rilevare la corruzione comparando le
repliche attraverso la rete, ogni chunkserver verifica l’integrita
indipendentemente.
Per le operazioni di lettura il chunkserver verifica l’integrita dei blocchi di
tutto il range di blocchi di lettura. Nel caso in cui si verifica qualche
errore il chunkserver riporta un errore al client e comunica la presenza di
inconsistenza al master, il quale provvedera a copiare il chunk da un’altra
replica.
47
Diagnostic Tools
GFS fornisce come strumento di diagnostica un log ampio e dettagliato
all’interno del quale vengono registrati tutti gli eventi significanti del
sistema (e tutte le richieste e le risposte RPC). Senza di esso e
impossibile replicare interazioni transienti e non replicabili.
Ovviamente possono essere cancellati senza alcun effetto sulla correttezza
del sistema.
Dato che il log di RPC contiene tutte le richieste e le risposte RPC e
possibile ricostruire l’intera cronologia delle transazioni e risalire al
problema.
48
Performance
Micro-benchmark
Il cluster del GFS usato per i test delle performance relativi al 2003 era
formato da:
• 1 master ( con 2 repliche);
• 16 chuckservers;
• 16 client
Ogni macchina era configurata con un processore PIII dual core 1.4 GHz,
con 2GB di RAM, 2 hard disk di 80GB ciascuno e con una connessione
Ethernet di 100 Mbps, e i chunkserver e i client erano connessi mediante
uno switch di 1 Gbps.
49
Micro-benchmark - Reads
Ognuno degli N client legge 4MB per 256 volte (1GB di dati) da un file
di 320GB.
Il limite teorico imposto dalla topologia di rete e di :
• 12.5MBps ( 100Mbps ) a macchina, raggiunti 10MBps ( 80% );
• 125MBps ( 1Gbps ) considerando gli switch collegati, raggiunti
94MBps (75 % ).
50
Micro-benchmark - Write
N client scrivono (1GB di dati) simultaneamente su N file differenti.
Il limite teorico e di 67MBps considerando che vi e una maggiore
congestione della rete rispetto alle read in quanto per ogni scrittura i dati
devono essere replicati su 3 chunkserver differenti.
Le velocita di scrittura raggiunte sono state:
• 6.3MBps per singolo client rispetto ai 12.5MBps possibili;
• 35MBps per 16 client rispetto ai 67MBps possibili.
51
Micro-benchmark - Record Append
• N client eseguono una append simultaneamente su un file;
• Le performance sono limitate dalla banda del chunkserver che
memorizza l’ultimo chunk del file, indipendentemente dal numero di
client;
• Si parte da 6.0 MB/s per un client e si termina con 4.8MB/s per 16
client, tale cambiamento dipende dalla congestione della rete e dalle
variazioni della velocita di trasferimento dei dati dei differenti client.
52
Performance in Real World
Cluster
Real World Cluster
Sono state messe a paragone le performance di due cluster usati da
Google per scopi differenti.
Li indicheremo come segue:
• CLUSTER A: Usato per scopi di ricerca e sviluppo;
• CLUSTER B: Usato per elaborazione dei dati.
53
Real World Cluster - Storage e Metadata
55TB/3 = 18TB di dati. 155/3 = 52TB di dati.
* Dead files: file cancellati o rimpiazzati da nuove versione che ancora non sono stati bonificati.
NOTA BENE: Il cluster B ha piu dead file e chunk poiche i suoi file
tendono ad essere piu grandi;
- Chunkserver’s Metadata: checksum per ogni blocco di 64KB +
numero di versione per chunk;
- Master’s Metadata: nome dei file + proprietario e permessi di un file
+ mapping dei chunk + mapping di ogni replica per ogni chunk +
numero di versione corrente per ogni chunk 54
Real World Cluster - Reads e Writes
Al momento dell’esecuzione dei test entrambi i cluster erano stati appena
riavviati a causa di un aggiornamento ad una nuova versione del GFS.
La configurazione della rete era:
• 750MBps per il cluster A;
• 1300MBps per il cluster B.
Le prestazioni in scrittura mediamente erano di 30MBps dopo il riavvio,
bisogna precisare che durante le misurazioni il cluster B era nel pieno
delle sue attivita per la produzione di circa 100 MBps.
55
Conclusioni
GFS / HDFS - Nascita
Con la diffusione dei Big Data nacque l’esigenza di apportare delle
modifiche all’architettura dei sistemi di elaborazione.
Google ha dato via al cambiamento nel 2003 con la nascita del GFS e nel
2004 con il rilascio di MapReduce.
Sempre nel 2003 Cutting stava lavorando al crawler web open source
chiamato Nutch, in particolare su alcuni elementi nel sistema in comune
con il GFS e il MapReduce di Google, l’anno successivo (2004) Nutch
entro a far parte del progetto Apache Lucene e successivamente(2006)
anche Yahoo! si interesso al progetto dando la nascita ad Hadoop.
56
GFS / HDFS - Motivazioni
• Il GFS e nato per l’elaborazione dei BigData di Google, licenza
proprietaria;
• HDFS e nato per l’esecuzione di applicazioni MapReduce ed e usato
da differenti client che hanno scopi differenti (Yahoo!, Facebook,
IBM, Twitter e cosı via. . .), e OpenSource.
57
GFS / HDFS - Assunzioni e Differenze
A parte dettagli relativi all’architettura, alle motivazioni e gli utilizzi
HDFS e GFS hanno molti punti in comune:
• File di Grandi dimensioni;
• Commodity Hardware;
• Scritture concorrenti;
• Banda Continua piuttosto che Bassa Latenza.
• Meccanismo di replica: costi di scrittura minimizzati, disposizione in
differenti Rack, sfruttamento della banda
Hadoop e ispirato dal GFS e dal MapReduce ma mira a fornire gli stessi
servizi tramite un progetto Open Source.
58
Conclusioni
Il GFS possiede le qualita essenziali per supportare workload su larga
scala su hardware-commodity.
• E’ nato per la gestione e l’elaborazione efficiente dei dati di Google
su larga scala;
• I fallimenti delle componenti sono considerati ”comuni” e non
eccezioni;
• I fault sono constantemente monitorati, le repliche dei dati sono
cruciali e vi e una modalita di recovery veloce e automatica,
checksum
• Alto throughput anche con readers e writers concorrenti.
59