Neutron LBaaS Requirements
Overview
Every cloud operator, vendor, etc. that wants load balancing as a service (LBaaS) has a different view on what load balancing is and how it should work. The goal of this page is to list overall requirements and use cases for the Neutron LBaaS plugin in an effort to concretely understand everyone's view on what load balancing is and how it should work. Furthermore, ranking requirements in terms of priority should also aid in determining the focus of current design and development efforts. This page should also help newcomers to the project understand where current efforts are being placed and why certain areas are not being worked on. If requirements can be created in a prioritized fashion, hopefully all participants in the project can understand expectations and maintain focus in an effort to have a more efficient development experience.
User Requirements
Requirement |
Description |
Priority* |
Blueprint Link
|
Multiple Vips per Pool |
A load balancer should be able to configure multiple tcp endpoints (Vips) for single IP address that point to the same pool of nodes |
High |
https://blueprints.launchpad.net/neutron/+spec/lbaas-multiple-vips-per-pool
|
High Availability |
A load balancer shall have the ability to fail-over in the event of a network outage, network degradation or device failure. |
High |
https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy
|
IPv4 & IPv6 Address Support |
A load balancer shall have the ability to simultaneously load balance both IPv4 and IPv6 traffic. |
Low |
|
L7 switching |
A load balancer shall have the ability to steer traffic based on L7 content rules. |
High |
https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules-haproxy
|
SSL Termination |
A load balancer shall have the ability to terminate SSL traffic at the load balancer and support versions up to TLS 1.2
- Private Key Management
- HTTP to HTTPS Redirection
- Ability to force HTTPS over HTTP
- Cipher Support For:
- ECDH+AESGCM
- DH+AESGCM
- ECDH+AES256
- DH+AES256
- ECDH+AES128
- DH+AES
- ECDH+3DES
- DH+3DES
- RSA+AESGCM
- RSA+AES
- RSA+3DES
- Option to force a specific version of SSL (SSLv3, TLS 1.0, TLS 1.1, or TLS 1.2)
|
High |
https://blueprints.launchpad.net/neutron/+spec/lbaas-haproxy-ssl https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-barbican
|
Server Name Indication (SNI) Support |
A load balancer shall have the ability to support multiple SSL certificates on a single HTTPS listener per the SNI protocol |
? |
|
HTTP Protocol Support |
The load balancer shall have the ability to load balance HTTP traffic. |
Done |
|
HTTPS Protocol Support |
The load balancer shall have the ability to load balance HTTPS traffic. |
Done w/o termination |
|
HTTP/HTTPS keepalive support |
A user should be able to specify a client keepalive timeout for HTTP/HTTPS connections (0 indicates keepalive disabled) |
? |
|
TCP Protocol Support |
The load balancer shall have the ability to load balance TCP traffic. |
Done |
|
UDP Protocol Support |
The load balancer shall have the ability to load balance UDP traffic. |
? (LVS can handle UDP) |
|
Static IP Addresses |
The load balancer shall have the ability to serve traffic over a static IP address. |
? |
|
Round Robin Algorithm |
The load balancer shall have the ability to serve traffic to back-end nodes in a round robin fashion. |
Done |
|
URI Algorithm |
The load balancer shall have the ability to serve traffic to back-end node pools based on specific URIs. |
L7? |
|
Least Connections Algorithm |
The load balancer shall have the ability to serve traffic to back-end nodes such that the node with the least number of connections receives traffic first. |
Done |
|
Active/Passive Failover |
In the event of node pool failure the load balancer shall have the ability to redirect traffic to a standby node pool. |
? |
|
Health Check Monitoring |
The load balancer shall have the ability to monitor the health of nodes and automatically disable/restore the flow of traffic to them. Health Checks to consider include:
- HTTP Checks
- HTTPS Checks
- MySql Checks
- TCP Checks
- ICMP Checks
|
Done (exc MySql) |
|
IP Access Control |
The load balancer shall have the ability to control access to the underlying nodes based on IPv4 and IPv6 addresses. The user shall be able to specify this in a whitelist/blacklist fashion. |
? |
|
Session Persistence |
The load balancer shall have the ability to direct traffic to the same node by using cookie-based sessions or ip addresses. |
Done |
|
Connection Logging |
All connections through the load balancer shall be logged and stored for later retrieval. |
Low |
|
Logging offload |
All access and error logs for the load balancer shall be automatically offloaded to a logging service |
Low |
|
Statistics |
The Neutron LBaaS API shall expose the following real-time performance statistics:
- Aggregate & Per-Server Connections Per Second (Current and Max)
- Aggregate & Per-Server Concurrent Connections (Current, Max, and Total)
- Aggregate & Per-Server Network Traffic (Bytes In and Bytes Out)
|
Done (currently - per Pool, will be per VIP) |
|
Status Indication |
Users can know whether the loadbalancing service is active.
Furthermore, users can know the state of the individual member.
|
High (It is not correct currently.) |
|
Asynchronous API |
Operation may take time to complete.
- A call to the API should return immediately.
- The user can check via the API the completion of the call.
- Concurrent calls on same object or on the same object tree should be allowed.
- The checked status should reflect the call status and not the object status
|
High (Current implementation persists the call status on the modified object.) |
|
Add/Remove members in batch |
For initial configuration and for scale-out/scale-in scenarios it is better to be able to add and remove members via a single call and in a batch
|
Medium |
|
CLI |
A complex VIP configuration might include many configuration items such as pools, l7 rules, SSL certificates and members.
- It is preferable that such configuration could be done using multiple short CLI command VS. a single very long CLI command.
- There are cases where the whole VIP tree is consistent as a single batch while using multiple actionable API calls results a transient non consistent state.
|
High |
|
Apology page |
A Web application might require to display an "Apology page" when all application members are down
|
? |
|
L7 Scripting |
Define a flexible API which allows for L7 Scripting
- SSL client authentication with OCSP
- Ability to insert Certificate Information into HTTP Headers
|
? |
|
Service VMs |
Integrate with service VMs
|
? |
https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms, https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt
|
*Priority is ranked Low to High.
User Use Cases
- TODO: Need user use cases
Operator Requirements
Requirement |
Description |
Priority* |
Blueprint Link
|
Scalability |
The system shall be able to scale to an indefinite number of load balancers. |
High |
|
DDoS Mitigation Tools |
The system shall have tools to address DDoS attacks. |
Medium |
|
Diagnostic instrumentation |
The system shall have sufficient instrumentation to troubleshoot typical operational problems (eg. tools are sufficient to pin-point failures in infrastructure, overloading or hot-spots, etc.) |
? |
|
Logging Alerting and Monitoring |
The system shall have sufficient instrumentation to provide total situational awareness, meet appropriate regulatory compliance, and be dynamically updated/created as capacity fluctuates. |
High |
|
Recoverability |
The system shall have sufficient recoverability options to protect against downtime. This includes but is not limited to self healing type features like multi region, geo redundancy, regular backups, and HA setups where appropriate. |
High |
|
Automation |
The system shall have sufficient automation instrumentation in place such that deploys can be orchestrated by deployment systems like Jenkins in a continuous way. |
High |
|
Feature |
Ability to define Source NAT (define nat-pool etc.) and to apply nat-pool to VIP |
|
|
Feature |
TCP and UDP session idle-timeout options and ability to apply this to VIP or Server |
|
|
Feature |
Ability to upload and apply the SSL certificates to VIP |
|
|
Feature |
Support for other load balancer algorithms |
|
|
Feature |
LB statistics and notification to be available for ceilometer |
|
https://blueprints.launchpad.net/neutron/+spec/lbaas-ceilometer-integration
|
Feature |
Option to pass proprietory LB commands to the driver |
|
|
Feature |
Anycast route injection for a VIP |
|
|
Feature |
Preserve source IP address transparency to real servers. |
|
|
*Priority is ranked Low to High.
Operator Use Cases
- TODO: Need operator use cases
Operator Data
Overview
Cloud operators have different types of cloud users. Thus, it fair to say that there will be times when disagreement on priorities will occur. The goal of this section is for cloud operators to provide data on how cloud users are consuming LBaaS. The aggregate of operator data below should be used to determine priority of requirements. Instead of blindly picking priorities of requirements, operator data should provide some guidance as to what features LBaaS users actually use (and thus value). If you are a cloud operator please feel free to add your data below. *Please note that all percentages are out of total number of load balancer instances*
Load Balancer Protocol Utilization
Protocol |
Rackspace |
Operator B
|
HTTP
|
72.55% |
-
|
HTTPS
|
19.67% |
-
|
MYSQL
|
3.94% |
-
|
TCP_CLIENT_FIRST
|
1.30% |
-
|
TCP
|
0.82% |
-
|
SMTP
|
0.39% |
-
|
UDP
|
0.33% |
-
|
FTP
|
0.27% |
-
|
SFTP
|
0.16% |
-
|
LDAP
|
0.13% |
-
|
POP3
|
0.08% |
-
|
DNS_UDP
|
0.10% |
-
|
LDAPS
|
0.06% |
-
|
DNS_TCP
|
0.04% |
-
|
IMAPv3
|
0.02% |
-
|
IMAPv4
|
0.04% |
-
|
IMAPv2
|
0.02% |
-
|
UDP_STREAM
|
0.03% |
-
|
POP3S
|
0.02% |
-
|
IMAPS
|
0.03% |
-
|
Load Balancer Algorithm Utilization
Algorithm |
Rackspace |
Operator B
|
LEAST_CONNECTIONS
|
58.86% |
-
|
ROUND_ROBIN
|
17.00% |
-
|
MYSQL
|
3.94% |
-
|
RANDOM
|
13.88% |
-
|
WEIGHTED_LEAST_CONNECTIONS
|
5.88% |
-
|
WEIGHTED_ROUND_ROBIN
|
4.38% |
-
|
Load Balancer Health Monitoring Utilization
Rackspace |
Operator B
|
57.46% |
-
|
Load Balancer Traffic Logging Utilization
Rackspace |
Operator B
|
22.00% |
-
|
Load Balancer SSL Termination Utilization
SSL Mode |
Rackspace |
Operator B
|
SSL_MIXED (port 80 & 443)
|
14.54% |
-
|
SSL_ONLY (port 443)
|
1.47% |
-
|
Load Balancer Content Caching Utilization
Rackspace |
Operator B
|
11.46% |
-
|