Upload
jasmin-fisher
View
223
Download
0
Embed Size (px)
DESCRIPTION
3 Background: CCA and H2O Common Component Architecture (CCA) Component standard for HPC Uses and provides ports described in SIDL Support for scientific data types Existing tightly coupled (CCAFFEINE) and loosely coupled, distributed (XCAT) frameworks H2O Distributed resource sharing platform Providers setup H2O kernel (container) Allowed parties can deploy pluglets (components) Separation of roles: decoupling Providers from deployers Providers from each other RMIX: efficient multiprotocol RMI extension
Citation preview
1
ProActive GCM – CCA Interoperability
Maciej Malawski, Ludovic Henrio, Matthieu Morel, Francoise Baude, Denis Caromel, Marian Bubak
Institute of Computer Science AGH, Kraków, Poland Academic Computer Centre CYFRONET-AGH, Kraków, PolandINRIA – I3S – CNRS – UNSA, Sophia-Antipolis, France
2
Outline
• Background: H2O and MOCCA• Motivation• CCA and Fractal – comparison• Approach to interoperability• Typing and ADL issues• Technical approach• Application example• Next steps
3
Background: CCA and H2O
ContainerProvider host
Deploy Lookup& use
Provider Client
<<create>>
B
A
Provider
<<create>>A
B
Container
Lookup& use
Client
Deploy Provider,Client,
or Reseller
Provider host
Traditional model
Proposed model
ContainerProvider host
Deploy Lookup& use
Provider Client
<<create>>
BB
AA
Provider
<<create>>AA
BB
Container
Lookup& use
Client
Deploy Provider,Client,
or Reseller
Provider host
Traditional model
Proposed model
• Common Component Architecture (CCA) Component standard for HPC Uses and provides ports described in
SIDL Support for scientific data types Existing tightly coupled (CCAFFEINE)
and loosely coupled, distributed (XCAT) frameworks
• H2O Distributed resource sharing platform Providers setup H2O kernel (container) Allowed parties can deploy pluglets
(components) Separation of roles: decoupling
• Providers from deployers• Providers from each other
RMIX: efficient multiprotocol RMI extension
4
MOCCA – a Distributed CCA Framework Based on H2O
• Each component is a separate pluglet Dynamic remote deployment of components Components packaged as JAR files Security: Java sandboxing, detailed access policy
• Using RMIX for communication – efficiency, multiprotocol interoperability• Flexibility and multiple scenarios – as in H2O• MOCCA_Light: pure Java implementation
Java API or Jython and Ruby scripting for application asssembly• http://www.icsr.agh.edu.pl/mambo/mocca
ComponentPlugletComponent
Pluglet
CCAComponent
ComponentPluglet
CCAComponent
BuilderPluglet
H2O Kernel
BuilderService
Invoke
Manage
Builder
CCACCAPluglet Pluglet
Builder Builder
CCACCA
Pluglet Pluglet
BuilderBuilder
CCACCA
Pluglet Pluglet
Builder
MoccaMainBuilder
MoccaMainBuilder
5
GCM (Current state)
•Based on Fractal Model
•Deployment Functionalities
•Asynchronous and extensible port semantics
•Collective Interfaces
•Autonomicity and adaptivity thanks to “autonomic” and “dynamic” controllers
•Support for language neutrality and interoperability
ComponentIdentity
BindingController
LifeCycleController
ContentController
ContentController
6
Motivation• Framework interoperability is an important issue
for GCM• Existing component models and frameworks for
Grids CCA, CCM
• Already existing „legacy” components• Web Services are not enough
Performance Composition
• ProActive/Fractal and H2O/MOCCA – alternative Java-based frameworks for distributed computing: can they interoperate?
7
Fractal vs. CCA
• Similarities: general for most component models Separation of interface from implementation Composition by connecting interfaces
• Differences Fractal components are reflective (introspection) vs. the CCA
components are given initiative to add/remove ports at runtime BindingController in Fractal vs. BuilderService in CCA No ContentController in CCA (and no hierarchy) Factory interface in Fractal vs. BuilderService in CCA AttributeController in Fractal vs. ParameterPort in CCA No ADL in CCA
8
Approaches Discussed• Single component
integration Wrapping a CCA component
into a primitive GCM one Allow to use a CCA
component in a GCM framework
• Framework interoperability Ability for two component
frameworks to interoperate Allow to connect a CCA
component assembly (running in a CCA framework) to a GCM component application
Wrapper
CCA Component
C BC
cca.Services
Wrapper
CCA Component
C BC
CCA Component
CCA Component
BuilderService
GlueGlue
CCA Framework
9
Solutions to typing issues
1. Generate the type of a wrapped CCA component at runtime (at initialization) Pros: fully automated Cons: restricts to usage of ports which are declared by CCA
component during initialization (at setServices() call)
2. Manual description of a CCA component in ADL format Pros: Generic solution Cons: Require additional task from developer
3. (Semi)automatic generation of ADL• May combine approach 1. and 2.
4. Reuse existing CCA type specifications (SIDL, CCAFFEINE scripting, others – not standardized)
10
Technical approach – CCA controller
• Creates glue components for all ports (client and server)• Connects glue to CCA system (using CCA builder) and to membrane
(using BC)
CCAController
CCA Component
C
CCA Component
CCA Component
BuilderService
Server Glue A
CCA Framework
ClientGlue B
BC
BC
WA
CCA
A AA A
B B B BB
H2O Kernel
H2O Kernel
H2O Kernel
11
Glue Components• Server Glue:
Deployed as Fractal component Uses MOCCA client code to delegate
invocation to CCA interface Can be also deployed on H2O kernel
• Client Glue: Deployed as CCA component in H2O
kernel Launches ProActive runtime in H2O
kernel Creates Fractal component in this
runtime
• Both: Can be generated from the interface
type (TODO)
CCA Component Client
Glue B
BC
B B B B
H2O Kernel
CCA Component
Server Glue A
WA
AA A
H2O Kernel
12
ProActive + MOCCA• MOCCA invocations are synchronous
Composite (membrane) should be synchronous to avoid deadlocks
Or, we may consider generating glue with wrapped types (IntWrapper, etc) – this changes types of interfaces
• Class loading issues The classes generated by ProActive runtime must be visible to the
code running in H2O kernel The RMI class loading works fine if the codebase is set properly
on ProActive side
13
Application Example: Modeling of Gold Clusters
• Clusters of atoms Very interesting forms between
isolated atoms or molecules and solid state
Important for the technology of constructing nanoscale devices.
• Modeling of clusters Several energy minimization
methods such as MDSA or L-BFGS,
Choosing an empirical potential Highly compute-intensive The optimal result depends on the
number of possible iterations and initial configurations for each simulation run.
14
Case study: gold cluster simulation
• MOCCA version Master-worker with additional feedback
loop Multiple (group) connections Deployments on cluster
and on small Grid testbed getMolecule() comm.
Model Buffered ports
GCM Wrapping Glue for Go and Molecule
ports New output
generatorimplemented in ProActive
Active objects vs. Java threads
Generator Control
Starter
Simulated Annealing Gather
MoleculeMolecule
...
Molecule
Annealing Control
Outputgenerator
Molecule
Configuration Generator
Simulated Annealing
Storeroom
Simulated Annealing
Control
CCAController
C BCCCA
GoPortglue
Moleculeglue
GoPort
MoleculeProActive
OutputGenerator
15
Roadmap• Wrapping of a single CCA component as Fractal
primitive: prototype working Wrapper generation (not runtime) ADL generation
• Next step: extend the solution into framework interoperability: proof of concept working CCA controller Glue components ProActive Runtime deployed on H2O Kernel Class loading issues solved
• To do: Implementation work – make the solution usable Test on real examples Benchmarks
16
Thank you!