presentazione

JDCE
Java Distribuited Computing Enviroment
Antonio Poggiali
per l’esame di Reti di Calcolatori LS
presentazione di
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
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
Java Distribuited Computing Enviroment
4
JDCE - Computazioni
In JDCE un’applicazione di calcolo
R1 R2 R3 R4 R5 … … RN
viene chiamata computazione.
1 2 3 4 5 … … N
Una computazione consiste in una
serie di pacchetti di dati numerati
in senso crescente a cui viene
pacchetti
applicata, pacchetto per pacchetto, pacchetti
di dati
1
R1
una operazione che restituisce un di risultati
nuovo pacchetto contenente il
JDCE
risultato.
JDCE distribuisce il calcolo
1
affidando i pacchetti a calcolatori
R1
diversi e raccogliendo i risultati
prodotti.
Il deployment su JDCE avviene
affidando la computazione ad un
opportuno agente.
operazione
Java Distribuited Computing Enviroment
5
JDCE - Struttura e componenti
customer
A
B
iscrizione
pippo
topo, pluto
JD
CE
A
B
B
pippo
pluto
topo
manager
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).
richiesta
iscrizione
di lavoro
client
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
… … … …
N
JDCE
R1 R2 R3 R4 R5 … … … … RN
Java Distribuited Computing Enviroment
DataPool
1
2
3
4
5
… … … …
7
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
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));
}
}
Java Distribuited Computing Enviroment
ResultCollector
9
R1 R2 R3 R4 R5 … … 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
Java Distribuited Computing Enviroment
10
Comunicazione fra le componenti
Le tre componenti comunicano
utilizzando RMI, ciascun
A
componente espone una interfaccia
per ciascuna delle altre parti che
devono comunicare con lui.
customer.IClient
customer.IManager
I riferimento agli oggetti remoti
devono essere reperiti da un
registro RMI; in JDCE viene fatta
manager.ICustomer
JD
l’ipotesi che il registro non fallisce,
CE
non ci sono politiche di recovery su
manager.IClient
registri secondari.
L’iscrizione e cancellazione dal
registro vengono gestite dai singoli
pippo
componenti. Il nome a cui ci si
client.IManager
iscrive viene reperito in modo “unico”
dal manager(vedi dopo).
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à.
manager.ICustomer extends NameResolver
public Token getValidName(…)
Token
JD
CE
manager.IClient extends NameResolver
public Token getValidName(…)
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
Token
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
JD
CE
IPE
pippo
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.
A
customer.IClient
… getComputation(…)
… getPacket(…)
… setComputationResult(…)
… notifyComputationError(…)
JD
CE
pippo
…
…
…
…
client.IManager
subscribeClient(…)
unscribeClient(…)
bindClient(…)
getValidName(…)
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.
A
customer.IManager
… grantBind(…)
… revokeBind(…)
manager.ICustomer
… subscribeCustomer(…)
… unscribeCustomer(…)
JD
CE
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.
A
customer.IManager
… grantBind(…)
… revokeBind(…)
… alive()
JD
CE
pippo
client.IManager
… alive()
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é
Funziona
troppo onerosa.
lo stesso
Ad esempio: un customer sta
gestendo una compressione video,
occorre replicare sia il video non
compresso (sorgente) sia il video
pippo
compresso (risultato, man mano che
viene calcolato) su tutti i nodi che
replicano il customer.
A
JD
CE
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.
master
M
… alive()
… joinGroup(…)
… leaveGroup(…)
manager
… alive()
… makeDataCheckpoint(…)
… makeSystemCheckpoint(…)
JD
CE
… becomeMaster()
… joinGroup(…)
… leaveGroup(…)
C
copia
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.
Java Distribuited Computing Enviroment
Caduta del Manager
Zzz
Remote
Exception
A
RMIRegistry
19
rebind
al nome del
Remote
master Exception
manager
M
… alive()
JD
CE
Remote
Exception
C
Zzz
pippo
copia
Java Distribuited Computing Enviroment
Caduta del Manager
20
lancio del manager
e rispristino stato
Zzz
RMIRegistry
A
JD
CE
?
?
Zzz
M
C
… becomeMaster()
pippo
copia
master
Java Distribuited Computing Enviroment
21
Caduta del Manager
A
RMIRegistry
JD
CE
lookup del manager
nel registro
M
pippo
master
Java Distribuited Computing Enviroment
22
Caduta del Manager
A
JD
CE
M
pippo
master
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.