1. OGSA-WG Session #2 Program Execution Services GGF10 Berlin March. 10, 2004 3:30-5pm Senate Hall

2. OGSA-WG Program Execution Services2 GGF Intellectual Property Policy All statements related to the activities of the GGF and addressed to the GGF are subject to all provisions of Section 17 of GFD-C.1 (.pdf), which grants to the GGF and its participants certain licenses and rights in such statements. Such statements include verbal statements in GGF meetings, as well as written and electronic communications made at any time or place, which are addressed to any GGF working group or portion thereof, Where the GFSG knows of rights, or claimed rights, the GGF secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the GFSG of the relevant GGF document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The working group or research group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the GGF secretariat in this effort. The results of this procedure shall not affect advancement of document, except that the GFSG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the GGF Secretariat, and made available. The GFSG may also direct that a summary of the results be included in any GFD published containing the specification.

3. OGSA-WG Program Execution Services3 Session Agenda Architecture for program execution related services High level naming service: WS-naming –Andrew Grimshaw, AD, University of Virginia

4. OGSA-WG Program Execution Services4 NB We use the terms OGSI, GSH, GSR, etc. below. For the next release will update these to the appropriate WS-RF terms.

5. OGSA-WG Program Execution Services5 GGF10 Sessions SessionDate/Time Room Organizer Program ExecutionMar. 10 Wed 3:30-5pm Senate Hall Andrew Grimshaw Ravi Subramaniam Data Information Mar. 11 Thu 10:30am-noon Audimax Jay Unger Hiro Kishimoto ManagementMar. 11 Thu 2-3:30pm Audimax Hiro Kishimoto Fred Maciel OGSA logging system WG - BoF Mar. 12 Fri 2-3:30pm 3092 Bill Horn

6. OGSA-WG Program Execution Services6 Overview Basic problem: provision and execute services (including legacy applications) in a grid –Use cases start up a service on-demand, utility computing start up and manage a set of legacy applications Want to be able to “start” a service and have the grid figure it out, and provide management interfaces throughout the lifetime of the service

7. OGSA-WG Program Execution Services7 Three basic phases Discover resources and schedule Enact the schedule – and all that is involved Monitor the job through its lifetime(s)

8. OGSA-WG Program Execution Services8 Service Definitions Containers Vaults Job’s (& job wrapper) Job managers Execution Planning Services Candidate set generators Provisioning services Info services Logging Monitoring

9. OGSA-WG Program Execution Services9 Resources Resource –Container J2EE Executable (Unix, Windows) BatchQ (LSF, PBS, SGE, Condor,..) … –Vault File system RDBMS –OS

10. OGSA-WG Program Execution Services10 Resource relationships Resources have relationships with one another …. –container “A” can see vault “A” Composite resources may be formed, e.g., container A, vault A, and OS 9.

11. OGSA-WG Program Execution Services11 Service Definitions Container “is_a” resource A container “contains” running services, e.g., a queuing service, a Unix host, a J2EE hosting environment, or a collection of containers (a façade or a VO of containers). Containers will have attributes (a.k.a. SDE’s) that describe both static information such as what kind of executables they can take, e.g., OS version, libraries installed, policies in place, security environment/QOS, etc., as well as dynamic information such as load, QOS issues, etc. A container also establishes a “context”. Definition of “context” in this context means agreement, security, I/O environment contexts. Porttypes: start, kill, signal, checkpoint, deploy

12. OGSA-WG Program Execution Services12 Vault “is_a” resource A vault represents a container for persistent state. It may be implemented many different ways, by a file system, by database, by a hierarchical storage system, etc. A vault is a subclass of a resource, and therefore has a manageability interface. Similarly, like a “container”, it has relationships to other resources. A vault will have methods to get a “handle” to persistent state that it is managing. (Called a “persistent address”) The form of the handle will depend how the state is actually stored. A persistent address may be a path name in a file system or a primary key value in a database. The key idea is that the persistent address can be used to directly access the data. Vaults will also have methods for managing their contained state, including passing it to other vaults. This will facilitate both migration and replication. Another way to think about it, it is a meta-data repository that tells you how to get to the data really fast using native mechanism, e.g., a mount point, a db key, a path.

13. OGSA-WG Program Execution Services13 Job A job is a grid service (named by a distinct GSH) and is created at the instant requested … even though no resources have been committed. The job does not necessarily “run” on/in the container where the actual “job” is run, whether the “job” is a legacy or not. A job encapsulates a job document. A job is not a workflow. A job may be instantiated by a job factory. A job goes through distinct states, started, suspended, restarted, terminated, completed, etc. These states are kept in the job document (described below). Jobs will have a manageability interface that will include functions such as start, stop, migrate, limit resource consumption, check resource consumption, etc. It is envisioned that the job type will be sub-classed into many different subclasses. For example, we envision a “legacy_job” subclass that has methods such as redirect TTY IO, reading and writing of local files, capturing a checkpoint, etc.

14. OGSA-WG Program Execution Services14 Job Document A job document describes the state of the job, e.g., the agreements that have been acquired, the JSDL, how many times it has been started. By state we do not mean for example the internal memory of a BLAST job. The job document is encapsulated by a job and exposed as service data of the job. The logical view is of one large document that consists of possibly many subdocuments, such as the JSDL, agreements, etc.. These subdocuments can be retrieved independently. The organization of the sub-documents may be subject to further specification.

15. OGSA-WG Program Execution Services15 Job Manager The manager manages jobs. For example it may be a workflow manager, it may be an array job, it may be a portal that interacts with users. It may deal with failures and restarts, it may schedule them to resources, it may collect agreements and reservations. It is responsible for making the job – or set of jobs. It is very likely to be a subtype of the WSDM collection, which is a collection of manageable entities. A WSDM collection can expose as its methods some of the methods exposed by the members of its collection. There may be a stop, kill, etc. The manager is responsible for orchestrating the set of services to start a job or set of jobs, e.g., negotiating agreements, interacting with containers, monitoring and logging services, etc. It may also aggregate job service data from underlying “related” job instances.

16. OGSA-WG Program Execution Services16 Job Manager Port-types Port-types instantiate a job instantiate a set of jobs destroy a job reschedule (migrate) a job or set of job list set of jobs – via service group (bag) Negotiate new agreements

17. OGSA-WG Program Execution Services17 Execution Planning Service A service that builds a temporal relationships jobs and resources, e.g., containers and vaults. Definition: A schedule is a mapping (relation) between grid services and resources, with possibly, time constraints. (Do we include precedence relationships?) A schedule can be extended with a list of alternative “schedule delta’s” that basically say, if this part of the schedule fails, try this one instead”. It is likely that the input document will be some sort of JSDL document. There may be many types of schedulers. FIFO, economic-based, priority, or right now.

18. OGSA-WG Program Execution Services18 Candidate container set generator Constructs a set of containers (really their GSH’s) where it is possible to run a service named by a GSH. There may be a default information service. Inputs: –A set of GSH’s (e.g., for job services) –optional : the GSH of a information service –optional: a static set of resources passed in. Output: –A set of lists –The lists are unordered, there is no implied preference or ordering.

19. OGSA-WG Program Execution Services19 Information services A discovery service is an example. The basic idea is that an information service is a place where one can find information about resources. Similar to MDAS services and collections. We have not specified this any further.

20. OGSA-WG Program Execution Services20 Deployment & Configuration Is able to deliver appropriate, compatible, “executables” for particular named services for particular named containers. This will be used primarily by services such as the job manager, possibly job container services. We need such a service – we are not planning on defining it in this subsection. We are working with CDDLM on this.

21. OGSA-WG Program Execution Services21 Reservation Services Reservation services manage reservations for resources, interact with accounting services (there may be a charge for making a reservation), revoke reservations, etc. This may not be a separate service, rather an interface to get and manage reservations from containers and other resources. The reservation itself is likely to be a document that is signed.

22. OGSA-WG Program Execution Services22 Other services Monitoring, fault-detection & recovery Logging – auditing, accounting, etc. License management Naming

23. OGSA-WG Program Execution Services23 Current thinking … Provisioning Deployment Configuration App. Class Manager Information Services Container Storage Local services Accounting Services Execution Planning Services Candidate Set Generator (Work - Resource mapping) Job Manager Workflow manager Caching Services Directory and Naming Services External management, Queues etc Reservation Other Services:

24. OGSA-WG Program Execution Services24 Job? Job Container Job Wrappe r Job Manager Monitoring Services Logging Services

25. OGSA-WG Program Execution Services25 Example 1 – Run a BLAST job Job manager either already exists (e.g., it is a portal) or is instantiated – or receives request from external load generator Job is instantiated – note that it is not necessarily in a “running” state JSDL and other doc’s (e.g., credentials) sent to scheduling service Scheduler interacts with candidate service set generator (CSG) to find out the set of places (resources) where the job can run CSG interacts with info services, returns the candidate set with no ordering

26. OGSA-WG Program Execution Services26 Example 1 - continued Scheduler receives candidate set, makes a placement decision – or perhaps a list of placements. May require further interaction with info services, reservation services, containers, vaults, etc. Returns placement(s) to job manager Job manager may require interaction with resources (e.g., containers) and provisioning services Job manager performs any staging required, e.g., data files, binaries (with provisioning services), sets up accounting information, etc. Job manager “starts” job in container, may set up a monitor to monitor the job, set up logging services, etc. (note, container may perform monitoring function as well)

27. OGSA-WG Program Execution Services27 When job completes, manager may handle clean-up, e.g., moving data around, updating accounting, logging, etc., may start next job (e.g. array jobs, or workflow) If job fails, may restart (go through whole processes), use alternate schedule, or return error

28. OGSA-WG Program Execution Services28 On demand May be same as above – but using different candidate set generator and/or scheduler

29. OGSA-WG Program Execution Services29