Skip to main content
search

Elastic Service Chaining (AutoScaling) using OpenContrail

Requirements: OpenContrail with OpenStack

What if you have an environment which needs to scale up during periods of peak loads & scale down during normal operations (Eg. Black-Friday). Can you have an automated solution which can handle this kind of scenario to save OpEx/CapEx?

The answer is YES! OpenContrail as the SDN controller provides a robust solution which will intelligently scale up & scale down the cloud-stack based on user-defined metrics. With this solution, cloud administrators define trigger points & the decision to scale is left to the cloud, thus resulting in an intelligent & elastic cloud.

In the previous blog, you have seen how we deploy a service chain using OpenContrail. In this blog, we will see how to enhance the existing service chain to implement the autoscaling feature which will scale up/down service-instances (Eg. Load-Balancers, Firewalls, etc.) using OpenContrail. An OpenStack project called as “Ceilometer” is used to generate alarms which will in turn trigger the scale up/down policies that are defined in the Heat Orchestration Template (HOT).

NOTE: OpenStack Heat is an OpenStack project which is used to orchestrate composite cloud applications using a declarative template format written in YAML through an OpenStack REST API.

OpenStack Ceilometer is an OpenStack project which provides metering, monitoring & alarming features that can be consumed by other OpenStack projects such as Heat.

Below, the video demonstrates how the resources from OpenContrail, Heat & Ceilometer work together to scale up/down service-instances belonging to a service chain. In theory, the process works as described below,

  • Once a service-instance is created, Ceilometer constantly polls the virtual-machine for key performance metrics that are defined in the template. In our case, we specify the metric “average CPU utilization (avg, cpu_util)” of the service-instance cluster. The template also defines thresholds (low & high) to implement the autoscaling feature.
  • Whenever the CPU utilization (load) of the service-instance in the cluster is greater than the upper-threshold value, Ceilometer raises an alarm (Alarm-High) & indicates Heat to instantiate & add a new service-instance to the cluster. Therefore, we now have two service-instances in the chain deployed in Active-Active configuration. This reduces the CPU utilization of the first service-instance since the load is now distributed across TWO service-instances in the cluster. If the average CPU utilization of the cluster is still greater than the upper-threshold value, the autoscaling policy adds another service-instance to the cluster. This autoscaling feature is indicated in the template by the “scaleup_policy”.Alternatively, if the average CPU utilization of the entire cluster is less than the lower-threshold value, Ceilometer raises an alarm (Alarm-Low) & indicates Heat to remove the newly added instances from the service-instance cluster. This is indicated in the template by the “scaledown_policy”.
  • Therefore, we now have an intelligent elastic service-chain that can scale up/down based on a certain user-defined metric. This provides a higher scalability index along with low OpEx.
  1. Some of the key resources & their properties used in the HOT are listed below,OS::ContrailV2::VirtualNetwork – A resource to create a Virtual Network
    OS::ContrailV2::VirtualMachineInterface – A resource to create a Virtual Machine Interface
    OS::ContrailV2::InstanceIp – A resource to allocate an IP address to an instance
    OS::ContrailV2::ServiceTemplate – A resource to create a Service Template
    OS::ContrailV2::ServiceInstance – A resource to create a Service Instance
    OS::ContrailV2::PortTuple – A resource to create a Service-Instance port tuple
    OS::ContrailV2::NetworkPolicy – A resource to create a Virtual-Network Policy
    OS::Heat::AutoScalingGroup – A resource that allows to create a desired number of similar resources.

    Properties:

    1. Max_size: Maximum number of resources (Service-Instances) in the group
    2. Min_size: Minimum number of resources (Service-Instances) in the group
    3. Desired_capacity: Desired initial number of resources

    OS::Heat::ScalingPolicy – A resource to manage scaling of OS::Heat::AutoScalingGroup

    Properties:

    1. Adjustement_type: Type of adjustement (Percentage or Absolute)
    2. Auto_scaling_group_id: Group ID to which the autoscaling policy is applied
    3. Scaling_adjustment: Size of adjustment (+N for scale-up by N, -N for scale-down by N)

    OS::Ceilometer::Alarm – A resource used to raise an alarm

    Properties:

    1. Meter_name: The name of the meter. (cpu_util, image, memory)
    2. Statistic: Meter statistic to evaluate (avg, sum, min, max, count)
    3. Period: Period to evaluate over (in seconds)
    4. Evaluation_periods: Number of periods to evaluate over
    5. Threshold: Threshold to evaluate against
    6. Comparison_operator: Operator used to compare specified statistic with threshold (gt, lt, eq)

Close Menu