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. 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.
Thanks,
Ram
> -----Original Message-----
> From: Ram Ganesh [mailto:[email protected]]
> Sent: 04 July 2012 07:29
> To: [email protected]
> 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 [mailto:[email protected]]
> > Sent: 04 July 2012 06:40
> > To: [email protected]
> > Subject: Re: AutoScale feature....
> >
> > On Tue, Jul 3, 2012 at 8:23 PM, Youcef Laribi
> > <[email protected]> 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
