cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ram Ganesh <>
Subject RE: AutoScale feature....
Date Thu, 05 Jul 2012 11:04:17 GMT

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. Periodicity
of timer is configurable. Monitoring framework in NetScaler is rich in protocol support varying
from L3 to L7 with deep packet inspection capabilities. 

Aggregator: This module aggregates the collected metric values based  on various algorithms
such as average, minimum, maximum etc. In NetScaler this is part of the monitoring infrastructure.

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.
In NetScaler this is part of powerful policy based infrastructure responsible for various
expression evaluations and actions.

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. In NetScaler
this is a web service residing in the management plane and acts as a glue between CloudStack
management server and NetScaler data plane.

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. 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. 

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
	- Discuss/debate the payload format: json/xml/both/? etc
	- Anything else?
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

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


> -----Original Message-----
> From: Ram Ganesh []
> Sent: 04 July 2012 07:29
> To:
> Subject: RE: AutoScale feature....
> I am in the process of updating the functional specs with lot of
> details as Chiradeep asked for in his earlier email and bring out which
> component is doing what, load balancer vs CloudStack vs Guest VM. I
> hope we will get more clarity post that and can enhance further to make
> it as generic as possible for other to implement this feature
> Thanks,
> Ram
> > -----Original Message-----
> > From: David Nalley []
> > Sent: 04 July 2012 06:40
> > To:
> > Subject: Re: AutoScale feature....
> >
> > On Tue, Jul 3, 2012 at 8:23 PM, Youcef Laribi
> > <> wrote:
> > >>I see where you are coming from. The point is not about treating
> one
> > LB preferentially over another. It is the LB-centric nature of the
> > proposal.
> > >>Surely it should be possible to have an implementation that does
> not
> > involve any LB at all (like the AWS auto scaling groups). The
> proposed
> > API is very much like the AWS auto-scaling >API, but is useless
> without
> > the Netscaler. Historically CloudStack almost always has had defaults
> > that work without any external devices. I think if you propose a
> > generic UI and a generic >API then it becomes important to follow
> this
> > precedent.
> > >>
> > >>I also submit that it doesn't have to be "months". I wager that
> some
> > level of re-factoring of your proposal / code should get us to this
> > state.
> > >
> > > This is not about code re-factoring. We are leveraging *existing*
> > features on NetScaler (like monitoring, policy-based triggering,
> > aggregating stats, etc.) that we thankfully don't have to code. In
> any
> > case, we don't have the resources, time or interest in
> (re)implementing
> > this inside CloudStack so that it can be used without a NetScaler.
> > >
> > > Our goal is to surface an "LB" autoscale capability that NetScaler
> > provides, so that CS users can take advantage of it when they are
> > deploying with a NetScaler. We have gone to great lengths to make the
> > API LoadBalancer-agnostic, to leave the door open for other
> > loadbalancers who have a similar capability.
> > >
> > > Youcef
> > >
> >
> >
> > So I am hoping that there is some disconnect here.
> >
> > I don't think that Chiradeep was asking for you to implement this
> > feature in CloudStack itself, but rather to make the framework that
> > you already are going to have to build a bit more generic. This
> allows
> > others to build on your work.
> >
> > That said, two different committers have suggested a more generic
> move
> > (albeit Chiradeep has done a far more eloquent and pragmatic job than
> > I) and this email suggests an unwillingness to consider those
> > comments.
> >
> > --David

View raw message