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.
- 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 resourcesOS::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)
Hello
Thank you for the contents, it is very well laid out. I am using contrail and am working on generating heat templates to deploy service-chaining and service scaling. In this regard had a couple of questions:
1. Does contrail support auto scaling? Is it possible to list down the differences between autoscaling and service-scaling?
2.In the example provided in the video, I see the interfaces for the newly added instance have different IPaddress as compared to the older existing instance.. then in contrail documentation there is mentioning of “sharing the IP address of one of the interfaces” between the instances… Can you provide some details on this?
Hi Teju,
Answering your questions,
1. AutoScaling is an OpenStack construct: https://wiki.openstack.org/wiki/Heat/AutoScaling & yes you can use it to scale up/down Contrail resources.
ServiceScaling is scaling out a service to meet a certain requirement (For example: Adding backend servers to an existing Load-Balancer pool). You can manually do this, or use AutoScaling resources to add/remove servers based on the LB pool health. In the above example, I use the CPU utilization threshold to trigger adding/removing instances from the service-chain. AutoScaling can be called intelligent ServiceScaling.
2. This implementation does not share the IP address. Instead the vRouter load balances (similar to BGP multi-path). Since there are multiple service-instances, vRouter will receive multiple XMPP routes towards the final destination. All the XMPP routes have the same destination prefix, but they have different Route Distinguishers (RDs) to keep them distinct, & have different next-hops and MPLS labels to identify the different downstream service instances.