OpenStack’s Load Balancer as a Service (LBaaS)

Posted: August 8, 2013 in Cloud Computing
Tags: , ,

If you are a fan of OpenStack, then I am sure that you have heard of the new Load Balancer as a Service (LBaaS) features of Neutron (formerly Quantum).  As the name indicates, it allows an OpenStack user to configure a load balancer for virtual machines running in OpenStack with relative ease.  I used Red Hat’s OpenStack and noticed that LBaaS is included, but not configured by default.  The goal of this post will be to walk you through the configuration changes that need to take place on an operational OpenStack install and demonstrate how to load balance two web servers.

My Lab Setup

First, let me talk a bit about my OpenStack lab environment.  It is small, just a couple of servers.  The controller, named openstack-ctrl, runs as a virtual machine in a Red Hat Enterprise Virtualization environment and provides all of the supporting services (mysql, qpid, Keystone, Cinder, Glance, Nova-API and Horizon)  in OpenStack along with the Quantum server.  A physical server, named server3, acts as a Nova Compute node and also hosts the Quantum L3, DHCP and metadata services.

I have the following networks configured in OpenStack:

Internal (Private): – this network is used for DHCP as well
External (Public): – this network is for connectivity to the external network.
A floating IP range available from

The web servers that I am using to show how the LBaaS works have been preconfigured with a unique hostname and a php page that returns the hostname of the server that is responding to the request.  The web servers do not need a floating IP assigned to them.

Up First, Configuration Changes

To start, we need to make some changes to the Quantum server configuration on the controller node.  To do this, I ssh into the server and complete the following steps:

First, we update the Horizon web interface to allow the LBaaS configuration to be included in the UI by editing the /etc/openstack-dashboard/local_settings file and adding the following lines.  I typically add these right after the closing curly bracket from the OPENSTACK_HYPERVISOR_FEATURES stanza.

'enable_lb': True

Next, add the plugin configuration to the /etc/quantum/quantum.conf file by adding in the following line in the “[DEFAULT]” section of the file.  I normally add the line in after the core_plugin line.

service_plugins =

After that, restart the web server.

[root@openstack-ctrl ~]# service httpd restart
Stopping httpd: [ OK ]
Starting httpd: [ OK ]

If you open the Horizon website and log into your project, you should see a menu option for “Load Balancers” now.


The next steps take place on the nodes that will provide the actual load balancer service.  For my setup this is the Nova-Compute node, server3.  The first step is to move the lbaas-agent.ini file to a new location and symlink it to /etc/quantum.

[root@server3 quantum]# mkdir -p /etc/quantum/plugins/services/agent_loadbalancer
[root@server3 quantum]# mv lbaas_agent.ini /etc/quantum/plugins/services/agent_loadbalancer/
[root@server3 quantum]# ln -s /etc/quantum/plugins/services/agent_loadbalancer/lbaas_agent.ini /etc/quantum/lbaas_agent.ini

For the next step, ensure the following lines are included in the /etc/quantum/lbaas-agent.ini file and are not commented out.

ovs_use_veth = True
interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver
evice_driver =
use_namespaces = True
user_group = haproxy

You need to also ensure that the haproxy package is installed.  The service does not need to be configured or started.

yum install -y haproxy

Now, restart the quantum-agent services to and turn it on to complete the configuration.  Don’t be alarmed by the “failed” status below.  That is just a result of the service having never been run before.

[root@server3 init.d]# for i in {dhcp,l3,lbaas,metadata,openvswitch}; do service quantum-$i-agent restart; done;
Stopping quantum-dhcp-agent: [ OK ]
Starting quantum-dhcp-agent: [ OK ]
Stopping quantum-l3-agent: [ OK ]
Starting quantum-l3-agent: [ OK ]
Stopping quantum-lbaas-agent: [FAILED]
Starting quantum-lbaas-agent: [ OK ]
Stopping quantum-metadata-agent: [ OK ]
Starting quantum-metadata-agent: [ OK ]
Stopping quantum-openvswitch-agent: [ OK ]
Starting quantum-openvswitch-agent: [ OK ]
[root@server3 ~]# chkconfig quantum-lbaas-agent on

Trying it For the First Time

Once all of the services are up and running again, click on the “Load Balancers” link that was highlighted previously.  You may get any errors such as the ones shown below, you may have to check your settings or reboot your OpenStack installation.


 If you did not see any pop-ups, click on the “Add Pool” button and fill out the form that appears.  I used the following settings:

Name: web_pool
Description: Test pool of a couple of web servers.
Subnet: (This is my internal or private subnet)
Protocol: HTTP
Load Balancing Method: ROUND_ROBIN


After adding the pool, we need to add members (instances) to it.  To do this step, click on the “Members” tab near the top of the screen.


Then click the “Add Members” button and fill out the form the appears.  For my installation, I chose the following settings:

Pool: web_pool
Members: Check both servers webserver-db24fcd6-480c-4ee0-8539-ad1782ff39ca and webserver-dc66ac32-8640-42d9-b5af-4a2be667978c
Weight: 1
Protocol Port: 80
Admin State: checked


Now, a monitor has to be added.  A monitor is used to determine which load balancer members are capable of serving requests.  To do this, click on the “Monitors” tab near the top of the page and then click on the “Add Monitor” button.


A form will appear to configure the details of the monitor.  Here are the settings that I used:

Pool: web_pool
Type: HTTP
Delay: 3
Max Retries (1-10): 3
HTTP Method: GET
URL: / (just get the index page)
Expected HTTP Status Codes: 200
Admin State: checked


We are almost finished.  Next, add the virtual IP (or VIP) to the load balancer by clicking on the “Pools” tab and then clicking the button for “Add VIP” located to the right side of the row that contains the pool that was added in an earlier step.  Another form will appear.  The settings that I used are:

Name: web_vip
Description: Virtual IP for my web servers
Vip Address from Floating IPs: Currently Not Supported
Specify a free IP address from
Protocol Port: 80
Protocol: HTTP
Session Preference: (leave blank to keep haproxy from maintaining sessions)
Cookie Name: (leave blank)
Connection Limit: 100
Admin State: checked


The final step is to assign a floating IP to the load balancer that was just configured.  To assign a floating IP, click on the link along the left side of the page for “Access & Security” and then click on the tab for “Floating IPs”.  If no IP addresses have been assigned to the project yet, you can click on the “Allocate IP to Project” button.  I already have three IPs assigned to my project, so I will use one of those by clicking the “Associate Floating IP” button and assign it to the load balancer.  As you can see in the below screenshot, the load balancer show up as “None:” in the Port to be associated field.


Once this step is complete, your web servers should be ready to test.

Testing the LBaaS

There are two easy ways to test the LBaaS.  You can use a web browser and navigate to http://192.168.133 (or whatever floating IP was assigned)  or use the curl command.  What you should see in either method is that the hostname that is returned by the php page bounces back and forth between the two hosts that are members of the load balancer pool.

[ted@teds-laptop ~]$ curl
[ted@teds-laptop ~]$ curl
[ted@teds-laptop ~]$ curl
[ted@teds-laptop ~]$ curl
[ted@teds-laptop ~]$ curl
[ted@teds-laptop ~]$ curl
[ted@teds-laptop ~]$ curl

If you get a “connection refused error” check and see if SELinux is getting in the way.  You can do that by executing the following command on the server that is running the LBaaS service (server3 in my lab).

[root@server3 ~]# setenforce 0

If SELinux is blocking connections you have two options; you can use audit2allow to try to figure out what is causing SELInux to block connections.  In my case, it was because a boolean was not set properly.  In a lot of cases, audit2allow will tell you exactly what you need to do to fix issues with SELinux.

[root@server3 ~]# audit2allow -w -a
type=AVC msg=audit(1376067243.592:217379): avc: denied { name_connect } for pid=10739 comm="haproxy" dest=80 scontext=unconfined_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
Was caused by:
The boolean allow_ypbind was set incorrectly.
Allow system to run with NIS
Allow access by executing:
# setsebool -P allow_ypbind 1

And that’s it.  I hope you enjoyed this and will find many ways to use this OpenStack feature.

  1. Senthil Sivam says:

    Reblogged this on sendilsadasivam and commented:
    LBaas… new one in the block..

  2. web page says:

    Heya i’m for that key period here. I came across the following table we in discovering This process useful & the idea forced me to be available considerably. I hope offer a very important factor yet again and also help other individuals just like you served me personally.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s