cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Youcef Laribi <>
Subject Re: AutoScale feature....
Date Tue, 03 Jul 2012 06:43:10 GMT
In a nutshell, the framework is as follows:

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)

2.       AutoScale Policy to express the low and high watermark thresholds on counters to
trigger a scaling up/down action.

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,

4.       AutoScale Group which represents the dynamic list of autoscale VMs (min/max members
in this group), and associates with them an autoscale policy  and a VM profile. Once defined,
the AutoScale Group is assigned to the LB Rule (just like assigning manually one VM/instance
to an LB Rule).

This is a generic framework.

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.


>On 7/2/12 6:24 PM, "David Nalley" <<>> wrote:


>>On Mon, Jul 2, 2012 at 2:08 PM, Ram Ganesh <<>>

>>> Hi All,


>>> Briefly talking about the feature - AutoScale feature allows you to

>>>scale up or scale down the virtual instances that are being load

>>>balanced by load balancers like NetScaler based on certain conditions.

>>>This feature is an extension to the ELB feature in CloudStack. This

>>>feature is similar to AWS autoscale feature except that monitoring of

>>>server's(guest vm) health is done by load balancers like NetScaler and

>>>provisioning is done by CloudStack. Monitoring done by loadbalancers

>>>has couple of benefits

>>>         - Loadbalancers are better placed to understand the health of

>>>the  server as traditionally LB devices had monitoring capability

>>>inbuilt in it.

>>>         - Decisions can be based not just on certain conventional

>>>counters like CPU, Memory etc but also on network counters like

>>>response time, bandwidth, connections etc

>>>         - Decreases the load on CloudStack management server.


>>But that inherently limits where AutoScale will work. This means all of

>>this work is inherently very niche, can only be tested by folks with NS

>>hardware,  and only utilized by the same folks - and autoscaling could

>>be inherently useful in other situations that don't have LB


>>CloudStack has inherently been hypervisor agnostic, is there a reason

>>not to be LB agnostic as well?


>It seems to me that the proposed APIs are not too LB-specific (there's stuff about snmp
ports and community strings that is specific to this implementation and should not belong
in a >generic API).

>I would imagine that an auto scaling implementation would have:

>1. Monitors that know how to monitor a specific kind of load 2. Configuration of thresholds
to get notified when the monitors detect a breach of thresholds 3. Actions to take on breach
>of thresholds


>I would like to see a generic framework such as this laid out and a description of how
this specific implementation uses the framework.


>Also, the FS template has lots of questions (

>) which have not been answered.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message