Google File System – Come funziona e la sua Architettura

Google Data Centers - File System Distributed

Ultimamente mi sono interessato ai File System Distribuiti, usati da una miriade di Sistemi di Calcoto Distribuiti ( HPC, Cluster, Sistemi GRID ), grazie alla peculiarita’ di poter immagazzinare enormi quantita’ di dati che altrimenti non potrebbero essere immagazzinate su un singolo disco rigido.

Immaginate un Sistema come quello di Google, con migliaia di cluster e centinaia di Terabyte di dati da gestire. Un Sistema in grado di visualizzare in pochi secondi e da qualsiasi parte del mondo tutte le vostre mail, tutti i vostri documenti, tutte le vostre immagini. Un Sistema che non ammette Failure o perdita di dati alcuna ( Spero almeno che i Crawlers di Google dopo questa premessa aumentino il SiteRank del blog 😛 ).

Google File System ( GFS o GoogleFS ) è il lavoro di anni di ricerca ed implementazione da parte del settore ricerca e sviluppo di Google, l’idea alla base dell’architettura deriva direttamente dai due fondatori di Google: Larry Page e Sergey Brin quando ancora studiavano a Stanford e pensavano ad un File System che soddisfacesse tale definizione:

“store data reliably even in the presence of unreliable machines”

che tradotto significa: “Immagazzinare dati in maniera affidabile anche in presenza di macchine inaffidabili”. Infatti la maggior parte dei computer utilizzati da Google sono formati da componenti economiche che molto spesso crashano o si rompono, per tale motovo il File System da usare doveva avere un alto grado di tollerenza ai guasti.

Prima di procedere alla spiegazione dell’architettura di un Sistema di Storage di Google dobbiamo elencare alcune assunzioni fatte dai progettisti:

  • Il Sistema è stato pensato per essere lanciato su componenti hardware economiche ( simili ai nostri comuni pc ). Deve continuamente monitorare se stesso alla ricerca di possibile failure, sia hardware che software
  • Il Sistema immagazzina un enorme quantità di dati. I file avranno dimensioni tipiche di 100 MB o ancora maggiori, per tale motivo il sistema è ottimizzato per la gestione di file molto grandi. I piccoli file possono essere anche supportati, ma non vi è nessuna ottimizzazione
  • I workloads ( carico di lavoro ) può essere suddiviso in due tipi: la lettura di una grande quantità di informazioni e la lettura random di piccole quantità di dati.
  • Il Sistema deve prevedere una semantica ben definita ed ottimizzata della lettura concorrente di un file da multipli Clients. Il sistema in questo caso deve risolvere il classico  problema del Produttore-Consumatore, gestendo le code di accesso e garantendo l’atomicità in maniera ottimizzata, garantendo il minimo overhead di sincronizzazione.
  • Si preferisce avere un alta quantita’ di banda piuttosto di un bassa latenza, ciò vuol dire che si dà la precedenza allo streaming continuato piuttosto che alle letture singole random.

Ad oggi, il sistema gira su sistemi cluster con più di 1000 nodi di storage, con un totale di oltre 300 TB di spazio disco, che sono pesantemente acceduti da migliaia di Client da tutto il mondo… e la cosa funziona davvero bene 😀 per tale motivo vediamo l’architettura di tale sistema un pò più nel dettaglio…

Architettura:

Architettura Google File System
L’immagine mostra una tipica interazione tra il Client, il quale dapprima chiede informazioni riguardo il file al GFS Master ed in seguito inizia l’iterazione con il ChunkServer responsabile della memorizzazione vera e propria dei dati.

L’architettura di un sistema di archiviazione Google è divisa in tre componenti principali: Un singolo Master Server, multipli ChunkServer a cui accedono multipli Client.

Master Server:

viene utilizzato solo per matenere i metadati sui file, tra cui i loro nomi , la loro locazione sparsa tra i vari ChunkServer, e quali processi stanno leggendo e/o scrivendo particolari chunk. Inoltre, prendono uno snapshot del chunk adatto alla replicazione, quando si rileva che il numero di copie di un chunk è minore del minimo prestabilito. Quando un’appliczione richiede un accesso ad un file è il Master Server che gli risponde indicandogli la posizione da dove prelevare tale file. Il Master è anche responsabile della gestione del “HeartBeat” tra i vari ChunkServer, in modo da avere periodiche informazioni sul loro stato e la loro eventuale migrazione.

ChunkServer:

hanno il compito di immagazzinare i veri e propri dati, i file sono divisi in chunks (analoghi dei blocks nei File System convenzionali) da 64MB ( dato che la maggior parte dei dati archiviati supera i 100 MB di dimensioni, tanto per darvi un’idea in un sistema Home Linux il block size è di soli 4KB ) e vengono replicati su minimo di tre ChunkServer. I file vengono acceduti grazie ad un chunk handle ed un range di byte, in quanto Google prevede la serializzazione del file e preferisce usare un append piuttosto che gestire il lock dei vari file.

Client:

Non sono altro che le API messe a disposizione da Google per accedere ai sui sistemi di archiviazione ( Ex. Applicazioni Web, Mail, Google Documents ecc.. ) e comunicano dapprima con il Master Server per avere informazioni su dove prelevare i dati, e solo dopo può accedere ai ChunkServer per l’operazione di lettura/scrittura del file. Per tale motivo non si viene a creare un collo bi bottiglia tra il Client ed il Master Server dato che da quest’ultimo vengono prelevati solo i metadati, mentre il flusso vero e proprio di dati avviene solo tra Client e ChunkServer.

Il perchè di alcune scelte

Chunk Size:
E’ una delle principali chiavi del progetto. Google ha scelto chunk da 64 MB, una quantita’ molto al di sopra dei normali block size sui sistemi comuni ( 4 KB ). Tale scelta va a discapito della frammentazioni interna, ma molto probabilmente è l’unica pecca di tale scelta dato che un size molto grande offre innumerevoli vantaggi

  1. Riduce lo scambio di dati tra Client-Master Server
  2. Il Client può implementare diversi meccanismi di ottimizzazione per la lettura dell’intero chunk, riducendo l’overhead di rete utilizzando una connessione persistente come il TCP
  3. Riduce il numero e la grandezza dei metadati contenuti nel Master Server

Chunk Location:
Il Master Server non tiene una copia persistente di quale ChunkServer ha una copia di un dato chunk, ma fa semplicemente una richiesta ad ogni startup del ChunkServer alla ricerca di tali informazioni. In tal modo si evita che il Master abbia una continua visione globale sui suoi ChunkServer ( evita overhead non necessario ), dato il fatto che leggendo solo le informazioni al momento dello startup del ChunkServer si eliminano continui flussi di dati tra i due sistemi, migliorando la letenza dell’intero sistema.

Operazioni di Log:
Come la maggior parte dei File System utilizzati, anche GFS utilizza un sistema si log in modo tale da prevenire eventuali failure sia sul Master Server che sui ChunkServer. Periodicamente è fatta una copia della tabella dei metadati presenti su ogni Master Server, grazie a tale operazione abbiamo due vantaggi principali:

  1. Si crea una Time Line che definisce l’ordine delle operazioni concorrenti avvenute sui vari chunk.
  2. 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 concorrente al file ( esattamente cio’ che avviene su ext3 o NTFS )

In queste poche righe ho cercato di spiegarvi in che modo Google immagazzina l’enorme quantità di dati che giornalmente raccoglie/distribuisce. Ovviamente è solo un piccolo riassunto, ma spero sia bastato a stimolare la vostra curiosità...
Vi inserisco il link all’articolo originale scritto da: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung

Download Articolo Originale: GFS pdf version

Una risposta a “Google File System – Come funziona e la sua Architettura”

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.