JDCE J ava D istribuited C omputing E nviroment

JDCEJava Distribuited Computing Enviroment

presentazione di Antonio Poggiali

per l’esame di Reti di Calcolatori LS

2Java Distribuited Computing Enviroment

Introduzione ai DCE

Un ambiente di calcolo distribuito (DCE) consiste in un sistema in grado di prendere delle applicazioni di calcolo e di distribuirne il carico computazionale su un insieme di calcolatori connessi alla rete. In un ambiente “collaborativo” questi calcolatori non sono noti a priori ma vengono concessi a tempo indeterminato dagli utenti e possono venire revocati in qualsiasi momento.

In particolare un DCE deve: Fornire ai programmatori un sistema per scrivere il codice delle loro

applicazioni di calcolo e mandarle in esecuzione (deployment nell’ambiente)

Permettere di mettere a disposizione i calcolatori in modo semplice (già che ci fanno il favore, perché complicargli la vita?)

Gestire la potenza di calcolo disponibile fra le varie elaborazioni che ne fanno richiesta

Gestire la distribuzione delle elaborazioni in maniera trasparente per il programmatore


JDCE - Main features JDCE è un ambiente per lo sviluppo e l’esecuzione di applicazioni

di calcolo distribuito di tipo cooperativo In JDCE le macchine che partecipano al calcolo offrendo le proprie

risorse non sono note a priori ma vengono liberamente messe a disposizione (e liberamente tolte) dagli utenti delle macchine stesse lanciando una applicazione

JDCE gestisce autonomamente la distribuzione della potenza di calcolo disponibile fra i vari richiedenti e gestisce le problematiche che nascono dall’ambiente distribuito

JDCE offre al programmatore un sistema semplice, basato su interfacce ed ereditarietà, per strutturare e sviluppare le proprie applicazioni di calcolo e per mandarle in esecuzione

JDCE è sviluppato in Java ed utilizza RMI come middleware di comunicazione fra i vari componenti


JDCE - ComputazioniIn JDCE un’applicazione di calcolo viene chiamata computazione.

Una computazione consiste in una serie di pacchetti di dati numerati in senso crescente a cui viene applicata, pacchetto per pacchetto, una operazione che restituisce un nuovo pacchetto contenente il risultato.

JDCE distribuisce il calcolo affidando i pacchetti a calcolatori diversi e raccogliendo i risultati prodotti.

Il deployment su JDCE avviene affidando la computazione ad un opportuno agente.

1 2 3 4 5 … … N

JDCEJDCE

1

1

R1

R1

R1 R2 R3 R4 R5 … … RN

operazione

pacchettidi dati

pacchettidi risultati


pippopippo

AA

JDCE - Struttura e componentiGli attori del sistema JDCE sono tre; ogni attore consiste in una applicazione che svolge determinate operazioni.

I client sono gli attori che mettono a disposizione la loro capacità di elaborazione.

I customer (committenti) sono gli attori che richiedono capacità di calcolo per eseguire una computazione.

Il manager è l’attore che si occupa di gestire la capacità di calcolo disponibile fra le varie computazioni pervenute. Ogni ambiente JDCE in funzione prevede un solo manager (eventualmente replicato).

JDCE

plutopluto

topotopo

BB

iscrizione

iscrizione

richiestadi lavoro

A B

topo, plutopippo

B

customer

client

man

ager


Implementare computazioniLe computazioni sono fisicamente articolate su una terna di elementi distinti che il programmatore deve sviluppare: la sorgente dei dati (data pool), l’operazione da eseguire (operation) ed il collettore dei risultati (result collector).

interfacceDataPoolResultCollector

classe astrattaOperation

Il Customer di JDCE lavora con questi tre componenti

1 2 3 4 5 … …

JDCEJDCE

… … N

R1 R2 R3 R4 R5 … … … … RN


DataPoolpublic interface DataPool {

public Packet getNextPacket() throws noMorePacketException;

public Packet getPacket(int number) throws InexistingPacketException;

public boolean hasPacket();

…

}

La sorgente di dati è vista come un flusso sequenziale di pacchetti numerati in ordine crescente recuperabili con getNextPacket(). Il metodo hasPacket() indica ci sono ancora pacchetti in sequenza. La sorgente deve permettere anche l’accesso random con il metodo getPacket(int number).

noMorePacketException > non ci sono più pacchetti

InexistingPacketException > il pacchetto richiesto non esiste

1 2 3 4 5 … … … … N


Operationpublic abstract class Operation implements Serializable{

public abstract Serializable compute(Packet data);

}

La classi figlie di Operation vengono recuperate dai client per poter eleborare i dati. Il metodo compute() restituisce il risultato dell’elaborazione sul pacchetto passato come parametro. La costruzione del pacchetto dei risultati è affidato al costruttore di ResultPacket che richiede una Operation da utilizzare. Questo meccanismo svincolare il programmatore dalla gestione esplicita dei numeri di pacchetto.

public class ResultPacket extends Packet{

public ResultPacket(Operation operation, Packet data){

super(data.getPacketNo(),operation.compute(data));

}

}


ResultCollectorpublic interface ResultCollector {

public void commit(ResultPacket result);

public boolean hasFinished();

public void signalError(int packetIndex) throws AbortComputationException;

}

Il metodo commit(ResultPacket result) consegna un pacchetto di risultati. Il metodo signalError(int packetIndex) indica che l’elaborazione del pacchetto con il numero packetIndex ha causato un errore sul cliente. Il metodo hasFinished() indica quando tutti i pacchetti sono stati consegnati (o hanno restituito errore).

Il customer di JDCE consegna i risultati o notifica gli errori rigorosamente in ordine e senza duplicati.

AbortComputationException > a seguito di un errore si richiede di abortire la computazione

R1 R2 R3 R4 R5 … … RN


Comunicazione fra le componentiLe tre componenti comunicano utilizzando RMI, ciascun componente espone una interfaccia per ciascuna delle altre parti che devono comunicare con lui.

I riferimento agli oggetti remoti devono essere reperiti da un registro RMI; in JDCE viene fatta l’ipotesi che il registro non fallisce, non ci sono politiche di recovery su registri secondari.

L’iscrizione e cancellazione dal registro vengono gestite dai singoli componenti. Il nome a cui ci si iscrive viene reperito in modo “unico” dal manager(vedi dopo).

pippopippo

AA

JDCE

manager.ICustomer

manager.IClient

customer.IClient customer.IManager

client.IManager


Identificazione e recupero delle entità

Per identificare le entità le operazioni richiedono l’identità del richiedente come parametro.Il manager permette di reperire nomi unici attraverso il metodo getValidName(), definito nelle sue interfacce estendendo NameResolver, che restituisce un token.I Token sono oggetti serializzabili da cui è possibile estrarre un nome con il metodo getName().Le entità si iscrivono al registro utilizzando il nome contenuto nel token e utilizzano il token per fornire la propria identità.

JDCE

manager.ICustomer extends NameResolver

manager.IClient extends NameResolver

public Token getValidName(…)

public Token getValidName(…)

Token


Controllo dei permessiQualsiasi operazione richiede che venga fornito un token che contiene l’identità del chiamante. Se il chiamante non è autorizzato ad eseguire quella operazione verrà sollevata un’eccezione InvalidPermissionException.Ad esempio, se un client chiede un pacchetto di dati ad un customer occorre che il manager abbia concesso il permesso al customer, se il customer non ha il permesso solleverà una InvalidPermissionException al client.

pippopippo

AA

JDCE

IPEToken


ClientL’applicazione client di JDCE si iscrive al manager e chiede di essere legato ad un customer. Una volta legato il client richiede al customer il codice dell’operazione, ed una volta ottenuto chiede un pacchetto di dati su cui eseguirlo.

Ogni volta che un pacchetto viene elaborato il client comunica al customer il risultato (o lo informa di un errore di calcolo) e gli chiede un altro pacchetto. Quando il customer ha concluso la propria elaborazione ne informa il client che ricomincia da capo.

Quando l’applicazione client termina si cancella dal manager.

… getComputation(…)… getPacket(…)

… setComputationResult(…)… notifyComputationError(…)

… subscribeClient(…)… unscribeClient(…) … bindClient(…)… getValidName(…)

pippopippo

JDCE

AA

customer.IClient

client.IManager


CustomerL’applicazione customer di JDCE richiede che le venga fornita una computazione da portare a termine. Il customer fa da ponte tra i client e la terna di componenti della computazione.

Per prima cosa si iscrive al manager, questi, quando ne ha disponibili, gli assegna uno o più client con cui poter lavorare. Le assegnazioni possono essere revocate in qualsiasi momento. Il customer serve solo le richieste che gli arrivano dai client che il manager gli ha assegnato.

Quando la computazione è terminata il customer si cancella.

… subscribeCustomer(…)… unscribeCustomer(…)

… grantBind(…) … revokeBind(…)

AA

JDCEmanager.ICustomer

customer.IManager


ManagerL’applicazione manager tiene traccia dei customer e dei client che si iscrivono, risponde alle richieste di legarsi dei client fornendogli un customer, comunica ai customer l’assegnazione di client, risponde alle richieste di cancellazione dei client, revocandoli al customer a cui sono assegnati e risponde alle richieste di cancellazione dei customer.Il ruolo del manager fondamentale: funge da broker fra i client ed i customer, decide come distribuire la potenza di calcolo e, nel caso di fallimenti di client o customer, si fa carico della gestione degli errori che ne risultano.

… grantBind(…) … revokeBind(…) … alive()

… alive()

pippopippo

AA

JDCE

customer.IManager

client.IManager


Caduta dei nodiLa caduta del manager impedirà a nuovi attori di entrare nel sistema; i customer potranno continuare a lavorare con i loro client. Per migliolare l’affidabilità del sistema è possibile replicare il manager su più nodi.La caduta di un customer porta alla perdita della computazione; la loro replicazione è stata scartata perché troppo onerosa.Ad esempio: un customer sta gestendo una compressione video, occorre replicare sia il video non compresso (sorgente) sia il video compresso (risultato, man mano che viene calcolato) su tutti i nodi che replicano il customer.

pippopippo

AA

JDCE

Funzionalo stesso


Replicazione del ManagerIl manager può essere replicato da copie passive dinamicamente aggiunte/rimosse durante l’esecuzione.Una copia è il master e viene mantenuto aggiornato: se cade il master il manager ne elegge un’altro trasmettendogli stato, se il manager cade il master diventa il nuovo manager (elegge un nuovo master).Manager e copie espongono una interfaccia Replicator comune che permette di entrare/uscire dal gruppo, chiedere al manager se è vivo, aggiornare il master e far diventare master una copia.Alcune azioni sono ovviamente prerogativa del manager, altre della copie ed altre del master.

JDCE

MM

CC

manager

master

copia

… alive()… makeDataCheckpoint(…)

… makeSystemCheckpoint(…)

… alive()… joinGroup(…) … leaveGroup(…)

… joinGroup(…) … leaveGroup(…)

… becomeMaster()


Caduta del Manager

Ogni operazione sul manager prima di restituire i risultati sincronizza il master trasmettendo le modifiche avvenute nelle sue strutture dati.

Al fallimento del manager (RemoteException) i componenti attendono un certo tempo poi interrogano il registro per un nuovo riferimento e ripetono la richiesta fallita.

Durante il tempo di attesa il master accede al registro RMI e si registra a nome del vecchio manager (rebind).

Questo protocollo è efficiente grazie all’unica copia sincronizzata ed alla semplicità di gestione del gruppo ma fallisce se manager e master cadono contemporaneamente; possibilità comunque remota.


Caduta del Manager

MM

CC

master

copia

pippopippo

AA

JDCE

RemoteException

RemoteException

Zzz

ZzzRemote

Exception

… alive()

RMIRegistry

rebindal nome del

manager


Caduta del Manager

CC

copia

pippopippo

AA

Zzz

Zzz

JDCE

lancio del managere rispristino stato

?

?

RMIRegistry

… becomeMaster()

MM

master


Caduta del Manager

pippopippo

AAJDCE

RMIRegistry

MM

master

lookup del managernel registro


Caduta del Manager

pippopippo

AAJDCE

MM

master


Locale vs. DistribuitoQuando JDCE può essere utilizzato per avere uno speed-up? Nel modello locale “pipelined” un processo legge i pacchetti di dati, un processo li elabora ed un processo finalizza.Le computazioni I/O bound non sono efficienti: la distribuzione dell’elaborazione non elimina i tempi di lettura e finalizzazione (introduce l’overhead di trasmissione).Le computazioni CPU bound nel modello locale “pipelined” con N pacchetti e tempo de elaborazione (costante) Te richiedono un tempo complessivo Tpipeline=N*Te.In Jdce consideriamo Tsend e Treceive tempi di trasmissione e ricezione di un pacchetto. Senza ritrasmissioni la sorgente deve trasferire e ricever N pacchetti con un tempo complessivo di Tjdce=N*Tsend+N*Treceive+(N*Te)/client, tempo che i client impiegano ad elaborare i pacchetti.Nelll’ipotesi che il numero di client sia costante ed elevato ponendo Tjdce<Tpipeline otteniamo Te<Tsend+Treceive condizione minima perché Jdce sia conveniente; condizione non sufficiente perchè calcolata senza considerare gli overhead che JDCE introduce.

Documents

JDCE J ava D istribuited C omputing E nviroment