MCSA

Mobile Code System Architecture

Infrastruttura a supporto della code mobility

Pierfrancesco Felicioni 171856Reti 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

Macchina specializzata in attesa di task da

eseguireEfficienza

Invia uno o più task sul server sfruttando i

vantaggi di una macchina ad alte performance

Server

Client

Client2

Task

Task

Response

Response

Traffico di rete ridottoSpedisce direttamente un

processo sul server evitando ripetute iterazioni

Permette di aggiornare un server e riqualificarlo senza dover interrompere il servizio: reti intelligenti e

attive

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 Implementazione del modello a copie attive

Trasparenza verso il cliente 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 sistemaClient che richiede di registrarsi presso un

server

Si occupa di assegnare al client un gruppo che gestisca le sue richieste

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

Proxy

Master gruppo1 Master gruppo 2

Slave gruppo 1Slave gruppo1 Slave gruppo 2

Client

Gruppo 1 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

ClientMaster

Slave A

I’m new master

Task

Task

Task

Slave B

Response

Proxy

Il proxy, entità che controlla i master è

caduto

Esempio di gestione dellafault tolerance nel caso peggiore

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 incoerentiNel 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 BalancingNel 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

Client 1

Task

Master gruppo 1

Client 2

Master gruppo 2

Task

Client 3

Task

Proxy

Client 5

Client 4

Task

Client 6

Request Redirected

Redirect Request of Client1

Register Client1 and compute the active

request

Response

I’m your master

Unregistered Client1

Valore soglia pari a 3

Implementazione

Ogni task dovrà implementare la seguente interfaccia:

< ITas k e xte nds Se r i al i zabl e > >

O bje c t run( )S tr ing to S tr ing( )

Il metodo run viene invocato

all’arrivo di un nuovo Task

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