google file system - gfs

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

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


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


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

google file system - gfs

Education