The Networking service offers two load balancer implementations through theneutron-lbaas service plug-in:
- LBaaS v1: introduced in Juno (deprecated in Liberty)
- LBaaS v2: introduced in Kilo
Both implementations use agents. The agents handle the HAProxy configurationand manage the HAProxy daemon. LBaaS v2 adds the concept of listeners to theLBaaS v1 load balancers. LBaaS v2 allows you to configure multiple listenerports on a single load balancer IP address.
Another LBaaS v2 implementation, Octavia, has a separate API andseparate worker processes that build load balancers within virtual machines onhypervisors that are managed by the Compute service. You do not need an agentfor Octavia.
Currently, no migration path exists between v1 and v2 load balancers. If youchoose to switch from v1 to v2, you must recreate all load balancers, pools,and health monitors.
LBaaS v1¶
LBaaS v1 is deprecated in the Liberty release. These links provide moredetails about how LBaaS v1 works and how to configure it:
LBaaS v2¶
LBaaS v2 has several new concepts to understand:
![LBaaS v2 layout](https://i-blog.csdnimg.cn/blog_migrate/d176263bb199300c438a0cf37b1221c4.png)
-
Load balancer
- The load balancer occupies a neutron network port and has an IP addressassigned from a subnet. Listener
- Load balancers can listen for requests on multiple ports. Each one of thoseports is specified by a listener. Pool
- A pool holds a list of members that serve content through the load balancer. Member
- Members are servers that serve traffic behind a load balancer. Each memberis specified by the IP address and port that it uses to serve traffic. Health monitor
- Members may go offline from time to time and health monitors divert trafficaway from members that are not responding properly. Health monitors areassociated with pools.
LBaaS v2 has multiple implementations via different service plug-ins. The twomost common implementations use either an agent or the Octavia services. Bothimplementations use the LBaaS v2 API.
Configuring LBaaS v2 with an agent¶
-
Add the LBaaS v2 service plug-in to the service_plugins configurationdirective in /etc/neutron/neutron.conf. The plug-in list iscomma-separated:
service_plugins = [existing service plugins],neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
-
Add the LBaaS v2 service provider to the service_provider configurationdirective within the [service_providers] section in/etc/neutron/neutron.conf:
service_provider = LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
If you have existing service providers for other networking serviceplug-ins, such as VPNaaS or FWaaS, add the service_provider line shownabove in the [service_providers] section as a separate line. Theseconfiguration directives are repeatable and are not comma-separated.
-
Select the driver that manages virtual interfaces in/etc/neutron/lbaas_agent.ini:
[DEFAULT] interface_driver = INTERFACE_DRIVER
Replace INTERFACE_DRIVER with the interface driver that the layer-2agent in your environment uses. For example, openvswitch for OpenvSwitch or linuxbridge for Linux bridge.
-
Run the neutron-lbaas database migration:
neutron-db-manage --subproject neutron-lbaas upgrade head
-
If you have deployed LBaaS v1, stop the LBaaS v1 agent now. The v1 andv2 agents cannot run simultaneously.
-
Start the LBaaS v2 agent:
neutron-lbaasv2-agent \ --config-file /etc/neutron/neutron.conf \ --config-file /etc/neutron/lbaas_agent.ini
-
Restart the Network service to activate the new configuration. You are nowready to create load balancers with the LBaaS v2 agent.
Configuring LBaaS v2 with Octavia¶
Octavia provides additional capabilities for load balancers, including using acompute driver to build instances that operate as load balancers.The Hands on Lab - Install and Configure OpenStack Octaviasession at the OpenStack Summit in Tokyo provides an overview of Octavia.
The DevStack documentation offers a simple method to deploy Octaviaand test the service with redundant load balancer instances. If you alreadyhave Octavia installed and configured within your environment, you canconfigure the Network service to use Octavia:
-
Add the LBaaS v2 service plug-in to the service_plugins configurationdirective in /etc/neutron/neutron.conf. The plug-in list iscomma-separated:
service_plugins = [existing service plugins],neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
-
Add the Octavia service provider to the service_provider configurationdirective within the [service_providers] section in/etc/neutron/neutron.conf:
service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
Ensure that the LBaaS v1 and v2 service providers are removed from the[service_providers] section. They are not used with Octavia. Verifythat all LBaaS agents are stopped.
-
Restart the Network service to activate the new configuration. You are nowready to create and manage load balancers with Octavia.
Add LBaaS panels to Dashboard¶
The Dashboard panels for managing LBaaS v2 are available starting with theMitaka release.
-
Clone the neutron-lbaas-dashboard repositoryand check out the releasebranch that matches the installed version of Dashboard:
$ git clone https://git.openstack.org/openstack/neutron-lbaas-dashboard $ cd neutron-lbaas-dashboard $ git checkout OPENSTACK_RELEASE
-
Install the Dashboard panel plug-in:
$ python setup.py install
-
Copy the _1481_project_ng_loadbalancersv2_panel.py file from theneutron-lbaas-dashboard/enabled directory into the Dashboardopenstack_dashboard/local/enabled directory.
This step ensures that Dashboard can find the plug-in when it enumeratesall of its available panels.
-
Enable the plug-in in Dashboard by editing the local_settings.py fileand setting enable_lb to True in the OPENSTACK_NEUTRON_NETWORKdictionary.
-
If Dashboard is configured to compress static files for better performance(usually set through COMPRESS_OFFLINE in local_settings.py),optimize the static files again:
$ ./manage.py collectstatic $ ./manage.py compress
-
Restart Apache to activate the new panel:
$ sudo service apache2 restart
To find the panel, click on Project in Dashboard, then click theNetwork drop-down menu and select Load Balancers.
LBaaS v2 operations¶
The same neutron commands are used for LBaaS v2 with an agent or with Octavia.
Building an LBaaS v2 load balancer¶
-
Start by creating a load balancer on a network. In this example, theprivate network is an isolated network with two web server instances:
$ neutron lbaas-loadbalancer-create --name test-lb private-subnet
-
You can view the load balancer status and IP address with thelbaas-loadbalancer-show command:
$ neutron lbaas-loadbalancer-show test-lb +---------------------+------------------------------------------------+ | Field | Value | +---------------------+------------------------------------------------+ | admin_state_up | True | | description | | | id | 7780f9dd-e5dd-43a9-af81-0d2d1bd9c386 | | listeners | {"id": "23442d6a-4d82-40ee-8d08-243750dbc191"} | | | {"id": "7e0d084d-6d67-47e6-9f77-0115e6cf9ba8"} | | name | test-lb | | operating_status | ONLINE | | provider | haproxy | | provisioning_status | ACTIVE | | tenant_id | fbfce4cb346c4f9097a977c54904cafd | | vip_address | 192.168.1.22 | | vip_port_id | 9f8f8a75-a731-4a34-b622-864907e1d556 | | vip_subnet_id | f1e7827d-1bfe-40b6-b8f0-2d9fd946f59b | +---------------------+------------------------------------------------+
-
Update the security group to allow traffic to reach the new load balancer.Create a new security group along with ingress rules to allow traffic intothe new load balancer. The neutron port for the load balancer is shown asvip_port_id above.
Create a security group and rules to allow TCP port 80, TCP port 443, andall ICMP traffic:
$ neutron security-group-create lbaas $ neutron security-group-rule-create \ --direction ingress \ --protocol tcp \ --port-range-min 80 \ --port-range-max 80 \ --remote-ip-prefix 0.0.0.0/0 \ lbaas $ neutron security-group-rule-create \ --direction ingress \ --protocol tcp \ --port-range-min 443 \ --port-range-max 443 \ --remote-ip-prefix 0.0.0.0/0 \ lbaas $ neutron security-group-rule-create \ --direction ingress \ --protocol icmp \ lbaas
Apply the security group to the load balancer’s network port usingvip_port_id from the lbaas-loadbalancer-show command:
$ neutron port-update \ --security-group lbaas \ 9f8f8a75-a731-4a34-b622-864907e1d556
This load balancer is active and ready to serve traffic on 192.168.1.22.
-
Verify that the load balancer is responding to pings before moving further:
$ ping -c 4 192.168.1.22 PING 192.168.1.22 (192.168.1.22) 56(84) bytes of data. 64 bytes from 192.168.1.22: icmp_seq=1 ttl=62 time=0.410 ms 64 bytes from 192.168.1.22: icmp_seq=2 ttl=62 time=0.407 ms 64 bytes from 192.168.1.22: icmp_seq=3 ttl=62 time=0.396 ms 64 bytes from 192.168.1.22: icmp_seq=4 ttl=62 time=0.397 ms --- 192.168.1.22 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2997ms rtt min/avg/max/mdev = 0.396/0.402/0.410/0.020 ms
Adding an HTTP listener¶
-
With the load balancer online, you can add a listener for plaintextHTTP traffic on port 80:
$ neutron lbaas-listener-create \ --name test-lb-http \ --loadbalancer test-lb \ --protocol HTTP \ --protocol-port 80
-
You can begin building a pool and adding members to the pool to serve HTTPcontent on port 80. For this example, the web servers are 192.168.1.16and 192.168.1.17:
$ neutron lbaas-pool-create \ --name test-lb-pool-http \ --lb-algorithm ROUND_ROBIN \ --listener test-lb-http \ --protocol HTTP $ neutron lbaas-member-create \ --subnet private-subnet \ --address 192.168.1.16 \ --protocol-port 80 \ test-lb-pool-http $ neutron lbaas-member-create \ --subnet private-subnet \ --address 192.168.1.17 \ --protocol-port 80 \ test-lb-pool-http
-
You can use curl to verify connectivity through the load balancers toyour web servers:
$ curl 192.168.1.22 web2 $ curl 192.168.1.22 web1 $ curl 192.168.1.22 web2 $ curl 192.168.1.22 web1
In this example, the load balancer uses the round robin algorithm and thetraffic alternates between the web servers on the backend.
-
You can add a health monitor so that unresponsive servers are removedfrom the pool:
$ neutron lbaas-healthmonitor-create \ --delay 5 \ --max-retries 2 \ --timeout 10 \ --type HTTP \ --pool test-lb-pool-http
In this example, the health monitor removes the server from the pool ifit fails a health check at two five-second intervals. When the serverrecovers and begins responding to health checks again, it is added tothe pool once again.
Adding an HTTPS listener¶
You can add another listener on port 443 for HTTPS traffic. LBaaS v2 offersSSL/TLS termination at the load balancer, but this example takes a simplerapproach and allows encrypted connections to terminate at each member server.
-
Start by creating a listener, attaching a pool, and then adding members:
$ neutron lbaas-listener-create \ --name test-lb-https \ --loadbalancer test-lb \ --protocol HTTPS \ --protocol-port 443 $ neutron lbaas-pool-create \ --name test-lb-pool-https \ --lb-algorithm LEAST_CONNECTIONS \ --listener test-lb-https \ --protocol HTTPS $ neutron lbaas-member-create \ --subnet private-subnet \ --address 192.168.1.16 \ --protocol-port 443 \ test-lb-pool-https $ neutron lbaas-member-create \ --subnet private-subnet \ --address 192.168.1.17 \ --protocol-port 443 \ test-lb-pool-https
-
You can also add a health monitor for the HTTPS pool:
$ neutron lbaas-healthmonitor-create \ --delay 5 \ --max-retries 2 \ --timeout 10 \ --type HTTPS \ --pool test-lb-pool-https
The load balancer now handles traffic on ports 80 and 443.
Associating a floating IP address¶
Load balancers that are deployed on a public or provider network that areaccessible to external clients do not need a floating IP address assigned.External clients can directly access the virtual IP address (VIP) of thoseload balancers.
However, load balancers deployed onto private or isolated networks need afloating IP address assigned if they must be accessible to external clients. Tocomplete this step, you must have a router between the private and publicnetworks and an available floating IP address.
You can use the lbaas-loadbalancer-show command from the beginning of thissection to locate the vip_port_id. The vip_port_id is the ID of thenetwork port that is assigned to the load balancer. You can associate a freefloating IP address to the load balancer using floatingip-associate:
$ neutron floatingip-associate FLOATINGIP_ID LOAD_BALANCER_PORT_ID
Setting quotas for LBaaS v2¶
Quotas are available for limiting the number of load balancers and loadbalancer pools. By default, both quotas are set to 10.
You can adjust quotas using the quota-update command:
$ neutron quota-update --tenant-id TENANT_UUID --loadbalancer 25
$ neutron quota-update --tenant-id TENANT_UUID --pool 50
A setting of -1 disables the quota for a tenant.
Retrieving load balancer statistics¶
The LBaaS v2 agent collects four types of statistics for each load balancerevery six seconds. Users can query these statistics with thelbaas-loadbalancer-stats command:
$ neutron lbaas-loadbalancer-stats test-lb
+--------------------+----------+
| Field | Value |
+--------------------+----------+
| active_connections | 0 |
| bytes_in | 40264557 |
| bytes_out | 71701666 |
| total_connections | 384601 |
+--------------------+----------+
The active_connections count is the total number of connections that wereactive at the time the agent polled the load balancer. The other threestatistics are cumulative since the load balancer was last started. Forexample, if the load balancer restarts due to a system error or a configurationchange, these statistics will be reset.