[occi-wg] Extraction of requirements

Thu Apr 30 08:24:12 CDT 2009

Ah excellent, good thing we have the elastichosts guys on board too!
Would be interesting to hear from either Richard or Chris does it add value to be able to declare vertical scaling rules a priori as well as having the ability to change parameters at runtime - another valuable piece of functionality in any IaaS interface.

Andy

-----Original Message-----
From: Ignacio Martin Llorente [mailto:llorente at dacya.ucm.es]
Sent: 30 April 2009 12:53
To: Edmonds, AndrewX
Cc: Krishna Sankar (ksankar); occi-wg at ogf.org
Subject: Re: [occi-wg] Extraction of requirements

Hi,

>
> Examples of elasticity:
> For a machine:
> - Set memory utilisation to 512MB but allow to grow to 1GB if demand
> exceeds minimum capacity
> - Set number of CPUs to 2 but allow to grow to 4 if demand exceeds
> minimum capacity
> - Set disk space to 5GB but allow to grow to 10GB if demand exceeds
> minimum capacity
> - Set network bandwidth to 10GB/s but allow to grow to 20GB/s if
> demand exceeds minimum capacity
> To each of these a policy can be applied that either seeks to
> minimise resource consumption (shrink; active) or the counter
> maintain current (keep expanded; passive) for a set period.
> There are also some examples of OVF ranges in section 8.4 of [1].

Agreed
>
> Regarding the state of current providers & vertical scaling; from
> what I seen so far are fix virtual hardware specifications offered
> to clients that cannot grow according to specified simple rules. The
> closest that I've seen is where a provider offers "burstable"
> capacity but this non-functional attribute (from the user's point of
> view) is not as fine-grained as the example rules above. If we take
> the example of Amazon EC2, to move from a small instance to a large
> instance means a re-provisioning AFAIK. Does anyone here have any
> examples where this is not the case?

ElasticHosts provide "instant flexibility" http://www.elastichosts.com/benefits/instant-flexibility
>
> As for placement constraints, I would imagine, just like what you
> said, that many of such non-functional properties like this would be
> hidden from the users of an IaaS interface and are mostly internal
> concerns of providers. Again as you stated in your previous mail,
> the only "placement" constraint that would be of relevance to users
> would be geographic location of provisioned resources (legal
> compliance or performance considerations etc).

Cheers
>
> Andy
>
> [1] http://www.dmtf.org/standards/published_documents/
> DSP0243_1.0.0.pdf
>
> -----Original Message-----
> From: Ignacio Martin Llorente [mailto:llorente at dacya.ucm.es]
> Sent: 30 April 2009 10:11
> To: Edmonds, AndrewX
> Cc: Krishna Sankar (ksankar); occi-wg at ogf.org
> Subject: Re: [occi-wg] Extraction of requirements
>
>
> Hi
>
>> I would prefer to see _infrastructure_ elasticity rules included as
>> they are directly related to a provisioning request (also helps a
>> provider do some up front resource optimisation). OVF also follows
>> this approach with their notion of "ranges". It makes sense as
>> pushing infrastructure elasticity rule management off to another
>> service only introduces another dependency that has to be managed/
>> tracked. Placing elasticity rules upfront and in the context of the
>> infrastructure request also aids in the creation of guarantees of
>> infrastructure so clients requesting infrastructure can further rely
>> on the offers given by providers (risk mitigation).
>
> Could you given an example of an infrastructure elasticity rule?, are
> they placement constraints?
>
>> I do however see that the elasticity of services (or scalability)
>> running on infrastructure should be managed by a service management
>> layer, possibly external, for example scalr - where it has
>> application specific scaling strategies to deal with horizontal
>> scaling based on infrastructural metrics.
>>
>> Speaking of horizontal scaling brings to mind vertical scaling.
>> Vertical scaling is what infrastructure should support via
>> elasticity. Horizontal scaling is what should and is be supported by
>> the likes of rightscale and scalr. This makes for a very clear and
>> clean separation of concerns and lessening of dependencies. By
>> supporting the two we have in effect diagonal scaling. All scaling
>> types can also, and in the case of cloud, be virtual and so by
>> virtualisation's theoretical nature, infinite in capacity.
>>
>> With respect to infrastructure placement rules/policies, these
>> approaches can still exist with vertical scaling and the clues
>> (elasticity rules in this case) supplied at provisioning time, can,
>> support runtime optimisation to some degrees.
>>
>> So what I suggest is differentiation between scaling on the cloud;
>> horizontal and vertical, where horizontal remains in the domain of
>> PaaS and vertical in the domain of IaaS.
>
> Agreed, in fact, if I am not wrong, infrastructure providers supports
> vertical scaling, this is support for dynamic changing the resource
> attributes of a running VM
>
> Regards
>>
>> Andy
>>
>> -----Original Message-----
>> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On
>> Behalf Of Ignacio Martin Llorente
>> Sent: 30 April 2009 08:36
>> To: Krishna Sankar (ksankar)
>> Cc: occi-wg at ogf.org
>> Subject: Re: [occi-wg] Extraction of requirements
>>
>> Hi,
>>
>> In my view:
>>
>> - SERVICE ELASTICITY RULES are implemented by the service management
>> layer on top of the infrastructure clouds. That is the case of
>> RightScale or the RESERVOIR Service Manager (Nephele by Telefonica I
>> +D), service management tools grow or shrink the service using the
>> Cloud API to meet given SLOs. See use case http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/ServiceManagerToControlOfLifecycleOfServicesInTheCloud
>> by Telefonica I+D (RESERVOIR)
>>
>> - INFRASTRUCTURE PLACEMENT RULES/POLICIES, such as load balancing or
>> VM consolidation, are executed internally by the cloud provider in
>> order to optimize a given metric, and are not exposed to end users.
>> The user can only define placement constraints as attributes in the
>> VM
>> definition, for example to specify a geographical location.
>>
>> Regarding storage management,  I understand that is related to image
>> management, that is the functionality that must be delivered for
>> enabling cloud infrastructure services (methods to register, upload,
>> update and download disk images).
>>
>> Cheers
>> --
>> Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente
>> DSA Research Group:  web http://dsa-research.org and blog http://blog.dsa-research.org
>> Globus GridWay Metascheduler: http://www.GridWay.org
>> OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 30/04/2009, at 2:15, Krishna Sankar (ksankar) wrote:
>>
>>> What about Elasticity rules, adjacency rules, processing rules et
>>> al ?
>>> Or Should we generically have a policy category ?
>>>
>>> Also storage management might be another one.
>>>
>>> Cheers
>>> <k/>
>>>
>>> |-----Original Message-----
>>> |From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On
>>> Behalf
>>> |Of Ignacio Martin Llorente
>>> |Sent: Wednesday, April 29, 2009 9:33 AM
>>> |To: occi-wg at ogf.org
>>> |Subject: [occi-wg] Extraction of requirements
>>> |
>>> |Hi,
>>> |
>>> |We are going to start with the evaluation of the submitted use
>>> cases.
>>> |I am planing to create a table summarizing requirements for the
>>> |different use cases with the following entries:
>>> |
>>> |A. Functional Requirements
>>> |VM Description
>>> |VM Management
>>> |Network Management
>>> |Image Management
>>> |
>>> |B. Non-functional Requirements
>>> |Security
>>> |Quality of Service
>>> |Others
>>> |
>>> |Any suggestion?
>>> |
>>> |Ignacio
>>> |--
>>> |Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-
>>> |research.org/doku.php?id=people:llorente
>>> |DSA Research Group:  web http://dsa-research.org and blog
>>> |http://blog.dsa-research.org
>>> |Globus GridWay Metascheduler: http://www.GridWay.org
>>> |OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |_______________________________________________
>>> |occi-wg mailing list
>>> |occi-wg at ogf.org
>>> |http://www.ogf.org/mailman/listinfo/occi-wg
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>> -------------------------------------------------------------
>> Intel Ireland Limited (Branch)
>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> Registered Number: E902934
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

-------------------------------------------------------------
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.