WO2014140116A1 - System and method for managing computational task sets - Google Patents

Abstract

A system and method for remotely executing and managing tasks on a high performance computer (HPC). The system comprising an HPC and a proxy server connected on a first network, and a client computer connected to the proxy server on a second network. The proxy server provides the client computer with access to services, the services defining tasks executable on the HPC. A user interface displayed on the client computer is used for remotely executing the tasks on the HPC, where the user interface simulates local execution of the tasks. On the user interface, a service to be executed on the HPC may be requested and required inputs for the service may be submitted. Receiving, on the user interface, the resultant output for the tasks of the requested service.

Description

SYSTEM AND METHOD FOR MANAGING COMPUTATIONAL TASK SETS

CROSS-REFERENCE TO RELATED APPLICATIONS

[001] This application claims the benefit of and priority to US provisional application number 61/777,404, filed March 12, 2013, under the title SYSTEM AND METHOD FOR MANAGING COMPUTATIONAL TASK SETS. The contents of the above application are hereby expressly incorporated by reference into the detailed description hereof.

FIELD OF THE INVENTION

[002] The invention relates to defining computing tasks and managing remote execution of the computing tasks, and more particularly, to defining and executing computationally demanding tasks on resources that are in some degree dedicated or specialised for that that task, for example High Performance Computers (HPC).

BACKGROUND OF THE INVENTION

[003] Scientific and technical computing tasks are frequently executed on dedicated HPC systems. These systems are often complex to use and require the prospective user to learn a substantial amount of system-specific information before they may become productive.

[004] HPC systems have diverse character and may be a cluster computer comprising many interconnected servers, a supercomputer, a distributed computing network, or other specialised hardware device. HPC systems share the common characteristic that they provide substantially more computing capability than is available within a contemporary workstation or desktop computer.

[005] By their nature, HPC systems require substantial capital expenditure to obtain, and depreciate rapidly as a consequence of Moore's Law progression in computer performance. HPC systems are therefore frequently operated as shared resources, wherein individual users or user groups contribute towards the

l capital expense of a system and/or contribute in proportion to their use of the resource.

[006] Access to HPC systems is typically mediated by a software system, herein referred to as a resource management system (RMS), that maintains a queue of tasks to perform and manages their execution on available resources according to a scheduling policy.

[007] User interaction with the RMS typically requires that the user be granted direct access to the HPC resource, affording them substantial access to the computer system and discretion in their use of it. This level of access provides an administrative burden in that it requires that the user be trusted to some degree. Furthermore, it also implies that the prospective user must learn system-specific details in order to execute their desired task.

[008] This administrative burden on the HPC service provider makes it difficult to offer casual or anonymous access to their resources. Similarly, differences between systems makes it difficult for a user to migrate to a new HPC service provider even if the task they wish to perform is a common one.

[009] Users of an HPC system typically interact with the RMS by submitting tasks for execution to a queue. Queued tasks are annotated by the user with a description of the resources necessary for their execution (eg number of CPU cores, amount of RAM, walltime to completion), upon which the RMS can make scheduling decisions. Users may examine the contents of the queue to

determine the state of their tasks (eg queued, executing, completed, failed). For this purpose, all enqueued tasks are assigned a unique identifier by the RMS, by which they must be referred . The execution of the task itself is non-interactive: RMSs typically provide only very limited ways for the user to interact with running tasks, so all input and configuration required for completion must be specified by the user at the submission time.

[0010] Although the task that the user wishes to execute on the HPC resource may be simply specified as a program executable and input data files, the user may need to perform significant configuration and ancillary tasks prior to execution. Examples include the compilation of source code to an executable program suitable for the HPC system, determination of resource and runtime requirements and manual staging of input and output files. Heterogeneity in hardware and software operating environments may preclude working task configuration from being between different HPC resources.

[0011] Many HPC tasks are throughput activities, that is they require the execution of large numbers of independent tasks (an ensemble of tasks). RMSs have limited support for simplifying the lifecycle of throughput tasks. Some assign a unique identifier to each individual task, while some (eg PBS Pro) implement the concept of task arrays, allowing the tasks to be controlled as a set. The use of an RMS-assigned identifier for either individual or ensemble tasks imposes an administrative burden on the user who must maintain their own mapping between them and those that they have themselves assigned as part of their own book-keeping .

[0012] Additional complexity for the HPC user arises from the physical and logical separation of the HPC from the user's own computer. This separation requires the user to establish some network-mediated connection to the HPC in order to interact with the RMS. This is typically accomplished using the Secure Shell protocol (SSH) for which appropriate authentication credentials must be obtained and presented . Furthermore, in the absence of any shared or common file system between the two systems, input data required for HPC tasks and resultant output files must be manually transferred by the user. Since task execution is asynchronous, output data are typically only available once the task is completed, even if they have been produced incrementally throughout the task's execution. This delay in obtaining the task output naturally delays the start of any subsequent analysis or processing .

SUMMARY OF THE INVENTION

[0013] The system of the present invention includes an HPC system, a proxy server system and a client system. The client system communicates and accesses HPC resources through the proxy server system.

[0014] The invention described herein provides a user interface (UI) to the end-user that provides an abstracted view of the HPC. Tasks are presented as "services" that are described by input requirements and the resultant output, with all implementation detail abstracted from the user's view.

[0015] The user interface further allows for large numbers of tasks

(ensembles) to be named, grouped and manipulated using an user-specified hierarchical name. If ensembles are too large for all members to be processed concurrently on the HPC, tasks will be serialised . The proxy server can divide each independent task into a set of sub-tasks with serialising dependencies in order that their execution may be time-sliced on the HPC in a manner

transparent to the user. The user interface further provides mechanisms for authentication, authorisation and accounting . A delegated authentication system allows for a group of users to operate independently using common

authorisation, for the purpose of shared accounting .

[0016] According to the present application, there is provided a system comprising a proxy server; a high performance computer (HPC) in

communication with the proxy server via a first network; and a client computer in communication with the proxy server via a second network, wherein the proxy server is configured to provide the client computer with access to services, the services defining tasks executable on the HPC, and wherein the client computer is configured to display a user interface for remotely executing the tasks on the HPC, where the user interface simulates local execution of the tasks.

[0017] As well, according to the present application, there is provided a method for accessing a high performance computer (HPC), the method comprising : displaying, on a client computer, a user interface for remotely executing tasks on the HPC; connecting, using the user interface, to a proxy server on a first network, the proxy server being connected to the HPC via a second network; providing, by the proxy server, the client computer with access to services, the services defining tasks executable on the HPC; and requesting, using the user interface, a service to be executed on the HPC and providing a required input for the requested service; receiving, at the client computer on the user interface, the resultant output for the tasks of the requested service.

[0018] Also, according to the present application, the method further comprises creating, using the user interface, an ensemble representing two or more tasks, wherein the ensemble may be named with a user-specified name, grouped and manipulated using the user interface. [0019] According to the present application, the method further comprises delegating, using the user interface, access to the HPC to a second client computer.

The first client and second client computer operate independently using a common authorization.

[0020] Additionally, according to the present application, the method further comprises specifying, via the user interface a new service to be instantiable on the HPC resource.

[0021] Additionally, according to the present application, the method further comprises creating, using the user interface, a user-specified identifier for requested tasks executable on the HPC; and transmitting, by the client computer, the user-specified identifier to the proxy server.

[0022] The method further comprises providing a restricted operating environment on the HPC resource, such that a task may be executed in a consistent software/hardware environment independent of that of the operating environment of the HPC resource itself, for the purposes of system security and portability of services definitions between H PC resources.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 shows a block diagram of the system according to one embodiment of the invention;

[0024] Figure 2 shows a table illustrating a representative list of

commands accepted by the proxy computer service, according to one

embodiment of the invention;

[0025] Figure 3 shows a table of an example service description provided by the proxy computer service, according to one embodiment of the invention;

[0026] Figure 4 shows a table of an example use of hierarchical naming of tasks, according to one embodiment of the invention; [0027] Figure 5 shows a sequence diagram of message exchanges between a client and a proxy, and the proxy and a HPC system during the execution of a task, according to an embodiment of the invention;

[0028] Figure 6 shows an example command line interface of a client invocation of a service, for two representative implementations of the client, according to an embodiment of the invention;

[0029] Figure 7 shows an example command line interface of the creation and revocation of delegated credentials, according to another embodiment of the invention;

[0030] Figure 8 shows an example command line interface of a client querying 1) the status of all projects (task groups) created under the user account and 2) the status of all tasks in a single project, according to another embodiment of the invention;

[0031] Figure 9 shows an example formula of a cost function used by the proxy server to produce a cost for a task, to be used for charging a user account, according to another embodiment of the invention; and

[0032] Figure 10 shows an example resource graph of time-slicing using task subdivision, according to another embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

[0033] An embodiment of this invention will be described below with reference to the accompanying figures.

[0034] Figure 1 is a block diagram showing the configuration of a computer system according to one embodiment of this invention. As shown in Figure 1, the computer system has a plurality of computers of different functional groups, including a first group of computers 7 (also referred to herein as "HPC

computers"), a second group of computers 8 (also referred to herein as "proxy servers") and a third group of computers 6(also referred to herein as "client computers"). The above components may also be referred to as the HPC system 7, proxy server system 8, and client system 6 respectively. Lines between components in Figure 1 depict network relationships, indicating for example whether relationships are one-to-one, one-to-many or many-to-many.

[0035] The computers of the HPC system 7 are composed of a plurality of compute resources 11 under the control of the Resource Management System RMS 10. Each HPC system 7 is coupled to a data storage system 2 that may be implemented as network-attached disk storage presented using the network file system (NFS). In other embodiments, storage may be implemented using non- disk media and presented using direct-attached block access, or as distributed storage.

[0036] In an embodiment of the invention, the HPC systems 7 are controlled by a Resource Management system (RMS) 10. Examples of RMS software include Torque, PBS Pro, Sun Grid Engine, LSF and SLURM.

[0037] The proxy servers 8 are connected to the HPC computers 7 via a first network 12 which exposes access to the HPC's (RMS) 10. The computers of the proxy server system 8 each share a connection to common storage 1. This may be implemented as an SQL database and as a network-attached disk storage presented using the network file systems (NFS).

[0038] In an embodiment of the invention, data held in the SQL database may include: (a) user account contact details (ex. Email address, postal address, etc); (b) user account authentication details (ex. username,

password); (c) delegated credentials, organised by user account; and (d) a record of all computational tasks, organised by user account, including start and end time, name of service invoked and cost.

[0039] The proxy servers 8 are also connected to the client computers 6 via a second network 13. The proxy servers 8 present to the client computers 6 a list of pre-defined services that specify computational tasks available on the HPC computers 7, along with an application programming interface (API) for instantiating and controlling said services. Furthermore, the proxy servers 8 limit access to services and service instances ('tasks') through application of authentication and authorisation policies, and maintain accounting records of all client and task activities. Under the control of a human or software agency, the client computers 6 delegate computational tasks to the HPC computers 7 through interaction with the proxy server 8. Software that executes on the client (the 'client program') performs all interaction with the proxy server. [0040] The HPC computers 7 and proxy servers 8 may exist in the same or separate trust domains.

[0041] In an embodiment of the invention where the proxy server systems 8

and HPC systems 7 exist in different trust domains 4, the two systems must establish a trust relationship prior to further interaction. Examples of

mechanisms for authorisation may include Kerberos ticket issuance, secure shell (SSH) connections using pre-shared cryptographic keys and HTTPS connections. In this embodiment, communication between the proxy server systems 8 and the HPC systems 7 for the purposes of interaction with the RMS 10 and for file transfer occurs over an IP network using a SSH connection established using RSA key exchange for mutual authentication.

[0042] In another embodiment of the invention, the proxy server systems 8

and HPC systems 7 exist in the same trust domain. In this embodiment, the proxy server system 8 is able to interact with the RMS 10 directly from the computer on which the proxy server system 8 is running . Also in this second embodiment, the NFS component of storage system 2 is common between the proxy server system 8 and the HPC computers 7. Thus, since the file system is shared, explicit file transfer operations from the HPC computer 7 to the proxy server 8 are not required.

[0043] The proxy server 8 interacts with the RMS 10 in any manner appropriate for the RMS 10. Examples of mechanisms may include: use of command line tools provided by the specific RMS 10(ex: variants of the

POSIX.1-2008 Batch Environment Services 'qsub', 'qdel' and 'qstat' for creating, listing and deleting tasks). In alternative embodiments, the proxy servers 8 may interact via a programmatic API such as the Distributed Resource Management Application API (DRMAA) or PBS(TM) calls, or any other HPC system-specific method .

[0044] A proxy server 8 may interact with one or more HPC system 7.

[0045] As well, all proxy servers 8 provide the same set of services and capabilities. The existence of more than one proxy server 8 is for the purposes of redundancy and load-balancing . [0046] In an embodiment, the proxy server 8 is configured with knowledge of a set of computational activities that can be performed on the associated HPC system. The definition of these activities is expressed in terms of the input data required and the output data generated. These definitions may be obtained through interrogation of the HPC RMS 10 or by external definition uploaded to the proxy server 8 via the client (see section 'Service Definiton and Task

Execution Environment'). The activities are advertised as a list of 'services', which may be instantiated as tasks by clients. All implementation details of the service are abstracted and opaque to the client.

[0047] The proxy server 8 accepts requests from clients via a network communication. Client computers 6 connect to the proxy servers 8 over an IP network 13. The Hypertext Transport Protocol (HTTP) may be used as a transport for requests sent to the proxy servers 8. Message payloads are encoded in Extensible Markup Language (XML).

[0048] In other embodiments of the invention, alternative protocols may be used as transport and message encoding. Examples of alternative transport protocols include SMTP. As well, examples of alternative message encodings include JSON and YAML and comma-separated-variables.

[0049] Client computers 6 may locate the IP network address of Proxy servers 8 by means of domain-name resolution using the Domain Name Services (DNS) protocol.

[0050] The proxy server 8 may communicate with multiple clients. The proxy server and clients exist in separate trust domains and the proxy server 8 must authenticate all communication attempts made by a client. As well, a client computer 6 may interact with one or more proxy servers 8.

Client Authentication and Authorisation

[0051] The trust relationship established between client computer 6 and proxy server 8 is independent of that established between proxy server 8 and HPC system 7. As such, the proxy server 8 acts an intermediary between the agent operating the client computer 6 and the HPC system 7, limiting the client's activities on the HPC to specific, pre-defined tasks. Client access to the HPC system 7 is contingent on the authentication and authorisation (A&A) policy of the proxy server 8. Proxy server 8 access to the HPC resources is contingent on the A&A policy of the HPC system 7.

[0052] Subject to appropriate authentication, a user of a client computer 6 can :

(a) Obtain a list of service definitions

(b) Instantiate a service ('create a task') by providing the task identifier and necessary input data

(c) Monitor the status of previously created tasks and retrieve any

pending results

(d) Obtain real-time and historic data on previous transactions

(e) Configure additional authentication for delegated users

[0053] The client computer 6 authenticates with a proxy server 8 by presenting appropriate credentials that associates the user with an existing accounting entry (the 'user account') in the proxy server's 8 permanent storage 1.

[0054] As previously discussed, client computers 6 and proxy servers 8 may reside in different trust domains 3. In one embodiment, clients authenticate the identity of the proxy server 8 by establishing an encrypted socket connection using Secure Socket Layer (SSL) communication 13 and verifying the x509 certificate presented by the proxy server 8.

[0055] Proxy servers 8 authenticate connections from client computers 6 by comparing presented authentication credentials against records held in storage 1.

[0050] Credentials presented by a client computer 6 are valid if they either: (a) match the name and password of a currently active User Account (UA), or (b) match one of the Delegated Credentials (DC) of a currently active User Account.

[0051] Client computer 6 access to a proxy server 8 may optionally be subject to a host-based Access Control List (ACL). After presenting valid authentication credentials, the hostname of the client computer 6 is compared by the proxy server 8 to the per-Account ACL held in storage 1. If the hostname is not listed in the ACL, nor matches any wildcard entry therein, the connection attempt is rejected by the Proxy.

[0056] Client computers 6 presenting valid User Account credentials to a proxy server 8 have the privileges required to :

(a) generate and revoke delegated credentials for that Account,

(b) alter any host-based access control list for that Account,

(c) list, retrieve, stop and delete any task associated with that Account, and

(d) view the transaction history of the Account.

[0057] A delegated credential (DC) is a token generated by the proxy server 8 that is associated with a User Account. Its purpose is to allow limited and revocable third party access to the resources accessible to the UA.

[0058] Client computers 6 presenting a valid delegated credential (DC) have the privileges required to :

(a) create a new task, provided the User Account has sufficient credit,

(b) list any tasks associated with the User Account,

(c) retrieve, stop and delete any tasks created using the same delegated credentials, and

(d) view the transaction history of the User Account.

[0059] A client computer 6 may instruct the proxy server 8 to generate "delegated credentials" that are associated with the user account. Operations on a proxy server 8 performed by the client computer 6 presenting these delegated credentials are associated with the originating account for accounting purposes (e.g . charging of tasks). A client computer 6 presenting delegated credentials is not authorised to generate further delegated credentials and may also be subject to further limitations (e.g . limited runtime or concurrency for tasks, lowered priority for task execution, ability to view other account activity). A client computer 6 that has authenticated itself with the full credentials for the associated account may revoke delegated credentials.

[0060] In an embodiment, the user account is associated with a balance of credit that indicates the amount of HPC resource use to which the user is entitled . Each task instantiated with the user account incurs a cost, which is deducted from the account's balance. User accounts with a zero or negative balance may be denied authorisation to create new tasks or perform other operations. The cost of a task is determined by the evaluation by the proxy server 8 of an arbitrary function, such as that shown in Figure 9. In one embodiment of the invention, the cost is determined as a constant plus an amount that is dependent upon task type, task duration and HPC resource type used . The balance may be incremented by the proxy server 8 upon receipt of an instruction from a funds switching or payment acquisition system.

[0061] As shown in Figure 1, the proxy computers 8 may connect to a third-party payment service 9 via an IP network. Examples of payment services include Paypal and Worldpay.

[0062] Notices of payments acquired through the payment computers 9 are transmitted to the proxy computers 8 via an IP network. The value of the payment is converted into accounting credit and credited to the associated user account record stored in storage 1.

[0063] Payment computers 9 and proxy computers 8 may exist in different trust domains 5. They communicate via an IP network encrypted using Secure Socket Layer 14 and mutually authenticate by verifying the validity of the x509 presented by their peer. In other embodiments, the communication may be secured by other means, for example, by using a shared secret.

[0064] Client computers 6 that have successfully authenticated with a proxy server 8 are able to call one of a set of commands to direct the Proxy to perform the desired operation. Figure 2 provides a representative list of the commands that a client computer 6 may call on a proxy server 8.

Service Definition and Task Execution Environment

[0065] A computational service available for a client computer 6 to instantiate on the HPC system 7 via the proxy server 8 are defined by a "service definition". The service definition contains i) a set of one or more files containing program code or data and ii) metadata describing the service, including a human-readable description; an enumeration of the input requirements and resultant output (cf Figure 3); and iii) metadata describing the resource requirements required for its execution, iv) Billing information

[0066] Service definitions may be statically defined on the proxy server, or uploaded from a client computer 6 to a proxy server 8. The correctness of a service description so uploaded is validated by the proxy server before being added to the list of services available to the user context used by the uploading client. [0067] For each uploaded service definition the proxy server 8 maintains an access control list (ACL), which limits the user accounts with the privilege to view and instantiate the service. The ACL may be modified by commands issued from the client to the proxy server under the context of the owning User

Account.

[0068] A service definition contains executable program code that may have arbitrary function. This represents a security risk for the HPC resource on which it will run. To limit the risk posed by untrusted code in a service definition, the tasks instantiated from a service are run inside a restricted operating environment. Examples of restricted operating environments include virtual machines and Linux containers. In one embodiment of the invention, tasks are executed within virtual machines (VM) under KVM on a Linux host system. Tasks so executing have neither external network access, nor direct access to host file systems. A VM instance is instantiated for each task and destroyed on task termination. These provisions ensure that malicious programs uploaded as service definitions, or tasks subverted by malicious input data are unable to compromise the integrity of the HPC resource or any external computer system.

[0069] A service definition contains executable program code that may have dependencies on specific third-party or operating system software. Such dependencies may be complex and/or commonly required by many services. A service definition may include all dependencies as part of its file set, but a more efficient method is to request a specific custom execution environment for the service instantiation. In one embodiment of the invention custom execution environments are implemented as virtual machine (VM) images containing known, documented software configurations. In this manner, a single service definition may be used to configure a service that can be instantiated on disparate HPC resources.

[0070] A service that requires a specific custom operating environment indicates this by including the name (unique identifier) of the environment in the service definition metadata. Upon receipt of an uploaded service definition, the proxy server 8 compares the identifier of any required operating environment with those present on the HPC resources and rejects the definition only if the environment dependency cannot be satisfied . [0071] Services configured with uploaded service definitions may be shared with other second-party UAs by means of an appropriately configured ACL. The originating first-party UA may include in the service definition billing information, indicating any charge applicable for second-party use of the service. A second-party UA instantiating such a service will incur the stipulated charge which will be debited from the second-party's account balance and accrued onto that of the first party. In one embodiment of the invention, service instantiations incur a fee that includes a flat component to the UA that originated the service definition and a variable component to the operator of the proxy server that is proportional to the amount of HPC resource consumed by the task.

Service Instantiation

[0072] The computational tasks that are available for a client computer 6 to instantiate on the HPC system 7 via the proxy server 8 are enumerated by the proxy server 8 in response to a client query, such as those shown in Figure 2. The list of services returned to the client is limited to those that the User

Account has privileges to invoke. In an embodiment of the invention, access to services is limited to User Accounts for which specific access has been

purchased .

[0073] An example of a service description is shown in Figure 3. The description specifies the input data required to invoke the service. Individual items of data can be specified as files or immediate values, may be optional or mandatory, and may be given default values. The description does not specify the actual compute resources required to run the job. The resource specification is automatically determined by the proxy server 8 using service-specific program code that is able to optimize the resource request based upon inspection of the client-supplied input. In this manner, the client computer 6 is insulated against the implementation details of the service on any given HPC system 7.

[0074] Upon instantiation, tasks are assigned an identifier so that they may be referred to in subsequent operations. A RMS 10 of the type found on HPC systems 7 typically identifies tasks under its control with a unique

alphanumeric identifier that it generates according to some algorithm. An example of such an algorithm is a simple sequential counter. Exposing these or other system-generated identifiers to the client computer 6 imposes an administrative overhead for the client in reconciling that identifier with the client's own description for the task. In contrast to the usual RMS 10 practice, in the present application the client computer 6 assigns this identifier. Therefore, the proxy server 8, when invoking a service as a result of a client request, accepts also a client-provided identifier for the task. The proxy server 8 imposes the requirement that each identifier is unique within the set of all identifiers created by a user.

[0075] Identifiers are composed of a sequence of tokens and delimiters. The tokens define nodes in a hierarchical graph, in order that several tasks related for some purpose may be given names that indicate their association.

[0076] The use of user-assigned identifiers for tasks obviates the need for the user to manually maintain the relationship of HPC RMS-assigned task identifiers with their own personal bookkeeping .

[0077] In an embodiment of the invention, the task identifier is formatted as a series of free text tokens separated by a delimiting token. Examples of task naming are shown in Figure 4. The delimitation of the string into tokens affords a hierarchical organisation of tasks, analogous to the directory structure of a computer file system and also allows wild-cards to be used to efficiently refer to arbitrary groups of tasks.

[0078] In one embodiment of the invention, wild-card formulations of task identifiers include:

(a) * specifies all valid values;

(b) XX : YY specifies all valid values that are lexically between values

XX and YY , inclusive;

(c) < XX specifies all valid values that are lexically less than XX,

exclusive; and

(d) > XX specifies all valid values that are lexically greater than XX, exclusive.

Lexical ordering follows the rules in effect for the active language locale of the computer on which the client is executing .

[0079] Commands accepted by the proxy server 8 (such as those commands shown in Figure 2) that require the identifier of a task as an argument also accept wild carded identifiers, in order to efficiently operate on multiple tasks with a single request. [0080] Figure 5 shows an example of the sequence of commands that may be executed by a client during the submission, monitoring and completion of a remote task. The rightmost column shows representative operations performed by the user. The leftmost column indicates the phases of the task lifecycle. The centre-left column indicates the messages that are exchanged between client computer 6 and proxy server 8. The centre-right column indicates the RMS 10 operations performed on the HPC by the proxy server 8.

[0081] The client computer 6 may interrogate the proxy server 8 for the status of any task. If the task is running or completed, the client may instruct the proxy to retrieve and transmit any output that it has generated up to that point. The client and proxy may negotiate the retrieval of subsets of the data in order to allow incremental retrieval of a slowly growing output set and avoid retransmission of previously retrieved data.

[0082] The client computer 6 may interrogate the proxy server 8 for a history of all activity associated with the user account. In one embodiment of the invention, the user interface on the client computer 6 presents this history to the user as a summary broken down by task grouping (via identifier hierarchy) and delegated username.

[0083] In one embodiment of the invention, the client system 6 is implemented as dynamic shared library and integrated into an existing

command-line driven scientific program (the 'application'). This integration allows the application to make a run-time decision whether to execute locally, on the user's own computer, or to delegate the execution to the HPC system 7 by invoking the corresponding service. In the latter case, the application is able to instantiate the service, monitor its progress and incrementally return output to the local computer, without changing the outward appearance that it is running locally. This integration of the client provides the opportunity to use existing application code to read and validate the input data. This avoids the task failing upon start on the HPC system 7 as a result of having been created with bad input.

[0084] In another embodiment, the client system 6 is a stand-alone application that allows the user to instantiate any of the services advertised by the proxy server 8, but at the expense of any specific validation of input data correctness before task creation. In both instances of the invention, the experience of the user of the application is that the task is executing locally, and no aspect of the interaction with the remote proxy server is apparent under normal use.

Task Time-Slicing

[0085] The client computer 6 may invoke more instances of a service than the HPC is able to execute concurrently. In this instance, the HPC RMS 10 would typically execute each task sequentially as resources become available. Although this provides acceptable throughput for the ensemble of tasks, this batching means the first tasks to execute run to completion before any subsequent ones may commence. This may be undesirable from the perspective of the submitting user, if they desire all tasks to progress at similar rates, for example, if the end condition for the tasks is dependent on a global property of the ensemble as a whole (for example testing a convergence criterion).

[0086] In one embodiment of the invention, upon receipt of a service instantiation request from a client computer 6, the proxy server 8 decomposes the request from a single task to a series of tasks, each of which have a shorter runtime. These tasks are passed to the RMS 10 and annotated with serialisation dependences to ensure their ordered execution. This decomposition is opaque to the client computer 6, which continues to consider the task as an atomic entity with a single identifier. In this manner, the system is able to simulate the effect of more compute resources, by in effect time-slicing the tasks on the HPC system 7, such that all progress incrementally.

[0087] In the embodiment where the user invokes more tasks than can be executed concurrently on the HPC system 7, the RMS 10 will maintain a queue of jobs, each job representing a single task, and run each in turn as HPC resources become available. In this manner, all tasks are eventually completed .

[0088] Figure 10 (A) shows an example of 8 tasks executing on an HPC resource 7 able to run only 4 concurrently. Although this queuing method ensures efficient use of the computational resources, it may undesirable if, for example, the user wishes to derive some property that is computed from data contributed from each task, such as a global running average. In that case, no data is available until tasks 1-4 have completed and tasks 5-8 have commenced at time Ti, at over halfway through the duration of runtime for the whole ensemble T . This high latency can be the cause of considerable inconvenience.

[0089] In Figure 10 (B) the 8 tasks have been each decomposed into a series of much shorter jobs and each job enqueued to the RMS with a

dependency on its predecessor to enforce serial execution. Although the HPC resource is still able to execute only 4 jobs concurrently, the division of each task into shorter jobs means that later tasks begin to make progress before the earlier ones have completed fully. The latency between submission of tasks and the availability of first results at T₂ is thus considerably reduced compared to Ti.

[0090] As previously discussed, the decomposition of the user-submitted task into a chain of RMS jobs is managed by the proxy server 8 and is opaque to the user, who continues to consider the task as an indivisible unit and refer to it using its task identifier. From the user perspective, the execution of any one task will appear to stall periodically, between jobs in the chain.

[0091] The mechanism for dividing the task into a series of jobs is service dependent. The length of each job is configured to balance the desire for prompt return of results with the need to compute efficiently.

User Interface

[0092] Figures 6 to 8 illustrate examples of a client system 6 using a command line interface to access an HPC system 7. In Figures 6 to 8 that show text representations of an interactive computer terminal session, the following typographic conventions will be observed :

• user@host> Indicates the prompt of an interactive shell belonging to the user account user on the computer with hostname host.

• command arg l (...) . Indicates and invocation of the program

named command with mandatory argument arg l and further optional arguments (...).

• // Comment In-line commentary to provide context and clarity.

• \\ Indicates continuation on the next line.

[0093] The client software mediates all user access to the proxy server 8. In one embodiment of the software the client is implemented as dynamic library, such that it may be incorporated into existing software for the purpose of transparently incorporating remote task execution into its function. In another embodiment, the client is a standalone application that exposes all the

operations available to the user (Figure 2) through a textual interface. Figure 6 shows an example of both embodiments. Although a text user interface is shown in example embodiments, the user interface may also be a graphical user interface.

[0094] In Figure 6, example [1] is a stand-alone version of the client system 6 used to invoke a service called 'ACEMD', creating as task called

'projectl/name'. The arguments required for the service invocation must be given explicitly by the user on client system 6, and match those specified in the relevant service description (Figure 3). The client is able to verify that the provided arguments match the specification but, lacking any service-specific context about the meaning of the files, is unable to verify the validity of the input before transmitting it to the proxy server 8 for service invocation.

[0095] In Figure 6, example [2] is a library version of the client system 6 incorporated into an existing application called 'ACEMD'. In this case, the application has been extended to perform a remote service invocation if run with the command line flag—cloud task/identifier. Since application code contains knowledge about the service it is hard-coded to invoke, it is able to perform additional validation of input before transmission to the proxy server 8, potentially avoiding failure of the remote task. Furthermore, the user need only supply the usual input for the application (in this example present implicitly in a file named input). The application is able to match that input to the set of inputs required according to the service specification.

[0096] In this way, the end user of the 'ACEMD' application is able to transition from running the application locally on their own desktop or

workstation computer, to running the same task remotely on an HPC system, without having to be aware of any of the underlying mechanisms.

[0097] Figure 7 shows a representative set of operations in which 'userl', a user in possession of the User Account credentials, manages the lifecycle of delegated credentials and access control for a user 'use^'. The following describes each of the operations [1] to [10] shown in Figure 7.

1. The administrative user in possession of the UA credentials requests a listing of the ACL. Since this is the first operation, the client requests the UA credentials, which are cached on the user's computer for subsequent use. The ACL, which contains only 'hostl', is returned .

2. The UA administrator adds 'host2' to the ACL.

3. The UA administrator lists the ACL, which now contains both 'hostl' and *host2'.

4. The UA administrator lists the users, which contains only 'userl'.

5. The UA administrator generates delegated credentials for 'use^'. The DC is an opaque token, shown as XXXX-XXXX-XXXX-XXXX. This is transmitted out-of-band to user2, using some secure method (e.g . signed email, or physical copy).

6. 'User2', authorises the computer 'host ' using the DC token. The client performs a transaction with the proxy server to verify the DC.

7. A malicious 'userB', who has intercepted the DC attempts to use the token to gain access. The client authorisation fails because the token is associated with the username 'use^'.

8. 'user2' begins using the client to run remote tasks and view the account status.

9. The administrative user, 'userl' decides to revoke 'user's access and does so by deleting the user's DC.

10. 'user2' is now no longer able to access to proxy server because his DC has been invalidated and may receive an authentication error.

[0098] Figure 8 shows a representative listing of [1] an overview of a user account's activity, and [2] the status of all the tasks within a particular project. The status summary lists the status of all the extant tasks associated with the user account, summarised by project name and by originating user. Any user in possession of valid delegated credentials may see the activity of all other DC users, but will have no ability to delete, retrieve or otherwise modify any tasks not their own. The detailed summary produced when the status is requested in conjunction with a wild-carded task identifier argument shows the status of all tasks matching that wild-card .

[0099] Tasks may be in any of the following states:

• Pending : Indicating that the task has yet to begin execution.

• Running : Indicating that the task has begun execution and not yet completed . • Ready: Indicating that the task has terminated, and results are ready to retrieve.

[00100] The cost of each task or project is given, along with the total balance credited to the UA. The cost of a task is computed by the proxy server 8 according to an implementation-specific charging function. In one embodiment of the invention, the charging function is a linear function of the runtime of the task and the size of the compute resource used, plus a fixed minimum cost, as shown in the mathematical formula of Figure 9. In another embodiment of the invention, the charging function includes a fee that is allocated to the UA that originated the service definition for the service from which the task as

instantiated .

[00101] If the balance of the UA is less than zero, the proxy server 8 may deny clients the ability to invoke new tasks. Furthermore, pending tasks may not be run and any currently running tasks terminated .

[00102] The scope of the claims should not be limited by the embodiments set forth in the examples, but should be given the broadest interpretation consistent with the description as a whole.

Claims

CLAIMS:

1. A system comprising :

a proxy server;

a high performance computer (HPC) in communication with the proxy server via a first network; and

a client computer in communication with the proxy server via a second network;

wherein the proxy server is configured to provide the client computer with access to services, the services defining tasks executable on the HPC, and wherein the client computer is configured to display a user interface for remotely executing and managing the tasks on the HPC, where the user interface simulates local execution of the tasks.

2. The system of claim 1, wherein the proxy server is further configured to : provide, to the client computer, a list of services available on the HPC, in response to receiving a request from the client computer.

3. The system of claim 1 or 2, wherein a service defines the properties of a task that may be executed on the HPC, including required input data, resources required to execute the task, and resultant output data.

4. The system according to any one of claims 1 to 3, wherein the client

computer is further configured to : request, to the proxy server, invocation of a service on the HPC; and

transmit, to the proxy server, input data required for the requested service, and wherein the proxy server is further configured to transmit, to the client computer, the resultant output of the requested service.

5. The system of claim 4, wherein the client computer is further configured to :

transmit, to the proxy server, a user-specified identifier for the task corresponding to the requested service.

6. The system according to any one of claims 1 to 5, wherein the client computer is further configured to :

create an ensemble representing two or more tasks, wherein the ensemble may be named with a user-specified name, grouped and manipulated using the user interface.

7. The system according to any one of claims 1 to 6, wherein in response to commands received from the client computer, the proxy server is further configured to :

transmit, to the HPC, input data for a requested service received from the client computer; and

transmit, to the client computer, output data from tasks executed on the HPC.

8. The system according to any one of claims 1 to 7, wherein the proxy server is further configured to :

add, monitor and delete tasks in a queue of the HPC in response to commands received from the client computer.

9. The system according to any one of claims 1 to 8, further comprising : a payment computer in communication with the proxy server via a third network for performing financial transactions relating to services performed by the HPC.

10. The system according to any one of claims 1 to 9, wherein the proxy server is further configured to :

provide conditional access to the client computer based on an

authentication and authorization policy.

11. The system according to any one of claims 1 to 10, wherein the proxy server is further configured to : maintain an accounting record of all services requested by the client computer.

12. The system according to any one of claims 1 to 11, wherein the proxy server is further configured to :

calculate a cost for the tasks performed on the HPC according to a pricing policy.

13. The system according to any one of claims 1 to 12, wherein the user interface has the appearance of an application represented by a service available on the HPC and wherein the application appears to run locally on the client computer.

14. The system according to any one of claims 1 to 13, wherein client

computer is further configured to : verify correctness of an input file for a service available on the HPC before requesting the service.

15. A method for accessing a high performance computer (HPC), the method comprising :

displaying, on a client computer, a user interface for remotely executing and managing tasks on the HPC;

connecting, using the user interface, to a proxy server on a first network, the proxy server being connected to the HPC via a second network;

providing, by the proxy server, the client computer with access to services, the services defining tasks executable on the HPC; and requesting, using the user interface, a service to be executed on the HPC and providing a required input for the requested service;

receiving, at the client computer on the user interface, the resultant output for the tasks of the requested service.

16. The method of claim 15, further comprising :

receiving, from the proxy server, a list of services available on the HPC; and displaying, on the user interface, the list of the available services including a description of the input requirement and the resultant output for each service.

17. The method of claim 15 or 16, further comprising :

authenticating, by the proxy server, the connection from the client computer.

18. The method according to any one of claims 15 to 17, further comprising : dividing, by the proxy server, a requested task into a set of sub-tasks with serializing dependencies for time-sliced execution by the HPC.

19. The method according to any one of claims 15 to 18, further comprising : creating, using the user interface, an ensemble representing two or more tasks, wherein the ensemble may be named with a user-specified name, grouped and manipulated using the user interface.

20. The method according to any one of claims 15 to 19, further comprising : delegating, using the user interface, access to the HPC to a second client computer.

21. The method of claim 20, wherein the first client and second client

computer operate independently using a common authorization.

22. The method according to any one of claims 15 to 21, further comprising : creating, using the user interface, a user-specified identifier for identifying requested tasks executable on the HPC; and

transmitting, by the client computer, the user-specified identifier to the proxy server.

23. The method according to any one of claims 15 to 22, wherein the user interface has the appearance of an application represented by a service available on the HPC and wherein the application appears to run locally on the client computer.

24. The method according to any one of claims 15 to 23, further comprising : verifying, at the client computer, correctness of an input file for a service available on the HPC before requesting the service.

25. The method according to any one of claims 15 to 24, further comprising : specifying, using the user interface, a new service to be instantiable on the HPC.

26. The method according to any one of claims 15 to 25, further comprising : executing the requested task in a restricted operating environment on the HPC, wherein the restricted operating environment is independent of a standard operating environment of the HPC.

27. The method according to any one of claims 15 to 26, wherein the proxy server maintains a service definition for each service available to the client computer.

28. The method of claim 27, wherein the service definition comprises a set of one or more files containing program data; metadata describing the service; identification of an input requirement and resultant output;

metadata describing the resource requirements for execution; and billing information.

29. The method of claim 27, further comprising :

uploading, from the client computer to the proxy server, the service definition; and

validating, by the proxy server, the service definition prior to adding the service to a list of services available on the HPC.

30. The method according to any one of claims 15 to 29, further comprising : maintaining, by the proxy server, an access control list for identifying users that are permitted to view and instantiate the services.