[occi-wg] Extraction of requirements

Thu Apr 30 18:04:28 CDT 2009

Hi Andy,

Another placement rule for VM's might be: don't place my VM's on a single physical host server - to ensure that a virtual cluster the customer defines isn't killed by the failure of a single host server.

Adding additional hardware resources for VM's will only be possible for those VM's running operating systems that support hot add of additional hardware.  OS's that don't support hot adding of hardware will require a reboot.  A VM that is receiving a certain share of a host CPU could however be granted more shares without any reconfiguration of the guest VM without any issues.

Regards,
--
Kristoffer Sheather
Cloud Central Pty Ltd   

----------------------------------------
From: "Edmonds, AndrewX" <andrewx.edmonds at intel.com>
Sent: 30 April 2009 19:53
To: Ignacio Martin Llorente <llorente at dacya.ucm.es>
Subject: Re: [occi-wg] Extraction of requirements 

Hey Ignacio :-),

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].

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?

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).

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
>> 
>>
>> |-----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.
_______________________________________________
occi-wg mailing list
occi-wg at ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090501/8eb496e5/attachment.html 