Brightbox Load Balancing

This wiki page provides technical and implementation details for the Load Balancing service.

Technical Overview

Health check types

The load balancer performs Health checks on each of the Brightboxes in your load balancing pool to make sure that they are up and available to service requests. If one or more of your Brightboxes fails its health check, it is removed from the load balancing pool. Health checks continue, and once it is passing them again, it is re-added to the pool.

By default, the load-balancer performs a “connect” check on port 80. This means that it initiates a TCP connection to the web server process on each Brightbox, and passes if the connection is accepted.

The alternatives are:

  • “negotiate”, which allows the load balancer to request a specific URL from each Brightbox, and only pass if a specified string (typically a “200” response) is received back from it.
  • “ping”, which passes if the box simply responds to an ICMP ping.
  • “on”, which considers all Brightboxes to be available all the time.

The latter two are not recommended, as there are a number of situations such as a webserver crash, or out-of-memory situation, in which they will not remove a failed Brightbox from the pool.

If you have more than one load-balanced app on your Brightboxes, then the “negotiate” check can only monitor one of them. This means that, if it breaks, the Brightbox will be removed from the pool even if the other apps are still working. Conversely, if an un-monitored app breaks, then it will continue to receive new connections.

Load balancing metrics

By default, the load-balancer users the “least connections” scheduler, with 300 seconds “persistence”. This directs new connections to whichever Brightbox in the pool has the least connections already open. This only counts connections which are using the load-balancer; if you have another site on the Brightbox which is not load-balanced, its connections are not counted.

Connections are “persistent” for 300 seconds. This means that a given client IP address is remembered for 300 seconds, and if it initiates a new connection, that connection will be directed to the Brightbox which served its previous connection, even if that is not the one which would be selected by “least connections”.

The alternatives are:

  • “round robin”, which distributes connections evenly as they arrive, without regard for the number of connections each Brightbox is already serving.
  • “source hash”, which distributes connections according to a hash of their source IP address. This is intended for situations where is critical that a given client IP always reaches the same server.

Available services

The load balancer can be used with any service which uses TCP, and most which use UDP. By default, a load balancer will be configured to balance TCP traffic to ports 80 and 443 (http and https). You can add multiple services (ports) to each load balancer if you wish.


It is not possible to connect to load balanced IPs from within the Brightbox network. This means that you cannot test your load balancer by connecting to it from your Brightbox; you must test from outside the Brightbox network.

Connection persistence can be a source of confusion when testing. If you repeatedly connect to your load-balanced IP from the same client address, you will always reach the same Brightbox. If you test a freshly provisioned load balancer by opening a connection from one client, then opening a second from another client, then you will see each reaches a different Brightbox correctly.

Each load balancer instance can only have a single load balanced pool, and only uses one type of health check. This means that if you have multiple services (for example http and ftp) on your load balancer, you can only health-check one of them - so if you are health-checking http and the ftp server on a Brightbox breaks, it will continue to receive requests so long as the web server is still passing health checks.

The load balancer interprets the HTTP “503” response (“service unavailable”), often used temporarily while maintenance is done, as a failure. If your Brightboxes are all returning HTTP 503 to requests then they will all be taken out of the load balanced pool and requests to your site will time out until this is remedied.

Implementation guide

Setup load balancing

  • Order a load balancer from the Control Panel. This will generate a support ticket.
  • A member of the Brightbox team will get in touch to ask which Brightboxes you would like to load balance, and whether you have any special requirements. Most people will be fine with the default settings.
  • We'll build your load balancer and get in touch again to let you know its IP address.
  • You can then test, and once you're happy, point the DNS for your site/s at the load-balanced IP.

Configure your application

In the vast majority of cases, applications will not need any changes to work with load-balancing. They will still see and log the client's IP address, if needed; the load balancer is not a proxy and so preserves this information.

docs/load-balancing.txt · Last modified: 2010/05/04 16:29 by george