Quan, Kao - SLA Negotiation Protocol for Grid-Based.pdf - Psychologia - koni86

SLA Negotiation Protocol for Grid-Based

Workﬂows

Dang Minh Quan and Odej Kao

Department of Computer Science, University of Paderborn, Germany

Abstract. Service Level Agreements (SLAs) are currently one of the

major research topics in Grid Computing. SLA negotiation protocol de-

ﬁnes a business relationship between consumer and provider and is thus a

necessary part of any commercial Grid application. In the Grid environ-

ment, an SLA negotiation protocol for a workﬂow becomes complicated

because of its structure which includes many dependent sub-jobs. The

complex workﬂow model leads to several constraints compared to single

jobs and requires advanced solutions. As a continuous eﬀort in building

a full system supporting SLAs for Grid workﬂows, this paper presents

an SLA negotiation protocol for workﬂows and an initial system imple-

mentation.

1 Introduction

Service Level Agreements (SLAs) [8] are currently one of the major research

topics in Grid Computing, as they serve as foundation for a reliable and pre-

dictable job execution at remote Grid sites. The process of SLA composition

between consumer and provider is implemented by an SLA negotiation protocol.

Most of the existing SLA negotiation protocols [1,2,3,10] apply solely for Grid

jobs deﬁned as monolithic entities, where the user sends the input data to a

service, computes the data – without dependencies – on this site and receives

the results. The complexity of the SLA negotiation protocol grows signiﬁcantly

in case of workﬂows consisting of multiple, dependent sub-jobs. Figure 1 depicts

a common scenario where a workﬂow in a Grid environment is executed. The ex-

ecution of such a workﬂow diﬀers from a single job execution in several aspects.

A workﬂow consists of many dependent sub-jobs, each of them with individual

requirements. Some sub-jobs have to run in parallel in order to fulﬁl the SLA

conditions, so certain resources are required simultaneously. Thus, it is necessary

to re-distribute the sub-jobs to diﬀerent sites. Those diﬀerences lead to further

challenges for systems supporting SLAs for a Grid workﬂow compared to the

single job scenario. The challenges are found in the architecture, the language

description [4], the mapping algorithm [5], etc.

This paper presents the next step of building a full system supporting SLAs

for Grid workﬂows, which is an SLA negotiation protocol for workﬂows. It is

organized as follows: Section 2 describes the related work, Section 3 presents the

protocol and Section 4 describes the implementation architecture as well as the

deployment. Finally, Section 5 concludes the paper with a short summary.

L.T. Yang et al. (Eds.): HPCC 2005, LNCS 3726, pp. 505–510, 2005.

Springer-Verlag Berlin Heidelberg 2005

506

D.M. Quan and O. Kao

2 Related Work

Czajkowski et al. introduced a general negotiation model called Service Negoti-

ation and Acquisition Protocol (SNAP) [3]. SNAP deﬁnes three types of SLAs

to manage resources across diﬀerent administrative domains, which are Task

SLA (TSLA), Resource SLA (RSLA) and Bind SLA (BSLA). Those types of

SLAs can be used together in order to describe complex service requirements

in a distributed environment. The SNAP protocol is general and valid for many

cases. However, the application of the protocol to a speciﬁc problem needs fur-

ther extension to satisfy the requirements. A research contribution to express

a detailed SLA negotiation and implementation is presented in [1]. The GGF

Grid Resource Agreement and Allocation Protocol Working Group proposed a

draft on Agreement-based Grid Service Management (OGSI-Agreement), which

deﬁnes a set of OGSI-compatible portTypes through which management appli-

cations and services can negotiate.

Nassif et al. presented an agent-based SLA negotiation in Grids [10]. The

negotiation module includes diﬀerent forms of negotiation called bilateral, multi-

issue and chaining negotiation. A bilateral negotiation occurs when only two

parts are involved. In a multi-issue negotiation, diﬀerent aspects are negotiated

such as price, quality and time schedule. The negotiation between user agent

and network agent is called chaining negotiation. A chaining negotiation occurs

after the negotiation between user agent and server agent ﬁnished.

An initial work to design and implement a system supporting SLAs for Grid

jobs is described in [6,7,2]. However, solely monolithic jobs are considered and

supported. Shortcomings are mainly the underlying cost model and the missing

consideration of SLOs (Service Level Objectives).

3 SLA Negotiation for Workﬂow

As shown in Figure 1, an implementation of SLAs for workﬂows needs the partic-

ipation of three entities: a consumer, a broker and one or more providers. From

consumer’s point of view, the broker is responsible for satisfying the published

SLA workflow broker

Provider 2

Provider 1

Subjob 1

Provider 3

Subjob 0

Subjob 3

Provider 4

Subjob 2

Fig. 1. Scenario of running a workﬂow in the grid environment

SLA Negotiation Protocol for Grid-Based Workﬂows

507

SLA subjob

Local RMS

SLA data transfer

SLA workflow

Grid resource

broker

SLA subjob

Local RMS

SLA subjob

Local RMS

SLA data transfer

Fig. 2. Interaction among participants in SLA for workﬂow negotiation process

requirements. However, the broker does not execute the workﬂow but manages

the workﬂow execution process. Components that run sub-jobs of the workﬂow

are computing services with their local Resource Management Systems (RMS).

The interaction among them in the negotiation process is depicted in Figure 2.

Figure 2 presents three diﬀerent types of sub SLA negotiations. The User

- Broker negotiation focuses on the deﬁnition of the submitted SLA. Broker

- Provider negotiation considers the workﬂow’s sub-jobs and uses the sub-job

SLAs. Provider - Provider negotiation deals with the data transfer between sub-

jobs (and also between providers) so the SLA part for data transfer is used.

In following, the each SLA part as well as the SLA negotiation procedures are

described in detail.

3.1 SLA Document Description

The SLA document deﬁnes the data transfers between two participants in the

negotiation process. All three types of the SLA text - including SLA workﬂow,

SLA sub-job, SLA data transfer - are compiled with the same SLA workﬂow

language [4]. The structure of the SLA text is presented in Figure 3, Figure 4,

and Figure 5.

3.2 Basic Negotiation Procedures

Although there are three types of SLA negotiation, the procedure remains the

same, only the service attributes diﬀer. Figure 6 describes this basic procedure as

a Client/Server model. In the ﬁrst step, the client creates a template SLA with

some preliminary service attributes and sends those to the server. The server

parses the text and checks the client requirements. In case of conﬂicts, a new

SLA version is compiled and sent back. Modiﬁed information can be start/stop

time, cost, maximal available CPUs etc. Additional information can be a new

SLO, FTP address, path etc. The client veriﬁes the new SLA version and sends

it to server again. The process is repeated until the SLA is deﬁnitely accepted or

rejected. After acceptance, the signing phase is completed leading to an accepted

SLA, which cannot be modiﬁed.

3.3 An SLA for a Workﬂow Negotiation Process

Figure 7 describes the SLA negotiation for a Grid-based workﬂow as a time se-

quence. The customer sending an SLA template for workﬂows to the broker starts

the process. The broker determines a solution and negotiates with the customer.

508

D.M. Quan and O. Kao

SLA workflow

SLA subjob

General SLA description

Subjobs description

SLO description

Data transfer description

Signature

Compute task description

SLOs description

Data transfer description

Signature

Fig. 3. SLA workﬂow structure

Fig. 4. SLA sub-job structure

SLA data transfer

1. Template SLA

General SLA description

Grid FTP

2. SLA negotiation

File list

Signature

3. SLA sign

Fig. 5. SLA data transfer structure

Fig. 6. Basic SLA negotiation procedure

Template SLA workflow

SLA workflow negotiation

Template SLA subjob

SLA subjob negotiation

SLA subjob signing

Template SLA dat-tran

SLA dat-tran negotiation

SLA workflow signing

SLA dat-tran signing

Phase 1

Phase 2

Phase 3

Fig. 7. SLA for workﬂow negotiation process

Thereafter, the broker performs an SLA sub-job negotiation with providers for

all sub-jobs in the workﬂow. The SLA data transfer can be initiated after all

related SLA sub-job negotiations are completed. In case of conﬂicts, the broker

will ﬁnd another solution and repeat phase 2 and phase 3. Following parts de-

scribe the negotiation steps with focus on the operation of each participant as

well as on the modiﬁed and additional information in the SLA text.

After the preliminary mapping decision (phase 1), the broker gains detailed

information on running the workﬂow, which is used for the negotiation (start/

stop time for each sub-job, data transfer SLA, etc.). Additional information can

be related for example to the SLO for workﬂows. However, in the SLA context,

consumers can also cause a Grid job failure for example by underestimating the

processing time. This will lead to job cancellation or job checkpointing after the

reserved time slot expired. Thus, it is necessary for the broker to add more SLOs

which impose the customer responsibility for the SLA text.

SLA Negotiation Protocol for Grid-Based Workﬂows

509

After receiving the SLA for a particular sub-job, the provider parses the

document and checks if it can fulﬁl the requirements (Phase 2). After successful

evaluation, the provider adds the FTP address and the storage path to the SLA

part deﬁning the data transfer.

Phase 3 with provider - provider negotiation process increases further the

complexity. It can be done only when the two related SLA sub-job negotiations

ﬁnished. If this is not the case, the destination provider will conclude that the

submitted SLA data transfer belongs to none of the jobs and will discard it. In

order to solve this problem, the broker monitoring the state of each SLA sub-job,

plays the role of SLA transition. The template SLA from source provider is sent

to the broker and then to the destination provider when appropriate.

4 System Implementation

An implemented prototype fulﬁls the above constraints and provides basic fea-

tures, which allow any client to negotiate SLAs, monitor running workﬂows and

to receive the result. Based on standard components such as Globus Toolkit 3.2,

MySQL database, Maui ME for the local RMS, the system is compatible with

the existing Grid infrastructure. The overall architecture schema is depicted in

Figure 8. The online demonstration of the negotiation process as well as the

execution of a workﬂow consisting of seven sub-jobs in cooperation of three local

RMS can be found at http://pc-kao3.upb.de:9035/manual/test.html

Client console

Client

OGSI

SLA workflow broker service

Parser

Database

Mapping Monitoring

Negotiation

Broker

OGSI

SLA local service

Local

RMS

SLA aware layer

Maui ME

Fig. 8. System implementation architecture

5Conluon

An SLA negotiation process for workﬂow in the Grid environments is more

sophisticated than the mapping of monolithic jobs contained in the workﬂow.

This paper aims at deﬁning that process and distinguishing the role as well as

the interaction of the components participating in the negotiation. The main

contribution of the paper is the deﬁnition of the components, the structure of

the SLA text and of the protocol which merges all components in the SLA

negotiation process. The process starts with negotiation on workﬂow between

Quan, Kao - SLA Negotiation Protocol for Grid-Based.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: