The Neutron Load Balancing as a Service extension, known as LBaaS, provides users with the ability to load balance traffic to applications running on virtual instances in the cloud. Neutron provides an API to manage virtual IPs, pools, pool members, and health monitors.
In this chapter, we will cover some fundamental load balancing concepts, including:
- Virtual IPs, pools, and pool members
- Load balancing algorithms
- Monitors
- Persistence
Neutron uses drivers to interact with hardware or software load balancers. In Kilo, the reference driver interacts with HAProxy. HAProxy is a free, open source load balancer that is available for most Unix-based operating systems. Third-party drivers are supported by LBaaS but are outside the scope of this book.
In this chapter, we will work through the following:
- Integrating load balancers into the network
- Installing and configuring the LBaaS agent
- Creating a load balancer
- Demonstrating load balanced traffic to instances
The LBaaS API underwent a major overhaul over the last few release cycles, which resulted in version 2 of the API. This chapter, however, focuses on version 1. Most of the concepts described throughout this chapter directly apply to both versions of the API, though the syntax to implement various components may differ.
There are three major components to a load balancer in Neutron:
- Pool members
- Pools
- Virtual IPs
A pool member is a layer 4 object that is composed of the IP address and listening port of a service. For example, a pool member might be a web server with a configured IP address of 10.30.0.2 listening on TCP port 80.
A pool is a group of pool members that typically serve identical content. A pool composed of web servers, for example, may resemble the following membership:
- Server A:
10.30.0.2:80 - Server B:
10.30.0.4:80 - Server C:
10.30.0.6:80
A virtual IP, or VIP, is an IP address that resides on the load balancer and listens for incoming connections. The load balancer then balances client connections among the members of the associated pool. A virtual IP is usually exposed to the Internet and often mapped to a domain name.
In version 1 of the LBaaS API, the following load balancing algorithms can be applied to a pool:
- Round robin
- Least connections
- Source IP
With the round robin algorithm, the load balancer passes each new connection to the next server in line. Over time, all connections are distributed evenly across all machines being load balanced. Round robin is the least resource-intensive algorithm and has no mechanism to determine when a machine is being overwhelmed by connections. To avoid overwhelming a pool member, all members should be equal in terms of processing speed, connection speed, and memory.
With the least connections algorithm, the load balancer passes a new connection to a server that has the least number of current connections. It is considered a dynamic algorithm as the system keeps track of the number of connections attached to each server and balances traffic accordingly. Pool members of higher capabilities would likely receive more traffic as they are able to process connections quicker.
With the source IP algorithm, all connections originating from the same source IP address are sent to the same pool member. Connections are initially balanced using the round robin algorithm and then tracked in a table for future lookup with subsequent connections from the same IP address. This algorithm is useful in cases where the application requires clients to persist to a particular server for all requests, such as an online shopping cart that stores session information on the local web server.
The LBaaS API supports multiple monitor types, including TCP, HTTP, and HTTPS. The TCP monitor tests connectivity to pool members at layer 4, while the HTTP and HTTPS monitors test the health of pool members based on the layer 7 HTTP status codes.
LBaaS supports session persistence, otherwise known as sticky sessions or session affinity, on virtual IPs. Session persistence is a method of load balancing that forces multiple client requests of the same protocol to be directed to the same node. This feature is commonly used with many web applications that do not share an application state among pool members.
The types of session persistence supported with the HAProxy driver include the following:
SOURCE_IPHTTP_COOKIEAPP_COOKIE
Using the SOURCE_IP persistence type configures HAProxy with the following settings within the backend pool configuration:
stick-table type ip size 10k stick on src
The first time a client connects to the virtual IP, HAProxy creates an entry in a sticky table based on the client's IP address and sends subsequent connections from the same IP address to the same backend pool member. Based on the configuration, up to 10,000 sticky entries can exist in the sticky table. This persistence method can cause a load imbalance among pool members if users connect from behind a proxy server that identifies multiple clients as a single address.
Using the HTTP_COOKIE persistence type configures HAProxy with the following settings within the backend pool configuration:
cookie SRV insert indirect nocache
The first time a client connects to the virtual IP, HAProxy balances the connection to the next pool member in line. When the pool member sends its response, HAProxy injects a cookie named "SRV" into the response before sending it to the client. The value of the SRV cookie is a unique server identifier. When the client sends subsequent requests to the virtual IP, HAProxy strips the cookie from the request header and sends the traffic directly to the pool member identified in the cookie. This persistence method is recommended over source IP persistence as it is not reliant on the IP address of the client.
Using the APP_COOKIE persistence type configures HAProxy with the following settings within the backend pool configuration:
appsession <CookieName> len 56 timeout 3h
When an application cookie is defined in a backend, HAProxy checks when the server sets such a cookie, stores its value in a table, and associates it with the server's identifier. Up to 56 characters from the value are retained. On subsequent client connections, HAProxy looks for the cookie. If a known value is found, the client is directed to the pool member associated with the value. Otherwise, the round-robin load balancing algorithm is applied. Cookies are automatically removed from memory when they go unused for longer than three hours.