Universita degli Studi di Trieste

Dipartimento di Ingegneria e ArchitetturaCorso di Laurea Magistrale in Ingegneria Informatica

Tesi di Laurea in Programmazione Distribuita

Progetto e realizzazione di unsistema robusto di gestione deidati per ambienti di esecuzione

distribuita

Candidato: Relatore:

Paolo Morandini Chiar.mo Prof. Alberto Bartoli

Correlatore:

Ph.D. Carlos Kavka

Anno Accademico 2012-13 - Sessione straordinaria

.

Alla mia famiglia, parenti e amici.Grazie.

Introduzione

Negli ambienti di esecuzione distribuita le elaborazioni avvengono su calcola-

tori distinti: queste sono orchestrate in modo statico o dinamico da un’unita

centrale. Tipicamente ognuna di queste elaborazioni richiede uno o piu file

in ingresso e produce uno o piu file in uscita, nasce cosı la necessita di tra-

sportare questi file ovunque essi siano richiesti come input.

Il prodotto di questa tesi e un software in grado di trasferire file di grandezza

arbitraria accessibili attraverso i piu comuni protocolli di trasferimento dei

file, esso utilizza persistenza e transazioni per poter offrire un certo grado di

robustezza in risposta ad eventi non catastrofici. Il prototipo realizzato e al-

tresı capace di individuare una strategia (qualora possibile) per trasferire un

file fra due dispositivi anche nel caso questi non possano stabilire connessioni

dirette fra loro.

Il motivo che ha portato allo sviluppo di un tale sistema e legato alla volonta

presso il gruppo di Ricerca e Sviluppo di ESTECO S.p.A. di sviluppare un

motore in grado di coordinare un’esecuzione distribuita. A fronte di tale

volonta si ritiene utile uno studio riguardo l’opportunita di sviluppare un

sistema ad-hoc, ed un’indagine sul potenziale impatto di alcune tecnologie

quali gli Enterprise Integration Patterns[1](d’ora in poi EIPs).

Il percorso che ha portato alla realizzazione del prototipo comprende lo studio

II

delle tecnologie di messaggistica asincrona (nello specifico JMS), lo studio di

alcuni sistemi, protocolli e metodologie per il trasferimento dei file, la valuta-

zione di diversi framework (in particolare quelli riguardanti gli EIPs), lo stu-

dio dei concetti di transazionalita e persistenza e delle librerie che forniscono

tali funzionalita.

Vincoli

Il sistema richiesto e vincolato ad utilizzare il linguaggio di programmazione

Java[2] (versione 7 o superiore), deve inoltre operare indifferentemente su

Microsoft Windows, su GNU/Linux e su Mac OS X. L’interfacciamento deve

avvenire in maniera asincrona tramite messaggi JMS utilizzando il broker

Apache ActiveMQ[3].

Contenuto della tesi

Nel primo capitolo verranno fornite informazioni riguardo allo smistamento

dei dati (nella letteratura tecnica: “data placement”) e alla sua importanza

nell’esecuzione distribuita, inoltre verranno passate in rassegna alcune meto-

dologie e tecnologie di trasferimento, movimentazione e distribuzione dei dati

per ognuna delle quali si dara una breve descrizione occasionalmente accom-

pagnata da considerazioni sul loro funzionamento. Nel capitolo successivo

si dara spazio all’analisi che ha preceduto il lavoro di progettazione, verra

delineato lo scenario tipico in cui si vuole lavorare, si analizzeranno obiettivi

e vincoli tecnologici. Il capitolo sulla progettazione definira l’interfaccia del

sistema realizzato e la suddivisione in moduli che e stata eseguita, per ogni

modulo verra definita una interfaccia. In seguito si scendera nel dettaglio

dell’implementazione dimostrando il modo in cui sono stati costruiti i mo-

duli utilizzando principalmente una composizione di Enterprise Integration

Patterns. Si conclude con un capitolo che riporta alcuni test di robustezza

effettuati e i risultati di alcune valutazioni di prestazioni.

Indice

1 Distribuzione dei dati per l’esecuzione distribuita 1

2 Analisi 10

2.1 Ipotesi sullo scenario tipico . . . . . . . . . . . . . . . . . . . . 10

2.2 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Progettazione 13

3.1 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Macrofunzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Ricerca dei file . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2 Pianificazione del trasferimento . . . . . . . . . . . . . 18

3.2.3 Esecuzione e verifica del trasferimento . . . . . . . . . 21

4 Implementazione 23

4.1 Ricerca dei file . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.2 Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Pianificazione del trasferimento . . . . . . . . . . . . . . . . . 28

4.2.1 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.2 Chunker . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.3 Mapper . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Esecuzione e verifica del trasferimento . . . . . . . . . . . . . . 31

INDICE IV

4.3.1 Transfer Manager . . . . . . . . . . . . . . . . . . . . . 31

4.3.2 File Checker . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Verifica della robustezza e valutazione delle prestazioni 33

5.1 Ambiente di test . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Configurazione dei nodi . . . . . . . . . . . . . . . . . 34

5.1.2 Configurazione di ActiveMQ . . . . . . . . . . . . . . . 35

5.1.3 Configurazione FTP e HTTP Server . . . . . . . . . . 36

5.2 Robustezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2.1 Monitoraggio del sistema . . . . . . . . . . . . . . . . . 36

5.2.2 Interruzioni improvvise . . . . . . . . . . . . . . . . . . 38

5.2.3 Problemi di rete . . . . . . . . . . . . . . . . . . . . . . 40

5.3 Prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3.1 Chunking e impatto dei relay . . . . . . . . . . . . . . 43

5.3.2 Thread e memoria occupata. . . . . . . . . . . . . . . . 44

6 Conclusioni 47

Elenco delle figure

1.1 Esempio di esecuzione distribuita . . . . . . . . . . . . . . . . 2

1.2 Esecuzione distribuita: un nodo genera dati che possono ser-

vire su altri nodi . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Stork: grafo rappresentante un trasferimento . . . . . . . . . . 5

1.4 BitTorrent: uso di nodi relay . . . . . . . . . . . . . . . . . . . 7

3.1 Interfaccia esterna del sistema . . . . . . . . . . . . . . . . . . 15

3.2 Moduli del sistema e loro comunicazione . . . . . . . . . . . . 17

3.3 Esempio di grafo della rete con Dijkstra . . . . . . . . . . . . . 19

3.4 Confronto trasferimento con e senza chunking . . . . . . . . . 20

4.1 Ricerca dei file . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Percorso messaggi nel Finder . . . . . . . . . . . . . . . . . . . 26

4.3 Percorso messaggi nel Catalog . . . . . . . . . . . . . . . . . . 27

4.4 Pianificazione del trasferimento . . . . . . . . . . . . . . . . . 28

4.5 Percorso messaggi nel Router . . . . . . . . . . . . . . . . . . 29

4.6 Percorso messaggi nel Chunker . . . . . . . . . . . . . . . . . . 30

4.7 Percorso messaggi nel Mapper . . . . . . . . . . . . . . . . . . 30

4.8 Transfer Manager . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1 Process Mining: analisi del sistema . . . . . . . . . . . . . . . 38

5.2 Attivita sui vari nodi durante il crash test . . . . . . . . . . . 39

5.3 Attivita sui vari nodi durante il test di interruzione delle co-

municazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.4 Test modifica della topologia . . . . . . . . . . . . . . . . . . . 41

5.5 Comparazione velocita di trasferimento con e senza chunking . 43

5.6 Risorse impegnate dal sistema . . . . . . . . . . . . . . . . . . 45

5.7 Risorse impegnate durante uno stress test . . . . . . . . . . . 45

5.8 Esempio di mancato rilascio delle risorse. . . . . . . . . . . . . 46

Elenco delle tabelle

5.1 Velocita di trasferimento con e senza chunking . . . . . . . . . 44

Capitolo 1

Distribuzione dei dati per

l’esecuzione distribuita

Quando l’esecuzione di un flusso di lavoro viene suddivisa e distribuita su piu

nodi e necessario distribuire, e successivamente raccogliere, i dati di ingresso e

uscita ad ogni elaborazione. I dati vengono prodotti su un dispositivo di me-

moria facente parte dell’ambiente distribuito non necessariamente accessibile

dagli altri nodi pertanto nasce la necessita di gestire tali dati.

Necessita degli ambienti di esecuzione distribuita

In un ambiente di esecuzione distribuita ogni nodo esegue un programma il

quale puo aver bisogno di determinati file di input ed eventualmente produce

uno o piu file di output. Una esecuzione puo essere composta da una molti-

tudine di elaborazioni eventualmente su diversi nodi, in tal modo l’output di

una di esse potrebbe essere l’input di una o piu altre esecuzioni, si veda ad

esempio la Figura 1.1. La pianificazione delle esecuzioni e dei trasferimenti

ha uguale importanza poiche nessuna elaborazione puo avvenire se mancano

i dati su cui deve operare.

Distribuzione dei dati per l’esecuzione distribuita 2

Node Node

Node

Node

Parameters

Mesh

Thermal Analysis

EMAnalysis

TurbulenceAnalysis

Figura 1.1: Esempio di esecuzione distribuita, a partire da alcuni pa-rametri un nodo crea un modello sul quale altri nodieseguiranno diverse tipologie di analisi e simulazioni.

Uno degli scenari possibili e quello in cui l’ambiente distribuito e composto

da un numero fissato di nodi tutti connessi fra di loro. In questi ambienti

l’esecuzione puo essere pianificata a priori conoscendo tutte le risorse dispo-

nibili cercando la loro allocazione piu efficiente.

Si noti che il tipo di connessione di cui parliamo non e da intendersi come

connessione fisica ma piuttosto come possibilita di utilizzare un protocollo

di trasferimento file fra due nodi, il termine “connessione” verra utilizzato

con questo significato ovunque non diversamente specificato, quando si fara

riferimento alla “topologia” della rete si intendera un grafo in cui i vertici

sono i nodi e gli archi sono connessioni di questo tipo.

Uno scenario diverso e quello di interesse per questa tesi: ad una rete parte-

cipano un numero incognito di nodi i quali, tramite un opportuno software,

sono in grado di riconoscere quali esecuzioni possono portare a termine in ba-

se alle risorse locali disponibili (file, programmi, etc..). Date queste premesse

e necessario che tutti i trasferimenti di dati vengano pianificati nel momento

in cui un nodo viene in possesso di una richiesta di elaborazione da portare

a termine.

In questa tesi non verra definito il modo in cui un nodo puo determinare quali

Distribuzione dei dati per l’esecuzione distribuita 3

richieste e in grado di soddisfare o come determina le dipendenze fra esse,

si affronteranno invece le problematiche relative alla localizzazione di dati

presenti nell’ambiente distribuito e al loro trasferimento sul nodo che ne ha

richiesto l’accesso. Si presuppone che i dati presenti nell’ambiente distribuito

siano contenuti (o possano essere inseriti) in dei file.

In un ambiente distribuito con dei nodi che competono per l’esecuzione di

un insieme di operazioni ad uno di essi ne viene assegnata una. Il nodo deve

recuperare tutti i dati necessari all’elaborazione descritta nella richiesta, esso

dispone di un identificatore univoco per ogni file di cui ha bisogno e tale

identificatore gli viene fornito assieme alla descrizione del lavoro che dovra

svolgere. I file cosı identificati risiedono in almeno un dispositivo di memoria

presente nell’ambiente distribuito oppure verranno prodotti e inseriti in uno

di questi, essi potrebbero essere replicati su piu di un nodo e il sistema che

coordina l’esecuzione (qualora esistesse) potrebbe o meno essere a conoscen-

za della loro posizione ed esistenza.

Node Node

NodeNodeParameters

I created Mesh

Thermal Analysis

You need Mesh

?

Figura 1.2: Il nodo in alto a sinistra in seguito ad una elaborazione haprodotto un file, il nodo in basso a destra ha bisogno di quelfile senza sapere chi l’ha generato o quando verra generato.

A tal proposito si veda la Figura 1.2, il nodo in alto a sinistra e incaricato

di eseguire una operazione e al termine di questa produce un file; in un mo-

mento diverso (non necessariamente successivo) un nodo vuole iniziare una

Distribuzione dei dati per l’esecuzione distribuita 4

esecuzione che necessita di operare sul file prodotto dal primo nodo: uno

scenario simile richiede un sistema in grado di localizzare tale file, stabilire

una strategia per il suo trasferimento ed effettuarlo in modo che il nodo possa

soddisfare tutti i requisiti necessari all’inizio dell’elaborazione.

Il modo in cui i vari nodi ricevono o prendono in carico una esecuzione, il

formato in cui ricevono la descrizione dell’elaborazione da eseguire, il modo

in cui sono descritti ed identificati i dati necessari in input e i dati che do-

vranno produrre in output non verranno definiti in quanto non sono oggetto

di questa tesi. Si suppone l’esistenza di un sistema in grado di orchestrare

l’esecuzione, di generare tutte le strutture dati necessarie e di comunicarle al

sistema che si vuole progettare.

Nel prosieguo del documento i termini “task”, “esecuzione” e “processo”

verranno sempre utilizzati per indicare l’operazione singola che un nodo ef-

fettua nell’ambiente distribuito. Sorgente e destinazione di un trasferimento

verranno chiamati anche “endpoint” mentre i nodi intermedi sui quali i dati

transitano temporaneamente verranno chiamati “relay”.

Alcuni sistemi di condivisione e trasferimento dei dati

Prima di progettare un sistema ex novo sono stati studiati alcuni sistemi

per la condivisione, distribuzione e trasferimento dei file. Alcuni di essi so-

no molto specifici mentre altri sono “general purpose”, per ognuno di essi

sono state vagliate le funzionalita che potrebbero essere utili nello scenario

descritto e soprattutto l’approccio architetturale al problema. I sistemi presi

in considerazione sono stati Stork[4], BitTorrent[5], Hadoop[6] e PhEDEx[7].

Distribuzione dei dati per l’esecuzione distribuita 5

Stork

Questo sistema opera nell’ipotesi di poter predeterminare l’assegnamento di

ogni task da eseguire ovvero di conoscere gia nel dettaglio l’intero ambiente

distribuito. Esso opera su un input che consiste in una rappresentazione del-

l’esecuzione distribuita tramite un grafo diretto aciclico (DAG), questo grafo

contiene tutte le informazioni sulle dipendenze fra le diverse esecuzioni.

Figura 1.3: Stork: DAG rappresentante un trasferimento tramite duenodi intermedi. k e il livello di concorrenza. Immaginetratta da [4]

Stork opera su questo grafo costruendo un secondo grafo (come ad esempio

quello in Figura 1.3) che rappresenta i trasferimenti fra i vari nodi. Questo

e un DAG ricavato da quello di input arricchito da nozioni sulla topologia

della rete (intesa non come rete fisica, ma ad un livello logico) e contenente

una descrizione completa e dettagliata delle operazioni da portare a termine.

Questa descrizione include anche tutti i trasferimenti intermedi quando fra

due nodi non si puo trasferire direttamente un file (ovvero non c’e connes-

sione). Il DAG ottenuto inoltre contiene indicazioni sullo spazio da riservare

sui dispositivi di memoria, sul momento in cui eliminare i file temporanei e

Distribuzione dei dati per l’esecuzione distribuita 6

tutti i dettagli inerenti a tali operazioni.

Stork non e stato studiato per esaminarne l’implementazione (anche se si

fosse voluto non sarebbe stato possibile poiche i sorgenti non sono pubblici)

ma per capire che tipo di architettura e organizzazione interna sono state

adottate, inoltre le pubblicazioni a riguardo riportano molte considerazioni

sul trasferimento dei file in ambienti distribuiti.

BitTorrent

Questo protocollo di scambio dei file opera con modalita peer-to-peer pur

mantenendo la necessita di uno (o piu) nodi centrali, questi nodi consentono

la localizzazione dei file e contengono informazioni necessarie a stabilire la

comunicazione fra i peer.

BitTorrent e nato per la distribuzione dei dati in un ambiente fortemente

dinamico. Esso ha lo scopo di raggiungere una elevata replicazione, tuttavia

e utilizzabile, in linea di principio, anche per trasferimenti singoli. Questo

protocollo non prevede una soluzione in grado di aggirare il caso in cui nes-

suno dei due nodi (sorgente e destinazione) puo stabilire una connessione

con l’altro a meno che il file non sia disponibile su altri nodi con i quali essi

possono connettersi.

Questa limitazione e aggirabile dotando la rete di alcuni nodi relay oppor-

tunamente configurati, tali nodi devono essere in grado di rilevare queste

criticita ed operare come “ponte” fra i due nodi interessati al trasferimento,

il meccanismo dovrebbe essere innescato dai nodi di sorgente e destinazione:

quando essi rilevano di non poter trasferire il file fra di loro chiedono ai nodi

relay di agire da tramite.

Distribuzione dei dati per l’esecuzione distribuita 7

Source Node

Destination Node

Relay Node

Relay Node

Virtual Direct Transfer

Real Transfer Step 1

Real Transfer Step 2

Real Transfer Step 3

Figura 1.4: BitTorrent: possibile configurazione per permettere il tra-sferimento fra due nodi protetti da firewall. Il trasferi-mento viene realizzato con tre trasferimenti che poggianosu due nodi configurati per fare da relay.

Hadoop

Si tratta di un framework nato per lo storage distribuito dei dati e loro acces-

so su larga scala, nasce con lo scopo di agevolare l’utilizzo degli algoritmi di

“MapReduce”, termine che e stato originato presso Google[8], sui dati salva-

ti. Suddivide, secondo delle strategie configurabili, i file in diversi frammenti

(detti anche “chunk”) che vengono salvati e replicati su un numero variabile

di nodi.

La frammentazione puo essere disattivata facendo in modo che Hadoop lavori

con file interi[9]. Questa tecnologia tuttavia richiede l’utilizzo di una rete in

cui tutti i nodi possono connettersi fra loro (talvolta utilizzando piu di un

protocollo). Il progetto e ritenuto stabile solo su GNU/Linux, mentre e

distribuito come “development platform” su Windows. Mac OS X, il sistema

operativo su cui e stata sviluppata questa tesi, non e supportato.

PhEDEx

Acronimo per “Physics Experiment Data Export”, PhEDEx e un sistema di

distribuzione al pubblico dei dati risultanti da esperimenti di fisica delle alte

Distribuzione dei dati per l’esecuzione distribuita 8

energie (HEP) generati presso gli acceleratori di particelle esistenti.

Il funzionamento e grosso modo quello di una struttura di distribuzione mul-

tilivello basata sul modello publisher subscriber[10], dove i centri di ricerca

accademici si registrano alle sorgenti di dati volute e PhEDEx si occupa di

trasportare sui nodi tutti i dati pubblicati dai gruppi di ricerca selezionati.

Questo sistema opera grazie ad una serie di agenti che sono piccoli software

indipendenti cooperanti per creare una funzionalita di alto livello. Grazie a

questo tipo di disaccoppiamento il sistema esibisce una robustezza nei con-

fronti di alcuni eventi non catastrofici in quanto ogni piccolo modulo opera

con un comportamento transazionale. L’elevato disaccoppiamento e stato

oggetto d’interesse e di studio nelle fasi preliminari di questa tesi ed e stato

approfondito in letteratura.

Necessita di sviluppare un sistema dedicato

Il sistema sviluppato in questa tesi richiede alcune funzionalita presenti in uno

o piu dei sistemi precedentemente esposti, tuttavia nessuno di essi le contiene

tutte, questo ha portato all’analisi, progettazione e implementazione di un

sistema dedicato in grado di operare con le seguenti precondizioni:

• Topologia di rete, supporto multiprotocollo: il sistema dovra na-

scondere la complessita legata alle modalita con cui il nodo e inserito nella

rete, ai protocolli che esso utilizza ed alla necessita o meno di usare relay

(anche multipli) per ottenere il trasferimento dei file.

• Verifica dei trasferimenti: ogni trasferimento dovra essere validato an-

che a scapito delle prestazioni in quanto non e ammissibile iniziare un

processo dispendioso di elaborazione su dati di input non validi (si pensi

ad una simulazione della durata di alcune ore o alcuni giorni).

Distribuzione dei dati per l’esecuzione distribuita 9

• Atomicita e persistenza: durante l’esecuzione distribuita alcuni nodi

potrebbero smettere di funzionare senza preavviso per motivi legati al-

l’usura dei componenti, mancanza di fornitura elettrica, problemi di rete,

crash di sistema. Nel caso di eventi non catastrofici i trasferimenti e l’e-

secuzione devono riprendere una volta ripristinato il nodo. I trasferimenti

devono essere atomici e idempotenti.

• Produzione differita dei dati: non e garantito che i dati richiesti da

un nodo siano gia presenti nel sistema al momento della richiesta, essi

potrebbero essere prodotti da un altro nodo in un istante successivo. I

dati potrebbero inoltre non essere mai prodotti.

• Ubicazione incognita dei dati: non deve essere necessario conosce-

re quale nodo ha prodotto i dati richiesti ne in in quale dispositivo essi

risiedano. Un identificatore univoco per tali dati deve essere sufficiente.

• Adattamento all’ingresso di nuovi nodi: l’ingresso di un nuovo nodo

nella rete durante l’esecuzione deve essere supportato, sia nel caso esso sia

un nodo precedentemente presente nella rete e ripristinato a seguito di un

errore sia nel caso esso sia nuovo.

Capitolo 2

Analisi

La fase di studio ed analisi del sistema che si andra a realizzare consiste

in una fase iniziale in cui sono stati raccolti alcuni dati riguardo il “setup”

tipico dell’ambiente in cui si dovra operare, una lista di funzionalita attese e

di vincoli tecnologici da rispettare.

2.1 Ipotesi sullo scenario tipico

Le caratteristiche degli ambienti di esecuzione distribuita presi in consi-

derazione hanno influenzato le scelte fatte nella fase di progettazione, in

particolare i seguenti punti sono quelli su cui ci si e maggiormente focalizzati.

• Tipologia dei nodi: non si e voluto definire le qualita dei nodi, potreb-

bero essere elaboratori per “High Performance Computing” come essere

dei personal computer con limitate capacita di calcolo. Si presume invece

che ognuno di essi abbia a disposizione uno spazio libero sulla memoria di

massa che consenta tutte le operazioni necessarie. Il sistema operativo non

e rilevante salvo il requisito di poter eseguire una Java Virtual Machine.

• Quantita dei nodi: il numero di nodi coinvolti nel sistema puo variare da

alcune unita a poche decine, ognuno di essi deve essere in grado di inviare

2.2 Obiettivi 11

e ricevere tutte le informazioni necessarie a determinare la composizione e

lo stato dell’ambiente distribuito.

• Topologia della rete: e richiesto di non fare ipotesi restrittive sulla

topologia della rete salvo il fatto che tutti i nodi hanno, necessariamente,

accesso ad un nodo con un sistema di comunicazione asincrona a messaggi

in esecuzione.

• Accesso ai dati: l’accesso ai dati, a basso livello, viene fornito tra-

mite FTP, HTTP, SMB o altri protocolli non specificati. Alcuni nodi

potrebbero non avere in esecuzione un file server.

2.2 Obiettivi

Lo scopo principale di questa tesi e quello di arrivare ad un prototipo che,

a seguito di una invocazione della sua interfaccia, possa trasferire i file e

notificare il loro avvenuto recupero al nodo che l’ha richiesto. Verranno ora

elencati gli obiettivi principali di questo progetto.

• Interfaccia tramite messaggi JMS: l’interfaccia deve essere composta

da un numero ben preciso di messaggi, non e stato posto alcun vincolo

sul loro contenuto se non quello di essere facilmente producibile con il

linguaggio di programmazione Java.

• Portabilita: tutte le tecnologie utilizzate devono essere in grado di fun-

zionare sui tre sistemi operativi di riferimento, i nodi devono inoltre essere

avviati e monitorati con le stesse modalita.

• Accesso multiprotocollo alle risorse: l’implementazione deve essere

in grado di includere qualsiasi protocollo di trasferimento possa essere

implementato (o importato da librerie di terze parti) in ambiente Java.

Nessuna ipotesi deve essere fatta sul protocollo necessario per accedere

alle risorse.

2.3 Vincoli 12

• Uso di nodi relay: nel caso in cui fra il nodo sorgente e quello desti-

nazione non fosse possibile effettuare un trasferimento diretto, il sistema

deve pianificare l’uso di uno o piu nodi di relay in cascata in modo che il

trasferimento possa avvenire ugualmente.

• Astrazione: chi invoca il sistema non deve essere necessariamente a co-

noscenza di alcun dettaglio riguardante i nodi, la loro collocazione, la loro

configurazione o altri parametri.

• Utilizzo di una quantita predicibile di risorse: e importante che il

sistema che verra realizzato impegni una quantita di risorse predefinita,

anche sotto stress. Le risorse impegnate per il funzionamento devono essere

correttamente rilasciate una volta terminato il loro utilizzo.

2.3 Vincoli

Il lavoro richiesto e stato sottoposto a pochi vincoli lasciando una discreta

liberta nella scelta delle tecnologie da utilizzare, essi verranno elencati di

seguito. Per ogni vincolo tecnologico viene data una breve spiegazione della

tecnologia e di come viene utilizzata.

• JavaTM 7: si vuole un linguaggio ad oggetti in grado di garantire un’eleva-

ta portabilita, Java risponde a questi requisiti. La versione 7 e attualmente

utilizzata dal gruppo di ricerca e sviluppo e pertanto e stata adottata.

• ActiveMQ: e il middleware di messaggistica utilizzato dal team di svilup-

po del motore di esecuzione distribuita, pertanto il sistema dovra utilizzare

questa implementazione conforme alle specifiche JMS.

• Protocolli esistenti: i trasferimenti devono utilizzare protocolli esisten-

ti e possibilmente molto diffusi in modo che sia plausibile supporre che

ogni nodo abbia, per la sua piattaforma, una implementazione di tale

protocollo.

Capitolo 3

Progettazione

L’attivita di progettazione ha avuto un ruolo chiave nella definizione archi-

tetturale del sistema sviluppato in questa tesi, nello specifico si e scelto di

utilizzare una “Event-driven architecture”[11,12] distribuita[13] in grado per

sua natura di supportare, se opportunamente utilizzata, un elevato livello di

disaccoppiamento[14].

Questa scelta e nata dal fatto che i messaggi sono, a tutti gli effetti, degli

eventi che arrivano alle varie componenti in tempi impredicibili. L’elevato

disaccoppiamento che ci si prefigge di raggiungere permettera di sostituire le

singole componenti anche in un solo nodo fintanto che queste rispetteranno

l’interfaccia definita in questo capitolo.

La costruzione dell’architettura distribuita viene coadiuvata dall’utilizzo de-

gli “Enterprise Integration Patterns” che si fondano sulla comunicazione tra-

mite messaggi e descrivono (fra i tanti) il pattern “Event Driven Consumer”,

inoltre essi prevedono il pattern “Transactional Client”, che verra utilizzato

per rendere il sistema robusto riguardo un insieme, limitato, di imprevisti.

Esistono diversi progetti, fra essi ci si e focalizzati su quelli Open Source, che

Progettazione 14

si propongono di implementare questi pattern. I framework presi in consi-

derazione in una fase preliminare sono stati: Spring Integration[15,16], Mule

ESB[17] e Apache Camel[18,19].

In seguito ad una valutazione iniziale delle tre alternative si e deciso di uti-

lizzare Apache Camel in quanto supporta un numero maggiore (al momento

della valutazione) di protocolli di comunicazione per i suoi componenti, inol-

tre esso permette di definire la composizione dei pattern tramite il linguaggio

di programmazione Java (contro XML degli altri due progetti), linguaggio

nel quale il candidato ha maggior dimestichezza.

Nella terminologia usata dalla documentazione di questa libreria una com-

posizione di pattern di integrazione si definisce “Route”, ovvero percorso.

Tali percorsi iniziano e terminano con degli “Endpoint”, siano essi reali o

virtuali. Ogni route preleva, elabora, manipola e consegna delle “Exchange”,

in questa tesi le Exchange utilizzate corrispondono a messaggi arricchiti da

metadati identificati da stringhe, tali metadati vengono salvati negli “Hea-

der”. Il paradigma ad eventi implementato in Apache Camel equipara ogni

messaggio recevuto da un endpoint ad un evento. Nel seguito di questo do-

cumento i termini messaggio ed evento verranno utilizzati come sinonimi, i

termini route e header verranno utilizzati con i significati di cui sopra.

Apache Camel e stato utilizzato in sinergia con lo Spring Framework[15] (da

non confondere con lo Spring Integration Framework, di cui sopra). Que-

st’ultimo offre la possibilita di istanziare alcune componenti descrivendole in

un file XML[20]. Il framework fa uso della tecnica di “Inversion of Control”

nello specifico la “Dependency Injection”[21] che permette di alleggerire il

codice delegando a Spring la creazione e la gestione di molti aspetti. Nel

caso specifico di questa tesi il framework e stato utilizzato nella gestione dei

componenti riguardo la comunicazione con JMS, la gestione delle transazio-

3.1 Interfaccia 15

ni, nonche l’esecuzione del DBMS H2[22] con relativa web console. Spring

ha permesso anche l’uso di alcune tecnologie di monitoraggio alle quali si

accennera nel Capitolo 5.

3.1 Interfaccia

Il sistema di gestione dei dati deve operare in risposta a determinati eventi,

segnalati dall’arrivo di messaggi in un sistema JMS, e deve rispondere in

modo analogo. L’interfaccia e costituita da due messaggi di richiesta e due

di risposta, il loro contenuto viene ora specificato.

Figura 3.1: L’interfaccia e costituita da messaggi in un sistema JMS,si evidenziano i quattro tipi di messaggi utilizzati.

• Add File to System: contiene un identificatore univoco del file che si

vuole inserire nel sistema, un indirizzo locale al mittente in cui il file esiste

e l’identificatore globale del nodo che ha generato il messaggio.

• Retrieve File: contiene l’identificatore univoco del file che si vuole rice-

vere e l’identificatore globale del nodo che genera la richiesta.

3.2 Macrofunzioni 16

• File Retrived: contiene l’identificatore univoco del file recuperato, l’in-

dirizzo locale al ricevente in cui il file risiede e l’identificatore globale del

nodo che lo ha richiesto.

• Error: contiene una eccezione che identifica un errore nell’uso dell’in-

terfaccia o nel recupero del file, opzionalmente puo includere informa-

zioni aggiuntive generate dai sottosistemi (utilizzabili per identificare piu

dettagliatamente l’errore occorso).

Per aumentare la leggibilita dei messaggi nello scenario di una interazione

manuale essi sono nel formato JSON[23]. Nel caso del messaggio di errore

alcuni degli oggetti che sarebbero consultabili fra le informazioni aggiuntive

non possono essere convertiti al formato JSON a causa di riferimenti circolari

introdotti da alcune librerie utilizzate: tali elementi vengono soppressi.

3.2 Macrofunzioni

In fase di progettazione si e deciso di suddividere la funzionalita globale in

tre macrofunzioni indipendenti ognuna dotata della sua interfaccia. Tali ma-

crofunzioni (dette anche moduli) rispondono alle tre azioni elementari che il

sistema deve svolgere: esse sono la ricerca e localizzazione di un file, la pia-

nificazione del trasferimento e l’esecuzione materiale del trasferimento con

verifica della sua correttezza. L’interfaccia di ogni modulo e basata sui mes-

saggi, si faccia riferimento alla Figura 3.2 che descrive la struttura del sistema.

I componenti indicati come “Orchestrator” e “Exported Interface” non ver-

ranno descritti nel dettaglio in quanto si tratta di funzionalita elementari

necessarie solo ad indirizzare i messaggi ricevuti dall’esterno e quelli generati

internamente sulle code JMS opportune.

3.2 Macrofunzioni 17

Distributed Data Manager

Locate Plan Execute

JMS

Exported InterfaceOrchestrator

ExternalInterface

Figura 3.2: Tutti i moduli comunicano tramite JMS, essi sono indipen-denti ed esportano una interfaccia. I due moduli “orche-strator” e “exported interface” si occupano rispettivamentedi fare da collante fra i vari sottomoduli e implementarel’interfaccia esterna.

3.2.1 Ricerca dei file

Questo modulo, indicato come “Locate” in Figura 3.2, ha il compito di lo-

calizzare un file nel sistema distribuito dato il suo identificativo univoco.

La localizzazione avviene interrogando tutti i nodi del sistema, se uno di essi

possiede il file corrispondente all’identificativo allora rispondera alla richiesta.

Qualora non si ricevesse una risposta il modulo provvede a ripetere la ricer-

ca. Gli intervalli di tempo che intercorrono fra una richiesta e la successiva

aumentano con una crescita esponenziale (per ogni singola ricerca), dopo un

lasso di tempo preconfigurato, se la ricerca non ha esito positivo, essa viene

interrotta.

L’interfaccia si compone dei seguenti messaggi, ad ogni invocazione il primo

e sempre presente mentre gli ultimi due sono mutuamente esclusivi:

• Locate File: contiene l’identificatore univoco di un file che si vuole lo-

calizzare, contiene inoltre informazioni accessorie come il timestamp e il

nome del nodo che fa la richiesta.

3.2 Macrofunzioni 18

• File Located: contiene l’identificatore univoco di un file e le informazioni

riguardo la sua ubicazione, anch’esso contiene il timestamp e il nome del

nodo che ha richiesto il trasferimento.

• Error: nell’eventualita che il file non fosse localizzabile (perche non esi-

ste o perche il nodo su cui risiede e irraggiungibile) viene inserito nella

coda questo messaggio contenente l’identificatore del file e una serie di

informazioni utili a capire l’origine dell’errore.

3.2.2 Pianificazione del trasferimento

Una volta che un file e stato localizzato e necessario determinare le modalita

con cui effettuare il suo trasferimento (modulo “Plan” in Figura 3.2). Il tra-

sferimento sara diretto quando possibile, altrimenti il file verra recuperato

tramite una catena di opportuni trasferimenti.

La connettivita della rete puo essere rappresentata tramite un multigrafo di-

retto (con archi eventualmente pesati) in cui i nodi rappresentano le macchine

nell’ambiente distribuito e ogni arco indica la possibilita di un trasferimento

diretto. Gli archi possono avere un peso non negativo che indica la preferenza

di alcune connessioni (per motivi tecnologici, economici, ...) rispetto ad altre.

Si rappresenta la rete con un multigrafo poiche fra due nodi un file puo essere

trasferito sia tramite protocolli diversi che, usando lo stesso protocollo, con

modalita diverse (push o pull). Data questa rappresentazione si puo utiliz-

zare l’algoritmo di Dijkstra[24] per rilevare il percorso piu corto (potrebbe

non essere unico) fra sorgente e destinazione. Dato il percorso minimo si crea

una lista ordinata di trasferimenti da eseguire.

Questa macrofunzione si deve occupare anche della gestione del “chunking”

dei file: ogni file viene diviso in uno o piu chunk, la cui dimensione e co-

3.2 Macrofunzioni 19

Source

Node Relay

Node

Destination

NodeRelay

Node

NodeNode

Relay Node

Relay

Computing Site 1

Computing Site 2

Source

Node Relay

Node

Destination

NodeRelay

Node

NodeNode

Relay Node

Relay

Computing Site 1

Computing Site 2

Figura 3.3: Grafo rappresentante una serie di nodi connessi, in alto leconnessioni possibili, in basso un possibile percorso per iltrasferimento del file, gli archi con due frecce rappresenta-no in realta due archi con direzione opposta fra i medesimivertici.

stante tranne al piu l’ultimo. L’impatto di questa scelta sulle prestazioni

verra presentato nella Sezione 5.3.1 . L’utilizzo di questa tecnica permette la

ricezione concorrente di un file da piu fonti nel caso fosse presente su piu nodi.

La dimensione dei chunk in un ambiente (non realistico) in cui i trasferi-

menti avvengono senza alcun tipo di “overhead” o latenza potrebbe essere

arbitrariamente piccola. In questo sistema ogni trasferimento ha overhead

multipli dovuti sia al protocollo di trasferimento che allo scambio di messag-

gi, pertanto la dimensione dei chunk e stata scelta pari a 25 MiB, valore che

rappresenta un buon compromesso sulla base di alcune stime e test prelimi-

nari.

3.2 Macrofunzioni 20

Time

Source

Relay

Destination

Relay

Source

Destination

Figura 3.4: Confronto fra un trasferimento senza e uno con chunking.All’istante iniziale vengono richiesti due file, le frecce chia-re rappresentano i trasferimenti relativi al primo file e quel-le scure quelli relativi al secondo file. Ogni nodo puo ese-guire un solo trasferimento alla volta. Il chunking (in bas-so) permette di ricevere i file in un tempo minore nel casodi relay. L’effetto si amplifica nel caso di relay multipli.

Si noti che il transito per i nodi “relay” genera delle copie del file nel sistema,

inoltre dopo il trasferimento il file non viene eliminato dal nodo di partenza.

Queste copie possono essere eliminate o mantenute; nel secondo caso si ha un

effetto di replicazione: i nodi sono in grado di riconoscere la presenza delle

repliche e le mantengono associate al medesimo identificatore univoco. In

questo caso tutti nodi che possiedono delle repliche saranno coinvolti nelle

successive interazioni riguardo tali file.

L’output di questo modulo consiste in una lista non ordinata di messaggi,

uno per ogni chunk, contenenti la descrizione del percorso che tale file deve

3.2 Macrofunzioni 21

eseguire dalla sorgente alla destinazione, che altro non e che la soluzione in-

dividuata dall’algoritmo di Dijkstra.

L’interfaccia si compone dei seguenti messaggi, ad ogni invocazione il primo

e sempre presente mentre gli ultimi due sono mutuamente esclusivi:

• Route File Request: contiene l’identificatore univoco di un file localiz-

zato e l’indicazione del nodo in cui risiede.

• File Chunk Transfer: contiene l’identificatore di un chunk del file da

trasferire e una rappresentazione del percorso che esso dovra compiere per

raggiungere il nodo che l’ha richiesto. Viene generato un messaggio di

questo tipo per ogni chunk di cui e composto il file.

• Error: se non esiste soluzione al problema del percorso minimo per il

trasferimento o in caso di altri errori questo messaggio conterra una serie

di oggetti serializzati che possono permettere di ispezionare il processo di

instradamento e verificare l’origine dell’errore.

3.2.3 Esecuzione e verifica del trasferimento

Dopo aver determinato il percorso il sistema deve provvedere all’esecuzio-

ne materiale dei trasferimenti. Cio viene eseguito da questa macrofunzione

(“Execute” in Figura 3.2) che opera indipendentemente per ogni richiesta di

trasferimento di un chunk, essa e in grado di esaminare la richiesta, estrarre

ed eseguire eventuali trasferimenti di sua competenza e poi inviare il messag-

gio al nodo cui compete il prossimo trasferimento.

All’interno di questo modulo viene nascosta la complessita introdotta dal-

l’uso di protocolli multipli, infatti al suo interno verranno selezionati i client

adatti ad effettuare ogni tipo di trasferimento richiesto. Si presume che ogni

nodo sia in grado di operare con tutti i protocolli previsti.

3.2 Macrofunzioni 22

Dopo il trasferimento di ogni chunk viene richiesta una verifica: tale verifica

viene eseguita dal nodo di destinazione (o destinazione intermedia) calco-

lando una funzione di “hash” del chunk in questione, questo valore viene

confrontato con un valore fornito durante la fase di pianificazione. In caso

non coincidessero il trasferimento verra ripetuto, eliminando al contempo i

chunk corrotti.

Quando tutti i chunk sono giunti al nodo di destinazione il file viene ricostrui-

to concatenandoli e anche questa operazione viene verificata utilizzando un

“hash”, una volta che il modulo verifica che il file sia integro il trasferimento

puo considerarsi terminato con successo. Soddisfatte queste condizioni il file

in arrivo dovra essere segnalato al richiedente.

L’interfaccia e data dai seguenti messaggi, ad ogni invocazione il primo e

sempre presente mentre gli altri due sono mutuamente esclusivi:

• File Chunk Transfer: contiene l’identificatore di un chunk del file da

trasferire e una rappresentazione del percorso che esso dovra compiere per

raggiungere il nodo che l’ha richiesto.

• File Delivered: contiene l’identificatore univoco del file recuperato, l’in-

dirizzo locale al ricevente in cui il file risiede e l’identificatore globale del

nodo che lo ha richiesto.

• Error: il meccanismo di verifica e ripetizione dei trasferimenti gestisce

buona parte degli errori, quelli non gestiti vengono notificati con que-

sto tipo di messaggio allegando, come negli altri moduli, una serie di

informazioni accessorie.

Capitolo 4

Implementazione

Per implementare il sistema descritto al capitolo precedente si e scelto, come

anticipato, di utilizzare il framework messo a disposizione dal progetto Apa-

che Camel. In tal senso ogni modulo e stato pensato come una composizione

di “Enterprise Integration Pattern”, ovvero una o piu route.

Ogni implementazione verra descritta mostrando con una notazione leggera

e poco formale le route che la compongono. Le route verranno alleggerite

rimuovendo i passaggi relativi alla generazione dei messaggi di “log”.

Non verra spiegato nel dettaglio il funzionamento dei singoli “bean” in quan-

to svolgono funzioni poco piu che banali e nemmeno si scendera nel dettaglio

implementativo delle singole classi in quanto questo richiederebbe una inclu-

sione dell’intero codice sorgente.

Verranno nascosti alcuni dettagli implementativi poiche essi sono poco si-

gnificativi, ad esempio lo schema del database su cui poggia il catalogo o

l’organizzazione del filesystem per salvare i frammenti dei file non verranno

approfonditi in quanto si tratta nel primo caso di banali tabelle di look-up e

nel secondo di arbitrarie generazioni di URI.

Implementazione 24

Organizzazione in moduli

Il sistema e stato implementato con una modularita su due livelli. Il primo

livello di modularita coincide con le macrofunzioni presentate nel Capitolo 3,

ognuna delle quali e a sua volta organizzata in moduli separati, talvolta

chiamati “componenti”. La descrizione di tali moduli verra data nel corso di

questo capitolo, per ogni macrofunzione essi sono:

• Ricerca dei file: Finder e Catalog.

• Pianificazione del trasferimento: Router, Chunker e Mapper

• Esecuzione e verifica del trasferimento: Transfer Manager e File Checker

Considerazioni sulle risorse utilizzate

Durante l’implementazione ci si e dovuti preoccupare dell’utilizzo delle risor-

se da parte del sistema, in particolare si vuole che esso occupi una dimensione

massima (predeterminata) di memoria ed utilizzi un numero massimo (an-

ch’esso predeterminato) di thread.

Il secondo vincolo viene rispettato grazie al fatto che tutte le librerie utilizza-

te, e nello specifico Apache Camel, utilizzano un modello di multithreading

basato su pool di dimensione fissa, pertanto il numero di thread e propor-

zionale al livello di concorrenza massima specificato per ogni route (quando

non specificato le route non prevedono concorrenza).

I limiti di memoria vengono fatti rispettare badando alle strutture dati piu

pesanti, in questo caso si tratta dei messaggi utilizzati internamente da Apa-

che Camel anche per lo scambio di file (e quindi raggiungendo dimensioni

ragguardevoli). Camel permette di limitare il numero di messaggi “in volo”

sia sulle singole route che globalmente, limitando di fatto la numerosita di

tali strutture dati.

4.1 Ricerca dei file 25

Nel Capitolo 5 verra presentato il modo in cui si e verificata la crescita

controllata e limitata delle risorse richieste, anche in situazioni in cui il tasso

di richieste di trasferimento supera quello che il nodo puo sostenere. Una

verifica di questo tipo e necessaria per sistemi che dovranno operare non

supervisionati per un tempo indefinito (ore, giorni, mesi...).

4.1 Ricerca dei file

La ricerca dei file comincia da un nodo, il richiedente, che utilizza un mo-

dulo “Finder” per colloquiare con il modulo “Catalog” degli N nodi di cui e

composto il sistema, compreso lo stesso nodo richiedente.

Finder Catalog

JMS File Located

JMS FileSearchJMS Locate File

File Request

Wait File LocatedTimeout

Got Response

JMS Router

Look Up DB

Found

Not Found

Figura 4.1: Schematizzazione dell’interazione fra due nodi durante laricerca dei file, all’esterno le code JMS, dentro i riquadrile due componenti di ogni nodo che stanno interagendo.

Come si puo notare in Figura 4.1 questa interazione coinvolge quattro code

JMS distinte, di queste, due fanno parte dell’interfaccia esterna, mentre le

altre due - disegnate con bordo tratteggiato - vengono utilizzate solo dalla

macrofunzione di ricerca, e possono essere nascoste agli altri livelli.

Per scelta d’implementazione il messaggio di ricerca del file viene inviato

alla coda solo dopo aver controllato che il file non sia gia presente sul nodo

4.1 Ricerca dei file 26

richiedente, questo per evitare le latenze introdotte dal broker JMS in un

caso la cui risposta puo essere fornita immediatamente.

4.1.1 Finder

Ogni nodo possiede un componente finder. Esso riceve un messaggio conte-

nente l’identificativo di un file da cercare, effettua un controllo su un “header”

che indica la presenza del parametro di timeout e se questo non esiste il ti-

meout viene impostato ad un valore di default. A questo punto il file viene

cercato nel catalogo locale per verificare che non sia gia presente sul nodo, nel

caso venisse trovato il componente scrive un messaggio in una coda apposita

segnalando la consegna del file, altrimenti viene generato un messaggio di

ricerca globale.

JMS RequestFile

Begin Transaction

Check Header Wait

Set Header Wait

CheckLocalRepo

Check Header Found

JMS FileSearch

JMS FileFound

Begin Transaction

Aggregate on UniqueID

Aggregate on UniqueID with Timeout = Wait

Check if instanceof FileTransferMessage

Check Wait > Max

Abort

JMS Error

Timeout Increment

JMS Router

JMS Local

True

False

True

False

Null

Not

Nul

l

Figura 4.2: Finder Route: composizione degli Enterprise IntegrationPattern per l’implementazione del modulo “Finder”. Ilgrafo e stato generato a partire dai sorgenti, e manipolatoper renderlo piu leggibile.

4.1 Ricerca dei file 27

Il messaggio entra in un aggregatore che effettua una correlazione fra messag-

gi di ricerca globale e messaggi di file localizzati, la correlazione viene fatta

su un header contenente un UUID[25]. L’aggregatore e configurato con un

timeout prelevato dall’header del messaggio di ricerca. Nel caso si ricevesse

entro il timeout un messaggio indicante — file localizzato, verrebbe generato

un messaggio di tipo “FileTransferMessage” che verrebbe inviato sulla coda

“Router”, altrimenti una volta raggiunto il timeout il messaggio di ricerca

rimarrebbe invariato e reinviato nella coda per le richieste. Ad ogni iterazio-

ne il timeout viene incrementato esponenzialmente. Solo nel caso il timeout

superasse un tempo critico configurabile la ricerca verrebbe abbandonata se-

gnalando un errore.

I messaggi di localizzazione dei file, ricevuti in risposta al messaggio di ricerca

globale, vengono a loro volta aggregati con un timeout statico in modo da

poter gestire il caso in cui piu nodi contengano il file, il modulo successivo

utilizzera eventualmente queste informazioni per elaborare una strategia di

trasferimento che ne tenga conto.

4.1.2 Catalog

JMS FileAnnounce

Filter StorageElement == Local

ManageFileAnnounce

JMS FileSearch

Filter StorageElement != Local

ManageFileSearch

Filter Found == true

JMS FileFound

Figura 4.3: Catalog: a sinistra gestione dell’aggiunta di un nuovo file,a destra gestione e risposta ad una ricerca globale.

4.2 Pianificazione del trasferimento 28

Il modulo “Catalog” e in grado di gestire due eventi. Alla ricezione di un

messaggio di inserimento di file nel sistema esso lo inserisce, preparando

tutte le informazioni necessarie per utilizzarlo (hash, chunking, etc...). Il

secondo evento e la ricezione di un messaggio di ricerca globale: in questo

caso il modulo ricerca in un database relazionale locale la presenza di quel

file sul nodo in questione. In caso di risposta negativa il messaggio viene

ignorato, altrimenti si genera una risposta positiva e viene inviata nella coda

“FileFound”.

4.2 Pianificazione del trasferimento

La macrofunzione di pianificazione del trasferimento si compone delle fun-

zionalita necessarie a mantenere una rappresentazione sotto forma di grafo

della connettivita dei nodi, inoltre rende possibile tutte le operazioni neces-

sarie per aggiornare, inserire ed estrarre dati utili da tali informazioni.

Router

Mapper

JMS Router

Try Shortest Path

Found

Get Chunk Hash

JMS Chunker

JMS FileTransfer

JMS HeartBeat Send Info

Update Graph

Delay

Not Found

Delay

Set Chunk Hash

Network Graph

Chunker

Figura 4.4: Pianificazione del trasferimento, a sinistra invio e ricezio-ne delle informazioni sulla connettivita, a destra in altoricerca del percorso minimo sul grafo e in basso recuperodei metadati sui chunk.

4.2 Pianificazione del trasferimento 29

4.2.1 Router

A questo modulo arrivano i messaggi riguardo file gia localizzati, esso ha il

compito di ricercare il percorso piu corto fra sorgente e destinazione consul-

tando un grafo che rappresenta le possibili connessioni fra i nodi con archi

pesati. Il peso per ogni arco puo essere assegnato secondo diverse metriche:

massima velocita dell’interfaccia di rete, massima velocita di trasferimento

registrata, una funzione inversa del numero di trasferimenti in corso su quel-

l’arco, etc...

JMS Router

Graph Solver

Check Retry Splitter: split[ body ] Set Next Node

JMS Chunker

Delay DefinitionTrue

False

Figura 4.5: Router: il modulo cerca un percorso sul grafo fra sorgentee destinazione, se non lo trova riprova dopo un lasso ditempo configurabile. Se il cammino esiste viene generatoun messaggio di trasferimento per ogni chunk.

Nel caso non fosse possibile trovare un cammino fra sorgente e destinazione

il messaggio viene ritardato di un periodo scelto in fase di configurazione

e successivamente fatto tornare all’input del modulo. Si presuppone che i

nodi siano sempre in qualche momento raggiungibili pertanto questo modu-

lo non prevede l’annullamento della ricerca. Le informazioni su cui opera

questo modulo, ovvero il grafo, vengono costruite ed aggiornate dal modulo

“Mapper” che verra esposto nella sottosezione 4.2.3

4.2.2 Chunker

Il modulo in questione si occupa di reperire le informazioni necessarie alla

gestione del file suddiviso in chunk e di generare i metadati di controllo rela-

tivi. Le informazioni riguardo l’hash dei singoli chunk risiedono sui soli nodi

4.2 Pianificazione del trasferimento 30

JMS Chunker Add Chunk Hash JMS FileTransferSet First Active Node

Figura 4.6: Chunker: recupera gli hash relativi ai vari frammenti earricchisce il messaggio di quest’informazione.

in possesso di tali frammenti.

Questa operazione viene effettuata generando dei messaggi di trasferimento

dei chunk che vengono inviati ad una apposita coda. Chi ha le informazioni

richieste (uno dei nodi che possiede il file nel suo catalogo) preleva il messag-

gio, lo arricchisce dei dati necessari e reinserisce tale messaggio in una coda

destinata a contenere i trasferimenti da eseguire.

4.2.3 Mapper

JMS HeartBeat

Merge Foreign Graph

timer:mapper

Bean SendNodeInfo Update Graph

JMS HeartBeat

Figura 4.7: Mapper: invio della propria conoscenza sulla topologia direte, ricezione e integrazione della conoscenza degli altrinodi.

Questo modulo si occupa della costruzione del grafo di connettivita dei nodi.

Si compone di un timer che innesca l’invio delle proprie informazioni di stato

(compreso il grafo della rete) ad un topic (architettura publisher subscriber)

al quale sono registrati tutti i nodi, tale componente e l’omonimo topic sono

stati chiamati “HeartBeat”. Il modulo contiene anche una componente che,

una volta ricevuto il messaggio di cui sopra dagli altri nodi, si occupa di

verificare l’eventuale possibilita di connettersi a loro (nel caso offrissero un

accesso tramite qualche protocollo) e di unire il grafo da loro rilevato a quello

locale. Grazie alle informazioni prodotte e consumate da questo modulo tutti

4.3 Esecuzione e verifica del trasferimento 31

i nodi hanno la possibilita di costruire e mantenere costantemente aggiornato

il loro grafo di connettivita.

4.3 Esecuzione e verifica del trasferimento

Questa macrofunzione si occupa di effettuare il trasferimento dei chunk uti-

lizzando uno dei protocolli disponibili fra due nodi connessi. Essa ha an-

che il compito di verificare la correttezza dei singoli trasferimenti nonche di

ricostruire il file dai suoi frammenti quando sono tutti stati ricevuti.

Transfer Manager

File Check

JMS Transfer

Execute Transfer

JMS Verify

Check Hash

Match Fail

Delete ChunkConfirm Transfer

Set Receiver

Figura 4.8: Esecuzione dei trasferimenti: a destra il “Transfer Ma-nager” esegue un trasferimento, a sinistra la componente“File Checker” ne verifica la correttezza.

4.3.1 Transfer Manager

Questa componente riceve un messaggio che descrive il trasferimento di un

frammento di file e il percorso (sul grafo) che il chunk deve compiere. Il mes-

saggio in questione contiene una rappresentazione del percorso come una lista

ordinata di trasferimenti diretti da effettuare fra due nodi, contiene inoltre

l’indicazione di quali siano gia stati effettuati.

Il Transfer Manager riceve un messaggio di richiesta solo quando e parte atti-

va nel processo. Esso preleva il prossimo trasferimento dalla lista, determina

4.3 Esecuzione e verifica del trasferimento 32

se deve fare un “download” o un “upload” e lo effettua. L’implementazione

utilizzata per gestire i trasferimenti e quella della “Chain of Responsibi-

lity”[26] che rende possibile un elevato disaccoppiamento fra il sistema di

gestione dei trasferimenti e le singole implementazioni per i diversi protocolli

facendo in modo che il primo abbia a che fare con una interfaccia che na-

sconde tutti i dettagli di implementazione.

Una volta completato il trasferimento si determina il nodo che dovra effet-

tuare la verifica dell’integrita del frammento, nel caso il trasferimento fosse

un “download” la verifica spetta al nodo stesso, altrimenti la verifica viene

richiesta al nodo che ha ricevuto il chunk.

4.3.2 File Checker

Ricevuto un messaggio di richiesta della verifica questo nodo accede al suo

“filesystem” per verificare che il frammento indicato dal messaggio esista e

sia integro tramite la verifica dell’hash. Se la verifica ha esito positivo il

messaggio viene trasformato in una richiesta di trasferimento dove l’ultimo

passo effettuato viene confermato e inserito nella lista dei trasferimenti gia

eseguiti, altrimenti il trasferimento verra rimesso nella lista dei trasferimenti

da fare in modo che venga ripetuto.

Non e stato previsto alcun meccanismo di prevenzione del deadlock, ad esem-

pio se il disco del nodo ricevente non ha spazio a sufficienza il trasferimento

potrebbe essere tentato indefinitamente. Per ovviare a questo problema sa-

rebbe sufficiente inserire un contatore associato ad ogni tentativo e stabilire

un numero massimo di tentativi. Questo meccanismo andrebbe integrato con

quello di pianificazione in modo da poter elaborare una strategia che tenga

conto anche di questi problemi, ma non e scopo di questa tesi affrontare tale

problema poiche esula dalle ipotesi iniziali sullo scenario.

Capitolo 5

Verifica della robustezza e

valutazione delle prestazioni

In questo capitolo si riportano alcuni dei test effettuati per verificare il corret-

to funzionamento del prototipo realizzato e la sua rispondenza ai requisiti.

I test realmente effettuati sono stati molto piu numerosi, sia sulle singole

componenti che sul sistema globale. Buona parte di essi consiste nel richie-

dere un numero elevato di trasferimenti scegliendo casualmente sorgenti e

destinazioni, in questo tipo di test si possono generare decine di migliaia di

messaggi, linee di log e file in pochi minuti.

5.1 Ambiente di test

Per eseguire il sistema distribuito e verificarne le funzionalita sono stati in-

stallati alcuni nodi su macchine virtuali e su macchine fisiche. Questi nodi

eseguono sistemi operativi diversi fra loro eccetto i due nodi con OS X. Ogni

nodo esegue il programma che e il risultato dell’implementazione del siste-

ma in oggetto alla tesi. E necessario installare e configurare gli ambienti in

modo da poter operare, nello specifico sono necessari dei servizi per la tra-

5.1 Ambiente di test 34

smissione o condivisione dei file e un servizio (centralizzato o distribuito) per

la comunicazione tramite messaggi.

5.1.1 Configurazione dei nodi

Per eseguire dei test sul sistema sono state fornite quattro macchine virtuali

affiancate a due macchine fisiche con le seguenti configurazioni:

• Workstation: iMac 2008 24, Intel Core 2 Duo 2.4 GHz, 4GB RAM, 320

GB SATA Disk, Ethernet 100 Mbps, OS X 10.9

• Notebook: MacBook 2009 13, Intel Core 2 Duo 2.0 GHz, 8GB RAM, 240

GB SATA SSD, Ethernet 1.0 Gbps, OS X 10.9.1

• Research 01: VM, CPU 2 core 3 GHz, 8 GB RAM, 80 GB Disk, VirtIO

Ethernet 10.0 Gbps, Windows 7

• Research 07: VM, CPU 2 core 3 GHz, 2 GB RAM, 25 GB Disk, Gigabit

Ethernet 1.0 Gbps, GNU/Linux Ubuntu 10.04 LTS

• Research 08: VM, CPU 2 core 3 GHz, 2 GB RAM, 8 GB Disk, VirtIO

Ethernet 10.0 Gbps, GNU/Linux Ubuntu 10.04 LTS

• Research 09: VM, CPU 2 core 3 GHz, 2 GB RAM, 25 GB Disk, Ethernet

NIC 100 Mbps, Windows XP

Le macchine virtuali vengono eseguite su un cluster composto dalle seguenti

unita:

• Prox1, Prox2: Dell PowerEdge R715, 2 x Opteron 3.2 GHz 8 core, 64

GB RAM, SAS RAID (solo SO), 4 x Ethernet Gigabit

• Prox3: Dell PowerEdge R515, 2 x Opteron 2.6 GHz 6 core, 16 GB RAM,

SATA RAID (solo SO), 4 x Ethernet Gigabit

5.1 Ambiente di test 35

• Storage3: Supermicro, Xeon E5645, 16 GB RAM, SATA RAID (SO +

share NFS), 4 x Ethernet Gigabit

Le share NFS di Storage3 contengono le immagini dei dischi utilizzati dalle

macchine virtuali che in questo modo possono migrare indifferentemente fra

i tre nodi che compongono il cluster. Il sistema di virtualizzazione utilizzato

e ProxMox VE[27].

5.1.2 Configurazione di ActiveMQ

Il message broker ActiveMQ e necessario per la comunicazione tramite JMS,

per questo specifico software Apache Camel possiede moduli di interfaccia-

mento ottimizzati potendo sfruttare funzionalita non standard, tuttavia que-

sti moduli sono pienamente compatibili con quelli che implementano la co-

municazione standard prevista da JMS. Il broker e stato utilizzato in due

diverse configurazioni:

• Broker Centralizzato: in questa modalita esiste un solo broker nella

rete, raggiungibile da tutti i nodi, che esegue il sistema di gestione dei

messaggi. Esso e configurato per supportare le transazioni e per utilizzare

la persistenza su disco.

• Network of Brokers: ogni nodo del sistema esegue un broker locale

che grazie a Spring Integration viene inizializzato ed eseguito all’avvio del

sistema di gestione dei dati. Questa modalita utilizza il multicast per

creare con gli altri broker in rete una federazione, alcuni parametri quali il

diametro della rete e il time-to-live dei messaggi devono essere impostati

con cura (richiedono una conoscenza sommaria della topologia della rete

in cui verranno utilizzati).

Il sistema di trasferimento dei file e stato utilizzato e testato indifferente-

mente con le due configurazioni, dimostrando performances analoghe a meno

dei tempi aggiuntivi introdotti dal meccanismo di “Store and Forward”[28]

utilizzato dalla configurazione distribuita.

5.2 Robustezza 36

5.1.3 Configurazione FTP e HTTP Server

Alcuni nodi, a seconda della configurazione degli stessi, sono stati configurati

per avere in esecuzione dei server FTP, dei server HTTP o entrambe.

Come server HTTP si e utilizzato Jetty[29], configurato per dare accesso

senza autenticazione a tutti i file contenuti a partire da una determinata

directory radice, esso e stato inserito nel pacchetto software contente il pro-

getto ed e attivabile tramite un parametro da linea di comando. Allo stesso

modo e stato inserito anche un server FTP basato su Apache FtpServer[30].

5.2 Robustezza

Al prototipo realizzato durante questa tesi e richiesto di manifestare un com-

portamento robusto riguardo a chiusure forzate e riavvii sia del software

sviluppato, sia del sistema sottostante. Il sistema deve inoltre dimostrarsi

robusto anche riguardo i problemi di connettivita sia di alto che di basso

livello.

Il primo scenario comprende anche la possibilita di interruzione della forni-

tura elettrica con conseguente arresto dell’esecuzione senza preavviso, ovvero

senza la possibilita di salvare lo stato. La soluzione ad entrambi questi proble-

mi e stata individuata nell’uso delle transazioni e della persistenza, pertanto

questi sono i comportamenti di cui si intende verificare la correttezza.

5.2.1 Monitoraggio del sistema

I trasferimenti durante questo tipo di test sono stati monitorati utilizzando

JMX[31] in combinazione con Jolokia[32] e HawtIO[33], in questo modo tra-

mite una console web si e potuto osservare in tempo reale l’andamento di

5.2 Robustezza 37

alcuni indicatori che riportavano lo stato dei trasferimenti in corso.

In alcune fasi dello sviluppo e in alcuni test si e fatto utilizzo delle tecniche

di “Process Mining”[34] per monitorare il comportamento dell’applicazione

distribuita. Per poter fare uso di questa tecnica i log emessi dai vari nodi

devono essere formattati in modo da poter essere suddivisi per ogni diversa

invocazione del sistema e devono riportare gli eventi in modo uniforme. I log

devono essere inoltre centralizzati ed i loro timestamp allineati ed unificati.

La soluzione adottata prevede l’utilizzo di un server Syslog[35] opportuna-

mente configurato per applicare timestamp con precisione al millisecondo.

Tale server riceve i log da tutti i nodi tramite un appender[36] specifico con-

figurato per produrre i log in formato “CSV”, ovvero con i campi separati

da virgole.

Il software utilizzato e Fluxicon Disco[37] grazie ad una licenza concessa dal

produttore per lo scopo di questa tesi. Esso e stato utilizzato sia per con-

frontare il processo effettivamente rilevato dall’analisi dei log con i workflow

implementati nei vari moduli che per verificare il rispetto dei medesimi an-

che in presenza degli imprevisti summenzionati. Questa tecnica si e rivelata

utile anche nel caso di elevato numero di richieste, circostanza nella quale e

oneroso tener traccia di tutti i trasferimenti senza strumenti di analisi auto-

matizzata. Sono stati inoltre usati gli strumenti di analisi temporale integrati

nel software Fluxicon Disco. In Figura 5.1 si puo vedere un esempio di estra-

zione dei processi in due test, a sinistra uno dei trasferimenti e corrotto e il

chunk relativo viene eliminato e ritrasferito, a destra alcuni dei file richiesti

non vengono trovati entro il timeout stabilito.

Un altro modo per verificare che i trasferimenti siano avvenuti correttamente

e, piu banalmente, quello di verificare la presenza dei file richiesti da ogni

nodo sul suo filesystem locale. Questa modalita fornisce molte meno infor-

5.2 Robustezza 38

File Request

Search

LocatedMatch

Abort

Try Route

OK Route

Split Chunks

Do Transfer

Transfer End

Hash OK

Next Transfer Merge File

Delivered

File Request

Search

LocatedMatch

OK Route

Try Route

Split Chunks

Do Transfer

Transfer End

Hash OK

Next Transfer Merge File

Delivered

Hash Fail

Delete & Retry

Figura 5.1: Process Mining: elaborazione dei log per ricostruire il com-portamento del sistema. La dimensione delle frecce rappre-senta la quantita di eventi che percorrono quell’arco. I dueprocessi rappresentati sono estratti da esecuzioni reali delsistema in cui alcune eventualita non si sono verificate (es.fallimento di “Route”).

mazioni sull’evoluzione del sistema durante il trasferimento ma e ugualmente

prova del corretto funzionamento del sistema.

5.2.2 Interruzioni improvvise

Per testare questo tipo di imprevisto si e fatto terminare il processo cor-

rispondente al sistema realizzato in un momento casuale, successivamente

questo e stato nuovamente eseguito e si e verificato che il trasferimento ve-

nisse effettuato correttamente. Questa procedura e stata effettuata su un

5.2 Robustezza 39

numero arbitrario e casuale di nodi ad ogni verifica.

In questa tesi verra riportata una sola configurazione di test con relativi dati

osservati: essa e quella in cui un trasferimento deve passare attraverso due

nodi relay. Dal nodo destinazione sono stati richiesti 100 trasferimenti, con

un tasso di una richiesta al secondo, e si e verificato che tutti i trasferimenti

terminassero correttamente.

Nella Figura 5.2 si riporta l’andamento dell’attivita su ogni nodo, stimata dal

numero di messaggi di log per unita di tempo. In alto c’e il nodo sorgente,

seguono i due relay, il quarto e il nodo destinazione. L’ultimo grafico rappre-

senta l’attivita globale. Si puo notare un leggero disallineamento dei grafici

dovuto al fatto che gli istanti di inizio e fine attivita dei vari nodi sono diver-

si, il che porta ad un leggero cambio di scala orizzontale (non modificabile

nel software utilizzato) che si e cercato di compensare con una traslazione

durante la manipolazione grafica dell’output.

Source

Relay 1

Relay 2

Destination

Global

Figura 5.2: Attivita durante il test di interruzione, dall’alto verso ilbasso: sorgente, due relay, destinazione e andamento glo-bale. Stima effettuata in base al numero di messaggi di lognell’unita di tempo.

5.2 Robustezza 40

5.2.3 Problemi di rete

Un modo efficace per simulare eventuali problemi di rete e quello di utilizzare

un firewall e modificarne le regole per permettere o impedire la comunica-

zione ad un certo nodo. Tale scenario e simile a quello delle interruzioni

improvvise salvo il fatto che si vuole testare la correttezza dei meccanismi di

timeout. Nella configurazione distribuita del message broker si vuole inoltre

verificare che i messaggi vengano effettivamente inoltrati una volta ristabilita

la connessione di rete.

Source

Relay 1

Relay 2

Destination

A B C

D E

F

Global

Trasferimenti Attivi

Figura 5.3: Test di interruzione delle comunicazioni di rete dei varinodi. Le frecce demarcano gli istanti in cui la condizionidi connettivita subiscono variazioni. “Trasferimenti Atti-vi” rappresenta il numero di trasferimenti in corso (ovverorichiesti e non ancora completati).

In Figura 5.3 si puo vedere un test (come nel test precedente si tratta di

100 trasferimenti con due relay) in cui si agisce sui due relay per simulare

una perdita di connettivita. Inizialmente vengono interdette tutte le comu-

nicazioni di rete al primo relay (A). In seguito viene prima ripristinata la

comunicazione con la coda (B) e, successivamente, anche con il resto dei no-

di (C). Dopo un certo intervallo di tempo viene scollegato il secondo relay

5.2 Robustezza 41

(D), gli effetti di questa operazione si vedono sul nodo destinazione che non

ha piu attivita di download da quel nodo. L’attivita riprende non appena si

ripristina la connessione (E).

In basso nella figura si riporta la quantita delle richieste di trasferimento at-

tive nel tempo. Si noti che il tasso di completamento (grossomodo indicato

dalla pendenza della curva) aumenta sotto una certa soglia rivelando un ef-

fetto di saturazione quando i trasferimenti contemporaneamente attivi sullo

stesso percorso superano un numero critico (in questo circa pari a 60).

E stato testato anche il caso in cui la topologia della rete cambiasse: in tale

caso si chiedeva al sistema di adeguarsi senza vincoli sul tempo impiegato.

L’unico modo per verificare che cio accadesse era quello di visualizzare, nodo

per nodo, il grafo rilevato dal componente “Mapper”. Come si puo vedere in

Figura 5.4 l’aggiornamento del grafo avviene correttamente.

Workstation

Research08

push

Research01

Research07

pushpull

pull

pull

push

Workstation

Research01

pull

Research07

pull

Research08

pull pushpush pull

pull

pull

push

Figura 5.4: Verifica dell’aggiornamento del grafo di connettivita inseguito ad una modifica della topologia di rete: il nodo“Workstation” ha un malfuzionamento del server HTTP,gli archi “pull” uscenti da “Workstation” vengono rimossi.

5.3 Prestazioni 42

Nell’esempio in Figura 5.4: il nodo “Workstation” inizialmente ha un server

HTTP in esecuzione, in seguito il server non e piu disponibile e il grafo viene

aggiornato. L’aggiornamento delle informazioni ha una frequenza configura-

bile. La figura e stata generata direttamente dal sistema realizzato grazie

ad una funzionalita della libreria per la gestione dei grafi che permette di

esportare la struttura dati nel formato DOT[38].

Nel caso alcuni trasferimenti in corso dovessero utilizzare un collegamento

non piu disponibile il sistema rimane in attesa, se il collegamento viene ripri-

stinato il trasferimento continuera altrimenti, dopo un lasso di tempo configu-

rabile, il sistema richiedera un nuovo trasferimento. Grazie all’idempotenza

dei trasferimenti non sara necessario annullare il precedente trasferimento.

5.3 Prestazioni

Una figura di merito investigata e quella delle prestazioni: in questo caso

tempi e velocita di trasferimento. Benche non ci fossero requisiti minimi su

tali valori si e voluto comunque misurarli. Ci si e da subito confrontati con

la possibilita di scegliere se misurare le singole velocita di trasferimento tra

i vari nodi oppure se aggregare i tempi di comunicazione ed elaborazione

introdotti dal sistema sviluppato.

Si e deciso di calcolare la velocita di trasferimento nel secondo modo, uti-

lizzando come tempo di inizio e fine trasferimento i timestamp relativi al

messaggio di richiesta di trasferimento e al messaggio di notifica di avvenuto

trasferimento. In tale scenario anche nel caso in cui non ci si appoggiasse

ad un relay le velocita rilevate saranno comunque sensibilmente inferiori a

quelle massime teoriche.

5.3 Prestazioni 43

5.3.1 Chunking e impatto dei relay

Si vuole verificare che il vantaggio introdotto dal chunking nei trasferimenti

che coinvolgono uno o piu nodi relay sia reale e quale sia la sua entita. Per

fare cio sono stati effettuati trasferimenti diretti, con un relay e con due

relay. Il file trasferito ha una dimensione di 218 MiB, il chunking viene

effettuato con frammenti di 25 MiB, dando luogo ad una ripartizione in 9

parti. Tutti trasferimenti sono stati ripetuti venti volte. La Figura 5.5 riporta

graficamente i risultati medi ottenuti mentre nella Tabella 5.1 si riportano

valori medi e deviazione standard rilevati.

1

2

3

4

5

6

7

Senza chunking

Con chunking

Diretto 1 Relay 2 Relay

Speed MiB/s

Figura 5.5: Differenze nella velocita di trasferimento senza e con chun-king. A scapito di una leggera perdita nei trasferimen-ti diretti il chunking permette guadagni in velocita neitrasferimenti con relay.

Nel caso di trasferimenti senza l’uso del chunking il trasferimento diretto po-

trebbe essere vantaggioso, tuttavia questo test non rende conto dei vantaggi

introdotti dal chunking nel caso in cui un trasferimento dovesse essere ripe-

tuto in seguito ad un evento imprevisto (corruzione del file, crash del nodo).

In tal caso con il chunking attivato si dovra ritrasferire un solo chunk invece

che il file intero.

5.3 Prestazioni 44

ConfigurazioneDiretta Un Relay Due Relay

Senza chunkingAvg 6.77 3.96 2.23

StdDev 0.64 0.20 0.13

Con chunkingAvg 5.71 5.07 4.15

StdDev 0.18 0.22 0.16

Tabella 5.1: Velocita di trasferimento rilevate, tutti i valori sono inMiB/s.

5.3.2 Thread e memoria occupata.

Per verificare che il sistema avesse alcune delle proprieta desiderabili per po-

ter rimanere in esecuzione per un tempo indeterminato sono state osservate

e verificate le seguenti caratteristiche: la crescita limitata della memoria uti-

lizzata, del numero di thread e il rilascio di queste risorse al termine delle

operazioni di trasferimento.

La verifica di queste proprieta e stata effettuata tramite l’utilizzo di JCon-

sole[39], un tool compreso nell’ambiente di sviluppo Java 7. Tramite l’uso

di JMX il tool offre una funzionalita in grado di visualizzare la sintesi delle

risorse utilizzate. In questa tesi ci si e concentrati sulla schermata in cui

vengono riportati i valori di Heap Memory utilizzata, il numero di thread

esistenti (sia attivi che inattivi), l’utilizzo della CPU ed il numero di classi

caricate (questo valore non e stato oggetto di analisi).

In Figura 5.6 sono stati eseguiti tre trasferimenti, aspettando che ognuno

terminasse prima di richiedere il successivo. I trasferimenti sono in corri-

spondenza delle tre zone non mascherate nella figura e si possono distinguere

dall’aumento di utilizzo del processore. Si puo vedere che il numero di thread

cresce leggermente durante i trasferimenti ma successivamente diminuisce,

rivelando che le risorse vengono correttamente rilasciate. Per la memoria

valgono considerazioni analoghe.

5.3 Prestazioni 45

Figura 5.6: Risorse impegnate dal sistema: la maschera evidenzia tretrasferimenti, le risorse impegnate vengono rilasciate.

Figura 5.7: Dieci trasferimenti contemporanei, il sistema limita itrasferimenti contemporanei a tre.

5.3 Prestazioni 46

Nella Figura 5.7 viene eseguita una rilevazione analoga ma aumentando il ca-

rico del sistema. Vengono richiesti 10 trasferimenti contemporaneamente: si

nota un plateau nell’aumento del numero di thread e una conseguente dimi-

nuzione degli stessi alla fine dei trasferimenti. Alla fine di questo test tramite

JMX e stata effettuata la Garbage Collection per verificare che la memoria

utilizzata si riportasse ai livelli di partenza. Questa verifica ha avuto successo.

Per riferimento si riporta in Figura 5.8 un comportamento anomalo ottenuto

durante le prime verifiche in fase di implementazione: in questo caso alcuni

thread inerenti la comunicazione FTP rimanevano attivi poiche la libreria

prevedeva il loro riutilizzo risparmiando sui tempi di connessione e login al

server remoto. Questa funzionalita non veniva sfruttata portando alla crea-

zione di un nuovo thread ad ogni richiesta. Come si puo osservare i thread

crescono linearmente, portando in breve tempo alla saturazione delle risorse

sia sul nodo in esame che sul server FTP.

Figura 5.8: Esempio di mancato rilascio delle risorse.

Capitolo 6

Conclusioni

La realizzazione di un prototipo del sistema richiesto e stata completata ed

il suo funzionamento e stato verificato con una moltitudine di configurazio-

ni delle quali in questo documento sono state riportate solo quelle ritenute

piu significative. Gli obiettivi iniziali sono stati soddisfatti sia in termini

di funzionalita che di robustezza, purtroppo il tempo a disposizione non ha

permesso di focalizzare l’attenzione sulla ricerca di performance elevate, esse

comunque risultano adeguate.

Il lavoro di tesi si e protratto per circa cinque mesi buona parte dei quali

dedicati alla progettazione e implementazione. Il prototipo realizzato - per

darne una quantificazione numerica - consiste in circa mille righe di docu-

menti XML piu altre sei mila di codice Java. Il codice e stato distribuito

in 20 packages contenenti un totale di 82 classi. Con tale organizzazione

del codice si e cercato di osservare alcune prassi consolidate sulla stesura di

codice leggibile e manutenibile[40].

A livello soggettivo l’esperienza e stata altamente positiva, l’ambiente di Ri-

cerca e Sviluppo e l’ideale per venire a contatto con idee innovative (ma anche

con metodologie piu affermate) riguardo lo sviluppo software, rappresentan-

Conclusioni 48

do un ulteriore avanzamento nella formazione personale e professionale. La

liberta data in fase di progettazione ed implementazione ha portato ad un

elevato grado di soddisfazione (ed affezione) riguardo il prototipo realizzato

ed ha fornito la motivazione per uno studio approfondito ed accurato delle

tecnologie coinvolte nella realizzazione.

Il prototipo realizzato e completamente disgiunto dai prodotti commerciali

di Esteco S.p.A. e al momento della stesura di questa tesi e visto come un

prodotto della ricerca teso a valutare sia la fattibilita di un tale sistema sia

il possibile impatto delle conoscenze acquisite sulle tecnologie utilizzate in

ambiti diversi da quello di questa tesi.

Bibliografia

[1] G. Hohpe e B. Woolf, Enterprise Integration Patterns: Designing,

Building, and Deploying Messaging Solutions. Boston, MA, USA:

Addison-Wesley Longman Publishing Co. Inc., 2003.

[2] Oracle, Java(TM) Platform, Standard Edition 7 API Specification.

indirizzo: http://docs.oracle.com/javase/7/docs/api/.

[3] The Apache Software Foundation, ActiveMQ 5.9.0 API. indirizzo:

http://activemq.apache.org/maven/5.9.0/apidocs/index.html.

[4] T. Kosar e M. Livny, “Stork: making data placement a first class ci-

tizen in the grid”, in Proceedings of the 24th International Conference

on Distributed Computing Systems (ICDCS’04), ser. ICDCS ’04, Wa-

shington, DC, USA: IEEE Computer Society, 2004, pp. 342–349. in-

dirizzo: http://research.cs.wisc.edu/htcondor/doc/stork-

icdcs2004.pdf.

[5] B. Cohen, The bittorrent protocol specification, ott. 2013. indirizzo:

http://www.bittorrent.org/beps/bep_0003.html.

[6] The Apache Software Foundation, Apache Hadoop 2.2.0. indirizzo:

http://hadoop.apache.org/docs/r2.2.0/.

[7] J. Rehn, “Phedex high-throughput data transfer management system”,

in Proceedings of CHEP06, Mumbai, India, 2006.

BIBLIOGRAFIA 50

[8] J. Dean e S. Ghemawat, “Mapreduce: simplified data processing on

large clusters”, in Proceedings of the 6th Conference on Symposium on

Opearting Systems Design & Implementation - Volume 6, ser. OSDI’04,

San Francisco, CA: USENIX Association, 2004, pp. 10–10.

[9] T. White, Hadoop: The Definitive Guide, 1st. 2009, pp. 241–241.

[10] K. Birman e T. Joseph, “Exploiting virtual synchrony in distributed

systems”, SIGOPS Oper. Syst. Rev., vol. 21, n. 5, pp. 123–138, nov.

1987.

[11] G. Hohpe, Programming without a call stack event-driven architectures,

2006. indirizzo: http://eaipatterns.com/docs/EDA.pdf.

[12] O. Etzion, “Towards an event-driven architecture: an infrastructure for

event processing position paper”, in Proceedings of the First Internatio-

nal Conference on Rules and Rule Markup Languages for the Semantic

Web, ser. RuleML’05, Galway, Ireland: Springer-Verlag, 2005, pp. 1–7.

[13] G. Muhl, L. Fiege e P. Pietzuch, Distributed Event-Based Systems.

Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2006.

[14] L. Jellema e L. Dikmans, Oracle SOA Suite 11G Handbook, 1a ed. New

York, NY, USA: McGraw-Hill, Inc., 2010, pp. 271–300.

[15] M. Fisher, J. Partner, M. Bogoevici e I. Fuld, Spring Integration In

Action. Shelter island, NY: Manning, 2012.

[16] M. Fisher, M. Bogoevici, I. Fuld et al., Spring integration reference

manual. indirizzo: http://docs.spring.io/spring-integration/

docs/3.0.0.RELEASE/reference/html/.

[17] MuleSoft Inc., Mule documentation. indirizzo: http://www.mulesoft.

org/documentation/display/current/Home.

[18] C. Ibsen e J. Anstey, Camel in Action, 1st. Greenwich, CT, USA:

Manning Publications Co., 2010.

BIBLIOGRAFIA 51

[19] The Apache Software Foundation, Apache camel documentation.

indirizzo: http://camel.apache.org/documentation.html.

[20] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler e F. Yergeau,

Extensible markup language (xml) 1.0 (fifth edition), World Wide Web

Consortium, Recommendation REC-xml-20081126, 2008.

[21] M. Fowler. (gen. 2004). Inversion of Control Containers and the De-

pendency Injection pattern, indirizzo: http://martinfowler.com/

articles/injection.html.

[22] T. Mueller, H2 database engine. indirizzo: http://www.h2database.

com/html/main.html.

[23] D. Crockford, “The application/json media type for javascript object

notation (json)”, IETF, RFC 4627, lug. 2006.

[24] E. W. Dijkstra, “A note on two problems in connexion with graphs”,

NUMERISCHE MATHEMATIK, vol. 1, n. 1, pp. 269–271, 1959.

[25] P. Leach, M. Mealling e R. Salz. (2005). Rfc 4122: a universally unique

identifier (uuid) urn namespace, indirizzo: http://www.ietf.org/

rfc/rfc4122.txt.

[26] E. Gamma, R. Helm, R. Johnson e J. Vlissides, Design Patterns:

Elements of Reusable Object-oriented Software. Boston, MA, USA:

Addison-Wesley Longman Publishing Co., Inc., 1995.

[27] Proxmox Server Solutions GmbH, Proxmox virtual environment.

indirizzo: http://www.proxmox.com/.

[28] The Apache Software Foundation, �using apache activemq - how do

distributed queues work�. indirizzo: http://activemq.apache.org/

how-do-distributed-queues-work.html.

[29] Intalio, Inc., Jetty : the definitive reference. indirizzo: http://www.

eclipse.org/jetty/documentation/current/.

BIBLIOGRAFIA 52

[30] The Apache Software Foundation, The apache ftpserver documenta-

tion. indirizzo: http : / / mina . apache . org / ftpserver - project /

documentation.html.

[31] Oracle Corporation, Jsr 3: javatm management extensions (jmxtm)

specification. indirizzo: https://www.jcp.org/en/jsr/detail?id=3.

[32] R. Huß, Jolokia - reference documentation. indirizzo: http://www.

jolokia.org/reference/html/index.html.

[33] R. H. Inc., Hawtio documentation. indirizzo: http : / / hawt . io /

configuration/index.html.

[34] W. M. P. v. d. Aalst, A. Adriansyah, A. K. A. d. Medeiros et al.,

“Process mining manifesto”, in BPM 2011 Workshops, Part I, vol. 99,

Springer-Verlag, 2012, pp. 169–194. indirizzo: http://www.win.tue.

nl/ieeetfpm/doku.php?id=shared:process_mining_manifesto.

[35] C. Lonvick, The bsd syslog protocol, United States, 2001.

[36] The Apache Software Foundation, Class syslogappender - javadoc api.

indirizzo: http://logging.apache.org/log4j/1.2/apidocs/org/

apache/log4j/net/SyslogAppender.html.

[37] ——, Class syslogappender - javadoc api. indirizzo: http://logging.

apache . org / log4j / 1 . 2 / apidocs / org / apache / log4j / net /

SyslogAppender.html.

[38] The Graphviz Open Source Team, Graphviz - The DOT Language.

indirizzo: http://www.graphviz.org/doc/info/lang.html.

[39] Oracle Corporation, The JConsole Java Management Extensions

(JMX) compliant monitoring tool. indirizzo: http://docs.oracle.

com/javase/7/docs/technotes/guides/management/jconsole.

html.

BIBLIOGRAFIA 53

[40] R. C. Martin, Clean Code: A Handbook of Agile Software Craftsman-

ship, 1a ed. Upper Saddle River, NJ, USA: Prentice Hall PTR,

2008.