Progettazione, Implementazione e Valutazione di un Sistema ...

Universita degli Studi di Roma “La Sapienza”

Facolta di Ingegneria

Tesi di Laurea in

Ingegneria Informatica

Ottobre, 2012

Progettazione, Implementazione e Valutazione di un

Sistema P2P per Volunteer-Computing

Bracone Giuseppe

Universita degli Studi di Roma “La Sapienza”

Facolta di Ingegneria

Tesi di Laurea in Ingegneria Informatica

Sessione Autunnale – Ottobre, 2012

Progettazione, Implementazione e Valutazione di un

Sistema P2P per Volunteer-Computing

Bracone Giuseppe

Relatore Prof. Leonardo Querzoni

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Revisore Prof. Camil Demetrescu

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Indirizzo dell’Autore:Bracone Giuseppec/da ramitelli, 6Campomarino (CB)86042 ITALIAe-mail: [email protected]

www:

Ringraziamenti

Riflettendo sull’esigenza o meno di scrivere queste righe, sono stato sommerso da unamarea di ricordi legati all’esperienza universitaria che mi appresto a concludere.

Ricordi legati a personone che, nel bene e nel male, hanno contribuito a plasmarela mia personalita e ad arricchire quel bagaglio di esperienze che mi vanto di possedere.

Proseguire con l’elenco di tali persone sarebbe dispendioso e inutile, rischiandoperaltro di saltarne qualcuna, mi limito quindi a dei ringraziamenti generici con lacertezza che chiunque li leggera sapra quanti e quali gli sono stati dedicati.

Il primo ringraziamento speciale va a coloro che mi hanno fornito gli strumenti perpoter iniziare questo lavoro di tesi, accompagnandomi e inocraggiandomi durante illungo periodo di gestazione necessario per esssere completato.

Un ringraziamento di cuore e diretto verso chi mi ha instillato il senso del dovere emi ha insegnato ad essere umile e al contempo caparbio per affrontare qualsiasi sfidae a coloro che mi hanno saputo tirar fuori la grinta e la tenacia necessarie a superarequalsiasi ostacolo che mi separava dal traguardo.

Ringrazio coloro che mi hanno dato la possibilita di poter iniziare e portare finoin fondo questo percorso di studio, le persone che hanno condiviso anche una piccolaparte di questo percorso dai quali ho imparato l’importanza della collaborazione edella condivisione e chi mi e stato vicino alla fine alleviando quell’ansia passeggera cheaccompagna ogni attesa di un evento importante e significativo.

L’ultimo ringraziamento e diretto a tutte le persone che sostengono l’universita,quell’ambiente dinamico ed eterogeneo in cui ogni giorno ho avuto la possibilita diallargare i miei orizzonti conoscitivi e di incontrare persone di idee e costumi differentiche hanno rafforzato la mia identita culturale e mi hanno insegnato il rispetto verso ladiversita.

i

ii CAPITOLO 0

Indice

Ringraziamenti i

1 IntroduzioneL’evoluzione dei sistemi per la computazione distribuita: dal Grid-Computing al Volunteer-Computing 11.1 I sistemi distribuiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 La tecnologia Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 L’avvento del Cloud-Computing . . . . . . . . . . . . . . . . . . . . . . . 91.4 Le potenzialita del Volunteer-Computing . . . . . . . . . . . . . . . . . . 12

1.4.1 XtremWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.2 Cohesion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.3 Alchemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.4 OurGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5 Il nostro contributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Tecnologie P2P per la Computazione Distribuita 172.1 La ricerca di risorse in un ambiente dinamico . . . . . . . . . . . . . . . 192.2 Allocare risorse senza controllo centralizzato . . . . . . . . . . . . . . . . 222.3 La rilevazione dei guasti . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Progettazione e Implementazione del sistema Cloud-to-Peer 273.1 Modello Fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Modello Architetturale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.2 Local Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.3 Local Resource Monitor . . . . . . . . . . . . . . . . . . . . . . . 313.2.4 Remote Resource Catalog . . . . . . . . . . . . . . . . . . . . . . 313.2.5 Virtual Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.6 Message Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.7 Job Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.8 Slicing Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.9 Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3 Protocolli e Interazioni tra Moduli . . . . . . . . . . . . . . . . . . . . . 37

iii

iv INDICE

3.3.1 Sottomissione di Job . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.2 Esecuzione/Interruzione/Completamento del job . . . . . . . . . 383.3.3 Sostituzione dei nodi guasti . . . . . . . . . . . . . . . . . . . . . 413.3.4 Aggiornamento del Remote Resource Catalog . . . . . . . . . . . 42

4 Test e Risultati 474.1 Ambienti di test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1 WordCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.2 StringSort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.3 SHA-BruteForceAttack . . . . . . . . . . . . . . . . . . . . . . . 52

4.3 Consumi energetici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5 Conclusioni 615.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2 Scenari di utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Capitolo 1

IntroduzioneL’evoluzione dei sistemi per lacomputazione distribuita: dalGrid-Computing alVolunteer-Computing

1.1 I sistemi distribuiti

I sistemi distribuiti nascono dall’esigenza di avere infrastrutture in grado si supportarel’esecuzione di task eseguibili in parallelo per l’analisi e la manipolazione di dati[8].

L’utilita dei sistemi distribuiti si riscontra nei campi:

• Scientifico: la scienza moderna e basata su simulazioni numeriche, analisi di enor-mi quantita di dati prodotti in real-time da sofisticati strumenti e collaborazionesu larga scala, problemi chiave afferenti ai piu svariati campi scientifici e ingegne-ristici necessitano di un’ infrastruttura in grado di fornire computazioni su largascala, ovvero in grado di estendere il potere computazionali offerto da una singolamacchina;

• Industriale:ambienti di simulazione sempre piu dettagliati richiedono notevolitempi computazionali;

• Aziendale-Controllo:la quantita di informazioni sempre piu dettagliate sui clienti esui cittadini richiedono computazioni data-intensive che necessitano del supportodi infrastrutture adeguate.

La nascita e l’espansione dei sistemi distribuiti e stata resa possibile dal progressoed evoluzione delle tecnologie hardware e software, nel seguito sono descritte le fasi

1

2 CAPITOLO 1

fondamentali del percorso evolutivo di ognuno. L’evoluzione dell’hardware puo essereriassunto nelle seguenti ere[31]:

1. Era dei mainframe e super-computer, rappresenta gli albori dei dispositivi dicalcolo automatico e sono caratterizzati da macchine aventi notevoli dimensionie altissimi consumi energetici;

2. Era dei minicomputer, nasce tramite la ricerca e l’applicazione di tecniche diminiaturizzazione che permettono di avere dispositivi di calcolo di dimensioniconsiderevolmente inferiori rispetto ai predecessori;

3. Era dei personal computer, il processo di miniaturizzazione e accompagnato dallaricerca di tecniche per la riduzione del consumo energetico e dall’abbattimento deicosti di produzione che portano alla diffusione di massa dei dispositivi di calcoloelettronico;

4. Era dei mobile device, alimentata da tecniche sempre piu efficienti ed efficaci perridurre i consumi energetici e le dimensioni dell’hardware e dal potenziamentodella rete di comunicazione, l’obiettivo e ottenere dispositivi di calcolo multifun-zionali interconnessi tra loro le cui funzionalita siano disponibili in qualsiasi luogoe in ogni momento.

Il percorso evolutivo del software prosegue parallelamente a quello dell’hardware, sia peradattarsi alle innovazioni che esso offre, sia per segnare la strada verso cui lo sviluppodell’hardware stesso deve essere indirizzato, possiamo distinguere le fasi:

• Batch-oriented, le applicazioni sono di tipo batch, l’interattivita e limitata,le applicazioni sono specializzate per eseguire determinati task risultando pocoparametrizzabili e con notevoli richieste di risorse di calcolo;

• Client-Server, le applicazioni sfruttano le risorse di rete per eseguire task su risorsecomputazionali remote, le tecniche per la parallelizzazione dei task e le tecnichedi scheduling permettono al server di agire come risorsa condivisa in grado disoddisfare le richieste provenienti da un gran numero di clients geograficamentedistribuiti;

• SOA e Web-Application, le applicazioni permettono di coordinare un maggiornumero di risorse e di aumentarne il grado di condivisione tra piu utenti, siassiste alla proliferazione di nuovi modelli per il calcolo distribuito e nascono iconcetti di QoS e di SLA, l’obiettivo principale delle applicazioni e soddisfare uninsieme di richieste sempre piu eterogeneo e articolato concentrandosi su come ilcomportamento di tali applicazioni vengono percepite dall’utente.

Una prima classificazione dei sistemi paralleli puo essere effettuate sulla base del gradodi disaccoppiamento e di condivisione delle risorse che vengono coordinate per eseguireuno specifico task, si hanno dunque[27]:

1.2. LA TECNOLOGIA GRID 3

• Array di processori, sono caratterizzati da stretto accoppiamento, co-locazionefisica e condivisione del sistema di clock.

• Sistemi multi-processore, sono caratterizzati dall’accesso diretto alla memoria con-divisa secondo il modello UMA(UnifiedMemoryAccess). Esempi di tali sistemisono le reti: Omega,Butterfly,Clos,Shuffle exchange.

• Sistemi multi-computer, sono caratterizzati dalla mancanza di accesso diretto allamemoria condivisa secondo il modello NUMA(NotUnifiedMemoryAccess)Esempidi tali sistemi sono: NYU Ultracomputer, CM* Connection Machine, IBM Bluegene.

Altre classificazioni possono essere effettuate sulla base di altre caratteristiche deisistemi distribuiti, tra cui:

• Capacita di coordinare un insieme di macchine per supportare l’esecuzione dispecifici task;

• Livello di concorrenza offerto, ovvero impatto dei tempi delle operazioni di sin-cronizzazione sul tempo totale di esecuzione dei task;

• Quantita e tipo di risorse condivise;

• Modalita di accesso alle risorse remote;

• Valutazione del rapporto performances/costo;

• Misura dell’affidabilita, intesa come l’insieme di disponibilita, integrita, tolleranzaai guasti;

• Scalabilita;

• Modularita.

1.2 La tecnologia Grid

Nel seguito verra analizzata una classe importante di sistemi distribuiti, tale classeracchiude tutti i sistemi paralleli di tipo multi-computer che permettono di esegui-re computazioni garantendo alti livelli di performances. Tali sistemi possono esseresuddivisi in 2 sottogruppi:

1. Cluster computing [26], sono composti da collezioni di workstation o PC, chiamatinodi, aventi configurazioni simili connessi da reti LAN che garantiscono comu-nicazioni ad alta velocita. Su ogni nodo e in esecuzione il medesimo sistemaoperativo.

4 CAPITOLO 1

2. Grid computing [22], anch’essi sono composti da nodi che pero vengono organizzatiin sottogruppi chiamati federazioni. I domini amministrativi che gestiscono i nodipossono essere differenti cosı come puo essere differente l’hardware e il softwareche compongono ogni nodo e la rete di comunicazione che li interconnette.

La popolarita dei sistemi di cluster computing crebbe di pari passo con il miglioramentodel rapporto prezzo/performances dei PC e delle workstations. Tale fattore permise direndere tecnicamente possibile ed economicamente attraente costruire sistemi di super-computing semplicemente interconnettendo tra loro una collezione di computer in unarete ad alta velocita. In tal modo il cluster computing permette di eseguire calcoloparallelo in cui un singolo programma gira su macchine multiple. Esempi di clustercomputing sono Beowulf e MOSIX.

In Beowulf[28] ogni cluster e composto da collezioni di nodi computazionali chesono controllati e acceduti da un unico nodo master che gestisce l’allocazione dei nodiad un particolare programma eseguibile in parallelo, mantiene una coda di jobs daeseguire al termine dell’esecuzione del programma corrente, ovvero nel cluster giraun programma per volta e richieste per l’esecuzione di altri jobs vengono accodate,e fornisce un interfaccia per l’utente del sistema. Quindi il master si occupa dellagestione del cluster, i nodi eseguono la computazione dei job fornendo semplicementeun sistema operativo standard Linux-based. Il middleware di Beowulf fornisce solofunzionalita avanzate di comunicazione message-based, ma non e in grado di gestire iguasti dei processi e di garantire la sicurezza del sistema.

I sistemi MOSIX[6] forniscono un cluster computing simmetrico che si oppone al-l’approccio gerarchico seguito da Beowulf. L’obiettivo di MOSIX e fornire una singolaimmagine del sistema in modo tale che l’intero cluster appaia come un singolo com-puter. Tale funzionalita e fornita mediante la caratteristica di trasparenza ovvero lapossibilita per un processo di migrare dinamicamente tra i nodi che compongono ilcluster. La funzionalita di migrazione dei processi permette ad un utente di iniziareuna applicazione su di un nodo e successivamente spostarla su altri nodi, per otteneread esempio un utilizzo piu efficiente delle risorse del cluster o per ovviare a possibiliguasti, senza interromperne l’esecuzione.

La caratteristica principale del cluster computing e l’omogeneita dei nodi di compu-tazione, essi hanno il medesimo sistema operativo e sono connessi alla medesima rete.I sistemi di grid computing sono invece caratterizzati da un alto grado di eterogeneita,ovvero per l’intero insieme di nodi computazionali non vi sono assunzioni sull’hard-ware, sul sistema operativo, sulla rete, sui domini amministrativi o sulle politiche disicurezza. Lo scopo dei sistemi di grid computing e permettere che organizzazioni dif-ferenti siano in grado di collaborare, tale collaborazione e realizzata secondo la formadella organizzazione virtuale[22]. I providers e i consumatori di risorse definiscono lecondizioni sotto le quali interagiscono, ovvero:

• cosa e condiviso;

• chi puo condividere e accedere alle risorse condivise;


Figura 1.1: Schema organizzativo delle grid

• quale qualita di servizio puo essere garantita.

L’organizzazione virtuale e l’insieme di individui e istituzioni che interagiscono secondole medesime condizioni. Le risorse sono tipicamente costituite da servers, funzionalitadi storage e databases, inoltre puo essere fornito l’utilizzo di speciali dispositivi cometelescopi, sensori,...etc. Mentre la ricerca sulla computazione distribuita e finalizzata arisolvere i problemi dovuti alla separazione geografica delle risorse, la ricerca sui gridha come obiettivo primario quello di risolvere problemi di integrazione e di gestione disoftware eterogeneo.

Una definizione piu formale di grid e la seguente: sistema che coordina risorsegeograficamente distribuite utilizzando protocolli e interfacce standard ed e in gradodi fornire adeguati livelli di QoS. Quindi si ha che il grid e costituito da protocollie interfacce che risolvono problemi fondamentali quali autenticazione, autorizzazione,resource discovery e accesso alle risorse. Tali protocolli devono essere standardizzati eaperti per permettere che sistemi differenti possano interagire e integrarsi. Inoltre ilgrid permette l’utilizzo delle risorse in modo coordinato per poter offrire differenti livellidi QoS definiti in basa a metriche quali: tempo di risposta, throughput, disponibilita esicurezza, gestendo l’allocazione di tipi di risorse multiple per soddisfare richieste piucomplesse, in tal modo l’utilita del sistema complessivo e significativamente maggiorerispetto a quella della somma delle sue parti.

L’ infrastruttura grid deve fornire supporto ad applicazioni che possono essereclassificate ini:

1. Applicazioni di monitoraggio e gestione di risorse remote, rappresentate per lopiu da fonti di dati permanenti, quali dispositivi di storage, o temporanei, comei sensori.

2. Applicazioni con requisiti minimi di comunicazione , sono anche chiamate em-barrassingly parallel-applications e consistono nel dividere un problema in sotto-

6 CAPITOLO 1

problemi che possono essere risolti in modo indipendente l’uno dall’altro o tut-talpiu con modesti overhead per lo scambio di messaggi;

3. Applicazioni con requisiti di linking, includono applicazioni che operano secondouno scenario in cui l’input e fornito da uno strumento situato al sito A, i datiche lo compongono vengono analizzati nel sito B, il risultato dell’analisi vienevisualizzato nel sito C. Tali applicazioni richiedono la coordinazione di risorseeterogenee e geograficamente distribuite come computers, archivi per lo storage,strumenti di visualizzazione e strumenti per la produzione di dati.

Le problematiche da risolvere per implementare tecnologia grid riguardano:

• Monitoraggio delle risorse, comprende i meccanismi utilizzati per conservare in-formazioni sullo stato delle risorse nel grid.Tali meccanismi devono essere esten-dibili, veloci, affidabili, sicuri e scalabili, inoltre occorre implementare tecnicheper associare ad ogni risorsa un identificativo univoco.

• Ricerca delle risorse, dato l’identificativo di una risorsa o le sue caratteristiche,occorre un meccanismo per localizzare la risorsa dentro il sistema. La natura dellerisorse e dinamica, alcune risorse possono essere persistenti, alcune transitorie ealtre possono essere create on demand.

• Sincronizzazione e coordinazione, riguarda le tecniche adoperate per orchestrareuna complessa sequenza di operazioni su una varieta di risorse, cio puo includere ladescrizione dei processi, l’implementazione di un sistema event-based, schedulingmultilivello e meccanismi per la gestione di workflow.

• Tolleranza ai guasti e dependability, riguarda la necessita di gestire il guasto dicomponenti hardware e/o software garantendo che i livelli di QoS non venganodegradati.

• Sicurezza, comprende l’autenticazione, l’autorizzazione e i meccanismi di accoun-ting.

• Concorrenza e consistenza, riguarda la necessita di mantenere un appropriatolivello di consistenza dei dati in un ambiente dinamico ed eterogeneo e che leinformazioni di stato sulle singole risorse rispecchino lo stato reale delle risorsestesse.

• Prestazioni, riguarda principalmente l’utilizzo di tecniche di caching e di replica-zione per ridurre il tempo di accesso a risorse remote.

• Eterogeneita, per permettere di utilizzare una moltitudine di risorse di naturadifferente appartenenti a differenti domini amministrativi.

• Scalabilita, ovvero necessita di espandere il numero di servizi e la dimensione delleapplicazioni utilizzando tecniche di automazione e auto-organizzazione.


La prima rudimentale grid in grado di rispettarne le caratteristiche e offrire lefunzionalita sopracitate fu NFSNET.

NFSNET[18] creata nel 1986 con una backbone avente larghezza di banda di 56Kb/seccollegava insieme i 5 centri di supercomputer dell’NFS. I successivi investimenti a taleinfrastrutture mirarono ad incrementare la larghezza di banda della backbone, passandoa 1,5Mb/sec e infine a 45Mb/sec agli inizi del 1990. Nel 2002 NFS ha fondato TeraGridche collega i 5 centri di supercomputer con una rete a fibra ottica avente capacita di40Gb/sec, parallelamente e stato sviluppato il programma Extensible Terascale Facilitycon l’obiettivo di espandere l’infrastruttura di TeraGrid ad altre istituzioni di ricerca,ovvero per integrare TeraGrid con altri sistemi grid.

A NFSNET sono seguiti numerosi altri progetti per dotare diversi paesi di unapropria infrastruttura grid[18]:

• StatiUniti: NSF Grid Physics Network, DOE Science Grid, NSF InternationalVirtual Data Grid Laboratory;

• Europa: EU DataGrid, EUROGRID;

• Progetti grid a livello nazionale: e-Science Grid(UK), INFN Grid(Italia), LHCComputing Grid(Svizzera).

Al finire degli anni 90 il progetto open-source GlobusToolkit definisce quello cheoramai e uno standard de-facto per le infrastrutture grid[22]. Le specifiche che il Globu-sToolkit implementa fanno parte dell’OpenGridServicesArchitecture e vengono ampia-mente adottate all’interno di realta industriali e di ricerca fornendo la base per prodottigrid sia commerciali che open-source. OGSA si occupa soprattutto della definizione diservizi basilari che la grid deve offrire e riguardano:

• Sistemi di gestione e di automazione;

• Gestione dei workload e delle performances;

• Sicurezza;

• Sistemi per garantire la disponibilita;

• Gestione delle risorse logiche;

• Servizi di clustering;

• Gestione della connettivita;

• Gestione delle risorse fisiche.

OGSA propone inoltre un’architettura a strati[22] per la gestione delle grid compo-sta principalmente dai seguenti elementi:

8 CAPITOLO 1

Internetstandards

De facto standardSingle implementation

Web services,et cetera

Computer science research

Real standardsMultiple implementations

Incre

ased functionalit

y, s

tandard

ization

1990 1995 2000 2005

Globus Toolkit

Open GridServices Arch

Customsolutions

Managed sharedvirtual systems

Figura 1.2: Fasi di standardizzazione della tecnologia Grid

1. Fabric layer, fornisce le risorse il cui accesso e mediato dai protocolli definitiall’interno della grid. Tali risorse possono essere risorse computazionali, sistemidi storage, catalogs, risorse di rete e sensori.Ogni risorsa dovrebbe implementaremeccanismi di introspezione che permettano di scoprire la propria struttura, ilproprio stato e la propria capacita, e meccanismi per la gestione della risorsastessa per poter controllare la qualita del servizio che essa offre.

2. Connectivity layer, definisce le basi della comunicazione e i protocolli necessa-ri per permettere la cooperazione tra le risorse. I protocolli di comunicazionepermettono li scambio di dati tra le risorse del fabric layer, i servizi che essiincludono riguardano trasporto, routing e indirizzamento. I protocolli di auten-ticazione vengono costruiti sui servizi di comunicazione e forniscono meccanismicrittograficamente sicuri per verificare l’identita delle risorse e degli utenti.

3. Resource layer, definisce i protocolli per la negoziazione, iniziazione, monitorag-gio, controllo e accounting per le operazioni che utilizzano le risorse del grid. Loscopo e quello di fornire l’interazione tra l’utente e le risorse remote del sistema.

4. Collective layer, contiene i protocolli che non sono associati a specifiche risorse,ma a collezioni di risorse fornendo indicazioni sullo stato globale del sistema esull’interazione tra collezioni di risorse differenti.

5. User application, comprende le applicazioni che operano all’interno della virtualorganization e utilizzano le API e i servizi forniti dagli altri strati, come: gestionedelle risorse, accesso ai dati, resource discovery,... .

1.3. L’AVVENTO DEL CLOUD-COMPUTING 9

Tools and applications User applications

Collective services

Resource andconnectivity protocols

Fabric

Directory brokering,diagnostics, and

monitoring

Diverse resourcessuch as

computers, storage media,networks, and sensors

Secureaccess

to resourcesand services

Figura 1.3: Architettura a strati proposta dall’OGSA

1.3 L’avvento del Cloud-Computing

La virtualizzazione e l’accesso on-demand sono gli strumenti con cui la tecnologia gridevolve verso un nuovo tipo di infrastruttura le cui caratteristiche sono ubiquita e traspa-renza. Il grid computing e il precursore di un paradigma di computazione piu generalechiamato cloud computing. I fattori che hanno permesso il passo evolutivo sono: tec-niche di virtualizzazione, miglioramento dei sistemi di comunicazione, sistemi per ilmonitoraggio delle risorse, tecniche di migrazione delle macchine virtuali, bilanciatoridi carico.

Figura 1.4: Cloud-Providers

A differenza della tecnologia grid, il cloud-computing[15] e ancora in fase di svi-

10 CAPITOLO 1

luppo e non esistono standards condivisi, tuttavia sono presenti numerosi providersche utilizzano il termine servizio-cloud per catturare il concetto di utility-computing.L’utility-computing e un paradigma di computazione secondo cui i servizi rappresentatida capacita computazionali sono offerti a seconda delle necessita degli utenti secondolo schema gia largamente adottato per la fornitura di acqua, elettricita, gas e telefonia,ovvero gli utenti non hanno piu l’esigenza di mantenere le proprie risorse computazio-nali o investire nell’acquisto di nuove e non sono vincolati a specifici computing-serviceproviders, le richieste di utilizzo di capacita computazionali vengono soddisfatte on-demand da uno dei cloud provider, pagando solo le risorse che utilizzano per il solotempo in cui vengono utilizzate.

Figura 1.5: Fase attuale della tecnologia cloud

In termini di infrastruttura, una cloud e un insieme di applicazioni internet-based,di servizi di storage e di computazione sufficienti a supportare la maggior parte deibisogni degli utenti e a disincentivare l’utilizzo di risorse locali. In termini di servizioofferto, il cloud-computing e semplicemente una tecnologia che permette di allocarerisorse di storage e risorse computazionali on-demand.

Il cloud-computing offre una combinazione di funzionalita che includono:

1.3. L’AVVENTO DEL CLOUD-COMPUTING 11

• Una infrastruttura dinamica e scalabile;

• Accesso universale, ovvero accesso da un qualsiasi punto della rete internet;

• Utilizzo, controllo e pagamento di risorse a vari livelli di granularita;

• Piattaforme standardizzate;

• Gestione di servizi di supporto;

L’obiettivo primario della tecnologia cloud-computing e il disaccoppiamento deiservers fisici dalle applicazioni. Nel cloud un utente alloca il numero e il tipo di mac-chine virtuali necessarie ad eseguire un task senza avere la necessita di sapere dove talimacchine sono fisicamente localizzate. Le macchine virtuali eseguono un task fincherichiesto e vengono spente quando il task e completato. Il disaccoppiamento e imple-mentato anche a livello di risorsa allocabile permettendo all’utente di avere un controlloa granularita fine sulle risorse offerte dal cloud, ad esempio i dati generati da un task inesecuzione su una specifica macchina virtuale potrebbero essere utilizzati da task cheverranno eseguiti su macchine virtuali differenti create in momenti successivi rispettoal tempo di spegnimento della macchina virtuale in cui i dati risiedevano, l’utilizzo dirisorse di storage offerte dal cloud permette ad ogni server del cloud di accedere a talidati, rispettando adeguati meccanismi di accesso controllato.

Nel cloud, i server fisici sono risorse condivise,mentre le macchine virtuali sono risor-se utilizzabili esclusivamente dall’utente che le ha create, il numero di macchine virtualiin esecuzione su un insieme di server puo variare nel tempo. Il cloud-provider mette adisposizione un insieme di server fisici pronti a rispondere a specifiche richieste per sup-portare servizi di allocazione, spostamento e spegnimento di macchine virtuali. Ognimacchina virtuale puo essere dedicata a task differenti. L’allocazione e la deallocazionerapida di macchine virtuali associato a tecniche di scheduling e di bilanciamento delcarico, permette al cloud-provider di riuscire a soddisfare le richieste degli utenti e adottenere un utilizzo efficiente delle risorse fisiche.

Le macchine virtuali allocate mediante i servizi on-demand possono essere utilizzateper espletare vari task:

• Esecuzione di workflows;

• Soddisfare i picchi di domanda per la computazione;

• Pianificare e attuare strategie di disaster recovery;

• Eseguire applicazioni distribuite.

Modelli differenti di cloud richiedono o supportano differenti livelli di informazionidi configurazione da parte dell’utente, ovvero l’utente puo configurare le risorse di cuirichiede l’allocazione in modi differenti e dettagliati, ad esempio un utente potrebbespecificare:

12 CAPITOLO 1

• Il numero di server che verranno utilizzati per l’esecuzione di uno specifico task;

• Il numero di server e il ruolo che ognuno di tali server assumera, ovvero potrebbespecificare i server che fungeranno da web-server e quelli che assumeranno inveceil ruolo di application-server.

• Una specifica immagine di macchina virtuale da eseguire su ognuna delle macchinerichieste.

All’utente e concessa anche la possibilita di selezionare i livelli si servizio che piu siadattano alle proprie esigenze.

Gli attributi dei servizi cloud percepiti dall’utente sono[32]:

• On-demand self-service, ovvero capacita di allocare, utilizzare e gestire risorsecomputazionali, di storage e applicazioni senza dover richiedere l’intervento dellostaff IT di supporto;

• Ubiquita dell’accesso, ovvero la possibilita di accedere alle risorse cloud da qual-siasi punto di accesso della rete internet;

• Scalabilita elastica, gli utenti possono decidere quanta risorsa utilizzare in ognimomento, l’allocazione e effettuata a seconda della domanda corrente evitandoun over-provisioning di capacita delle risorse per gestire i picchi di domanda;

• Pagamento flessibile, il modello utilizzato per pagare i servizi cloud si basa sul“pay-as-you-go”, ovvero ogni utente paga solamente le risorse che effettivamentesta utilizzando in ogni dato momento.

1.4 Le potenzialita del Volunteer-Computing

Con volunteer computing si intende la tecnologia con la quale e possibile sfruttare lerisorse sottoutilizzate di macchine connesse alla rete internet per poter offrire serviziequivalenti a quelli forniti dal cloud. I fattori che alimentano la ricerca nel campo delvolunteer computing sono:

• Possibilita di ottenere hardware a basso costo;

• Progressiva diffusione della banda larga per la connessione ad internet;

• Maggior sensibilita verso le tecnologie green;

• Possibilita di avere enorme potere computazionale a costo 0.

Il primo progetto che dimostro le potenzialita del volunteer computing fu SETI@HOME[14]che offrendo la possibilita di collezionare potere computazionale dai cicli CPU in sta-to idle dei desktop-pc ha permesso di risolvere problemi compute-intensive in modo

1.4. LE POTENZIALITA DEL VOLUNTEER-COMPUTING 13

piu efficiente rispetto al piu veloce supercomputer esistente. Da SETI@HOME e na-to il sistema BOINC[13], capostipite di una serie di altri sistemi (Condor, Entropiae GridSat) in grado di fornire tecniche efficienti per l’individuazione e l’allocazione dirisorse computazionali sottoutilizzate. Essi operano principalmente in reti stabili, ov-vero reti con basso dinamismo in cui i nodi sono omogenei e sicuri, e sfruttano unarchitettura centralizzata che se da un lato permette di avere maggior controllo sulsistema e di garantire un certo livello di performance, dall’altro limita la scalabilita edespone il sistema ai classici problemi delle architetture centralizzate: presenza di unsingle-point-of-failure, vulnerabilita ad attacchi di tipo Denial-of-Service e possibilitache il nodo master diventi un collo di bottiglia per le performance globali del sistema.Quindi anche se i sistemi sopracitati ottengono significativi risultati all’interno di retipiccole e controllate, essi non si adattano ad ambienti come internet in cui e possibilesfruttare una quantita enorme di risorse che pero risultano estremamente eterogenee einaffidabili.

Da tali osservazioni sono nati progetti per l’implementazione di sistemi di volunteer-computing che limitano l’utilizzo di strutture centralizzate, nelle prossime sezioni sonoanalizzati alcuni di tali sistemi.

1.4.1 XtremWeb

In XtremWeb[17] i nodi sono funzionalmente suddivisi in 3 categorie:

1. Clients, sono i nodi che possono richiedere al sistema l’esecuzione dei job.

2. Workers,comprende i nodi che eseguono la computazione distribuita.

3. Cooordinators, e formata dai nodi che gestiscono le richieste dei clients e monito-rano l’attivita dei workers.

A differenza di sistemi come Boinc o Condor, i nodi godono di maggiore autonomia, maservizi come indicizzazione e gestione delle risorse restano centralizzati. XtremeWebpermette l’esecuzione di un gran numero di job caratterizzati da bassa correlazione tratask paralleli, come ad esempio BoT (Batch of Task) o MPI (Message Passing Interface).La comunicazione tra i nodi e gestita dal protocollo RPC(Remote Procedure Call). Leprocedure di scheduling delle risorse sono espletate dai nodi coordinatori.

La sicurezza e garantita a vari livelli:

• Per la gestione dei task vengono utilizzati sistemi di protezione della privacy deidati e verifica dei risultati.

• Per lai gestione delle risorse vengono utilizzate tecniche di sandboxing per pro-teggere il sistema da codice malevolo.

Infine sono utilizzate tecniche di replicazione e checkpointing per garantire tolleranzaai guasti.

14 CAPITOLO 1

Personal Devices

Workers LAN

Results Collector

XtremWeb Root Server

Worker

XtremWeb

Server

Legend

Workers

Transactions

Servers

TransactionsPrivate LAN

Collaborators LAN

ISP Server

1

2

3

4

5

6

7

Application

dedicated

0

Personal Devices

Figura 1.6: XtremWeb

1.4.2 Cohesion

Cohesion[37] utilizza JXTA per mantenere una rete P2P non strutturata e altamenteconfigurabile, ottenendo adattivita ad ambienti distribuiti caratterizzati da instabilitae volatilita. Cohesion adotta una architettura a micro-kernel in cui sono incluse solofunzionalita minime, in tal modo garantisce un controllo a granularita fine delle risorsee mitiga la complessita dello scheduling. Cohesion risulta inoltre flessibile per gestirevari modelli di esecuzione parallela fornendo strumenti per la decomposizione dinamicadei job. Il bilanciamento del carico viene effettuato mediante migrazione dei task e leinformazioni sulle risorse sono aggregate mediante una struttura ad albero. La sicurezzae ottenuta mediante tecniche di sandboxing e di trust-management per attribuire unvalore di reputazione agli host. Il fallimento dell’esecuzione dei task viene tolleratomediante la replicazione dei task stessi.

1.4.3 Alchemi

Alchem[4]i permette l’aggregazione di Windows PC-Desktop in stato idle per l’esecu-zione di applicazioni resource-intensive. La comunicazione e la sicurezza sono gestitedal framework .NET. L’architettura adoperata e di tipo gerarchico. Le richieste diesecuzione dei job sono gestite dal nodo manager che provvede a schedularle ai nodi se-condo un modello FCFS. Alchemi non offre alcuna soluzione per i problemi di gestionedei guasti e ripristino delle funzionalita.

1.4. LE POTENZIALITA DEL VOLUNTEER-COMPUTING 15

Solaris Windows Linux Others

Java Virtual Machine (JVM)

OS

Gi P

latfo

rm C

ore

Desktop

Integration

Application

Container

Sensing

Framework

Substrate (XMPP, JXTA)

Discovery

Composable Channels Endpoint Management

Failure DetectionGroup Membership

Host System

Integration

Communication

Virtualization

Task Pool

Load Balancing Termination Detection Fault Tolerance

Programming ModelsApplications

Task

Model

Ma

na

ge

me

nt &

Se

curity

Figura 1.7: Cohesion

Figura 1.8: Alchemi

1.4.4 OurGrid

OurGrid[2] e un middleware open-source che ha lo scopo di permettere la collaborazionetra differenti comunita di ricerca. Tutti gli utenti sono suddivisi in gruppi, gli utentiall’interno del medesimo gruppo interagiscono direttamente tra loro mediante un client-broker chiamato MyGrid. Il fenomeno del free-riding, ovvero la possibilita che utentifungano esclusivamente da consumatori di risorse senza condividere le proprie, e gestitomediante un insieme di metodi chiamato Network of Favors. La protezione dei datilocali e garantita da una tecnica di isolamento basata sulla macchina virtuale Xen.

16 CAPITOLO 1

Figura 1.9: OurGrid

1.5 Il nostro contributo

L’obiettivo del lavoro che verra presentato nel seguito e quello di definire un’architettu-ra di un sistema completamente decentralizzato che sia in grado di offrire le medesimefunzionalita del volunteer-computing. A tal scopo saranno analizzate le tecniche dispo-nibili per poter implementare, secondo un approccio di tipo P2P, le funzionalita basedel sistema:

• Ricerca delle risorse;

• Allocazione delle risorse;

• Gestione del churn.

Verra infine sviluppato un prototipo per testare l’efficacia delle tecniche descrit-te e per fornire una valutazione in termini di prestazione e utilita del sistema e perindividuare possibili utilizzi e migliorie da apportare.

Capitolo 2

Tecnologie P2P per laComputazione Distribuita

Le caratteristiche dei sistemi per il P2P computing sono:

• Mancanza di relazioni di tipo client-server;

• Comunicazione simmetrica;

• Tempi di vita dei peers impredicibili;

• Diretto scambio di informazioni tra i peers.

Il P2P computing permette di:

• Migliorare la scalabilita evitando la dipendenza da punti di controllo centralizzati;

• Eliminare il bisogno di costose infrastrutture permettendo la comunicazione di-retta tra peers;

• Facilitare l’aggregazione di risorse.

La maggiore scalabilita ottenuta dalla decentralizzazione del sistema di controllodella computazione risulta pero limitato da fattori quali la quantita di operazioni chedevono essere eseguite con un approccio centralizzato (come ad esempio le operazionidi sincronizzazione e coordinazione), la quantita sulle informazioni sullo stato dellacomputazione che devono essere conservate, il grado di parallelismo delle applicazioni.

Il requisito basilare del p2p computing e quello di poter suddividere una compu-tazione complessa in unita di computazione di minore complessita chiamati task e dipoterli assegnare a differenti peers affinche vengano processati in parallelo. Il processodi suddividere un programma in task e chiamato decomposizione. Il processo di decom-posizione puo dar luogo a task indipendenti, ovvero un insieme di task che puo essereeseguito in qualsiasi sequenza, o task dipendenti, ovvero insieme di task che per essere

17

18 CAPITOLO 2

completati devono attendere la ricezione dei dati prodotti dal completamento di altritask.

Il numero e la dimensione dei tasks in cui un problema e decomposto determinanola granularita della decomposizione, il processo di decomposizione si dice a granularitafine se genera un gran numero di task, a granularita grossolana altrimenti. Piu lagranularita e fine maggiore sara il livello di concorrenza della computazione e miglioresara la distribuzione tra i nodi, d’altro canto la possibile condivisione di dati di input,di output e intermedi implica un numero maggiore di interazione tra i task che sureti con alta latenza potrebbero comportare un notevole overhead che verrebbe ridottoutilizzando processi di decomposizione piu grossolani.

I paradigmi di computazione possono essere classificati in base al programma asse-gnato ad ogni task . . . :

• Programma Singolo, tutti i task eseguono il medesimo programma, i dati utilizzaticome input sono differenti per ogni task;

• Programma Multiplo, i task eseguono programmi differenti utilizzando come inputil medesimo insieme di dati oppure insiemi di dati differenti.

. . . e dal modo in cui i task interagiscono tra loro:

• Data partitioning, ogni task lavora su una porzione di un insieme di dati. I nodihanno accesso alla medesima memoria condivisa, oppure ricevono i dati da unasorgente dati esterna al nodo. Solitamente si preferisce l’approccio code-to-data,ovvero utilizzare come nodi computazionali i nodi che gia conservano i dati daelaborare. I task sono indipendenti e il risultato della computazione e conservatoanch’esso in una porzione di memoria condivisa.

• Message Passing, ogni task comunica con gli altri tramite invio e ricezione di mes-saggi, tali messaggi contengono informazioni necessarie al task per essere comple-tato. I nodi non condividono porzioni di memoria, ma cooperano utilizzando larete di comunicazione.

• Ibrido, fonde alcuni aspetti dei paradigmi precedenti per poter eseguire task piucomplessi.

La classe di applicazioni descritta e detta classe di applicazioni parallelizzabili ed e perlo piu costituita da applicazioni compute-intensive. Altri tipi di applicazioni p2p sono:

• Applicazione per la gestione dei dati, sono focalizzate sulla conservazione e il recu-pero di dati da vari peers che compongono la rete. Il modello di maggior successodi tali applicazioni e quello basato sullo scambio, come Napster e Gnutella, in cuiad ogni peer e consentito la ricerca e il download di dati resi disponibili dagli altripeers.

• Applicazioni collaborative, permettono agli utenti di collaborare in tempo realeper collezionare e trasmettere informazioni. A tale classe appartengono i sistemidi Instant Messaging come AOL, Skype e Jabber.

2.1. LA RICERCA DI RISORSE IN UN AMBIENTE DINAMICO 19

2.1 La ricerca di risorse in un ambiente dinamico

Con ricerca delle risorse si intende l’insieme delle operazioni finalizzate alla ricerca eindividuazione di risorse del sistema che rispettino determinate caratteristiche.

Il metodo per la ricerca delle risorse adatto al sistema in analisi deve:

• Utilizzare un approccio totalmente decentralizzato;

• Essere scalabile;

• Supportare vari tipi di query;

• Essere robusto nei confronti del dinamismo della rete.

Per implementare un algoritmo adatto a risolvere il problema della ricerca occorre:

• Definire il concetto di risorsa;

• Descrivere come indicizzare e/o caratterizzare le risorse;

• Descrivere il formalismo utilizzato per esprimere le query e le tecniche per sotto-metterle al sistema;

• Descrivere il protocollo con cui il sistema processa la query, comprendendo pro-tocolli di routing e condizioni di matching.

Nel sistema in analisi, la ricerca e indirizzata verso le risorse di tipo computazionali,ovvero l’insieme della configurazioni hardware che permettono ad un nodo di ricevere,processare e inviare un insieme di dati secondo uno schema computazionale non no-to a priori. In genere tali risorse possono essere caratterizzate da 2 tipi di attributiclassificabili come:

• Statici, il cui valore non varia nel tempo, come tipo di sistema operativo, larghezzadi banda, locazione nella rete, dimensione della memoria RAM, architettura efrequenza di clock della CPU e capacita di storage.

• Dinamici, il cui valore puo subire importanti variazioni al trascorrere del tempo,come utilizzazione della CPU, utilizzazione della memoria RAM, spazio di storagedisponibile, utilizzazione della larghezza di banda.

La query e lo strumento con cui un nodo descrive e richiede le risorse che desidera,possono essere rappresentante mediante una combinazione di valori o intervalli di valoridegli attributi delle risorse e possono essere classificate in:

• Esatte: specificano i desiderati valori per tutti gli attributi delle risorse. Esempio:Architettura=x64 and CPU- Speed=1.8 Ghz and RAM=512MB and Spazio liberodi memoria secondaria=300 GB and larghezza di banda=10 GB/s and OS=linux.

20 CAPITOLO 2

• Parziali : sono specificati i valori di solo un sottoinsieme degli attributi. Esempio:Architettura=Macintosh and RAM=1024MB.

• Vincolant i: sono specificati gli intervalli dei valori per alcuni o tutti gli attributi.Esempio 1.8 Ghz < CPU-Speed < 3 GHz and 128MB < RAM < 1024 MB.

• Booleane: sono specificate le condizioni booleane che gli attributi devono soddi-sfare. Esempio: RAM > 512 MB or Spazio libero di memoria secondaria>4GB.

Il processo della ricerca delle risorse e strettamente correlato alla tecnica di indiciz-zazione delle risorse, cioe possibilita di individuare in modo univoco le risorse all’internodel sistema, e dalla raggiungibilita delle risorse, ovvero la possibilita per ogni nodo diinteragire con ogni altro nodo della rete che possiede le risorse richieste.

Le risorse sono strettamente correlate ai nodi della rete, ogni nodo mette a dispo-sizione le proprie risorse ed ogni risorsa e associata ad un solo nodo, all’interno dellarete l’identificativo che permette di individuare ogni nodo e l’indirizzo di rete.

Una volta formulata, la query deve essere sottoposta al sistema, in una rete P2Pin assenza di entita centrali che coordinino tale processo, la sottomissione di queryequivale all’applicazione di un protocollo di routing. Questo processo e inevitabilepoiche non e possibile conservare all’interno di ogni singolo nodo le informazioni chepossano descrivere l’intero insieme delle risorse della rete.

I metodi per il forwarding delle query, ovvero per la scelta dei nodi a cui inviare laquery, puo essere di tipo deterministico, se e basato su una conoscenza a priori dellarete, o probabilistico, se il routing e casuale o si basa su un certo tipo di probabilita.

Le DHT sono la tecnologia dominante per il resource discovery in reti P2P di tipostrutturato, vengono utilizzate in sistemi come Chord, Pastry e Tapestry, e sono ingrado di fornire servizi di query routing mediante O(log N) messaggi e l’aggiornamentodella rete mediante O(log2N) messaggi. I nodi sono organizzati secondo una topologiaad anello, ogni nodo mantiene una piccola finger table che e utilizzata per reindirizzarele query agli altri nodi finche raggiungono il nodo corretto, ovvero il nodo che indicizzale risorse aventi determinati attributi. La DHT fornisce un metodo veloce e sicuro per ilrouting delle richieste, ma puo non rappresentare la soluzione migliore. Infatti la DHTpossiede lo svantaggio di poter garantire il routing efficiente di query 1-dimensionali,ovvero query che esprimono vincoli su uno solo degli attributi delle risorse. Tecniche perpoter estendere la capacita delle DHT per supportare query d-dimensionali prevedonol’utilizzo di:

• Curve Space filling, come ad esempio la curva di Hilbert[9] o la curva-Z[19];

• Strutture dati basate sugli alberi, come i Quad-Tree[16] o gli R-Tree[5];

• Hashing tramite SHA[40];

Questi se da un lato risolvono il problema della limitazione delle risorse ricercabili,dall’altro inducono un overhead maggiore perdendo l’upper bound logaritmico che leDHT originarie erano in grado di fornire.

2.1. LA RICERCA DI RISORSE IN UN AMBIENTE DINAMICO 21

Per le reti non strutturate il routing delle query e invece effettuato tramite la tecnicadel flooding. Il flooding e utilizzato con successo in reti come Gnutella e FreeNet, incui permette di supportare la ricerca di file in un ambiente distribuito e altamentedinamico, ma presenta alcuni svantaggi. Tali svantaggi riguardano l’impredicibilita deitempi necessari a completare il processamento della query e la possibilita che la querynon produca risultati poiche la risorsa desiderata si trova su di un nodo posto al difuori dell’orizzonte della query, ovvero non appartiene all’insieme dei nodi raggiuntidalla query.

Quella basata sul flooding e una tecnica di ricerca definita di tipo cieco, i nodi nonhanno alcun tipo di conoscenza a priori sulla rete, esempi di utilizzo di tale tecnicasono:

• BFS(Breadth First Search)[29], utilizza il flooding delle query tramite broadcaste associa ad ogni query un Time-To-Live per limitare la profondita della ricerca.Tale tecnica utilizza un enorme quantita di traffico dati non necessario e nellascalabilita limitata al valore del Time-To-Live, le risorse al di fuori dell’orizzontedella query non vengono mai scoperte;

• RBFS(RandomBreadthFirstSearch)[20], la scelta del numero di nodi a cui inviarela query e casuale. In tal modo e possibile ovviare al problema del traffico eccessivodi messaggi generato dal BFS, ma la probabilita che la query non raggiunga i nodiche possiedono le risorse desiderate e maggiore.

• Ricerca Iterativa in Profondita[11], consiste nell’eseguire piu BFS con diversi va-lori del Time-To-Live. Questo metodo permette di avere maggiore scalabilita ri-spetto al BFS, ma risulta lento e ogni nodo puo dover processare un gran numerodi repliche della medesima query.

• Random Walks[25], il numero di nodi a cui la query e inviata e limitata ad unnumero scelto in modo casuale, tale numero e diverso per ogni nodo che reinviala query ricevuta, la terminazione e assicurata dall’utilizzo del Time-To-Live.Il vantaggio principale di questa tecnica e quello di avere un bilanciamento delcarico locale ad ogni nodo per il processamento di query, ma le performancesdell’algoritmo sono variabili e dipendono dalla scelta del numero casuale effettuatada ogni nodo.

• Flooding con k Random Walks Indipendenti [34], effettua dapprima un BFS che hal’obiettivo di scoprire k nuovi nodi, dopodiche vengono eseguite k random walksa partire dai k nodi scoperti.Combina i vantaggi del flooding e del random walks,ma l’overhead per lo scambio dei messaggi nella rete e molto alto.

Nella ricerca informata i peers mantengono informazioni di routing per il forwardingdelle query. Tali informazioni sono basate su parametri che possono indirizzare la que-ry verso nodi in grado di fornire le risorse richieste. Le tecniche basate sulla ricerca

22 CAPITOLO 2

informata hanno performances migliori rispetto alle tecniche di ricerca cieca, ma richie-dono che ogni nodo conservi e aggiorni un insieme di indici. Un elenco di algoritmi cheimplementano tale tecnica e costituito dai seguenti:

• DFBS(DirectedBreadthFirstSearch)[41], ogni nodo invia la query a un sottoinsie-me dei suoi nodi vicini, la scelta di tali nodi si basa su informazioni ottenute daprecedenti BFS e comprendono il numero di risultati che sono stati ottenuti daogni nodo e la latenza con cui la query e stata processata. L’obiettivo e quellodi ridurre i tempi di risposta delle query, migliorare la probabilita di trovare larisorsa desiderata, migliorare la scalabilita di BFS. Gli svantaggi di questa tec-nica sono rappresentati dall’elevato numero di informazioni che ogni peer deveconservare e dalla mancanza di flessibilita nei confronti del churn-rate.

• Ricerca Probabilistica Adattiva[10], la ricerca e basata su k probabilistic walks.,in cui ogni nodo invia la query al vicino con probabilita data dall’indice di talevicino. L’indice di ogni nodo e calcolata in base al risultato di ogni walk, l’indicee incrementato se la query e soddisfatta, mentre e decrementato se la query nontrova alcun matching.Tale tecnica possiede buona robustezza rispetto ai cambia-menti nella topologia della rete, ma puo presentare forti sbilanciamento di carico,le query sono indirizzate verso i primi peers scoperti dall’algoritmo trascurandogli altri vicini che potrebbero fornire risultati simili.

• GIA[42], ogni nodo invia la query al vicino avente maggior capacita, l’invio diogni query e preceduta da un protocollo di handshake in cui il nodo riceventeinforma il nodo mittente del proprio carico di lavoro per il processamento dellequery. Tale tecnica offre un efficiente metodi per il bilanciamento del carico, mainduce overhead di comunicazione tra i nodi ed esclude dal routing delle query inodi che hanno minor capacita ma maggior probabilita di poter trovare la risorsarichiesta.

• Ricerca Adattiva Basata sulla Popolarita[30], invece di basarsi sulle caratteristichedei nodi, tale protocollo utilizza una stima della popolarita di ogni risorsa richiestaper scegliere i paramentri con cui inizializzare le random walks. Gli svantaggi ditale algoritmo sono la mancanza di meccanismi per il bilancimento del caricodi ogni nodo e la necessita di dover conservare un gran numero di informazionirisultando poso scalabile rispetto al numero di risorse differenti che risiedono nelsistema.

2.2 Allocare risorse senza controllo centralizzato

In questa sezione si analizzano le tecniche esistenti per l’allocazione, o scheduling, dellerisorse, ovvero la possibilita che un utente possa richiedere l’utilizzo esclusivo per uncerto periodo di tempo di risorse condivise per l’esecuzione di job.

2.2. ALLOCARE RISORSE SENZA CONTROLLO CENTRALIZZATO 23

Durante l’allocazione delle risorse, i consumatori e i fornitori di risorse possiedonodifferenti funzioni obiettivo:

• La funzione obiettivo del consumatore e centrate sulle applicazioni,poiche il suoscopo e quello di ottimizzare le performances di ogni job. Le performances di unjob riguardano il makespan, ovvero il tempo che intercorre tra l’inizio dell’esecu-zione del primo task alla fine dell’ultimo task di cui il job e composto, e, nel casodell’introduzione di un modello economico per l’utilizzo delle risorse, del costonecessario per completare l’esecuzione.

• La funzione obiettivo del fornitore e centrate sulle risorse, il suo fine e quello diottimizzare le performances delle risorse. In tal caso con il termine performancesci si riferisce al throughput, ovvero capacita di una risorsa di processare un certonumero di jobs in un dato intervallo di tempo, e utilizzazione, definita comepercentuale di tempo in cui la risorsa e occupata. L’incentivo alla condivisionedelle risorse puo essere ottenuto mediante l’introduzione di un modello economicobasato sulle metriche sopracitate.

L’entita che stabilisce quali e a quale utente le risorse possono essere allocate vienechiamata scheduler. Il processo di allocazione deve essere completamente decentraliz-zato e deve fornire la garanzia che le richieste di allocazione vengano soddisfatte entroun certo intervallo di tempo. Gli strumenti adottati dallo scheduler sono la scopertadei peers che compongono la rete, la stima dello stato di ogni peer e la disseminazioneall’interno della rete di informazioni sulle proprie attivita.

Una prima classificazione delle tecniche di allocazione puo essere effettuata traschedulers statici e schedulers dinamici.

Negli schedulers statici[21] ogni task che compone il job viene assegnato una voltasola alle risorse. La stima del costo dell’esecuzione di un task su un determinato nodoviene effettuata prima dell’inizio dell’esecuzione.Possono essere utilizzate euristiche perstimare il tempo di completamento dei task su un determinato nodo e l’affidabilita,ovvero la probabilita che la risorsa allocata non si guasti, o lasci il sistema, prima diterminare il task. Tale approccio richiede una conoscenza della rete globale per poterallocare le risorse migliori disponibili, maggiore e la quantita di informazioni conservateda ogni nodo, migliore e la scelta delle risorse da allocare.

Negli schedulers di tipo dinamico[23], ogni task puo essere assegnato piu volte anodi differenti, l’allocazione iniziale puo essere modificata eseguendo una migrazionedel task da un nodo ad un altro, cio permette di evitare la stima iniziale del tempo dicompletamento dei task. Tale approccio consente di tener maggiormente in considera-zione la natura dinamica della rete, consentendo il rescheduling dei task quando risorsemigliori sono rese disponibili o per ottenere un miglior bilanciamento del carico. Lascelta del nodo dove migrare il task puo basarsi sulle seguenti tecniche:

• Opportunistica, viene selezionato il nodo con il minor numero di task accodati.E’ l’approccio piu semplice per effettuare il bilanciamento del carico che pero nonrisultera quello ottimale.

24 CAPITOLO 2

• Bilanciata, la migrazione dei task accodati viene effettuata in modo periodico perottenere il medesimo numero di task allocati su tutti i nodi. Con tale tecnicasi ottiene un bilanciamento di carico migliore rispetto al primo, ma richiede unconsiderevole traffico dati per lo scambio di informazioni sullo stato della coda diogni nodo. Tale traffico puo essere minimizzato limitando il bilanciamento soloal vicinato del nodo considerato.

• Vincolata dal costo, oltre allo spostamento periodico dei task accodati viene ese-guita una stima del tempo di esecuzione sul nuovo nodo, se il costo di migrazionedel task e maggiore rispetto al tempo di esecuzione stimato, allora il task nonviene spostato. L’efficienza di tale tecnica e tanto maggiore quanto maggiori sonogli overheads di comunicazione della rete con cui sono connessi i nodi.

Un’altra classificazione degli schedulers e basata sul concetto di cooperazione.Negli scheduling di tipo cooperativo[7], ogni scheduler agisce in accordo con gli altri

per raggiungere un obiettivo comune, ovvero massimizzare il throughput globale delsistema.

Nel caso di scheduling non-cooperativo[35], ogni scheduler agisce in modo autonomoper ottimizzare la propria funzione obiettivo, agendo quindi in modo egoistico senzacurarsi dell’effetto delle proprie decisioni sul resto del sistema.

Altri tipi di scheduling sono stati sviluppati mediante l’utilizzo di tecniche diffe-renti da quelle tradizionali citate finora. L’utilizzo di tali tecbiche e giustificata dacaratteristiche del sistema come autonomia dei nodi,modelli di interazione tra di essie cambiamenti dinamici dello stato delle risorse. Tra gli approcci di scheduling nontradizionali vi sono quelli basati su:

• Modello di asta[43], in cui ogni scheduler a seconda della propria disponibilitaeconomica, propone un offerta per allocare una determinata risorsa. Lo schedulerche effettua la migliore offerta si aggiudica l’allocazione della risorsa, il nodoproprietario di tale risorsa ottiene un guadagno con cui effettuare a sua voltaofferte per future operazioni di allocazione di risorse remote.

• Equilibrio di Nash[24], in cui ogni task e modellato come un giocatore e le possibilistrategie sono i nodi su cui puo essere eseguito.

• Algoritmi genetici [24], in cui le possibili soluzioni sono l’assegnazione dei taska specifici nodi, il valore di fitness e il makespan dei mapping task-nodo e ilcross-over e lo scambio dell’assegnazione dei task tra due nodi differenti.

• Simulated annealing [3], in cui l’equilibrio termico e rappresentato dall’assegna-zione ottimale tra task e nodi, la temperatura e il tempo totale di completamentodei task secondo l’attuale allocazione, il cambio di temperatura e il processo dimodifica del mapping task-nodo.

• Ricerca Tabu[1], in cui l’allocazione iniziale viene modificata mediante la ricercadi un nodo la cui allocazione riduce il makespan del job. La ricerca termina

2.3. LA RILEVAZIONE DEI GUASTI 25

quando la riduzione del makespan ottenuta dall’ultimo cambiamento e inferiorerispetto ad una data soglia.

2.3 La rilevazione dei guasti

La scalabilita delle reti P2P permette di avere sistemi formati da un numero di nodiconsiderevole, se da un lato cio permette di poter usufruire di maggior risorse, dall’altroespone il sistema ad una maggior probabilita che al suo interno si verfiichino guasti,che possono essere:

• Guasto fisico del nodo;

• Guasto del link di comunicazione che connette il nodo alla rete;

• Disconnessione del nodo dalla rete.

Le tecniche utilizzate per individuare tali guasti in un ambiente decentralizzato sibasano sull’utilizzo del gossip in cui ogni nodo mantiene una tabella locale, ogni entry ditale tabella e associata ad un nodo che conosce, in ogni entry e contenuto un contatorechiamato heartbeat, durante l’esecuzione del protocollo di rilevamento dei guasti si hache:

1. Ogni nodo sceglie un gruppo di altri nodi;

2. Ad ogni nodo scelto viene inviata la tabella locale in cui il nodo mittente haincrementato il proprio heartbeat;

3. Quando un nodo riceve una tabella, la fonde con la tabella locale adottando perogni entry comune l’heartbeat maggiore;

4. Se dopo un certo intervallo di tempo un nodo rileva che un dato heartbeat non estato incrementato, allora il nodo a cui e associato tale heartbeat viene sospettatodi guasto;

5. Per ogni nodo sospettato di guasto viene eseguito un protocollo di consenso permantenere le informazioni coerenti su tutti i nodi.

Un sistema per il rilevamento di nodi guasti si basa su 3 parametri:

• Tempo di gossip, e l’intervallo di tempo che intercorre tra l’invio di due messaggidi gossip consecutivi;

• Timeout, e il tempo massimo dopo il quale un nodo viene sospettato di guasto;

• Tempo per il consenso, e l’intervallo di tempo necessario per raggiungere il con-senso sul guasto di un dato nodo.

26 CAPITOLO 2

La difficolta maggiore per l’implementazione di un rilevatore di guasti e la sceltadel timeout, utilizzare valori troppo piccoli puo generare falsi positivi causando unnotevole aumento del traffico di rete per completare il protocollo di consenso, mentrevalori troppo grandi causano un ritardo nella procedura di identificazione dei nodiguasti che potrebbero compromettere le funzionalita del sistema.

Alcune variazioni sono state proposte con l’intento di migliorare il protocollo pre-cedentemente descritto, tra queste:

• Invio dei messaggi in Round-Robin, ha lo scopo di minimizzare e rendere piauniforme il traffico dei messaggi. Ad ogni round di esecuzione dell’algoritmo,ogni nodo riceve ed invia un solo messaggio, la scelta del nodo d a cui inviare ilmessaggio e basata sull’identificativo del nodo mittente s e dal numero di roundcorrente r, d = r+s. Dopo l’esecuzione di un numero di round pari alla dimensionedella rete meno uno, ogni nodo avra comunicato con ogni altro nodo della rete.

• Invio dei messaggi in Round-Robin binario, riduce la banda utilizzata per l’inviodei messaggi eliminando i messaggi di gossip ridondanti. La scelta del nodo desti-natario di ogni messaggio e data da d = (s+ 2r−1)mod(n) dove n e la dimensionedella rete.

Capitolo 3

Progettazione e Implementazionedel sistema Cloud-to-Peer

In questo capitolo e presentato Cloud-to-Peer. Cloud-to-Peer e un sistema che puo esse-re inserito nella classe dei sistemi di volunteer-computing, la sua peculiarita rispetto aisistemi esistenti e la completa decentralizzazione di tutte le sue funzionalita. L’utenteche utilizza Cloud-to-Peer e in grado di eseguire task complessi che richiedono note-voli risorse computazionali e tempi di completamento non banali sfruttando le risorseremote offerte dal sistema. L’intero processo di sottomissione e allocazione dei jobs etrasparente all’utente, ricalcando il modello di servizio Infrastructure as a Service(IaaS)offerto dalla tecnologia cloud: il sistema fornisce le risorse, l’utente definisce il softwareche puo essere eseguito su tali risorse.

Nel seguito viene fornita una descrizione piu dettagliata di Cloud-To-Peer utiliz-zando:

• Modello Fisico, viene analizzata la composizione hardware del sistema con riferi-mento all’insieme di computers e altri dispositivi e rete di interconnessione tra diessi.

• Modello Architetturale, analizza il middleware che coordina e controlla il siste-ma fornendo una descrizione delle funzionalita e dell’interfaccia fornita da ognimodulo.

• Protocolli e Interazioni tra i Moduli utilizzati per garantire che le funzionalitaofferte dal sistema vengano rispettate.

3.1 Modello Fisico

Il sistema e composto da una piattaforma hardware composta da un numero indefi-nito di computers, o host, connessi tra loro, la rete viene gestita mediante la suite diprotocolli TCP/IP. Non vi sono assunzioni sulla particolare configurazione hardware

27

28 CAPITOLO 3

che ogni computer deve possedere, nel sistema possono essere presenti varie architetturehardware con risorse computazionali (CPU e memoria di lavoro) e dispositivi di storageeterogenei.

Tra gli host non vi sono divisioni di ruolo, ognuno e sia fornitore che consumatoredi risorse, l’ unica eccezione e rappresentata dal server utilizzato per il bootstrap dellarete. Il server di bootstrap consente ad ogni host di connettersi alla rete P2P, costituiscedunquei il punto di aggancio degli host al sistema. L’utilizzo di un server per l’accessoalla rete e reso necessario dal ben noto problema del bootstrapping che affligge ognirete P2P e di cui ad oggi vi sono soluzioni decentralizzate solo per reti di piccoledimensioni[12].

Ogni host non e vincolato a possedere specifici componenti software come ad esempioun particolare sistema operativo, l’unico requisito e quello di possedere una java virtualmachine che fornisce la virtualizzazione necessaria per l’ambiente di esecuzione dei task.

3.2 Modello Architetturale

L’architettura utilizzata per implementare il middleware del sistema e rappresentata infigura 3.1. Ogni utente e in grado di interagire direttamente con il sistema utilizzandol’interfaccia utente, le comunicazioni tra nodi avvengono mediante socket utilizzandoi protocolli forniti dalla rete di comunicazione a cui ogni host e connesso. Nel seguitoe fornita la descrizione di ogni componente che costituisce il middleware utilizzandol’astrazione della composizione basata su eventi asincroni[36] in cui ogni componentedel sistema, denominato modulo, fornisce una interfaccia composta dagli eventi chericeve e che produce. Ogni evento puo 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 entita a cui e possibile richie-

dere l’esecuzione di jobs che possono essere scomposti ed eseguiti in parallelo. Persottomettere 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;

• Numero dei nodi da allocare per eseguire il jar;

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 chunckdi dati aventi dimensione pari a:

Dimensione file di input / numero nodi allocatiIl partizionamento non tiene conto del contenuto o tipo di file da partizionare,

ogni nodo ricevera un chunck di dati avente la medesima dimensione e tali che laconcatenazione di tutti i chunck permette di ricostruire il file di input originario.

Le indicazioni sulla configurazione hardware dei nodi da allocare consiste nelladefinizione di vincoli sulla:

• Frequenza di clock della CPU;

• Dimensione della memoria di lavoro;

• Capacita di storage.

L’interfaccia offerta dal modulo e composta da:

SUBMIT JOB(req) Richiede l’esecuzione di un determinato job con un determinatoinput. Req e il path del file contenente la richiesta dell’utente. Tale file conterra

30 CAPITOLO 3

il nome del codice eseguibile (in formato jar) del job, il nome del file che verrrautilizzato come input, la configurazione hardware minima dei nodi che verrannoallocati per eseguire il job.

STATUS(state) indica all’utente lo stato di avanzamento della computazione. Lacomputazione puo trovarsi in uno dei seguenti stati:

• RESOURCE ALLOCATION, indica che il sistema e nella fase di allocazionedelle 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 ein attesa che la computazione distribuita termini.

• RETRIVING OUTPUT, indica che la computazione distribuita e terminatae il risultato e in fase di trasmissione verso il nodo locale.

• COMPLETED, indica che la computazione distribuita e terminata e l’outputsi trova in un file del dispositivo di storage locale.

• INTERRUPTED, indica che la computazione e stata interrotta senza portarea 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 puo inqualsiasi momento eseguire la disconnessione interrompendo la condivisione dellerisorse locali.

CONNECT() , richiede la connessione dell’host alla rete e abilita la condivisione dellerisorse locali.

3.2.2 Local Cache

E’ il componente del sistema che interagisce con il sistema operativo per accedereai dispositivi di storage del nodo. I dati utilizzati dal sistema sono contenuti in filesorganizzati 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 adogni 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 datype(specifica se i dati sono di input, ouptut o codice eseguibile) e l’identificativoda name;

PUT DATA(type,name) , richiede l’allocazione di un file di tipo specificato da typecon identificativo name;


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 risorsecomputazionali 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 valorenon viene notificato agli altri nodi del sistema, ma viene utilizzato per stabilire unacondizione di disconnessione del nodo dal sistema, quando il suo valore supera la sogliadel 30%, viene automaticamente attivata la procedura di leave che consentira all’host didisconnettersi 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 sottodella soglia del 30%, il nodo eseguira la procedura di join per tornare a far parte dellarete P2P e condividere nuovamente le risorse computazionali locali.

L’automazione della procedura di join/leave appena descritta, consente all’utentedi non percepire alcun cambiamento nelle performances del proprio PC-Desktop, datoche l’utilizzo del nodo da parte dell’utente locale avra sempre priorita maggiore rispettoall’utilizzo da parte di utenti remoti.

3.2.4 Remote Resource Catalog

Il RemoteResourceCatalog(RRC) si occupa di conservare informazioni sulle risorse deinodi che compongono la rete. Le informazioni sulle risorse remote sono rappresentatemediante tuple del tipo:

< ID nodo,<tupla risorse computazionali>, delay comunicazione >

dove:

• ID nodo e l’identificativo del nodo all’interno della rete, corrisponde all’indirizzoIP;

32 CAPITOLO 3

• <Tupla risorse computazionali> e composta da: <numero di CPU, frequenza diclock delle CPU, dimensione della memoria di lavoro, percentuale di utilizzo dellamemoria di lavoro, spazio di storage disponibile>;

• Delay di comunicazione e il tempo necessario a trasferire uno stream di dati paria 100KB verso il nodo.

Conservare le informazioni sulle risorse remote nel nodo locale permette di averetempi di query costanti, il tempo necessario per ottenere informazioni sulle risorseremote corrisponde al tempo necessario per interrogare la tabella per cercare i nodi icui attributi rispettino i vincoli richiesti dalla query.

L’interfaccia e costituita da:

GET NODE( n,<tupla risorse computazionali> ) richiede gli identificativi di unnumero di nodi pari a n le cui risorse computazionali hanno attributi con valoripari o maggiore a quelle indicate in <tupla risorse computazionali>, a parita divalore 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 nodoidentificato con ID nodo;

DELETE NODE(ID nodo) richiede la rimozione dal catalog della entry associataal 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 sipoggia il sitema di ricerca delle risorse, ovvero e il modulo che implementa l’ OverlayManagement Protocol(OMP). Tale rete utilizza l’astrazione del virtual node, ovveroi nodi sono suddivisi in piccoli gruppi, i nodi all’interno del medesimo gruppo sonoconnessi l’uno con l’altro secondo la topologia della clique. All’interno di ogni virtualnode 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 numerodi nodi fisici compreso tra due intervalli: max-size e min size.

Quando la dimensione del virtual node e inferiore alla soglia del min-size, vengonoattivati gli attratori, ovvero una procedura atta a spostare all’interno del virtual nodenodi fisici che appartengono ad altri virtual nodes, la scelta del virtual node da cuiprelevare 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 accetterapiu nuovi nodi, se le dimensioni di tutti i virtual nodes raggiungono la soglia definita


da max-size, allora l’ingresso nella rete di nuovi nodi portera alla formazione di nuovivirtual 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 unatopologia 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 unaoverlay network caratterizzata:

• Diametro piccolo, che consente di utilizzare un meccanismo veloce per il routingdelle query;

• Buona scalabilita;

• Possibilita di definire una condizione deterministica per la funzione di attrazioneprecedentemente descritta, tale condizione stabilisce che la migrazione dei nodipuo essere fatta solo verso i livelli piu bassi dell’albero, ovvero i virtual nodespossono attrarre solo i nodi che si trovano nei virtual nodes a cui sono legati dallarelazione padre-figlio all’interno dell’albero.

VLr,j

VNi

AB

C

DE

F

VNkG

H

IL

MVNj

NOVNh

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 daiseguenti passi:

1. Un nodo ni invia una richiesta di query q ad uno dei nodi nr che compongono ilvirtual node radice del virtual tree;

2. nr produce un messaggio QUERY (q) contenente la descrizione di tutti i nodi chenel dato istante commpongono il virtual node a cui nr appartiene;

3. nr invia QUERY (q) a tutti i nodi appartenenti al virtual node radice e ai nodiche compongono i virtual nodes del livello 1 dell’albero:

34 CAPITOLO 3

4. Quando un nodo nj appartenente ad un virtual node di livello x riceve QUERY (q)esegue la seguente procedura:

(a) esegue i passi 2 e 3;

(b) invia un messaggio QUERY REPLY (q, valuej) a tutti i nodi del propriovirtual node;

(c) attende finche:

i. colleziona da tutti i nodi nk descritti in QUERY (q) i messaggiQUERY REPLY (q, valuek) e

ii. riceve un messaggio CHILD QUERY REPLY (q, valV Ny) da almenoun nodo contenuto in ogni virtual node figlio V Ny.

(d) valuta la query in base all’insieme di valori collezionati nella fase 2 e suivalori valV Ny ottenuti dai nodi del livello inferiore;

(e) invia un messaggio CHILD QUERY REPLY (q, valV Nx) a tutti i nodi checompongono 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 volunteercomputing che stiamo analizzando offre le seguenti funzionalita:

• Garantire che i nodi rimangano connessi anche in presenza di ambienti dinamicicon livelli di churn rate impredicibili;

• Supportare il routing di query valide, ovvero di query la cui risposta e costruitamediante il contributo dei nodi che sono connessi al sistema durante l’intervallodi tempo che va dall’istante di sottomissione della query all’istante di ricezionedella risposta.

L’intero processamento delle query e le operazioni di migrazione dei nodi vengononascoste agli altri moduli del sistema, l’interfaccia offerta e composta semplicementeda:

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 unaquery per distribuire le informazioni sulle risorse computazionali possedute dalnodo locale.

3.2.6 Message Handler

Il Message Handler si occupa della ricezione e smistamento dei messaggi ricevuti tramitesocket dagli altri nodi della rete. I messaggi sono in formato XML e sono differenziatiin:


• 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 nodoidentificato con ID nodo;

MESSAGE RECEIVED(mess,ID nodo) indica la ricezione di un messaggio messinviato dal nodo identificato con ID nodo.

3.2.7 Job Tracker

Il Job Tracker monitora l’esecuzione della computazione distribuita fungendo anche dafailure detector per i nodi che partecipano alla medesima computazione. Ogni nodoall’interno della computazione puo 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, ogninodo che esegue un task indipendente invia periodicamente un messaggio al proprionodo aggregatore contenente l’identificativo del job in esecuzione, l’identificativo deidati di input in elaborazione e l’identificativo del nodo che ha richiesto l’esecuzionedel job. Quindi i nodi che eseguono i task indipendenti sono nodi monitorati. Ogninodo che esegue un task di aggregazione inizializza un insieme di timer associati adognuno dei nodi da cui aspetta il risultato da aggregare. Alla ricezione del messaggiodi 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’attivazionedel 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.

36 CAPITOLO 3

3.2.8 Slicing Service

Lo Slicing Service si occupa dell’allocazione delle risorse. Il suo compito e assicurarsiche venga allocato il numero di nodi richiesti e che, in caso di guasti, ogni nodo guastovenga rimpiazzato da un altro nodo della rete avente configurazione hardware adeguata.


CREATE SLICE( n,<tupla risorse computazionali> ) richiede che un numerodi nodi pari a n vengano allocati, <tupla risorse computazionali> e l’insieme divalori minimi che la configurazione dei nodi allocati deve possedere.

ADD NODE(ID nodo) richiede l’aggiunta di un nuovo nodo identificato da ID nodoal cluster di nodi allocato.

3.2.9 Job Manager

Il Job Manager si occupa della gestione delle richieste di esecuzione dei jobs. Talegestione viene espletata sia a livello locale che a livello globale. A livello locale sioccupa 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 risorsenecessarie alla computazione distribuita;

• Collezionare statistiche sulla computazione(come ad esempio: numero di guastiverificatisi, tempo necessario a completare la query, tempo necessario a completarel’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.


3.3. PROTOCOLLI E INTERAZIONI TRA MODULI 37

INIT JOB(ID job, ID input, n, <tupla risorse computazionali> ) , richiede laconfigurazione di un cluster di nodi per eseguire la computazione distribuita.Ladimensione del cluster richiesto e indicata da n, la configurazione hardware diogni nodo e vincolata da <tupla risorse computazionali>, il job da eseguire e idati da elaborare sono indicati rispetivamente da ID job e ID input.

SET JOB(path jar) , richiede l’impostazione del path del file jar che rappresenta ilcodice eseguibile del job.

SET INPUT(path input) , richiede l’impostazione del path del file utilizzato comeinput.

SET OUTPUT(path output) , richiede l’impostazione del path del file utilizzatoper conservare l’output.

SET SLICE(<lista ID nodi>) , richiede che i nodi contenuti in <lista ID nodi>vengano utilizzati per eseguire la computazione distribuita

JOB COMPLETED(path output) , indica che il job e stato completato fornendoil path del file di output .

JOB INTERRUPTED(error) , indica che il job e stato interrotto fornendo il mes-saggio di errore prodotto dall’esecuzione del task.

3.3 Protocolli e Interazioni tra Moduli

In questa sezione e mostrato come l’interazione tra i moduli precedentemente descrittipermette al sistema di espletare funzioni piu complesse, per ognuna di esse e associatala sequenza di eventi prodotti dal sistema.

3.3.1 Sottomissione di Job

Lo schema che descrive la gestione e l’esecuzione delle operazioni necessarie ad inizia-lizzare il sistema per l’esecuzione di uno specifico job fornito da un utente e mostratoin figura 3.3. La sequenza di eventi raffigurata e composta da:

1. SUBMIT JOB(req).L’utente fornisce al sistema le istruzioni per configurare ilcluster di nodi che eseguiranno la computazione distribuita.

2. INIT JOB(ID job, ID input, n , <tupla risorse computazionali>). In base alleinformazioni dell’utente viene generata una richiesta al modulo JobManager perinizializzare la computazione distribuita.

3. GET PATH(JAR, ID job) GET PATH(INPUT,ID input). Vengono richiesti ipath del codice eseguibile del job e dei dati da elaborare.

38 CAPITOLO 3

4. SET JOB(path jar) SET INPUT(path input). Il Job Manager acquisisce infor-mazioni sulla locazione del file eseguibile del job e del file di input associato.

5. CREATE SLICE(n,<tupla risorse computazionali>).Viene rischiesta l’allocazio-ne dei nodi secondo le istruzioni fornite dall’utente.

6. GET NODE(n,<tupla risorse computazionali>). Viene interrogato il RRC perottenere gli identificativi dei nodi aventi risorse adeguate.

7. ADD NODE(ID nodo). Lo SlicingService riceve le informazioni disponibili suinodi della rete che possono essere allocati.

8. SEND MESSAGE(ALLOCATION REQ,ID nodo). Ad ogni nodo individuato nelpasso precedente viene inviato un messaggio di richiesta di allocazione.

9. MESSAGE RECEIVED(ACK, ID nodo) oppure MESSAGE RECEIVED(NACK,IDnodo). Per ogni messaggio inviato, viene ricevuto un messaggio di rispostache notifica se le risorse del nodo remoto sono state allocate (ACK) oppureno(NACK).

10. SET SLICE(<lista ID nodi>). I nodi allocati sono comunicati al JobManager.

11. SEND MESSAGE(JAR,ID nodo) SEND MESSAGE(INPUT,ID nodo). Ad ogninodo allocato viene inviato il codice eseguibile del task e la porzione dei dati diinput da elaborare.

12. SET JOB CONFIG(ID nodo locale,ID job,ID input,< llista nodi>). Viene atti-vato il monitoraggio dei nodi elencati in <lista nodi> per rilevare la presenza dieventuali guasti durante l’elaborazione.

3.3.2 Esecuzione/Interruzione/Completamento del job

I nodi allocati per l’esecuzione della computazione distribuita ricevono:

• Il chunck di dati che costituisce l’input del job;

• Il codice eseguibile del job;

• Le istruzioni per portare a termine la computazione.

Le istruzioni che ogni nodo riceve comprendono:

• Eventuali parametri aggiuntivi per l’esecuzione del job;

• Una lista di nodi da cui ricevere l’output ottenuto dall’esecuzione dei task indi-pendenti su differenti chunck di input. Tale lista puo essere vuota, in tal caso ilnodo eseguira solo il task indipendente;


Figura 3.3: sottomissione di job

• L’identificativo del nodo verso cui inviare il risultato della computazione localecostituita dall’esecuzione del task indipendente e da eventuale esecuzione di taskdi aggregazione.

In base alle istruzioni ricevute, l’insieme di nodi allocati verra organizzato secondouna struttura ad albero chiamata albero computazionale. In tale albero ogni nodofoglia eseguira solo il task indipendente,i nodi intermedi del livello i eseguiranno un taskindipendente e k task di aggregazione dove k = h− (i + 1)) e h e l’altezza dell’albero,il nodo radice eseguira il task indipendente, h task di aggregazione e inviera il risultatodella computazione al nodo proprietario del job.

L’esecuzione viene interrotta solo quando:

• Si verifica un errore durante l’esecuzione di uno qualsiasi dei task;

• Viene rilevato un nodo guasto e anche il proprietario del job risulta guasto, in talcaso non puo essere eseguita la procedura di sostituzione del nodo guasto.

In figura3.5 sono raffigurati gli eventi generati all’interno del sistema per l’esecuzio-ne/interruzione/completamento del job:

1. GET PATH(output, identificativo dei dati di output). Al termine dell’esecuzionedel task indipendente, il JobManager richiede i dati prodotti dal task.

40 CAPITOLO 3

A B c D

B

D

D

Task Indipendenti

Task di Aggregazione

Output del Job

Codice Eseguibile del Job Dati di Input

Figura 3.4: Albero computazionale

2. SET OUTPT(path file di output). Il JobManager riceve il path completo del fileutilizzato per conservare l’output prodotto dal task completato.

3. SEND MESSAGE(OUTPUTt,nodo aggregatore) oppure in caso di occorrenza dierrori durante l’esecuzione SEND MESSAGE(ERROR,nodo proprietario del job).Il JobManager provvede ad inviare l’output del task al nodo aggregatore, oppu-re se si sono verificati errori di esecuzione, informa il nodo proprietario del jobdell’impossibilita di portare a termine il task.

4. RESET JOB CONFIG(). Al termine dell’invio dell’output, o del messaggio dierrore, l’invio periodico di heartbeat da parte del JobTracker viene interrotto.

5. MESSAGE RECEIVED(OUTPUT, ID nodo mittente). Questo evento si verificasolo se l’evento 4 ha prodotto l’invio di un messaggio di tipo OUTPUT. In talcaso il nodo aggregatore riceve l’output prodotto dal nodo identificato da ID nodomittente ed esegue il task di aggregazione, al termine del quale verranno ripetutii passi precedentemente descritti.

6. RECEIVE MESSAGE(OUTPUT,ID ultimo nodo aggregatore) oppure RECEI-VE MESSAGE(ERROR, ID nodo mittente). Quando l’ultimo nodo aggregatoreesegue l’ultimo task di aggregazione, invia il messaggio contenente l’output ot-tenuto al nodo proprietario del job. Se uno qualsiasi dei nodi rileva un erroredurante l’esecuzione del task, il nodo proprietario ricevera un messaggio di erroree verranno generati gli eventoi descritti a partire dal punto 8.


Figura 3.5: Esecuzione/Interruzione/Completamento del job

7. PUT DATA(OUTPUT,file di output del job).Il JobManager richiede l’allocazionedi un file per conservare il flusso di dati ricevuto dall’utlimo nodo aggregatore.

8. RESET JOB CONFIG(). Il monitoraggio dell’utlimo nodo aggregatore vieneinterrotto.

9. JOB COMPLETED(path del file di output) oppure JOB INTERRUPTED(error).Il JobManager comunica all’UserInterface il completamento o l’interruzione del-l’esecuzione del job.

10. STATUS(COMPLETED) oppure STATUS(INTERRUPTED). L’utente riceva unanotifica sul completamento dell’esecuzione del job o sulla sua interruzione.

3.3.3 Sostituzione dei nodi guasti

Durante la computazione distribuita si possono verificare eventi che impediscono auno o piu nodi di portare a termine il proprio task, tali eventi possono essere guastidell’hardware che rendono i nodi inutilizzabili, guasti alla rete che rendono i nodi irrag-giungibili o interruzione da parte del nodo della condivisione delle risorse locali. Ogninodo allocato per eseguire una computazione distribuita e monitorato da un altro nodomediante un meccanismo di rilevazione guasto basato su timer e messaggi di heartbeat.

42 CAPITOLO 3

Quando un nodo rileva un guasto, viene inviato un messaggio di CRASH al nodo pro-prietario del job, ovvero al nodo attraverso cui l’utente ha richiesto l’esecuzione del job,tale nodo provvede a sostituire il nodo guasto con un nuovo nodo secondo lo schemariportato in figura 3.6, in cui gli eventi sono:

1. RECEIVE MESSAGE(CRASH,ID nodo). Il nodo proprietario riceve un messag-gio in cui e indicato l’identificativo del nodo guasto.

2. CRASH DETECTED(ID nodo). Il JobTracker, dopo aver verificato che il nodorilevato come guasto appartiene all’insieme dei nodi allocati e il mittente delmessaggio e il nodo controllore, notifica allo SlicingServer che il cluster e statoprivato di un nodo.

I restanti eventi sono speculari a quanto gia discusso per la sottomissione dei job,ovvero:

3. GET NODE(n,<tupla risorse computazionali>). Corriponde al passo 6 descrittonella sezione 3.3.1

4. ADD NODE(ID nodo).Corriponde al passo 7 descritto nella sezione 3.3.1

5. SEND MESSAGE(ALLOCATION REQ,ID nodo). Corriponde al passo 8 de-scritto nella sezione 3.3.1

6. MESSAGE RECEIVED(ACK, ID nodo) oppure MESSAGE RECEIVED(NACK,IDnodo).Corriponde al passo 9 descritto nella sezione 3.3.1

7. SET SLICE(<lista ID nodi>).Corriponde al passo 10 descritto nella sezione 3.3.1

8. SET JOB CONFIG(ID nodo locale,ID job,ID input,< llista nodi>).Corripondeal passo 12 descritto nella sezione 3.3.1

3.3.4 Aggiornamento del Remote Resource Catalog

Come gia discusso, il Remote Resource Catalog(RRC) e lo strumento utilizzato da ogninodo per conoscere il tipo e la locazione delle risorse presenti nella rete. L’approcciodi ricerca delle risorse mediante interrogazione dell’RRC permette di avere tempi perl’esecuzione della query costanti, ma d’altro canto richiede che le informazioni conte-nute nell’RRC siano coerenti con tutti gli RRC conservati in tutti i nodi del sistema.La distribuzione delle informazioni del RRC, mostrata in figura3.7, e implementatasfruttando i servizi offerti dal Virtual Tree, in particolare:

• Ogni nodo invia una query di tipo ascendente contenente le informazioni relativealla configurazione hardware locale , la query risale l’albero fino a raggiungere laradice dove viene aggregata con le informazioni associate alle altre query.


Figura 3.6: Sostituzione dei nodi guasti

• L’aggregazione delle query costituisce il RRC che viene distribuito mediante unaquery di tipo discendente a tutti i nodi dell’albero.

Il procedimento descritto ha luogo ogni qualvolta un nodo effettua una operazionedi join o di leave oppure quando il Local Resource Monitor rileva una modifica allaconfigurazione hardware del nodo locale. La modifica del catalog e di tipo incremen-tale, solo le modifiche vengono propagate, i nodi che si connettono per la prima voltaal sistema propagano una query per la richiesta dell’intero catalog che verra inviato di-rettamente dal nodo radice. In figura 3.8 sono rappresentate le interazioni tra i modulidel sistema durante l’aggiornamento del catalog, nel dettaglio:

1. RESOURCE UPDATE(<tupla risorse computazionali>). Il Local Resource Mo-nitor richiede l’invio di una query per distribuire informazioni sulla configurazionehardware del nodo locale.

2. SEND MESSAGE(QUERY UPDATE,ID nodo). La query con le informazionidelle risorse computazionali locali viene inviata ai nodi dell’albero affinche vengaindirizzata ail nodo radice.

3. RECEIVE MESSAGE(RRC,ID nodo). Ogni nodo dell’albero riceve le informa-zioni aggregate dal nodo radice.

44 CAPITOLO 3

Distribuzione

Aggregazione

Figura 3.7: Distribuzione e aggregazione delle query all’interno delVirtual Tree

4. UPDATE NODE(ID nodo, <tupla risorse computazionali>). Vengono aggiorna-te le informazioni del RRC di ogni nodo.


Figura 3.8: aggiornamento del RRC

46 CAPITOLO 3

Capitolo 4

Test e Risultati

In questo capitolo sono presentati i dati relativi a test eseguiti su Cloud-To-Peer indiversi ambienti. Lo scopo e quello di fornire un’analisi delle performances del sistemadalle quali ottenere scenari di utilizzo e possibili migliorie da apportare al sistema.In ultima analisi e fornita una osservazione riguardante i consumi energetici dei nodiche eseguono i test per poter dedurre i costi che incorrono nell’utilizzo e gestione delsistema.

4.1 Ambienti di test

Con ambiente di test si intende l’insieme degli host utilizzati per la simulazione, lecaratteristiche di ognuno e della rete che li interconnette. La scelta degli ambien-ti e finalizzata ad avere configurazioni quanto piu differenti tra loro Per eseguire lasimulazione sono stati utilizzati:

• Macchine Virtuali su unico server, i nodi del sistema sono rappresentati da mac-chine virtuali residenti su 4 server di tipo IBM BladeCenter, ognuno dei qualipossiede la seguente cofigurazione hardware:

– 4 CPU IntelXeon a 2,8GHz;

– Bus di sistema a 1,66GHZ;

– 8GB di RAM.

– Larghezza di banda delle connessioni tra le macchine=10Gbps

Ogni macchina virtuale e equipaggiata con le seguenti risorse computazionali:

– 1CPU a 2,8 GHz;

– 1GB di RAM;

– 40GB di spazio di storage disponibile.

47

48 CAPITOLO 4

Il numero di macchine virtuali utilizzate per i test e pari a 20. Le caratteristicheprincipali di questo sistema sono l’omogeneita delle risorse dei nodi, l’assenza didinamismo e bassissimi ritardi di comunicazione.

• PC-Desktop del dipartimento di informatica, i nodi del sistema sono rappresentatidai PC adoperati da docenti e ricercatori all’interno del dipartimento di informa-tica e sistemistica dell’universita Sapienza di Roma, i PC sono connessi tra loromediante una Gigabit Ethernet. Tale ambiente e caratterizzato da dinamicita ecomposizione eterogenea di risorse, inoltre gli host che costituiscono il sistema so-no utilizzati per attivita di routine dai proprietari, i test forniscono dunque ancheil grado di intrusivita del sistema. Per l’esecuzione dei test in tale ambiente sonostati utilizzati in media 40 PC-Desktop.

• PlanetLab, i nodi appartengono ad un insieme di macchine geograficamente di-stribuito in tutta Europa. La peculiarita di tale ambiente e rappresentata dall’im-possibilita di predire i ritardi di comunicazione tra i nodi dovuti a livelli variabilidi congestione della rete di comunicazione. Le macchine richieste per l’esecuzionedei test e di 100 unita.

Per eseguire i test e stata aggiunta un nuovo tipo di query denominata GET BEST NODE(n)il cui risultato e una lista di n nodi associati al punteggio di performances attesa mag-giore calcolato mediante la formula:

(NoCPU)X(FrequenzaDiClockDelleCPU)+(DimensioneMemoriaDiLavoro)X(%DiUtilizzoDellaMemoriaDiLavoro)DelayDiComunicazione

L’utilizzo del RRC permette di ottenere il soddisfacimento delle query con tempiindipendenti rispetto ai delay di comunicazione della rete, nei nostri test il valore deltempo di query in tutti e 3 gli ambienti descritti non e mai risultato superiore ai 2secondi, tuttavia l’RRC rappresenta un limite alla scalabilita del sistema, dato che ilRRC non potra mai fornire una vista globale dei nodi connessi al sistema, ma solo unaparziale, nel nostro caso fornisce solo la lista dei nodi avente il punteggio di performancesattesa piu alto.

4.2 Benchmarks

Il sistema e stato testato per l’esecuzione distribuita di programmi she si differenzianoin base a complessita computazionale, tipo di input e dimensione di output prodotto.Per ogni test sono stati misurati i tempi di esecuzione globale per poter ottenere ivalori di throughput medi del sistema. Il tempo di esecuzione di un job e definito comel’intervallo di tempo compreso tra l’istante in cui inizia l’invio dei dati partizionativerso i nodi allocati e l’istante in cui tutti i task di aggregazione sono stati ultimati,producendo l’output del job. Lo scopo dei test e ottenere indicazioni su quali tipi

4.2. BENCHMARKS 49

di computazione e possibile eseguire negli ambienti descritti nella sezione precedenteindividuando le limitazioni nell’utilizzo del sistema.

• WordCount, e un’operazione di tipo IO-Bound che puo essere facilmente paralle-lizzata mediante un algoritmo basato sul data-partitioning.

• StringSort, e la classica operazione di ordinamento di un insieme di stringhe conl’ausilio di una struttura dati ad albero di tipo Red-Black.

• SHABruteForceAttack, e una operazione di tipo CPU-Bound nella scansione com-pleta di un insieme di bytes appartenenti ad un dato intervallo per trovare lasequenza di byte la cui codifica tramite SHA-1 corrisponde alla sequenza di bitdati in input.

4.2.1 WordCount

Il WordCount e un’operazione di data-mining che consiste nel suddividere i dati con-tenuti in un file di testo in stringhe e associare ad ognuna di esse il numero di voltecon cui occorrono nel file. Tale job costituisce uno dei classici benchmark utilizzati pertestare le funzionalita e le prestazioni di un sistema di computazione distribuita. L’al-goritmo, come gia discusso nel capitolo 3, e composto da 2 fasi, una fase di elaborazionesu ogni nodo in modo indipendente dagli altri e una fase di aggregazione eseguita sunodi specifici in base al risultato dei task indipendenti, lo pseudocodice delle fasi in cuie composto l’algoritmo e mostrato rispettivamente in Algorithm1 e Algorithm2.

Algorithm 1: WordCount

Data: una porzione di file di testo CHUNCKResult: un insieme SET di coppie <word,num>begin

SET= ∅;foreach word ∈ CHUNCK do

if SET contains word thenextract <word,num> from SET;num=num+1;

elseadd <word;1> to SET;

return SET;

L’input e costituito da un file di testo ottenuto mediante la concatenazione di libriappartenenti al progetto Gutenberg scelti in modo casuale. I test sono stati eseguiticon file aventi dimensioni pari a 4GB, 20GB e 40 GB in tutti e 3 gli ambienti descrittinella sezione precedente.

Il calcolo della complessita computazionale del job rispetto alla dimensione n del-l’input e dato da:

50 CAPITOLO 4

Algorithm 2: WordCount - aggregazione risultati parziali

Data: due insiemi SET1 e SET2 composti da coppie <word,num>Result: un insieme di coppie <word,num>begin

foreach < word, num1 >∈ SET1 doif SET2 contains word then

extract < word, num2 > from SET2;num2=num2+num1;

elseadd < word, num1 > to SET2;

return SET2;

• costo delle operazioni di scansione dell’insieme dei dati

O(n)

• costo delle operazioni di estrazione delle coppie < word, count >

O(log2 n)

L’upper bound logaritmico di tale operazione e dovuto all’utilizzo di un alberoRed-Black come struttura dati di ausilio locale ad ogni nodo.

• costo delle operazioni di aggregazione

O(n log2 n)

Quindi il costo totale dell’algoritmo risulta essere

O(n log2 n)

Ultima considerazione riguarda la dimensione dell’output, che risulta considerevol-mente inferiore rispetto all’input, riduzione che puo essere quantificata all’incirca di 3ordini di grandezza.

Nei grafici 4.1 sono riportati i valori del tempo di esecuzione impiegati per il com-pletamento del job con i dati di input descritti nei 3 differenti ambienti di test. Da taligrafici si osserva che raddoppiando il numero di nodi allocati per la computazione siassiste ad un incremento significativo delle performances del sistema nel caso dei testeseguiti sulle macchine virtuali, mentre negli altri ambienti le prestazioni risultano in-differenti rispetto al numero di nodi allocati, ottenendo incrementi minimi e a volte nonsignificativi delle performances del sistema, cio puo essere dovuto alle limitazioni del-la capacita di banda degli ambienti considerati, oppure alla presenza dell’eterogeneitadelle risorse e al loro dinamismo.

La scelta di questo benchmark e guidata anche dalla possibilita di poter confron-tare le prestazioni di Cloud-to-Peer con quelle offerte da Hadoop. Hadoop[38] e unframework utilizzato per eseguire calcolo parallelo su cluster di dimensioni considerevo-li, offrendo come strumenti di supporto un file sytem distribuiti (HDFS) e un pattern

4.2. BENCHMARKS 51

di programmazione denominato MapReduce. Hadoop-MapReduce risulta essere unostandard de-facto per l’esecuzione parallela di algoritmi per l’analisi, la manipolazionee il data-mining di grandi dataset. Il modello computazionale di MapReduce e moltosimile a quello utilizzato da Cloud-To-Peer, infatti si basa sul partizionamento di datiche vengono processati in modo indipendente da task denominati map-task e sull’ag-gregazione dei risultati parziali, gli outputs di ogni map-thread vengono collezionati edelaborati da uno o piu reducer-thread per ottenere l’output finale.

La differenza tra Hadoop-MapReduce e il Cloud-to-Peer risiede in:

• Operazioni centralizzate, tutte le operazioni di scheduling dei task e di rilevazionedei guasti sono orchestrati da un unico nodo chiamato master;

• Assenza di elasticita, i nodi utilizzati per eseguire la computazione sono definitiprima di richiedere l’esecuzione dei task, cio implica che durante l’esecuzione deitask non e possibile aggiungere nuovi nodi al sistema e che al verificarsi di guastiil cluster di nodi viene ridimensionato.

• Bilanciamento del carico, ad ogni nodo il master assegna un numero di task inbase al tempo che il nodo impiega a completare i task assegnati in precedenza.Questa funzionalita permette di evitare che i nodi lenti limitino le prestazionidel sistema, ma aumenta l’overhead di gestione dei task da parte del master chepotrebbe rappresentare un collo di bottiglia per il sistema.

Nei grafici 4.2 sono rappresentati i risultati ottenuti eseguendo i medesimi test con lemedesime macchine virtuali utilizzate per i test descritti in precedenza, nei medesimigrafici sono riportati in parallelo i risultati di Cloud-to-Peer e Hadoop per un rapidoraffronto tra i due sistemi. Da quest’ultimi test si puo notare come la soluzione decen-tralizzata adottata nell’implementazione del sistema offra vantaggi significativi rispettoall’approccio centralizzato utilizzato da Hadoop, anche se la disparita di prestazioni siassottiglia all’aumentare dei nodi in favore di Hadoop, l’incremento prestazionale offer-to da Cloud-to-Peer risulta sempre maggiore del 36%, superando i valori dell’80% nelcaso di esecuzione del job con input di dimensioni minori.

4.2.2 StringSort

Lo StringSort, ovvero l’ordinamento di stringhe secondo la relazione di precedenzalessicografica, e un altro benchmark largamente utilizzato per testare le prestazioni diun sistema di calcolo distribuito. La versione implementata per i nostri test e descrittain Algorithm3 e in Algorithm4 rappresentanti rispettivamente lo pseudocodice del taskindipendente e di aggregazione che conpongono l’algoritmo.

Come nel caso del WordCount descritto nella sezione precedente, e stato utilizzatoun albero red-black come struttura dati di ausilio, ne risulta che la complessita com-putazionale dell’algoritmo rispetto alla dimensione n dell’input anche inquesto caso epari a:

O(n log2 n)

52 CAPITOLO 4

Algorithm 3: StringSort

Data: una porzione di file di testo CHUNCKResult: un insieme SET di stringhe in ordine lessicograficobegin

Red-Black-Tree RBTree= ∅;foreach word ∈ CHUNCK do

insert word in RBTree;

while sizeofRBTree > 0 doword=first elements of RBTree in lexicographic order;SET=SET∪word;remove word from RBTree;

return SET

Lo scopo di eseguire test con lo StringSort e stressare il fattore comunicazionetra i nodi necessario per completare il job, infatti a differenza del WordCount in cuisi assisteva ad una riduzione notevole della dimensione dell’output rispetto a quelladell’input, in questi test non vi sono operazione di riduzione, l’output ha le medesimedimensioni dell’input.

I test sonon stati eseguiti con i medesimi file di input descritti nella sezione prece-dente, la comparazione mostrata nel grafico 4.3 con i risultati ottenuti dal WordCountpermette di stabilire l’impatto negativo che le operazioni di trasferimento di dati trai nodi hanno sulle prestazioni dell’intero sistema. La degradazione delle performancescausata dal maggior scambio di dati tra i nodi risulta essere consitente, si osserva unavariazione media negativa del trhougput del 20% con picchi che si avvicinano al 30%, po-tendo cosı dedurre che la quantita di dati scambiati tra i nodi durante la computazionedistribuita costituisce il principale fattore limitante delle prestazioni del sistema.

4.2.3 SHA-BruteForceAttack

Il benchmark descritto in questa sezione consiste nella ricerca della sequenza di bytela cui codifica tramite l’algoritmo di hashing SHA-1 corrisponde ad un dato messagedigest.

Lo pseudocodice dell’algoritmo e mostrato in Algorithm 5, nell’algoritmo e de-scritto solo il task indipendente, poiche il task di aggregazione consiste nella sempliceconcatenazione dei dati di output prodotti da ogni nodo.

In questi test l’input consiste semplicemente nella definizione dell’intervallo di va-lori che ogni nodo dovra scansionare, la complessita dell’algoritmo non e legata alladimensione dei dati di input inviati, ma alla dimensione della porzione di spazio divalori esplorata da ogni nodo. Indicando con D il numero di bit necessari a poter rap-presentare i valori contenuti nello spazio di ricerca e con m il numero di nodi allocatiper l’esecuzione della computazione, la complessita dell’algoritmo e data da:

O(2D

m )

4.2. BENCHMARKS 53

Algorithm 4: StringSort - aggregazione dei risultati parziali

Data: due insiemi SET1, SET2 di stringhe in ordine lessicograficoResult: un insieme di stringhe SETf in ordine lessicograficobegin

SETf=∅;while SET1 6= ∅ ∧ SET2 6= ∅ do

word1=first element of SET1;word2=first element of SET2;if word1 ≺ word2 then

SETf = SETf ∪ word1;remove word1 from SET1;

elseSETf = SETf ∪ word2;remove word2 from SET2;

if SET1 6= ∅ thenSETf =SETf ∪ SET1;

elseSETf =SETf ∪ SET2;

return SETf ;

Algorithm 5: SHA - Brute Force Attack

Data: tre interi B0, Bn, digest rappresentanti rispettivamente 2 sequenze dibyte e una sequenza di 180 bit e tali che B0 < Bn

Result: un interobegin

Bi = B0;while Bi 6= Bn do

if SHA(Bi) ≡ digest thenreturn Bi;

elseBi=Bi+1;

return 0;

Lo scopo dell’esecuzione di tali test e osservare le prestazioni del sistema durantel’esecuzione di un algoritmo totalmente CPU-Bound in cui la comunicazione tra nodi eridotta al minimo, nel grafico 4.4 sono mostrati i risultati ottenuti da tali test. L’esecu-zione di un job con requisiti minimi di trasferimento dati permette di sfruttare a pienole potenzialita offerte dal sistema, l’aumento delle prestazioni rispetto al numero dinodi allocati per l’esecuzione del job risulta pressoche lineare, in tal caso le limitazionialle performances del sistema sono da attribuire al limite di scalabilita del sistema edall’incapacita di garantire l’allocazione dei nodi in presenza di vari livelli di churn-rate.

54 CAPITOLO 4

4.3 Consumi energetici

Durante l’esecuzione dei test, oltre ai tempi di completamento dei task, sono stai ri-levati anche i dati relativi ai consumi energetici. Lo scopo di tale misurazione e for-nire una indicazione quantitativa sul costo che occorre sostenere per poter utilizzarel’infrastruttura di computazione distribuita basata sul volunteer-computing.

In figura4.5 e mostrato l’andamento nel tempo del consumo energetico di un pc-desktop utilizzato nella valutazione sperimentale delle performances del sistema. Tuttii consumi energetici dei pc-desktop monitorati presentano il medesimo patttern:

1. Un aumento di consumo iniziale dovuto alla procedura eseguita per le operazionidi join del nodo al sistema:

2. Un andamento pressoche lineare e comparabile al consumo medio del pc-desktopin stato idle quando il nodo e in attesa di ricevere richieste di esecuzione;

3. Una variazione in positivo durante la ricezione dei dati di input e l’esecuzione deitask;

4. Il ritorno al livello di consumo descritto nel punto 2.

Il valore della variazione descritta al punto 3 rappresenta il costo in termini diconsumo energetico delle macchine durante la computazione distribuita, tale costo inmedia e pari a 25 W.

La medesima procedura di rilevazione dei consumi energetici e stata effettuatasui server IBM-Blade descritti nella sezione relativa agli ambienti di test, in tal casoabbiamo rilevato un consumo energetico durante l’esecuzione dei task pari a 160W.

Da tali dati e possibile stabilire il surplus o il risparmio di energia prodotto dalsistema di volunteer-computing, cio e ottenuto moltiplicando il consumo energeticoistantaneo dei server e dei pc-desktop per i rispettivi tempi di completamento deitask. Nel grafico 4.6 e mostrata la percentuale di risparmio energetico dell’utilizzodel volunteer computing rispetto a quello dei server.

Dal grafico e possibile osservare che il sistema Cloud-to-Peer sfruttando le risorseinutilizzate della rete in un ambiente dinamico e eterogeneo e in grado di offrire unrisparmio energetico di misura non inferiore al 44% (arrivando a toccare un picco del63.97%) rispetto all’utilizzo di un insieme di server dedicato all’esecuzione distribui-ta dei medesimi task, tuttavia il risparmio energetico risulta tanto inferiore quantomaggiore e il numero di macchine allocate. Ulteriori studi potrebbero individuare lasoglia oltre cui l’utilizzo di nodi superiore a detta soglia renderebbe nullo il risparmioenergetico individuato durante i test descritti in questa sezione.

4.3. CONSUMI ENERGETICI 55

10 20 30 40

40

50

60

70

Dimensione Input(GB)

Thro

ughpu

t(M

B/se

c)

16nodi8nodi4nodi

(a) Macchine virtuali

10 20 30 40

16

18

20

22

24


Thro

ugh

put(

MB

/sec

)

16nodi8nodi4nodi

(b) Pc-desktop dipartimento

10 20 30 40

5

10

15


Thro

ugh

put(

MB

/sec

)

16nodi8nodi4nodi

(c) PlanetLab

Figura 4.1: Cloud-to-Peer - WordCount

56 CAPITOLO 4

10 20 30 40

20

30

40

50

Dimensione input(GB)

Th

rough

put(

MB

/se

c)

Cloud-To-PeerHadoop-MapReduce

(a) 4nodi

10 20 30 40

30

40

50

60


Thro

ugh

pu

t(M

B/s

ec)


(b) 8nodi

10 20 30 40

40

50

60

70


Thro

ugh

put(

MB

/sec

)


(c) 16nodi

Figura 4.2: WordCount su macchine virtuali - Confronto tra Cloud-to-Peer e Hadoop-MapReduce


10 20 30 40

50

60

70


Thro

ugh

put(

MB

/se

c)

WordCountStringSort

(a) 16 nodi

10 20 30 4035

40

45

50

55

60


Thro

ugh

pu

t(M

B/se

c)

WordCountStringSort

(b) 8 nodi

10 20 30 40

30

35

40

45


Thro

ugh

put(

MB

/sec

)

WordCountStringSort

(c) 4 nodi

Figura 4.3: Cloud-to-Peer - Confronto tra WordCount e StringSort

58 CAPITOLO 4

0 10 20 30 40 50 60 70

20

40

60

80

Numero nodi

Th

rou

gh

pu

t(M

B/se

c)Macchine Virtuali

PlanetLab

(a) Throughput

0 10 20 30 40 50 60 70

20

40

60

Numero nodi

Tem

po

di

esec

uzi

one(

sec)

Macchine VirtualiPlanetLab

(b) Tempi di esecuzionei

Figura 4.4: Cloud-to-Peer - SHA Brute Force Attack


�

� ��

�

��

��

��

��

��

��

�

�

��

��

��

��

��

��

��

��

��

��

��

��

Figura 4.5: Pattern del consumo energetico di un nodo

10 20 30 40

45

50

55

60

65


Ris

par

mio

ener

geti

co(%

)

4 nodi8 nodi16 nodi

Figura 4.6: Percentuale di consumo energetico risparmiato dal volunteer-computingmediante l’utilizzo di Cloud-to-Peer sui PC-Desktop

60 CAPITOLO 4

Capitolo 5

Conclusioni

Come premesso nell’introduzione, lo scopo di questo lavoro e stato quello di proporreun’architettura di un sistema decentralizzato in grado di offire servizi di volunteer-computing. Non essendoci ancora una definizione chiara e generalmente condivisadi volunteer-computing, ci siamo basati sulla definizione definita dal NIST di cloud-computing. In tal senso il cloud-computing e l’infrastruttura di calcolo distribuitoche meglio implementa il concetto di utility-computing, ovvero la possibilita di poterutilizzare in modo elastico le risorse condivise messe a disposizione dal cloud-provider.

In Cloud-to-Peer non vi sono cloud-provider, il sistema e completamente decentra-lizzato e l’infrastruttura che costituisce l’insieme delle risorse condivise che e possibi-le utilizzare e formata dall’insieme di PC-Desktop degli utilizzatori del sistema, chedunque assumono il doppio ruolo di fornitori e consumatori di risorse.

Durante la progettazione del sistema abbiamo individuato 2 elementi chiave delmiddleware:

1. Lo Slicing Service, che permette di implementare una politica di schedulingdistribuito con la quale allocare le risorse.

2. Il RemoteResourceCatalog, che permette di indicizzare le risorse del sistema inmodo tale da possedere in qualunque momento una vista delle risorse disponibilidel sistema.

Tali moduli risultano essenziali e al contempo indipendenti dal resto del sistema,l’utilizzo di un particolare tipo di schema di allocazione delle risorse non influenza lacapacita del sistema di eseguire particolari task locali o richiedere l’allocazione di risorseremote. Analogamente il RRC consente di disaccoppiare il sistema di indicizzazionedelle risorse dal particolare OMP utilizzato per mantenere la connettivita dei nodi econsentire il routing delle query tra tutti i nodi della rete.

Con questi presupposti possiamo liberamente scegliere l’OMP che preferiamo, lanostra scelta e ricaduta sul VirtualTree per i seguenti motivi:

• Capacita della rete di mantenere la connettivita dei nodi anche in presenza dialti livelli di churn rate. Tutti i sistemi distribuiti sono sensibili al problema del

61

62 CAPITOLO 5

churn, in particolar modo se sono decentralizzati e dinamici come quelli descrittinel capitolo 4 per i quali risulta essenziale avere la resistenza al churn che evitiperiodi in cui i servizi offerti dal sistema risultino non disponibili.

• Possibilita di associare una semantica alle query. Le informazioni contenute nelRRC sono costruite in base ai risultati ottenuti da query di aggregazione perio-diche. La coerenza del RRC con lo stato reale del sistema permette di potereffettuare la scelta migliore per l’allocazione delle risorse. Virtual Tree a diffe-renza di altri OMP,come mostrato in 5, garantisce che le informazioni contenutenella risposta della query sono il risultato dell’aggregazione di tutti i nodi presentinel sistema,

Multiple Tree Cyclon Virtual Tree0

1000

2000

3000

4000

5000

6000

7000

8000

colle

cted

resu

orce

s

Figura 5.1: Confronto tra OMP basato sul numero di risorse collezionate durante ilprocessamento di query in una rete composta da 8192 nodi e fattore di churn rate paria 10−2

Nei test descritti nel capitolo 4 abbiamo mostrato come Cloud-to-Peer sia una validaalternativa ad altri sistemi per il calcoli distribuito basati su un’architettura centraliz-zata. Inoltre e stata fornita una misura quantitativa della capacita computazionaledi host connessi alla rete e sottoutilizzati, mostrando che e possibile ottenere, oltreal risparmio sui costi di acquisto e manutenzione di server dedicati alla computazionedistribuita, anche un risparmio di tipo energetico come mostrato dai grafici di figura4.6.

Cloud-to-Peer riesce dunque a riassumere le caratteristiche di 3 classi di paradigmiper la computazione distribuita:

• Utility Computing, dato che implementa il modello di servizio IaaS(Infrastructureas a Service) offerto dai sistemi di cloud-computing;

• P2P Computing, poiche non possiede single-point-of-failure e le operazioni diricerca e allocazione delle risorse sono decentralizzate;

• Green Computing, sfruttando solamente le risorse sottoutilizzate presenti nellarete, Cloud-to-Peer permette di ottenere un’infrastruttura volatile per il calcolo

5.1. SVILUPPI FUTURI 63

parallelo con requisiti energetici inferiori rispetto a quelli richiesti per un analogosistema dedicato.

5.1 Sviluppi futuri

L’implementazione di Cloud-to-Peer, bensı consenta effettivamente di supportare l’ese-cuzione distribuita di job, costituisce un prototipo che necessita di essere migliorato edampliato. Nel seguito forniamo un elenco di aspetti del sistema che richiedono ulteriorelavoro:

• Sicurezza, allo stato attuale il sistema non offre alcuna garanzia che le risorsedei nodi vengano utilizzate in modo inproprio. Possibili strumenti che possonoessere utilizzati per ovviare a tale mancanza sono i sistemi di crittografia a chiavepubblica per cifrare il flusso di informazioni scambiati tra i nodi durante la fasedi allocazione e di ricerca delle risorse, i sistemi di autenticazione basati ad esem-pio sulle WebOfTrust[39] che offrono la possibilita di autenticare ogni utente delsistema senza rinunciare alla sua natura di sistema decentralizzato, tecniche disandboxing che permettono di proteggere le risorse locali di ogni nodo impedendoa task che eseguono codice malevolo di danneggiare le stesse;

• Gestione della concorrenza, la politica di scheduling si basa esclusivamente sul-l’utilizzo di un protocollo di allocazione delle risorse basate sull’accodamento dirichieste e di scelta della richiesta da soddisfare in base all’ordine di tale accoda-mento. Tale politica risulta efficace ma non efficiente, poiche non tiene conto dellivello di utilizzo globale del sistema. L’utilizzo di un protocollo di scheduling checonsidera anche altre informazioni associate alla richiesta come ad esempio la ca-ratterizzazione del job (CPU-Bound o IO-Bound) o la reputazione dell’utente cheha emesso la richiesta (la reputazione puo basarsi sul comportamento dell’utentedescritto tramite quantita di richieste sottomesse e soddisfatte o percentuale dicondivisione delle proprie risorse) potrebbe migliorare il throughput globale cheil sistema e in grado di fornire;

• Data Locality, l’esecuzione di task sui medesimi dati di input potrebbe ridurrel’overhead di trasmissione dei dati di input. La possibilita di conservare e distri-buire informazioni sulla locazione dei dati utilizzati in computazioni precedenticonsente di eliminare la fase di invio dell’input verso i nodi limitando quindi iltrasferimento di dati al solo codice eseguibile la cui dimensione e notevolmenteinferiore a quella dell’input;

• Pattern di programmazione. La definizione di un pattern di programmazionefacilita lo sviluppo di applicazioni in grado di sfruttare l’infrastruttura offerta dalsistema agevolandone la diffusione e garantendo l’accesso ad un maggior numerodi utenti.

64 CAPITOLO 5

5.2 Scenari di utilizzo

Cloud-To-Peer puo essere utilizzato in tutte quelle organizzazioni in cui e richiestol’utilizzo di infrastrutture in grado di offrire funzionalita di supercomputing a bassocosto.

Oggigiorno le universita sono dotate di reti interne (come la rete LAN che abbiamoadoperato nei test descritti nel capitolo 4) in cui molti PC la maggior parte del temporestano in stato idle o vengono per lo piu utilizzati per eseguire semplici task come ilprocessamento di file di testo che non sfruttano appieno le capacita computazionali che ilPC e in grado di offrire. Cloud-to-Peer permette di aggregare tali risorse sottoutilizzatee offrire uno strumento per la risoluzione di problemi computazionalmente onerosi,permettendo ai gruppi di ricerca delle universita con budget ristretti di poter proseguirecon il proprio lavoro che altrimenti rimarrebbe bloccato dai limiti di spesa imposti.

Analogamente, per le medesime necessita di avere alto potere computazionale abasso costo, Cloud-to-Peer puo essere utilizzato per connettere tra loro laboratori diricerca geograficamente distanti. Ad esempio un laboratorio europeo puo, durante le orediurne, utilizzare le risorse inutilizzate di un laboratorio situato in Giappone.Il principiodi utilita di tale soluzione si basa sul fatto che mentre in Europa e giorno e dunquele risorse del laboratorio sono contese per espletare molteplici compiti, il Giappone sitrova in piena notte e dunque le risorse del laboratorio risultano inutilizzate. Invertendoil ragionamento, anche i laboratori giapponesi possono sfruttare le risorse dei laboratorieuropei quando questi durante la notte riducono la propria attivita, creando cosı unastretta collaborazione che permette ad entrambe le parti di ottenere maggior utiliutadalle proprie risorse.

Un altro settore in cui Cloud-to-Peer puo trovare la propria utilita e all’nterno diaziende che necessitano di analisi periodiche dei dati di produzione, delle vendite odelle informazioni riguardanti clienti e strategie di marketing. In tal caso l’acquisto diuna infrastruttura di calcolo per eseguire il data-mining di tali dati puo rappresentareun costo troppo oneroso per l’azienda. La periodicita con cui vengono effettuate talioperazioni suggerisce l’utilizzo di una infrastruttura volatile come quella offerta daCloud-to-Peer. In tal modo l’azienda evitera i costi di manutenzione per uno strumentoche rimarrebbe inutilizzato per la maggior parte del tempo.

Infine, come accennato nella sezione 2.2, l’utilizzo di un modello economico all’inter-no del processo di allocazione delle risorse, puo incentivare gli utenti della rete interneta condividere le risorse dei propri PC ottenendone in cambio un profitto. Come nelprimo caso analizzato, spesso il PC utilizzato dagli utenti possiede capacita computa-zionali superiori rispetto all’utilizzo che ne viene fatto. Poter ottenere un guadagnodalla condivisione del proprio PC permette di abbattere i costi per il suo acquisto datoche l’investimento iniziale puo nel tempo essere ripagato.

In ultima analisi forniamo un grafico riassuntivo che in base alle considerazioni fattefinora permette di stabilire quali sono le applicazioni che maggiormente potrebbero be-neficiare dall’utilizzo della piattaforma di calcolo offerta da Cloud-to-Peer. In figura 5.2e mostrata una funzione di convenienza basata sulla caratterizzazione delle applicazioni

5.2. SCENARI DI UTILIZZO 65

(CPU-Bound o IO-Bound) e dalla ciclicita con cui viene eseguito (esecuzione one-shoto periodica).

−10

−5

0

5

10

CiclicitàCaratterizzazione

Con

veni

enza

−10

−5

0

5

10

I/O bound

CPU bound

one shot

periodico

Figura 5.2: Analisi qualitativa della convenienza dell’utilizzo di Cloud-to-Peer in basealla caratterizzazione e ciclicita delle applicazioni

66 CAPITOLO 5

Bibliografia

[1] R. Braun, H. Siegel, N. Beck, L. Boloni, M. Maheswaran, A. Reu-ther, J. Robertson, M. Theys, B. Yao, D. Hensgen and R. Freund. AComparison of Eleven Static Heuristics for Mapping a Class of Independent Ta-sks onto Heterogeneous Distributed Computing Systems. Journal of Parallel andDistributed Computing (2001).

[2] W. Cirne, F. Brasileiro, N. Andrade, L. Costa, A. Andrade, R. Novaes,and M. Mowbray. Labs of the world, unite!!! Journal of Grid Computing(2006).

[3] Y. Liu. Survey on Grid Scheduling, 2004.

[4] A. Luther, R. Buyya, R. Ranjan, and S. Venugopa. Alchemi: A .NET-based enterprise grid computing system. International Conference on InternetComputing (2005).

[5] A. Mondal, Y. Lifu, and M. Kitsuregawa. “P2PR-Tree: An rtree-based Spa-tial Index for Peer-to-Peer Environments. Peer-to-Peer Computing and Databases(2004).

[6] A.Barak, A.Shiloh. The MOSIX Cluster Operating System for High-Performance Computing on Linux-Clusters, Multi-Clusters and Clouds,2012.

[7] A.Barak,A.Shiloh,L.Amar. An Organizational Grid of Federated MosixClusters. CCGRID (2005).

[8] A.S.Tanenbaum, M.VanSteen. Distributed Systems : Principles andParadigms, 2007.

[9] C. Schmidt and M. Parashar. “Flexible Information Discovery inDecentralized Distributed Systems. High Performance Distrib. Computing (2003).

[10] D. Tsoumakos, and N. Roussopoulos. Adaptive Probabilistic Search for Peer-to-Peer Networks. Int.Conf.P2P Computing (2003).

67

68 BIBLIOGRAFIA

[11] D. Tsoumakos, N. Roussopoulos. Analysis and Comparison of P2P SearchMethods. INFOSCALE (2006).

[12] D.I. Wolinsky, P. St. Juste, P. O. Boykin,R. J. O. Figueiredo. “Ad-dressing the P2P Bootstrap Problem for Small Overlay Networks. IEEE TenthInternational Conference on Peer-to-Peer Computing (2010).

[13] D.P.Anderson. BOINC: A System for Public-Resource Computing and Storage.International Workshop on Grid Computing (2004).

[14] D.P.Anderson, J.Cobb, E.Korpela, M.Lepofsky, D.Werthimer. SE-TI@HOME:An Experiment in Public-Resource Computing. Communications ofthe ACM (2002).

[15] D.Sullivan. The Definitive Guide to Cloud Computing, 2010.

[16] E. Tanin, A. Harwood, and H. Samet. A Distributed Quadtree Index forPeer-to-Peer Settings. Int. Conf. Data Eng. (2005).

[17] F. Cappello, S. Djilali, G. Fedak, T. Herault, F. Magniette, and O.Lodygensky. Computing on large-scale distributed systems: XtremWeb archi-tecture, programming models, security, tests and convergence with grid. FutureGeneration Computer Systems (2005).

[18] F.Berman, G.Fox, T.Hey. Grid Computing: Making the Global Infrastructurea Reality, 2003.

[19] Ganesan, P., Yang, B., and Garcia-Molina,H. One torus to rule themall:multi-dimensional queries in p2p systems. WebDB (2004).

[20] G.H. L. Fletcher, H. A. Sheth, K. Borner. Unstructured Peer-to-Peer Net-works: Topological Properties and Search Performance. Lecture Notes in ComputerScience - Agents and Peer-to- Peer Computing (2005).

[21] G.Tibor. A resource Allocation protocol for Providing Quality of Service in GridComputing. AICT-ICIW (2006).

[22] I.Foster. The Grid 2: Blueprint for a New Computing Infrastructure, 2003.

[23] I.Leila. Dynamic Resource Allocation Mechanism for Grid Computing. IEEETRIDENT-COM (2007).

[24] L. Young, S. McGough, S. Newhouse, and J. Darlington. SchedulingArchitecture and Algorithms within the ICENI Grid Middleware. UK e-ScienceAll Hands Meeting (2003).

[25] Lv. C, Cao. P, Cohen. E, Li. K and Shenker. S. Search and replication inunstructured peer-to-peer networks. Int. Conf. Supercomputing (2002).

BIBLIOGRAFIA 69

[26] M.Baker, A.Apon, R.Buyya, H.Jin. Cluster Computing and Applications.Encyclopedia of Computer Science and Techology (2002).

[27] M.J.Quinni. Parallel Programming in C with MPI and OpenMP, 2004.

[28] M.Meredith, T.Carringan, J.Brockman, T.Cloninger, J.Privoznik,J.Williams. Exploring Beowulf Clusters. Journal of Computing Sciences inColleges (2003).

[29] M.S.Sareireh. Performance Evaluation of Search Algorithms over P2P Networks.European Journal of Scientific Research (2011).

[30] Nabhendra Bisnik and Alhussein A. Abouzeid. Optimizing random walksearch algorithms in P2P networks. Computer Networks: The InternationalJournal of Computer and Telecommunications Networking (2007).

[31] P.E.Ceruzzi. Computing:A Coincise History. MIT Press Essential Knowledge(2012).

[32] P.Mell, T.Grance. The NIST Definition of Cloud Computing, 2011.

[33] R. Baldoni, S.Bonomi,A. Cerocchi ,L.Querzoni. Virtual Tree: a Robu-st Overlay Network for Ensuring Interval Valid Queries in Dynamic DistributedSystems. ICDCN (2012).

[34] R. Dorrigiv, A. Lopez-Ortiz, P. Pralat. Search Algorithms for Unstruc-tured Peer-to-Peer Networks. IEEE Conference on Local Network Protocols andAlgorithms Computer Networks (2007).

[35] R.Buyya, D.Abramson,J.Giddy,H.Stockinger. Economic Models for Re-source Management and Scheduling in Grid Computing. Concurrency andComputation:Pratice and Experience (2002).

[36] R.Guerraoui, L.Rodrigues. Introduction to Reliable Distributed Program-ming, 2006.

[37] S. Schulz, W. Blochinger, M. Held, and C. Dangelmayr. Cohesion -a microkernel based desktop grid platform for irregular task-parallel applications.Future Generation Computer Systems (2008).

[38] T.White. Hadoop:The Definitive Guide, 2012.

[39] W.Stallings. PGP web of trust, 1995.

[40] Y. M. Teo, V. Mar., and X. Wang. “A DHT-Based Grid Resource Indexingand Discovery Scheme. MIT Alliance Annual Symp. (2005).

[41] Yang, and H. Garcia-Molina. Improving search in peer-to-peer networks.IEEE International Conference on Distributed Computing (2002).

70 BIBLIOGRAFIA

[42] Yatin Chawathe, Sylvia Ratnasamy, Lee Breslau, Nick Lanham andScott Shenker. “Making gnutella-like P2P systems scalable. Applications,Technologies, Architectures, and Protocols for Computer Communications (2003).

[43] Y.Ming,L.Yuanan,M.Xiaolei,L.Li,Z.Linbo. Research on grid resource al-location based on equivalent price. Computing,Communication,Control andManagement (2009).

Progettazione, Implementazione e Valutazione di un Sistema ...

Documents

Transcript of Progettazione, Implementazione e Valutazione di un Sistema ...