Distribuited Map/Reduce Grid for YASARA

Transcript

R Y
DM
GA
Distribuited Map/Reduce Grid for YASARA
Alessandro Bove, Alfonso Martorelli, Luigi Di Biasi
{a.bove10, a.martorelli5, l.dibiasi}@studenti.unisa.it
July 22, 2011
Abstract
Questo
1
documento
sviluppata
per
descrive
permettere
l'architettura
la
Nell'ambito della simulazione delle dinamiche moleco-
R Y
DM
GA ,
distribuzione
lari sono richiesti tempi di elaborazione nell'ordine delle
e
ore, dei giorni o delle settimane.
l'elaborazione parallela di macro YASARA utilizzando i
dal valore assunto dall' insieme di variabili che caratterizzano il
tipo di analisi che il chimico vuole eettuare : come es-
Si è scelto di non utilizzare Hadoop come layer per la
introdotto
Il RT di ogni singola
elaborazione è fortemente inuenzato
concetti di Map/Reduce [5] e di explode-point.
costruzione della grid in modo da eliminare
Introduzione
empi di queste variabili è possibile citare la dimensione
l'overhead
della molecola, il tipo, la conformazione, la posizione, la
dall'utilizzo delle Virtual Machine -VM-
temperatura del uido dove è immersa e così via.
(necessarie per l'installazione su larga scala di slave
hadoop), dalla gestione del lesystem HDFS [9], dal pool-
Inoltre, molti tipi di esperimenti sono computazional-
ing degli slave, dalla presenza della Java Virtual Machine
mente simili e richiedono di analizzare, per una stessa
-JVM- [12] e dalla schedulazione dei lavori [6][7].
molecola,
Tale
la
dinamica
in
condizioni
in
cui
un
solo
scelta si basa su due constatazioni: la dimensione ridotta
parametro è variato e gli altri sono rimasti identici:
delle informazioni che è necessario scambiare tra i nodi
possibile considerare come esempio di questo tipo di anal-
non richiede la presenza di un lesystem distribuito per-
isi il calcolo della dinamica di una molecola immersa in
formante; inoltre, se vengono eliminate le VM la CPU
acqua in un range di temperature che va da 100°K a
è
verrà utilizzata per un tempo maggiore (e senza emu-
200°K; si hanno 100 problemi simili in cui varia solo un
lazione) dal codice binario di YASARA.
parametro e se ogni singolo sottoproblema richiede 2 ore
alla ne l'intero calcolo, nell'ipotesi che venga svolto in
Premesso
che
molte
delle
elaborazioni
eseguite
con
modo sequenziale, richiede circa 8 giorni.
YASARA hanno un Running Time -RT- nell'ordine delle
Come diretta conseguenza si ha che l'elaborazione se-
ore (si arriva anche a giorni o settimane) si è deciso di
quenziale non è accettabile per questo tipo di analisi
implementare uno scheduler (denominato MF/MA) non
e pertanto si è obbligati ad utilizzare schemi di elabo-
equo orientato all'assegnazione dei job allo slave più ve-
razione distribuita.
loce.
Esistono molti framework tra cui Hadoop[6] (basato, anCome protocollo per il trasferimento di le tra i nodi è
che esso, sul modello Map/Reduce) i quali consentono di
stato scelto CIFS/SMB di Microsoft che, dalle anal-
eettuare calcolo distribuito.
isi svolte, si è rivelato suciente allo scopo. Per le co-
strumenti che permettono la traduzione del problema
municazioni di servizio e per il pooling degli slave viene
dal
punto di vista chimico
formatico:
utilizzato il protocollo TCP.
Inne, per rendere l'architettura fruibile agli utilizzatori

di YASARA e non legata ad uno specico problema ma
Tuttavia, non forniscono
al
punto di vista in-
Un chimico si occupa di descrivere i tipi di analisi
che vuole eettuare, come queste analisi devono es-
general purpose, è stato implementato un pre-processore
sere eettuate e come salvarne i risultati per poterli
(danominato yadm) che permette di separare il lavoro
elaborare successivamente. Teoricamente non ha la
del chimico dal lavoro dell'informatico ; l'idea che sta alla
conoscenza necessaria per riuscire a distribuire su
base di yadm è l'explode-point che permette di specicare
griglia le sue elaborazioni.
quali parti della macro variano, nascondendo totalmente

all'utilizzatore la presenza della griglia che si occuperà
dell'elaborazione.
Al contrario,
un informatico,
teoricamente,
non
conosce nulla di chimica e si limita a fornire la griglia
1
2.1.2
su cui distribuire l'elaborazione.
Calcolo della Glass transition temperature
[11]
Pertanto, è necessario uno strato intermedio (una sorta di
compilatore) che traduca il linguaggio chimico in linguag-
Il problema arontato è quello del calcolo della temper-
gio informatico:
atura alla quale avviene una transizione di fase.
in questo documento viene proposta
l'architettura a EP (paragrafo 3.6) che permette di map-
Questo
pare in formato Map/Reduce macro eseguibili tramite
costruzione di una membrana calcolandone la dinamica a
YASARA; successivamente viene descritta l'architettura
diverse temperature e monitorandone diversi parametri
sviluppata per permettere la costruzione della griglia per
come lo spessore o l'orientamento delle code.
l'esecuzione parallela delle sotto-macro generate.
Inne,
vengono
dell'architettura
presentate
è
utile
per
validare
la
Successivamente, il parametro scelto (nel nostro caso lo
performance
particolare
spessore della membrana) viene riportato su un grafo
e, sulla curva denita dai punti, vengono calcolate le
derivate prima e seconda per poter individuare la tem-
CIFS/SMB)
peratura di transizione.
beneci
con
elaborazione
tenzione ai limiti a cui è soggetta (legati al protocollo
ai
4)
di
at-
e
(paragrafo
le
tipo
apportati
in
termini
di
riduzione del RT globale.
L'elaborazione viene eettuata su due membrane: una
già nota (in modo da poter confrontare se i risultati ot-
2
tenuti dall'elaborazione corrispondono a quelli sperimen-
Casi di studio
tali) ed una non nota (tentando di prevedere il comportamento della membrana alle diverse temperature).
Di seguito vengono riportate le descrizioni dei problemi
Ogni
R Y
DM
GA .
che sono stati mappati per essere eseguiti su
singola
brana,temperatura )
elaborazione
(coppia
richiede
4,5
circa
ore
memper
la
membrana BSM-CHOL e circa 30 ore per la membrana
2.1
POPC (sul singolo nodo della
Macro YASARA distribuite
Grid2
(più
performanti)
Grid1).
richiede
Sui nodi della
circa
3,2
ore
per
fase di Map
cor-
BSM-CHOL e circa 28 ore per POPC.
Per YASARA sono stati utilizzati tre tipi di macro,
con RT di ordine crescente, per poter analizzare come
Per questo tipo di elaborazione la
l'architettura distribuita apporti miglioramenti sensi-
risponde all'esplosione della macro su due variabili:
bili rispetto ad una elaborazione sequenziale.
I sot-
1. Temperature che varia da 280 a 310 a step di 2.
toparagra successivi riportano una breve descrizione,
dal punto di vista chimico, dei problemi arontati.
2. Membrana che assume valori relativi ai nomi delle
membrane da analizzare (nel nostro caso POPC e
2.1.1 Macro di test per tuning griglia
BSM-CHOL).
La
Questo test è stato eseguito con lo scopo di analizzare
la scalabilità dell'architettura in funzione del numero di
valori assunti dal parametro analizzato (lo spessore della
(inteso anche come potenza di calcolo a disposizione).
membrana).
La macro utilizzata per questo tipo di test (blocco 3)
L'esplosione della macro genera 30 job da elaborare nella
carica in memoria una molecola e ne avvia la simulazione
grid.
della dinamica ad una determinata temperatura.
una
singola
elaborazione
il
tempo
necessario
corrisponde nel raccogliere il risul-
ogni coppia (temperatura,membrana) vengono associati i
lavori da eseguire e del numero di slave a disposizione
Per
fase di Reduce
tato delle elaborazioni e fornire in output un le in cui ad
è
2.2
costante (circa 25 secondi sul singolo nodo della Grid1 ) e
come output viene generato un le contenente una coppia
Wordcount distribuito
Anche se l'architettura è stata progettata ad-hoc per es-
T Ki =(temperaturai ,energia sistemai ).
eguire elaborazioni CPU-bounded, sono stati eettuati
La macro è stata modicata in modo da esplodere (vedi
diversi test per determinarne il comportamento in situ-
EP paragrafo 3.6) per il parametro temperatura pertanto
azioni IO-bounded. In questo modo si è cercato di deter-
limite superiore
variando il range di temperature si ha un incremento del
minare il
numero di job.
dell'architettura viene compromessa dall'assenza di un
La
fase di Map
per
questo
test
all'esecuzione di un semplice job mentre la
duce
lesystem ottimizzato per la gestione di grandi quantità
corrisponde
di dati (es: HDFS).
fase di Re-
corrisponde nell'unicare tutte le coppie
T Ki
oltre il quale la scalabilità
e
La scelta è caduta sul problema del wordcount per diversi
fornirle in un unico le di output.
motivi:
2
Pertanto,
tramite
la
i miglioramenti che puntiamo ad ottenere
parallelizzazione
all'eliminazione
sono
dell'overhead
strettamente
introdotto
legati
dall'accesso
random al disco. Essenzialmente, il vincolo da rispettare
per migliorare le performance è riassunto di seguito:
Il
tempo
di
generazione,
trasferimento
deve
essere minore del tempo richiesto per elab-
verso lo slave e conteggio su un chunk
orare lo stesso chunk, letto in modalità random
durante un elaborazione multithreading, in locale.
Inoltre, puntiamo a determinare una taglia dei chunk che
migliori anche la gestione della HashMap.
Figure 1: Dierenze tra WC locale e distribuito.
La
gura
1
mostra
come
viene
eseguita
la
fase
di
Map/Reduce nell'archiettura implementata.
1. E' localmente IO-bounded; legge un le e mantiene
H con Key = {word}
V alue(w) = {#occorrenze di w}
una HashMap
2. E'
intrinsecamente
risolvibile
con
la
e
H(w) =
3
tecnica
di
Map/Reduce.
L'architettura
(a) Dato il le
chunk
Ci
F
intero e possibile dividerlo in
1. MASTER deve essere collegato ad un modulo di
Ci
MAP che fornisce la logica di mapping. Negli sce-
(c) La fase di reduce è semplice ed ancora IO-
nari analizzati in questo documento verranno usati
Bounded; è necessario recuperare dagli slave
Hi
due moduli di MAP; uno per il wordcount ed uno
unendone i risul-
per la generazione delle macro distribuite (in realtà
tati in una tabella nale in cui ogni riga ha
H(w) =
X
base
griglia (Figura 2). In particolar modo:
processo di conteggio; questo processo genererà
l'insieme delle HashMap
di
logica applicativa che determina il comportamento della
sui nodi della griglia ed eseguire localmente il
associata al chunk
componenti
esterni (nel caso di Windows sono DLL) che forniscono la
(b) Successivamente è possibile distribuire i chunk
Hi
quattro
REDUCER. I componenti base sono collegabili a moduli
e assegnare ad ogni chunk un iden-
una HashMap
prevede
(Core) denominati MASTER, SLAVE, DISPATCHER e
ticatore univoco (i).
valore
Architettura
un modulo che implementa il pre-processore yadm).
Hi (w).
2. SLAVE deve essere collegato ad un modulo di EXEC
i=1...n
che fornisce la logica per eseguire i vari job rice-
Dato che il wordcount eettua l'accesso sequenziale ad
vuti.
un le e la costruzione della HashMap (che al crescere
Nei casi analizzati il modulo EXEC lancerà
YASARA oppure un eseguibile (wc.exe) che si limita
della dimensione diventa più lenta), per migliorarne le
a contare le occorrenze delle parole e a salvarle in un
performance partiamo dall'idea di dividere il le in chunk
le.
e conteggiarli (tramite lettura sequenziale) in parallelo su
diversi nodi. Questo tipo di elaborazione in locale non
3. REDUCER deve essere collegato ad un modulo di
è eciente poiché:
REDUCE che fornisce la logica di riduzione dei
problemi mappati tramite il mapper.
1. L'accesso al le in modalità random non è eciente
Nel caso di
YASARA verranno utilizzati due moduli distinti per
(richiede molte seek ed è più o meno lenta a sec-
arontare i due problemi (dei range di temperatura
onda di come è implementato il lesystem) rispetto
e delle interazioni membrana/ligando).
all'accesso sequenziale.
2. Due thread possono abbassare notevolmente le per-
I componenti del Core (quando non linkati alle DLL)
formance nel caso in cui stiano elaborando dati sal-
implementano solo le funzionalità di base per la coop-
vati su settori del disco molto distanti (nel caso peg-
erazione e sono totalmente astratti dal lavoro che verrà
giore vanno in mutua esclusione).
distribuito sulla griglia. I tipi di comunicazione utilizzati
Le performance
degradano ulteriormente se i le sono frammentati
sono tre:
e quindi bisogna saltare da un settore all'altro.
TCP.
3
shared-memory, DFS (CIFS/SMB) e socket
Algorithm 1
Collegamento ai moduli MAP e DIS-
PATCH
Figure 2:
interface IYasaraD_MapHandler
WSET getNextWorkingSet();
Architettura utilizzata per la gestione della
grid.
3.1
interface IYasaraD_DispatchHandler
BOOL DispatchWSET(*WSET w);
MASTER
class WCountMAP implements
IYasaraD_MapHandler
WSET getNextWorkingSet()
return genera_il_prossimo_wset;
Il modulo MASTER fornisce l'interfaccia utente utilizzabile per la programmazione della griglia.
Inoltre, im-
plementa i protocolli necessari per eseguire le operazioni
di:

Connessione agli SLAVE e al modulo REDUCER.

Richiesta al MAPPER del prossimo job da dis-
class UNCWinDis implements
IYasaraD_DispatchHandler
BOOL DispatchWSET(*WSET w)
SendToSlave(w);
tribuire.

Controllo dello stato della griglia.

Monitoraggio dello stato dei job e degli slave.

Scheduling dei job (Algoritmo MF/MA, paragrafo
class MASTER
// Caricamento dinamico moduli
LoadDLL (wcountmap.dll,uncwindis.dll)
IYasarad_MapHandler myMap ← WCountMAP()
Yasarad_Dispatch myDisp ← UNCWinDis()
while not EndOfJob
// s è il nextSlave
myDisp.DispatchWSET(s,myMap.getNextWSet)
3.3).
In caso di errore (o timeout) provvede ad assegnare il lavoro al prossimo slave libero.
Quando un lavoro è stato completato informa
il modulo REDUCER (non fa partire la fase di
reduce ma segnala solo che un lavoro è stato
completato).
Come già detto, il modulo MASTER non conosce come
vengono generati i working-set poiché tutta la logica di
generazione è implementata nella DLL esterna (che fa le
veci di MAP) in modo da non legare l'architettura solo a
YASARA, rendendola disponibile anche per altri tipi di
elaborazioni.
di
Questa caratteristica (basata sui concetti
interfaccia e istanza
- algoritmo 1) è stata usata
nello scenario del wordcount analizzato nel paragrafo 4.2.
4
Figure 3: Interrogazione di uno SLAVE
Figure 4:
Assegnazione di job ad uno slave.
Per ogni
EXEC viene avviato un nuovo thread.
3.2
SLAVE
1. INIZIALIZZAZIONE, durante la quale vengono in-
Il modulo SLAVE implementa i protocolli necessari per
terrogati tutti gli slave in modo da avere a dis-
eseguire le operazioni di:
posizione sucienti informazioni riguardo alle loro
code di esecuzione (in particolar modo quanti job

Ricezione assegnazione dei job dal MASTER.

Esecuzione dell'algoritmo distribuito MF/MA.

Segnalazione di lavoro completato verso il MAS-
possono

in
contemporanea).
Durante
lo slave più performante poiché vengono interrogati
tramite TCP. Pertanto, solo durante l'esecuzione
l'algoritmo convergerà verso il comportamento ot-
TER.

eseguire
l'inizializzazione non è possibile conoscere quale è
timale.
Reset del proprio DFS nel caso di connection-break
2. ESECUZIONE, durante la quale per ogni job viene
con il MASTER o alla ricezione di un comando di
scelto lo slave che dovrà eseguirlo.
RESET_DFS.
modicata dinamicamente dai messaggi di ACK
La coda viene
(termine lavoro). Di conseguenza, quanto più sarà
Esecuzione del lavoro (Solo se collegato alla libreria
veloce uno Slave, tante più volte comparirà in coda
che ne denisce il comportamento).
e dunque riceverà una maggiore quantità di job da
eseguire (Convergenza dell'algoritmo).
Lo SLAVE è di tipo passivo pertanto, una volta avviato,
attende comandi da parte del MASTER (gure 3 e 4).
Lo pseudo codice di MF/MA è riportato nell'algoritmo
2.
L'idea che sta alla base di questa suddivisione è quella
di voler associare MASTER e SLAVE così come avviene
3.4
nelle architetture multiprocessore AMP[2]: gli slave sono
una risorsa del MASTER che si occupa di coordinarne il
funzionamento.
REDUCER
Il modulo REDUCER implementa i protocolli necessari
per eseguire le operazioni di:
3.3
Scheduler MF/MA
L'idea di Scheduler
MostFast/MostAssigned

risultato della fase di reduce (in genere una cartella
si basa
presente nel MASTER).
sull'assunzione che lo slave più veloce deve essere quello

più utilizzato per eseguire working-set, in modo da sfrut-
ricevuto una notica di job completato).
Dato che il calcolo è distribuito è necessario che lo sched-
event-driven
Accesso al DFS degli Slave per la lettura delle informazioni richieste dalla fase di reduce (dopo che ha
tarlo quanto più possibile.
uler sia di tipo
Ricezione dal MASTER della path dove salvare il

ed, in particolar modo,
Esecuzione della fase di reduce (Solo se collegato alla
libreria che ne denisce il comportamento).
è necessario che modichi il proprio comportamento in
base al procedere della computazione .
Il modulo REDUCE è passivo così come il modulo
L'algoritmo utilizza una semplice coda (struttura Queue )
SLAVE pertanto, come quest'ultimo, viene pilotato dal
e si divide in due fasi:
MASTER.
5
Algorithm 2 Pseudo codice dello scheduler MF-MA
class MASTER
{
Queue FreeSlave;
List Activejob;
// Le due sezioni di codice identificate da THREAD:
//sono eseguite in parallelo!
THREAD: DISPATCH
{
// FASE DI INIZIALIZZAZIONE
// Interroga tutti gli slave conosciuti.
foreach s in SlaveList
SEND_TCP_PACKET(s,REQUEST_QUEUE_STATUS)
// FASE DI ESECUZIONE
// Attende che qualche slave arrivi in coda
while exist another job
nextSlave ←FreeSlave.dequeue() // se vuota bloccante
myDisp.DispatchWSET(nextSlave,myMap.getNextWorkingSet())
SEND_TCP_PACKET(nextSlave,ASSIGN_JOB(jID))
}
THREAD: REC_TCP_MESSAGE
{
while true
REC_PCK = RECV_TCP_PACKET(s,t); //s = slave; t=text of packet
if REC_PCK.t=ASSIGN_JOB_INQUEUE
// Il job è stato avviato viene contrassegnato
// come associato allo slave che ha inviato il pacchetto
if REC_PCK.t=ASSIGN_JOB_ACK
// Il job è stato completato dunque lo slave è libero
FreeSlave.enqueue(s);
if REC_PCK.t=REQUEST_QUEUE_STATUS(k)
// lo slave ha disponibili k slot. Dunque lo inserisce k volte in coda!
for k times FreeSlave.enqueue(t)
}
6
Figure 7: Cooperazione tra i moduli per generare e assegnare un nuovo job
Figure 5: Fase di Assign, Exec e Reduce.
3.5
Struttura
Filesystem
(CIFS/SMB)
condiviso
yadm che permettono di esprimere i costrutti di array[]
e for in modo da poterli mappare automaticamente sulla
griglia.
Per permettere la distribuzione delle informazioni tra i
Il pre-processore yadm fonda il proprio funzionamento
vari nodi viene usata la funzione net share dei sistemi
sul concetto di
Microsoft.
un EP è una zona della macro che deve variare e che
Il Master suddivide il proprio spazio in tre partizioni
contribuisce a generare l'insieme di tutte le possibili com-
explode point -EP-.
Essenzialmente,
binazioni di macro da eseguire. La gura 8 mostra un
logiche:
le MCE (Macro With Explode Denition) e le successive
esplosioni intermedie no alla generazione del result-set
1. EWS -Entire Workset Space - in cui vanno salvati
nale, la cui dimensione è:
tutti i le necessari per il funzionamento dei job.
Nel caso delle macro YASARA in questo spazio va
Y
salvato il le MCE da esplodere ed i le di supporto
i=1...n
necessari per il funzionamento delle macro generate.
con
|EPi |
|EPi |
numero di valori che può essumere l'i-esimo
EP.
2. JS -job Space - in cui vengono salvati temporanea-
mente i job generati; il Master mantiene una copia
Le esplosioni
dei job nel caso in cui sia necessario riassegnarli dopo
non sono indipendenti pertanto vengono
applicate in modo sequenziale.
un errore o un timeout.
esplosione è univoco:
Inoltre, ogni punto di
non è possibile inserire lo stesso
3. RS -Reducer Space - in cui verrà salvato il risultato
punto di esplosione in due punti diversi della macro a
della fase di reduce; questo spazio è accessibile uni-
meno che quei due punti non debbano assumere lo stesso
camente dal REDUCER e dal MASTER.
valore
Ogni slave utilizza tutto lo spazio a disposizione per mantenere i workingset da elaborare. Il DISPATCHER si occupa di eettuare la copia dei le necessari per ogni job
dal proprio spazio JS allo spazio JS dello slave.
3.6
Preprocessore yadm (Fase di Map)
Come anticipato, è necessario uno strato intermedio che
permetta di far cooperare il lavoro di un chimico con il lavoro di un informatico : la scelta è caduta sullo sviluppo
di un semplice pre-processore in grado di esprimere in
forma di Map/Reduce le macro YASARA. Di seguito
viene descritta la sintassi delle tre funzioni principali di
7
k
per la stessa esplosione
i.
Figure 6: Struttura del Filesystem condiviso.
Figure 8: Esplosione di un le MCE in macro YASARA
8
3.6.1 Sintassi per la denizione del comporta- 3.6.2
mento degli EP
Utilizzo dei punti di esplosione
I punti di esplosione vanno immessi direttamente tra le
istruzioni YASARA racchiudendoli tra due simboli AT
La sintassi utilizzata per denire un EP è:
@EPi @.
##EXPLOSION(n )= EXP_TYPE[PARAM]@ENDEXP
→ n è l'ID dell'EP.
→ EXPLOSION_TYPE tipo di EP da applicare.
→ PARAM parametri configurazione EP.
→ @ENDEXP delimitatore di fine EP.
Consideriamo l'esempio nel blocco 3:
i punti di esplo-
sione sono indicati in blu e vengono applicati in base
alla sequenza con cui vengono denite; L'EP
SION(1)@
@EXPLO-
fa si che il valore del parametro Tempera-
280 a 290 in step di 5 pertanto avremo
3 macro intermedie; successivamente, l'EP @EXPLOSION(3)@ fa si che vengano caricati i PDB elencati nel
ture vari da
Per la parallelizzazione delle macro YASARA sono stati
le di testo passato come parametro (nell'esempio con-
implementati i seguenti tipi di EP:
tiene 3 nomi di le).
Il result-set nale sarà di
→ WRITE_RANGE [start,stop,step ] da usare
per variare valori interi di tipo numerico
che partono da start , arrivano a stop con
passi di step .
(Il classico for(i=start;i<=stop;i+=step))
9
macro e conterrà tutte le
possibili combinazioni di valori.
Come riportato nei paragra precedenti, nel caso in
esame yadm è stato re-implementato per essere eseguito
come modulo dinamico e
Map.
viene utilizzato nella fase di
Le macro generate vengono mantenute in memo-
ria.
→ WRITE_ARRAY [val1 , val2 , ..........valn ] da usare
per far variare l'EP con i valori indicati
tra parentesi.
4
→ WRITEF_ARRAY ['filename'] da usare come
WRITE_ARRAY, salvo prendere i valori dal
file filename strutturato come un insieme
di valori,uno per ogni riga.
Analisi delle performances
L'assenza di informazioni relative ad altre architetture
per la distribuzione di YASARA ha reso necessaria la
denizione di metodi non comparativi per poter determinare l'ecienza della griglia.
Per poter evidenziare i limiti dell'architettura sono state
eettuate analisi in situazioni IO-Bounded poiché la
presenza di CIFS/SMB (non sviluppato per essere distribuito) lascia ipotizzare un limite superiore alla scalabilità dell'architettura: in particolar modo ci si aspetta
che esista un
limite superiore
oltre il quale, in situ-
azioni IO-Bounded, l'aumento della potenza di calcolo
p
non apporta ulteriori beneci.
Tuttavia,
data la natura CPU-Bounded delle elabo-
razioni YASARA, questo limite non porta particolari
problemi poiché i le da trasferire, per poter avviare
un'elaborazione, hanno dimensione nell'ordine dei 10MB.
Pertanto, sono stati deniti i concetti di RT globale
RTgrid
e Step Time:
RTgrid
è il tempo necessario per completare tutte le
sottomacro distribuite su una griglia.
Step T ime
è il tempo necessario per completare
un'unica sotto-macro appartenente all'insieme delle
possibili macro.
Si ritiene che l'architettura sia eciente (in condizioni
CPU-Bounded) se al crescere della potenza di calcolo
p
(inteso come aumento del numero di nodi o della potenza
dei nodi) il RT globale tende allo Step Time, ovvero se:
9
Algorithm 3 Esempio di utilizzo degli EP
#############################
# Macro gestita con gli EP #
#############################
#
# La definizione del comportamento degli EP
##EXPLOSION(1) = WRITE_RANGE[280,290,5] @ENDEXP
##EXPLOSION(3) = WRITEF_ARRAY['pdbdacaricare.txt'] @ENDEXP
#
clear
# Qui viene utilizzato un EP
LoadPDB @EXPLOSION(3)@
HideMessage Style Sidechain=Stick
SimSpeed Normal
ForceField AMBER03,SetPar=Yes
Interactions Bond,Angle,Dihedral,Planarity,Coulomb,VdW
SimSteps 5
TimeStep 2,1.0000
# Qui ne viene utilizzato un altro
Temperature @EXPLOSION(1)@ ,Reassign=Yes
CleanAll
Sim On
Wait 100
Sim Off
energia = EnergyAll
Tabulate (energia)
SaveTab 1,prova.tab,Format=Text,Columns=1,NumFormat=6.2f,tabella
exit
10
SO
Win7
Xp
Linux
Dar
W08
Tuttavia, l'obiettivo di queste analisi è quello di deter-
MB
B1
P1(w)
P1(l)
M1
S1
W03
S2
S3
S4
minare quali possono essere i colli di bottiglia che pos-
102
61
36
7
3
10
16
8
11
sono portare ad un decadimento dell'architettura e di-
103
845
374
53
36
143
165
95
159
mostrare che distribuire l'elaborazione (quando neces-
104
1476
1027
477
349
2159
1803
676
1131
sario e possibile) permette di aumentarne la velocità;
ssata quindi la qualità dei dischi rigidi come uno dei
RT in secondi
principali parametri di ecienza considerimo le architetTable 1: RT del processo wordcount eseguito in locale su
ture con lesystem poco eciente.
diverse architetture.
lim
p→∞ RTgrid
4.2.1
= Step T ime.
Performance su Grid1
Fissati come riferimenti i valori riportati nelle colonne
4.1
B1,
Tipi di analisi
Per eseguire l'analisi delle performance sono state utilizzate due griglie identicate come Grid1 (omogenea, su
LAN), Grid2 (eterogenea su LAN). Inoltre, vengono riportati i test relativi all'esecuzione della macro
tuning
senza l'utilizzo di macchine virtuali: i valori Identicati
H
analizzare il comportamento del wordcount distribuito
sulle due griglie. Nelle tabelle 2, 3 e 4 vengono riportati
i risultati ottenuti per ogni le: ogni riga rappresenta la
dimensione del chunk trasmesso agli slave mentre ogni
colonna indica il numero di slave utilizzato; in grassetto
su una griglia composta da 14 nodi, basata su Hadoop
dal presso
P 1w , S1, S2 e S4 della tabella 1 (corrispondenti ai sis-
temi che eseguono wordcount più lentamente) è possibile
fanno riferimento ai risultati di questi test.
vengono evidenziati i
valori limite
oltre i quali non si
hanno più beneci anche aumentando il numero di nodi;
la tabella 4 riporta solo i valori più signicativi per il
Alcuni test sono stati eettuati esternamente alle griglie
le da 10GB poiché per le altre combinazioni di (di-
per evidenziare come sistemi operativi diversi possono
mensione_chunk,numero_nodi) non si hanno né miglio-
fornire prestazioni diverse.
ramenti né degradi interessanti (±1%).
L'hardware utilizzato è ri-
portato nel paragrafo 8.
Per la Grid1 il valore limite è stato sempre raggiunto in
corrispondenza del punto di
4.2
Wordcount distribuito
determinare i valori ottimali da assegnare alla dimensione del chunk e al numero di nodi per massimizzare la
I test eseguiti con il processo di wordcount vengono utilizzati per determinare i
saturazione della banda
disponibile della NIC. Utilizzando le tabelle è possibile
velocità di elaborazione.
punti critici associati al dete-
rioramento delle prestazioni (e alla mancata scalabilità)
Nei casi migliori è stato possibile ottimizzare la velocità
dell'architettura basata su CIFS/SMB.
di elaborazione del:
Sono stati eseguiti due tipi di analisi:

1. Calcolo dei RT con processo eseguito su ogni
gola tipologia di macchina
75% rispetto a B1, del 58% rispetto a
P 1w ,
del 21%
rispetto a S1 e del 6% rispetto a S2 (taglia 100MB).
sin-
utilizzando l'intera
dimensione del le.

81% rispetto a B1, 57% rispetto a
P 1w ,
del 46%
rispetto a S1 e del 4% rispetto a S2 (taglia 1GB).
2. Confronto dei RT con processo distribuito sulla
griglia omogenea, variando numero di nodi e taglia

rispetto a S2 e del 2% rispetto a S4 (taglia 10GB).
dei chunk.
Tuttavia, i parametri associati alle performance ottimali
La tabella 1 mostra come il processxo wordcount, se eseguito in locale, scala in funzione della
e del lesystem utilizzato.
25% rispetto a B1, 48% rispetto a S1, del 38%
sono caratterizzati dai degradi riportati di seguito:
qualità del disco
(vedere paragrafo 8 per le
speciche tecniche).

-50% rispetto a S1,
-36% rispetto a S3 (taglia
100MB)
L'utilizzo
di
altri
sistemi
operativi
ha
permesso
di

poter determinare l'overhead introdotto dai rispettivi IOSubsystem: la quarta colonna (corrispondente a HFS+)
-11% rispetto a S1,
100MB)
mostra come sia possibile ridurre il RT del wordcount
no a renderne inutile (per le taglie utilizzate nei casi di
studio) la distribuzione su griglia.

-7% rispetto a
10GB)
11
P 1w ,
#chunk/slave
2
3
4
5
6
7
8
9
10
500
64
47
33
27
25
27
27
26
27
700
59
40
34
27
24
23
22
22
22
103
51
34
29
23
19
19
18
19
20
1, 5 · 103
1, 5 · 103
44
33
25
21
17
17
18
17
17
2 · 103
43
28
24
20
16
16
16
15
15
3 · 103
37
26
22
15
15
15
15
15
5 · 103
36
26
20
18
18
16
15
16
15
6 · 103
35
26
22
18
15
16
16
104
35
26
22
18
16
14
16
Table 2: RT
3
5
6
10
400
287
250
229
-
-
226
211
2 · 103
-
-
203
182
3 · 103
382
270
172
171
5 · 103
-
-
16
6 · 103
300
260
160
160
159
16
16
104
-
-
175
164
15
15
#chunk/slave
3
10
Table 3: RT
wordcount (100MB) su Grid1.
160
wordcount (1GB) su Grid1.
I degradi sono sempre risultati associati alla saturazione
della banda del NIC (>
performanti.
95%)
sui sistemi con HD molto
Ciò porta a considerare la dimensione
#chunk/slave
dei le nell'ordine dei 10GB come problematica per
l'architettura proposta.
Limite superiore di CIFS/SMB
Table 4: RT
10
6 · 10
1109
104
1199
3
wordcount (10GB) su Grid1.
I risultati ottenuti permettono di ssare il limite supe-
CIFS/SMB
blocca la scalabilità dell'architettura al crescere
delle dimensioni del le poiché il tempo necessario
a creare un chunk, trasferirlo ed elaborarlo è superiore cercato, superato il quale la scelta di
riore rispetto al tempo necessario per analizzare localmente il chunk e passare al successivo (gura 9).
Nel
paragrafo 6 vengono proposte diverse soluzioni per elevare il valore limite. Tuttavia, la dimensione su cui opererà l'architettura supera raramente i 10MB; pertanto
l'utilizzo di queste ottimizzazioni è superuo nel contesto
corrente.
Figure 9: Limite superiore associato alla saturazione del
NIC
12
Macro TYPE
Step Time
ExpNum
RT SeqT
Stimed SeqT
HRT
25
12
288
-
320
T P haseT1
155 · 102
15
-
2325 · 102
-
T P haseT2
108 · 103
15
-
162 · 104
-
MEM/LIG
396 · 104
12
-
4752 · 104
-
TUNING
RT in secondi
Table 5: RT misurato (o stimato) per i tre tipi di macro
se eseguite in modo sequenziale su singolo slave.
4.3
YASARA
Numero di Slave
Come per wordcount, anche per la distribuzione di macro
YASARA sono stati eseguiti diversi tipi di analisi:
1. Calcolo dei RT per ogni insieme di macro eseguite
su ogni
singola tipologia di macchina.
(a) I tre tipi di macro utilizzate comprendono
elaborazioni atomiche (non divisibili) risolvi-
Grid
ProcNum
2
3
4
5
6
7
8
9
10
H14
1
1
142
88
57
53
50
41
40
31
31
-
1
2
135
85
77
58
53
49
46
41
38
-
2
1
150
72
46
-
-
-
-
-
-
-
2
2
137
63
32
-
-
-
-
-
-
-
H
1
-
-
-
-
-
-
-
-
-
52
Secondi
bili in circa 30 secondi (primo tipo), in tempi
nell'ordine delle 30 ore (secondo tipo) e in
Table 6: RT globale per la macro di tuning.
tempi nell'ordine delle 300 (terzo tipo).
2. Confronto dei RT con processo distribuito sulle due

griglie, variando numero di nodi e numero di processi
La prima riga mostra che eettivamente al crescere
del numero di nodi il tempo necessario a completare
paralleli per slave.
l'intero lavoro tende a
L'utilità della distribuzione è lampante già nel caso delle
macro di secondo tipo: elaborare (in modo sequenziale)

Step T ime.
La seconda riga mostra come una congurazione errata (2 processi contemporanei su ogni salve
due macro dal comportamento identico (ogni macro è
P 1w che
non ha a disposizione suciente RAM per support-
un'elaborazione atomica), in cui varia solo un parametro
arli) faccia degradare le performance della griglia.
in un insieme di 5 valori, richiederebbe circa 150 ore;
usando cinque macchine è possibile riportare il tempo

La terza e la quarta riga fanno riferimento alla grid2
richiesto a 30 ore; Di conseguenza, per abbattere ulterior-
costruita su hardware più performante; in questo
mente il tempo di elaborazione sarà suciente aumentare
caso l'hardware supporta più processi paralleli e ciò
la potenza di calcolo (hardware) della griglia.
comporta un miglioramento
netto del RT globale.
La tabella 5 riporta nelle colonne RT SeqT e Stimed SeqT
i tempi di elaborazione (stimati nel caso delle macro
Inoltre, la colonna HRT (griglia 5) e H14 (tabella 6)
di secondo e terzo tipo) necessari per eseguire l'intero
è possibile notare come la presenza di Hadoop e della
working-set compresivo di tutte le sotto-macro in modo
JVM facciano degradare notevolmente le prestazioni
sequenziale. La seconda colonna identicata da ExpNum
degli slave.
riporta il numero eettivo di macro da elaborare per com-
Possiamo quindi assumere che aumentando il numero di
pletare un working-set.
La
prima
colonna
riporta
invece
lo
Step Time
nodi e (se necessario) la potenza dell'hardware,
che
R Y
DM
GA
scala correttamente.
verrà utilizzato come riferimento per determinare la
percentuale di miglioramento raggiunta grazie alla distribuzione dell'elaborazione.
4.3.2
Glass Transition Temperature
4.3.1 Tuning delle griglie
Per questa analisi vengono prese come riferimento la seconda e la terza riga della tabella 5.
Per questa analisi viene presa come riferimento la prima
Il calcolo della temperatura a cui avviene una transizione
riga della tabella 5.
di fase è un problema molto più oneroso rispetto al tun-
Step T ime(P 1w ) '
I risultati riportati in tabella 6 mostrano come dis-
ing: in questo tipo di elaborazione
tribuire l'insieme di macro su più macchine faccia si che
123, 5 · 103 (155 · 102 + 108 · 103 )
RT grid → Step T ime.
membrana sulla quale sta avvendendo l'elaborazione)
In particolar modo:
13
secondi (dipende dalla
La quarta riga, denotata con Mix fa riferimento al tempo
di esecuzione richiesto per completare l'intero lavoro utilizzando un'unica griglia composta dagli slave di
e
Grid2:
Grid1
questo test è stato eettuato per simulare
l'aumento contemporaneo del numero dei nodi e della
potenza di calcolo;
Step T ime
anche in questo caso
RTgrid →
riducendo il RT del 93% rispetto al tempo
stimato.
5
Limiti dell'architettura
L'architettura di
R Y
DM
GA
basa il proprio funzionamento
sui protocolli SMB/CIFS e TCP. Per entrambi, è necessario analizzarne accuratamente le limitazioni imposte
da Microsoft in modo da poter determinare quali versioni dei sistemi operativi sia possibile sfruttare per far
crescere di dimensioni la griglia.
Purtroppo, Microsoft
ha creato diverse limitazioni nei suoi prodotti al ne di
incoraggiare gli utenti ad acquistare le licenze per le versioni Server.
Numero di Slave
Grid
PNum
1
1
-
2
1
859
2
2
516
Mix
Mix
2
3
Limiti di SMB
4
8
9
10
-
-
234
207
187
576
430
-
-
-
-
-
-
461
236
Esiste un limite (visualizzabile da shell utilizzando
cong server)
net
al numero di connessioni SMB in en-
trata sia per le versioni Professional (10) che per le ver-
143
sioni Home (5).
Secondi ( ·103 )
Tuttavia, l'architettura non risente di
questa limitazione poiché ogni slave avrà un'unica con-
Table 7: RT globale per il calcolo delle temperature di
nessione SMB sempre attiva in ingresso (ovvero la con-
transizione di fase.
nessione al MASTER) e una connessione che verrà attivata e disattivata solo per il tempo richiesto dal reducer
pertanto si ha uno
Stimed SeqT ' 1852, 5 · 103
secondi
(' 21 giorni) .
La tabella 7 riporta i risultati ottenuti distribuendo
l'elaborazione
Grid2.
prima
su
Grid1
e
successivamente
su
Non sono stati eettuati test su un numero mi-
per poter recuperare i risultati delle elaborazioni.
Limiti di TCP
Discorso a parte va fatto per le connessioni di tipo TCP.
nore di slave poiché il tempo necessario non sarebbe stato
Per evitare che lo stack TCP/IP occupi tutte le risorse
accettabile.
sul computer vengono usati diversi parametri che control-
Sulla
Grid1
elaborato in
lano quante connessioni il sistema operativo potrà gestire
utilizzando 10 slave l'intero workset è stato
187, 2 · 10
3
secondi (' 3 giorni) con un
miglioramento del 90% rispetto all'elaborazione sequenziale. Inoltre, durante l'elaborazione è stato monitorato
in contemporanea.
Il numero massimo numero di con-
nessioni TCP simultanee è determinato dal parametro
TcpNumConnections (16Milioni di default).
il comportamento dello scheduler che ha assegnato il
Da notare che un limite di 16 milioni di connessioni
carico di lavoro maggiore agli slave più performanti es-
sarebbe molto promettente ma ci sono altri parametri che
cludendo i due elaboratori congurati per procedere più
limitano notevolmente le connessioni: quando un client
lentamente.
Anche in questo caso, analizzando il com-
invoca la connect() allora in modo invisibile/implicito
portamento con 8, 9 e 10 slave è possibile notare come
viene eettuata la bind su una porta emera; il range dei
RTgrid → Step T ime (234 · 103 ⇒ 207 · 103 ⇒ 187, 2 · 103 )
numeri di porta utilizzabili in Windows va da 1024 a 5000
all'aumentare del numero di nodi della griglia.
pertanto si hanno al più 3976 connessioni concorrenti us-
Utilizzando
la
Grid2
è
possibile
constatare
centi per ogni indirizzo IP; tuttavia, è possibile cambiare
che
all'aumentare della potenza di elaborazione decresce rap-
questo limite modicando il parametro MaxUserPort.
idamente il tempo necessario a completare l'intera elab-
Un altro problema da analizzare è dato dalle connessioni
orazione.
TCP che entrano in stato di TIME_WAIT: purtroppo
14
questo stato continua ad occuparci una porta per 4
del SO migliorando ulteriormente le performance (ad
minuti circa (2 volte MSL) prima di essere rimossa; tut-
esempio le trame non vengono divise via software ma
tavia, anche in questo caso è possibile cambiare questo
sull'hardware delle NIC).
valore modicando il parametro TcpTimedWaitDelay in
modo da velocizzare il rilascio delle porte.
7
Inne, per il corretto funzionamento della procedura di
pooling degli slave è necessario modicare il tempo di
Conclusioni
timeout di una connessione TCP/IP (che di default è di
R Y
DM
GA
2 ore) in modo da determinre quanto più velocemente
VM, dalla JVM e dai layer su cui è costruito Hadoop. La
possibile la caduta di uno slave (migliorando così anche
presenza del CLR di .NET è ritenuta trascurabile poiché:
la gestione degli beacon-message): è possibile cambiare

quanto spesso TCP/IP dovrebbe controllare le connes-
anche in presenza del CLR, l'architettura risulta più
performante della controparte scritta per funzionare
sioni modicando la chiave KeepAliveTime.
6
permette di eliminare l'overhead introdotto dalle
su hadoop.

Ottimizzazioni
sebbene il prototipo sia stato implementato su sistemi Microsoft, l'idea che sta alla base di
R Y
DM
GA
ne permette il porting in modo semplice; se conside
eriamo sistemi con kernel Linux è suciente sosti-
dell'elaborazioni delle macro YASARA potrebbe essere
tuire CIFS/SMB con SAMBA (NFS o qualsiasi altro
utile introdurre alcuni accorgimenti di tipo software (o
lesystem distribuito) e adattare le system-call per
hardware) in grado di incrementare la velocità di elabo-
l'uso dei socket.
In
riferimento
alle
performance
del
wordcount
razione.
Di
Per quanto riguarda il wordcount, una prima ottimizzazione potrebbe consistere nel modicare parte del
MASTER e degli slave in modo da non utilizzare, su
questi ultimi, la memoria di massa per mantenere le informazioni sul job da eseguire, bensì trasferire i chunk
tramite TCP ed elaborarli al volo in RAM. Come diretta
conseguenza verrebbe eliminato l'overhead introdotto
dall'utilizzo di SMB (durante i trasferimenti dei chunk)
rispostarlo nella memoria dello slave per poi lanciare il
codice
binario
di
YASARA
(e
posizione senza dover passare per layer di emulazione
garantendo una signicativa diminuzione del tempo di
elaborazione globale (RTGrid ).
problemi
di natura diversa (ignorando completamente la presenza della griglia). Allo stato attuale di sviluppo sono
L'utilizzo degli EP rende possibile distribuire

processo di count. Per l'esecuzione di macro YASARA
essibile-membrana essibile.
menti signicativi poiché, una volta trasferiti il le macro

ed i le di supporto, il RT è in funzione unicamente della
Surng on surfaces ovvero macro che permettono
di sfruttare la grid per eseguire docking ligando
questo accorgimento non potrebbe apportare migliora-
capacità di calcolo dell'elaboratore.
Flexible
docking
(stesso
principio
di
SURSURF
ma applicata alla più classica interazione ligandoproteina. La essibilità della proteina è resa da un
un secondo migliora-
ensemble di diverse conformazioni proteiche)
mento potrebbe essere apportato modicando l'hardware

di rete: nelle congurazioni utilizzate il principale collo
di bottiglia è risultato essere la banda della NIC (funzionante a 100MBit/s) che, una volta saturata,
il
stati distribuiti i problemi di:
e l'overhead generato durante la lettura del chunk per
Ancora riguardo al wordcount,
conseguenza,
Autodock) viene eseguito direttamente sui core a dis-
Glass transition temperature ovvero calcolo della
temperatura di transizione di fase di una molecola.
non
permetteva alla griglia di scalare anche aggiungendo
Inoltre sono in preparazione per la distribuzione i prob-
nuovi nodi; pertanto, ci aspettiamo che all'aumentare
lemi di:
delle prestazioni della NIC aumentino (in funzione della

bontà del sottosistema di rete e della velocità con cui
Molecular dynamics of model membranes ovvero
quest'ultimo genera i pacchetti TCP) anche le prestazioni
una macro che consente di eseguire calcoli di dinam-
e la scalabilità del wordcount. Aumentando la potenza
ica molecolare di una library di molecole su una serie
dell'hardware di rete (nell'ipotesi di non riuscire a sat-
di membrane modello.
urarla) ci aspettiamo che il nuovo limite superiore sia
in funzione della velocità di trasferimento dell'hard-disk,

Steered molecular dynamics (mediante l'uso combinato di steered MD e di dinamica tradizionale, per-
della cache di quest'ultimo e dell'ecienza del sottosis-
mette di calcolare 2ns di MD per ogni posizione oc-
tema di rete del sistema operativo.
cupata da una molecola che attraversa una mem-
Inne, utilizzando la tecnica che sta alla base di DAFS
brana. Questa macro consente anche la creazione di
[4] è possibile bypassare alcuni layer dello strato di rete
mean eld di membrane).
15

Mean eld molecular dynamics ovvero una macro
che consente di distribuire dei calcoli di dinamica
CPU
2x
Intel Xeon@3200Mhz (Bus: 200Mhz,
FSB: 800Mhz)
ibrida, nel quale l'interazione tra un peptide e una
membrana viene fatta con una MD del solo peptide
in un mean eld.
RAM: 4GB DDR2@800Mhz
HD: Seagate SCSI ST373207LW (solo dati,
SO su altro disco)@10.000RPM (Cache:8MB,
Max-Bandwidth: 320MB/Sec) (NTFS)
Dall'analisi dei log è emerso che lo scheduler MF/MA ha
assegnato il carico di lavoro maggiore (maggior numero
di jobs) allo slave più veloce.
NIC: Intel Pro/1000 su rete a 100Mbit/s
SO: Microsoft Windows Server 2003 SE SP2 +
.NET Framework 3.5
I risultati riportati nel paragrafo 4 evidenziano come la
RTGrid direttamente proporzionale alla potenza della griglia e alla
natura CPU-Bounded delle elaborazioni renda
1x
SERVER Intel (S2)
qualità della parallelizzazione che si riesce ad eet-
MOTHER-BOARD:
tuare : gli EP forniscono un metodo semplice e total-
-
mente astratto dal mondo informatico per descrivere una
6300ESB(ICH-S)
macro da eseguire in parallelo; inoltre, YASARA fornisce
nativamente ulteriori ottimizzazioni per l'uso dei multicore e
R Y
DM
GA
eredita automaticamente queste ottimiz-
R Y
GA
DM
può essere considerata una ar-
chitettura valida sulla quale costruire griglie per la par-
ASUSTeK
i875P
-
PCH-DL
SouthBridge
LPCIO: Winbond W83627THF
2x
CPU
Intel Xeon Prestonia
@2660Mhz
RAM: 3GB DDR@266Mhz
HD:
Maxtor
(solo
allelizzazione di elaborazioni bioinformatiche tramite il
dati,
UATA/100
SO
(Cache:2MB,
framework YASARA.
8
Intel
(Bus: 133Mhz, FSB: 533Mhz)
zazioni, poiché usa YASARA come black-box.
Di conseguenza,
Chipset:
su
altro
STM380215A
disco)@7.200RPM
Max-Bandwidth:
100MB/Sec)
(NTFS)
Hardware Utilizzato
SO: Microsoft Windows Server 2003 SE SP2 +
.NET Framework 3.5
8.1
Hardware utilizzato per le
grid
1x
WORKSTATION (S3)
La Grid1 è stata implementata su 10 elaboratori (P1) di
MOTHER-BOARD: Packard Bell MCP73VTPM
tipo HP Compaq:
-
American
Megatrends
PBDV10.P18
SouthBridge NVIDIA nForce 610i

MOTHER-BOARD: 09FCh - Bios: 786D1 v01.03

FILESYSTEM (NTFS su Windows - Ext3 su Linux)

CPU: Intel Pentium 4 HT Prescott @3200Mhz

LPCIO: ITE IT8718
CPU
1x
Intel Pentium E5300 (Dual Core)
Wolfdale @2600Mhz (Bus:
200Mhz,
FSB:
800Mhz)
HD:
Seagate
NIC: Broadcom NetXtreme Gigabit Ethernet (fun-
(solo
dati,
zionante a 100MBit/s)
(Cache:8MB,
SATA
SO
su
NCQ
altro
STM3320813AS
disco)@7.200RPM
Max-Bandwidth:
3GBit/Sec)
(NTFS)
SO:
+
Microsoft
.NET
Windows
Framework
3.5
XP
/
Professional
Fedora
SP3
(2.6.27.9-
159.fc10.i686)
diversa per testare il funzionamento dello scheduler:
WORKSTATION (S4)
MOTHER-BOARD: Intel D510MO Atom Host
Bridge - SouthBridge Intel NM10
MOTHER-BOARD: Intel SE7320EP2 D11950450 SouthBridge 6300ESB (ICH-S)
1x
SERVER Intel (S1)
SO: Microsoft Windows 7 + .NET Framework
3.5
La Grid2 è stata implementata su elaboratori di potenza
1x
LPCIO: Winbond W83627THF
CPU
1x
Intel
Atom
D510
(Dual
Core)
Pineview-D @1666Mhz (Bus: 166Mhz, FSB:
LPCIO: NS PC3874L
666Mhz)
16
HD:
Seagate
(solo
dati,
SATA
SO
(Cache:8MB,
su
umane necessarie all'esecuzione (e alla comprensione) di
NCQ
altro
ST3250318AS
disco)@7.200RPM
Max-Bandwidth:
YASARA e del linguaggio di script Yanaconda.
Inne, un grazie a Vincenzo Di Biasi che ha messo a dis-
3GBit/Sec)
posizione tutte le macchine in suo possesso per la
Grid2.
(NTFS)
SO:
Microsoft
Windows
2008
R2
+
.NET
10
Glossario
Framework 3.5
Chunk:
8.2
Altro hardware utilizzato
1x
CIFS/SMB:
Common
Internet
File
System/Server
Message Block.
WORKSTATION (B1)
CPU-bounded:
dipende esclusivamente dalla velocità di elaborazione
Intel GL40 - SouthBridge 82801IM (ICH9-M)
della CPU, poichè non esistono tempi di attesa dovuti
CPU
1x
all'interazione con l'hardware di IO.
Intel Pentium T4300 (Dual Core)
@2100Mhz
(Bus:
200Mhz,
DLL:
FSB:
800Mhz)
HD:
WDC
DFS:
@5.400RPM
tem che permette la memorizzazioni di le e risorse in
Max-Bandwidth:
3GBit/Sec)
dispositivi di archiviazione distribuiti in una rete infor-
(NTFS)
matica.
NIC: Atheros AR8131 PCI-E Gigabit (Ndis
DAFS: Direct Access File System è un protocollo di le
system di rete veloce e leggero. Le performance di accesso
SO: Microsoft Windows 7 + .NET Framework
ai le sono migliorate utilizzando metodi di trasporto ad
3.5
accesso diretto come InniBand.
DCOM:
WORKSTATION (M1)
MacBook Unibody (Mod.
CPU
1x
No:
DCOM permette di eettuare chiamate di procedure re-
A1278) 2Ghz
mote attraverso una rete, occupandosi di tutte le medi-
Intel Core Due Duo @2000Mhz (Bus:
azioni necessarie, in maniera indipendente dal linguaggio.
1,07Ghz)
Event-driven:
ware/algoritmo che modica il proprio comportamento
HD: Fujitsu MHZ 2160BH [email protected]
(Cache:8MB,
Distributed Component Object Model è una
tecnologia informatica presentata nel 1996 da Microsoft.
Logic Board
Distributed File System è un particolare le sys-
WD1600BEVT
6.20)
dynamic-link library è una libreria software che
viene caricata dinamicamente in fase di esecuzione
(Cache:8MB,
programmi il cui tempo di esecuzione
MOTHER-BOARD: Acer BA50-MV - Chipset:
Penryn
1x
blocco di taglia ssa relativo ad un le.
Max-Bandwidth:
3GBit/Sec)
termine utilizzato per riferirsi ad un soft-
in base al vericarsi di eventi.
Grid:
infrastruttura di calcolo distribuito, utilizzata per
(Journaled HFS+)
l'elaborazione di grandi quantità di dati, mediante l'uso
SO: MacOS 10.6.7 (10J869) - Kernel Darwin
di una vasta quantità di risorse.
10.7.0
HashMap:
tabella chiave-valore non sincronizzata, per-
mette valori nulli sia per le chiavi che per i valori.
9
Hdfs:
Ringraziamenti
Hadoop Distributed File System.
HFS+:
le system sviluppato da Apple per sostituire
Grazie al Prof. Giuseppe Cattaneo (Dipartimento Infor-
il precedente Hierarchical File System (HFS) del quale è
matica ed Applicazioni "Renato M. Capocelli" ) per aver
una versione migliorata.
messo a disposizione le macchine (tipoP 1w e
stata installata la
P 1l ) su cui è IO-bounded:
Grid1 e per averci trasmesso l'interesse
nel testare a fondo le cose (e in modo laico!).
Un ringraziamento particolare va al Prof.
programmi che eseguono molte oper-
azioni di input/output rispetto alla quantità di elaborazioni che avvengono nella cpu.
Stefano Pi-
MCE: Macro with Explode Denition.
otto e alla Dott.ssa Federica Campana (Lab. of Materials
Sciences - Dep. of Pharmaceutical and Biomedical Sci-
MF/MA: MostFast/MostAssigned;
ences ) per aver messo a disposizione le risorse software e
equo per l'assegnazione dei job agli slave più veloci.
17
scheduler
non
Numa:
Non-Uniform Memory Access è un'architettura
[6]
di memoria sviluppata per i sistemi multiprocessore dove
[7]
i tempi di accesso dipendono dalla posizione della memo-
[8]
ria locale, più lentamente alle memorie degli altri proces-
T.White, Hadoop, the denitive guide , O'Reilly,
2009.
ria rispetto al processore. Nelle architetture NUMA un
processore può accedere rapidamente alla propria memo-
Jason, Pro Hadoop , Apress, 2009.
Sanjay Ghemawat, Howard Gobio, and Shun-Tak
Leung, The Google File System , 2003, pag 1-2.
sori o alla memoria condivisa. L'architettura NUMA è il
passo logico successivo delle architetture SMP (Symmet-
[9]
Garth A. Gibson, David F. Nagle, Khalil Amiri,
ric Multiprocessing).
Je Butler, Fay W. Chang, Howard Gobio, Charles
PVL: Portable Vector Language.
Hardin, Erik Riedel, David Rochberg, Jim Zelenka,
A Cost Eective High Bandwith Storage Architec-
RAID: Redundant Array of Independent Disks è un sis-
ture , 1998.
tema informatico che usa un insieme di hard disk per
condividere o replicare le informazioni.
[10] Nelly
I beneci del
Andrusier,
Efrat
Mashiach,
Ruth
Nussi-
nov, and Haim J. Wolfson, Principles of Flexible
RAID sono di aumentare l'integrità dei dati, la toller-
Protein-Protein Docking, PMC, 2009.
anza ai guasti e le presazioni, rispetto all'uso di un disco
singolo
[11] J. F. Nagle, Lipid Bilayer Phase Transition: Den-
Ramdisk:
sity Measurements and Theory, Proc. Nat. Acad.
hard disk costituito da memorie RAM ali-
mentato da batterie che le rendono non volatili.
Sci. USA Vol. 70, No. 12, Part I, pp. 3443-3444, De-
SCSI: Small Computer System Interface è un'interfaccia
cember 1973.
standard progettata per realizzare un bus di trasferi-
[12] Ramesh Radhakrishnan, Ravi Bhargava, Lizy K.
mento di dati.
John, Improving Java performance using hardware
SAS: Serial Attached SCSI.
translation , ICS '01 Proceedings of the 15th international conference on Supercomputing, New York,
TCP: Transmission Control Protocol.
Throughput:
2001.
indica la banda eettiva di un canale di
comunicazione, misurata in un certo periodo di tempo.
Yasara:
Yet Another Scientic Articial Reality Appli-
cation.
References
[1]
Silberschatz, Galvin, Gagne, Sistemi Operativi -
Concetti ed Esempi 7th edtion , par. 1.3.2 Sistemi Multiprocessore, par. 4.2 Multithread, par 5.4
Scheduling per sistemi Multiprocessore,
par.
6.2
Problema della sezione critica, par 6.4 Hardware per
la sincronizzazione, chap. 7 Stallo dei processi, par.
11.1 Struttura del File System, par 11.4 Metodi di
allocazione, par 12.7 Strutture RAID, 2006.
[2]
Lina J. Karam, Ismail AlKamal, Alan Gatherer,
Gene A. Frantz, David V. Anderson, Brian L. Evans,
Trends In Multi-Core DSP Platforms , Nov 2009,
pp 3.
[3]
Kay and Lauder, A Fair Share Scheduler , CACM,
31(1), Jan 1988, pp 1-2.
[4]
Kostas Magoutis, "Design and Implementation of a
Direct Access File System (DAFS) Kernel Server for
FreeBSD", Dec 2001.
[5]
Jerey Dean, Sanjay Ghemawat, MapReduce: Sim-
plied Data Processing on Large Clusters , 2004.
18