[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Use cases for Cloud Profile
|
See inline… From: Isaiadis, Stavros [mailto:stavros.isaiadis@baml.com]
Hi Jeff, As far as I can see, these use cases are sort of extensions to the work already in the cloud profile, i.e. for provisioning etc we will still use the same protocols, it’s just that now we have a
more elaborate background scenario, which I think is a good thing. The story is quite fluid and I don’t have any major objections. I will try to incorporate these into the cloud profile as per the structural changes we agreed last Monday. Jeff – Your right. It isn’t a major departure for the catalog xml, but would also include verbiage about catalog contributions. Without the extra verbiage,
I kept asking myself “why would someone use SAF?” A small comment: I would expect provider to provide the whole SAF “infrastructure” thus providing the Diagnostician as well, with exceptions only where consumers want to do more sophisticated or
specialized stuff. But I expect a default Diagnostician to always be available from the providers. Jeff – Agreed. I can lose the paragraph about where the SAF Diagnostician resides. Also, I didn’t quite get your comments about the CIMI Meter interface: if metering/management systems are already in place, and CIMI provides such an interface, surely we could exploit it in these
use cases in order to manage the monitoring needed for our system? E.g. enable/disable advanced monitoring depending on the SLA and/or on pay as you use when e.g. the consumer need more detailed monitoring during periods of high demand or resource constraints. Jeff – The problems with CIMI Meter (in context of our use cases) are: 1.
I don’t think you can Meter across a collection of machines (to see the aggregate avg cpu for example). 2.
Provider exposed metering (via CIMI) would allow the consumer to monitor machines, but how does that fit into our SAF use cases?
a.
Are we saying that a Prescription will call a CIMI Meter interface and generate new Symptoms as a result? That gets rather convoluted.
b.
Are we saying that a systems manager on the consumer will use the CIMI Meter interface and generate new Symptoms? That’s certainly possible,
but doesn’t really discuss CIMI Meter in the context of SAF. 3.
For Systems, basic, comprehensive metering tends to be “always on”. Granted, there are some types of (primarily application) metering that get
enabled only periodically so as to reduce performance impact, but CIMI Metering seems to be primarily about systems. Enabling advanced/detailed metering as the result of a triggered Syndrome seems contrived (just my opinion). I’ll crack on with the profile and upload today. Jeff – Great. I’ll add the catalog xml afterwards (before Monday’s call). Thanks, Stavros PS. Is there any particular reason we’re not having this discussion on the SAF mailing list?? Jeff – No reason... other than the list doesn’t always distribute. I’ve added. From: Vaught, Jeffrey A [mailto:Jeffrey.Vaught@ca.com]
Stavros, I took a couple steps backwards.
J After going through several renditions of the use cases (including the monitoring scenario), and deciding they weren’t quite right, I came up with the following proposals
below. I think we need to showcase the benefits of SAF, not just that we can interface with CIMI/OCCI.
The major benefit of SAF (in my opinion): Various parties can contribute to a decision support catalog. SAF is a differentiator in the Cloud as both consumers &
providers can collaborate to improve the decision making. To that end, what do you think about the following use cases: Use Case #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 combinations. 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 Syndromes (supplied by Provider) to detect high/low cpu 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 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-Percent” which provisions/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.
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. Use Case #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 contribute 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-Percent” 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 Symptom 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 underloaded 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.
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. Other notes…
-
At first glance, I thought the CIMI Meter interface/schema might be a good scenario to explore. For example, a Protocol might enable metering to collect additional diagnostics.
But, coming from a company whose primary business is to supply metering/management software, I realized much of the metering would already be in place.
No enterprise is going to provision machines w/o some kind of basic metering in place. Application metering might be the exception (where you enable more invasive techniques in cases where additional diagnostics are needed). But, CIMI is mostly about systems,
not applications.
-
I think we *might* want to explore the CIMI Job interface/schema. For example, a Protocol could invoke a backup/restore Job.
The problem – CIMI doesn’t define standard types of Jobs, only the interface (and generic attributes) by which to invoke. That won’t do a consumer much good when they switch providers, so doesn’t seem too useful. -jeff This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential
or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained
in or attached to this message is prohibited. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]