Load Balancer as a Service (LBaaS)

Overview

The SysEleven Stack offers LBaaS via two different generations of APIs: Neutron LBaaSv2 (obsolete) and Octavia LBaaS.

Looking at the API definition both services are similar. But there are differences in the feature set provided by the SysEleven Stack.
With Neutron LBaaS only simple TCP-based load balancers are supported, with Octavia also HTTP and HTTPS can be used. Both services optionally allow to set up health monitoring.

The client IP address can only be made visible to the backend servers if an Octavia load balancer is used, in case of Neutron the backends will only see the IP address of the load balancer.

Quick comparison table

The following table compares the supported features of the two LBaaS services:

Cloud dashboard (Horizon)

Both LBaaS services can be managed in the cloud dashboard (Horizon) at cloud.syseleven.de under the Network category as "Neutron Load Balancers" and "Octavia Load Balancers" respectively.

Neutron LBaaSv2

Neutron load balancers can be maintained using the cloud dashboard (Horizon) at cloud.syseleven.de, or using the API and the neutron CLI (e.g. neutron lbaas-loadbalancer-list).

Limitations

• Only TCP-based load balancers are supported. For this reason, it is not possible to make the client IP address visible to the backend servers with Neutron LBaaSv2

Octavia LBaaS

Octavia is our more advanced load balancer option. Below you will find the reference documentation. If you want a quick start, please refer to our LBaaS tutorial.

Load balancing protocols

The load balancing protocol can be configured using the Octavia LBaaS listener resource (e.g. openstack loadbalancer listener create).

Only when using the HTTP and TERMINATED_HTTPS load balancing protocols, it is possible to use header insertion as well as l7 rules and policies.

With load balancers that use the TCP and HTTPS load balancing protocols, this is unfortunately not possible.

Health monitoring protocols

Adding a health monitor to your load balancer is optional, but we recommend it. Health monitors will make sure that only load balancer pool members that pass a certain test will be considered.

The test protocol (health monitor type) can be configured, among other things, using the Octavia LBaaS healthmonitor resource (e.g. openstack loadbalancer healthmonitor create).

Pool protocols

The pool together with the pool members represent a set of backend servers. It is possible to configure the protocol between backend and load balancer.

Using the special PROXY protocol it is possible to retrieve the client IP address, even with TCP or non-terminated HTTPS load balancing protocols. Please refer to the HAProxy documentation for a specification of the PROXY protocol.

Your application must support the PROXY protocol. It is possible to add a reverse proxy like nginx between your application and the Octavia loadbalancer to add PROXY support. The nginx documentation provides a how-to for receiving the proxy protocol.

There is a tutorial covering the process of configuring the PROXY protocol for nginx in MetaKube.

Distribution strategies

The distribution strategy controls how the load balancer chooses its backend.

Session persistence

Session persistence can be configured on the load balancer pool resource.

For load balancers of type HTTP and TERMINATED_HTTPS, we support the APP_COOKIE and HTTP_COOKIE session persistence methods. The SOURCE_IP session persistence method is supported for all load balancer types.

With APP_COOKIE the load balancer will use the specified cookie_name to send future requests to the same backend server (pool member).

Using HTTP_COOKIE, the load balancer will generate a cookie and insert it to the response.

Header insertion

Header insertion can be configured on the load balancer listener resource, for example using the command openstack loadbalancer listener create --insert-headers <HEADER>=true [..].

Header insertion is turned off by default. When turned on, the specified header with information about the request will be passed to the pool members.

Header insertion is only supported for the HTTP and TERMINATED_HTTPS load balancer methods. If you need the client IP address on your backend servers with other load balancer methods, consider the PROXY pool protocol.

L7 rules and policies

Using L7 policies the load balancer can perform actions defined in the L7 rule, when all the conditions defined in the associated L7 policies are met.

L7 policies are associated with a load balancer listener resource. The listener will evaluate them in order, sorted by the position parameter.

The action of the first matching L7 policy will be executed. The L7 policy matches, if all the L7 rules match (AND condition). If you need an OR condition, create multiple policies with the same action and different rules.

The L7 rule type is one of COOKIE, FILE_TYPE, HEADER, HOST_NAME, PATH, SSL_CONN_HAS_CERT, SSL_VERIFY_RESULT, and SSL_DN_FIELD.

L7 rules always compare a given value with a request value (specified by the rule type), using a compare_type (One of CONTAINS, ENDS_WITH, EQUAL_TO, REGEX, or STARTS_WITH).

Some rule types allow specifying a key. Using the key you can choose a specific COOKIE or HEADER by name.

The result can be optionally inverted using the invert parameter.

Load balancer flavors

The SysEleven Stack currently provides two flavors of Octavia Load Balancers:

The default load balancer flavor is failover-small which offers more performance and failure resilience. You may choose standalone-small instead for development setups to save some resources when failure resilience is not the top priority.

Default timeouts and connection limits

Octavia load balancers have the following default timeout and connection limits:

You may set different timeouts or limits in the configuration of the listener.

Topology limits

The total number of members (backends) across all pools of a load balancer is limited to 300.