Too much traffic for a single server? And with so much traffic, do you need robustness such that if one server goes down, (an)other one will take over? You need to split the load - you're looking for a load balancing or clustering solution. But what's the difference?
SIMPLE LOAD BALANCING
With a simple LOAD BALANCING scheme, you can split your traffic down by URL or subdirectory, so that (for example) all traffic for /course goes to one server, and all traffic for /horse goes to another, with the front end machine acting simply as a router, forwarding requests via mod_proxy (if it's running Apache httpd) or similar.
Where you have a site that's very broad - i.e. has lots of directories - and the structure of the site is such that no one of them receives the majority of your traffic, this is a good and quick way of increasing throughput. It's not going to do a great deal for you in terms of robustness, although the failure of a back end component won't knock the whole site out, and it's not going to do much for you if you're serving flat pages as they'll be routed back via the front end server anyway.
For details - look up mod_proxy.
BALANCING THE LOAD BY SESSIONS
This is a scheme that works well for a busy session based application - i.e. one where a visitor arrives at your site and then works through a single or group of applications. Examples include forums, blogs, other CMS systems, booking systems.
When a user first arrives at your site, the front end machine identifies the fact and forwards him on to another machine, selected 'at random' from a group of available back end machines. Subsequent requests by the same user are identified as being a continuation of the same session by the front end machine (using URL rewrite, cookies or hidden fields) and are forwarded to the same back end machine that was previously selected.
This scheme uses Apache httpd mod_rewrite and mod_proxy
Detailed configuration file samples available
here
Our examples include files for balancing the load on both Apache httpd servers and Apache Tomcat servers. In other words, as well as using this method to share the load on Java application servers, it can also be used to do the same thing for applications in PHP, Perl, etc.
CLUSTERING VIA A DATABASE
In Clustering solutions to load sharing, any request made to the front end server may be routed to ANY back end server. A great theory - this is the single queue at your Post Office or McDonald's allowing fair service from the next available team member.
But there's a big problem. Requests are 'atomic' - they're bunched together into a series rather than being made all at once, and somehow you need to ensure that the first team member that you place the first part of your order with informs the second team member with whom you complete your order.
The first, and simplest, approach to clustering is to ensure that all cluster members save pertinent information to a shared database after each atom. Then any subsequent request checks back with that database and continues on with the process in the knowledge of what's gone before.
CLUSTERING VIA MULTICAST BROADCASTS
Rather than use a common database level, Tomcat provides a multicast clustering solution. Here, any files / data modified by a user's activity is broadcast over the network to all other cluster members so that they can keep up to date with the status of all customers.
Multicast Clustering is unlikely to be cheap - although the very use of multicasting ensures that only one transmission of changes is needed (and not one per sibling server), that can still be a lot of traffic and a dedicated 'store back' subnet is recommended. Even then, to double the traffic handled by a single server you're likely to need three back end servers.
OTHER ROBUSTNESS ISSUES
Have you noticed that all the solutions offered use a single httpd front end? A hardware load balancer will allow you, if you need to get THAT big, to split that traffic down arbitrarily between a series of available systems, and none of the schemes outlined above requires you to return to the same top level server. Another robustness solution at this top level is to have a "heartbeat" system checking the initial single httpd, ready to take over should it sense a problem.
The database, too, can form a bottleneck. And whereas the front end server can easily switch, that's not quite the case with the database. However, most database applications are "read mostly", so here's a scheme:
- All writes to a single MySQL (master) server
- MySQL master updates replica servers on each cluster member
- All reads from replica servers
- "Heartbeat" monitoring of master server, with scripted fail-over
WHICH SOLUTION SHOULD WE CHOOSE?
There's as many different requirements as there are people! Have a look through the options suggested above, and you'll probably see which one has the metrics that best suit you.
If you can get away with a simple load balancing solution, do so - quick and easy. If your user work by sessions, balance the load by sessions using mod_rewrite and mod_proxy - not quite to easy, but a walk in the park compared to clustering solutions. Only cluster if you must!
See also
Deploying Apache httpd and Tomcat
Please note that articles in this section of our
web site were current and correct to the best of our ability when published,
but by the nature of our business may go out of date quite quickly. The
quoting of a price, contract term or any other information in this area of
our website is NOT an offer to supply now on those terms - please check
back via
our main web site