OpenStack:Havana:LBaaS

From DocWiki

Jump to: navigation, search

Contents

Overview

This guide will provide a quick walk through of setting up OpenStack LBaaS (Load-Balancing as a Service) functionality that is now available as in the Cisco OpenStack Installer (COI) Havana Release 2 (H.2).

This guide can be used for configuring LBaaS pools on any H.2 release, but the networking topology is based on an example walk through from the OpenStack Havana All-in-One Guide. The specific scenario that was used for validating the LBaaS functionality found in this guide is the AIO with Per-Tenant Routers with Private Networks example.

Diagrams

You can review the diagram in Figure 1 to better understand the example topology: Figure 1


Figure 1: AIO Per-Tenant Router with Private Networks Diagram

AIO-H2.jpg




















The Networking Topology as seen by the OpenStack Dashboard shows the public network that connects to the internal private network via a Neutron router. There are two instances running Fedora that will be used to host our basic web page. Figure 2


Figure 2: Dashboard Network Topology

Lbaas net topo.jpg




















LBaaS Configuration

As was previously stated, the LBaaS functionality is now on by default in the COI H.2 release. All you have to do is configure LBaaS via CLI (not shown here) or via the OpenStack Dashboard.

In the example that will be shown in this document there will be two Fedora instances running (web-1 and web-2) and both are configured to run a basic Python module that acts as a web server. There will be a LBaaS Pool, VIP, Member servers, and optionally, an LBaaS monitoring service configured.

Step 1: Create an LBaaS Pool

In the example shown in Figure 3, the pool name is lb_pool_1 and has the following settings:

  • Provider = haproxy # This is the default unless you add plugins for other load balancers such as an F5
  • Subnet = 10.10.10.0/24 # This is the subnet that the instances are attached to and will be used to load balance against
  • Protocol = HTTP # Other options include: HTTPS and TCP
  • Load Balancing Method = ROUND_ROBIN # Other options include LEAST_CONNECTIONS and SOURCE_IP

Figure 3


Figure 3: LBaaS Pool

Lbaas pool 1.jpg

























Step 2: Add a VIP (Virtual IP)

The VIP will be used to logically represent, via an IP address, the member servers running behind the VIP. In the example shown in Figure 4 the VIP has the following settings:

  • Name = vip_1
  • Specify a free IP = 10.10.10.254 # This is a free IP address out of the same subnet range that the instances are located. This will will be used as the VIP IP address.
  • Protocol Port = 80 # This is the port that the VIP will be listening on. It must match that of the incoming requests.
  • Protocol = HTTP # Other options include: HTTPS and TCP
  • The other fields are left blank and you can investigate them on your own. If left blank, the "Connection Limit" field is set to "-1" which is unlimited.

Figure 4


Figure 4: LBaaS VIP

Lbaas vip 1.jpg

































Step 3: Launch the Instances

In the example shown in Figure 5 there are two instances running. You can launch these via the OpenStack Dashboard or via the 'nova boot' command. If you are following this document to the letter then you will need to launch a Fedora or Ubuntu image as the smaller Cirros image does not have the Python module installed that will act as the basic web server. Figure 5 shows the details of the two instances that were launched:

Figure 5


Figure 5: Instance View

Lbaas instance list.jpg









Step 4: Create a new Security Group or modify the 'default' Security Group

To allow for ping, SSH and HTTP access to the two instances that were launched in Step 3, open up the Security Group Rules as follows:

Figure 6


Figure 6: Security Group Rules

Lbaas sec group.jpg






Step 5: Add the Members to the LBaaS Pool

Once the instances are launched they will show up in the 'Add Members' interface. In the example shown in Figure 7, the following settings are:

  • Pool = lb_pool_1 # LBaaS pool created in step 1
  • Member(s) = web_1 and web_2
  • Protocol Port = 80 # This is the back-end port between the VIP and the Member servers. This port has to match the 'listening' port on the instance (i.e. port 80 for the sample HTTP app).

Figure 7


Figure 7: LBaaS Add Members

Lbaas add member.jpg



















Step 6: Setup a the Sample Web Server

Configure a basic index.html file on each node and run the Python module that will act as the basic web server.

Get a list of the running instances:

root@all-in-one:~# nova list
+--------------------------------------+-------+--------+------------+-------------+--------------------------+
| ID                                   | Name  | Status | Task State | Power State | Networks                 |
+--------------------------------------+-------+--------+------------+-------------+--------------------------+
| 877c496c-309c-4588-b378-9f7491882b83 | web_1 | ACTIVE | None       | Running     | Private_Net10=10.10.10.2 |
| cb1d84cd-9a78-4cac-b54e-ada8cfc5b7b2 | web_2 | ACTIVE | None       | Running     | Private_Net10=10.10.10.4 |
+--------------------------------------+-------+--------+------------+-------------+--------------------------+

Get the Neutron router-id:

root@all-in-one:~# ip netns
qlbaas-620258b5-669f-45d3-b14d-dabb867eb484
qdhcp-d7c039ae-6f11-429b-aaf9-10a2d659608a
qrouter-e9c35b5e-1778-431c-8b86-5f1a45dfafa9

Use the IP netns syntax to SSH into the first instance (this is assuming that you have already uploaded the appropriate keypair from the AIO setup documentation):

root@all-in-one:~# ip netns exec qrouter-e9c35b5e-1778-431c-8b86-5f1a45dfafa9 ssh fedora@10.10.10.2
The authenticity of host '10.10.10.2 (10.10.10.2)' can't be established.
RSA key fingerprint is bd:40:10:cd:21:96:5d:e6:ac:db:f8:17:20:14:1f:51.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.10.10.2' (RSA) to the list of known hosts.

Create a basic index.html file on the first instance:

[fedora@web-1 ~]$ sudo -i
[root@web-1 ~]# cat > index.html
HTTP/1.0 200 OK Web-1
^C

SSH into the second instance:

root@all-in-one:~# ip netns exec qrouter-e9c35b5e-1778-431c-8b86-5f1a45dfafa9 ssh fedora@10.10.10.4
The authenticity of host '10.10.10.4 (10.10.10.4)' can't be established.
RSA key fingerprint is e0:8a:3c:b2:c8:68:93:45:c9:f6:28:fe:7b:df:b2:49.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.10.10.4' (RSA) to the list of known hosts.
[fedora@web-2 ~]$ sudo -i
[root@web-2 ~]# cat > index.html
HTTP/1.0 200 OK Web-2
^C

Run the Python SimpleHTTPServer module that comes with Fedora and Ubuntu distributions:

[root@web-1 ~]# python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 ...
[root@web-2 ~]# python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 ...

Step 7: Validate the VIP and Web Servers

Run a WGET from the IP Namespace to ensure that the VIP is listening and can load-balance to each instance. The address that is used is the VIP address that was assigned in Step 2. Notice that when the WGET is run twice against the same VIP address that the LBaaS service in Neutron is performing ROUND_ROBIN per the policy:

root@all-in-one:~# ip netns exec qrouter-e9c35b5e-1778-431c-8b86-5f1a45dfafa9 wget -O - http://10.10.10.254
--2014-03-11 16:29:40--  http://10.10.10.254/
Connecting to 10.10.10.254:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22 [text/html]
Saving to: `STDOUT'

 0% [                               ] 0           --.-K/s   HTTP/1.0 200 OK Web-1
100%[==============================>] 22          --.-K/s   in 0s
root@all-in-one:~# ip netns exec qrouter-e9c35b5e-1778-431c-8b86-5f1a45dfafa9 wget -O - http://10.10.10.254
--2014-03-11 16:29:42--  http://10.10.10.254/
Connecting to 10.10.10.254:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28 [text/html]
Saving to: `STDOUT'

 0% [                                ] 0           --.-K/s   HTTP/1.0 200 OK Web-2
100%[===============================>] 28          --.-K/s   in 0s      

Step 8: Assign a FloatingIP address to the VIP

This step allows external clients access to the VIP and back-end web service. In the example shown in Figure 8, the following settings are:

  • IP Address = 192.168.81.11 # This is the FloatingIP address that came out of the pool of addresses on the Public network
  • Port to be associated = None: 10.10.10.254 # This is the VIP address that was configured in Step 2

Figure 8


Figure 8: Assign FloatingIP to VIP

Lbaas floating ip.jpg













Step 9: Validate that the FloatingIP

Ensure that the VIP is reachable and functioning from outside of the OpenStack environment. Use a web browser or WGET to access the VIP on the new public address. Refresh the browser a few times or re-run WGET to see the ROUND_ROBIN functionality:

root@all-in-one:~# wget -O - http://192.168.81.11
--2014-03-11 16:31:43--  http://192.168.81.11/
Connecting to 192.168.81.11:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22 [text/html]
Saving to: `STDOUT'

 0% [                               ] 0           --.-K/s   HTTP/1.0 200 OK Web-1
100%[==============================>] 22          --.-K/s   in 0s
root@all-in-one:~# wget -O - http://192.168.81.11
--2014-03-11 16:31:45--  http://192.168.81.11/
Connecting to 192.168.81.11:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28 [text/html]
Saving to: `STDOUT'

 0% [                                ] 0           --.-K/s   HTTP/1.0 200 OK Web-2
100%[===============================>] 28          --.-K/s   in 0s    

Step 10: Add an LBaaS Health Monitor

In the example shown in Figure 9, the following settings are:

  • Type = HTTP # Other options include PING, HTTPS, TCP
  • Delay = 5 # Test this value. The time, in seconds, between probes.
  • Timeout = 5 # Test this value. The time, in seconds, the monitor will wait for a reply.
  • Max Retries = 5 # Test this value. The time, in seconds, the monitor will retry the probe before it fails the Member server out of rotation.
  • HTTP Method = GET # Currently, this is the only HTTP Method supported.
  • URL = / # Indicates the root path from the Web server
  • Expected HTTP Status Codes = 200 * This is the code response the monitor expects to get back on each probe.

Figure 9


Figure 9: LBaas Add Monitor

Lbaas monitor.jpg




























Authors

Shannon McFarland (@eyepv6) - Principal Engineer

Rating: 5.0/5 (1 vote cast)

Personal tools