Sperimentazione del file system distribuito HDFS in ambiente GRID

BORSA DI STUDIO GARR “ORIO CARLINI”
Sperimentazione del file
system distribuito HDFS in
ambiente GRID
Rapporto attività terzo trimestre 2012
Borsista: dott. Giovanni Marzulli
Tutor: dott. Domenico Diacono
Istituto Nazionale di Fisica Nucleare – sezione di Bari
INTRODUZIONE
Il secondo trimestre di attività è stato impiegato prevalentemente per la realizzazione delle due
custom policy: One Replica e Hierarchical placement policy; l’ultimo trimestre invece, è stato
dedicato alla verifica delle policy implementate e alla realizzazione di un cluster geografico
indispensabile per l’esecuzione dei test. A contorno, una serie di attivit{ secondarie finalizzate allo
svolgimento delle prime.
CLUSTER BARI-NAPOLI
È stato realizzato il primo cluster HDFS su scala geografica tra i siti INFN di Bari e Napoli. Il cluster,
configurato con lo scopo di testarne inizialmente le funzionalità e successivamente le prestazioni, è
composto da 3 nodi a Bari (tra cui namenode e secondary namenode) e tre nodi a Napoli su cui è
stata installata la release Cloudera Hadoop 4.
Utilizzando questo cluster, sono stati ripetuti i test di funzionalità già eseguiti sul cluster in rete
LAN a Bari. Dopo un’opportuna configurazione delle porte di connessione Hadoop sul sito di Napoli,
è stato verificato che non sussistono né problemi di comunicazione tra datanode e namenode e
viceversa, né anomalie nello scambio di dati sia in fase di scrittura che in fase di lettura.
TEST DELLE POLICY
Successivamente è stata verificata la funzionalità delle nuove policy; questa fase ha evidenziato
alcuni bachi presenti nelle implementazioni e quindi, in parallelo, ci si è dedicati anche all’attivit{ di
correzione degli errori.
Per tale test è stato necessario eseguire numerosi cicli di scritture di dati e analizzare la
disposizione fisica delle repliche sui rack in base a quanto definito nelle nuove policy; data la
grande quantità di dati scritti non è stato possibile effettuare manualmente tale analisi, ma si è
provveduto alla realizzazione di script che rendono automatico il processo producendo risultati
aggregati e rilevando le anomalie:
1

per il test della One Replica policy, sono stati configurati due rack: Bari e Napoli. Con un
fattore di replica pari a due, ogni file è ridondato in entrambi i siti.
Non sono stati rilevati particolari problemi.

per il test della Hierarchical policy, è stato necessario configurare una topologia di rete
basata su 2 livelli. Bari e Napoli corrispondono al livello più alto (livello farm). Ogni farm
contiene al suo interno più rack. In questo test sono stati creati 2 rack per ogni farm.
Per ogni file, secondo la policy, viene scritta una prima copia nel rack locale alla sorgente
dati, una seconda, in un rack diverso della farm locale, e infine una terza copia in un rack
della farm remota.
Dopo una serie di correzioni e test, è stato raggiunto un ottimo livello di stabilità.
TEST DI PERFORMANCE
È stata eseguita la prima fase dei test di performance sul cluster HDFS locale. In particolare, è stato
misurato il tempo impiegato per la scrittura e lettura dei dati confrontando i risultati in diverse
configurazioni variando il fattore di replica, la dimensione del blocco, lo stato del nodo sorgente (se
datanode attivo o inattivo ) e il tipo di client come specificato di seguito:
 fattore di replica: 1, 2
 dimensione blocco: 64MB, 128MB, 256MB
 datanode: attivo, non attivo
 client: Fuse-Dfs, Java (predefinito Hadoop)
Il test è avvenuto eseguendo, per ogni singola combinazione dei parametri, 100 processi di scrittura
sequenziali e da un unico nodo, di file di dimensione pari a 4GB. È stato eseguito prima da un
datanode attivo, con la conseguente possibilità che la prima replica avvenga sul nodo locale
(riducendo i tempi di scrittura), e successivamente da un datanode inattivo, su cui è presente solo il
client per accedere al file system, e quindi ogni replica è inviata ai datanode attivi.
Il test è stato eseguito sull’infrastruttura di calcolo del sito INFN di Bari dove sono in esecuzione
altri servizi e processi di calcolo scientifico, pertanto la misurazione è avvenuta in un ambiente
reale (e non ideale dove le risorse sono dedicate al file system Hadoop) in cui il carico di lavoro
dell’intera farm varia durante il giorno in modo random e non predicibile e influenza le prestazioni
dei processi HDFS.
Di seguito sono riportate le medie dei campioni dei dati rilevati per ogni configurazione:

Test di scrittura lanciato su un datanode attivo con client Java:
Fattore di replica
1
2
1
2
Dimen. blocco (MB)
64
128
Tempo medio (ss)
Velocità media (MB/s)
56.27
86.71
86.78
54.00
49.81
96.32
104.47
50.83
2
1
2

1
2
1
2
1
2
91.48
87.85
61.59
Dimen. blocco (MB)
64
128
256
Tempo medio (ss)
Velocità media (MB/s)
63.21
71.30
87.38
51.77
54.61
82.49
81.47
59.00
65.22
76.01
95.56
50.52
Test di scrittura lanciato su un datanode attivo con client Fuse-Dfs:
Fattore di replica
1
2
1
2
1
2

54.84
Test di scrittura lanciato su un datanode inattivo con client Java:
Fattore di replica

256
Dimen. blocco (MB)
64
128
256
Tempo medio (ss)
Velocità media (MB/s)
50.22
83.75
72.72
59.96
53.70
79.41
71.51
59.85
58.48
76.48
92.19
49.77
Test di scrittura lanciato su un datanode inattivo con client Fuse-Dfs:
Fattore di replica
1
2
1
2
Dimen. blocco (MB)
64
128
Tempo medio (ss)
Velocità media (MB/s)
91.60
45.66
106.83
40.24
90.58
46.13
99.09
42.45
3
1
2

256
89.20
47.95
100.44
42.71
Test di lettura lanciato su un datanode inattivo, con client Fuse-Dfs:
Fattore di replica
1
2
1
2
1
2
Dimen. blocco (MB)
64
128
256
Tempo medio (ss)
Velocità media (MB/s)
73.31
61.57
76.44
62.29
63.36
67.59
69.45
60.87
64.16
66.24
74.12
61.84
RISULTATI SCRITTURA
I risultati ottenuti mostrano palesemente una grande fluttuazione (dovuta alla continua variablità
del carico computazionale della farm) dei valori medi di tempo e velocità e talvolta sono
contrastanti tra loro, pertanto non consentono di dedurre quale sia la configurazione di dimensione
di blocco più performante.
Riguardo la distinzione datanode attivo-inattivo, risulta statisticamente più efficiente eseguire
l’operazione di scrittura da un datanode attivo; ciò è giustificato dal fatto che, seppur in un basso di
numero di casi, per evitare la saturazione dello spazio disco, una delle repliche è memorizzata sullo
storage locale con conseguente risparmio di tempo per la trasmissione dei dati sulla rete.
È possibile invece dedurre che il costo computazionale per la realizzazione della ridondanza dei
dati, con la seconda replica, è inferiore al doppio della prima, per cui il compromesso tra costo e
affidabilità dei dati risulta ad un livello più che accettabile.
Eccetto l’ultimo set di risultati, che si considera un outlier dovuto probabilmente ad un eccessivo
carico dell’infrastruttura di calcolo, i restanti sono in linea con quanto atteso.
RISULTATI LETTURA
I test in lettura non sono stati differenziati né per datanode attivo o inattivo, poiché tale distinzione
non avrebbe senso dato che i dati sono distribuiti su più nodi in entrambi i casi, né per tipo di client,
poichè l’uso futuro ed eventuale di questo sistema di storage in produzione prevederà
prevalentemente l’utilizzo del client Fuse-dfs per l’operazione di lettura.
4
Per gli stessi motivi descritti nel paragrafo precedente, anche in questo caso, non è possibile
definire la dimensione di blocco ottimale; tuttavia il livello di performance ottenuto è considerato
accettabile. Durante l’esecuzione del test si è verificata una situazione reale di fallimento di alcune
macchine della farm locale su cui era attivo il processo datanode; esse erano coinvolte nel processo
di scrittura dei dati. È stato osservato che, seppur in un tempo maggiore, l’esecuzione del test è
terminata correttamente poichè dopo la rilevazione del problema il namenode ha reindirizzato la
scrittura in corso sugli altri nodi attivi. Data l’anomalia, il relativo dato non è stato considerato ai
fini del calcolo delle performance.
Nei prossimi mesi si continuerà con la realizzazione di ulteriori test di performance e scalabilità,
eseguendo più scritture e/o letture contemporanee (in modo da aumentare il carico di lavoro) con
il coinvolgimento del sito di Napoli per una valutazione su rete WAN.
MONITORING: GANGLIA
Durante l’attivit{ di test è stato necessario utilizzare un tool di monitoring quale Ganglia. Ganglia è
un sistema di monitoring distribuito adatto per ambienti grid.
Il software Hadoop, di default, integra il supporto a Ganglia fornendo una serie di metriche
classificate in dfs (distributed file system), jvm (java virtual machine), mapred (mapreduce, che
esula dagli obiettivi di questo progetto), rpc (remote procedure call) che si vanno ad aggiungere a
quelle predefinite di Ganglia che riguardano il carico di lavoro, traffico sulla rete, ecc.
Ganglia si compone di due demoni, GMOND e GMETAD. Il primo è installato su tutte le macchine che
si intende controllare e si occupa della raccolta dei dati delle metriche che saranno poi inviati a
GMETAD. Esso consiste in un web frontend centralizzato, che raccoglie tutte le informazioni dai
singoli nodi del cluster e le presenta mediante dei plot aggiornati in tempo reale.
5
STORICIZZAZIONE DELL E INFORMAZIONI
Durante l’utilizzo del file system Hadoop fino a questo momento, si è sentita l’esigenza di disporre
delle informazioni riguardanti la disposizione fisica di ogni singola replica in modo strutturato, che
permetta ricerche puntuali sull’id del file, sui blocchi, sui nodi o ricerche per data, e che consenta di
avere uno storico limitato di tali dati, in modo da poter individuare ad esempio, dopo una rireplicazione, da quali nodi è transitato un blocco o nel caso di fallimento di un nodo, sapere quali
dati esso conteneva. È stato quindi realizzato un semplice parser che attraverso l’esecuzione di un
apposito comando Hadoop legge e memorizza tali informazioni in un database MySQL.
INSTALLAZIONE AUTOMATICA INTELLIGENTE
Durante il secondo trimestre era stato creato un sistema di packaging con repository e script per
l’esecuzione automatica dell’installazione e la configurazione del software Hadoop in modo da
automatizzare il processo in un cluster di oltre 200 nodi. In questo trimestre, si è resa tale
procedura “intelligente”: la configurazione non è più standard per tutte le macchine ma si adatta ad
ogni singolo nodo con l’obiettivo di assegnare al file system tutto lo storage disponibile. Lo script
analizza tutti i dischi e le partizioni presenti nel nodo e, ad esclusione di quelle riservate per il
sistema operativo, assegna le partizioni ad Hadoop modificando il file di configurazione XML,
aggiungendo i relativi path e riavviando il processo. Nel caso qualche partizione non dovesse essere
già montata, lo script provvede autonomamente al mount del disco/partizione.
6
GESTIONE DELLA SICUREZZA: KERBEROS
È stato approfondito l’aspetto sulla sicurezza di un cluster HDFS, e data la possibilit{ di integrare il
software Hadoop con il protocollo Kerberos, si è configurato il sistema con l’autenticazione tramite
il servizio Kerberos già presente nella sezione INFN di Bari. In questo modo l’identit{ di ogni nodo
(sia namenode che datanode) che vorrà unirsi al file system sarà verificata dall’Authentication
Server mediante il principal ad esso assegnato. Inoltre, l’accesso al file system da parte degli utenti
verrà limitato a chi è in possesso del ticket rilasciato dal Ticket Granting Server dopo aver effettuato
l’autenticazione mediante credenziali valide.
La configurazione della parte Kerberos di Hadoop è stata abbastanza laboriosa poichè prevede
l’installazione e la configurazione del client Kerberos su ogni nodo del cluster, la creazione dei
principal e l’esportazione della relativa keytab, la modifica della configurazione Hadoop (file hdfssite.xml e core-site.xml) differente per ogni tipo di nodo, la configurazione dei permessi sulle
directory di configurazione per limitare l’accesso ai soli utenti root e hdfs e la risoluzione di alcune
dipendenze da altre librerie come JSVC.
Dopo aver completato tutta la procedura, l’integrazione è avvenuta con successo, pertanto ogni
utente prima di accedere ai dati dovrà autenticarsi e ricevere il ticket eseguendo:
kinit -k -t hdfs.keytab hdfs/[email protected]
Utilizzando il servizio kerberos già in produzione, basterà indicare le credenziali di accesso che ogni
utente già possiede per gli altri servizi di sezione.
CONCLUSIONE
Dopo un’attenta e adeguata sperimentazione di HDFS è stato ritenuto opportuno cominciare a
testare sul campo il servizio di storage fornendolo ai veri utenti finali. Il custer Hadoop in
produzione sul sito di Bari è stato reso accessibile ad alcuni utenti locali che hanno iniziato ad
utilizzarlo per archiviare diversi gigabyte di dati senza incontrare nessun problema; ciò
rappresenta un ulteriore segnale positivo verso il raggiungimento dell’obiettivo finale, e cioè l’uso
di HDFS in una farm in produzione a pieno regime.
7