A proposal to replace dedicated servers with a fully load balanced server infrastructure running a mixture of Ubuntu Linux and Windows Server 2008.


Currently you have two dedicated servers, one hosting all websites and one hosting all databases.  Each of these boxes has 4GB of RAM.

With this solution, if either server goes down or is overloaded, all your structure fails and you lose access to all your websites.

Proposed Architecture

The architecture we are proposing will be the same no matter the sizes of the servers at each level, so we can move between sizes as needed. If a larger configuration is needed until the software is optimised, we can shrink easily when performance leaks are fixed.

Request Path

Following a single request, assuming all servers are operational:

  1. DNS picks one of the two front-end balancers
  2. Chosen load balancer picks web server experiencing the lowest load
  3. Web server handles request
  4. DB traffic for this request goes to same side Database balancer
  5. Database balancer forwards request to same side Database server

When all servers are fully operational, you can visualise this as an individual request passes down one side of the diagram.  This means roughly 50% of all requests will use each side.

If something goes wrong

Front-End Load Balancers

If a front-end balancer fails, it's IP address is instantly transferred to the other load balancer and all requests are sent there.

Impact: Half the transfer speed available, most pages are low enough weight for this to have little noticeable effect.

Web server

If a web server were to stop responding or be overloaded, the front-end balancers would detect this and take it out of service, sending all future requests to the other web server

Impact: Probably a noticeable slow down, however all transactions should complete.

Database Balancer

Should one of the DB balancers go down, the web server will be flagged as down and the front-end balancers will send the load to the other side of the tree.

Impact: Same as unresponsive web server.

Database Server

If a database server stops responding or is overloaded, the DB balancers will switch to using the other one.  These balancers are operating on a backup rather than on the shared load basis that the front-end balancers are.  This is to ensure data integrity within each request.

Impact: Probably a noticeable slow down, all data should be up to date due to replication in the database layer and all transactions should complete.

Additional Benefits

Security and software updates

As each layer has redundancy, we can safely run updates at almost any time, as long as it’s only one server per level.  This means you have safe and secure systems without downtime.

Staging servers

One fringe benefit of this solution is that whenever there are design or large scale code changes on any of your sites, we can very easily run these changes in a staging environment before they are pushed to the live site.  To explain, this is the process:

  1. Write and test code on development site
  2. When happy code works, push to staging site
  3. Front end balancers send 10% of users to staging site instead of live site
    1. If no bugs found and changes have desired effect they are pushed to live
    2. If further testing needed or changes result in less conversions staging site rolled back

Having a staging system allows you to much more thoroughly test any updates with real users but without the risk of affect huge numbers of them and causing any great loss of income.

Unavailable messages

At the front-end load balancer level, a small webserver can be set up that will serve a single "We are experiencing heavy load" page should, for whatever reason, both web servers were unavailable.  This means that your visitors are at least getting a friendly, branded response rather than a "Page Cannot be Displayed" message.

Proposed Configurations

Option 1 – Equivalent Capacity to current

  • 2x 512MB Front-End Balancers
  • 2x 2048MB Web Servers
  • 2x 512MB DB Balancers
  • 2x 2048MB DB Servers

This is giving you 4GB total Web server RAM and 4GB total DB RAM, but with the added load balancing, failover, staging and general architecture improvements.

Option 2 – Boost Web Servers & Front-End Throughput

  • 2x 1024MB Front-End Balancers
  • 2x 4096MB Web Servers
  • 2x 512MB DB Balancers
  • 2x 2048MB DB Servers

In this solution we are adding RAM to the web servers, as the present web server does seem to be the worst bottleneck, so boosting the specs here should add a decent amount of capacity.

Option 3 – Boost Web Servers & DB Servers

  • 2x 1024MB Front-End Balancers
  • 2x 4096MB Web Servers
  • 2x 512MB DB Balancers
  • 2x 4096MB DB Servers

Here we have also boosted the size of the database servers to 4GB each, this should only be necessary if the database design is very poor.

Option 4 – Normal DB Servers, Quadruple Web Size

  • 2x 1024MB Front-End Balancers
  • 2x 8192MB Web Servers
  • 2x 8192MB DB Balancers
  • 2x 2048MB DB Servers

If the web servers are still struggling under the inefficiencies of the code, but the database servers are coping well, this is the next step up for the web servers.  Here we have allocated 8GB per web server, four times your current web server 

Support Ticket
Remote Support
clever girl