JDCE Java Distribuited Computing Enviroment presentazione di Antonio Poggiali per l’esame di Reti di Calcolatori LS.

Presentazione sul tema: "JDCE Java Distribuited Computing Enviroment presentazione di Antonio Poggiali per l’esame di Reti di Calcolatori LS."— Transcript della presentazione:

1 JDCE Java Distribuited Computing Enviroment presentazione di Antonio Poggiali per l’esame di Reti di Calcolatori LS

2 Java Distribuited Computing Enviroment 2 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

3 Java Distribuited Computing Enviroment 3 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

4 Java Distribuited Computing Enviroment 4 JDCE - Computazioni In 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 JDCE 1 1 R1 R2 R3 R4 R5 … … RN operazione pacchetti di dati pacchetti di risultati

5 Java Distribuited Computing Enviroment 5 pippo A A JDCE - Struttura e componenti Gli 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). JD CE pluto topo B B iscrizione richiesta di lavoro AB topo, plutopippo B customer client manager

6 Java Distribuited Computing Enviroment 6 Implementare computazioni Le 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). interfacce DataPool ResultCollector classe astratta Operation Il Customer di JDCE lavora con questi tre componenti 1 2 3 4 5 … … JDCE … … N R1 R2 R3 R4 R5 … … … … RN

7 Java Distribuited Computing Enviroment 7 DataPool public 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

8 Java Distribuited Computing Enviroment 8 Operation public 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)); }

9 Java Distribuited Computing Enviroment 9 ResultCollector public 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

10 Java Distribuited Computing Enviroment 10 Comunicazione fra le componenti Le 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). pippo A A JD CE manager.ICustomer manager.IClient customer.IClientcustomer.IManager client.IManager

11 Java Distribuited Computing Enviroment 11 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à. JD CE manager.ICustomer extends NameResolver manager.IClient extends NameResolver public Token getValidName(…) Token

12 Java Distribuited Computing Enviroment 12 Controllo dei permessi Qualsiasi 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. pippo A A JD CE IPE Token

13 Java Distribuited Computing Enviroment 13 Client L’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(…) pippo JD CE A A customer.IClient client.IManager

14 Java Distribuited Computing Enviroment 14 Customer L’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(…) A A JD CE manager.ICustomer customer.IManager

15 Java Distribuited Computing Enviroment 15 Manager L’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() pippo A A JD CE customer.IManager client.IManager

16 Java Distribuited Computing Enviroment 16 Caduta dei nodi La 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. pippo A A JD CE Funziona lo stesso

17 Java Distribuited Computing Enviroment 17 Replicazione del Manager Il 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. JD CE M M C C manager master copia … alive() … makeDataCheckpoint(…) … makeSystemCheckpoint(…) … alive() … joinGroup(…) … leaveGroup(…) … joinGroup(…) … leaveGroup(…) … becomeMaster()

18 Java Distribuited Computing Enviroment 18 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.

19 Java Distribuited Computing Enviroment 19 Caduta del Manager M M C C master copia pippo A A JD CE Remote Exception Remote Exception Zzz Remote Exception … alive() RMIRegistry rebind al nome del manager

20 Java Distribuited Computing Enviroment 20 Caduta del Manager C C copia pippo A A Zzz JD CE lancio del manager e rispristino stato ? ? RMIRegistry … becomeMaster() M M master

21 Java Distribuited Computing Enviroment 21 Caduta del Manager pippo A A JD CE RMIRegistry M M master lookup del manager nel registro

22 Java Distribuited Computing Enviroment 22 Caduta del Manager pippo A A JD CE M M master

23 Java Distribuited Computing Enviroment 23 Locale vs. Distribuito Quando 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.