Home > user > design > Load Balancer Component

Load Balancer Component

The lb component is of core importance and part of most platforms since it defines the load balancing of request being received by the platform.

You can configure the lb component as part of your platform in design phase and specific to an environment in the transition phase.

Once your assembly is deployed in an environment you can access the lb in operation.


Besides the global configuration available for any component such as Name, you can configure the following attributes:

LB Service Type: Defines type of LoadBalancing service to use. Two options available:

  • lb: for physical loadbalancer service e.g. Citrix Netscaler.
  • slb: for software loadbalancer service e.g. Octavia from the openstack project.

Switching the service type after an initial deployment is not advised and can lead to inconsistent state of the deployed system.

Listeners: Defines the ports that the LB will be listing on for incoming traffic.

LB Method: Defines the protocol used to forward traffic to balance the load to the servers. Two methods are available described below:

  • Least Connection Method: The default method, when a virtual server is configured to use the least connection, it selects the service with the fewest active connections.
  • Round Robin Method: This method continuously rotates a list of services that are attached to it. When the virtual server receives a request, it assigns the connection to the first service in the list, and then moves that service to the bottom of the list.

Session Persistence: Directs the LB to send related requests to the same server. Additional attributes described below if session persistence is checked. Persistence Type, Cookie Domain and LB Custom Attributes are shown when Session Persistence is checked.

  • Persistence type: Defines the method the LB will provide the persistence. Two available are described below.v
    • SourceIP: The LB caches the IP of the server to send related traffic to.
    • Cookieinsert: The LB caches a cookie for a period of time which directs the traffic.
  • Cookie Domain: Defines the domain where the cookie is valid.

Create Cloud vips: Vips at the cloud level are available by default. This checkbox will allow the vips to be avaialble to all cloud regions in the data center.

Enable LB Group: Used to enable the LB group for persistence across all listeners.

LB Custom Attributes: Used to define and utilize additional attributes avaialble on the LB’s. Examples of this are: Enable Access Logs and Configure Connection Draining. (ex. Key/Value - ConnectionDraining/Enabled: True,Timeout: 300). Please check for the available attributes for your lb’s.

Required Availability Zone: Used to horizontally scale physical LB Devices.

Connection Limit: Applicable only for software loadbalancers. The maximum number of connections per second allowed for the vip. Valid values: a positive integer or -1 for unlimited (default).

ECV: Used to define service monitors. (ex. 80 => GET /someservice/node). Port-available monitors are used for tcp(s) and udp.

Note: Currently ECV checks will use TCP on Azure. If your app server (ex. Tomcat) is listeneing on port HTTP 8443 and runs out of listeners, the lb will think the server is still listening and direct traffic to it. Please be aware.

ServiceGroup Custom Attrs: Used to define additional attributes available to the Server Groups defined. Examples of these are: servicegroupname, servicetype, maxclient, cipheader. Please check for the available attributes for your lb’s.

Octavia Software Load Balancer

Octavia is an open source scalable software load balancer that is part of the OpenStack ecosystem. Compared to using physical load balancers such as Netscaler, it can increase operational efficiency and reduces outages.

Octavia and barbican service need to be enabled in the OpenStack cloud to use this feature.

The connection limit parameters is only applicable for software loadbalancer and set the maximum number of connections per second allowed for the virtual IP. Valid values are a positive integer or -1 for unlimited (default).

SLB listener options available are explained below.

Octavia SLB offers all three types of LB connections as available in Physical Netscalars. Listener configurations for each type is explained in the following.

Non-Secure Load balancer

An unencrypted, non-secure LB connection uses HTTP with a listener configuration such as:

http 80 http 8080

This configuration forwards any incoming requests on port 80 to the internal port 8080.

Non-Terminated HTTPS Load Balancer

This type of connection enables end to end SSL encryption with HTTPS.

https 443 https 8443

Any incoming requests on the default HTTPS port 443 are forwarded to the internal computes at 8443. It is necessary to configure the needed certificate in the ssl-certificate-component.

The certificate is copied to the backend servers and certificate verification is done at the backend.

Terminated HTTPS Load Balancer

This type of connection allows SSL encryption between client and the load balancer. Connectivity from the load balancer to the backend servers is unencrypted:

terminated_https 443 http 8080

This configuration takes incoming HTTPS requests on port 443 and forwards them as HTTP requests to port 8080. The advantage of this configuration is that it requires no certificate configuration on the computes.

It is necessary to configure the certificate in the ssl-certificate-component. The certificate is copied to the load balancer only and certificate verification is done at the load balancer.

Usage of the terminated HTTPS load balancer configuration requires the barbican service in the openstack cloud. Certificate details entered in lb-certificate component are converted to barbican secret and containers for octavia load balancer to use with the TLS_Termination option.