Jump to: navigation, search

Difference between revisions of "Neutron/LBaaS/requirements"

< Neutron‎ | LBaaS
(User Requirements)
(User Requirements)
Line 97: Line 97:
 
|-
 
|-
 
| 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
  || ?||
 
|-
 
| Source NAT || Ability to define Source NAT (define nat-pool etc.) and to apply nat-pool to VIP
 
 
   || ?||
 
   || ?||
 
|-  
 
|-  

Revision as of 01:08, 3 April 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 balancer 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
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  ?

*Priority is ranked 1 through 10 where 1 is the highest priority.

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

*Priority is ranked 1 through 10 where 1 is the highest priority.

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% -