L’architettura utilizzata per implementare il middleware del sistema `e rappresentata in figura 3.1. Ogni utente `e in grado di interagire direttamente con il sistema utilizzando l’interfaccia utente, le comunicazioni tra nodi avvengono mediante socket utilizzando i protocolli forniti dalla rete di comunicazione a cui ogni host `e connesso. Nel seguito `e fornita la descrizione di ogni componente che costituisce il middleware utilizzando l’astrazione della composizione basata su eventi asincroni[36] in cui ogni componente del sistema, denominato modulo, fornisce una interfaccia composta dagli eventi che riceve e che produce. Ogni evento pu`o essere associato ad un insieme di attributi, ovvero un insieme di informazioni associate all’evento, e possono essere di tipo:
• Richiesta, sono prodotte dai moduli per richiedere un servizio da un altro modulo; • Conferma, sono generate da un modulo per notificare il completamento del
sod-disfacimento di una richiesta;
• Indicazione, sono utilizzati per consegnare informazioni ad un altro modulo.
3.2.1 User Interface
E’ il modulo che si occupa di gestire l’interazione tra utente e sistema.
Dal punto di vista dell’utente, il sistema `e un’unica entit`a a cui `e possibile richie-dere l’esecuzione di jobs che possono essere scomposti ed eseguiti in parallelo. Per sottomettere un job, l’utente specifica:
• Nome del jar che costituisce il codice eseguibile del programma parallelo; • Nome del file che contiene i dati di input;
3.2. MODELLO ARCHITETTURALE 29
Figura 3.1: architettura a strati del sistema • Configurazione hardware minima dei nodi da allocare; • Eventuali parametri per la configurazione dei task;
La suddivisione dei dati di input avviene tramite partizionamento del file in chunck di dati aventi dimensione pari a:
Dimensione file di input / numero nodi allocati
Il partizionamento non tiene conto del contenuto o tipo di file da partizionare, ogni nodo ricever`a un chunck di dati avente la medesima dimensione e tali che la concatenazione di tutti i chunck permette di ricostruire il file di input originario.
Le indicazioni sulla configurazione hardware dei nodi da allocare consiste nella definizione di vincoli sulla:
• Frequenza di clock della CPU; • Dimensione della memoria di lavoro; • Capacit`a di storage.
L’interfaccia offerta dal modulo `e composta da:
SUBMIT JOB(req) Richiede l’esecuzione di un determinato job con un determinato input. Req `e il path del file contenente la richiesta dell’utente. Tale file conterr`a
il nome del codice eseguibile (in formato jar) del job, il nome del file che verrr`a utilizzato come input, la configurazione hardware minima dei nodi che verranno allocati per eseguire il job.
STATUS(state) indica all’utente lo stato di avanzamento della computazione. La computazione pu`o trovarsi in uno dei seguenti stati:
• RESOURCE ALLOCATION, indica che il sistema `e nella fase di allocazione delle risorse che rispettano la configurazione hardware fornita dall’utente. • DATA PARTITIONING, indica che `e in esecuzione la funzione di
partizio-namento dei dati e di invio di ogni partizione ai nodi allocati.
• WAITING, indica che il sistema ha terminato l’invio dei dati di input ed `e in attesa che la computazione distribuita termini.
• RETRIVING OUTPUT, indica che la computazione distribuita `e terminata e il risultato `e in fase di trasmissione verso il nodo locale.
• COMPLETED, indica che la computazione distribuita `e terminata e l’output si trova in un file del dispositivo di storage locale.
• INTERRUPTED, indica che la computazione `e stata interrotta senza portare a termine il job.
JOB TERMINATED(output) , indica che il job `e terminato e l’output `e conser-vato in un file del dispositivo di storage locale.
DISCONNECT() , richiede la disconessione del nodo dalla rete P2P, l’utente pu`o in qualsiasi momento eseguire la disconnessione interrompendo la condivisione delle risorse locali.
CONNECT() , richiede la connessione dell’host alla rete e abilita la condivisione delle risorse locali.
3.2.2 Local Cache
E’ il componente del sistema che interagisce con il sistema operativo per accedere ai dispositivi di storage del nodo. I dati utilizzati dal sistema sono contenuti in files organizzati in 4 directory nelle quali verrannno conservati i file di input, i file di output, i file eseguibili e i file di log utilizzati per registrare eventi significativi verificatisi ad ogni nodo e per scopi di debugging.
L’interfaccia del modulo `e costituita da:
GET DATA(type,name) , richiede i dati contenuti nel file il cui tipo `e specificato da type(specifica se i dati sono di input, ouptut o codice eseguibile) e l’identificativo da name;
PUT DATA(type,name) , richiede l’allocazione di un file di tipo specificato da type con identificativo name;
3.2. MODELLO ARCHITETTURALE 31
GET PATH(type,name) , richiede il path completo del file di tipo type corrispon-dente a name.
3.2.3 Local Resource Monitor
Il LocalResourceMonitor(LRM) `e il modulo che si occupa di individuare le risorse computazionali locali e di monitorarne l’utilizzo. Le risorse monitorate sono:
• CPU;
• Memoria di lavoro.
L’interfaccia del modulo `e costitita da:
GET N CPU() , richiede il numero di CPU presenti nel nodo;
GET CPU SPEED() , richiede le frequenze di clock delle CPU locali al nodo; GET RAM() , richiede la dimensione della memoria di lavoro;
GET RAM UTILIZATION() , richiede la percentuale di utilizzo medio della me-moria di lavoro.
Tra le risorse monitorate vi `e anche la percentuale di utilizzo della CPU, il cui valore non viene notificato agli altri nodi del sistema, ma viene utilizzato per stabilire una condizione di disconnessione del nodo dal sistema, quando il suo valore supera la soglia del 30%, viene automaticamente attivata la procedura di leave che consentir`a all’host di disconnettersi dalla rete P2P e quindi interrompere la condivisione delle risorse locali. In modo analogo, quando il valore percentuale dell’utilizzo della CPU scende al di sotto della soglia del 30%, il nodo eseguir`a la procedura di join per tornare a far parte della rete P2P e condividere nuovamente le risorse computazionali locali.
L’automazione della procedura di join/leave appena descritta, consente all’utente di non percepire alcun cambiamento nelle performances del proprio PC-Desktop, dato che l’utilizzo del nodo da parte dell’utente locale avr`a sempre priorit`a maggiore rispetto all’utilizzo da parte di utenti remoti.
3.2.4 Remote Resource Catalog
Il RemoteResourceCatalog(RRC) si occupa di conservare informazioni sulle risorse dei nodi che compongono la rete. Le informazioni sulle risorse remote sono rappresentate mediante tuple del tipo:
< ID nodo,<tupla risorse computazionali>, delay comunicazione > dove:
• ID nodo `e l’identificativo del nodo all’interno della rete, corrisponde all’indirizzo IP;
• <Tupla risorse computazionali> `e composta da: <numero di CPU, frequenza di clock delle CPU, dimensione della memoria di lavoro, percentuale di utilizzo della memoria di lavoro, spazio di storage disponibile>;
• Delay di comunicazione `e il tempo necessario a trasferire uno stream di dati pari a 100KB verso il nodo.
Conservare le informazioni sulle risorse remote nel nodo locale permette di avere tempi di query costanti, il tempo necessario per ottenere informazioni sulle risorse remote corrisponde al tempo necessario per interrogare la tabella per cercare i nodi i cui attributi rispettino i vincoli richiesti dalla query.
L’interfaccia `e costituita da:
GET NODE( n,<tupla risorse computazionali> ) richiede gli identificativi di un numero di nodi pari a n le cui risorse computazionali hanno attributi con valori pari o maggiore a quelle indicate in <tupla risorse computazionali>, a parit`a di valore vengono scelti i nodi associati al minor valore di delay comunicazione; UPDATE NODE( ID nodo, <tupla risorse computazionali> richiede
l’aggior-namento dei valori degli attributi delle risorse computazionali associate al nodo identificato con ID nodo;
DELETE NODE(ID nodo) richiede la rimozione dal catalog della entry associata al nodo identificato con ID nodo;
3.2.5 Virtual Tree
Il Virtual Tree [33] `e il modulo che si occupa di gestire la rete P2P sulla quale si poggia il sitema di ricerca delle risorse, ovvero `e il modulo che implementa l’ Overlay Management Protocol(OMP). Tale rete utilizza l’astrazione del virtual node, ovvero i nodi sono suddivisi in piccoli gruppi, i nodi all’interno del medesimo gruppo sono connessi l’uno con l’altro secondo la topologia della clique. All’interno di ogni virtual node sono definte:
• Le interconnessioni verso gli altri virtual nodes per formare la virtual overlay; • Gli attrattori che hanno il compito di spostare i nodi fisici tra i virtual nodes. L’utilizzo degli attrattori permette di avere virtual nodes composti da un numero di nodi fisici compreso tra due intervalli: max-size e min size.
Quando la dimensione del virtual node `e inferiore alla soglia del min-size, vengono attivati gli attratori, ovvero una procedura atta a spostare all’interno del virtual node nodi fisici che appartengono ad altri virtual nodes, la scelta del virtual node da cui prelevare il nodo fisico `e basata su una regola deterministica. Quando invece la dimen-sione del virtual node `e superiore al valore di max-size, il virutal node non accetter`a pi`u nuovi nodi, se le dimensioni di tutti i virtual nodes raggiungono la soglia definita
3.2. MODELLO ARCHITETTURALE 33
da max-size, allora l’ingresso nella rete di nuovi nodi porter`a alla formazione di nuovi virtual nodes.
Gli attrattori hanno dunque il ruolo di garantire la sopravvivenza dei virtual nodes, invece la virtual overlay garantisce che le connessioni tra i virtual nodes rispettino una topologia predefinita, che nel caso del virtual tree ha una struttura ad albero.
L’utilizzo della topologia ad albero, mostrata in 3.2.5, permette di ottenere una overlay network caratterizzata:
• Diametro piccolo, che consente di utilizzare un meccanismo veloce per il routing delle query;
• Buona scalabilit`a;
• Possibilit`a di definire una condizione deterministica per la funzione di attrazione precedentemente descritta, tale condizione stabilisce che la migrazione dei nodi pu`o essere fatta solo verso i livelli pi`u bassi dell’albero, ovvero i virtual nodes possono attrarre solo i nodi che si trovano nei virtual nodes a cui sono legati dalla relazione padre-figlio all’interno dell’albero.
VLr,j VNi A B C D E F VNk G H I L M VNj N OVNh VNr VLr,i VLj,k VLj,h Level 0 Level 1 Level 2
Figura 3.2: Virtual Tree
L’algoritmo di processamento delle query all’interno del virtual tree `e composto dai seguenti passi:
1. Un nodo ni invia una richiesta di query q ad uno dei nodi nr che compongono il virtual node radice del virtual tree;
2. nrproduce un messaggio QU ERY (q) contenente la descrizione di tutti i nodi che nel dato istante commpongono il virtual node a cui nr appartiene;
3. nr invia QU ERY (q) a tutti i nodi appartenenti al virtual node radice e ai nodi che compongono i virtual nodes del livello 1 dell’albero:
4. Quando un nodo njappartenente ad un virtual node di livello x riceve QU ERY (q) esegue la seguente procedura:
(a) esegue i passi 2 e 3;
(b) invia un messaggio QU ERY REP LY (q, valuej) a tutti i nodi del proprio virtual node;
(c) attende finch`e:
i. colleziona da tutti i nodi nk descritti in QU ERY (q) i messaggi QU ERY REP LY (q, valuek) e
ii. riceve un messaggio CHILD QU ERY REP LY (q, valV Ny) da almeno un nodo contenuto in ogni virtual node figlio V Ny.
(d) valuta la query in base all’insieme di valori collezionati nella fase 2 e sui valori valV Ny ottenuti dai nodi del livello inferiore;
(e) invia un messaggio CHILD QU ERY REP LY (q, valV Nx) a tutti i nodi che compongono il virtual node padre del virtual node a cui nj appartiene. In basa a quando descritto finora, il virtual tree all’interno del sistema di volunteer computing che stiamo analizzando offre le seguenti funzionalit`a:
• Garantire che i nodi rimangano connessi anche in presenza di ambienti dinamici con livelli di churn rate impredicibili;
• Supportare il routing di query valide, ovvero di query la cui risposta `e costruita mediante il contributo dei nodi che sono connessi al sistema durante l’intervallo di tempo che v`a dall’istante di sottomissione della query all’istante di ricezione della risposta.
L’intero processamento delle query e le operazioni di migrazione dei nodi vengono nascoste agli altri moduli del sistema, l’interfaccia offerta `e composta semplicemente da:
INIT JOIN() richiede la connessione del nodo alla rete P2P gestita dall’OMP. INIT LEAVE() richiede la disconnessione del nodo dalla rete P2P.
RESOURCE UPDATE(<tupla risorse computazionali> ) richiede l’invio di una query per distribuire le informazioni sulle risorse computazionali possedute dal nodo locale.
3.2.6 Message Handler
Il Message Handler si occupa della ricezione e smistamento dei messaggi ricevuti tramite socket dagli altri nodi della rete. I messaggi sono in formato XML e sono differenziati in:
3.2. MODELLO ARCHITETTURALE 35
• Messaggi utilizzati dall’OMP per gestire la rete P2P;
• Messaggi utilizzati per la coordinazione e monitoraggio della computazione di-stribuita.
L’interfaccia del sistema `e composta da:
SEND MESSAGE(mess,ID nodo) richiede l’invio di un messaggio mess al nodo identificato con ID nodo;
MESSAGE RECEIVED(mess,ID nodo) indica la ricezione di un messaggio mess inviato dal nodo identificato con ID nodo.
3.2.7 Job Tracker
Il Job Tracker monitora l’esecuzione della computazione distribuita fungendo anche da failure detector per i nodi che partecipano alla medesima computazione. Ogni nodo all’interno della computazione pu`o eseguire due tipi di task:
• Task indipendente il nodo elabora i dati ricevuti;
• Task di aggregazione il nodo combina il risultato dell’esecuzione di tak indipen-denti eseguiti su altri nodi della rete.
L’individuazione dei nodi guasti si basa su un meccanismo di heartbeating, ogni nodo che esegue un task indipendente invia periodicamente un messaggio al proprio nodo aggregatore contenente l’identificativo del job in esecuzione, l’identificativo dei dati di input in elaborazione e l’identificativo del nodo che ha richiesto l’esecuzione del job. Quindi i nodi che eseguono i task indipendenti sono nodi monitorati. Ogni nodo che esegue un task di aggregazione inizializza un insieme di timer associati ad ognuno dei nodi da cui aspetta il risultato da aggregare. Alla ricezione del messaggio di heartbeat da parte di un nodo n, il timer associato a n viene resettato.
L’interfaccia del modulo `e composta da:
SET JOB CONF(ID nodo,ID job,ID input,<lista nodi>) richiede l’attivazione del failure detector per i nodi elencati in <lista nodi>.
RESET JOB CONFIG() richiede la terminazione delle operazioni di failure detec-tion.
CRASH DETECTED(ID nodo) indica l’individuazione del guasto del nodo iden-tificato con ID nodo.
3.2.8 Slicing Service
Lo Slicing Service si occupa dell’allocazione delle risorse. Il suo compito `e assicurarsi che venga allocato il numero di nodi richiesti e che, in caso di guasti, ogni nodo guasto venga rimpiazzato da un altro nodo della rete avente configurazione hardware adeguata.
L’interfaccia del modulo `e composta da:
CREATE SLICE( n,<tupla risorse computazionali> ) richiede che un numero di nodi pari a n vengano allocati, <tupla risorse computazionali> `e l’insieme di valori minimi che la configurazione dei nodi allocati deve possedere.
ADD NODE(ID nodo) richiede l’aggiunta di un nuovo nodo identificato da ID nodo al cluster di nodi allocato.
3.2.9 Job Manager
Il Job Manager si occupa della gestione delle richieste di esecuzione dei jobs. Tale gestione viene espletata sia a livello locale che a livello globale. A livello locale si occupa di:
• Gestire la coda contenente le richieste di esecuzione di task;
• Implementare una politica di scheduling locale per decidere quale task eseguire; • Invocare l’esecuzione del codice eseguibile associato ad un determinato task
ga-rantendo che i dati di input siano disponibili; • Interrompere l’esecuzione dei task;
• Gestire il flusso dei dati di output prodotti dal task;
• Collezionare i messaggi di errore prodotti dal task durante la sua esecuzione. A livello globale le sue funzioni sono:
• Configurare lo Slicing Service e il Job Tracker per allocare e monitorare le risorse necessarie alla computazione distribuita;
• Collezionare statistiche sulla computazione(come ad esempio: numero di guasti verificatisi, tempo necessario a completare la query, tempo necessario a completare l’esecuzione,informazioni sullo stato della computazione....);
• Interrompere l’esecuzione della computazione distribuita;
• Ricevere e richiedere l’allocazione sul nodo locale dei dati prodotti dalla compu-tazione distribuita.