JDCE J ava D istribuited C omputing E nviroment

1. JDCEJava Distribuited Computing Enviroment presentazione di Antonio Poggiali per l’esame di Reti di Calcolatori LS

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. 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. 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. R1 R3 R5 … R2 R4 … RN 1 3 5 … 2 4 … N pacchetti di dati pacchetti di risultati JDCE 1 R1 1 R1 operazione

5. JDCE - Struttura e componenti customer • 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). A B iscrizione pippo topo, pluto JDCE manager A B B pippo topo pluto richiesta di lavoro iscrizione client

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). interfacceDataPoolResultCollector 1 3 5 … … 2 4 … … N JDCE classe astrattaOperation Il Customer di JDCE lavora con questi tre componenti R1 R3 R5 … … R2 R4 … … RN

7. DataPool 1 3 5 … … 2 4 … … N • 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

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. ResultCollector R1 R3 R5 … R2 R4 … RN • 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

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). A customer.IClient customer.IManager manager.ICustomer JDCE manager.IClient pippo client.IManager

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à. manager.ICustomer extends NameResolver public Token getValidName(…) JDCE Token manager.IClient extends NameResolver public Token getValidName(…)

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. A IPE JDCE Token pippo

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. A customer.IClient … getComputation(…) … getPacket(…) … setComputationResult(…) … notifyComputationError(…) JDCE client.IManager … subscribeClient(…) … unscribeClient(…) … bindClient(…) … getValidName(…) pippo

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. A customer.IManager … grantBind(…) … revokeBind(…) JDCE manager.ICustomer … subscribeCustomer(…) … unscribeCustomer(…)

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. A customer.IManager … grantBind(…) … revokeBind(…) … alive() JDCE pippo client.IManager … alive()

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. A JDCE Funziona lo stesso pippo

17. Replicazione del Manager master • 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. M … alive() … joinGroup(…) … leaveGroup(…) … alive() … makeDataCheckpoint(…) … makeSystemCheckpoint(…) manager JDCE … becomeMaster() C … joinGroup(…) … leaveGroup(…) copia

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. Caduta del Manager Remote Exception rebind al nome del manager Remote Exception Zzz RMIRegistry master A M … alive() JDCE Remote Exception C Zzz pippo copia

20. Caduta del Manager lancio del manager e rispristino stato Zzz RMIRegistry A JDCE ? ? M C Zzz … becomeMaster() pippo copia master

21. Caduta del Manager RMIRegistry A JDCE lookup del manager nel registro M pippo master

22. Caduta del Manager A JDCE M pippo master

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.