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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ignacio Martin Llorente Sent: 30 April 2009 08:36 To: Krishna Sankar (ksankar) Cc: occi-wg@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/ServiceManage... 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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Ignacio Martin Llorente |Sent: Wednesday, April 29, 2009 9:33 AM |To: occi-wg@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@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@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.