Configure Load Balancing-as-a-Service (LBaaS) in OpenStack Networking

Updated -

Note: The LBaaS content has been moved into the Networking Guide for these releases:

Introduced in Red Hat Enterprise Linux OpenStack Platform 5, Load Balancing-as-a-Service (LBaaS) enables OpenStack Networking to distribute incoming requests evenly between designated instances. This ensures the workload is shared predictably among instances, and allows more effective use of system resources. Incoming requests are distributed using one of these load balancing methods:

  • Round robin - Rotates requests evenly between multiple instances.
  • Source IP - Requests from a unique source IP address are consistently directed to the same instance.
  • Least connections - Allocates requests to the instance with the least number of active connections.

Table 1: LBaaS features

Feature Description
Monitors LBaaS provides availability monitoring with the ping, TCP, HTTP and HTTPS GET methods. Monitors are implemented to determine whether pool members are available to handle requests.
Management LBaaS is managed using a variety of tool sets. The REST API is available for programmatic administration and scripting. Users perform administrative management of load balancers through either the CLI (neutron) or the OpenStack dashboard.
Connection limits Ingress traffic can be shaped with connection limits. This feature allows workload control and can also assist with mitigating DoS (Denial of Service) attacks.
Session persistence LBaaS supports session persistence by ensuring incoming requests are routed to the same instance within a pool of multiple instances. LBaaS supports routing decisions based on cookies and source IP address.

Note: LBaaS is currently supported only with IPv4 addressing.

OpenStack Networking and LBaaS Topology

OpenStack Networking (neutron) services can be broadly classified into two categories.

1. - Neutron API server - This service runs the OpenStack Networking API server, which has the main responsibility of providing an API for end users and services to interact with OpenStack Networking. This server also has the responsibility of interacting with underlying database to store and retrieve tenant network, router, loadbalancer, etc details.

2. - Neutron Agents - These are the services that deliver various network functionality for OpenStack Networking.
For example:

  • neutron-dhcp-agent - manages dhcp ip addressing for tenant private networks
  • neutron-l3-agent - facilitates layer 3 routing between tenant private networks and tenant private network and external network, and others.
  • neutron-lbaas-agent - provisions the LBaaS routers created by tenants.

Service Placement

The OpenStack Networking services can either run together on the same physical server, or on separate dedicated servers.

The server that runs API server is usually called the controller node, whereas the server that runs the agents is called the network node. An ideal production environment would separate these components to their own dedicated nodes for performance and scalability reasons, but a testing or PoC deployment may have them all running on the same node.
This article covers both of these scenarios; the section under Controller node configuration need to be performed on the API server, whereas the section on Network node is performed on the server that runs the LBaaS agent.

Note: If both the Controller and Network roles are on the same physical node, then the steps must be performed on that server.

Configure LBaaS

This procedure configures OpenStack Networking to use LBaaS with either the Open vSwitch (OVS) or the Linux Bridge plug-in. The Open vSwitch LBaaS driver is required when enabling LBaaS for OVS-based plug-ins, including BigSwitch, Floodlight, NEC, NSX, and Ryu.
Perform these steps on nodes running the neutron-server service:

On the Controller node (API Server):

1. Enable the HAProxy plug-in using the service_provider parameter in the /etc/neutron/neutron.conf file:

service_provider =

2. Enable the LBaaS plugin by setting the service_plugin value in the /etc/neutron/neutron.conf file:

service_plugins = lbaas

3. Apply the new settings by restarting the _neutron-server services.

# systemctl restart neutron-server.service

Enable LBaaS Integration with Dashboard

Usually Horizon dashboard is run on the same node where neutron API service run. You can enable Load Balancing in the Project section of the Dashboard user interface.
Perform these steps on the node running the Dashboard (horizon) service:

1. Change the enable_lb option to True in the /etc/openstack-dashboard/local_settings file:


2. Apply the new settings by restarting the httpd service.

# systemctl restart httpd.service

You can now view the Load Balancer management options in the Network dropdown list in dashboard's Project view.

On the network node (running the LBaaS Agent):

1. Enable the HAProxy load balancer in the /etc/neutron/lbaas_agent.ini file:

device_driver =

2. Configure the user_group option in /etc/neutron/lbaas_agent.ini

# The user group
# user_group = nogroup
user_group = haproxy

3. Select the required driver in the /etc/neutron/lbaas_agent.ini file:

  • If using the Open vSwitch plug-in:
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
  • If using the Linux Bridge plug-in:
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver

4. Apply the new settings by restarting the neutron-lbaas-agent service.

# systemctl restart neutron-lbaas-agent.service


Are this changes compatible with a deployment made with the "Red Hat Enterprise Linux OpenStack Platform Installer"?
If not, which cloud be the best way to made those changes on a infraestructure which was configured using the "Red Hat Enterprise Linux OpenStack Platform Installer" ?

"Red Hat Enterprise Linux OpenStack Platform Installer" does not support LBaaS deployment. You can stop puppet on all nodes and do the configuration manually.

If you see errors ( in the neutron's log ) about HA-Proxy not finding "nogroup" , you have to create the "nogroup" group in the node that you want to run the HA-Proxy Process.

Or configure to use an existing "group" in /etc/neutron/lbaas_agent.ini

# The user group
# user_group = nogroup
user_group = haproxy

Thanks Sadique, I've added this step to the article. See 'Configure LBaaS' -> Step 4.

I have basically a 3 node Juno setup, Host 1 controller (all services except network), Host 2 network (neutron), host 3 compute.

These directions won't work as followed unless you do this (I assume the above is for a all-in-one install):

Steps 1 and 2 on the Host 1, the controller.

Steps 3, 4 and 5 on Host 2, the network neutron node.

Step 6, restart the neutron server service on Host 1, the controller, and restart and enable the lbaas agent on Host 2, the network neutron node.

Then follow the directions on your controller node for the dashboard, steps 1 and 2.

Last, install haproxy on the Host 2, network neutron node.

Wil @ Genesys Telecomunications

Thanks for the feedback Wil, reviewing...

Correct. This document was focusing on an all-in-one installation. If you are separating controller node and network node to separate hosts, then the controller related tasks (neutron-server) need to be done on controller node and lbaas-agent related configuration and tasks on network node.

I hope to have this doc modified to reflect this.

Article has been updated for multinode.
Thanks for your help here, Sadique.

I noticed this does not work in OSP10. the path to the haproxy device driver is different. I get : /var/log/neutron/lbaas-agent.log Could not load

I found it in a different location:

grep -r HaproxyNSDriver /usr/lib/python2.7/site-packages/neutron_lbaas/drivers/haproxy/ class HaproxyNSDriver(agent_device_driver.AgentDeviceDriver): super(HaproxyNSDriver, self).init(conf, plugin_rpc) [root@overcloud-controller-1 heat-admin]#

so I changed to match :

/etc/neutron/lbaas_agent.ini device_driver = neutron_lbaas.drivers.haproxy.namespace_driver.HaproxyNSDriver

now it works

root@overcloud-controller-1 heat-admin]# systemctl restart neutron-lbaasv2-agent [root@overcloud-controller-1 heat-admin]# systemctl status neutron-lbaasv2-agent ● neutron-lbaasv2-agent.service - OpenStack Neutron Load Balancing as a Service (API v2.x) Agent Loaded: loaded (/usr/lib/systemd/system/neutron-lbaasv2-agent.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2016-12-28 21:09:57 UTC; 8s ago Main PID: 691821 (neutron-lbaasv2) CGroup: /system.slice/neutron-lbaasv2-agent.service └─691821 /usr/bin/python2 /usr/bin/neutron-lbaasv2-agent --config-file /usr/share/neutron/neutron-dist.conf --config-file /usr/share/neutron/neu...

Also need to put service_provider here not neutron.conf

/etc/neutron/neutron_lbaas.conf: [service_providers] service_provider = LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

Hi Jeremy, thanks for the feedback. Wanted to update you that I'm working with the SMEs on this.