Difference between revisions of "Neutron/LBaaS/requirements"
(→Operator Requirements) |
(→Operator Requirements) |
||
(12 intermediate revisions by 5 users not shown) | |||
Line 12: | Line 12: | ||
| 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 | | 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 | + | | 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 | | 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 | ||
Line 40: | Line 40: | ||
|- | |- | ||
| HTTPS Protocol Support || The load balancer shall have the ability to load balance HTTPS traffic. || Done w/o termination || | | 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 || | | TCP Protocol Support || The load balancer shall have the ability to load balance TCP traffic. || Done || | ||
Line 98: | Line 100: | ||
| Apology page || A Web application might require to display an "Apology page" when all application members are down | | 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 | + | ''''' *Priority is ranked Low to High. ''''' |
==== User Use Cases ==== | ==== User Use Cases ==== | ||
*TODO: Need user use cases | *TODO: Need user use cases | ||
Line 122: | Line 132: | ||
| 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 || | | 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 | + | ''''' *Priority is ranked Low to High. ''''' |
==== Operator Use Cases ==== | ==== Operator Use Cases ==== | ||
*TODO: Need 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 ==== | ||
+ | {| class="wikitable sortable" | ||
+ | |+ | ||
+ | |- | ||
+ | ! 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 ==== | ||
+ | {| class="wikitable sortable" | ||
+ | |+ | ||
+ | |- | ||
+ | ! 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 ==== | ||
+ | {| class="wikitable sortable" | ||
+ | |+ | ||
+ | |- | ||
+ | ! Rackspace !! Operator B | ||
+ | |- | ||
+ | | 57.46% || - | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | ==== Load Balancer Traffic Logging Utilization ==== | ||
+ | {| class="wikitable sortable" | ||
+ | |+ | ||
+ | |- | ||
+ | ! Rackspace !! Operator B | ||
+ | |- | ||
+ | | 22.00% || - | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | ==== Load Balancer SSL Termination Utilization ==== | ||
+ | {| class="wikitable sortable" | ||
+ | |+ | ||
+ | |- | ||
+ | ! SSL Mode !! Rackspace !! Operator B | ||
+ | |- | ||
+ | ! SSL_MIXED (port 80 & 443) | ||
+ | | 14.54% || - | ||
+ | |- | ||
+ | ! SSL_ONLY (port 443) | ||
+ | | 1.47% || - | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | ==== Load Balancer Content Caching Utilization ==== | ||
+ | {| class="wikitable sortable" | ||
+ | |+ | ||
+ | |- | ||
+ | ! Rackspace !! Operator B | ||
+ | |- | ||
+ | | 11.46% || - | ||
+ | |- | ||
+ | |} |
Latest revision as of 17:17, 2 May 2014
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
|
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:
|
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:
|
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.
|
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.
|
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
|
? | |
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% | - |