Mailing List Archive

Hi Peter,

Are you Ben Laurie's brother?

The second option is the correct one. In principle, mod_backhand is a peer to peer system where there is no master and every instance runs the same config file. Every instance makes local decisions about whether to execute the request or proxy it to another instance. The decision rules are not magic but can actually be determine by the web manager. We do provide several decision functions with the package.

Note that it is perfectly possible to set the cluster such that only one (or a few) of the instances receives outside requests. This will give you in effect an architecture similar to your first option.

The mod_backhand instances in the cluster periodically publish their load parameters to other members using non-reliable udp multicast or broadcast messages. The rate and the address are configuration determined. We use 1 second. These messages help mod_backhand determine the membership of alive instances as well as their parameters.

Cheers,

:) Yair. http://www.cs.jhu.edu/~yairamir

Peter Laurie wrote:

> Hi
>
> I'm writing a new chapter for our book: 'Apache The Definitive Guide', which
> will try to describe mod_backhand. I start, like a good journalist, from a
> position of ignorance.
>
> It isn't clear to me from the documentation, and I'd be most grateful if
> someone could explain, does mod_backhand have a front end server that deals
> out the requests to a mess of back end servers?
>
> or
>
> does it run the same Apache config file on all the servers and distribute
> the requests in some magical way?
>
> Thanks in advance.
>
> ----
> Peter Laurie Phone: +44 (1305) 871131
> Director AL Systems Fax: +44 (1305) 871132
> Author & Journalist Email: peter@abbotsbury.co.uk
>
> Co-author of 'Apache, The Definitive Guide',
> O'Reilly 1997, 2nd ed. 1999, 3rd ed. in preparation.
> Specialist in automatic forms processing, OCR,
> OMR and imaging. See www.algroup.co.uk/alsystems
> Programmer; Unix, SQL, Perl, 'C', Apache
>
> Technical Director www.Medic-Planet.com
> PGP key on keyservers
>
> _______________________________________________
> backhand-devel mailing list
> backhand-devel@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/backhand-devel

Umm. Well, it's not automagical or anything. :) First off, it
integrates transparently to the attaching http client. They see no
difference. Inside of the apache/backhand daemon is where the automagical
inspirations take place. In the Apache config file you can specify rules
by file type, extentions, and directories. A few of the rules
include: forwarding to specific machines, balancing in a cluster
based on load, and balancing in a cluster based on metacomputer weights
determined on a calculation of CPU/IO/Memory usage compared to a threshold
value. As long as the content is available locally and remotely from all
http servers then you can build a very scaleable mix of machines, serviing
up everything or balancing certain tasks between certain groups of
machines. Some very nice things can be created with Backhand and layer 4
software(LinuxDirector) or hardware(CiscoDirector) switches and even
benefits can be gained with out these switching systems in front of it.

This can lend it's self to a very complicated mesh of Apache
servers or a very simple setup. You can have a single machine answer the
front and hand off all CGI/JPEGs/HTML from the appropriate cluster of
machines.. Such as Suns to crunch CGI, JPEGs from the hi-avail raid farm,
and HTML from some cost effective X86's. This can be very beneficial for
distributing http requests in any environment. Take a another
scenario.. You have 3 machines.. 1 web server, a mail server and a dns
server. Your web server tanks every night starting at 6pm... Your dns and
mail servers load is near next to null but you can't afford to convert
them into fulltime servers for whatever reason. You load up backhanded
apache on your web, dns, and mail server. All you incoming http requests
bounce from www, to dns because it's load is always next to nothing
and it's a P-III 500. Then all of a sudden you dns server gets crammed in
the dirt because some guy is doing a recursive walk across some domains
you are the authority for.. Instead of the web server crawling and tanking
it starts shoving http clients transparently to the P-II 400 mail
server. During the middle of this fiasco the power supply burns in the
mail server and because the web server(a P-II 266) has exhausted it's
resources.. it is forced to serve the requests itself. Because the
weight computation and internal forwarding is a negligible amount of time,
the clients can't tell the difference and with the innovations in high
availability SCSI bus, FCAL fabrics with JDOBs, or and super NFS
servers.. high availability clustering is now conceivable with off the
shelf parts and open source software.


Happy hacking.





On Wed, 15 Nov 2000, Peter Laurie wrote:

> Hi
>
> I'm writing a new chapter for our book: 'Apache The Definitive Guide', which
> will try to describe mod_backhand. I start, like a good journalist, from a
> position of ignorance.