HOCs: Higher-Order Components for Grids Jan Dnnweber (with Martin - - PowerPoint PPT Presentation

HOCs: Higher-Order Components for Grids

Jan Dünnweber (with Martin Alt, Jens Müller and Sergei Gorlatch) University of Münster, Germany

1

FROM HPC PROGRAMMING TO GRID PROGRAMMING

➜ Low-level programming model remains a challenge in the HPC world (e.g., MPI with explicit send-recv) ➜ Difficult to manage large numbers of processors ➜ Grids connect several HPC systems together, thereby making the task of application programmers even more challenging ➜ Grid-specific tasks are added:

• heterogeneous processing nodes
• heterogeneous, dynamic interconnects

➜ Grid middleware deals with these tasks:

• Grid Services extend Web Services to become

stateful and transient

• Web Services allow for remote procedure calls via the

Internet (passing proxies and firewalls), using SOAP via HTTP

FROM HPC PROGRAMMING TO GRID PROGRAMMING 2

PROGRAMMING GRIDS WITH MODERN MIDDLEWARE

• ✁

deliver Result request Service Client Application Grid Servers

S O A P / H T T P

provide Service create create create hosted by

Service Factory Grid Service Instance Grid Service Instance Grid Service Instance

Grid Middleware

➜ Middleware should take care of resources ➜ What should the programmer take care of?

PROGRAMMING GRIDS WITH MODERN MIDDLEWARE 3

EXAMPLE: PROGRAMMER’S TASKS IN GLOBUS

• writing GWSDL interface definitions
• writing service implementations (OGSI in GT 3)
• writing GWSDD deployment configuration
• packaging Grid Application Archive (GAR)
• deploying the services remotely

CODE GT 3 GWSDL CODE GWSDD

OGSA GT 3 GAR GSDD OGSI GWSDL WSRF Grid Application Deployment Descriptor Interfaces Globus Implementation Archive Service Developer

GAR

EXAMPLE: PROGRAMMER’S TASKS IN GLOBUS 4

AN EXAMPLE GWSDL-INTERFACE DEFINITION

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="MasterService" targetNamespace="http://org.gridhocs/Master" xmlns:gwsdl="http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions" ... <!-- more namespace declarations

• ->

xmlns="http://schemas.xmlsoap.org/wsdl/"> <wsdl:import location="schema/ogsi/ogsi.gwsdl" namespace="http://www.gridforum.org/namespaces/2003/03/OGSI"/> <wsdl:types> <schema targetNamespace="http://org.gridhocs/Master" xmlns="http://www.w3.org/2001/XML <import namespace="http://schemas.xmlsoap.org/soap/encoding/"/> <complexType name="ArrayOf_xsd_double"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:double[]"/> </restriction> </complexContent> </complexType> ... <!-- more parameter type declarations

• ->

</element> </schema> </wsdl:types> <wsdl:message name="configureRequest"> <wsdl:part name="in0" type="impl:ArrayOf_xsd_string"/> </wsdl:message> <wsdl:message name="configureResponse"> <part name="parameters" element="impl:void"/> </wsdl:message> <!-- more message declarations

• ->

<gwsdl:portType name="MasterPortType" extends="ogsi:GridService ogsi:NotificationSink"> <wsdl:operation name="configure" parameterOrder="in0"> <wsdl:input message="impl:configureRequest"/> <wsdl:output message="impl:configureResponse"/> <fault name="Fault" message="ogsi:FaultMessage"/> </wsdl:operation> ... <!-- more operation declarations

• ->

</gwsdl:portType> </wsdl:definitions>

AN EXAMPLE GWSDL-INTERFACE DEFINITION 5

IDEA: GRID PROGRAMMING WITH COMPONENTS

➜ Select and parameterize suitable components with distributed implementation in form of Grid Services ➜ Express application by composing components Note: Program’s parameters are programs ⇒ higher-order

Java

Application Developer

write select

an image processing farm e.g., worker parameter for application specific code,

Divide Map & Conquer Scan HOC Farm HOC HOC HOC

Component Repository

HOC Pipeline

mobile code parameter

Grid Expert

IDEA: GRID PROGRAMMING WITH COMPONENTS 6

GRID PROGRAMMING USING COMPONENTS

➜ Components are developed by Grid experts capable of writing efficient parallel code for the target machines ➜ The component repository is packaged with neccesary confi- guration files (WSDL, WSDD) in a GAR file deployed remotely

stored in contains: GWSDL, GT3−Code, GWSDD

Application Developer

Component Repository

Map HOC Farm HOC Pipeline HOC Scan HOC & Conquer Divide HOC

mobile code parameter

Java

write select provides Grid Expert

GAR

GRID PROGRAMMING USING COMPONENTS 7

GRID PROGRAMMING USING COMPONENTS

➜ For e.g., Farm applications the application programmer only needs to provide two parameters: application specific code for the master and the workers ➜ A distributed evaluator implementation in the form of Grid Services incl. all needed configuration files will be provided by the component developer.

? ?

• ✁

GWSDL CODE GWSDD GT 3 CODE

Parameter Worker Parameter Master Service Interfaces Descriptor Deployment Farm−Service Implementation Developer Application Expert Grid

GRID PROGRAMMING USING COMPONENTS 8

AN EXAMPLE: FARM-HOC EVALUATION

➀ client obtains Farm Service instance, ➁ Farm service

• btains worker services ➂, distributes calculations ➃ and

resassembles result ➄

Worker Factory Worker Factory

3 3 4 4 4 5

2) Worker Service 2) Worker Service 2) Worker Service 2) Worker Service client

... ...

create

...

create create

1) Farm Service Factory Farm−HOC Farm−HOC

1 2

AN EXAMPLE: FARM-HOC EVALUATION 9

HOCS: HIGHER-ORDER COMPONENTS FOR GRIDS

➜ Servers provide architecture-tuned implementations of composable and reusable components e.g., Farms, Pipes, ... ➜ Clients access components via common remote interfaces e. g. the FarmHOC: public interface FarmHOC { public void setMaster(Master m); public void setWorker(Worker w); public void configureGrid(String[] availableServers); public double[] compute(double[] input); } ➜ known HOC interface (e.g. FarmHOC) is implemented hardware-specific in server-side HOC-library

HOCS: HIGHER-ORDER COMPONENTS FOR GRIDS 10

PARAMETERS FOR HOCS: MOBILE CODE UNITS

➜ Code parameters are hardware-independent, application-specific, and implement interfaces like e.g., public interface Worker { public double[] compute(double[] input); } public interface Master { public double[][] split(double[] input, int numWorkers); public double[] join(double[][] input); }

PARAMETERS FOR HOCS: MOBILE CODE UNITS 11

SOLUTION: THE HOC CODE BASE

We introduce Code Mobility Mechanisms to the OGSA by providing two extensions:

➜ The HOC Code base, an OGSA-compliant Grid Service, that allows for the upload and download of code in the form of primitive byte data. ➜ An HOC Remote Class Loader, that replaces the default class loader and connects to the Code Base when needed.

client Farm HOC Service CodeBase

store("WorkerID", ...) farm("WorkerID",...)

Remote Class Loader

retrieve("WorkerID")

SOLUTION: THE HOC CODE BASE 12

GRID APPLICATION PROGRAMMING USING HOCS

Programming Grid Applications with HOCs can now be

• utlined as follows:

Service CodeBase B B HOC2

Client

instantiation HOC1

• f HOC1

HOC2 HOC3 Grid hosts HOC repository

Server Y Server X

HOC repository

Remote Class Loader

Server Z 2 1 4 3

local code code for A code for B HOC1( ) ... ... A,B B A

B C A

A A A A B C A B C C D

GRID APPLICATION PROGRAMMING USING HOCS 13

CASE STUDY: COMPUTING JULIA SETS WITH THE FARMHOC

• calculating fractal images is a compute intensive task
• procedure can be applied to multiple independent tiles
• straightforward parallelization possible
• dynamic process has varying time costs
• ✁

CASE STUDY: COMPUTING JULIA SETS WITH THE FARMHOC 14

WHAT NEEDS TO BE DONE

➜ Programmer only provides a simple implementation of the Fractal Generator as follows: public class FractalWorker implements Worker { public Object compute(Object tile) { for (int y = 0; y < tileHeight; ++y) { for (int x = 0; x < tileWidth; ++x) { ... // compute julia value for (x, y) } }}} ➜ automatic load-balancing is achieved by running multiple threads for a single tile, taken from a pre-configured pool. ➜ invocation is done as follows

WHAT NEEDS TO BE DONE 15

INVOCATION OF A HOC

farmHOC = farmHOCFactory.createHOC( ); farmHOC.setMaster("masterID"); farmHOC.setWorker("workerID"); farmHOC.configureGrid( "masterHost", "workerHost1",... , "workerHostN" ); farmHOC.compute(input);

➜ request HOC instance from factory ➜ select code parameters ➜ pick the servers ➜ start remote processing

INVOCATION OF A HOC 16

MEASURED EXECUTION TIMES

for all experiments the distance between the server running the master code unit and the servers running the workers was

• ca. 500 kilometers

1 remote server 2 remote servers 3 remote servers 4 processors 4 + 8 processors 4 + 8 + 12 processors 198,212 sec 128,165 sec 48,377 sec Interesting results:

• sequential time for a local evaluation was more than 1000

seconds (more then five times higher than using a remote server with 4 processors)

• transferring the result via SOAP takes much time (about 60 sec),

due to the complexity of the SOAP encoding.

MEASURED EXECUTION TIMES 17

FUTURE WORK

➜ setting up a HOC Service Architecture (HOC-SA) covering much more than simple data-parallel computations (Pipes, Divide & Conquer, ...) ➜ integrating a Lookup Service and a faster Transfer Service for result data (e.g., using GridFTP via COGs or WS-Attachments) ➜ enhancing the Code Service to maintain mobile code units persistently in multiple databases (using the UK-OGSA-DAI) ➜ setting up a user friendly portal to access the HOC-SA via a standard Web-Browser ➜ allowing for other code parameter formats than Java Bytecode (e.g., native code attached to requirement descriptors).

FUTURE WORK 18