cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: AutoScale feature....
Date Fri, 06 Jul 2012 00:33:49 GMT
Thanks. I have attempted to elide the NS pieces below to get a better
understanding. I also looked at the updated spec
http://wiki.cloudstack.org/display/DesignDocs/Auto+Scale+Feature

On 7/5/12 4:04 AM, "Ram Ganesh" <Ram.Ganesh@citrix.com> wrote:

>Hi,
>
>I have updated the functional specs with more details around the various
>components that come into play plus answers for various questions as
>required by the functional spec template. Talking briefly about modules -
>Collector/Monitor, Aggregator, Trigger/Alarm generator and Trigger/Alarm
>handler
>
>Collector/Monitor: This module is responsible for gathering metrics from
>various guest VMs. Timers wakes up a collector/monitor periodically for
>metric collection purpose. [etc]
>
>Aggregator: This module aggregates the collected metric values based  on
>various algorithms such as average, minimum, maximum etc. [etc]
>
>Trigger/Alarm Generator: Timer based triggers monitor the output of
>aggregators, evaluates autoscale conditions and generates a trigger/alarm
>if the condition is evaluated to true. [etc]
>
>Trigger/Alarm Handler: Trigger/Alarm Handler acts on trigger/alarm and
>initiates a scale up/scale down action working in unison with Cloud
>orchestration products such as CloudStack. [etc]
>
>AutoScale configuration done on an LB rule using the CloudStack APIs
>configures the management plane of NetScaler system. In the current
>implementation all the above 4 modules reside inside NetScaler system.

To me, these are the generic interfaces that should exist in the auto
scaling framework inside CloudStack. If you define the API nicely in these
(java) interfaces, then you can write Netscaler classes that implement
these interfaces. Then you can tell CloudStack that the specific classes
that implement the interfaces in components.xml . The APIs would be
broadly those that handle the auto scaling configuration from the end-user
API.
The Netscaler implementations would merely act as proxies to the actual
modules that run on the Netscaler. Now someone else can come in and
provide their own implementation to replace these classes and configure
CloudStack to use theirs instead. This is what I meant by a
"re-factoring". But until that other implementation is done, the Netscaler
implementation is the only one available.

>The interaction between Trigger Generator and Handler is based on
>standard json payload over HTTP. We could look at implementing a generic
>Trigger/Alarm Handler in CloudStack and then rest of the modules in a
>phased manner.

This is a good idea, but the minimum ask is to define the interface / API.
> 

>
>For the trigger handler support in CloudStack we need to
>
>	- Discuss/debate the protocol to use : HTTP/HTTPS vs alert based
>protocols like SNMP,UDP

Note this does not have to be generic: this could be custom for the
Netscaler realization, but generic is nice. HTTP/json is nice, but some
kind of authentication is required.


>	
>But as mentioned earlier there is lot of value in leveraging richer
>monitoring capabilities offered by load balancer devices and thereby
>taking far intelligent scaling actions

Nobody ever said anything to the contrary. I am certain that this is going
to be a fantastic feature.
The only thing we are trying to achieve here is a clean architecture that
other contributors feel they can enhance or implement rather than doing
yet another rewrite.

>
>Also around the placement of SNMP community and SNMP port I am open to
>better ideas.

As I mentioned before, they can be passed in as generic key value pairs.
The Netscaler classes implementing the configuration API would interpret
they key value pairs (and reject the API call if they are not there).

--
Chiradeep


Mime
View raw message