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
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
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
- 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
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
- 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
Enable LB Group: Used to enable the LB group for persistence across all
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
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
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
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
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:
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.
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 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
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
certificate component. The certificate
is copied to the load balancer only and certificate verification is done at the
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.