1. Grid Resources for Industrial Applications Steve Taylor IT Innovation Centre 19 October 2004

2. Introduction GRIA is an infrastructure providing business process management of computational resources Aimed at business users –e.g. HPC providers, SME clients GRIA enables: –HPC providers to rent out their spare CPU cycles –Clients to outsource HPC application codes Application focused –HPC providers connect GRIA to application codes & advertise this as a service

3. Functionality and Positioning GRIA = A Grid for Today –secure "off the shelf" Web Services technology –supports well-defined B2B processes –designed to support today’s legacy applications –available immediately Key features –file storage and processing infrastructure –accounting: billing and billability (trust) –QoS: managing service load

4. Business Process Overview

5. Business Model Features Hierarchical business model Contractual terms are agreed per account –the relationship between the client and service provider –no need to re-specify for each job Users can request multi-job, long term Resource Allocations within an account Jobs and data storage are set up within the context of a resource allocation –all users need to do is run the job

6. Business Model Features Jobs and Data are handled by separate services –data may be uploaded to a data stager, and used in a different jobs Delegation is used extensively –account holders can delegate access to the account –resource allocation owners can delegate access to the allocation –data stager owners can delegate access to that data stager

7. GRIA Business Process Account(Trust)Service App requirements CC Number Account Ref (ContextID)

8. GRIA Business Process Account(Trust)Service Trust(AccountRef, User Credentials) User Credentials) ConfirmUser User Credentials

9. GRIA Business Process Account(Trust)Service InitResourceAlloc(ResourceService,AccountRef) ResourceRef(ContextID) ResourceAllocationService GetAlloc(ResourceRef,Requirements) Allocation Offer

10. GRIA Business Process ResourceAllocationService InitJob(JobService,ResourceRef) JobRef(ContextID) JobService StartJob(JobRef, InputRef, OutputRef) Acknowedgement

11. GRIA Business Process JobService Check(JobRef) Status DataService Read(OutputRef) Data

12. DataService AllowRead(DataRef,CustomerCredential) ConfirmUser Read(DataRef) Data Customer Credentials

13. GRIA Business Process Account(Trust)Service Statement Check(AccountRef) out of band settlement (payment logging)

14. Accounting Model An account is given a credit limit & incurs liability –liability must always be less than credit limit! Credit limit determined when account is opened Liability is increased when a resource allocation is confirmed –the financial cost of the entire resource allocation Liability is reduced by payments

15. Account Service Provides a means for clients to open & maintain accounts –request opening of account –get statements –close accounts Financial operations handled out of band –payments, credit checks, etc –internal operations to log payments, update liability, etc

16. Resource Allocation Service Used within the context of an account User can request a resource allocation –service responds with an offer or a failure User may accept or reject an offer –acceptance transforms the offer into an allocation –rejection removes the pending offer User may initialise job and data services in an allocation User may request an extension to an existing allocation –e.g. time, disk space

17. Job Service Used within the context of a resource allocation Used to run computational jobs –retrieve input (subject to authorisation) –submit job to resource manager –monitor job –write output (subject to authorisation) All inputs and outputs are URIs & context IDs of data stagers

18. Data Service Used within the context of a resource allocation Manages data staging areas –each data staging area is identified by URI of data service and context ID Users can upload and download data and check the status of a staging area Users can delegate access to others (e.g. remote job services or other users) for access to the data in the staging area

19. High Level Architecture Secure –X.509 compliant public key encryption –Certification policy for user authentication –Services accessed via Apache HTTP server and Mod_SSL: popular and well-patched Modular –Distinct roles for software modules –Code reuse with other projects –GRIA v2 a distribution of modules, some from outside GRIA

20. Client Architecture

21. Service Provider Architecture

22. Client Installation

23. Service Provider Installation

24. Status and Future Plans GRIA project status –project duration: 12/2001 – 11/2004 –GRIA v3 software currently being evaluated by partners GRIA used & further developed in ongoing research GRIA v3 will be released open source under LGPL –freely available – griasupport@it-innovation.soton.ac.uk –commercial software support/customisation from IT Innovation –selected application services from Dolphin

25. griasupport@it-innovation.soton.ac.uk http://www.gria.org Steve Taylor IT Innovation Centre 19 October 2004