The Google File System

Google File System - GFS
Gabriele Lombari - Alessandra Zullo
Sistemi Operativi Avanzati - Giuseppe Cattaneo
May 23, 2016
Universit`a 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. Conclusioni
1

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 è 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 Proﬁling Infrastructure )
4

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;
• Scalabilità: File scritti e letti in una copia locale; quando
l’operazione è conclusa il file modificato è 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 ﬁle 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 pu`o essere client o server.
7

Contesto Storico (4) - CODA
• Nasce come erede di AFS;
• Aggiunge la possibilità di eseguire le operazioni in modalità
disconnessa migliorando l’affidabilità del sistema;
• A partire dalla versione 2.2 è stato integrato direttamente nel kernel
di Linux.
8

Contesto Storico (5) - Intermezzo
• Ideato da Braam (stesso ideatore di CODA);
• E’ un ﬁle system ancora in fase di test;
• Ha le stesse caratteristiche di Coda;
• Cerca di migliorare le prestazioni in fase di sincronizzazione di
operazioni in modalit`a disconnessa.
9

Contesto Storico (6) - NFSv4
• Influenzato da AFS
• Aggiunta di funzionalità quali autenticazione sicura e integrità dei
dati mediante Kerberos, miglioramento delle prestazioni, file caching,
lock migration;
• Diviene Statefull cioè sono mantenute le informazioni per le richieste
dei client.
10

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 ﬁle sono ignare
della loro reale posizione piuttosto fanno riferimento ad un
namespace dei ﬁle;
11

Introduzione (1)
Google.
• Scalabilità:Un sistema deve essere in grado di supportare in maniera
efficiente le connessioni di più client;
11

Introduzione (1)
Google.
• Affidabilità: Vi deve essere la disponibilità immediata dei dati senza
modifiche, alterazioni o errori; se si utilizza il meccanismo di replica
affidabilità significa che i dati devono essere coerenti su tutte le
replice;
11

Introduzione (1)
Google.
• Affidabilità: Vi deve essere la disponibilità immediata dei dati senza
modifiche, alterazioni o errori; se si utilizza il meccanismo di replica
affidabilità 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 necessit`a:
1. Fault tolerance;
12

Introduzione (2)
1. Fault tolerance;
2. Support for big ﬁle;
12

Introduzione (2)
1. Fault tolerance;
3. Concorrenza;
12

Introduzione (2)
1. Fault tolerance;
3. Concorrenza;
4. New consistency model.
12

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 ﬁle sono suddivisi in blocchi chiamati chunks, di 64MB.
14

Architettura (2)
Ogni chunk `e identiﬁcato da un chunk handle di 64 bit, assegnato dal
master al tempo di creazione, e memorizzato da un chunkserver sul
proprio disco locale.
14

Architettura (2)
Ogni chunk è 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 è 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 ﬁle in chunk, locazione corrente di ogni
chunk ).
15

chunk ).
Il master si occupa anche del controllo globale del sistema:
15

chunk ).
• gestione della localit`a dei chunk;
15

chunk ).
• garbage collection dei chunk orfani;
15

chunk ).
• migrazione dei chunk tra chunkservers.
15

chunk ).
• migrazione dei chunk tra chunkservers.
Inoltre, periodicamente controlla lo stato dei chunkservers tramite dei
messaggi chiamati HeartBeat.
15

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
Nè client nè chunkserver hanno una cache dei file.
17

• 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 è la
necessità di rendere i dati coerenti;
17

• 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 è la
necessità di rendere i dati coerenti;
• Chunkserver: Non è stato implementato nessun meccanismo di
caching sul chunkserver in quanto i file sono memorizzati come file
locali, quindi viene già 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 più vicina ad esso, specificando il
chunk handle e i byte da leggere.
19

Dimensioni dei chunk (1)
La dimensione dei chunk è di 64MB, ognuno di essi è 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 è rimandata il più a lungo
possibile.
20

Dimensioni dei chunk (2) - Vantaggi
L’utilizzo di blocchi di dimensioni ”grandi” ha i seguenti vantaggi:
21

• Riduzione richieste: i client eﬀettuano ”minori richieste” al master
per conoscere la locazione del chunk su cui eseguire la
computazione;
21

computazione;
• Riduzione overhead della rete: i client eseguono pi`u operazioni su
un dato chunk riducendo l’overhead sulla rete;
21

computazione;
• Riduzione overhead della rete: i client eseguono pi`u 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 ﬁle e chunk namespace;
23

Metadati (1)
2. il mapping dei ﬁle in chunk;
23

Metadati (1)
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 è sempre aggiornato in maniera semplice e
affidabile.
23

Metadati (2)
I metadati sono memorizzati in memoria per rendere le operazioni più
veloci.
Il master legge lo stato del sistema in maniera più 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 necessit`a 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 più
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)
• Atomicità delle mutazioni del file namespace;
• Regione del file: lo stato dipende dal tipo di mutazione effettuata,
e può essere:
27

e pu`o essere:
• Consistente: tutti i client vedono lo stesso dato indipendentemente
dalla replica su cui lo leggono;
27

e può essere:
• Definita: se è consistente e tutti i client vedono la modifica nella
sua interezza;
27

e può essere:
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);
27

e può essere:
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 poichè dipende dalla
copia da cui li leggono, le copie sono differenti a causa di un
fallimento nella mutazione.
27

Le operazioni che portano alla mutazione di un file possono essere:
• WRITE: il client specifica l’offset del file (con scritture concorrenti
una regione può contenere frammenti provenienti da più client);
28

Le operazioni che portano alla mutazione di un file possono essere:
• WRITE: il client specifica l’offset del file (con scritture concorrenti
una regione può contenere frammenti provenienti da più client);
• RECORD APPEND: il client specifica solo i dati da scrivere; è il
GFS a specificare l’offset.
In entrambi i casi il GFS non garantisce che non vi siano record
duplicati.
28

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 è 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 effettuerà le modifiche nello stesso ordine (per
garantire coerenza nei dati).
3Il lease dura tipicamente 60 secondi, ma può essere esteso in caso di necessità.
30

Interazioni con il sistema - Scrittura (1)
Il processo di scrittura pu`o essere riassunto in 7 step:
31

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’identità 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 finchè 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 più client, assegnando un numero,
crescente, ad ogni modifica ed effettua le modifiche localmente.
32

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 è considerata fallita.
Se la grandezza dei dati da scrivere è superiore a quella di un chunk
l’operazione viene divisa in più operazioni di scrittura.
33

Flusso dei dati
Si è 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 è 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 modalità 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 ciò non è 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. Ciò
comporta che parte dei dati, o i dati interi, possono trovarsi più volte
all’interno dei blocchi.
GFS garantisce solo l’atomicità 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 già presenti nel GFS;
4. Quando un client effettua una richiesta per un chunk C il master
inoltra la richiesta del client verso un handle CI
, e richiede ai
chunkservers che posseggono il chunk C di creare un nuovo chunk
CI
.
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 è composta da più livelli.
Esso, infatti, può essere composto da migliaia di computer disposti su più
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’affidabilità e la disponibilità dei chunk;
• Massimizzare l’utilizzo della banda a disposizione.
Non basta diffondere le repliche dei chunk tra le macchine, ma è
necessario di diffonderli anche tra i vari rack in modo da garantire la
disponibilità dei file anche se uno dei rack è, 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 è 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 è 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 necessità di un
eventuale cancellazione di parte dei chunk.
5l’intervallo è 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 modalità riguardano le
applicazioni che creano e cancellano file ripetutamente poichè non hanno
possibilità 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
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 più veloce. Il sistema infatti non
distingue il normale spegnimento da quello ”anormale”.
Il sistema è progettato per replicare i chunk in più rack e su più
chunkservers. L’utente può impostare diversi fattori di replica per diverse
porzioni di namespace. Il master ordina le repliche quando è necessario.
Lo stato del master è replicato per affidabilità. Tutti gli operation log
sono replicati su più macchine. Quando esso si guasta è 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’integrità dei dati viene utilizzato il checksumming, grazie
al quale è possibile riconoscere la corruzione dei dati salvati.
Dato che sarebbe improponibile rilevare la corruzione comparando le
repliche attraverso la rete, ogni chunkserver verifica l’integrità
indipendentemente.
Per le operazioni di lettura il chunkserver verifica l’integrità 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 provvederà 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 è
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 è
possibile ricostruire l’intera cronologia delle transazioni e risalire al
problema.
48

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 ﬁle
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 è di 67MBps considerando che vi è una maggiore
congestione della rete rispetto alle read in quanto per ogni scrittura i dati
devono essere replicati su 3 chunkserver differenti.
Le velocità 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 velocità 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 diﬀerenti.
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 più dead file e chunk poichè i suoi file
tendono ad essere più 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 conﬁgurazione 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 attivit`a per la produzione di circa 100 MBps.
55

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
entrò a far parte del progetto Apache Lucene e successivamente(2006)
anche Yahoo! si interessò al progetto dando la nascita ad Hadoop.
56

GFS / HDFS - Motivazioni
• Il GFS è nato per l’elaborazione dei BigData di Google, licenza
proprietaria;
• HDFS è nato per l’esecuzione di applicazioni MapReduce ed è usato
da differenti client che hanno scopi differenti (Yahoo!, Facebook,
IBM, Twitter e cos`ı via. . .), è 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 è ispirato dal GFS e dal MapReduce ma mira a fornire gli stessi
servizi tramite un progetto Open Source.
58

Conclusioni
Il GFS possiede le qualità 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 è una modalità di recovery veloce e automatica,
checksum
• Alto throughput anche con readers e writers concorrenti.
59

The Google File System

More Related Content

What's hot (15)

Viewers also liked (17)

Similar to The Google File System (20)

The Google File System