SAF-CloudProfile-WD

jockeyropeInternet και Εφαρμογές Web

2 Φεβ 2013 (πριν από 4 χρόνια και 9 μήνες)

315 εμφανίσεις

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 SAF TC.


Symptoms Automation Framework
(SAF) Cloud Profile

Working Draft
0
8

1
2

Mar

2012

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 SAF 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 SAF 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 SAF TC.

1.

Introduction

1.1

Purpose

This document specifies guidelines for the application of the Symptoms
Automation

Framework
(SAF) to the domain of c
loud management

and specifically utilizing the Distributed Management
Task Force (DMTF) Cloud Management Working Group (CMWG) Interface
[
CMWG
]
.

It serves as
a primer for anyone wishing to use SAF to facilitate collaboration between cloud consumers and
clo
ud providers, and automate cloud management operations.

As a primer, it has been kept
intentionally simple

in terms of the use cases demonstrated.


Similar profiles may be developed to serve different domains/communities wishing to utilize SAF
for manageme
nt, diagnosis and/or treatment purposes. In such cases, it is expected that the
profiles follow the same format and outline for 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 names
paces 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_p
rofile_v1



2.

Definitions

The
re

are two main roles in this profile: the Cloud consumer and the Cloud provider. A
Cloud
provider

is an Infrastructure as a Service (IaaS) solution provider that further exposes
management interfaces adhering to the DMTF CMWG s
tandard
.


A
Cloud consumer

is any individual or company wishing to host one or more applications into a
cloud solution provided by a Cloud provider. The consumer will use the CMWG interface to
manage the virtual instances allocated to his applicatio
n(s), e.g. add more storage, request a new
or update an existing machine, etc.


In addition, both the Cloud consumer and provider will adopt the SAF role of Catalogue Author for
the purposes of this profile, i.e. they will both contribute Syndrome and Prot
ocol definitions to a
common Catalogue instance,
typically to be

provided by the Cloud Provider
, e.g. as part of a
more complete Cloud solution

(although systems with more than one Catalogues are certainly an
option).


Both of them will a
lso adopt the roles of Symptom Sources, since Symptoms originating from both
the Provider’s infrastructure monitoring components, and in response to the Consumer’s business
indicators, will
typically
flow through the system.

This flow of Symptoms from diff
erent sources is
what enables SAF to act as a collaboration facilitator between the consumer and 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 SAF TC.




3.

Use Cases

The
significant migration to t
he Cloud

that has taken place for
a large number of
businesses over
the last few years, has
resulted in a
disconnect between providers and consumers. Where these
would typically have a strong relationship and a good understanding of business requirement
s
and technical challenges,
i
n the Cloud

this is no longer the case, owing to the on demand and
contract
-
less
p
atterns

of usage and billing
.

Providers do not know their customer’s businesses,
and consumers do not necessarily know the technicalities of how providers operat
e and manage
their services.
I
t

has therefore

become

imperative to provide a means for allowing the mutual
understanding and collaboration between consumers and providers

towards a much improved
level of collaboration and the extension of the Cloud delive
ry model to domains and business
functions that do not lend themselves very well to the current model
.
SAF can be used to better
align the high level business requirements to
lower
-
level provider operations, in a collaborative
environment.


We envision Cloud providers
supplying

Protocols that can be used by the consumers in order to
link the
ir requirements

to
c
loud operations such as the provisioning/deprovisioning of cloud
resources via CIMI

[
CIMI
]
. In addition,
both providers and consumers
would typically contribute
s
yndromes that define the criteria for invoking s
uch
protocols: consumers providing the
syndromes related to their specific business activities, and providers supplying the syndromes
related to the systems they manage. Together, these
contributions

will

form

the

basis for
cooperative d
ecision making

within the SAF framework


In the sections below, we outline two use cases for consumer driven decision support. The first is
almost exclusively provider supplied, with the SAF elements of syndrome and protocol being
contributed by the clou
d provider. The second use case expands on the first, including a
syndrome contributed by the consumer.



3.1

Consumer driven decision support for Elasticity

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

m
achines.


Our first use case mimics those rules/actions but allows
the Consumer to pick the
most appropriate
combinati
on

of rules/actions for their business
.


SAF
,
as
an ecosystem where Consumer and Provider knowledge contributions are combined into a

sin
gle decision support system, facilitates those Consumer choices.


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


SAF uses a combination

of

Syndromes (supplied by Provider) to detect high/low cpu
load, invokin
g Protocols (also supplied by the
Provider
) to provision machines accordingly.


The provider will contribute two Syndromes which detect symptoms reporting cpu load of greater
than 90% and 95% respectively. The provider will also contribute two preventati
ve Protocols
which will provision additional hardware in an attempt to lessen the cpu burden on existing
machines. The two Protocols will provision an additional 10% and 5% respectively.


The provider will leave it to the consumer to determine how these
Syndromes and Protocols are
linked together. For example, the consumer may decide to associate a more conservative
protocol, provisioning only 5% additional resources, with a more sensitive syndrome, detecting
when cpu load exceedes 90%. Another possibil
ity, not fully explored in this document, is to
associate both protocols to each syndrome, allowing the diagnostician to sort out the best choice
of protocol based upon guidance provided in the syndrome and protocol definitions.


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 SAF TC.

3.1.1

Provider Contributed
Proto
col
: Provision
-
10
-
Percent

Protocol represents the “action definition” portion of the rule/action equation. In our scenario, the
Provision
-
10
-
Percent protocol is a definition describing the process by which an additional 10
percent of machines are provisio
ned (or deprovisioned) and which elements of the triggering
symptoms are passed as parameters. In addition, the protocol provides guidance to the
diagnostician about the risk/reward of invoking such an action, such that it can choose one
protocol over ano
ther.

<Protocol>


The first four elements uniquely identify the protocol and its constituent prescription
instances.


ProtocolType uniquely identifies the type of protocol

<ProtocolType>

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

</Prot
ocolType>


PrescriptionType uniquely identifies the type of the prescription instances generated
,

typically by the Diagnostician
, baring the ProtocolType

<PrescriptionType>

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

</PrescriptionTy
pe>


ProtocolName is a descriptive name for the protocol

<ProtocolName>Provision
-
10
-
Percent</ProtocolName>


Description provides a more verbose explanation for the protocol

<Description>Provision or DeProvision virtual machines</Description>


The next four

elements relate to guidance that can be used by the diagnostician

to
best

choose the most appropriate protocol.
For example, if the diagnostician understands the
triggering conditions to be
of high urgency, it can select a protocol with the appropriate
d
uration such that the situation is attended to sooner rather than later.


Effectiveness is a measure of the expected success of the protocol.

<Effectiveness>Effective</Effectiveness>


Risk
is a measure of the expected or unexpected side effects of invoki
ng this protocol.

<Risk>Moderate</Risk>


Duration is a measure of the length of time to complete the protocol.

<Duration>Moderate</Duration>


Function describes whether the protocol is diagnostic, preventative, or remedial in nature.

<Function>Preventative
</Function>


The final two elements in this example define the process instructions and a means to
extract parameters to that process from the set of triggering symptoms.


Directive is an xquery expression used to
set/
derive/extract parameters from the set

of
triggering symptoms. The triggering symptoms are the set whic
h match our syndrome
signature (see section
x.x.x.x
).

In our scenario, we
do all three


set, derive, and extract. We directly set the change
percentage parameter to 10. We
derive a “pro
vision”

parameter

by asserting to true if
cpu load is greater than
50 percent, and asserting to false if cpu load is less/equal than
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 SAF TC.

50 percent. And finally, we extract the client id parameter from the subject element of the
triggering symptom(s).

The e
xpression ultimately returns an xml document containing the parameters

within a
single enclosing element
. The

diagnostician
will
extract these parameters from the
resulting xml document and provide them as parameters to the process of the
prescription.

<D
irective>

let $client_id := /Symptoms/Symptom/Subject

let $change_percentage := 10

let $provision := true

if (/Symptoms/Symptom/Content/AggregateCpu/AverageLoad >
50
) then (


$provision := true

)

else (


$provision := false

)

return

<Details>



<ClientID>$client_id</ClientID>


<ChangePercentage>$change_percentage</ChangePercentage>


<Provision>$provision</Provision>

</Details>

</Directive>


Process is an implementation specific set of workflow instructions that are executed by
the pre
scriptive instance of the protocol.

The values extracted via the directive are
supplied as parameters to the process.

In our scenario we use the Ruby language as the means for defining process instructions

that leverage the CIMI standard
. The arguments fo
r ClientID, ChangePercentage, and
Provision are passed as parameters to the Ruby script.

<Process>


Using Ruby scripting language below, and passing arguments for:

$ClientID, $ChangePercentage, and $Provision


First, we get the
list of
current machines

by

calling

CIMI “get” against
clientid/machines url.

get_response = RestClient.get(“
http://saf.com/cimi/” + $
ClientID + “/machines
”)


The http response resembles the xml below:

<MachineCollec
tion>










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





























<name>mymachines</name>











<description>my machines</description>











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











<machine href=”
http://saf.com/cimi/12345/machine/mymachine1
” />














<machine href=”
http://saf.com/cimi/12
345/machine/mymachine2
” />














<machine href=”
http://saf.com/cimi/12345/machine/mymachine3
” />














<machine href=”
ht
tp://saf.com/cimi/12345/machine/mymachine4
” />














<operation rel=”add” href=”
http://saf.com/cimi/12345/machines
” />

</MachineCollection>


Next, we get a count of those current machines by runni
ng an xpath “count”
function against the response. The count is then increased by the
$ChangePercentage parameter.

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 SAF TC.

$client_uri = “
http://saf.com/cimi/
” + $ClientID + “
/
machines”

$machine_count =
XPath(count(
$
get_
respon
se/MachineCollection[$client_uri]/machine

$new_machine_count = $machine_count * (1 + $ChangePercentage)


For each new machine…

do


begin


We form the CIMI request for MachineCreate, using a template.


body = {


<MachineCreate>


<name>m
ymachineXXXXXX</name>


<machineTemplate href=”
http://saf.com/cim
i/” + $ClientID +
“/machineTemplates/LinuxTemplate
” />


</MachineCreate>


}




And then invoke the CIMI MachineCollection “add” operation to pro
vision the
machine.


if ($Provision == true)


RestClient.post(get_response/MachineCollection/operation[@rel=’add’]/@href,
body)


else


(


Deprovisioning is beyond the scope of this document.


)



end


$new_machine_count = $new_machi
ne_count
-

1

while $new_machine_count >= 0



</Process>


</Protocol>


3.1.2

Provider Contributed
Protocol
: Provision
-
5
-
Percent

This protocol is very similar to the former, except we will provision an additional 5 percent rather
than 10 percent.


<Pro
tocol>


The first four elements uniquely identify the protocol and its constituent prescription
instances.


ProtocolType uniquely identifies the type of protocol

<ProtocolType>

<Uri>http://saf.com/types/protocols/compute_provision_
5
</Uri>

</ProtocolType>


PrescriptionType uniquely identifies the type of the prescription instances generated,
typically by the Diagnostician, baring the ProtocolType

<PrescriptionType>

<Uri>http://saf.com/types/prescriptions/compute_provision_
5
</Uri>

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 SAF TC.

</PrescriptionType>


Protoco
lName is a descriptive name for the protocol

<ProtocolName>Provision
-
5
-
Percent</ProtocolName>


Description provides a more verbose explanation for the protocol

<Description>Provision or DeProvision virtual machines</Description>


The next four elements rel
ate to guidance that can be used by the diagnostician to best
choose the most appropriate protocol. For example, if the diagnostician understands the
triggering conditions to be of high urgency, it can select a protocol with the appropriate
duration such
that the situation is attended to sooner rather than later.


Effectiveness is a measure of the expected success of the protocol.

<Effectiveness>Effective</Effectiveness>


Risk is a measure of the expected or unexpected side effects of invoking this proto
col.

<Risk>Moderate</Risk>


Duration is a measure of the length of time to complete the protocol.

<Duration>Moderate</Duration>


Function describes whether the protocol is diagnostic, preventative, or remedial in nature.

<Function>Preventative</Function>


The final two elements in this example define the process instructions and a means to
extract parameters to that process from the set of triggering symptoms.


Directive is an xquery expression used to set/derive/extract parameters from the set of
triggerin
g symptoms. The triggering symptoms are the set which match our syndrome
signature (see section x.x.x.x).

In our scenario, we do all three


set, derive, and extract. We directly set the change
percentage parameter to 5. We derive a “provision” parame
ter by asserting to true if cpu
load is greater than 50 percent, and asserting to false if cpu load is less/equal than 50
percent. And finally, we extract the client id parameter from the subject element of the
triggering symptom(s).

The expression ulti
mately returns an xml document containing the parameters within a
single enclosing element. The diagnostician will extract these parameters from the
resulting xml document and provide them as parameters to the process of the
prescription.

<Directive>

let
$client_id := /Symptoms/Symptom/Subject

let $change_percentage :=
5

let $provision := true

if (/Symptoms/Symptom/Content/AggregateCpu/AverageLoad >
50
) then (


$provision := true

)

else (


$provision := false

)

return

<Details>


<ClientID>$cl
ient_id</ClientID>


<ChangePercentage>$change_percentage</ChangePercentage>


<Provision>$provision</Provision>

</Details>

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 SAF TC.

</Directive>


Process is an implementation specific set of workflow instructions that are executed by
the prescriptive insta
nce of the protocol. The values extracted via the directive are
supplied as parameters to the process.

In our scenario we use the Ruby language as the means for defining process instructions
that leverage the CIMI standard. The arguments for ClientID, Cha
ngePercentage, and
Provision are passed as parameters to the Ruby script.

<Process>

This element is identical to the prior protocol’s process element and is not
repeated here.

</Process>


</Protocol>


3.1.3

Provider contributed
Syndrome
:
CPUExtremes
-
LowSensitivity

Syndrome represents the “rule definition” portion of the rule/action equation. In our scenario, the
CPUExtremes
-
LowSensitivity syndrome describes the pattern of symptoms where cpu load
exceeds 95 percent of maximum.


<Syndrome>


The first

three elements uniquely identify the syndrome.


SyndromeType uniquely identifies the type of syndrome.

<SyndromeType>


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

</SyndromeType>


SyndromeName is a descriptive name for the syndrome.

<SyndromeName>
CPUExtremes
-
LowSensitivity</SyndromeName>


Description is a verbose explanation of the syndrome.

<Description>


Detect when cpu load has exceeded a threshold and provision additional servers

</Description>


The next three elements relate to guidance tha
t can be used by the diagnostician to best
choose the most appropriate protocol. For example, the diagnostician could favor less
“risky” protocols when the syndrome Impact is VeryLow. Similarly, a syndrome
Likelihood of Rare may not illicit enough confid
ence to invoke a “risky” protocol.


Likelihood is a measure of typicality of the syndrome.

<Likelihood>Common</Likelihood>

Impact is a measure of the consequences of this syndrome if not treated.

<Impact>Moderate</Impact>


Urgency is a measure of the speed

and tenacity with which this syndrome should receive
attention.

<Urgency>Moderate</Urgency>


Signature is an xquery expression specifying

the criteria for recognizing a pattern of
symptoms defined by this syndrome.

The resulting document is the set of mat
ching
symptoms.

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 SAF TC.

In our scenario, the xquery enumerates through all of the symptoms in the store,
matching those with a particular symptom type (eg. aggregate_cpu) and an average cpu
load of greater/equal than 9
5

percent.

<Signature>


for $x in /Symptoms
/Symptom


where


$x[SymptomType=” http://saf.com/types/symptom/aggregate_cpu”


and


$x/Content/AggregateCPU/AverageLoad >= 9
5
]

</Signature>


AssociatedProtocols references a list of protocols that can potentially be invoked as a
result

of this syndrome being activated. The diagnostician will choose the most
appropriate protocol from this list based upon the guidance included in both the
syndrome and protocol definitions. In our scenario, the provider has purposely

left this
element bl
ank, leaving it up to the consumer to identify the protocols that could be
potentially invoked.

<AssociatedProtocols />


</Syndrome>


3.1.4

Provider contributed
Syndrome
:
CPUExtremes
-
HighSensitivity

This HighSensitivity syndrome is quite similar to the prior Low
Sensitivity syndrome, only it adjusts
the signature to detect symptoms where the cpu load exceeds 90% of maximum rather than 95%
of maximum. In this way, the syndrome is more sensitive to the changes in cpu.


<Syndrome>


The first three elements uniquely
identify the syndrome.


SyndromeType uniquely identifies the type of syndrome.

<SyndromeType>


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

</SyndromeType>


SyndromeName is a descriptive name for the syndrome.

<SyndromeName>CPUExtremes
-
High
Sensitivi
ty</SyndromeName>


Description is a verbose explanation of the syndrome.

<Description>


Detect when cpu load has exceeded a threshold and provision additional servers

</Description>


The next three elements relate to guidance that can be used by the dia
gnostician to best
choose the most appropriate protocol. For example, the diagnostician could favor less
“risky” protocols when the syndrome Impact is VeryLow. Similarly, a syndrome
Likelihood of Rare may not illicit enough confidence to invoke a “risky”

protocol.


Likelihood is a measure of typicality of the syndrome.

<Likelihood>Common</Likelihood>

Impact is a measure of the consequences of this syndrome if not treated.

<Impact>Moderate</Impact>


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 SAF TC.

Urgency is a measure of the speed and tenacity with which

this syndrome should receive
attention.

<Urgency>Moderate</Urgency>


Signature is an xquery expression specifying the criteria for recognizing a pattern of
symptoms defined by this syndrome. The resulting document is the set of matching
symptoms.

In our s
cenario, the xquery enumerates through all of the symptoms in the store,
matching those with a particular symptom type (eg. aggregate_cpu) and an average cpu
load of greater/equal than 90 percent.

<Signature>


for $x in /Symptoms/Symptom


where



$x[SymptomType=” http://saf.com/types/symptom/aggregate_cpu”


and


$x/Content/AggregateCPU/AverageLoad >= 90]

</Signature>


AssociatedProtocols references a list of protocols that can potentially be invoked as a
result of this syndrome being
activated. The diagnostician will choose the most
appropriate protocol from this list based upon the guidance included in both the
syndrome and protocol definitions. In our scenario, the provider has purposely left this
element blank, leaving it up to th
e consumer to identify the protocols that could be
potentially invoked.

<AssociatedProtocols />


</Syndrome>


3.1.5

Consumer Contributed
Syndrome
:
AssociatedProtocols

In our case, the consumer won’t actually contribute a new syndrome, but rather modify one of th
e
provider supplied syndromes


the CPUExtremes
-
LowSensitivity syndrome. We won’t replicate
the entire syndrome again, only displaying the relevant changes to the AssociatedProtocols
element.


<Syndrome>

This syndrome has already been defined above
--

th
e CPUExtremes
-
LowSensitivity
syndrome contributed by the provider.




AssociatedProtocols references a list of protocols that can potentially be invoked as a
result of this syndrome being activated. The diagnostician will choose the most
appropriate proto
col from this list based upon the guidance included in both the
syndrome and protocol definitions. In our scenario, the consumer will populate this
element with a single protocol, admittedly making the decision trivial for the diagnostician.

<AssociatedPr
otocols>


<ProtocolReference>


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


</ProtocolReference>

</AssociatedProtocols>


</Syndrome>


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 SAF TC.

3.1.6

Runtime Elements:
Symptom

Symptoms are typically emitted by some
domain manager such as
sy
stem, network, application,
or other. In our scenario, the symptoms originate from a systems manager which detects cpu
utilization on servers.

The xml below is one such example of a symptom.


<Symptom>


SymptomId uniquely defines the symptom in time.

.
<S
ymptomId>http://saf.com/symptoms/aggregate_cpu/12345/machines/1</SymptomId>


SymptomType defines the semantics of the symptom. In our scenario, the systems
manager symptom emitter could emit several symptoms related to cpu utilization, each
with a differe
nt SymptomId and variations in the AggregateCpu numbers. All would still
maintain the same SymptomType.

<SymptomType>


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

</SymptomType>


CreationDate is the date/time in xml schema xs:dateTime format
when the symptom was
created.

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


Confidence is a measure of how assured the symptom emitter is with respect to the
accuracy of this symptom.

<Confidence>High</Confidence>


Reported is the identity of the sympt
om emitter.

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


Subject is the identity of resource exhibiting the symptom. In our scenario, this is the
reference to the IT service supporting our online sales.

<Subject>http://saf.com/subjec
ts/

service
-
12345
</Subject>


Content
contains any embedded xml specific to the symptom type.

In our scenario, the
Content contains information about the aggregate cpu utilization at a point in time.

Note
that our syndrome signature and protocol directive

both consider the AverageLoad value
embedded within the Content of these symptom types.

<Content>


<AggregateCpu >


<MachineCollectionID>12345/machines</MachineCollectionID>


<AverageLoad>85</AverageLoad>


<MaxLoad>98</MaxLoad>



<MinLoad>05</MinLoad>


<InstantaneousLoad>72</InstantaneousLoad>


</AggregateCpu>

</Content>


</Symptom>



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 SAF TC.

3.1.7

Runtime Elements:
Prescription

Prescriptions are runtime elements which define the instructions and workflow necessary for the
Practition
er to remediate, prevent, or diagnose
a condition. Prescriptions are usually derived
from Protocols. The xml below is one such example of a prescription.


<Prescription>



PrescriptionId uniquely defines the prescription in time.

<PrescriptionId>http://sa
f.com/prescriptions/001</PrescriptionId>



PrescriptionType defines the semantics of the prescription, and is usually defined in a
corresponding Protocol. In our scenario, multiple prescriptions, each with a unique
PrescriptionId, to provision additional
resources could be instantiated by the diagnostician
in cases where the demand for compute resources massively spiked. All would still
maintain the same PrescriptionType.

<PrescriptionType>


http://saf.com/types/prescriptions/ compute_provision_10

</
PrescriptionType>



ExpirationDate is the date beyond which the prescription is obsolete.

The diagnostician
could derive this value from some of the protocol guidance, such as “duration”.

<ExpirationDate>2010
-
03
-
25T13:45</ExpirationDate>



Arguments

consis
t of embedded xml which defines the parameters required by the
Process script. The diagnostician derives the arguments by applying the protocol
directive against matching symptoms (which, in turn, are the result of the syndrome
signature applied against a
ll possible symptoms in the symptom store).

<Arguments>




<Details>




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


<ChangePercentage>10</ChangePercentage>


<Provision>true</Provision>


</Details>

</Arguments>



Process is

a direct copy of the process in the corresponding protocol, and supplies the
execution instructions/workflow necessary to remediate, prevent, or diagnose a condition.

<Process>


Same as defined in our corresponding
Protocol
.

</Process>



</Prescripti
on>





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 SAF TC.

3.2

Consumer driven decision support for Elasticity
, with consideration of
Consumer Business Activity

Abstract
:

Extending
our first u
se
c
ase, we extend support to include more complex rules which
adjust capacity based upon consumer leading indicators

for sales trends.


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


Description
: An online 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.


The provider contributions are identical to the first use c
ase. The consumer additionally
contributes a modified copy of the provider “CPUExtremes
-
LowSensitivity” syndrome which, in
addition to detecting cpu load on machines, will also detect
leading online sales indicators.


3.2.1

Consumer

contributed
Syndrome
: CPUExt
remes
-
SalesIncrease

Syndrome represents the “rule definition” portion of the rule/action equation. In our scenario, the
CPUExtremes
-
SalesIncrease

syndrome describes the pattern of symptoms where cpu load
equals or
exceeds 9
5

percent of max
imum
and

sales p
rojections equal or exceed 10 percent.


This syndrome is nearly identical to the provider contributed CPUExtremes
-
LowSensitivity, but
with a few minor modifications to account for sales increases. We’ve highlighted those
modifications.


<Syndrome>


The
f
irst three elements uniquely identify the syndrome.


SyndromeType uniquely identifies the type of syndrome.

<SyndromeType>


<Uri>http://saf.com/types/syndrome/
combination/cpuload
-
salesincrease
</Uri>

</SyndromeType>


SyndromeName is a descriptive name fo
r the syndrome.

<SyndromeName>CPUExtremes
-
SalesIncrease
</SyndromeName>


Description is a verbose explanation of the syndrome.

<Description>


Detect when cpu load has exceeded a threshold

and sales projections have increased
beyond a threshold,

and provi
sion additional servers

</Description>


The next three elements relate to guidance that can be used by the diagnostician to best
choose the most appropriate protocol. For example, the diagnostician could favor less
“risky” protocols when the syndrome Impa
ct is VeryLow. Similarly, a syndrome
Likelihood of Rare may not illicit enough confidence to invoke a “risky” protocol.


Likelihood is a measure of typicality of the syndrome.

<Likelihood>Common</Likelihood>

Impact is a measure of the consequences of this

syndrome if not treated.

<Impact>Moderate</Impact>


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 SAF TC.

Urgency is a measure of the speed and tenacity with which this syndrome should receive
attention.

<Urgency>Moderate</Urgency>


Signature is an xquery expression specifying the criteria for recognizing a
pattern of
symptoms defined by this syndrome. The resulting document is the set of matching
symptoms.

In our scenario, the xquer
y enumerates through all
“pair combinations” of
symptoms in
the store, matching those
combinations consisting of high cpu load s
ymptom and an
increased sales projection symptom. Typically, a time proximity between the pairs of
symptoms would also be defined, but for the purposes of xquery simplification we have
left that out.

<Signature>

for $x in /Symptoms/Symptom

for $y in /Sym
ptoms/Symptom

where

$x[SymptomType=” http://saf.com/types/symptom/aggregate_cpu”

and

$x/Content/AggregateCPU/AverageLoad >= 9
0
]




and



$y[SymptomType=
http://saf.com/types/symptom/salesprojection

and

$y/Content/SalesProjection/PercentIncrease >= 10]

</Signature>


AssociatedProtocols references a list of protocols that can potentially be invoked as a
result of this syndrome being activated. The diagnos
tician will choose the most
appropriate protocol from this list based upon the guidance included in both the
syndrome and protocol definitions. In our scenario, the consumer will populate this
element with a single protocol, admittedly making the decision

trivial for the diagnostician.

<AssociatedProtocols>


<ProtocolReference>


<Uri>http://saf.com/types/protocols/compute_provision
_5
</Uri>


</ProtocolReference>

</AssociatedProtocols>


</Syndrome>


3.2.2

Runtime Elements:
Symptom

for High Cpu Utiliza
tion

Symptoms are typically emitted by some domain manager such as system, network, application,
or other. In our scenario, oneo of the symptoms originate from a systems manager which detects
cpu utilization on servers and sales projection increases. The

xml below is one such example of
a symptom.


<Symptom>


SymptomId uniquely defines the symptom in time.

.
<SymptomId>http://saf.com/symptoms/aggregate_cpu/12345/machines/1</SymptomId>


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 SAF TC.

SymptomType defines the semantics of the symptom. In our scenario, the

systems
manager symptom emitter could emit several symptoms related to cpu utilization, each
with a different SymptomId and variations in the AggregateCpu numbers. All would still
maintain the same SymptomType.

<SymptomType>


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

</SymptomType>


CreationDate is the date/time in xml schema xs:dateTime format when the symptom was
created.

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


Confidence is a measure of how assured the symptom emitter is with r
espect to the
accuracy of this symptom.

<Confidence>High</Confidence>


Reported is the identity of the symptom emitter.

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


Subject is the identity of resource exhibiting the symptom. In our s
cenario, this is the
reference to the IT service supporting our online sales.

<Subject>http://saf.com/subjects/

service
-
12345
</Subject>


Content contains any embedded xml specific to the symptom type. In our scenario, the
Content contains information abou
t the aggregate cpu utilization at a point in time. Note
that our syndrome signature and protocol directive both consider the AverageLoad value
embedded within the Content of these symptom types.

<Content>


<AggregateCpu >


<MachineCollectionID>
12345/machines</MachineCollectionID>


<AverageLoad>85</AverageLoad>


<MaxLoad>98</MaxLoad>


<MinLoad>05</MinLoad>


<InstantaneousLoad>72</InstantaneousLoad>


</AggregateCpu>

</Content>


</Symptom>



3.2.3

Runtime Elements:
Symptom

for

High Projected Sales Increase

Symptoms are typically emitted by some domain manager such as system, network, application,
or other. In our scenario, one of the symptoms originate from a sales and marketing application
which alerts on high projected sales

increases. The xml below is one such example of a symptom.


<Symptom>


SymptomId uniquely defines the symptom in time.

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


SymptomType defines the semantics of the symptom. In our scenario, t
he
sales/marketing application

s
ymptom emitter could emit several symptoms related to
sales projections
, each with a different SymptomId and variations in the
projection

numbers. All would still maintain the same SymptomType.

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 SAF TC.

<SymptomType>


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

</SymptomType>


CreationDate is the date/time in xml schema xs:dateTime format when the symptom was
created.

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


Confidence is a measure of how assured the symptom e
mitter is with respect to the
accuracy of this symptom.

<Confidence>High</Confidence>


Reported is the identity of the symptom emitter.

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

</Reporter>


Subject is the identity of resource exhibiting the symp
tom.
In our scenario, this is the
reference to the IT service supporting our online sales
.

<Subject>http://saf.com/subjects/

service
-
12345
</Subject>


Content contains any embedded xml specific to the symptom type. In our scenario, the
Content contains in
formation about the aggregate cpu utilization at a point in time. Note
that our syndrome signature and protocol directive both consider the AverageLoad value
embedded within the Content of these symptom types.

<Content>


<SalesProjection>


<Regi
on>Global</Region>


<PercentageIncrease>10</PercentageIncrease>


</SalesProjection>

</Content>


</Symptom>


3.2.4

Runtime Elements:
Prescription

Prescriptions are runtime elements which define the instructions and workflow necessary for the
Practitione
r to remediate, prevent, or diagnose a condition. Prescriptions are usually derived
from Protocols. The xml below is one such example of a prescription.


<Prescription>



PrescriptionId uniquely defines the prescription in time.

<PrescriptionId>http://saf
.com/prescriptions/00
2
</PrescriptionId>



PrescriptionType defines the semantics of the prescription, and is usually defined in a
corresponding Protocol. In our scenario, multiple prescriptions, each with a unique
PrescriptionId, to provision additional r
esources could be instantiated by the diagnostician
in cases where the demand for compute resources massively spiked. All would still
maintain the same PrescriptionType.

<PrescriptionType>


http://saf.com/types/prescriptions/ compute_provision_
5

</Pr
escriptionType>



ExpirationDate is the date beyond which the prescription is obsolete. The diagnostician
could derive this value from some of the protocol guidance, such as “duration”.

<ExpirationDate>2010
-
03
-
25T13:45</ExpirationDate>


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 SAF TC.


Arguments consist
of embedded xml which defines the parameters required by the
Process script. The diagnostician derives the arguments by applying the protocol
directive against matching symptoms (which, in turn, are the result of the syndrome
signature applied against all

possible symptoms in the symptom store).

<Arguments>




<Details>




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


<ChangePercentage>
5
</ChangePercentage>


<Provision>true</Provision>


</Details>

</Arguments>



Process is a
direct copy of the process in the corresponding protocol, and supplies the
execution instructions/workflow necessary to remediate, prevent, or diagnose a condition.

<Process>


Same as defined in our corresponding
Protocol
.

</Process>



</Prescription>



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 SAF TC.




4.

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


[CMWG]

Cloud Management Working Group
,
http://dmtf.org/standards/cloud


[
CIMI
]

Cloud
Infrastructure
Management
Interface
,
http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.0a.p
df

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 SAF TC.

A.

Revision History


Revision

Date

Editor

Ch
anges

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 text (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 throughout the document

04

11/28/2011

Jeff Vaught

Added a sin
gle DMTF CIMI protocol (and
associated elements).

05

15/12/2011

Stavros Isaiadis

Cleaned up a bit and re
-
structured as per our
latest discussions. Added some text in the
definitions sections.

06

12/20/2011

Jeff Vaught

Modified two use cases extensively f
or
simplification and clarity.

07

02/06/2012

Jeff Vaught

Comments on Section 3 for review by TC.

08

03/12/2012

Stavros Isaiadis

Added references; small improvements to the
main text