[occi-wg] Extraction of requirements

Thu Apr 30 06:53:21 CDT 2009

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.