Upload
august-webb
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
SLA Management in an Auction-Based Market Infrastructure
Simon Caton, Nikolay Borissov & Omer Rana
Contents Overview of SORMA
Market-based SLA Generation and Representation
Challenges of this process, and related research issues
Currently, unanswered research questions
Motivation for this work
Emergence of work on Cloud Computing Commercial providers offering resources (disk storage,
processors) + hosting environments Examples: CycleComputing, EC2/S3, Hadoop, IBM Blue
Cloud, Sun Cloud, Nimbus, Eucalyptus, etc
Pricing Price pre-advertised – then payment based “on demand”
usage Significant potential for brokering approaches in this
domain – especially when interoperability between these providers arises E.g. Eucalyptus using EC2/S3 interfaces
SORMA Overview… 1
SORMA Overview… 2
Intelligent Tools – Agent-based auction participation Market- and agenda-driven
Bid/Offer submission Trading Management – the
Auctioneer Introduces consumers and
providers using technical and economic matchmaking
EERM – an Economically Enhanced Resource Manager
Contract Management – SLA Life Cycle Modelling: Generation, Runtime Logic and
Final price calculation SLA Enforcement – impartial SLA
adherence monitoring; violation detection
Payment – Transaction management for SLA-related billing (Paypal)
The SORMA Model Use Cases:
Job Submission
Service Provision
Market “rules”
All bids and offers are binding – like eBay
i.e. if there is a match participants are (currently) obliged to enter an SLA
Term Languages
JSDL – job/service definition – requirements modelling
WS-Agreement – SLA representation
EJSDL* – Economically Enhanced JSDL for Market-specific data
Currently, no intrinsic or extrinsic support in WS-Agreement for this data
Actors: Consumers Providers SORMA Market
Ecomonic Data
Common Market Data
Bid/Offer
Penalty type
Payment type
Service type
Private Economic Data
Bidding Strategy
Consumer’s Maximum willingness to pay and provider’s reserve price
Optional Market Data
Reservation Period
EJSDL* Envelops JSDL to provide an
economic foundation for Market participation
Three Versions: EJSDLBid – defines the
bid/offer of a Market participant
EJSDLPrivate – defines the private Market-specific data of each participant
EJSDLMarket – encapsulates an established Market Match
Ultimately, the use of EJSDL* means that we reduce the number of matchable and definable terms inherent in WS-Agreement E.g. preference elicitation/term
weighting But, core Market data is more
important!
SLA Generation & RepresentationWS-Agreement WS-Agreement envelops one or more disseminated EJSDLMarket
documents Generation is automated using an EJSDL-orientated Java API +
Apache’s XmlBeans Each SLA is between the consumer and the provider – SORMA
plays no part here! In the future (SORMA #2) we could consider a broker-like SLA
hierarchy, requiring much more sophistication in the Market logic Consumer SORMA SORMA 1 or more Providers
We will come back to this later
in the talk
SLA Lifecycle Overview WS-Agreement States (from SORMA’s perspective)
A bid is made No match
Market matchmaki
ng
Match found, SLA is created, enforced and
paid forSLA life cycle
complete
We do not use these
states
Note: this does not mean it
was not violated
Bids/offers are binding, they cannot
be terminated or withdrawn
Limitations with
bids that are “binding”
SLA Service and Guarantee Term States
For Pragmatic Enforcement and Billing
Service States Guarantee Term States
Service cannot yet be started
Service can be started or is
running
Service has finished
Not RunningRunning
Monitoring of SLA Guarantee term adherence
WS-Agreement only records a global state. Not useful for: Quantifying the impact or frequency of
violations Pragmatic penalty calculation
A finished service != successful service
SLA Enforcement must therefore also monitor at the service level
If a service fails, then it must determine why This is difficult to perform in practice!
Representing SLA Adherence…1WS-Agreement Specification Too General
SORMA provides an SLA Enforcement Mechanism, which collects SLA-related data for adherence classification.
Providers are actively encouraged to participant in this scheme Especially if they wish to be matched in the future Questions of trust are quickly raised, but will not be
discussed here. WS-Agreement’s State representation lacks a
practical representation of adherence in general
Remember that we need to be able to send this information between SORMA components and comply to the WS-Agreement specification.
Representing SLA Adherence…2A Motivating Example for change Example:
3 Non-static Terms T1, T2 and T3 e.g. % Range of CPU utilization available
Adherence is monitored 150 times, and all terms are determinable
T1 is violated 149 times, T2 is violated once and T3 is fully fulfilled
Questions: Terms T1 and T2 are both violated, but their violations
are not truly comparable. Should, and if so how can, we differentiate between these two violations?
How do we apply an appropriate penalty in this case? Is it fair to treat both violations in the same way? Should a penalty function consider that T2 was
predominantly fulfilled?
Augmenting the WS-Agreement Term States Representation The WS-Agreement State representation enables only the
basic status of a term i.e. [Fulfilled | Violated | Not Determined]
However, there is a spare <xsd:anyType> in the document specification
We add additional “house keeping” information here SORMA-specific term language identifying the frequency each
state observation Service scope
2 guarantee terms can have the same name, or 1 term can relate to multiple services.
This differentiation is performed using a service scope. Not in a state document. If the term is violated in one instance but not the other, the
whole term will be identified as violated, which is not the case. Our “House keeping” information encapsulates this too. Enables a fairer penalty application
Comparison of Documents
<GuaranteeTermState ws:termName="termName“>
<State>Violated</State></GuaranteeTermState>
<GuaranteeTermState ws:termName="termName">
<stat:GuaranteeTermStateHouseKeeping> <stat:ServiceScope
ws:ServiceName="serviceName"/> <stat:GuaranteeTermStateTransitions> <stat:NotDetermined> <stat:Frequency>1</stat:Frequency> </stat:NotDetermined> <stat:Violated> <stat:Frequency>1</stat:Frequency> </stat:Violated> <stat:Fulfilled> <stat:Frequency>1</stat:Frequency> </stat:Fulfilled> </stat:GuaranteeTermStateTransitions> </stat:GuaranteeTermStateHouseKeeping> <State>Violated</State></GuaranteeTermState>
Standard WS-Agreement Our Augmented Version
Namespaces (removed for ease of presentation): WS-Agreement: http://schemas.ggf.org/graap/2007/03/ws-agreement House keeping (stat:): http://www.sormaproject.eu/message/sla/state
Enables matchmak
ing
SLA PaymentFinal Price = Market Price – Applied Violation-Orientated Penalty Payment can only be made at
specific points in an SLA’s lifecycle: Before commencement and
After completion Not during
Penalties are specified in EJSDL:<Penalty>
<functionName>DefaultPenalty</functionName>
<normalizationConstant>1.0</normalizationConstant>
</Penalty>
Normalization constant Low is good for providers –
minimizes impact High is good for consumers –
maximizes assurance Negative values also would
introduce interesting scenarios
Best effort using standard representation
w(tn) – weight of term t p – price identified by the Market at the time
of match v(tn) – identifies whether term t was violated
returns [0,1] nc – normalization constant
v(tn), f(tn), nd(tn) – frequency violated, fulfilled and not determined respectively for term t
p
tw
twtvnc n
n
n
nn
*)(
)(*)(*
1
1
Simple Weighted Penalty Function
p
tw
twtndtvtf
tv
nc n
n
n
nnnn
n
*)(
)(*)()()(
)(
*
1
1
Penalty Function based on Violation Impact
Term violated [yes|no]
How the term was violated
Using the adherence data outside of penalty calculationsE.g. Market Information Services
When an SLA is complete all runtime information can be made available to a Market Information Service
For future use and Market Introspection Attribute level adherence monitoring:
Demonstrates provider reliability Enables reputation-based matchmaking Difficulty for a provider to adhere to specific attributes Mechanisms for providers to assess their own
violations, and reputation
Summary
WS-Agreement needs extension for intuitive use in market infrastructures
Term states do not currently enable a pragmatic representation of violation-related data, especially for violation-orientated billing
We are using WS-Agreement outside its "normal" use. There is no (bilateral) negotiation No agreement templates SLAs are based upon and stem from the market matching and
bidding mechanisms. In order to progress further we need a Market-Orientated
version of WS-Agreement. To include: Business values / weighting – in matchmaking Preference elicitation – for best case matchmaking Inclusion of Market data in WS-Agreement Offer Templates
We currently assume legal grounding for each SLA and in the future this needs resolution
Outlook
Identify valuation scenarios and incorporate it in penalty functions
Elaboration of general definitions for weighted Guarantee Terms SLO extraction from two matched JSDL documents
(Consumer and Provider) Mapping of weighted SLOs to Penalty Functions Inclusion of Legal Foundation
WS-Agreement – Specify economic extensions for: Auction-based infrastructures The associated scheduling strategies and decision making
models.
Some topics which are interesting for discussion…1
Can we build a tiered SLA model in a Market place? Consumer Market Broker, Market Broker 1 or more Providers The aim here is to increase transparency to the consumer But there are further challenges:
Handling malicious or untrustworthy providers Issues of Legal Liability for the Broker
Similar to work in AssessGrid? Whose fault is it when a service fails? And, how does this affect
the SLA? No scheduler or resource manager can guarantee a 100% success
rate on job/service submission What if no terms in the SLA were violated?
Is it the Consumer’s fault; perhaps poor programming? What about unfamiliarity of environment, or failed data staging?
Ultimately, who is responsible and therefore going to pay the fee/penalty?
Some topics which are interesting for discussion…2
Application of Legal Foundations in a SLA Example: A consumer pays in full and in advance for a service, but the provider does not
adhere to the SLA and a penalty is due. Therefore, the consumer has overpaid. How can we (en)force the provider to pay the penalty. Or, if they do not, instantiate a legal
process?
Aspect 1: How architecturally can legal issues be supported? Use of a trusted entity to provide a “legal foundation”? Digitally signing and counter signing a SLA. What constitutes a legal document in this context?
Aspect 2: Conceptual issues surrounding the legal enforcement of SLAs How long should an SLA be stored after it is complete
E.g. for dispute resolution Legal issues associated with payment types: (i) before use; (ii) after use; (iii)
either – each option has different legal stipulations E.g. Ensuring that a consumer pays in cases (ii) and (iii)
Which legal directives (e.g. European eCommerce directives) relate to an SLA when the participants are in different “Legal Zones” E.g. Consumer (US), Provider (Asia), Market (EU)
Issues of limited liability.
Questions…?