Unidades de apoyo a la actividad profesional

The system use cases are shown in Figure 12 and describe a set of goals using behaviour and actions from the perspective of the major entities within the system. They also describe goal dependencies to help build a picture of how each action is related to the next. The use cases are divided into boundaries of responsibilities. If a use case falls within a boundary, that entity is responsible for carrying out the action. The key entities considered during the implementation of the SLA Management architecture are the end- user, the SLA Manager and the resource broker. Within each use case the goal and actions are described. Underlined text within each description infers a dependence on another use case.

uc Use Cases

Broker Use Cases SLA Manager Use Cases

End User Use Cases

End-user

Create SLA Request Resources for

Task

Setup monitoring

Update SLA Accept SLA offer

Request initial prediction Prov ide task requirements and

guarantees

Monitor application progress

Execute control loop

Adapt application execution

Select resources for Task

Reserv e resources

Submit application

Transfer Checkpoint

Present results to user

Migrate application execution

Perform initial prediction Request SLA for Task

Rej ect SLA offer

«i ncl ude» «i nclude»

«incl ude»

«i nvokes»

«extend»

«incl ude» «incl ude»

«i nvokes» «i nclude» «include» «i nclude» «incl ude» «include» «include» «i nclude» «incl ude» «incl ude» «i nvokes» «incl ude»

Figure 12 System use case diagram

3.4.1 End-User Use Cases

The end-user use cases describe actions performed by the end-user.

• Request SLA for task - The goal of this use case is to send a request to the SLA Manager for the execution of a task representing a run of a Grid application. Most Grid applications are categorised as single or multiple batch submissions, MPI or interactive. The type of tasks targeted by the SLA Management Architecture are single batch applications. They are submitted to cluster based Grid resources using Grid middleware scheduled locally using a network batch queuing system. During the request the end-user will be required to provide task requirements and guarantees.

• Provide task requirements and guarantees - The goal is to provide the SLA Manager with a set of task requirements and guarantees. These describe

hardware and software requirements, guarantees and timing constraints. The SLA Manager uses these requirements to create an SLA template and request resources for task.

• Request initial prediction - This requests an initial prediction from the SLA Manager for the application execution time. The method of prediction is described in section 5.2.3 and produces an approximation of the execution time based on previous runs of the application. This estimation is used to determine the finishing time of the application whilst it is executing. The SLA Manager performs the initial prediction and presents the results to the user.

• Reject SLA offer - The end-user has the option of rejecting the SLA offered by the SLA Manager. If rejected, the end-user has to request another SLA for task.

• Accept SLA offer – If the end-user accepts the SLA offered by the SLA Manager, the SLA is approved for execution and the application is submitted. The SLA Manager submits the application which is described by the SLA.

3.4.2 SLA Manager Use Cases

The SLA Manager use cases describe actions which can be taken by the SLA Manager. • Request resources for task – After the end-user has provided the task requirements and guarantees, the SLA Manager must determine if the requirements can be matched to resources. To do this the SLA Manager uses a resource broker such as the Three-phase commit SNAP broker [7] to select resources for task. If resource reservation is needed the SLA Manager can also reserve resources for task using the resource broker.

• Create SLA – An instance of a SLA is created which contains the requirements, guarantees and initial prediction according to the specification in section 3.8. This occurs after the SLA Manager has selected resources for the task.

• Present results to user – The goal is to allow the end-user to view the result of some internal process; for example the creation of an SLA or the results of an initial prediction.

• Perform initial prediction – The goal is to produce an initial prediction for the application execution time. The method of prediction is described in section 5.2.3 and produces an approximation of the execution time based on previous runs of the application.

• Submit application – Once the end-user has accepted the SLA, the SLA Manager submits the application in accordance with the SLA.

• Setup monitoring – The SLA Manager must be in a position to monitor the applications progress when the Grid application begins execution. The monitoring data describes the performance of the application or the system on which the application is executing SLA Manager.

• Monitor application execution – The goal is to monitor changes in performance based on application or system level monitoring data. The SLA Manager executes the control loop in order to determine the best control response for the application given the current state of monitoring. The methods used to monitor application progress are discussed in section 3.3.5.

• Execute control loop – The goal is to determine the control response given the Grid applications performance. The SLA Manager implements an adaptive rule based controller described in section 3.3.6. If the Grid application is found to be behind schedule and is predicted to finish after the time deadline, the SLA manager may, depending on the stringency of the rules in the rule base, adapt the application execution.

• Adapting the application execution – The SLA Manager will attempt to restart the application on a new resource with the latest checkpoint. If free resources are available with the current Grid resource provider, the application will be migrated to another node. If resources are unavailable with the current Grid resource provider, the application will be migrated to another provider. If this is the case, the SLA Manager must use a Grid resource broker to determine which resources are free by selecting resources for the task. If no resources are free, the Grid application continues to execute on the current resource. Once selected, the SLA Manager must migrate the application execution to a new resource provider and transfer the checkpoint. The SLA Manager is then

responsible for submitting the application to the new resource. The SLA Manager must update the SLA with violations or warnings.

• Migrate application execution – The goal is to move the application execution to a new resource. This resource could be with the same resource provider or if no spare capacity is available, resources are selected with a different resource provider.

• Transfer checkpoint – The goal is to transfer the latest checkpoint available onto a new resource and restart the application. The applications is assumed to support application level checkpointing. A description of checkpointing techniques is provided in section 2.7.

• Update SLA – The goal is to modify those elements of the SLA specification which record warnings, migrations and violations to reflect the changes given the adaptation of the application execution.

3.4.3 Broker Use Cases

The broker use cases describe actions which can be taken by the resource broker. • Select resource for task – The goal is to search for Grid resources which

match the task requirements, guarantees and the duration specified by the initial prediction. Once selected the resource broker provides details of the resource onto which the SLA Manager can submit the application.

• Reserve resources – The goal is to reserve a node with a given resource provider. This reservation is for a specified period of time and restricts usage so that a users application can start executing at a specified time.