Telecom IQ
Showing results for 
Search instead for 
Did you mean: 

NFV Nuts and Bolts: Load balancing approaches for Heat based Auto Scaling


Author: Senthil Kumar Subramaniam

Lead Architect – NFV Solutions


Network Functions Virtualization (NFV) technology has begun to transform the way telecom services are deployed and delivered. One of the primary goals of NFV is to enable automatic scaling of Virtual Network Function (VNF) components based on policies and service level agreements (SLAs). A load balancer plays a vital role in implementing efficient auto-scaling methodologies. Since NFV workloads are network oriented, multiple approaches to implement load balancing functionality is required.


Based on the network requirements and functionalities needed in a load balancer, the following options are available to be used with heat-based orchestration for auto scaling.

  • Neutron Load Balancing as a Service (LBaaS)
  • Inbuilt HAProxy support in OpenStack Heat
  • External virtual load balancer
  • Software Defined Networking (SDN) / OpenFlow based load balancing

Neutron Load Balancing as a Service (LBaaS) provides on demand and open API based solutions, to create a load balancer for a set of backend servers. LBaaS works based on a driver approach wherein multiple types of load balancers can be used, as long as the vendor provides the LBaaS driver. The default one provided is based on HAProxy. OpenStack Heat has inbuilt support to use LBaaS as part of the resource template.


Heat takes care of adding/removing VNFC instances based on Ceilometer alarms and then automatically adds/removes the instances to the LBaaS pool.



LBaaS provides the advantage of a common API to work with different types of load balancers (VM or hardware appliances), and internals are abstracted by LBaaS drivers. There are limitations such as no support for HA for the LBaaS agent, tenant-specific SSL termination and L7 content based load balancing.


Inbuilt HAProxy support in Heat is implemented using the following resource template. When specified, Heat automatically spawns a HAProxy instance and adds the current set of VNFC instances to it. As part of the AutoScaling policy defined in the template, Heat adds or removes instances to or from the HAProxy configuration file.



The inbuilt HAProxy approach eliminates Neutron overhead, but it is limited to HAProxy-based load balancers.

External virtual load balancer approach is similar to the above but instead of Neutron/Heat managing the load balancer instance, the user has to define it as another server instance as part of the stack template. The addition or deletion of members should also be done using an external process which would listen to VNFC lifecycle notifications and use the load balancer APIs to manage the same.



The advantage of this approach is that any virtual load balancer can be used, not just the ones supported by Neutron LBaaS. The disadvantage is that a separate process is required for member management unlike the first two approaches where either Neutron or Heat is managing the same.


SDN/OpenFlow based load balancing is an emerging approach where the OpenFlow flow rules are used to set up load balancing for an incoming client session. An SDN controller or an app running on it, should support the load balancing functionality by providing North Bound APIs for policy and member management. There is no inbuilt support for this model in Heat, but the model can be achieved by having an external process listening to the VNFC lifecycle events and use the NB API of the SDN controller to add or remove members. All the switches on the network path (vSwitches, physical switches) should support OpenFlow, so that the controller can set the flow rules accordingly for an incoming session.



The advantage of the SDN/OpenFlow approach is that the load balancing can be done with network visibility. For example, if there is any failure on a particular network path, the flow rules can be changed so that a different path is taken to reach VNFC instances. Additionally bandwidth/quality of service (QoS) can also be dynamically set for a given flow. The limitations are that there is currently no support for content-based load balancing (example HTTP header content) and SSL termination.


In summary, a NFV platform should provide various options for load balancing as part of VNF onboarding. This way the VNF vendor or service provider can choose the best option to load balance the VNF components as required by network service type, SLAs etc. For more information on how HP is providing an integrated NFV solution offering, please refer to HP`s OpenNFV Architecture and Partner Program.

0 Kudos
About the Author


Read for dates
HPE Webinars - 2019
Find out about this year's live broadcasts and on-demand webinars.
Read more
Read for dates
HPE at 2019 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2019.
Read more
View all