Task Management Service

Transcription

1 UMEÅ UNIVERSITY Department of Author:,

2 Contents 1 Abstract 1 2 About this document 1 3 Introduction 2 4 Overview 2 5 Use cases The TMS point of view The users / clients point of view Architecture TMS Customization API Interface Web Service Interface WSRF Resource Properties Client API Interface Configuration 9 9 Using the TMS Deployment Reference clients Security Appendix Customization point Java interfaces Client API interfaces Sample configuration file

3 1 Abstract The (TMS) is a grid service intended to function as a robust and autonomous high-level grid job execution tool. Jobs are specified as abstract task definitions in the XML-based Job Specification Description Language (JSDL) [1]. The TMS is primarily intended to be used by the Task Group Management Service (TGMS) [10], which offers similar functionality for groups of tasks (i.e. compiled batches), but also offers an easy-to-use Java client API for end users. The TMS is an integral part of the Grid Job Management Framework (GJMF) [8] and also includes a set of customization point interfaces to facilitate customization and adaptation. 2 About this document The aim of this document is to outline the rationales underlying the design of the (TMS) and at the same time provide a design overview. The intended audience of this document (grid service developers familiar with the Globus Toolkit [6] platform and / or other grid environments) will find it useful as a first introduction to the TMS. The TMS is developed by - the Grid Infrastructure Research & Development [3] project of the department of computing science at Umeå University, Sweden. 1 TMS

4 3 Introduction The design of the TMS is focused around the intended usage scenario where a client wishes to submit a job without having to monitor progress or manually resubmit the job upon failures etc - i.e. so called fire-and-forget job submission. The TMS is designed to try to resubmit and handle the most obvious, foreseeable errors that may arise in job submission. In this scenario, a user of such a client software is assumed to be primarily interested in ease of use and result statistics rather than continuous fine grained job control when selecting a grid job submission tool. The purpose of the TMS is to provide a simple fire-andforget type of tool which automatically handles tasks such as resubmissions and compilation of logs and execution statistics. Jobs are submitted to the service as abstract task definitions expressed in JSDL [1]. The TMS functions as a higher-level job submission tool which utilizes the Brokering and Submission Service (BSS) [7] for job submission and relies on the Job Control Service (JCS) [4] for gathering of individual job information. Although not required for job submission, logs and more detailed execution information can be retrieved from the Log Accessor Service (LAS) [9]. These abstractions isolates the TMS from the underlying middleware(s) and delegates platform specific behavior to the previously mentioned services. The TMS also employs a WS Notification [2] scheme to allow the prospective client to subscribe to notifications for change in task state, statistics or resulting job instances. 4 Overview The is intended to be deployed in an infrastructure made up by a set of services handling all aspects of job submission and monitoring - the Grid Job Management Framework (GJMF) [8]. The Task Management Service resides in the center of this system and relies on the Brokering and Submission Service (BSS) [7] to submit jobs. The BSS in turn employs the Resource Selection Service (RSS) and the Job Control Service (JCS) [4] to gather information and submit / control jobs respectively. In this infrastructure, the TMS is in turn used by the Task Group Management Service (TGMS) [10] to form a robust task executer. Naturally, the TMS can also be used directly by the end user or other services. From this perspective, the JCS thus constitutes an abstraction layer to the underlying middlewares and shields the other services from much of the platform specific issues found in these middlewares, allowing for a simpler implementation of these higher abstraction layers. The TGMS and TMS make up the natural entry-points to the GJMF system from the end-users perspective, both offering similar functionality for task groups and tasks, respectively. For more information about the GJMF and the interaction between the services in it, see [8]. 2 TMS

5 5 Use cases The TMS is designed to be an autonomous and robust job submission and management service. The intention is to provide a fire-and-forget solution for batch schedulers, individual users, workflow job submission services, grid portals or other types of client software. For more information about the terminology, use cases and state models of the GJMF, see [8]. 5.1 The TMS point of view From the TMS point of view, a representative usage scenario between the services is 1 A task is submitted to the TMS. 2 The TMS adds the task to an internal queue. 3 The TMS continuously traverses its task queue and submits the tasks one by one to the BSS. Submission and execution failures are handled by resubmitting the task (up to a maximum number of times). 4 The BSS processes the jobs as described in [8]. Naturally, the TMS also keeps clients informed of its progress via notifications. 5.2 The users / clients point of view From the users / clients point of view, a representative usage scenario is 1 Input data files are staged into the grid. 2 A task is specified and submitted to the TMS. 3 Notifications about state changes are received, logs and statistics are retrieved (logs from the LAS). 4 Upon task completions, output data is retrieved from the grid. 5 The task is removed from the TMS (either explicitly or when the task has been inactive (i.e. reached a terminal state) for a specified period of time). 3 TMS

6 6 Architecture 6.1 TMS Internally the TMS consists of the following main components: TaskManagementService The service implementation, functions as a web service front-end interface to the TaskManager. Note that the TaskManagementService provides only the submit and list methods, which are directly mapped to the corresponding methods in TaskManager. This class functions as a wrapper around the (factory) web service interface and translates the stub classes to the internally used types. TaskManager The actual implementation of the TMS. The TaskManager contains a task queue and provides the service methods submit and list - the only operations in the TMS which do not operate directly on task resources. Note that via a factory design pattern implementation a separate TaskManager is provided to each user. TaskPool Regulates submitter access to, and maintains internal states of active tasks. With the help of the TaskPrioritizer plug-in, TaskPool serves the job submitter with unprocessed tasks (upon request). TaskQueue The TaskQueue is as the name implies the internal component responsible for maintaining the list of non-processed tasks in the TMS. Its main purpose is to maintain the state machine for the tasks and therefor also acts as the main listener of all active job instances. Internally, the TaskQueue contains a task pool, a job submitter and a job submission thread. The latter processes all tasks in the task pool by sequentially submitting them to a BSS via the job submitter. TaskQueue also harbors the customization points for the TMS; the TaskPrioritizer, CongestionHandler, FailureHandler and the StateTransitionMonitor. TaskResource The task WSRF resource, exposes resource properties for the public parts of a task and handles notifications and subscriptions. TaskResource contains the actual task description, the current state of the task, a brief summary of the task run statistics to date (which contains references to resulting job instances), the credentials proxy used to execute the tasks and also handles all state and log updates to the LAS. TaskResource.Home The WSRF resource home implementation, provides (additional to the standard resource home functionality) an list of references to all task resources in the TMS. Creates and initializes task resources. 4 TMS

7 JobSubmitter JobSubmitter is the TMS link to the BSS and JCS, it is embedded in the TaskQueue and wraps the logic of accessing the other services. It also contains a thread for polling inactive job instances from the JCS (which feeds updated states to the TaskQueue as (simulated) job instance state notifications). 6.2 Customization As mentioned above, the TMS provides four customization points for behavior modification plug-ins. These customization points are provided in the form of regular Java interfaces. To insert a customized plug-in a user implements the interface, provides the implementation (in the system class path) to the container and specifies where to find the implementation in the TMS configuration file (primary, see section configuration and deployment for details) or by setting a matching system property (secondary). The customization point interfaces provided are (the actual Java interfaces are included in the appendix of this document) CongestionHandler The congestion handler is a decision interface that allows for implementation of a back-off behavior for job submission congestion situations. More specifically, it provides a way to specify how long the TMS should wait before attempting resubmission after a job submission has failed. A default implementation is provided which provides an incremental back-off, in the resolutions of minutes (up to a maximum of 30 minutes). FailureHandler The failure handler plug-in is a decision interface that determines the level of persistence in resubmissions of failed tasks. Put in other words, the failure handler plug-in provides a way to customize how the TMS responds to situations where job submissions and / or job executions fail. A default implementation is provided which allows for the specification of a maximum number of submission and execution attempts. The default implementation enforces a maximum of 3 submission attempts and 5 execution attempts. TaskPrioritization The task prioritization interface provides a way to customize how individual tasks are ordered in the task queue. A default implementation provides a random selection (i.e. all idle tasks are equally likely to be submitted). StateTransitionMonitor The state transition monitor plug-in provides a monitor interface which allows for convenient monitoring of task state transitions. 5 TMS

8 6.3 API The TMS provides a pure Java client API, which allows software developers with limited experience of web services and / or the Globus Toolkit to use and develop for the TMS without having to be confronted with many of the implementation specific details of Globus Toolkit programming. A direct mapping of all methods in the service interface is provided and the full functionality of the TMS is accessible through the Java API. Note that if the flag uselocalcalls is provided to the client API class it will assume to be in the same process space (i.e. executing within a service hosted in the same container) as the TMS and attempt to use the TaskManager directly instead of going through the web service interface. 6 TMS

9 7 Interface In the TMS, each task resource exposes a WSRF [5] resource with properties representing job specification, task state, current statistics and the resulting job instances for the task. In addition to these (read-only) properties, a web service interface containing operations to submit and list methods is included. The Client API offers all of these functionalities in the form of Java interfaces. 7.1 Web Service Interface This section outlines the web service interface exposed by the TMS in broad strokes. This interface is sometimes referred to as the factory interface of the TMS. Submit Submits a (precompiled) task to the TMS. The task will enter active mode and begin submitting jobs to the BSS immediately if possible. List Lists all tasks in the TMS owned by the current user. 7.2 WSRF Resource Properties In addition to the web service operations, a WSRF Resource exposing four types of (read only) properties is also available for each task: Task The original task specification. State The current task state. Note that this property also exposes a subscribable notification topic. Statistics The current task run statistics. Note that this property also exposes a subscribable notification topic. JobInstances A list of the job instances which the job has resulted in. Note that this property also exposes a subscribable notification topic. 7 TMS

10 7.3 Client API Interface This section outlines the Java interfaces exposed by the TMS Client API in broad strokes. As the client API provides the same functionality as the web service interface and the resource properties, users are free to use either as they see fit. Submit Submits a (precompiled) task to the TMS. The task will enter active mode and begin submitting jobs to the BSS immediately if possible. List Lists all tasks in the TMS owned by the current user. GetTask Returns the original job specification of a task GetTaskState Retrieves current state for specified task. GetTaskStatistics Retrieves current progress statistics for specified task. GetInstanceEPRs Returns a list of end point references to the WSRF resources of the job instances associated with the specified task (or an empty list if there are none). Destroy Destroys the task resource and thereby removes the specified task from the TMS. Any currently active tasks are aborted and all associated job instances in Job Control Services are also destroyed. 8 TMS

11 8 Configuration The TMS can be configured through the TMS configuration file etc/tms-configuration.xml This file is simply an XML document where the listed tags are used for TMS configuration. For URLs, the entire URL must be specified and for classes, the full class name (including package) must be specified- (see example configuration file in appendix for format) BrokeringAndSubmissionService (optional, 0 - n tags allowed) Specifies URL to the Brokering and Submission Service(s) to use If more than one BSS is specified, the TMS will attempt to use all of them. If no BSS is specified, the TMS will attempt to use a local one (i.e. one hosted in the same container as the TMS). LogAccessorService (optional, 0 - n tags allowed) Specifies URL to the Log Accessor Service(s) to use. If more than one LAS is specified, the TMS will attempt to use all of them. If no LAS is specified, the TMS will attempt to use a local one (i.e. one hosted in the same container as the TMS). CongestionHandler (optional, 0-1 tags allowed) Specifies an implementation of the congestion handler plug-in interface FailureHandler (optional, 0-1 tags allowed) Specifies an implementation of the failure handler plug-in interface TaskPrioritizer (optional, 0-1 tags allowed) Specifies an implementation of the task prioritizer plug-in interface StateTransitionMonitor (optional, 0-1 tags allowed) Specifies an implementation of the state transition monitor plug-in interface It is also possible to specify plug-in classes for the TMS through system properties matching the names of the configuration file tags above. Note though, that if both are present the configuration file will always take precedence over any system properties. A complete example configuration file is provided in the appendix of this document. 9 TMS

12 9 Using the TMS 9.1 Deployment The TMS requires a Brokering and Submission Service and a Job Control Service to be deployed and running in order to operate. These do not need to be located in the same container as the TMS, but if they are the TMS attempts to make local calls (bypassing the actual service interface) to improve performance. 9.2 Reference clients A few simplistic reference implementations of clients using the TMS is provided with the TMS. These all use the Java client API provided, which is the recommended way of developing using the TMS. Users of other programming environments are naturally able to use the web service interface directly and should be able to use these client implementations as examples of intended use if nothing else. 9.3 Security The TMS allows for three modes of security to be used - secure conversation, message security and transport layer security. By design, the TMS only allows the owner of a task access to the task, this includes access to the WSRF resource properties that are published by the service. 10 TMS

13 10 Appendix 10.1 Customization point Java interfaces public interface FailureHandler { public enum Action {ABORT, RESCHEDULE}; } public Action getsubmissionfailureaction (Task task); public Action getexecutionfailureaction (Task task); public void remove (Task task); public interface CongestionHandler { public void setcongestionstatus (boolean congestion); public long getdelay (); } public interface TaskPrioritizer { public Task select (Task[] tasks); } public interface StateTransitionMonitor { public void statechanged (Task task, TaskState state); } 11 TMS

14 10.2 Client API interfaces public interface TaskManagementFactoryService { public TaskManagementService submit (Task task, SubscriptionRequest subscription) throws ConnectException, ProxyException, CongestionException, FailureException; } public EPR[] list () throws ConnectException, ProxyException, FailureException; public interface TaskManagementService { public Id getid (); public EPR getepr (); public Task gettask () throws ConnectException, ProxyException, FailureException; public TaskState getstate () throws ConnectException, ProxyException, FailureException; public TaskStatistics getstatistics () throws ConnectException, ProxyException, FailureException; public EPR[] getinstanceeprs () throws ConnectException, ProxyException, FailureException; } public void destroy () throws ConnectException, ProxyException, FailureException; 12 TMS

15 10.3 Sample configuration file <!-- configuration file for the task management service --> <tmsconfig> <!-- brokering and submission service (multiple entries allowed) --> <BrokeringAndSubmissionService> </BrokeringAndSubmissionService> <!-- log accessor service(s) --> <LogAccessorService> </LogAccessorService> <!-- plug-ins (optional, single entry only) --> <CongestionHandler> se.gird.gjmf.tms.impl.plugins.incrementalcongestionhandler </CongestionHandler> <FailureHandler> se.gird.gjmf.tms.impl.plugins.limitedretriesfailurehandler </FailureHandler> <TaskPrioritizer> se.gird.gjmf.tms.impl.plugins.randomtaskprioritizer </TaskPrioritizer> <StateTransitionMonitor> se.gird.gjmf.tms.impl.plugins.defaultstatetransitionmonitor </StateTransitionMonitor> </tmsconfig> 13 TMS

16 References [1] A. Anjomshoaa, F. Brisard, M. Drescher, D. Fellows, A. Ly, A. S. McGough, D. Pulsipher, and A. Savva. Job Submission Description Language (JSDL) specification, version November [2] S. Graham and B. Murray (editors). Web Services Base Notification 1.2 (WS-BaseNotification). WS-BaseNotification-1.2-draft-03.pdf, November [3] Grid Infrastructure Research & Development (). May [4] Arvid Norberg. Job Control Service (JCS). May [5] D. Snelling, I. Robinson, and T. Banks. OASIS Web Services Resource Framework (WSRF) TC. October [6] The Globus Alliance. [7]. Brokering and Submission Service (BSS). May [8]. Grid Job Management Framework (GJMF). May [9]. Log Accessor Service (LAS). May [10]. Task Group Management Service (TGMS). May TMS