To demonstrate the creation and use of load balancers in Neutron, this next section is dedicated to building a functional load balancer based on the following scenario:
A tenant has a simple Neutron network set up with a router attached to both an external provider network and internal tenant network. The user would like to load balance HTTP traffic between two instances running a web server. Each instance is configured with an index.html page containing a unique server identifier.
To eliminate the installation and configuration of a web server for this example, you can mimic the behavior of one using the SimpleHTTPServer Python module on the instances, as follows:
ubuntu@web1:~$ echo "This is Web1" > ~/index.html ubuntu@web1:~$ sudo python -m SimpleHTTPServer 80 Serving HTTP on 0.0.0.0 port 80 ...
Repeat the mentioned commands for the second instance, substituting Web2 for Web1 in the index.html file.
The first step to building a functional load balancer is to create a pool. Using the Neutron lb-pool-create command, create a pool with the following attributes:
- Name:
WEB_POOL - Load balancing method:
Round robin - Protocol:
HTTP - Subnet ID:
<Subnet ID of the pool members>
Figure 10.3
The next step to building a functional load balancer is to create and associate pool members with the pool.
In this environment, there are two instances eligible for use in the pool:
Figure 10.4
Using the Neutron lb-member-create command, create two pool members with the following attributes based on the nova list output:
- Member 1:
- Name:
WEB1 - Address:
10.30.0.7 - Protocol port:
80 - Pool:
WEB_POOL
- Name:
- Member 2:
- Name:
WEB2 - Address:
10.30.0.8 - Protocol port:
80 - Pool:
WEB_POOL
- Name:
The following screenshot demonstrates the process of creating the first pool member:
Figure 10.5
Repeat the process shown in the preceding screenshot to create the second pool member.
The Neutron lb-member-list command returns a list showing the two pool members but does not list their associated pools:
Figure 10.6
As a workaround, you can include certain columns to be returned, as shown in the following figure:
Figure 10.7
To provide high availability of an application to clients, it is recommended to create and apply a health monitor to a pool. Without a monitor, the load balancer will continue to send traffic to members that may not be available.
Using the Neutron lb-healthmonitor-create command, create a health monitor with the following attributes:
- Delay:
5 - Max retries:
3 - Timeout:
4 - Type:
TCP
Figure 10.8
To associate the newly created health monitor with the pool, use the lb-healthmonitor-associate command, as follows:
lb-healthmonitor-associate HEALTH_MONITOR_ID POOL
Now, consider the following screenshot:
Figure 10.9
The last step in creating a function load balancer is to create the virtual IP, or VIP, which acts as a listener and balances traffic across pool members. Using the Neutron lb-vip-create command, create a virtual IP with the following attributes:
- Name:
WEB_VIP - Protocol port:
80 - Protocol:
HTTP - Subnet ID:
<Subnet ID of Pool> - Pool:
WEB_POOL
Figure 10.10
Once the virtual IP is created, the state of the VIP and pool will change to ACTIVE:
Figure 10.11
A listing of the network namespaces on the host running the LBaaS agent reveals a network namespace that corresponds to the load balancer just created:
Figure 10.12
The IP configuration within the namespace reveals an interface that corresponds to the subnet of the virtual IP:
Figure 10.13
Neutron creates an HAProxy configuration file specific to every load balancer created by users. The load balancer configuration files can be found in the /var/lib/neutron/lbaas/ directory of the host running the LBaaS agent.
The configuration file for this load balancer built by Neutron can be seen in the following screenshot:
Figure 10.14
From within the router namespace, confirm direct connectivity to WEB1 and WEB2 via their respective addresses over port 80 using curl:
Figure 10.15
By opening multiple connections to the virtual IP 10.30.0.9 within the router namespace, you can observe a round robin load balancing in effect:
Figure 10.16
With round robin load balancing, every connection is evenly distributed among the two pool members.
A packet capture on WEB1 reveals that the load balancer is performing TCP checks its health every 5 seconds:
Figure 10.17
In the preceding output, the load balancer sends a TCP SYN packet every 5 seconds and immediately sends a RST upon receiving the SYN ACK from the pool member.
To observe the monitor removing a pool member from eligibility, stop the web service on Web1 and observe the packet captures and logs:
Figure 10.18
In the preceding output, the web service is stopped and connections to port 80 are refused. Immediately following the third failure, the load balancer marks the pool member as DOWN:
Figure 10.19
While WEB1 is down, all subsequent connections to the VIP are sent to WEB2:
Figure 10.20
After restarting the web service on WEB1, the load balancer places the server back in the pool upon the next successful health check:
Figure 10.21
To connect to a virtual IP externally, a floating IP must be associated with the VIP because the virtual IP exists within a subnet behind the router and is not reachable directly.
Using the Neutron floatingip-create command, assign a floating IP to be used with the virtual IP:
Figure 10.22
A test from a workstation to the floating IP confirms external connectivity to the load balancer and its pool members:
Figure 10.23