presentazione

MCSA
Infrastruttura a supporto della code
mobility
Mobile Code System Architecture
Pierfrancesco Felicioni 171856
Reti di Calcolatori L.S. 2005/2006
Definizioni
Mobile Code: software in grado di
viaggiare su una rete eterogenea,
attraversando domini di protezione e che
può essere eseguito automaticamente
all’arrivo a destinazione
 Mobile Computation: computazione che
inizia su qualche nodo lungo una rete, e
che può continuare la sua esecuzione su
qualche altro nodo

Vantaggi del Code Mobility
Permette di aggiornare
un server e riqualificarlo
senza dover interrompere
il servizio: reti intelligenti e
attive
Traffico di rete ridotto
Spedisce direttamente un
processo sul server
evitando ripetute iterazioni
Task
Client
Response
Server
Efficienza
Invia uno o più task sul
server sfruttando i
vantaggi di una macchina
ad alte performance
Task
Response
Client2
Macchina specializzata
in attesa di task da
eseguire
Obbiettivi

Realizzare una architettura a supporto della code
mobility che sia:

Tollerante ai guasti

Replicazione

Trasparente verso il cliente

Affidabile


Controllo correttezza delle risposte
Efficiente

Load Sharing/Balancing
Analisi

Tolleranza ai guasti


Trasparenza verso il cliente



Implementazione del modello a copie attive
All’atto del collegamento
In caso di guasto
Efficienza

Ottenuta mediante un bilanciamento del carico di
lavoro, fra le entità che forniscono il servizio
Architettura


L’architettura che è stata implementata è la
Client/Server
Per ovviare ai tipici problemi di una architettura
centralizzata sono state introdotte forme di replicazione
(copie attive).



Il client invia dei task da eseguire ad un gestore (master) che
passa le richieste alle varie copie (slave)
Il gestore coordina gli slave e verifica la correttezza delle
risposte, restituendo il risultato al client
In questo modo il client comunica con i servitori in modo
implicito
Architettura del sistema
Si occupa di assegnare
al client un gruppo che
gestisca le sue richieste
Client che richiede di
registrarsi presso un
server
Proxy
Ogni gruppo di server è
formato da un master e
zero o più slave
Il proxy conosce la
composizione di ogni
gruppo, poiché tutti i
server devono registrarsi
presso di lui
Gli slave eseguono le
stesse operazioni: copie
attive
Client
Gruppo 1
Master gruppo1
Slave gruppo1
Slave gruppo 1
Gruppo 2
Master gruppo 2
Slave gruppo 2
Fault Tolerance

E’ stato implementato il modello a copie
attive. Il sistema gestisce i seguenti fault:

Caduta del master

Mentre è idle


Ogni master è controllato dagli stessi slave e dal proxy
Durante la gestione di una richiesta da parte del
client

Il master dopo aver ricevuto un task (richiesta) la
inoltra sugli slave. Lo slave designato come nuovo
master, invia la risposta al client in call back e
aggiorna i riferimenti del client (trasparenza).
Fault Tolerance
Esempio di gestione della
fault tolerance nel caso peggiore
I’m new master
Response
Task
Task
Slave A
Client
Master
Task
Il proxy, entità che
controlla i master è
caduto
Proxy
Slave B
Fault Tolerance

Caduta di uno slave:

Mentre è idle: il master controlla periodicamente
gli slave del proprio gruppo.


In caso in cui uno slave cade il master provvede a
rimuoverlo dalla sua lista e a notificarlo agli altri
componenti del gruppo
Prima di rispondere ad una richiesta inoltrata dal
master:

Ogni task inviato dal client viene eseguito su tutti gli
slave. Il master prima di inviare un responso, controlla
che tutti gli slave abbiano risposto.
 In caso contrario accerta che non ci sia qualche
slave caduto, se si, lo deregistra e lo notifica al resto
del gruppo
Fault Tolerance

Risposte incoerenti

Nel caso in cui le risposte restituite dagli slave,
siano incoerenti

Viene scelta la risposta data dal maggior numero di
server facenti parte del gruppo

Nel caso in cui i responsi siano tutti diversi fra loro,
viene restituita al client una condizione di errore
Efficienza

Proxy Load Sharing

Decide quale gruppo assegnare ad un client,
in base a due parametri:


Numero di richieste attualmente gestite
Numero di client connessi
Questo tipo di bilanciamento (a priori) non è efficace. Supponiamo che
in una fase successiva, i client connessi ad un gruppo inizino ad
inviare un numero esorbitante di richieste, mentre nell’altro gruppo
questa situazione non si verifichi. In questo caso il bilanciamento del
carico non avrebbe esordito l’effetto voluto.
Efficienza

Master Load Balancing

Nel caso in cui il numero di richieste da
gestire superi una certa soglia, il master
chiede al proxy di poterle smistare su un
altro gruppo.

Se il proxy non riesce nell’intento, il master
raggiunto il valore soglia rifiuta ulteriori
registrazioni da parte di altri client.
Master Load Balancing
Valore soglia pari a 3
Unregistered Client1
Request Redirected
Client 2
Task
Task
Client 3
Master gruppo 1
Task
Response
Client 1
Proxy
Redirect Request of
Client1
I’mClient
your
6 master
Master gruppo 2
Task
Register Client1 and
compute the active
request
Client 4
Client 5
Implementazione

Ogni task dovrà implementare la
seguente interfaccia:
Il metodo run viene invocato
all’arrivo di un nuovo Task
<ITask extends Serializable>>
Object run()
String toString()
Il metodo toString permette di
confrontare i vari risultati
Conclusioni

Il sistema che è stato realizzato, soddisfa i
requisiti di cui si è parlato precedentemente:





Affidabilità
Trasparenza
Efficienza
Tolleranza ai guasti
Tuttavia…..

Il sistema è basato su una struttura centralizzata

Il proxy è un entità centrale del sistema.
Sviluppi futuri

Gestire la fault tolerance lato proxy
 Introdurre forme di sicurezza

Autenticazione del client

Supporto per la strong mobility
 Composizione automatica di gruppi di server
in modo da trovare un compromesso tra:


Replicazione
Load Balancing