1 OASIS Team, INRIA Sophia-Antipolis/I3S CNRS, Univ. Nice Christian Delbé Data Grid Explorer 15/09/03 Large Scale Emulation Mobility in ProActive

2 Oasis Team Objets Actifs, Sémantique, Internet et Sécurité Common Project : INRIA, CNRS-I3S, UNSA Created in June 1999 Directed by Isabelle Attali Methods and tools for analysis, construction, validation and maintenance of distributed applications

3 Java API+Tools for Parallel, Distributed Computing  Main features :  Remotely accessible Objects (RMI, JINI, UDDI)  Asynchronous Communications with synchronization (automatic futures)  Group Communications, Migration (mobile computations)  XML Deployment Descriptors  Interfaced with various protocols (rsh,ssh,LSF,Globus, ….SOAP)  Visualization and monitoring: IC2D  Requirements : JDK (>= 1.3) ProActive

4  Suited for the Grid (large and heterogeneous systems, high latency,…)  On going large scale SPMD applications environment :  SPMD API based on group communications  Load balancing based on migration  Fault tolerance  Deployment with XML descriptors ProActive and the Grid

5 Recent experiment : Jem3D  In cooperation with CAIMAN project (INRIA Sophia)  Solve 3D Maxwell’s equations in electromagnetism 2 main tests :  On a 64 processors cluster  On desktop machines LAN: 252 processors No more available resources...

6 Objectives with Data Grid Explorer  More resources to confirm scalability  Develop and test new features  new protocols integration  security testing  fault tolerance ...  Need to validate many models  load balancing  migration discussed later ...

7 Migration of Active Objects  Generic mechanism : any active object can migrate  No modification of source code nor bytecode  Weak migration : migration is initiated by the object itself  Automatic and transparent forwarding of:  requests (remote references remain valid)  replies (its previous queries will be fulfilled)

8 Localization of Active Objects  Two approaches  distributed (forwarders) When it migrates, an object leaves a forwarder which leads to its new location  centralized (location server) When it migrates, an object informs a location server of its new location

9 S Host A A Host BHost CHost D S : Source A : Agent F : Forwarder reference Localization using forwarders

10 S Host A Host B A Host CHost D Request forwarding FA F Migration S : Source A : Agent F : Forwarder reference Localization using forwarders

11 Host B F Host C A Host D Update location F S Host A S : Source A : Agent F : Forwarder reference Localization using forwarders

12 Host B F Host C A Host D F S Host A Next communications with the new reference S : Source A : Agent F : Forwarder reference Localization using forwarders

13 Localization of Active Objects  Two approaches  distributed (forwarders) When it migrates, an object leaves a forwarder which leads to its new location  centralized (location server) When it migrates, an object informs a location server of its new location

14 S Host A A Host BHost CHost D S : Source A : Agent reference Server Localization using server

15 S Host A Host B A Host CHost D S : Source A : Agent reference Migration Server Update Localization using server

16 S Host A Host BHost CHost D S : Source A : Agent reference Migration A Server Update Localization using server

17 S Host A Host BHost CHost D S : Source A : Agent reference Message A Server Failed Localization using server

18 S Host A Host BHost CHost D S : Source A : Agent reference A Server Ask for new location Answer Message Localization using server

19  Provide an hybrid protocol : –use forwarders for limited period –if chain is broken, use localization server –a  Parameterized by two values : –TTL (Time To Live) : after TTL, forwarder is garbage collected –TTU (Time To Update): a mobile object update his location every TTU Hybrid protocol : TTL-TTU Forwarders are better on a MAN … but resources consuming ! Server is better on a LAN … but time consuming !

20 First Step : validating models  Modeling using Markov chains for predicting response time (Fabrice Huet ) –validate model with simulations and experiments  But hypothesis cannot be fulfilled ! –Infinite number of hosts, homogeneous latency,…  Determine impact of hypothesis variation

21 Second Step : Determining TTL and TTU  No model of the hybrid protocol (but some insights from previous models)  Determine impact of TTL-TTU values in given conditions  Choose best values for a minimal response time –before deployment –during execution

22 Conclusion  Our objectives are : –Confirm scalability –Test new features –Validate models, localization TTL-TTU  Our requirements are : –a Java runtime (>=1.3) –ProActive packages