Martedi 8 novembre 2005 Consorzio COMETA Progetto PI2S2 FESR DReflect Middleware riflessivo per la distribuzione di applicazioni Java su cluster Grid Borsista.

Presentazione sul tema: "Martedi 8 novembre 2005 Consorzio COMETA Progetto PI2S2 FESR DReflect Middleware riflessivo per la distribuzione di applicazioni Java su cluster Grid Borsista."— Transcript della presentazione:

1 martedi 8 novembre 2005 Consorzio COMETA Progetto PI2S2 FESR DReflect Middleware riflessivo per la distribuzione di applicazioni Java su cluster Grid Borsista COMETA: Paolo Giarrusso (6 mesi, apr - sett 2007) UniCT: Giuseppe Pappalardo, Emiliano Tramontana Dipartimento di Matematica e Informatica, Università di Catania

2 Obiettivi ● ● “Verrà considerato l'impiego di tecniche di progettazione a oggetti innovative per l’ambito Grid, quali la riflessione computazionale, miranti a un'integrazione quanto più possibile trasparente tra l'applicazione e il supporto proposto per la gestione delle risorse” [Allegato B, pag. 79] ● ● Pertanto DReflect mira a costituire il prototipo di un middleware che – – consenta a un’applicazione Java nata per un ambiente centralizzato di “girare” su Grid in modo distribuito, su n host (worker node) disponibili, in maniera trasparente ● ● Si è quindi resa necessaria la trasformazione automatica di applicazioni Java, per abilitarle all’uso trasparente dell’ambiente distribuito ● ● E’ stato sviluppato un set di componenti per: – – la gestione delle interazioni tra le varie parti remote – – la trasformazione del bytecode di un’applicazione, ai fini di inserirvi il supporto per le interazioni con le parti remote – – l’ispezione delle caratteristiche delle classi applicative ● ● L’host scelto per allocare le classi applicative si basa sulle caratteristiche di classi e risorse disponibili su Grid

3 DReflect DReflect permette – – L’analisi delle caratteristiche di una classe Java – – L’esecuzione di varie politiche di allocazione che scelgono gli host che riceveranno oggetti a runtime – – La trasformazione automatica del bytecode di applicazioni Java centralizzate – – La distribuzione trasparente delle classi e delle interazioni tra vari oggetti che eseguono in ambito distribuito DReflect ispeziona il bytecode di una classe per ricavare – – Il grado di accoppiamento tra classi misurato come il numero di invocazioni trovate nel codice – – Le percentuali di bytecode di una classe che si riferiscono all’uso di CPU e IO

4 ● ● DReflect fornisce alcune politiche per l’allocazione di oggetti che operano in base alle caratteristiche delle classi – – Match di requisiti ● ● Per le caratteristiche della classe, trova le librerie software, la CPU e l’ammontare di RAM più appropriate tra i vari host disponibili ● ● Bilancia il carico sugli host, l’allocazione è possibile su un host quando il suo workload è minore di una soglia – – Minimizza il ritardo di comunicazione tra oggetti ● ● In accordo al workload degli host, manda oggetti che interagiscono molto sullo stesso host o su host “vicini” ● ● Una misura di “vicinanza” è calcolata a priori per gli host sulla base della latenza nelle comunicazioni tra ciascuna coppia di host Politiche di allocazione

5 Architettura di DReflect ● ● Alle risorse Grid è richiesta l’esecuzione di un job lato server (tramite opportuno JDL) su alcuni worker node e di un job lato client ● ● Il job lato server comunica il proprio indirizzo IP ad un repository e si mette in ascolto di richieste (di allocazioni ed esecuzioni) tramite il componente ServerProxy ● ● Il job lato client contiene l’applicazione Java da distribuire, che comincia ad eseguire su un unico worker node, nella fase di caricamento le classi verranno trasformate ● ● La classe Interceptor è associata riflessivamente con ogni classe dell’applicazione e per ogni istanza ridirige in remoto, quando occorre, istanziazioni e chiamate ad altri oggetti – – La Riflessione Computazionale (e la manipolazione del bytecode) permettono di catturare allocazioni ed esecuzioni di metodi di altre istanze ● ● La classe Locator è usata sia lato client che lato server per tenere le posizioni degli oggetti distribuiti

6 Trasformazioni a Load-time ● ● Il componente TranslatorOut cambia il bytecode di ciascuna classe dell’applicazione, usando la libreria Javassist – – Per ciascuna classe trasformata, i riferimenti a potenziali oggetti remoti sono cambiati nel tipo ObjRRef – – Un parametro di configurazione suggerisce quali classi possono diventare remote – – Le invocazioni verso potenziali oggetti remoti sono cambiate, così da poter gestire la comunicazione remota ob.m1(args) in _metaObj.trapMethodCall(ob, args, “m1”) ● ● L’istanza ob di ObjRRef tiene: – – il nome della classe che rappresenta – – un identificatore dell’istanza sull’host remoto – – un identificatore dell’host remoto

7 Trasformazioni a Load-time TranslatorOut cambia i tipi dei parametri per le invocazioni remote nel tipo ObjRRef – – Tali parametri sono oggetti acceduti da un host remoto La trasformazione permette la gestione della comunicazione remota Nella classe remota tutti gli accessi a tale parametro saranno gestiti tramite intercettazione TranslatorOut inserisce dei controlli per evitare la gestione di una invocazione tramite riflessione quando l’istanza potenzialmente in remoto è in effetti locale – – Questo riduce l’overhead della riflessione ob.m1(a) in if (ob==this) ob.m1(a) else if(ob.isLocal()) ob.getLocalObject().m1(a) else _metaObj.trapMethodCall(...)

8 Esperimento ● ● Vedremo un esperimento in cui il job lato server è mandato in esecuzione su n worker node, comincia ad eseguire, comunica il proprio indirizzo, si mette in ascolto di connessioni remote ● ● Il job lato client, contenente l’applicazione BasicSearch, è mandato in esecuzione, trasforma il bytecode, esegue l’applicazione che permette di cercare in parallelo una chiave su un repository di dati – – Diversi thread (istanze di classe Request) per la ricerca sono fatti partire ed ogni thread esegue su una istanza di InfoElement – – La classe Request è accoppiata con la classe InfoElement (6 chiamate di metodo) – – La classe InfoElement non è accoppiata con altre classi – – Istanze di Request e InfoElement vengono distribuite a runtime al momento della loro istanziazione sui worker node (lato server) disponibili, grazie all’adozione della politica che tiene conto di accoppiamento e load-balancing

9 Conseguenze e conclusioni ● ● L’applicazione suddetta viene distribuita, come desiderato, sui worker node disponibili, trasparentemente ● ● I tempi di esecuzione quando vari thread sono in esecuzione diminuiscono rispetto all’esecuzione centralizzata, ammortizzando quindi l’overhead dovuto alle comunicazioni tra host ● ● La Riflessione Computazionale è stata usata per ottenere trasparenza nella gestione del deployment remoto di oggetti ● ● Sono state realizzate alcune politiche per allocare in modo efficace gli oggetti sulla base delle loro caratteristiche ● ● Sono state valutate le prestazioni dell’applicazione distributa e confrontate con quelle dell’esecuzione centralizzata

10 Bibliografia ● ● A. Di Stefano, M. Fargetta, G. Pappalardo, E. Tramontana. Supporting Resource Reservation and Allocation for Unaware Applications in Grid Systems. In Journal of Concurrency & Computation: Practice & Experience (CCPE). John Wiley. Volume 18, Issue 8. 2006. ● ● P. Giarrusso, G. Pappalardo, L. Toscano, E. Tramontana. RexMidas: A Reflective Middleware for Transparently and Effectively Distributing Objects on a Grid System. In Proceedings of IEEE WETICE. 2008 ● ● P. Giarrusso, G. Pappalardo, E. Tramontana. RexMidas: Automatically Spreading an OO Application over Grid Resources. In Proceedings of Workshop finale dei Progetti Grid del PON "Ricerca" 2000-2006 - Avviso 1575. 2009