Gestione di Service Level Agreements (SLA) in sistemi Grid Dip. di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Orazio Tomarchio

Agenda Towards Service Oriented GRIDs Service Level Agreements concept The WS-Agreement specification The proposal: dynamically modifiable SLAs Conclusion Grid Open Days al LNS - Catania 23 gennaio 2008

Convergence between Grid and SOA Software engineering evolution GRID evolution More computational power for e-science applications through modularisation Handling complexity High Performance Computing Object orientation Cluster Computing Component based architectures Networked Computing (GRID) Business requirements SOA Service Oriented Architectures Service Oriented GRID: Computing and storage available on the Internet Common challenges

Fully Networked Business Interactions Many potential providers can be found for each required function. The distinction between internal and external applications and providers looses importance

IT for the New Enterprise Today it is vital to adapt the computing model to the business interaction model Need to encapsulate business function to make it available to partners: service components. Services must be defined by explicit contracts to allow independent party access. Consequence is automatic binding. Core concern of business is to integrate business processes and functions. Business components are integrated creating service compositions. New value is created through integration/composition.

Service Level Agreements SLA Service Customer Service Provider Service Level Agreement (SLA): Formal negotiated agreement between a Service Provider and a Service Customer The contract involves parameters relating to the service to be provided, both functional and non functional (QoS) QoS to be achieved is expressed through the Service Level Objectives (SLOs)

SLA in GRID environments GRID resources: CPUs Storage In GRID environments “services” take the form of resource leasing GRID VO are the service (or resource) providers QoS to be guaranteed in SLAs is to be expressed in terms of computational power and storage capability

The WS-Agreement specification Developed by the GRAAP working group (Grid Resource Allocation Agreement Protocol) of the Open Grid Forum (OGF) It has been recently published (May 2007) as an OGF Proposed Recommendation The objective of WS-Agreement is to define a language (XML based) for establishing and monitoring Agreements between two parties Main features One-shot interaction It allows the use of custom languages for the description of domain– specific resources No support for negotiations

One-shot interaction Agreement Initiator (on behalf of the Service Customer) Agreement Responder (on behalf of the Service Provider) Negotiation Phase Agreement Offer Accept/Reject Monitoring Phase Terminate

WS-Agreement’s limitation Once agreed by the parties, the Service Level Objectives can not be modified during the service provision Sometimes the parties are not able to honor the Agreement, due to: Resource management issues for Service Providers Dissatisfaction of the perceived QoS for Service Customers Agreement’s violation: Penalties for the violator Waste of resources, time and money The WS-Agreement protocol is not flexible: No room for any re-negotiation of the terms No means to modify the terms

WS-Agreement in composite services scenarios Service Provider SP4 Ag41 Ag1c Ag21 Service Provider SP1 Consumer c Ag32 Service Provider SP2 These limitations are particularly pressing in composite services scenarios, where multiple one-to-one Agreements are established among parties. For instance, let us assume that C has stipulated an Agreement with SP1 for a given service. And SP1 to provide that service has to rely on some other services (SP2, SP3, SP4,…). If for some reason SP2 is not able to maintain the agreed QoS level, the Agreement is terminated and the service stopped. These means that also the Agreement 1c between C and SP1 cannot be maintained anymore and it is terminated too. The Agr. Ag32 and ag41 should not be terminated, but they willproduce a waste of money for sp2 and sp1 respectively, since they are paying for a service that they arenot consuming anymore. Service Provider SP3 Grid Open Days al LNS - Catania 23 gennaio 2008

Our Work Objective: Giving the parties the possibility to modify the terms of the Agreement while the service is being provided A new scenario: Step 1: The parties negotiate the modification of the terms of the earlier signed Agreement Step 2: The Agreement is formally modified Our proposal provides means to support just the formal modification of the Agreement (Step 2). Step 1 is out of the scope of this presentation We are currently working on the integration of a support for the terms’ (re)negotiation

What has been done Integrations to the XML schema of the Agreement The schema now takes into account for the possibilities of agreeing on SLOs that are modifiable at run-time An Agreement document conforming to the old XML schema is conformant to the new schema too! Enhancement of the protocol New Port Types and Operations have been added to support a new level of interaction between the parties

An additional level of interaction Agreement Initiator (on behalf of the Service Customer) Agreement Responder (on behalf of the Service Provider) Negotiation Phase ModifiableAgreement Offer Accept/Reject Re-Negotiation Phase AgreementModification Offer Accept/Reject

Simple two way interaction SLOModification Acceptance Agreement Handler Agreement Factory Agreement Initiator Agreement Responder CreateModifiableAgreement The AR accepts the Agreement offer and creates the new Agreement Result Ongoing re-negotiation of the QoS levels ModifySLO The AR receives the modification proposal and evaluates it Result The AR decides to accept the modification proposal and modifies the Agreement’s terms Accept Result

A service composition scenario Ag1c Ag21 Service Provider SP1 Consumer c Ag32 Service Provider SP2 Service Provider SP3

Three way interaction Service Provider SP3 Consumer SP1 needs to modify the terms of its Agreements In order to accept the modification proposal, on its turn, SP2 has to modify the Agreement it has with SP3 CondModifySLO CondModifySLO CondModifySLO C agrees to the modification proposal CondAccept SP3 agrees to the modification proposal SP2 agrees to the modification proposal CondAccept CondAccept The modified Agreement becomes effective Confirm Confirm Confirm

Ongoing and future Work Implementation work has been carried out Based on the CREMONA framework (IBM) Protocol validation and refinement Tested the correctness and effectiveness on a B2C scenario Better understanding of service requirements for the runtime QoS adjustment without the need of service suspension Introducing the support for automatic negotiation: Negotiation of resources before the agreement takes place Re-negotiation of the resources at run-time

Thank you for your attention! Questions?