[occi-wg] Extraction of requirements

Thu Apr 30 04:10:55 CDT 2009

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.