cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Youcef Laribi <Youcef.Lar...@eu.citrix.com>
Subject RE: AutoScale feature....
Date Tue, 03 Jul 2012 18:11:08 GMT

>> 1.       VM Counters that specify the monitored aspects of the VMs (some
>> of these counters are monitored through SNMP agents running inside the 
> >VM- hence they are of the SNMP type)

>This is specific to the implementation. There are several ways to monitor performance.
SNMP is just one. Hence it should not be part of the API. It can be a generic key-value pair
(for an >example, look at the createLbStickinessPolicy http://download.cloud.com/releases/3.0.0/api_3.0.0/user/createLBStickinessPolicy.html)

Counters can be of any type. One of the types supported is SNMP. If the user has got an SNMP
agent inside his VM that is monitoring some aspect of that VM, he needs to be able to configure
it as a counter that can be used in the autoscale policies. If the contention is not to surface
the "type" of a counter, we can hide it inside a "param" argument, which can contain "type"
as one of the keys in a key/value list. In any case, the implementer must understand how to
instantiate counters.


>>3.       VM Profile that contains the details needed to auto-instantiates
>>VMs and captures anything VM-specific (template, service offering, 
>>network, VM's SNMP agent port and community, etc.)
>
> Template, service offering and network are generic, SNMP is not.

Same here, the VM's SNMP port and community string are specific to the VM and can be configured
as a generic key/value list.

>>The implementation relies on the LoadBalancer Resource being able to 
>>support this new config item in an LB Rule. Any LB offering in 
>>CloudStack can support this new additional config and is free in the 
>>way it implements it. CloudStack will only allow configuring this 
>>feature on an LB Rule when the network LB offering supports it. The 
>>NetScaler offering will support this new feature, and we are extending 
>>the existing NetScaler Resource layer to implement it.
>>
>
>It is not necessary for an LB to implement the auto scaling. Any other component can do
the same. For example, a component can monitor via hypervisor stats, or volume IO stats. So
in >this sense it is not generic.

It is not necessary for an LB to implement the auto scaling but NetScaler LB provides one
and we want to allow CS admins who are using NetScaler to be able to take advantage of it.
There is nothing here that prevents other components to take advantage of Counters, AutoScale
policies, etc. if they wish to.

Youcef


Mime
View raw message