MOCCA - H2O-based CCA component framework for programming grids and metacomputing systems

1. Institute of Computer Science AGH, Kraków, Poland Academic Computer Centre CYFRONET-AGH, Kraków, Poland Distributed Computing Laboratory in the Dept. of Math and Computer Science, Emory University, Atlanta MOCCA - H2O-based CCA component framework for programminggrids and metacomputing systems Maciej Malawski, Marian Bubak, Michał Placek, Daniel Harężlak, Dawid Kurzyniec,Vaidy Sunderam

2. Outline • Motivation – programming grids • Component approach and CCA as a component standard • H2O resource sharing platform • Design and implementation of MOCCA • Applications and initial results • Future research – GCM interoperability

3. Problem – how to program the Grid Many programming models: MPI Service Oriented Architectures, Web Services Tuple spaces, HLA Distributed Objects Custom protocols Components ...

4. Common Component Architecture Component standard for High Performance Computing Uses and provides ports described in SIDL Support for scientific data types (complex numbers, data arrays) Existing tightly coupled (CCAFFEINE) and loosely coupled, distributed (XCAT) frameworks

5. Existing CCA Frameworks CCAFFEINE Tightly coupled Support for Babel MPI support XCAT Loosely coupled Globus-compatible Java-based DCA MPI based MxN problems SCIRun2 Metacomponent model LegionCCA Based on Legion Metacomputing system

6. Requirements for a Metacomputing-oriented CCA Framework Facilitated deployment - provide easy mechanisms for creation of components on distributed shared resources; Efficient communication - both for distributed and local components; Flexible - allow flexible configuration of components and various application scenarios; Support native components, i.e. components written in non-Java programming languages and compiled for specific architecture. Interoperable with Grid standards (Web services) Solution: H2O

7. H2O Resource sharing platform • Providers own resources • They independentlyshare them over the network • access control policies • Clients discover, locate, and utilize resources • Resources configurable via plugins • Aggregation and reselling: cascading pairwise relationships

8. H2O Component Model Nomenclature container = kernel component = pluglet Pluglet = remotely accessible object implements Pluglet interface, used by kernel to signal/trigger pluglet state changes Remote access: based on the RMI model Pluglets export functional remote interfaces Interface Pluglet { void init(RuntimeContext cxt); void start(); void stop(); void destroy(); } Pluglet Kernel tutorial/step1/srv/Hello.java public interface Hello extends Remote { String hello() throws RemoteException; } Clients Functionalinterfaces (e.g. Hello) Pluglet

9. Example scenarios of H2O Registration and Discovery e-mail,phone, ... UDDI JNDI LDAP DNS GIS ... Publish Find ... Deploy Provider A nativecode A A B A Deploy B Client Provider Client Provider B Client Provider Deploy LegacyApp Repository Repository A B A B Reseller Developer C C 1. Provider = deployer • e.g. resource = legacy application 3. Client = deployer • e.g. client runs custom distributed application on shared resources 2. Reseller:= developer = deployer • e.g. computational service offered within a grid system

10. RMIX Communication Substrate Service RMIX RMIXJRMPX RMIXXSOAP RMIXRPCX RMIX JXTA Java Web Services ONC-RPC JXTA SOAP clients • Extensible framework • Remote Method Invocations paradigm • Pluggable protocol providers • Multiple protocols supported • JRMPX, ONC-RPC, SOAP • Request-Response and Asynchronous calls • Combines simplicity, flexibility, and performance

11. RMIX: multiple protocols Protocol switching Protocol negotiation Various protocol stacks for different situations SOAP: interoperability SSL: security ARPC, custom (Myrinet, Quadrics): efficiency H2O Kernel security H2O Kernel Internet firewall efficiency H2O Kernel H2O Kernel Harness Kernel efficiency H2O Kernel

12. RMIX over JXTA • Fully operational RMI implementation running over JXTA P2P network • Methods can be invoked on remote objects located behind firewalls or NATs • Our implementation of JXTA socket factories manages all the JXTA connectivity transparently from user’s point of view

13. MOCCA Implementation in H2O • Each component running in separate pluglet • Facilitated deployment and security • Thanks to H2O kernel security mechanisms, multiple components may run without interfering • Using RMIX for communication – efficiency, multiprotocol interoperability • Flexibility and multiple scenarios – as in H2O • MOCCA_Light: pure Java implementation - need for supporting multilanguage components

14. Remote Port Call

15. How to use MOCCA(step by step) Implement component code extending CCA interfaces (cca.Port, cca.Component) Compile component classes into JAR file Publish application JARs on HTTP server Use the Java client API or write a Jython script to assemble application from components Specify components and their connections Specify locations of H2O kernels where to instantiate components Running the script automatically deploys necessary pluglets into H2O kernels and spawns application

16. Example script builder = MoccaMainBuilder() uriKernel1 = URI.create("http://emily.mathcs.emory.edu:7800/") uriKernel2 = URI.create("http://zeus10.cyf-kr.edu.pl:7800/") userBuilderID = builder.addNewBuilder(uriKernel1, "MyBuilderPlugletA") providerBuilderID = builder.addNewBuilder(uriKernel2, "MyBuilderPlugletB") properties = MoccaTypeMap() properties.putString("mocca.plugletclasspath", "http://emily.mathcs.emory.edu/mocca/mocca-samples.jar") properties.putString("mocca.builderID", userBuilderID.getSerialization()) userID = builder.createInstance("My StarterComponent", "mocca.samples.pingpong.impl.MoccaStarterComponent”, properties) properties.putString("mocca.plugletclasspath", "http://emily.mathcs.emory.edu/mocca/mocca-samples.jar") properties.putString("mocca.builderID", providerBuilderID.getSerialization()) providerID = builder.createInstance("MyPingComponent", "mocca.samples.pingpong.impl.PingPongComponent", properties) connectionID = builder.connect(userID, "PingPongUsesPort", providerID, "PingPongProvidesPort") MoccaBuilderClient.invokeGo(userID)

17. Automatic Flow Composer Example • Compose application graph from initial data (e.g. initial ports) or incomplete graph • First implemented for XCAT framework • Easy migration to MOCCA • Modification of code required (xcat.Port) • Similar performance for XCAT and MOCCA (exchange of text documents)

18. Communication Intensive Application Benchmark Simplified scenario: 2 components Provides port: receive and send-back array of double (ping-pong) Tested on local Gigabit Ethernet and on transatlantic Internet between Atlanta and Krakow 2.4 GHz Linux machines Comparison with XCAT

19. Small Data Packets Factors: SOAP header overhead in XCAT Connection pools in RMIX

20. Large Data Packets • Encoding (binary vs. base64) • CPU saturation on Gigabit LAN (serialization) • Variance caused by Java garbage collection

21. 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. Example: modeling gold clusters

22. Example – deployment

23. Integration with existing Grid middleware • A pool of computing resources may be created by submitting a number of H2O kernels on many Grid sites • Application components may be deployed on the kernels belonging to the pool

24. Multilanguage support: motivation • Grids are heterogeneous • Multiple programming languages – in single application • Java for middleware • C for system programming • FORTRAN for computing • Python for scripting • Multiple protocols – in single application • High speed local networks (Myrinet) • TCP/SSL/TLS in WAN • SOAP for loosely coupled message exchange • Overlay P2P networks for traversing private network boundaries (NATs) • Context: MOCCA component framework

25. Multilanguage Solution - Babel • SIDL – Scientific Interface Definition Language • Standard for CCA Components • Supports arrays and complex types • Focus on interfaces • Babel: • SIDL parser • Code generator • Runtime library • Intermediate ObjectRepresentation (IOR) • Core of Babel object • Array of function pointers • Generated code in C package example version 1.2 { class Hello { string hello( in string hello); } } // user defined non-static methods: /** * Method: hello[] */ public java.lang.String hello_Impl ( /*in*/ java.lang.String hello ) { // DO-NOT-DELETE splicer.begin(example.Hello.hello) // Insert-Code-Here {example.Hello.hello} (hello) return ”Server says: ” + hello; // DO-NOT-DELETE splicer.end(example.Hello.hello) } /** * Method: hello[] */ char* example_Hello_hello( /*in*/ example_Hello self, /*in*/ const char* hello);

26. Fortran native library SIDL SIDL C++ native library Currently: Babel for Local Applications • All Babel objects in one process • Implemented in CCAFFEINE framework • Existing multilanguage CCA components – see CCA tutorial Java application Babel IOR Babel IOR

27. Network SIDL C++ native library SIDL SIDL SIDL Our Solution • Babel + RMIX • Implementation of Babel RMI extensions • generic mechanism of method invocation (reflection) • Dynamic loading of communication library • No need for code generation and compilation RMIX library RMIX library Babel IOR Babel IOR Java application Fortran native library

28. Beyond CCA ? Supporting multiple component standards Goal: to enable loading of components written for different standards (e.g. Corba CCM, other) Examples of similar solutions: CCAFFEINE supports „classic” and „Babel” components; SCIRun2 implementing meta-component model Using MOCCA as promising platform for feasibility studies in various aspects of Grid components For experiments with advanced features Scheduling and load-balancing Fault-tolerance Semantic description and composition As a platform for higher-level grid services and tools

29. Fractal/GCM – CCA Interoperability? • CCA as Fractal • Adapter calls setServices() on a component • Component registers ports on the adapter • Component is ready for introspection and connection • Fractal as CCA • CCA framework creates component, adapter and invokes setServices() • Adapter introspects the component and registers interfaces to the framework • Adapter obtains references to external interfaces (getPort()) and binds them to the component

30. References Maciej Malawski, Dawid Kurzyniec, and Vaidy Sunderam. MOCCA – towards a distributed CCA framework for metacomputing, Accepted for: 10th International Workshop on High-Level Parallel Programming Models and Supportive Environments (HIPS2005) at IPDPS’2005 http://mathcs.emory.edu/dcl/h2o/papers/h2o_hips05.pdf H2O Project homepage: http://www.mathcs.emory.edu/dcl/h2o/ CCA Forum: http://www.cca-forum.org CCA Specification Tutorial MOCCA homepage: http://www.icsr.agh.edu.pl/mambo/mocca Download binary and source distribution README