Understanding OpenStack Load Balancing as a Service


Understanding OpenStack Load Balancing as a Service

Rackspace recently released version 12.2 of Rackspace Private Cloud powered by OpenStack. My colleague, Walter Bentley, provided details in a series of blog posts, which included a post on OpenStack Neutron Load Balancing as a Service. Since LBaaS is still a relatively new offering in the OpenStack community, Walter and I want to provide more details to help users understand what LBaaS does and how it can be used in an OpenStack cloud. Tomorrow, Walter will cover a use case for LBaaS, specifically autoscaling. Today's post will provide a technical overview of LBaaS by answering four questions:

  1. What is load balancing and Load Balancing as a Service?
  2. How does LBaaS work in OpenStack?
  3. What does Rackspace recommend for load balancing in RPC?
  4. What may be the future of LBaaS in RPC?

What is Load Balancing and LBaaS

For those who may be new to the concept, load balancing is a technology that has been around for some time and is a foundation for delivering highly available resources over a network. At a high level, load balancing is typically accomplished by having a load balancer or set of load balancers present a virtual server to a set of clients. This virtual server is backed by a pool of “real” servers that provide some type of resource to those clients. The role of the load balancer is to distribute client requests across the pool of servers including rerouting requests when a member of the pool fails. Clients are not aware which “real” server in the pool are servicing their requests since they are only aware of the virtual server presented by the load balancer. By leveraging load balancers, client requests can be serviced in such a way as to mitigate against bottlenecks due to resource contention on any given server or against failed requests due to failures on any given servers. The former use case is what is often considered scaling out while the latter is about creating a fault tolerant service. The canonical example is the use of load balancers in front of a pool of web servers to serve out web pages to incoming clients via the internet. LBaas Historically, load balancers have been hardware devices, either general or purpose built, that balance requests across a pool of physical servers. With the advent of the cloud, we are seeing more use cases where software or virtual load balancers are used to provide services to a pool of virtual servers. Rackspace’s public cloud, for example, offers Cloud Load Balancers to our customers to use in front of Cloud Servers, which are virtual machines. LBaas But note that while virtual load balancers are often used with virtual servers, that is not an absolute requirement. You can in fact use hardware load balancers with virtual servers and vice versa. There are a number of benefits to using virtual load balancers including allowing users to provision load balancers on demand and in the case of metered clouds, allowing users to pay for load balancing services on a utility basis. These two benefits are often what user think of when they talk about Load Balancing as a Service.

OpenStack and LBaaS

The OpenStack Neutron project is currently on version 2 of its LBaaS implementation. LBaaS v2 seeks to address some of the limitations in v1, including a lack of scalability and a lack of flexibility in how LBaaS could be configured. Since LBaaS v1 has been deprecated in the Liberty release and in RPC v12.2, we’ll focus on v2. LBaas OpenStack LBaaS leverages agents that control the HAProxy configuration and manage the HAProxy daemon. HAProxy is a popular open source software that provides TCP/HTTP load balancing and is the default load balancing engine for OpenStack Load balancers. These HAProxy based load balancers have network access to clients and to the member servers which answer client requests by requesting and receiving Neutron networks ports and IP Addresses. A significant change in LBaaS v2 is the addition of Listeners. A Listener is mapped to and listens for requests made to a given network port. In LBaaS v1, a load balancer could only have one listener per load balancer. With v2, uses can create multiple Listeners for a load balancer, allowing requests to come in via multiple network ports. Another significant change is the additional option of using an alternate implementation of LBaaS called Octavia. Octavia is fully integrated with Neutron and LBaaS v2 and provides additional capabilities such as allowing users to deploy redundant load balancer instances.

The Present and Future of LBaaS in Rackspace Private Cloud

So why is OpenStack LBaaS, even with v2, only in technical preview in RPC v12.2? As I iterated when v12.2 became generally available, we don’t currently view LBaaS as production ready, either in its default implementation or in its new reference implementation with Octavia. The reason for this determination is that the default implementation of LBaaS has certain scalability limits and does not support redundant load balancers. While Octavia does address some of this by allowing redundant load balancer instances to be provisioned, Rackspace engineers determined that Octavia was not quite mature enough to provide the level of service RPC customers demand. We believe, however, there is value for customers to have access to LBaaS as a technical preview in certain test/dev environments, and so that they can become familiar with the LBaaS APIs. In a future release, we will provide full support for LBaaS, when it is ready, using the same APIs that are available as part of the technical preview. We are also continually evaluating Octavia to see when it will reach a level of maturity where we can use it as the RPC implementation of LBaaS. In the interim, RPC customers have another option for load balancing in their OpenStack clouds. Rackspace has a long standing partnership with F5, a company that specializes in making purpose built hardware load balancers. We use F5 appliances throughout the Rackspace data centers and they are part of the RPC reference architecture which uses these appliances to load balance API request to OpenStack control planes. Given that history, we are very comfortable recommending that customers use F5 to provide load balancing for and fault tolerance to their networked applications. Hopefully, we have piqued your interest in trying out Load Balancing as a Service, even as a technical preview in RPC v12.2. Stay tuned for upcoming resources that will walk you through how to setup LBaaS and the relevant use cases for enabling this service in your OpenStack cloud.

Realize the Full Value of the Cloud Today