Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
Load Balancing and Clustering

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

Related Material

Web Application Deployment - Tomcat - Extra Features
  [934] - ()
  [1006] - ()
  [1121] - ()
  [1370] - ()
  [1376] - ()
  [1377] - ()
  [1383] - ()
  [1896] - ()
  [1899] - ()
  [1939] - ()
  [3018] - ()

Web Application Deployment - Clustering and load balancing
  [934] - ()
  [1121] - ()
  [1771] - ()
  [1993] - ()
  [1995] - ()
  [2059] - ()
  [2482] - ()
  [2483] - ()
  [3293] - ()
  [3339] - ()
  [3892] - ()
  [4432] - ()

Web Application Deployment - Apache httpd mod_proxy
  [631] - ()
  [934] - ()
  [1006] - ()
  [1121] - ()
  [1376] - ()
  [1566] - ()
  [1767] - ()
  [1939] - ()
  [1944] - ()
  [2062] - ()
  [2273] - ()
  [2325] - ()
  [2482] - ()
  [3293] - ()
  [3339] - ()
  [3680] - ()
  [3892] - ()

Web Application Deployment - Apache httpd mod_rewrite
  [631] - ()
  [755] - ()
  [934] - ()
  [1006] - ()
  [1009] - ()
  [1207] - ()
  [1376] - ()
  [1381] - ()
  [1636] - ()
  [1731] - ()
  [1771] - ()
  [1778] - ()
  [1954] - ()
  [2094] - ()
  [2555] - ()
  [2728] - ()
  [2768] - ()
  [2773] - ()
  [2900] - ()
  [2981] - ()
  [3197] - ()
  [3339] - ()
  [3568] - ()
  [3753] - ()
  [3862] - ()

resource index - Deployment
Solutions centre home page

You'll find shorter technical items at The Horse's Mouth and delegate's questions answered at the Opentalk forum.

At Well House Consultants, we provide training courses on subjects such as Ruby, Lua, Perl, Python, Linux, C, C++, Tcl/Tk, Tomcat, PHP and MySQL. We're asked (and answer) many questions, and answers to those which are of general interest are published in this area of our site.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho

PAGE: http://www.wellho.net/solutions/general- ... ering.html • PAGE BUILT: Wed Mar 28 07:47:11 2012 • BUILD SYSTEM: wizard