OpenStack Load Balancer: Native vs. Third-Party Choices
OpenStack load balancer supports both native and third-party methods of load balancing, and each has its advantages and disadvantages.
What is load balancing? It is a technique used by service providers and IT departments to provide a mission critical service that is always available and scales per the user requests. There are several load balancing techniques and their approaches can differ among various implementations, with some being more intelligent than others:
- Round-Robin – distributes user requests across workloads in rotation. This is the most common, and the most basic, load balancing technique.
- Least Connection – monitors the load on each backend worker to determine where to serve the next user request from, rerouting requests to the workload with the least number of active connections, ensuring that workloads are distributed evenly.
- Agent Based Dynamic Load Balancing (ABDLB) – an independent software runs as a network administrator, able to learn and determine where to best distribute requests.
- Source IP Hash – a unique hash key is generated based on the source and destination IP addresses, then used to allocate the client to a specific server and ensure repeat connections.
- Weighted Response Time – taking into account server health, requests are directed to the server responding fastest at that time so as not to overload those currently responding slowly.
Why Load Balancing Is Important for Cloud Operations
As a developer delivering a mission critical service for your organization, you need to ensure that service will always be up, highly available, and performant. This can be achieved with load balancing by distributing the workload between many workers at the backend, while the front is managed by the load balancing service that is routing requests to different backends. Employing this technique, when the user requests increase, more workers can be added at the backend to take up that additional load. Similarly, when the load goes down, the workers in the back-end can be scaled back.
When preparing to handle calamities with your infrastructure, the backend can be planned so that it does not go down all at once and a portion of it can be served by the front-end load balancing service. If some workloads become unhealthy due to infrastructure issues or software bugs, the service remains available by using the healthy portion of the application cluster.
Additionally, the backend applications can be upgraded without interrupting users by replacing the workloads one by one. Due to these various unique capabilities, load balancing services are becoming essential in modern IT and application deployments to ensure low latency and highly available service.
Third Party Load Balancing with OpenStack Load Balancer
OpenStack has a well-known API called Load-Balancing as a Service (LBaaS), which is currently at version 2. This API can be backfilled by third party LBaaS services like AVI, F5 networks, etc.
When choosing a third party LBaaS solution, these key factors should be considered:
- Familiarity with the LBaaS – you already have an LBaaS system that is used and trusted in your IT department or cloud for non-OpenStack workloads, with automation set up around it and applications currently using it.
- Battle-tested LBaaS – the LBaaS has been tested in production first at scale and is known to perform under peak loads, providing proven solutions for production workloads.
Native Load Balancing with OpenStack Load Balancer
The native LBaaS service in OpenStack is called Octavia and it has been part of the OpenStack project since the Liberty release. This LBaaS has the distinct advantage of being fully compliant with the LBaaS v2 API and is maintained by an open source community. Developers already using OpenStack in their deployment might find it easier to use Octavia-based LBaaS as the next step in their cloud journey.
Octavia is also fully integrated with Keystone, is multi-tenant like all of their OpenStack services, and provides reference LBaaS implementation in OpenStack. If you have an application or a cloud deployment that works well with OpenStack, Octavia is an easier way to integrate LBaaS into the mix. The project community has endorsed Octavia as the LBaaS service implementation. The API will be moved to Octavia and its use with Neutron deprecated as of the Pike release.
- Kubernetes Service Mesh: A Comparison of Istio, Linkerd, and Consul - October 21, 2019
- Democratizing MySQL: From Cloud Managed to Kubernetes Managed - June 11, 2019
- Kubernetes Logging and Monitoring: The Elasticsearch, Fluentd, and Kibana (EFK) Stack – Part 2: Elasticsearch Configuration - September 12, 2018