OASIS Team, INRIA Sophia-Antipolis/I3S CNRS, Univ. Nice Christian Delbé Data Grid Explorer

1

OASIS Team, INRIA Sophia-Antipolis/I3S CNRS, Univ. Nice

Christian Delbé

Data Grid Explorer15/09/03

Large Scale EmulationMobility 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 (isabelle.attali@sophia.inria.fr)

Methods and tools for analysis, construction, validation and maintenance of distributed applications

3

Java API+Tools for Parallel, Distributed ComputingMain features :

Remotely accessible Objects (RMI, JINI, UDDI)Asynchronous Communications with synchronization

(automatic futures) Group Communications, Migration (mobile computations)XML Deployment DescriptorsInterfaced 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 communicationsLoad balancing based on migrationFault toleranceDeployment 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...

0

100

200

300

400

500

600

700

800

900

0 10 20 30 40 50 60 70

# of processors

Du

rati

on

(sec)

21*21*21

31*31*31

43*43*43

55*55*55

81*81*81

97*97*97

113*113*113

121*121*121

6

Objectives with Data Grid Explorer

More resources to confirm scalability

Develop and test new features new protocols integrationsecurity testingfault tolerance ...

Need to validate many models load balancingmigration 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 B Host C Host D

S : SourceA : AgentF : Forwarder

reference

Localization using forwarders

10

S

Host A

Host B

A

Host C Host D

Request

forwarding forwardingF AF

Migration Migration

S : SourceA : AgentF : Forwarder

reference

Localization using forwarders

11

Host B

F

Host C

A

Host D

Update location

F

S

Host A S : SourceA : AgentF : 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 : SourceA : AgentF : 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 B Host C Host D

S : SourceA : Agent

referenceServer

Localization using server

15

S

Host A

Host B

A

Host C Host D

S : SourceA : Agent

reference

Migration

Server

Update

Localization using server

16

S

Host A

Host B Host C Host D

S : SourceA : Agent

reference

MigrationA

Server

Update

Localization using server

17

S

Host A

Host B Host C Host D

S : SourceA : Agent

reference

Message

A

Server

Failed

Localization using server

18

S

Host A

Host B Host C Host D

S : SourceA : Agent

reference

A

ServerAsk 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 - 2003)– 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