SysEleven Stack provides load balancing through Load Balancer as a Service (LBaaS).
Currently the SysEleven Stack provides two APIs/services for Load Balancers: Octavia LBaaS and Neutron LBaaSv2. With the Neutron variant the SysEleven Stack only supports TCP-based load balancers, whereas with Octavia also HTTP and HTTPS are supported.
Please refer to our reference documentation for a more detailed comparison between Octavia LBaaS and Neutron LBaaS.
Below you will find two tutorials: how to set up an HTTP load balancer (using Heat for orchestration and Octavia load balancers) and how to set up a simple TCP load balancer (again using Heat for orchestration, but with Neutron load balancers).
The heat template examples used in the tutorials are available on Github.
git clone https://github.com/syseleven/heat-examples.git
This repository is used in both setups described below:
Octavia is currently in the public beta phase. This means we invite you to test Octavia load balancers, but we do not recommend you to use them for production workloads yet.
In this tutorial we demonstrate an Octavia LBaaS setup with the following features:
Open the folder containing the example code and create the stack providing your SSH key and the stack name.
$ cd heat-examples/lbaas-octavia-http
# openstack stack create -t lbstack.yaml --parameter key_name=<publicKeyName> <stackName>
$ openstack stack create -t lbstack.yaml --parameter key_name=exampleuser examplelb
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| id | f1ef864b-4acc-4e32-ac92-43c3551b794b |
| stack_name | examplelb |
| description | A Group of Load Balanced Servers |
| creation_time | 2018-03-01T10:03:48Z |
| updated_time | None |
| stack_status | CREATE_IN_PROGRESS |
| stack_status_reason | Stack CREATE started |
+---------------------+--------------------------------------+
By default the load balancer will accept connections from everywhere. In order to limit the incoming traffic to certain client IP address ranges you need to configure the listener with allowed CIDRs (one or multiple).
In our HEAT template example the listener's name is the stack name followed by "-listener", e.g. "examplelb-listener".
# openstack loadbalancer listener set --allowed-cidr 172.20.0.0/16 --allowed-cidr 10.0.0.0/8 <listener name>
$ openstack loadbalancer listener set --allowed-cidr 172.20.0.0/16 --allowed-cidr 10.0.0.0/8 examplelb-listener
It is not possible to remove individual CIDRs, so you have to overwrite the list of CIDRs with the new complete list. Or set it explicitly to 0.0.0.0/0 to allow access to everyone again.
The example code contains the LB floating IP in its output:
# openstack stack show <stack name> -f value -c outputs
$ openstack stack show examplelb -f value -c outputs
[
{
"output_value": "http://195.192.128.20:80",
"output_key": "lburl",
"description": "This URL is the \"external\" URL that can be used to access the load balancer.\n"
}
]
To retrieve only the URL use the following command:
# openstack stack output show <stack name> <output key> -c output_value -f value
$ openstack stack output show examplelb lburl -c output_value -f value
http://195.192.128.20:80
Open Anyapp in your browser via http://<loadbalancerIP>
which shows the IP of the currently-used backend server.
Open Anyapp in other tabs/windows to see the load balancer working.
With Neutron LBaasV2 only TCP-based load balancing is supported.
In contrast to Octavia-based stacks you have to attach a security group to the load balancer VIP port after the stack was created successfully.
In this tutorial we demonstrate a Neutron LBaaSv2 setup with the following features:
$ cd heat-examples/lbaas
# openstack stack create -t lbstack.yaml --parameter key_name=<publicKeyName> <stackName>
$ openstack stack create -t lbstack.yaml --parameter key_name=exampleuser examplelb
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| id | f1ef864b-4acc-4e32-ac92-43c3551b794b |
| stack_name | examplelb |
| description | A Group of Load Balanced Servers |
| creation_time | 2018-03-01T10:03:48Z |
| updated_time | None |
| stack_status | CREATE_IN_PROGRESS |
| stack_status_reason | Stack CREATE started |
+---------------------+--------------------------------------+
After a successful launch the whole setup will not be reachable from the outside until you bind a valid security group to the load balancer port. This step is necessary, because it is not possible to update ports in Heat.
See this link for more information on this.
Assign a security group to the port as follows:
openstack port set --security-group <Security Group> <LoadBalancer Port>
To make things easier for you, the example Heat template defines an output section that will format a valid openstack command for this port / security group assignment.
With the following command you can display the formatted port set
command:
openstack stack output show <stackName> sec_group_connection -c output_value -f value
The example code contains the LB floating IP in its output:
# openstack stack show <stack name> -f value -c outputs
$ openstack stack show examplelb -f value -c outputs
[
{
"output_value": "http://195.192.128.20:80",
"output_key": "lburl",
"description": "This URL is the \"external\" URL that can be used to access the load balancer.\n"
},
{
"output_value": "openstack port set --security-group 11764de3-3889-4be7-9627-3fb2e9431de1 447617cf-5818-4007-9909-ec3cf3fe4912",
"output_key": "sec_group_connection",
"description": "This command can be used to connect security groups to the load balancer port. After the LB is accessible from the outside."
}
]
To retrieve only the URL use the following command:
# openstack stack output show <stack name> <output key> -c output_value -f value
$ openstack stack output show examplelb lburl -c output_value -f value
http://195.192.128.20:80
Open Anyapp in your browser via http://<loadbalancerIP>
which shows the IP of the currently-used backend server.
Open Anyapp in other tabs/windows to see the load balancer working.
You should now be able to adapt this example to your needs. One of the things you might want to change are the upstream servers. The overall architecture should work for many scenarios.