LBaaS version 2

LBaaS is short for 'Load balancer as a Service' an in City Cloud we do offer the LBaaS version 2 that was first introduced in the OpenStack version named 'Kilo'. LBaaS version 1 was deprecated in OpenStack version 'Liberty' and in hence not available in City Cloud (current version is based on the 'Train' release).

The implementations use agents. The agents handle the HAProxy configuration and manage the HAProxy daemon. LBaaS v2 allows for configuring multiple listener ports on a single load balancer IP address.

Another LBaaS v2 implementation, further described at our Octavia page, has a separate API and separate worker processes that build load balancers within virtual machines on hypervisors that are managed by the Compute service. You do not need an agent for Octavia.

LBaaS v2 has some concepts to understand:

LBaaS v2 layout


  • Load balancer
    The load balancer occupies a neutron network port and has an IP address assigned from a subnet.
  • Listener
    Load balancers can listen for requests on multiple ports. Each one of those ports 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 member is 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 traffic away from members that are not responding properly. Health monitors are associated with pools.

LBaaS v2 has multiple implementations via different service plug-ins. The two most common implementations use either an agent or the Octavia services. Both implementations use the LBaaS v2 API

Building an LBaaS v2 load balancer

  1. Start by creating a load balancer on a network. In this example, the private network is an isolated network with two web server instances:

    $ neutron lbaas-loadbalancer-create --name test-lb private-subnet
  2. You can view the load balancer status and IP address with the lbaas-loadbalancer-show command:

    +---------------------+------------------------------------------------+
    | 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           |
    +---------------------+------------------------------------------------+
  3. 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 into the new load balancer. The neutron port for the load balancer is shown as vip_port_id above.

    Create a security group and rules to allow TCP port 80, TCP port 443, and all 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_idfrom thelbaas-loadbalancer-showcommand:

    $ 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.
  4. 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

  1. With the load balancer online, you can add a listener for plaintext HTTP traffic on port 80:

    $ neutron lbaas-listener-create \
      --name test-lb-http \
      --loadbalancer test-lb \
      --protocol HTTP \
      --protocol-port 80
  2. You can begin building a pool and adding members to the pool to serve HTTP content on port 80. For this example, the web servers are192.168.1.16and192.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
  3. You can usecurlto verify connectivity through the load balancers to your 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 the traffic alternates between the web servers on the backend.

  4. You can add a health monitor so that unresponsive servers are removed from 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 if it fails a health check at two five-second intervals. When the server recovers and begins responding to health checks again, it is added to the pool once again.

Adding an HTTPS listener

You can add another listener on port 443 for HTTPS traffic. LBaaS v2 offers SSL/TLS termination at the load balancer, but this example takes a simpler approach and allows encrypted connections to terminate at each member server.

  1. 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
  2. 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 are accessible to external clients do not need a floating IP address assigned. External clients can directly access the virtual IP address (VIP) of those load balancers.

However, load balancers deployed onto private or isolated networks need a floating IP address assigned if they must be accessible to external clients. To complete this step, you must have a router between the private and public networks and an available floating IP address.

You can use thelbaas-loadbalancer-showcommand from the beginning of this section to locate thevip_port_id. Thevip_port_idis the ID of the network port that is assigned to the load balancer. You can associate a free floating IP address to the load balancer usingfloatingip-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 load balancer pools. By default, both quotas are set to 10.

You can adjust quotas using thequota-updatecommand:

$ 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 balancer every six seconds. Users can query these statistics with the lbaas-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 were active at the time the agent polled the load balancer. The other three statistics are cumulative since the load balancer was last started. For example, if the load balancer restarts due to a system error or a configuration change, these statistics will be reset.