This is the first in a series of posts by speakers at the Hong Kong OpenStack Summit. Today we bring you a discussion of Havana’s load balancing features, from Eugene Nikanorov and Ilya Shakhat. Their talk, “Load Balancing in OpenStack“, is scheduled for Thursday, November 7, from 4:30pm to 5:10pm.
Put all the bricks together for production-ready load balancing: multi-vendor support in Neutron LBaaS, elasticity via Heat templates, and service monitoring via Ceilometer. This session will cover new features introduced in the Havana release cycle, and will briefly cover how to write vendor drivers for the service. The talk also will cover the roadmap planned for Icehouse.
We’ve asked Eugene and Ilya for a short discussion of this topic.
Load Balancing in OpenStack
Havana’s Load Balancer-as-a-Service (LBaaS) development has mostly focused on creating a vendor-friendly infrastructure that zeroes in on two major goals, enabling:
- Vendors to create their own drivers with the architecture they want.
- Cloud operators to use different types of load balancers (and choose the provider that implements the service).
The first of these goals is achieved through a plugin driver–a server-side piece of code that performs vendor-specific steps. Such steps may include communicating with a remote agent that actually configures the device, or communicating with the device directly. Also, significant efforts have been put toward improving the existing HAProxy-based implementation.
One of the major new features of this implementation is the ability to have more than one LBaaS agent in the cloud, which was not available in the Grizzly release. That helps to distribute the load between nodes and makes the HAProxy implementation more production-ready.
Plans for the next release cycle include the following features and changes:
- Object model change
- One big flexibility limitation of the existing LBaaS object model is the 1:1 VIP-Pool relationship. Most load balancers now support more a flexible m:n relationship, allowing you to bind several VIPs to a single pool, and vice versa.
- Another change stemming from the one above is the new notion of a “service instance.” This is a new object that allows users to think of load balancer resources in a more intuitive way. It also allows users to bind the group of resources to certain appliance or provider.
- LBaaS API extensibility
- At the moment, LBaaS is a Neutron API extension. The plan is to make the LBaaS API a part of the core, and then utilize the extension framework so vendor plugin drivers can add their specific API extensions and functionality.
For more information about the LBaaS project, please visit the LBaaS wiki.
Eugene Nikaronov, a Mirantis Senior Software Engineer, is a Neutron contributor and an LBaaS developer. In his own words, he likes “fixing code and making things work.” Ilya Shakhat is a Mirantis Community Group Lead. He joined the OpenStack Community during the Grizzly cycle and has participated in implementation of the load balancing as a service feature in Quantum/Neutron.
Headed to the Hong Kong OpenStack Summit? Up your OpenStack game with a 3-day bootcamp for OpenStack!