- make API comparison between PayPal, Atlas, Mirantis, and Amazon ELB. based on that, drive creation of “next-gen” unified API for tenants and cloud administrators
Networking (tighter integration with OpenStack)
- nova-network: currently the tenant has to explicitly specify IP and VLAN for incoming public traffic. this information needs to be taken from the Nova database instead and should in any case be validated against the Nova database to check that this VLAN belongs to the tenant
- Quantum: build a prototype with HAProxy as a virtual software load balancer, demonstrate connectivity to the right networks and IMAP through Quantum
- long-term, make a decision on whether LBaaS can exist as a standalone service or will be closely tied to Quantum
- make sure LBaaS supports HA configurations of load balancers. such as active/standby and active/active configuration
- need to develop for per-tenant resource limits in LBaaS
- must agree on the approach. there can be different variations:
- software-based load balancers: if we they will be provisioned through nova on behalf of a tenant, we can use nova resource limits (everything is allowed, as long as a virtual machine with HAProxy can be instantiated)
- hardware-based load balancers: either allow cloud administrator to partition each device manually and manually assign tenant to individual partition (will work well in case of private clouds with small, pre-defined number of tenants). or, have LBaaS enforce per-tenant resource limits
Server Farm Monitoring and Statistics
- need to enhance API to support usage statistics of the load balancer, such as the number of succeeded/failed requests, the distribution of request latencies etc. This information is very important and should definitely be exposed through the API.
Integration with Quantum
- Quantum network manager, new in OpenStack releases since Folsom (2012), allows to explicitly represent and manipulate the network topology in a unified way as a graph of nodes and devices connected through ports. Using load balancers as “devices” has been explicitly anticipated by the designers of Quantum. This naturally allows to easily build complex network topologies combining load balancers and other network devices, such as WAN accelerators, firewalls etc.
Software Load Balancers on Demand
- Currently the software doesn’t support spawning a new instance of software load balancers such as HAProxy: you must have a pre-launched instance, and LBaaS will merely configure this instance. We should definitely address this by automatically launching software load balancer VMs on behalf on a tenant, when needed
Drivers for more LBs
- The first step would be open-sourcing HAProxy, Cisco ACE, and F5 BigIP. The next candidate is nginx.
- Engage community to contribute their drivers: Riverbed (Stingray/Zeus), Citrix (Netscaler), Radware, etc.
- Using the load balancing device as an SSL proxy has several benefits: it reduces the CPU load on the back-end servers and allows the LB to make routing decisions based on the content of the HTTP packets (which would otherwise be impossible, since packets are traveling encrypted). Many hardware LB devices support this mode. It is planned to expose this support through API.
- We do not plan to add auto-scaling capabilities into the LBaaS service proper, as it would introduce too much coupling between it and other nova components. However, it is worth considering the implementation of a separate component which interacts both with the LBaaS API and the nova API and controls auto-scaling based on the current load on used VMs.