Research activities in Grid middleware in the PARIS* research group - - PowerPoint PPT Presentation

research activities in grid middleware in the paris
SMART_READER_LITE
LIVE PREVIEW

Research activities in Grid middleware in the PARIS* research group - - PowerPoint PPT Presentation

Research activities in Grid middleware in the PARIS* research group Thierry Priol IRISA/INRIA * Common project with CNRS, ENS-Cachan, INRIA, INSA, University of Rennes 1 Small Britain PARIS Identity card Created in December 1999 Research


slide-1
SLIDE 1

Research activities in Grid middleware in the PARIS* research group

Thierry Priol IRISA/INRIA

* Common project with CNRS, ENS-Cachan, INRIA, INSA, University of Rennes 1

slide-2
SLIDE 2
  • Research activities
  • Operating Systems for Clusters

and Grids (C. Morin)

  • Software component platform

(J-L. Pazat, C. Pérez, T. Priol)

  • Large Scale Data Management

(G. Antoniu, L. Bougé, Y. Jégou)

  • P2P systems (A-M. Kermarrec)
  • Coordination models (J-P.

Banâtre)

  • Budget in 2003: 620 K€ (not

including salaries of researchers and some of the PhD, ~1670 K€ otherwise)

Small Britain

PARIS Identity card

  • Created in December 1999
  • Head of the project
  • T. Priol (DR INRIA)
  • Researchers-Lecturers
  • J-P. Banâtre (Prof IFSIC)
  • L. Bougé (Prof ENS)
  • J.L. Pazat (Ass. Prof. INSA)
  • Full time researchers
  • G. Antoniu (CR INRIA)
  • Y. Jégou (CR INRIA)
  • A-M. Kermarrec (DR INRIA)
  • C. Morin (DR INRIA)
  • C. Perez (CR INRIA)
  • 3 Engineers
  • 11 PhD Students
slide-3
SLIDE 3

Research activities in Grid Computing

Towards a software component platform for the Grid

Extension/adaptation of existing component models Communication framework for software components Deployment of software components Coordination of components

Towards a shared global address space for the Grid

Distributed shared memory Hierarchical cache coherence protocols A P2P approach for large scale data sharing

slide-4
SLIDE 4

High Performance applications

Not anymore a single parallel application but several of them

  • High performance applications are more and more

complex… thanks to the increasing in performance of

  • ff-the-shelves hardware
  • Several codes coupled together involved in the

simulation of complex phenomena

  • Fluid-fluid, fluid-structure, structure-thermo, fluid-

acoustic-vibration

  • Even more complex if you consider a parameterized

study for optimal design

  • Some examples
  • e-Science
  • Weather forecast: Sea-Ice-Ocean-Atmosphere-Biosphere
  • Industry
  • Aircraft: CFD-Structural Mechanics, Electromagnetism
  • Satellites: Optics-Thermal-Dynamics-Structural Mechanism

Plane wave Scattering of 2 on 1 Virtual plane Scattering of 1 on 2

Object 1 Object 2

Single-physic multiple-object Thermal Dynamics Structural Mechanics Optics

QuickTime™ et un décompresseur TIFF (non compressé) sont requis pour visionner cette image.

Ocean-atmosphere coupling Electromagnetic coupling Multiple-physics single-object

slide-5
SLIDE 5

The current practice…

SAN cluster

Code coupler (MpCCI, OASIS …)

MPI code #1

MPI implementation

MPI code #2 MPI code #n MPI code #3

  • Coupling is achieved through the use
  • f specific code coupling tools
  • Not just a matter of communication !
  • Interpolation, time management, …
  • Examples: MpCCI, OASIS, PAWS,

CALCIUM, ISAS, …

  • Limitations of existing code coupling

tools

  • Originally targeted to parallel

machines with some on-going works to target Grid infrastructure

  • Static coupling (at compile time): not

“plug and play”

  • Ad-hoc communication layers (MPI,

sockets, shared memory segments, …)

  • Lack of explicit coupling interfaces
  • Lack of standardization
  • Lack of interoperability

MPI MpCCI Code A Code B MpCCI The MpCCI coupling library

slide-6
SLIDE 6

Another approach for code coupling

We need a programming model suitable for the Grid !

Code A

Code interface

Out In Code B

Code interface

Out In

  • Component definition by C. Szyperski
  • “A component is a unit of independent

deployment”

  • “Well separated from its environment and from
  • ther components”
  • Component programming is well suited for

code coupling

  • Codes are encapsulated into components
  • Components have public interfaces
  • Components can be coupled together or through

a framework (code coupler)

  • Components are reusable (with other

frameworks)

  • Application design is simpler through composition

(but component models are often complex to master !)

  • Some examples of component models
  • HPC component models
  • CCA, ICENI
  • Standard component models
  • EJB, DCOM/.NET, OMG CCM

Code coupler Component-based framework

In Out Out In Out Out Code B

Code interface

Out In Code D

Code interface

Out In Code C

Code interface

Out In In In Code A

Code interface

Out In

slide-7
SLIDE 7

Distributed components: OMG CCM

we like CORBA but seems to be alone in the Grid community

  • A distributed component-oriented model
  • An architecture for defining components

and their interaction

  • Interaction implemented through

input/output interfaces

  • Synchronous and asynchronous

communication

  • A packaging technology for deploying

binary multi-lingual executables

  • A runtime environment based on the

notion of containers (lifecycle, security, transaction, persistent, events)

  • Multi-languages, multi-OS, multi-ORBs,

multi-vendors, …

  • Include a deployment model
  • Could be deployed and run on several

distributed nodes simultaneously My Component Component interface Facets Event sources Event sinks Attributes Receptacles OFFERED REQUIRED

Component-based application

slide-8
SLIDE 8

CCM in the context of HPC

  • Encapsulation of parallel codes into software components
  • Parallelism should be hidden from the application designers as much as

possible when assembling components

  • Issues:

How much my parallel code has to be modified to fit the CCM model What has to be exposed outside the component ?

  • Communication between components
  • Components should use the available networking technologies to let

components to communicate efficiently

  • Issues:

How to combine multiple communication middleware/runtime and to make

them to run seamlessly and efficiently ?

How to manage different networking technologies transparently ? Can my two components communicate using Myrinet for one run and using

Ethernet for another run without any modification, recompilation,..?

slide-9
SLIDE 9

Making CORBA Components parallel-aware

What the application designer should see…

  • Communication between

components :

  • Implemented through a remote

method invocation (to a CORBA

  • bject)
  • Constraints
  • A parallel component with one

SPMD process = a standard component

  • Communication between

components should use the ORB to ensure interoperability

  • Little but preferably no modification

to the CCM specification

  • Scalable communication between

components by having several data flows between components

HPC Component A HPC Component B

… and how it must be implemented !

// Comp. A SPMD Proc. SPMD Proc. SPMD Proc. SPMD Proc. SPMD Proc.

// Comp. B SPMD Proc. SPMD Proc. SPMD Proc. SPMD Proc. SPMD Proc.

slide-10
SLIDE 10

GridCCM

interface Interfaces1 { void example(in Matrix mat); }; … component A { provides Interfaces1 to_client; uses Interfaces2 to_server; }; Parallel Component Of type A

  • Comp. A-0

SPMD Proc.

  • Comp. A-4
  • Comp. A-0

SPMD Proc.

  • Comp. A-3
  • Comp. A-0

SPMD Proc.

  • Comp. A-2
  • Comp. A-0

SPMD Proc.

  • Comp. A-1
  • Comp. A-0

SPMD Proc.

  • Comp. A-0

to_client to_server Component: A Port: to_client Name: Interfaces1.example Type: Parallel Argument1: *, bloc …

XML IDL

slide-11
SLIDE 11

Runtime support for a grid-aware component model

  • Main goal for such a runtime
  • Should support several communication runtime/middleware at the same time
  • Parallel runtime (MPI) & Distributed Middleware (CORBA) such as for GridCCM
  • Underlying networking technologies not exposed to the applications
  • Should be independent from the networking interfaces
  • Let’s take a simple example
  • MPI and CORBA using the same protocol/network (TCP/IP, Ethernet)
  • MPI within a GridCCM component, CORBA between GridCCM components
  • The two libraries are linked together with the component code, does it work ?
  • Extracted from a mailing list:

Message 8368 of 11692 | Previous |Next [ Up Thread ] Message Index From: ------- -------- < -.-----@n... > Date: Mon May 27, 2002 10:04 pm Subject: [mico-devel] mico with mpich I am t r y i n g to run a M i co p rog ram in pa ra l l e l us i ng mp ich . When cal l i ng CORBA: :ORB_ in i t ( a rgc , a rgv ) i t seems to cor edump . Does anyone have expe r i ence i n runn i ng m ico and mp ich a t t he same t ime?

slide-12
SLIDE 12

PadicoTM architecture overview

OmniORB MICO Orbacus Orbix/E Kaffe Mome Mpich CERTI

  • Provide a set of personalities to

make easy the porting of existing middleware

  • BSD Socket, AIO, Fast

Message, Madeleine, …

  • The Internal engine controls the

access to the network and scheduling of threads

  • Arbitration, multiplexing,

selection, …

  • Low level communication layer

based on Madeleine

  • Available on a large number of

networking technologies

  • Associated with Marcel

(multithreading)

DSM JVM MPI CORBA HLA

PadicoTM Services

Madeleine

Portability across networks

Marcel

I/O aware multi-threading

Myrinet SCI Multithreading Network s TCP Personality Layer Internal engine

PadicoTM Core

This work is supported by the Incentive Concerted Action ``GRID'' (ACI GRID) of the French Ministry of Research.

slide-13
SLIDE 13

Performances

Experimental protocols

  • Runtimes and middleware:

MPICH, CORBA OmniORB3, Kaffe JVM

  • Hardware: Dual-Pentium III 1

Ghz with Myrinet 2000, Dolphin SCI

Performance results

  • Myrinet-2000

MPI: 240 MB/s, 11 µs CORBA: 240 MB/s, 20 µs 96 % of the maximum

achievable bandwidth of Madeleine

  • SCI

MPI: 75 MB/s, 23 µs CORBA: 89 MB/s, 55 µs

50 100 150 200 250 1 10 100 1000 10000 100000 10000001E+07 Message size (bytes)

CORBA/Myrinet-2000 MPI/Myrinet-2000 Java/Myrinet-2000 CORBA/SCI MPI/SCI TCP/Ethernet-100

Bandwidth (MB/s)

18 µs

slide-14
SLIDE 14

Peer-to-Peer applied to Storage Grid

Cluster A Cluster B Cluster C Cluster D

  • Idea
  • Provide a global address space for the

Grid

  • A peer is a cluster
  • Locate available memory resources

within a set of peers

  • Distributed storage: store distributed

data among a set of peers

  • Replicate data through consumer peers
  • Build reliability & performance through

replication

  • Problems
  • Data coherency due to data replication
  • Implementation
  • JXTA: a set of XML-based protocol to

implement P2P services This work is supported by the Incentive Concerted Action ``Masse de Données'’ (ACI MD) of the French Ministry of Research.

slide-15
SLIDE 15

PARIS involvement in GRID initiatives

National projects

ACI GRID GRID2: scientific

animation of the French Grid scientific community

ACI GRID HYDROGRID: Grid

applications

ACI GRID ANIMAGRID:

scientific animation related to storage Grid

ACI GRID GRID’5000: set up a

National Grid infrastructure

ACI MD GDS: Large Scale Data

Management

ACI MD GdX: Grid Data

Explorer

  • International projects
  • STAR French-South Korean Grid

collaboration (with NSU)

  • University of New Hampshire

(USA)

  • European initiatives (FP6)
  • NoE CoreGRID (Scientific

Coordinator)

  • SSA EGRESS
  • SSA GridCoord
  • National projects
  • RNTL Casper : ASP scientific

computing

  • RNTL E-Toile: Grid computing

platform

  • RNRT VTHD/VTHD ++: High-

bandwidth wide area network experiments

  • ACI GRID RMI: High-performance

distributed objects platform

slide-16
SLIDE 16

PARIS involvement in GRID’5000

48 ports Fast-Iron 1 Gbit Switch

100 Mbit/s November 2003 December 2003

32 32 Catalyst 6500 router

VTHD 2.5 Gbit/s 3 x 1 Gbit/s Q2 2004 Q2 2005

96 96

Around 50 nodes (PC, Apple) in 2003… Around 256 nodes (512 processors) in 2005…

slide-17
SLIDE 17

Conclusions

PARIS research activities

Not on the Grid main stream (no Grid services or a bit)… with

some technology risks (CORBA…) but we are civil servants…

We are more interested to work on concepts (including their

validation through research prototypes) rather than the development of the whole grid software infrastructure

We are looking for collaborations on

The infrastructure level for component deployments Applications, applications and applications…