SlideShare una empresa de Scribd logo

Tesi: Progetto e realizzazione di un sistema robusto di gestione dei dati per ambienti di esecuzione distribuita.

•
•
Paolo Morandini
Paolo Morandini

Progetto e realizzazione di un sistema robusto di gestione dei dati per ambienti di esecuzione distribuita.

Tecnología
1 de 61
Descargar para leer sin conexión
Universit`a degli Studi di Trieste Dipartimento di Ingegneria e Architettura Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea in Programmazione Distribuita Progetto e realizzazione di un sistema robusto di gestione dei dati 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’unit`a centrale. Tipicamente ognuna di queste elaborazioni richiede uno o pi`u file in ingresso e produce uno o pi`u file in uscita, nasce cos`ı la necessit`a 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 pi`u 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 volont`a 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 volont`a si ritiene utile uno studio riguardo l’opportunit`a 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 transazionalit`a e persistenza e delle librerie che forniscono tali funzionalit`a. 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 dar`a una breve descrizione occasionalmente accom- pagnata da considerazioni sul loro funzionamento. Nel capitolo successivo si dar`a spazio all’analisi che ha preceduto il lavoro di progettazione, verr`a delineato lo scenario tipico in cui si vuole lavorare, si analizzeranno obiettivi e vincoli tecnologici. Il capitolo sulla progettazione definir`a l’interfaccia del sistema realizzato e la suddivisione in moduli che `e stata eseguita, per ogni modulo verr`a definita una interfaccia. In seguito si scender`a 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 Attivit`a sui vari nodi durante il crash test . . . . . . . . . . . 39
5.3 Attivit`a sui vari nodi durante il test di interruzione delle co- municazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.4 Test modifica della topologia . . . . . . . . . . . . . . . . . . . 41 5.5 Comparazione velocit`a 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 Velocit`a 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 pi`u 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 necessit`a di gestire tali dati. Necessit`a degli ambienti di esecuzione distribuita In un ambiente di esecuzione distribuita ogni nodo esegue un programma il quale pu`o aver bisogno di determinati file di input ed eventualmente produce uno o pi`u file di output. Una esecuzione pu`o 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 pi`u altre esecuzioni, si veda ad esempio la Figura 1.1. La pianificazione delle esecuzioni e dei trasferimenti ha uguale importanza poich´e nessuna elaborazione pu`o 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 EM Analysis Turbulence Analysis Figura 1.1: Esempio di esecuzione distribuita, a partire da alcuni pa- rametri un nodo crea un modello sul quale altri nodi eseguiranno 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 pu`o essere pianificata a priori conoscendo tutte le risorse dispo- nibili cercando la loro allocazione pi`u efficiente. Si noti che il tipo di connessione di cui parliamo non `e da intendersi come connessione fisica ma piuttosto come possibilit`a di utilizzare un protocollo di trasferimento file fra due nodi, il termine “connessione” verr`a utilizzato con questo significato ovunque non diversamente specificato, quando si far`a riferimento alla “topologia” della rete si intender`a 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 verr`a definito il modo in cui un nodo pu`o 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 dovr`a 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 pi`u 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 ha prodotto un file, il nodo in basso a destra ha bisogno di quel file senza sapere chi l’ha generato o quando verr`a 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 funzionalit`a 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 gi`a 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 due nodi intermedi. k `e il livello di concorrenza. Immagine tratta 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 pu`o 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 poich`e 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 modalit`a peer-to-peer pur mantenendo la necessit`a di uno (o pi`u) 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) pu`o 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 criticit`a 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 poggiano su 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 pu`o 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 pi`u 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 funzionalit`a 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. Necessit`a di sviluppare un sistema dedicato Il sistema sviluppato in questa tesi richiede alcune funzionalit`a presenti in uno o pi`u 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 dovr`a na- scondere la complessit`a legata alle modalit`a con cui il nodo `e inserito nella rete, ai protocolli che esso utilizza ed alla necessit`a o meno di usare relay (anche multipli) per ottenere il trasferimento dei file. • Verifica dei trasferimenti: ogni trasferimento dovr`a 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 • Atomicit`a 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 gi`a 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 n´e 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 andr`a a realizzare consiste in una fase iniziale in cui sono stati raccolti alcuni dati riguardo il “setup” tipico dell’ambiente in cui si dovr`a operare, una lista di funzionalit`a 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 qualit`a dei nodi, potreb- bero essere elaboratori per “High Performance Computing” come essere dei personal computer con limitate capacit`a 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. • Quantit`a dei nodi: il numero di nodi coinvolti nel sistema pu`o variare da alcune unit`a 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. • Portabilit`a: 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 modalit`a. • 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 pi`u 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 quantit`a predicibile di risorse: `e importante che il sistema che verr`a realizzato impegni una quantit`a 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 libert`a 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 portabilit`a, 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 dovr`a 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’attivit`a 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 permetter`a 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 verr`a 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 possibilit`a 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, nonch´e l’esecuzione del DBMS H2[22] con relativa web console. Spring ha permesso anche l’uso di alcune tecnologie di monitoraggio alle quali si accenner`a 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 pu`o includere informa- zioni aggiuntive generate dai sottosistemi (utilizzabili per identificare pi`u dettagliatamente l’errore occorso). Per aumentare la leggibilit`a 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 funzionalit`a 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 funzionalit`a 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 External Interface 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 rispettivamente di fare da collante fra i vari sottomoduli e implementare l’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 risponder`a 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’eventualit`a che il file non fosse localizzabile (perch´e non esi- ste o perch´e 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 modalit`a con cui effettuare il suo trasferimento (modulo “Plan” in Figura 3.2). Il tra- sferimento sar`a diretto quando possibile, altrimenti il file verr`a recuperato tramite una catena di opportuni trasferimenti. La connettivit`a della rete pu´o 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 possibilit`a 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 poich´e fra due nodi un file pu`o essere trasferito sia tramite protocolli diversi che, usando lo stesso protocollo, con modalit`a diverse (push o pull). Data questa rappresentazione si pu`o utiliz- zare l’algoritmo di Dijkstra[24] per rilevare il percorso pi`u 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 pi`u 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 le connessioni possibili, in basso un possibile percorso per il trasferimento del file, gli archi con due frecce rappresenta- no in realt`a due archi con direzione opposta fra i medesimi vertici. stante tranne al pi`u l’ultimo. L’impatto di questa scelta sulle prestazioni verr`a presentato nella Sezione 5.3.1 . L’utilizzo di questa tecnica permette la ricezione concorrente di un file da pi`u fonti nel caso fosse presente su pi`u 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 pu`o ese- guire un solo trasferimento alla volta. Il chunking (in bas- so) permette di ricevere i file in un tempo minore nel caso di 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 dovr`a 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 conterr`a 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. Ci`o 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 complessit`a 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 verr`a 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 pu`o considerarsi terminato con successo. Soddisfatte queste condizioni il file in arrivo dovr`a 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 dovr`a 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 pi`u route. Ogni implementazione verr`a 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 verr`a spiegato nel dettaglio il funzionamento dei singoli “bean” in quan- to svolgono funzioni poco pi`u che banali e nemmeno si scender`a nel dettaglio implementativo delle singole classi in quanto questo richiederebbe una inclu- sione dell’intero codice sorgente. Verranno nascosti alcuni dettagli implementativi poich´e 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 modularit`a su due livelli. Il primo livello di modularit`a 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 verr`a 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 pi`u 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 numerosit`a di tali strutture dati.
4.1 Ricerca dei file 25 Nel Capitolo 5 verr`a 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 pu`o 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 la ricerca dei file, all’esterno le code JMS, dentro i riquadri le due componenti di ogni nodo che stanno interagendo. Come si pu`o 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 gi`a 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 pu`o 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 gi`a 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 NotNull Figura 4.2: Finder Route: composizione degli Enterprise Integration Pattern per l’implementazione del modulo “Finder”. Il grafo `e stato generato a partire dai sorgenti, e manipolato per renderlo pi`u 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 pi`u nodi contengano il file, il modulo successivo utilizzer`a 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- zionalit`a necessarie a mantenere una rappresentazione sotto forma di grafo della connettivit`a 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 connettivit`a, a destra in alto ricerca del percorso minimo sul grafo e in basso recupero dei metadati sui chunk.
4.2 Pianificazione del trasferimento 29 4.2.1 Router A questo modulo arrivano i messaggi riguardo file gi`a localizzati, esso ha il compito di ricercare il percorso pi`u 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 pu`o essere assegnato secondo diverse metriche: massima velocit`a dell’interfaccia di rete, massima velocit`a 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 Definition True False Figura 4.5: Router: il modulo cerca un percorso sul grafo fra sorgente e destinazione, se non lo trova riprova dopo un lasso di tempo configurabile. Se il cammino esiste viene generato un 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 verr`a 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 e arricchisce 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 di rete, ricezione e integrazione della conoscenza degli altri nodi. Questo modulo si occupa della costruzione del grafo di connettivit`a 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 possibilit`a 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 possibilit`a di costruire e mantenere costantemente aggiornato il loro grafo di connettivit`a. 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 nonch´e 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 gi`a 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 dovr`a effet- tuare la verifica dell’integrit`a 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 gi`a eseguiti, altrimenti il trasferimento verr`a 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 poich`e 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 pi`u 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 funzionalit`a 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 unit`a: • 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 funzionalit`a 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 modalit`a 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 modalit`a 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 connettivit`a sia di alto che di basso livello. Il primo scenario comprende anche la possibilit`a di interruzione della forni- tura elettrica con conseguente arresto dell’esecuzione senza preavviso, ovvero senza la possibilit`a 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 pu`o 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, pi`u banalmente, quello di verificare la presenza dei file richiesti da ogni nodo sul suo filesystem locale. Questa modalit`a 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 quantit`a di eventi che percorrono quell’arco. I due processi rappresentati sono estratti da esecuzioni reali del sistema in cui alcune eventualit`a 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 verr`a 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’attivit`a su ogni nodo, stimata dal numero di messaggi di log per unit`a 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’attivit`a globale. Si pu`o notare un leggero disallineamento dei grafici dovuto al fatto che gli istanti di inizio e fine attivit`a 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: Attivit`a durante il test di interruzione, dall’alto verso il basso: sorgente, due relay, destinazione e andamento glo- bale. Stima effettuata in base al numero di messaggi di log nell’unit`a 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 vari nodi. Le frecce demarcano gli istanti in cui la condizioni di connettivit`a subiscono variazioni. “Trasferimenti Atti- vi” rappresenta il numero di trasferimenti in corso (ovvero richiesti e non ancora completati). In Figura 5.3 si pu`o 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 connettivit`a. 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 pi`u attivit`a di download da quel nodo. L’attivit`a riprende non appena si ripristina la connessione (E). In basso nella figura si riporta la quantit`a 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 ci`o accadesse era quello di visualizzare, nodo per nodo, il grafo rilevato dal componente “Mapper”. Come si pu`o 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 connettivit`a in seguito 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 pi`u 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 funzionalit`a 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 pi`u disponibile il sistema rimane in attesa, se il collegamento viene ripri- stinato il trasferimento continuer`a altrimenti, dopo un lasso di tempo configu- rabile, il sistema richieder`a un nuovo trasferimento. Grazie all’idempotenza dei trasferimenti non sar`a necessario annullare il precedente trasferimento. 5.3 Prestazioni Una figura di merito investigata `e quella delle prestazioni: in questo caso tempi e velocit`a di trasferimento. Bench`e non ci fossero requisiti minimi su tali valori si `e voluto comunque misurarli. Ci si `e da subito confrontati con la possibilit`a di scegliere se misurare le singole velocit`a 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 velocit`a 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 velocit`a 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 pi`u nodi relay sia reale e quale sia la sua entit`a. Per fare ci`o 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 velocit`a di trasferimento senza e con chun- king. A scapito di una leggera perdita nei trasferimen- ti diretti il chunking permette guadagni in velocit`a nei trasferimenti 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 dovr`a ritrasferire un solo chunk invece che il file intero.
5.3 Prestazioni 44 Configurazione Diretta Un Relay Due Relay Senza chunking Avg 6.77 3.96 2.23 StdDev 0.64 0.20 0.13 Con chunking Avg 5.71 5.07 4.15 StdDev 0.18 0.22 0.16 Tabella 5.1: Velocit`a di trasferimento rilevate, tutti i valori sono in MiB/s. 5.3.2 Thread e memoria occupata. Per verificare che il sistema avesse alcune delle propriet`a 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 propriet`a `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 funzionalit`a 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 pu`o 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 tre trasferimenti, le risorse impegnate vengono rilasciate. Figura 5.7: Dieci trasferimenti contemporanei, il sistema limita i trasferimenti 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 poich´e la libreria prevedeva il loro riutilizzo risparmiando sui tempi di connessione e login al server remoto. Questa funzionalit`a non veniva sfruttata portando alla crea- zione di un nuovo thread ad ogni richiesta. Come si pu`o 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 pi`u significative. Gli obiettivi iniziali sono stati soddisfatti sia in termini di funzionalit`a 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 pi`u 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 pi`u affermate) riguardo lo sviluppo software, rappresentan-
Conclusioni 48 do un ulteriore avanzamento nella formazione personale e professionale. La libert`a 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 fattibilit`a 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. M¨uhl, 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.

Recomendados

PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...
PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...
PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...Alex Ronci
 
Realizzazione di una base di dati per la gestione delle valutazioni di proget...
Realizzazione di una base di dati per la gestione delle valutazioni di proget...Realizzazione di una base di dati per la gestione delle valutazioni di proget...
Realizzazione di una base di dati per la gestione delle valutazioni di proget...Efrem Venturuzzo
 
Tesina di fine seminario sas ed sql
Tesina di fine seminario sas ed sqlTesina di fine seminario sas ed sql
Tesina di fine seminario sas ed sqlMarco D'Alessandro
 
Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...
Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...
Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...Filippo Muscolino
 
Relazione Agic
Relazione AgicRelazione Agic
Relazione Agicguestc09d24
 
AreaMVC: un'architettura software basata sulla semplicità
AreaMVC: un'architettura software basata sulla semplicitàAreaMVC: un'architettura software basata sulla semplicità
AreaMVC: un'architettura software basata sulla semplicitàGiulio Destri
 
Database Data Aggregator
Database Data AggregatorDatabase Data Aggregator
Database Data AggregatorDavide Ciambelli
 
Tesi_Adamou
Tesi_AdamouTesi_Adamou
Tesi_Adamoututorialsruby
 

Recomendados

PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...
PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...
PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...Alex Ronci
 
Realizzazione di una base di dati per la gestione delle valutazioni di proget...
Realizzazione di una base di dati per la gestione delle valutazioni di proget...Realizzazione di una base di dati per la gestione delle valutazioni di proget...
Realizzazione di una base di dati per la gestione delle valutazioni di proget...Efrem Venturuzzo
 
Tesina di fine seminario sas ed sql
Tesina di fine seminario sas ed sqlTesina di fine seminario sas ed sql
Tesina di fine seminario sas ed sqlMarco D'Alessandro
 
Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...
Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...
Analisi e sviluppo di un sistema collaborativo simultaneo per la modifica di ...Filippo Muscolino
 
Relazione Agic
Relazione AgicRelazione Agic
Relazione Agicguestc09d24
 
AreaMVC: un'architettura software basata sulla semplicità
AreaMVC: un'architettura software basata sulla semplicitàAreaMVC: un'architettura software basata sulla semplicità
AreaMVC: un'architettura software basata sulla semplicitàGiulio Destri
 
Database Data Aggregator
Database Data AggregatorDatabase Data Aggregator
Database Data AggregatorDavide Ciambelli
 
Tesi_Adamou
Tesi_AdamouTesi_Adamou
Tesi_Adamoututorialsruby
 
Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Maurizio Cacace
 
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...Davide Bravin
 
Publish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingPublish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingNicola Mezzetti
 
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Gianluca Ritrovati
 
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...Implementazione in Java di plugin Maven per algoritmi di addestramento per re...
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...Francesco Komauli
 
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - TesiAnalisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - TesiMicheleDamian
 
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...danieledegan
 
Profilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzatiProfilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzatiPietro Corona
 
Dynamic Scheduling
Dynamic SchedulingDynamic Scheduling
Dynamic SchedulingNicola Mezzetti
 
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...Francesco Cucari
 
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...Idriss Riouak
 
Monitoraggio di mac address in lan
Monitoraggio di mac address in lanMonitoraggio di mac address in lan
Monitoraggio di mac address in lanCe.Se.N.A. Security
 
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linuxInoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linuxCe.Se.N.A. Security
 
Openfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsOpenfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsLorenzo Stacchio
 
domenicoCaputiTriennale
domenicoCaputiTriennaledomenicoCaputiTriennale
domenicoCaputiTriennaleDomenico Caputi
 
Algoritmo di Dijkstra
Algoritmo di DijkstraAlgoritmo di Dijkstra
Algoritmo di DijkstraMassimoPalmisano
 
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...Luca Bressan
 
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...michael_mozzon
 
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...Reti di partecipazione fra società di capitale in Italia: presenza di topolog...
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...Andrea Cavicchini
 
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...maaske
 

Más contenido relacionado

Similar a Tesi: Progetto e realizzazione di un sistema robusto di gestione dei dati per ambienti di esecuzione distribuita.

Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Maurizio Cacace
 
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...Davide Bravin
 
Publish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingPublish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingNicola Mezzetti
 
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Gianluca Ritrovati
 
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...Implementazione in Java di plugin Maven per algoritmi di addestramento per re...
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...Francesco Komauli
 
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - TesiAnalisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - TesiMicheleDamian
 
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...danieledegan
 
Profilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzatiProfilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzatiPietro Corona
 
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...Francesco Cucari
 
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...Idriss Riouak
 
Monitoraggio di mac address in lan
Monitoraggio di mac address in lanMonitoraggio di mac address in lan
Monitoraggio di mac address in lanCe.Se.N.A. Security
 
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linuxInoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linuxCe.Se.N.A. Security
 
Openfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsOpenfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsLorenzo Stacchio
 
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...Luca Bressan
 
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...michael_mozzon
 
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...Reti di partecipazione fra società di capitale in Italia: presenza di topolog...
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...Andrea Cavicchini
 
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...maaske
 

Similar a Tesi: Progetto e realizzazione di un sistema robusto di gestione dei dati per ambienti di esecuzione distribuita. (20)

Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques
 
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
 
Publish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingPublish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based Routing
 
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
 
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...Implementazione in Java di plugin Maven per algoritmi di addestramento per re...
Implementazione in Java di plugin Maven per algoritmi di addestramento per re...
 
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - TesiAnalisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
 
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del ...
 
Profilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzatiProfilazione utente in ambienti virtualizzati
Profilazione utente in ambienti virtualizzati
 
Dynamic Scheduling
Dynamic SchedulingDynamic Scheduling
Dynamic Scheduling
 
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...
Art Everywhere: progetto per workshop Google. Sviluppo di sistemi di pattern ...
 
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...
Uno studio sull'efficacia di checker automatici per la modernizzazione di cod...
 
Monitoraggio di mac address in lan
Monitoraggio di mac address in lanMonitoraggio di mac address in lan
Monitoraggio di mac address in lan
 
Inoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linuxInoltro di pacchetti ip in sistemi linux
Inoltro di pacchetti ip in sistemi linux
 
Openfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsOpenfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistems
 
domenicoCaputiTriennale
domenicoCaputiTriennaledomenicoCaputiTriennale
domenicoCaputiTriennale
 
Algoritmo di Dijkstra
Algoritmo di DijkstraAlgoritmo di Dijkstra
Algoritmo di Dijkstra
 
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
Estrazione automatica di informazioni da documenti cartacei: progetto e reali...
 
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello...
 
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...Reti di partecipazione fra società di capitale in Italia: presenza di topolog...
Reti di partecipazione fra società di capitale in Italia: presenza di topolog...
 
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
 

Tesi: Progetto e realizzazione di un sistema robusto di gestione dei dati per ambienti di esecuzione distribuita.

  • 1. Universit`a degli Studi di Trieste Dipartimento di Ingegneria e Architettura Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea in Programmazione Distribuita Progetto e realizzazione di un sistema robusto di gestione dei dati 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
  • 2. . Alla mia famiglia, parenti e amici. Grazie.
  • 3. Introduzione Negli ambienti di esecuzione distribuita le elaborazioni avvengono su calcola- tori distinti: queste sono orchestrate in modo statico o dinamico da un’unit`a centrale. Tipicamente ognuna di queste elaborazioni richiede uno o pi`u file in ingresso e produce uno o pi`u file in uscita, nasce cos`ı la necessit`a 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 pi`u 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 volont`a 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 volont`a si ritiene utile uno studio riguardo l’opportunit`a 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
  • 4. 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 transazionalit`a e persistenza e delle librerie che forniscono tali funzionalit`a. 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 dar`a una breve descrizione occasionalmente accom- pagnata da considerazioni sul loro funzionamento. Nel capitolo successivo si dar`a spazio all’analisi che ha preceduto il lavoro di progettazione, verr`a delineato lo scenario tipico in cui si vuole lavorare, si analizzeranno obiettivi e vincoli tecnologici. Il capitolo sulla progettazione definir`a l’interfaccia del sistema realizzato e la suddivisione in moduli che `e stata eseguita, per ogni modulo verr`a definita una interfaccia. In seguito si scender`a 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.
  • 5. 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
  • 6. 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
  • 7. 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 Attivit`a sui vari nodi durante il crash test . . . . . . . . . . . 39
  • 8. 5.3 Attivit`a sui vari nodi durante il test di interruzione delle co- municazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.4 Test modifica della topologia . . . . . . . . . . . . . . . . . . . 41 5.5 Comparazione velocit`a 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 Velocit`a di trasferimento con e senza chunking . . . . . . . . . 44
  • 9. Capitolo 1 Distribuzione dei dati per l’esecuzione distribuita Quando l’esecuzione di un flusso di lavoro viene suddivisa e distribuita su pi`u 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 necessit`a di gestire tali dati. Necessit`a degli ambienti di esecuzione distribuita In un ambiente di esecuzione distribuita ogni nodo esegue un programma il quale pu`o aver bisogno di determinati file di input ed eventualmente produce uno o pi`u file di output. Una esecuzione pu`o 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 pi`u altre esecuzioni, si veda ad esempio la Figura 1.1. La pianificazione delle esecuzioni e dei trasferimenti ha uguale importanza poich´e nessuna elaborazione pu`o avvenire se mancano i dati su cui deve operare.
  • 10. Distribuzione dei dati per l’esecuzione distribuita 2 Node Node Node Node Parameters Mesh Thermal Analysis EM Analysis Turbulence Analysis Figura 1.1: Esempio di esecuzione distribuita, a partire da alcuni pa- rametri un nodo crea un modello sul quale altri nodi eseguiranno 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 pu`o essere pianificata a priori conoscendo tutte le risorse dispo- nibili cercando la loro allocazione pi`u efficiente. Si noti che il tipo di connessione di cui parliamo non `e da intendersi come connessione fisica ma piuttosto come possibilit`a di utilizzare un protocollo di trasferimento file fra due nodi, il termine “connessione” verr`a utilizzato con questo significato ovunque non diversamente specificato, quando si far`a riferimento alla “topologia” della rete si intender`a 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 verr`a definito il modo in cui un nodo pu`o determinare quali
  • 11. 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 dovr`a 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 pi`u 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 ha prodotto un file, il nodo in basso a destra ha bisogno di quel file senza sapere chi l’ha generato o quando verr`a 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
  • 12. 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 funzionalit`a 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].
  • 13. 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 gi`a 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 due nodi intermedi. k `e il livello di concorrenza. Immagine tratta 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 pu`o 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
  • 14. 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 poich`e 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 modalit`a peer-to-peer pur mantenendo la necessit`a di uno (o pi`u) 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) pu`o 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 criticit`a 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.
  • 15. 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 poggiano su 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 pu`o 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 pi`u 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
  • 16. 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 funzionalit`a 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. Necessit`a di sviluppare un sistema dedicato Il sistema sviluppato in questa tesi richiede alcune funzionalit`a presenti in uno o pi`u 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 dovr`a na- scondere la complessit`a legata alle modalit`a con cui il nodo `e inserito nella rete, ai protocolli che esso utilizza ed alla necessit`a o meno di usare relay (anche multipli) per ottenere il trasferimento dei file. • Verifica dei trasferimenti: ogni trasferimento dovr`a 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).
  • 17. Distribuzione dei dati per l’esecuzione distribuita 9 • Atomicit`a 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 gi`a 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 n´e 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.
  • 18. Capitolo 2 Analisi La fase di studio ed analisi del sistema che si andr`a a realizzare consiste in una fase iniziale in cui sono stati raccolti alcuni dati riguardo il “setup” tipico dell’ambiente in cui si dovr`a operare, una lista di funzionalit`a 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 qualit`a dei nodi, potreb- bero essere elaboratori per “High Performance Computing” come essere dei personal computer con limitate capacit`a 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. • Quantit`a dei nodi: il numero di nodi coinvolti nel sistema pu`o variare da alcune unit`a a poche decine, ognuno di essi deve essere in grado di inviare
  • 19. 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. • Portabilit`a: 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 modalit`a. • 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.
  • 20. 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 pi`u 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 quantit`a predicibile di risorse: `e importante che il sistema che verr`a realizzato impegni una quantit`a 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 libert`a 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 portabilit`a, 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 dovr`a 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.
  • 21. Capitolo 3 Progettazione L’attivit`a 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 permetter`a 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 verr`a 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
  • 22. 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 possibilit`a 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-
  • 23. 3.1 Interfaccia 15 ni, nonch´e l’esecuzione del DBMS H2[22] con relativa web console. Spring ha permesso anche l’uso di alcune tecnologie di monitoraggio alle quali si accenner`a 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.
  • 24. 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 pu`o includere informa- zioni aggiuntive generate dai sottosistemi (utilizzabili per identificare pi`u dettagliatamente l’errore occorso). Per aumentare la leggibilit`a 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 funzionalit`a 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 funzionalit`a elementari necessarie solo ad indirizzare i messaggi ricevuti dall’esterno e quelli generati internamente sulle code JMS opportune.
  • 25. 3.2 Macrofunzioni 17 Distributed Data Manager Locate Plan Execute JMS Exported InterfaceOrchestrator External Interface 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 rispettivamente di fare da collante fra i vari sottomoduli e implementare l’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 risponder`a 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.
  • 26. 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’eventualit`a che il file non fosse localizzabile (perch´e non esi- ste o perch´e 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 modalit`a con cui effettuare il suo trasferimento (modulo “Plan” in Figura 3.2). Il tra- sferimento sar`a diretto quando possibile, altrimenti il file verr`a recuperato tramite una catena di opportuni trasferimenti. La connettivit`a della rete pu´o 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 possibilit`a 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 poich´e fra due nodi un file pu`o essere trasferito sia tramite protocolli diversi che, usando lo stesso protocollo, con modalit`a diverse (push o pull). Data questa rappresentazione si pu`o utiliz- zare l’algoritmo di Dijkstra[24] per rilevare il percorso pi`u 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 pi`u chunk, la cui dimensione `e co-
  • 27. 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 le connessioni possibili, in basso un possibile percorso per il trasferimento del file, gli archi con due frecce rappresenta- no in realt`a due archi con direzione opposta fra i medesimi vertici. stante tranne al pi`u l’ultimo. L’impatto di questa scelta sulle prestazioni verr`a presentato nella Sezione 5.3.1 . L’utilizzo di questa tecnica permette la ricezione concorrente di un file da pi`u fonti nel caso fosse presente su pi`u 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.
  • 28. 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 pu`o ese- guire un solo trasferimento alla volta. Il chunking (in bas- so) permette di ricevere i file in un tempo minore nel caso di 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
  • 29. 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 dovr`a 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 conterr`a 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. Ci`o 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 complessit`a 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.
  • 30. 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 verr`a 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 pu`o considerarsi terminato con successo. Soddisfatte queste condizioni il file in arrivo dovr`a 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 dovr`a 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.
  • 31. 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 pi`u route. Ogni implementazione verr`a 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 verr`a spiegato nel dettaglio il funzionamento dei singoli “bean” in quan- to svolgono funzioni poco pi`u che banali e nemmeno si scender`a nel dettaglio implementativo delle singole classi in quanto questo richiederebbe una inclu- sione dell’intero codice sorgente. Verranno nascosti alcuni dettagli implementativi poich´e 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.
  • 32. Implementazione 24 Organizzazione in moduli Il sistema `e stato implementato con una modularit`a su due livelli. Il primo livello di modularit`a 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 verr`a 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 pi`u 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 numerosit`a di tali strutture dati.
  • 33. 4.1 Ricerca dei file 25 Nel Capitolo 5 verr`a 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 pu`o 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 la ricerca dei file, all’esterno le code JMS, dentro i riquadri le due componenti di ogni nodo che stanno interagendo. Come si pu`o 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 gi`a presente sul nodo
  • 34. 4.1 Ricerca dei file 26 richiedente, questo per evitare le latenze introdotte dal broker JMS in un caso la cui risposta pu`o 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 gi`a 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 NotNull Figura 4.2: Finder Route: composizione degli Enterprise Integration Pattern per l’implementazione del modulo “Finder”. Il grafo `e stato generato a partire dai sorgenti, e manipolato per renderlo pi`u leggibile.
  • 35. 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 pi`u nodi contengano il file, il modulo successivo utilizzer`a 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.
  • 36. 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- zionalit`a necessarie a mantenere una rappresentazione sotto forma di grafo della connettivit`a 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 connettivit`a, a destra in alto ricerca del percorso minimo sul grafo e in basso recupero dei metadati sui chunk.
  • 37. 4.2 Pianificazione del trasferimento 29 4.2.1 Router A questo modulo arrivano i messaggi riguardo file gi`a localizzati, esso ha il compito di ricercare il percorso pi`u 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 pu`o essere assegnato secondo diverse metriche: massima velocit`a dell’interfaccia di rete, massima velocit`a 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 Definition True False Figura 4.5: Router: il modulo cerca un percorso sul grafo fra sorgente e destinazione, se non lo trova riprova dopo un lasso di tempo configurabile. Se il cammino esiste viene generato un 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 verr`a 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
  • 38. 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 e arricchisce 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 di rete, ricezione e integrazione della conoscenza degli altri nodi. Questo modulo si occupa della costruzione del grafo di connettivit`a 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 possibilit`a 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
  • 39. 4.3 Esecuzione e verifica del trasferimento 31 i nodi hanno la possibilit`a di costruire e mantenere costantemente aggiornato il loro grafo di connettivit`a. 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 nonch´e 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 gi`a 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
  • 40. 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 dovr`a effet- tuare la verifica dell’integrit`a 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 gi`a eseguiti, altrimenti il trasferimento verr`a 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 poich`e esula dalle ipotesi iniziali sullo scenario.
  • 41. 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 pi`u 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 funzionalit`a 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-
  • 42. 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 unit`a: • 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
  • 43. 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 funzionalit`a 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 modalit`a 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 modalit`a 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.
  • 44. 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 connettivit`a sia di alto che di basso livello. Il primo scenario comprende anche la possibilit`a di interruzione della forni- tura elettrica con conseguente arresto dell’esecuzione senza preavviso, ovvero senza la possibilit`a 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
  • 45. 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 pu`o 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, pi`u banalmente, quello di verificare la presenza dei file richiesti da ogni nodo sul suo filesystem locale. Questa modalit`a fornisce molte meno infor-
  • 46. 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 quantit`a di eventi che percorrono quell’arco. I due processi rappresentati sono estratti da esecuzioni reali del sistema in cui alcune eventualit`a 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
  • 47. 5.2 Robustezza 39 numero arbitrario e casuale di nodi ad ogni verifica. In questa tesi verr`a 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’attivit`a su ogni nodo, stimata dal numero di messaggi di log per unit`a 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’attivit`a globale. Si pu`o notare un leggero disallineamento dei grafici dovuto al fatto che gli istanti di inizio e fine attivit`a 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: Attivit`a durante il test di interruzione, dall’alto verso il basso: sorgente, due relay, destinazione e andamento glo- bale. Stima effettuata in base al numero di messaggi di log nell’unit`a di tempo.
  • 48. 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 vari nodi. Le frecce demarcano gli istanti in cui la condizioni di connettivit`a subiscono variazioni. “Trasferimenti Atti- vi” rappresenta il numero di trasferimenti in corso (ovvero richiesti e non ancora completati). In Figura 5.3 si pu`o 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 connettivit`a. 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
  • 49. 5.2 Robustezza 41 (D), gli effetti di questa operazione si vedono sul nodo destinazione che non ha pi`u attivit`a di download da quel nodo. L’attivit`a riprende non appena si ripristina la connessione (E). In basso nella figura si riporta la quantit`a 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 ci`o accadesse era quello di visualizzare, nodo per nodo, il grafo rilevato dal componente “Mapper”. Come si pu`o 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 connettivit`a in seguito ad una modifica della topologia di rete: il nodo “Workstation” ha un malfuzionamento del server HTTP, gli archi “pull” uscenti da “Workstation” vengono rimossi.
  • 50. 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 pi`u 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 funzionalit`a 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 pi`u disponibile il sistema rimane in attesa, se il collegamento viene ripri- stinato il trasferimento continuer`a altrimenti, dopo un lasso di tempo configu- rabile, il sistema richieder`a un nuovo trasferimento. Grazie all’idempotenza dei trasferimenti non sar`a necessario annullare il precedente trasferimento. 5.3 Prestazioni Una figura di merito investigata `e quella delle prestazioni: in questo caso tempi e velocit`a di trasferimento. Bench`e non ci fossero requisiti minimi su tali valori si `e voluto comunque misurarli. Ci si `e da subito confrontati con la possibilit`a di scegliere se misurare le singole velocit`a 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 velocit`a 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 velocit`a rilevate saranno comunque sensibilmente inferiori a quelle massime teoriche.
  • 51. 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 pi`u nodi relay sia reale e quale sia la sua entit`a. Per fare ci`o 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 velocit`a di trasferimento senza e con chun- king. A scapito di una leggera perdita nei trasferimen- ti diretti il chunking permette guadagni in velocit`a nei trasferimenti 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 dovr`a ritrasferire un solo chunk invece che il file intero.
  • 52. 5.3 Prestazioni 44 Configurazione Diretta Un Relay Due Relay Senza chunking Avg 6.77 3.96 2.23 StdDev 0.64 0.20 0.13 Con chunking Avg 5.71 5.07 4.15 StdDev 0.18 0.22 0.16 Tabella 5.1: Velocit`a di trasferimento rilevate, tutti i valori sono in MiB/s. 5.3.2 Thread e memoria occupata. Per verificare che il sistema avesse alcune delle propriet`a 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 propriet`a `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 funzionalit`a 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 pu`o 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.
  • 53. 5.3 Prestazioni 45 Figura 5.6: Risorse impegnate dal sistema: la maschera evidenzia tre trasferimenti, le risorse impegnate vengono rilasciate. Figura 5.7: Dieci trasferimenti contemporanei, il sistema limita i trasferimenti contemporanei a tre.
  • 54. 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 poich´e la libreria prevedeva il loro riutilizzo risparmiando sui tempi di connessione e login al server remoto. Questa funzionalit`a non veniva sfruttata portando alla crea- zione di un nuovo thread ad ogni richiesta. Come si pu`o 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.
  • 55. 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 pi`u significative. Gli obiettivi iniziali sono stati soddisfatti sia in termini di funzionalit`a 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 pi`u 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 pi`u affermate) riguardo lo sviluppo software, rappresentan-
  • 56. Conclusioni 48 do un ulteriore avanzamento nella formazione personale e professionale. La libert`a 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 fattibilit`a di un tale sistema sia il possibile impatto delle conoscenze acquisite sulle tecnologie utilizzate in ambiti diversi da quello di questa tesi.
  • 57. 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.
  • 58. 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. M¨uhl, 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.
  • 59. 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/.
  • 60. 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.
  • 61. 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.