Introduction

Currently Apache CloudStack supports AutoScaling feature with external Citrix NetScaler device for three purposes: monitoring, grouping and load balancing. For anyone don't know about it, please take a look into Admin guide. Also, there is a pretty explanation below:

http://support.citrix.com/proddocs/topic/ns-system-10-map/ns-autoscale-how-autoscale-works-con.html

Starting from a motivation about creating a native solution of AutoScaling feature, I made some changes to reproduce NetScaler engine operation. The first version still keeps the similar steps compared with the current NetScaler version, while adding two new native counters (Linux User CPU - native & Linux User Memory - native). You can find more detail from my presentation here:

 http://www.slideshare.net/tuna20073882/autoscale-without-netscalerccceu13

http://www.youtube.com/watch?v=LJnKMuADvHc

Chiradeep, CloudStack PMC, has a vision to improve my hacking with some new changes below:

         + Need to remove Load Balancing feature from AutoScaling. That’s very simple to do.
         + Need to use SNMP for monitoring not only instance-level but also application-level.
         + Also, supporting well KVM hypervisor

The idea is that the monitoring (WHAT to monitor and HOW to monitor) is separate from the autoscaling decision.

The autoscaling decision should be a pure mathematical decision. 

The various services can interact via  Java API(s). In this case the deployment is simple (within the CS management server).

However, the monitoring service likely needs more scale than regular CloudStack orchestration. Ideally there should be the option of running the monitoring service outside of the CS MS.

Responsibilities:

Monitoring service:

  - monitor counters in VMs/hypervisors/network appliances

  - provide aggregates and threshold crossing outputs

  - communicates threshold crossing info to autoscale service

Auto Scale Service

   - decides to scale based on policy and threshold crossing info from monitoring service

   - communicates with CS MS to perform scale-up/scale-down

Design Architecture

API change

+ AutoScale API: keep the same

• createConditionCmd, listConditionCmd, deleteConditionCmd
• createPolicyCmd, listPolicyCmd, deletePolicyCmd
• createProfileCmd, listProfileCmd, deleteProfileCmd
• createGroupCmd, listGroupCmd, deleteGroupCmd, disableGroupCmd, enableGroupCmd

+ Monitor API:

• addMonitorDeviceCmd
  • request parameter:
    • physical n/w id (required) - id of the physical n/w to which MonitorDevice is associated with
    • mgmt. ip (required) - IP address for connecting to MonitorDevice
    • username (required) - Username for connecting to MonitorDevice
    • password (required) - Password for the above username
  • response:
    • deviceId
    • deviceName
    • physical n/w id
    • providerName
• removeMonitorDeviceCmd
  • request parameter:
    • deviceId (required)
  • response
    • boolean (success / failure)
• listMonitorDeviceCmd
  • request parameter
    • deviceId (optional)
    • physical n/w id (optional)
  • response
    • deviceId
    • deviceName
    • physical n/w id
    • providerName

+ HTTP request from CS to Monitor device

• sendConfiguration
  • request parameter
    • counterName (required) - type of parameter need to monitor
  • response
    • boolean (success / failure)
• queryPerformanceData
  • request parameter
    • total_vm
    • foreach vm
      • duration (required) - time range, in second, to monitor. It need to calculate the average value
      • counterName (required)
      • vm IP address (required)
  • response
    • foreach vm
      • counterName
      • average value in duration

Interface

AutoScaling service

Monitoring service