Load Balancer as a Service (Octavia)
Overview
firstcolo Cloud offers LBaaS with the openstack Octavia module.
Octavia LBaaS
Octavia is our advanced load balancer option. Below you will find the reference documentation. If you want a quick start, please refer to our LBaaS tutorial.
| Octavia LBaaS Feature | Supported in eu-central-1 region |
|---|---|
| Load balancing protocols | TCP, HTTP, HTTPS, TERMINATED_HTTPS |
| Health Monitoring protocols | PING, HTTP, TCP, HTTPS, TLS-HELLO |
| Pool protocols | PROXY, TCP, HTTP, HTTPS |
| Distribution strategies | ROUND_ROBIN, LEAST_CONNECTIONS, SOURCE_IP |
| Session persistence | Yes |
| Header insertion | Yes |
| L7 rules and policies | Yes |
| Load Balancer Flavors | Yes |
| VIP QoS policies | No |
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.
Distribution strategies
The distribution strategy controls how the load balancer chooses its backend.
| Distribution strategy | Description |
|---|---|
| ROUND_ROBIN | Distribute new requests evenly across all backends (pool members) |
| LEAST_CONNECTIONS | Choose the backend server with the least open connections from the load balancer |
| SOURCE_IP | Choose the backend server depending on the client IP address |
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.
| Header | Description |
|---|---|
| X-Forwarded-For | The client IP address |
| X-Forwarded-Port | The source port of the TCP connection to the client |
| X-Forwarded-Proto | The used protocol between the client and load balancer (Either http or https) |
| X-SSL-Client-Verify | Contains 0 if the client authentication was successful, or an error ID greater than 0. The error IDs are defined in the OpenSSL library |
| X-SSL-Client-Has-Cert | true if a client authentication certificate was presented, and false if not. Does not indicate validity. |
| X-SSL-Client-DN | Contains the full Distinguished Name of the certificate presented by the client |
| X-SSL-Client-CN | Contains the Common Name from the full Distinguished Name of the certificate presented by the client |
| X-SSL-Issuer | Contains the full Distinguished Name of the client certificate issuer |
| X-SSL-Client-SHA1 | Contains the SHA-1 fingerprint of the certificate presented by the client in hex string format |
| X-SSL-Client-Not-Before | Contains the start date presented by the client as a formatted string YYMMDDhhmmss[Z]. |
| X-SSL-Client-Not-After | Contains the end date presented by the client as a formatted string YYMMDDhhmmss[Z]. |
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.
| L7 Policy Action | Description |
|---|---|
| REDIRECT_TO_POOL | Will use a different load balancer pool for requests matching the L7 policy rules |
| REDIRECT_TO_PREFIX | Will concatenate the given prefix with the complete original URI path, and redirect to the resulting location. |
| REDIRECT_TO_URL | Will redirect to the given location |
| REJECT | The request is denied with the Forbidden (403) response code, and not forwarded on to any back-end pool |
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
firstcolo Cloud currently provides three flavors of Octavia Load Balancers:
| LB Flavor | Topology | Description |
|---|---|---|
| lb1.small | Active/Standby | Load balancer is implemented in two virtual machines in an active/standby setup. |
| lb1.medium | Active/Standby | Load balancer is implemented in two virtual machines in an active/standby setup. |
| lb1.large | Active/Standby | Load balancer is implemented in two virtual machines in an active/standby setup. |
The default load balancer flavor is lb-ap-small which offers more performance and failure resilience.
Default timeouts and connection limits
Octavia load balancers have the following default timeout and connection limits:
| Configuration parameter | Value |
|---|---|
| timeout-client-data | 50000ms |
| timeout-member-connect | 5000ms |
| timeout-member-data | 50000ms |
| connection-limit | 50000 |
You may set different timeouts or limits in the configuration of the listener.
Availability Zones
When creating a load balancer, an availability zone can be specified in addition to the flavor used. If no zone is explicitly assigned during creation, the load balancer is created in the AZ-1 zone. The following zones are currently supported for load balancers:
| Zone |
|---|
| AZ-1 |
| AZ-2 |
Topology limits
The total number of members (backends) across all pools of a load balancer is limited to 300.