Clustering, load balancing, mod_rewrite and mod_proxy
Archive - Originally posted on "The Horse's Mouth" - 2006-11-21 07:02:15 - Graham Ellis
"It's not friendly - it's like a reference book". Customer comment on yesterday's tailored training day, where we were load balancing a web application between a number of back end servers, using Apache httpd, with mod_proxy and mod_rewrite to do the clever bits.
Our customers are right - it IS tough for a newcomer to work out what to do from the mod_rewrite manual. So you might like, for starters, to read my article on techniques for load balancing and clustering. Then you might like to look at some of the sample configuration files that we used to have a single httpd instance share the load between multiple further httpds, or multiple Tomcats. Yes, that's right, the solution works not only for Java applications, but also for Perl and PHP ones!
For newcomers to balancing the load, via mod_rewrite and mod_proxy, here's a commented version of the additions we made to httpd.conf at the end of the day, to share PHP applications in a directory called /demo on our backend servers via a URL called /booze on our front end.
# Only make the following tests if the URL starts /booze
<Location /booze>
RewriteEngine On
# Look for a cookie called "what", which is the flag
# we use for a continuing session.
# If the cookie is there, it's been set up to include the
# server name as given in the phpbal file ... and if you
# find it, rewrite the URL to the appropriate server,
# in the demo directory. The [P,L] tells mod_rewrite to
# call mod_proxy for the new URL, and that this is the last
# rewrite in the chain - i.e. if it matches, don't look at
# any further instructions!
# If there was no cookie, however, this is the first request
# of a series and it should be forwarded to a server in the
# group at random. FIRST is defined in phpbal.conf
# Responses from the two servers may (will?) have been
# rewritten to point directly back at the back end server.
# Rewrite those returned URLs so that future requests will
# also be brokered via the front end server, and the back
# end system will be transparent to the user.
local 192.168.200.67:80
live www.wellho.net:80
FIRST 192.168.200.67:80|www.wellho.net:80
and that instructs the server to randomly choose between our live web server and one of the servers in our training centre for first service ... then to revert to the same server if the cookie is set with a "live" or "local" value. The full source of the PHP application we tested with is in one of the links above, but the vital line to set the cookie is worth reproducing here:
setcookie("what","local-".$uniquekey);
with "local" changed to "live" on the second system in the cluster ...
I do enjoy days like yesterday, when we explored topics that are advanced and not quite the nor for our usual courses. My customer left really happy with what we had done, and I had the opportunity to push through and develop further practical knowledge and further my own understanding of some of the detail - a true win/win. And of course I'm all the better place not if YOU want to come and learn more about sharing the load across servers - whether you've a PHP or Java application.