DReflect Middleware riflessivo per la distribuzione di applicazioni Java su cluster Grid Borsista COMETA: Paolo Giarrusso (10 mesi, apr - sett 2007, feb - mag 2008) UniCT: Giuseppe Pappalardo, Emiliano Tramontana Dipartimento di Matematica e Informatica, Università di Catania
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 scegliere dinamicamente, in base alle caratteristiche delle classi applicative e delle risorse Grid disponibili, l’host che eseguirà le classi
DReflect DReflect permette l’analisi delle caratteristiche di una classe Java la trasformazione automatica del bytecode di applicazioni Java centralizzate ai fini specificati nei due punti seguenti l’implementazione di varie politiche di allocazione ai fini della scelta degli host che eseguiranno oggetti a runtime la distribuzione trasparente delle classi e delle interazioni tra i vari oggetti eseguiti 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
Politiche di allocazione Per l’allocazione di oggetti, DReflect fornisce alcune politiche che operano in base alle caratteristiche delle classi, p.es.: Match dei requisiti In base alle caratteristiche di una classe, trova, tra gli host disponibili, quello con le librerie ed il tipo di CPU più appropriati Bilancia il carico tra gli host: l’allocazione è possibile su un host quando il suo workload è minore di una soglia Minimizzazione del ritardo di comunicazione tra oggetti Nel rispetto della soglia di workload degli host, invia, sullo stesso host o su host “vicini”, oggetti fortemente accoppiati Una misura di “vicinanza” per gli host è effettuata, a priori, sulla base della latenza nelle comunicazioni tra ciascuna coppia di host
Architettura di DReflect
Architettura di DReflect In ambiente Grid vengono eseguiti tramite opportuni JDL un job lato client su un worker node uno o più job lato server su altrettanti worker node A regime tipicamente il job lato client eseguirà alcune classi di UI ed ogni job lato server alcune classi remotizzate in automatico da DReflect Ogni job lato server comunica il proprio IP a un repository, poi si mette in ascolto di richieste di esecuzioni tramite il componente ServerProxy Inizialmente il job lato client contiene l’applicazione Java da distribuire, che viene avviata su un unico worker node nella fase di caricamento il bytecode delle classi verrà trasformato per consentire il controllo trasparente dell’applicazione da parte di DReflect La classe Interceptor è associata riflessivamente con ogni classe applicativa e ne attua in remoto, quando occorre, istanziazioni e chiamate ad altri oggetti La Riflessione Computazionale (e la manipolazione del bytecode) permettono di intercettare allocazioni ed esecuzioni di metodi
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 vengono modificate come segue, così da poter gestire la comunicazione remota: ob.m1(args) in _metaObj.trapMethodCall(ob, args, “m1”) L’istanza ob di ObjRRef registra: il nome della classe che ob rappresenta un identificatore dell’oggetto remoto corrispondente un identificatore dell’host remoto
Trasformazioni a Load-time TranslatorOut cambia i tipi dei parametri delle chiamate remote nel tipo ObjRRef I parametri originari sono oggetti che dovranno essere acceduti da parte di un host remoto La trasformazione permette la gestione della comunicazione remota Nella classe remota tutti gli accessi a tale parametro trasformato 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(...)
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 invoca metodi di un’istanza di InfoElement La classe Request è accoppiata con la classe InfoElement La classe InfoElement non è accoppiata con altre classi Istanze di Request e InfoElement vengono distribuite a runtime (lato server) al momento della loro istanziazione sui worker node disponibili, grazie alle politiche di ottimizzazione della comunicazione e al load-balancing
Conseguenze e conclusioni L’applicazione BasicSearch viene distribuita trasparentemente, come desiderato, sui worker node disponibili Sono state valutate le prestazioni dell’applicazione distributa e confrontate con quelle dell’esecuzione centralizzata 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
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
Bibliografia G. Novelli, G. Pappalardo, C. Santoro, E. Tramontana. Transcoding Agents for Multimedia Content Delivery in a Grid. In Proceedings of the International Transactions on Systems Science and Applications. 2006 G. Novelli, G. Pappalardo, C. Santoro, E. Tramontana. A Grid-based Infrastructure to Support Multimedia Content Distribution. In Proceedings of ACM UPGRADE-CN Workshop of HPDC. 2007 R. Giunta, G. Pappalardo, E. Tramontana. An Aspect-Generated Approach for the Integration of Applications into Grid. In Proceedings of ACM SAC. 2007 R. Giunta, G. Pappalardo, E. Tramontana. Handling Replica Management Concerns by means of Aspects. In Proceedings of IEEE WETICE. 2007 R. Giunta, F. Messina, G. Pappalardo, L. Toscano, E. Tramontana. Testing Replica Selection Policies in a pan-European Grid VO. In Proceedings of IEEE WETICE. 2008 R. Giunta, F. Messina, G. Pappalardo, E. Tramontana. Analysing the Performances of Grid Services handling Job Submission. In Proceedings of IEEE WETICE. 2009 R. Giunta, F. Messina, G. Pappalardo, E. Tramontana. Measuring Performances of Globus Toolkit middleware Services. In Proceedings of Workshop finale dei Progetti Grid del PON "Ricerca" 2000-2006 - Avviso 1575. 2009 R. Giunta, F. Messina, G. Pappalardo, E. Tramontana. Improving the Performances of a Grid Infrastructure by means of Replica Selection Policies. In Proceedings of Workshop finale dei Progetti Grid del PON "Ricerca" 2000-2006 - Avviso 1575. 2009 12