Launchpad Entry: server-maverick-uds-cloud-loadbalancing
Users deploying on the cloud, whether private or public, often require load balancing. Amazon has solved this for EC2 users with Elastic Load Balancing. haproxy is available on Ubuntu and provides most if not all of the capability of Elastic Load Balancing services. Missing components that may be beneficial to be write include workalikes to the amazon ec2 API tools elb-create-lb, elb-register-instances-with-lb, elb-configure-healthcheck.
Ubuntu 10.10 offers a cloud load balancing stack. A simple stack is provided to enable an out of the box load balancer to be setup and configured, with automatic registration of backend servers, and high availability features.
Load balancers should not be difficult to configure for basic workloads. HAproxy provides an extremely stable and scalable load balancing solution. Given the low amount of overhead involved, it may make sense to run this stack on an existing node rather than pay the extra cost of running Amazon's Elastic Load Balancer service. For non-cloud deployments, a simple tool is useful as it will provide the benefit of easy maintenance and a uniform deployment procedure.
- As a system administrator who has been exposed to Amazon's EC2 and Elastic Load Balancing, I want a similar interface for load balancing servers that are not necessarily part of EC2.
- As a system administrator and/or web application developer I want to be able to deploy load balancing for new applications with a minimal amount of configuration and customization.
- As a web application developer I want the ability to create simple auto-scaling for my web application using command line tools and existing infrastructure.
- haproxy is fast enough to handle many thousands of requests per second with a single instance. In tests, 1600 active HTTP connections (from 8 EC2 nodes running siege) were not enough to make haproxy show more than 3% CPU usage running on a "small" ec2 instance.
- Cloud environments are not going to offer any sort of physical network connection (so IPVS's strongest method, Direct Routing, and its simplest method, NAT, are both unusable in the cloud)
haproxy is generally held up as the best of breed for user-space software load balancers. While IPVS may be very powerful, it has the limitation of working at layer 4, and so requires encapsulation to traverse disparate subnets involved with modern cloud setups.
The haproxy package itself should not require any modification, but should be promoted to main
A config backend will either be provided as a puppet module using exported configs (under investigation), or some web scripts must be created to implement a simple REST interface to enable client scripts to add/remove/list/disable/enable healthchecks, nodes, and listeners in a secure and simple fashion.
haproxy's normal config file is user editable and may already be configured for other usage on a machine. This package will define an upstart service that starts haproxy with a generated config file from the config information contained in cloud-loadbalancer's config backend (hopefully puppet). This leaves the door open for other load balancers.
haproxy has a lot more power than this that some may want to take advantage of after initial setup. A suitable, simple templating engine (m4?) will be used to generate the files, and the templates can be edited as users see fit.
A set of scripts that use the cloud-loadbalancer config backend above in a similar fashion to the elb-* tools from amazon's EC2 ELB API Tools. These will attempt to match all of the features of the amazon elb-* scripts. The 'LoadBalancerName' given in these scripts will be the hostname of the load balalancer.
See blueprint white board server-maverick-uds-cloud-loadbalancing
High Availability will still have to be manually configured, though the cluster features already available in Ubuntu will at least make this relatively easy.
UDS session agenda and discussion
Notes from session:
Look into a load balancing/proxying http solution based on:
- - nginx:
- In universe.
- In universe.
- In main. mod_proxy + mod_proxy_balancer.
- TODO: promote to main?
- In universe.
- Needs to be packaged.
- In main.
- Network topologies:
- - NAT - load balancer must be node default gateway - Direct Routing - load balancer must be on same LAN - Tunneled - Non shared default gateway
- In universe.
Performance is important.
- a way to provide auto scaling in cloud without hardware
- HTTP - persistence mapping should survive reconfiguration
- Realtime reconfiguration / Backend Self Registration
- Web Services / REST
- Ensemble will do this
- Avahi (Auto registration in eucalyptus, session at noon)
- Backend server dependency handling
- develop proof of concept auto scaling on UEC (nick)
- ensemble should be considered