[occi-wg] Extraction of requirements
Ignacio Martin Llorente
llorente at dacya.ucm.es
Thu Apr 30 06:53:21 CDT 2009
> 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 .
> 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).
>  http://www.dmtf.org/standards/published_documents/
> -----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
>> 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
>> -----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
>> 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
>> 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).
>> 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.
>>> |-----Original Message-----
>>> |From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On
>>> |Of Ignacio Martin Llorente
>>> |Sent: Wednesday, April 29, 2009 9:33 AM
>>> |To: occi-wg at ogf.org
>>> |Subject: [occi-wg] Extraction of requirements
>>> |We are going to start with the evaluation of the submitted use
>>> |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
>>> |Quality of Service
>>> |Any suggestion?
>>> |Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-
>>> |DSA Research Group: web http://dsa-research.org and blog
>>> |Globus GridWay Metascheduler: http://www.GridWay.org
>>> |OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
>>> |occi-wg mailing list
>>> |occi-wg at ogf.org
>> occi-wg mailing list
>> occi-wg at ogf.org
>> 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.
More information about the occi-wg