MCSA Mobile Code System Architecture Infrastruttura a supporto della code mobility Pierfrancesco Felicioni 171856 Reti di Calcolatori L.S. 2005/2006.

Presentazione sul tema: "MCSA Mobile Code System Architecture Infrastruttura a supporto della code mobility Pierfrancesco Felicioni 171856 Reti di Calcolatori L.S. 2005/2006."— Transcript della presentazione:

1 MCSA Mobile Code System Architecture Infrastruttura a supporto della code mobility Pierfrancesco Felicioni 171856 Reti di Calcolatori L.S. 2005/2006

2 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

3 Vantaggi del Code Mobility Macchina specializzata in attesa di task da eseguire Efficienza Invia uno o più task sul server sfruttando i vantaggi di una macchina ad alte performance Traffico di rete ridotto Spedisce direttamente un processo sul server evitando ripetute iterazioni Permette di aggiornare un server e riqualificarlo senza dover interrompere il servizio: reti intelligenti e attive

4 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

5 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

6 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

7 Architettura del sistema Client 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

8 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).

9 Fault Tolerance I’m new master Task Response Il proxy, entità che controlla i master è caduto Esempio di gestione della fault tolerance nel caso peggiore

10 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

11 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

12 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.

13 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.

14 Master Load Balancing Task 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

15 Implementazione Ogni task dovrà implementare la seguente interfaccia: Il metodo run viene invocato all’arrivo di un nuovo Task Il metodo toString permette di confrontare i vari risultati

16 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.

17 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