quando la riduzione del makespan ottenuta dall’ultimo cambiamento `e inferiore rispetto ad una data soglia.
2.3 La rilevazione dei guasti
La scalabilit`a delle reti P2P permette di avere sistemi formati da un numero di nodi considerevole, se da un lato ci`o permette di poter usufruire di maggior risorse, dall’altro espone il sistema ad una maggior probabilit`a 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 si basano sull’utilizzo del gossip in cui ogni nodo mantiene una tabella locale, ogni entry di tale tabella `e associata ad un nodo che conosce, in ogni entry `e contenuto un contatore chiamato heartbeat, durante l’esecuzione del protocollo di rilevamento dei guasti si ha che:
1. Ogni nodo sceglie un gruppo di altri nodi;
2. Ad ogni nodo scelto viene inviata la tabella locale in cui il nodo mittente ha incrementato il proprio heartbeat;
3. Quando un nodo riceve una tabella, la fonde con la tabella locale adottando per ogni entry comune l’heartbeat maggiore;
4. Se dopo un certo intervallo di tempo un nodo rileva che un dato heartbeat non `e stato incrementato, allora il nodo a cui `e associato tale heartbeat viene sospettato di guasto;
5. Per ogni nodo sospettato di guasto viene eseguito un protocollo di consenso per mantenere 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 messaggi di 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
La difficolt`a maggiore per l’implementazione di un rilevatore di guasti `e la scelta del timeout, utilizzare valori troppo piccoli pu`o generare falsi positivi causando un notevole aumento del traffico di rete per completare il protocollo di consenso, mentre valori troppo grandi causano un ritardo nella procedura di identificazione dei nodi guasti che potrebbero compromettere le funzionalit`a 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 pi`a uniforme 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 il messaggio `e basata sull’identificativo del nodo mittente s e dal numero di round corrente r, d = r+s. Dopo l’esecuzione di un numero di round pari alla dimensione della rete meno uno, ogni nodo avr`a comunicato con ogni altro nodo della rete. • Invio dei messaggi in Round-Robin binario, riduce la banda utilizzata per l’invio
dei 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 dimensione della rete.
Capitolo 3
Progettazione e Implementazione
del sistema Cloud-to-Peer
In questo capitolo `e presentato Cloud-to-Peer. Cloud-to-Peer `e un sistema che pu`o esse-re inserito nella classe dei sistemi di volunteer-computing, la sua peculiarit`a rispetto ai sistemi esistenti `e la completa decentralizzazione di tutte le sue funzionalit`a. L’utente che 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 risorse remote offerte dal sistema. L’intero processo di sottomissione e allocazione dei jobs `e trasparente 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 software che pu`o essere eseguito su tali risorse.
Nel seguito viene fornita una descrizione pi`u 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 di essi.
• Modello Architetturale, analizza il middleware che coordina e controlla il siste-ma fornendo una descrizione delle funzionalit`a e dell’interfaccia fornita da ogni modulo.
• Protocolli e Interazioni tra i Moduli utilizzati per garantire che le funzionalit`a offerte 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 di protocolli TCP/IP. Non vi sono assunzioni sulla particolare configurazione hardware
che ogni computer deve possedere, nel sistema possono essere presenti varie architetture hardware con risorse computazionali (CPU e memoria di lavoro) e dispositivi di storage eterogenei.
Tra gli host non vi sono divisioni di ruolo, ognuno `e sia fornitore che consumatore di risorse, l’ unica eccezione `e rappresentata dal server utilizzato per il bootstrap della rete. Il server di bootstrap consente ad ogni host di connettersi alla rete P2P, costituisce dunquei il punto di aggancio degli host al sistema. L’utilizzo di un server per l’accesso alla rete `e reso necessario dal ben noto problema del bootstrapping che affligge ogni rete P2P e di cui ad oggi vi sono soluzioni decentralizzate solo per reti di piccole dimensioni[12].
Ogni host non `e vincolato a possedere specifici componenti software come ad esempio un particolare sistema operativo, l’unico requisito `e quello di possedere una java virtual machine che fornisce la virtualizzazione necessaria per l’ambiente di esecuzione dei task.