SAF-CloudProfile-WD

tastefallInternet and Web Development

Feb 2, 2013 (4 years and 8 months ago)

382 views

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.


Symptoms Automation Framework
(SAF) Cloud Profile

Working Draft 0
4

28

Nov

2011

Specification URIs:

This Version:

-

Previous Version:


[NA]

Latest Version:

-

Technical Committee:

OASIS Symptoms Automat
ion Framework (SAF)

TC

Chair(s):

Jeffrey Vaught, CA Inc

Stavros Isaiadis, Fujitsu Limited

Editor(s):


?


Declared XML Namespace(s):

http://docs.oasis
-
open.org/saf/ns/symptoms/2009/10


Ab
stract:

The Symptoms
Automation

Framework (SAF) is a generic framework for the analysis,
diagnosis, and prevention or treatment of conditions that can arise within a system. Due
to the generic nature of the framework, certain communities will want to furth
er
standardize/ constraint the framework to suit the specific needs of the domain. This
document specifies such constraints and guidelines for the application of SAF to the
domain of cloud management

and business alignment between cloud consumers and
provi
ders
.

Status:

This document was last revised or approved by the SAF TC on the above date. The level
of approval is also listed above. Check the “Latest Version” or “Latest Approved Version”
location noted above for possible later revisions of this document
.

Technical Committee members should send comments on this specification to the
Technical Committee’s email list. Others should send comments to the Technical
Committee by using the “Send A Comment” button on the Technical Committee’s web
page at
http://www.oasis
-
open.org/committees/
saf
/
.

For information on whether any patents have been disclosed that may be essential to
implementing this specification, and any offers of paten
t licensing terms, please refer to
This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

the Intellectual Property Rights section of the Technical Committee web page
(
http://www.oasis
-
open.org/committees/saf/ipr.php
.

The non
-
normative errata pa
ge for this specification is located at
http://www.oasis
-
open.org/committees/
saf
/
.

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

Notices

Copyright © OASIS® 2008
. All Rights Reserved.

All capitalized terms in the followin
g text have the meanings assigned to them in the OASIS
Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the
OASIS website.

This document and translations of it may be copied and furnished to others, and derivati
ve works
that comment on or otherwise explain it or assist in its implementation may be prepared, copied,
published, and distributed, in whole or in part, without restriction of any kind, provided that the
above copyright notice and this section are includ
ed on all such copies and derivative works.
However, this document itself may not be modified in any way, including by removing the
copyright notice or references to OASIS, except as needed for the purpose of developing any
document or deliverable produced

by an OASIS Technical Committee (in which case the rules
applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to
translate it into languages other than English.

The limited permissions granted above are perpetua
l and will not be revoked by OASIS or its
successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE U
SE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that
would neces
sarily be infringed by implementations of this OASIS Committee Specification or
OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to
grant patent licenses to such patent claims in a manner consistent with the IPR

Mode of the
OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of
ownership of any patent claims that would necessarily be infringed by implementations of thi
s
specification by a patent holder that is not willing to provide a license to such patent claims in a
manner consistent with the IPR Mode of the OASIS Technical Committee that produced this
specification. OASIS may include such claims on its website, but
disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the technology described in this
document or the extent

to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such rights. Information on
OASIS' procedures with respect to rights in any document or deliverable produced by a
n OASIS
Technical Committee can be found on the OASIS website. Copies of claims of rights made
available for publication and any assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the

use of such proprietary rights by
implementers or users of this OASIS Committee Specification or OASIS Standard, can be
obtained from the OASIS TC Administrator. OASIS makes no representation that any information
or list of intellectual property rights wi
ll at any time be complete, or that any claims in such list are,
in fact, Essential Claims.

The names "OASIS",
[insert specific trademarked names and abbreviations here]

are trademarks
of OASIS, the

owner and developer of this spec
ification, and should be used only to refer to the
organization and its official outputs. OASIS welcomes reference to, and implementation and use
of, specifications, while reserving the right to enforce its marks against misleading uses. Please
see
http://www.oasis
-
open.org/who/trademark.php

for above guidance.

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

1.

Introduction

1.1

Purpose

This document specifies guidelines and best practices for the application of the Symptoms
Automation

Framework (SAF)

to the domain of cloud management. The cloud profile defines
semantic extensions and constraints to the SAF specification, as well as domain specific XML
entities and schemas. A use case in the cloud management dom
ain is also provided separately
[RFC2119]
.


Similar profiles may be developed to serve different domains/communities wishing to utilize SAF
for management, diagnosis and/or treatment purposes. In such cases, it is expected that the
profiles follow the same format and outline f
or consistency and readability purposes.

1.2

Notations and Terminology

The key words
must
,
must not
,
required
,
shall
,
shall not
,
should
,
should not
,
recommended
,
may
,
and
optional

in this document are to be interpreted as described in
[RFC2119]


[Maybe we define the most important SAF terms here as well or reference the spec definitions]


1.3

Namespaces

The following namespaces are used in this document:

Prefix

Namespace

xsd

http://www.w3.org/2001/XMLSchema

sym

http://docs.oasis
-
open.org/symptoms/symptoms_v1


sycl

http://docs.oasis
-
open.org/symptoms/cloud_profile_v1


2.

Cloud Taxonomy

[
unique SAF aspects, maybe some adopted from NIST?
]


[
concisely
define symptoms in this domain: a
notification of either a status change, a new
condition in the system, new data on the same event channel, or ???
]


[
Define the role in the cloud that we are enabling with this profile, e.g. provider, developer,
user...
]

3.

Profile Overview

[This section shou
ld define the general objectives, scope, and requirements of the cloud profile.
This info should be derived from the supporting use case(s) and should be from that (higher level)
application perspective

as oppo
sed to the details in the next
section which
will be more technical
and centered on the symptoms spec]

3.1

Objectives

To extend the semantics of the original SAF specification; provide constraints; limit or provide
directions where options are available; and provide a set of

guidelines as to how to apply

SAF for
purposes of cloud
business alignment
.

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

3.2

Requirements

[
Point to the interoperability boun
daries addressed by the profile
]

3.3

Scope

All levels of cloud computing but focusing on the interactions between entities in different levels,
e.g. between a consu
mer and a PaaS provider, and how they can negotiate resources, contracts,
report issues and problems, etc.

3.4

Supported Use Cases

A number of use cases have been developed or adapted from relevant domains and SDOs, in an
effort to identify the key customer an
d provider requirements regarding interactions and Cloud
management. These use cases have focused on a) the more generic mapping between the high
level customer business requirements to the lower level provider operations (one of the core
motivators for SA
F), such as the Automated Provisioning of Resource use case
[ref]

and b) on
the interactions and requirements pertaining to a specific “business” function, such as Policy
management
[ref]
, contract management
[ref]
, energy and CO2 footprint management
[ref
]
, and
more.

4.

SAF

for
Cloud
Business Alignment

[
Some introductory text here???
]


In the Cloud domain, where outsourcing at least parts of a company’s infrastructure and/or
capabilities, it becomes imperative to provide a means for allowing the mutual unders
tanding and
collaboration between consumers and providers. Providers do not know their customer’s
businesses, and consumers do not know how their providers operate and manage their services.
SAF can be used in order to better align the high level business
requirements to lower level
provider operations, in a collaborative environment.
[more]

4.1

Use Cases

We envision that the Cloud providers will provide
generic
Protocols that can be used by the
consumers in order to link their requirements to Cloud operations
. Such Protocols can be
parameterized in nature, and could embed the means to “translate” from higher level
requirements to concrete infrastructure or service operations.


For example, an IaaS provider could contribute to the SAF Catalog a Protocol
templat
e
for
increasing the capacity of a VM server instance. Such Protocol could have a parameter which the
consumer would then fill out, to denote the percentage of increase in relation to the baseline or
existing status, the consumer would like to enforce, e.
g. “20% increase in VM server capacity”.
This high level parameter, which the consumer can understand, can then be “translated” within
the Protocol mechanics to more concrete actions, e.g. “
200MHz more powerful CPU and 1GB
more memory” or similar.

4.1.1

Consumer

driven decision support for Elasticity

Abstract
: Today, Cloud providers supply simple rules & actions for elastically
provisioning/deprovisioning machines.


Our first use case simply mimics those rules/actions but
allows the Consumer to pick the combinati
ons.


SAF is an ecosystem where Consumer and
Provider knowledge contributions are combined into a single decision support system.

Description
: An online pet store hosts its application on Cloud provided, load
-
balanced
machines.


SAF uses a combination Syn
dromes (supplied by Provider) to detect high/low cpu
This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

load, invoking Protocols (also supplied by the Consumer) to provision or deprovision machines
accordingly.

Provider contributes
:

-

Syndrome “CPUExtremes
-
HighSensitivity” which detects a symptom from a syst
ems
manager denoting average aggregate cpu load across all machines has exceeded 79%
or receded below 20%.

-

Syndrome “CPUExtremes
-
LowSensitivity” which detects the same as above, but
exceeded 89% or receded below 10%.

-

Protocol “Provision
-
10
-
Percent” which p
rovisions/deprovisions via CIMI an
increase/reduction of 10% capacity.


A minimum of 3 machines is maintained for
reductions.

-

Protocol “Provision
-
15
-
Percent”


same as above except 15%.

Consumer contributes
:

-

Linkage of Syndrome to Protocol, deciding on low

sensitivity and 10%
provisioning/deprovisioning.

Syndrome

Associated Protocol(s)

CPUExtremes
-
LowSensitivity

Provision
-
10
-
Percent

SAF diagnostian
: Can reside either at Consumer or Provider:

-

At Consumer


Provider must send Symptoms about cpu load back to

the consumer.

-

At Provider


All Symptoms stay within Provider.


4.1.1.2
DMTF
Cloud
Infrastructure Management Interface

The following is an example of a possible Protocol, utilizing
CIMI
:



<!

CIMI Protocol


<Protocol>


<ProtocolType>


<Uri>http://saf
.com/types/protocols/compute_provision_increase</Uri>


</ProtocolType>


<PrescriptionType>


<Uri>http://saf.com/types/prescriptions/compute_provision_increase</Uri>


</PrescriptionType>


<ProtocolName>Provision
Additional
VM
s
</ProtocolName>


<Descrip
tion>Provision additional virtual machines</Description>


<Effectiveness>Effective</Effectiveness>


<Risk>Moderate</Risk>


<Duration>
Moderate
</Duration>


<Function>
Preventative
</Function>


<Directive>


for $x in /Symptoms/Symptom


let $clien
t_id := $x/Subject


let $change_percentage := fn:number($x/Content/SalesProjection/PercentageIncrease)


return


<Details>


<ClientID>$client_id</ClientID>


<ChangePercentage>$change_percentage</ChangePercentage>



<Details>


</Directive>


<PotentialSyndromes />


<Process>

#ruby


# arguments:
$
client.id,
$
change.percentage

#

get current machines

get_response = RestClient.get(“
桴hp㨯⽳慦⹣潭Lcim
i/” + $client.id + “machines
”)

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

# response resembles below

#
<MachineCollection>

#









<uri>
http://saf.com/cimi/12345/machines</uri
>



















#










<name>mymachines</name>

#










<description>my machines</description>

#










<created>2011
-
10
-
04T11:28:00</created>

#










<machine href=”
桴h瀺p⽳慦⹣潭Lcimi⼱L㌴㔯R慣桩n支eym慣桩湥1
” />
=
=
=
=
@
=
=
=
=
=
=
=
=
=
=
<m慣桩湥⁨牥==

桴h瀺p⽳慦⹣潭Lcimi⼱L㌴㔯R慣桩n支eym慣桩湥O
” />
=
=
=
=
@
=
=
=
=
=
=
=
=
=
=
<machine href=”
桴h瀺p⽳慦⹣潭Lcimi⼱L㌴㔯R慣桩n支eym慣桩湥P
” />
=
=
=
=
@
=
=
=
=
=
=
=
=
=
=
<machine href=”
桴h瀺p⽳慦⹣潭Lcimi⼱L㌴㔯R慣桩n支eym慣桩湥4
” />
=
=
=
=
@
=
=
=
=
=
=
=
=
=
=
<operation rel=”add” href=”
桴瑰㨯⽳慦⹣潭⽣imi⼱㈳㐵⽭慣桩n

” />
=
@
<L䵡c桩湥C潬l散瑩潮[
=
=
⌠@摥瑥牭i湥=m扥r=⁡=摩ti潮慬慣桩湥s⁲e煵ir敤
=
$client_uri = “
桴h瀺p⽳慦⹣潭⽣imiL
” + $client.id + “machines”
=
A
m慣桩湥彣潵n琠t⁘m慴栨h潵湴⡲
敳灯湳支e慣桩湥䍯ll散瑩潮嬤xli敮t彵ri
崯z慣h
i湥
=
A
湥睟w慣桩湥彣潵湴n==
A
m慣桩n敟c潵湴nG
ㄠ1=
A
c桡湧攮e敲e敮t慧支eM〩
=
=
⌠@慤搠d潲攠o慰慣ity
=
摯d
=

扥gin
=
††=
扯dy==⁻
=
†††
<䵡chin敃e敡t放
=
††††
<n慭放mym慣桩湥uuuuuu<⽮Lm放
=
††††
<machineTemplate href=”
http://saf.com/cimi/” + $client.id +
“machineTemplates/LinuxTemplate
” />
=
†††
<⽍慣桩n敃e敡瑥[
=
††
}
=
††
RestClient.post(get_response/MachineCollection/operation[@rel=’add’]/@href, body)
=

敮e
=

A
湥睟w慣桩湥彣o畮琠=
=
A
湥w彭慣桩湥彣潵湴=
-
=
1
=
睨wl攠
A
湥睟w慣桩湥彣潵n琠t=‰
=

<Lmr潣敳s[†††††=
=
<⽐r潴ocol[
=
=
=
=
<!

An example Symptom
indicating 10 percent projected increase in sales
--
>

<Symptom>


<SymptomId>http://saf.com/symptoms/salesprojection/1</SymptomId>


<SymptomT
ype>


<Uri>http://saf.com/types/symptom/salesprojection</Uri>


</SymptomType>


<CreationDate>2011
-
10
-
24T13:10:05</CreationDate>


<Confidence>High</Confidence>


<Reporter>http://saf.com/reporters/salessensor
-
123</Reporter>


<Subject>http://saf.com/s
ubjects/client
-
12345</Subject>


<ExpirationDate />


<RelatedSymptoms />


<Incident />


<Content>


<SalesProjection>


<Region>Global</Region>


<PercentageIncrease>10</PercentageIncrease>


</SalesProjection>


</Content>

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

</Symptom>




<!

The diagnostician creates
this

Prescription (instance) from the Protocol and
participating Symptoms
--
>

<Prescription>



<PrescriptionId>http://saf.
com
/prescriptions/001</PrescriptionId>



<PrescriptionType>

http://saf.com/types/prescriptions/ comput
e_provision_increase

</PrescriptionType>



<ExpirationDate>2010
-
03
-
25
T
13:45</ExpirationDate>



<Arguments>




<
Details
>


<ClientID>http://saf.com/subjects/client
-
12345</ClientID>


<ChangePercentage>10</ChangePercentage>


</Details>


</Arg
uments>


<Process>


Same as above, in Protocol


</Process>


</Prescription>




<!

A Syndrome

which detects the projected sales increase is greater
-
equal to 10 percent,
and triggers the invocation of the above Prescription
--
>

<Syndrome>


<
SyndromeTy
pe
>


<Uri>
http://saf.com/types/syndrome/salesprojection
</Uri>


</SyndromeType>


<SyndromeName>
Detect Sales Increase
</SyndromeName>


<Description>


Detect projected sales increase and provision additional servers


</Description>


<Likelihood>
Comm
on
</Likelihood>


<Impact>
Moderate
</Impact>


<Urgency>
Moderate
</Urgency>


<Signature>


for $x in /Symptoms/Symptom


where


$x[SymptomType=” http://saf.com/types/symptom/salesprojection”
=
††††
慮a
=
†††
⑸⽃潮瑥湴npal敳mr潪散瑩潮⽐敲ee湴ng敉
湣r敡se‾=‱そ
=

<Lpi杮慴畲u[
=

<Ass潣i慴a摐r潴潣潬s[
=
††
<mr潴oc潬o敦敲敮e放
=
†††
<啲i[
桴h瀺p⽳慦⹣潭⽴yp敳⽰牯瑯Lols⽣潭灵瑥t灲pvisi潮_i湣r敡se
<⽕Li[
=
††
<Lmr潴潣潬o敦敲敮e放
=

<LAss潣i慴a摐ro瑯tols[
=
<⽓yn摲潭放
=
=
=
=
=
This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

4.1.2

Consumer driven decision support for

Elasticity, with consideration of
Consumer Business Activity

Abstract
: Extending Use Case #1, we extend support to include more complex rules which adjust
capacity based upon consumer leading indicators for sales trends.


SAF allows the Consumer to
contri
bute their decision nuances and combine with knowledge from the Provider into a single
catalog.

Description
: An online pet store hosts its application on Cloud provided, load
-
balanced
machines.


SAF uses a combination of Syndromes supplied by both Consumer

and Provider to
detect combinations of high/low cpu load and sales trends, invoking Protocols to provision or
deprovision machines accordingly.

Provider contributes
: Same as Use Case #1 above…

-

Syndrome “CPUExtremes
-
HighSensitivity” which detects a symptom

from a systems
manager denoting average aggregate cpu load across all machines has exceeded 79%
or receded below 20%.

-

Syndrome “CPUExtremes
-
LowSensitivity” which detects the same as above, but
exceeded 89% or receded below 10%.

-

Protocol “Provision
-
10
-
Perc
ent” which provisions/deprovisions via CIMI an
increase/reduction of 10% capacity.


A minimum of 3 machines is maintained for
reductions.

-

Protocol “Provision
-
15
-
Percent” which provisions via CIMI an increase of 15%
capacity.


Deprovisioning is still at 10%

with a minimum of 3 machines maintained for
reductions.

Consumer contributes
:

-

Syndrome “ProjectedSalesIncrease” which detects leading indicators that online sales
are expected to increase.

-

Protocol “Generate
-
Symptom
-
CPUExtremes” which generates a new Symp
tom indicating
that the Syndrome “CPUExtremes
-
*Sensitivity” was triggered.


This provides a
mechanism to decouple consumer & provider supplied syndromes.

-

Protocol “Generate
-
Symptom
-
SalesIncrease” which generates a new Symptom indicating
that the Syndrome “
ProjectedSalesIncrease” was triggered.

-

Syndrome “CPUExtremes
-
SalesIncrease” which detects that CPU is overloaded or
underloaded where sales demands could exacerbate the situation.

-

Syndrome “CPUExtremes
-
SalesFlat” which detects that CPU is overload or under
loaded
and where sales demands are unlikely to exacerbate.

-

Linkage of Syndrome to Protocol, deciding again on low sensitivity and 15% provisioning
where sales is projected to increase, 10% provisioning where sales is not projected to
increase.

Syndrome

Syn
drome
detects…
=
Ass潣i慴a搠
mr潴ocolEsF
=

=
䍐rbx瑲敭敳
-
䱯wpe湳itivity
=
䍰甠l潡搠d‸=%=
慮搠<‱〥
=
d敮敲慴e
-
pym灴潭
-
䍐rbx瑲敭敳
=

=
mr潪散瑥tpal敳䥮fr敡se
=
䱥慤in朠g湤ic慴ars=
f潲⁳慬敳⁩湣r敡s攮
=
d敮敲慴e
-
pym灴潭
-
p慬敳䥮fr敡se
=

=
䍐rbx瑲敭敳
-
p慬敳䥮fr敡se
=
pyn摲潭敳‣=…=
⌲=c畲uin朠
瑯t整桥r
=
mr潶ision
-

-
m敲e敮t
=

=
䍐rbx瑲敭敳
-
p慬敳cl慴
=
pyn摲潭敳‣=…=
乏q‣=
=
mr潶ision
-

-
m敲e敮t
=
SAF diagnostian
: Can reside either at Consumer or Provider:

-

At Consumer


Provider must send Symptoms about cpu load back to the consumer.

-

At Prov
ider


All Symptoms stay within Provider.



This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

5.

Interactions with other standards

[
thoughts:
eMIX? DMTF? OCCi? WS
-
Agreement? CEP stuff anyone?

]


In the domain of Protocol definition for Cloud management, we have explored and utilized the
OCCi
[ref]

and DMTF
[ref]

Cloud interfaces.




6.

References

[RFC2119]

S. Bradner,
Key words for use in RFCs to Indicate Requirement Levels
,
http://www.ietf.org/rfc/rfc2119.txt
, IETF RFC 2119, March 1997


[
XXX
]

??,

XXX

Use Cas
e
, [???], ???

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views of OASIS or the OASIS SA
F TC.

A.

Revision History


Revision

Date

Editor

Changes

0
1

11/01/2010

Stavros

Isaiadis

Initial draft, outline, abstract text,
some
initial
text

02

08/05/2010

Stavros Isaiadis

Added the introductory OASIS stuff and
disclaimer.

M
odifications to the t
ext (and comments) to
reflect the focus towards business alignment,
the new use cases we have, and the new
s
tructure
.

Added text in Section 4

and an OCCi
Prescription!

03

06/05/2010

Stavros Isaiadis

Added more
protocols

and sanitized / refined
text throug
hout the document

04

11/28/2011

Jeff Vaught

Added a single DMTF CIMI protocol (and
associated elements).