At 01:01 PM 10/30/2000 -0600, Leslie Mikesell wrote:
>According to Gunther Birznieks:
>
> > I guess part of the question is what is meant by "balanced" with regard to
> > the non-apache back-end servers that was mentioned?
>
>I'd be very happy with either a weighted round-robin or a least-connections
>choice.  When the numbers get to the point where it matters, pure
>statistics is good enough for me.   But, I love what you can
>do with mod_rewrite and would like an easy way to point
>the target of a match at an arbitrary set of back end servers.
>Mod_jserv has a nice configuration setting for multiple
>back ends where you name the set and weight each member.  If
>mod_proxy and/or mod_backhand had a similar concept with the
>group name being usable as a target for mod_rewrite and
>ProxyPass it would be easy to use.  I think Matt's idea
>of creating a Location handler and rewriting to the location
>would work as long as the modules are loaded in the right
>order, but it would make the configuration somewhat confusing.

Mod_Rewrite supports this by writing a custom script to do it (not easy).
Mod_Backhand does it natively but is a bit harder than you describe for 
mod_jserv.

With mod_backhand, you basically can set up IP Addresses/Hostnames which 
can be weeded out for different things. eg some servers only get load 
balanced during the day because at night they are sending SPAM mail. 
(Theo's example not mine!)

> > I am also concerned that the original question brings up the notion of
> > failover. mod_backhand is not a failover solution. Backhand does have some
> > facilities to do some failover (eg ByAge weeding) but it's not failover in
> > the traditional sense. Backhand is for load balance not failover.
>
>Does it do something sensible if one of the targets does not
>accept the connection, or does it start sending them all
>to that one because it isn't busy?  Mod_jserv claims to
>mark that connection dead for a while and moves on to
>another backend so you have a small delay, not a failure.
>After a configurable timeout it will try the failing one
>again.

There are no connections ever marked as dead. THey are only marked as not 
having checked in with their status. If they don't check in with the status 
within 20-30 seconds, mod_backhand takes them off the list using the ByAge 
candicacy function. If it comes back up again and reports its status, then 
it will come back into the list.

> > While Matt is correct that you could probably write your own load balance
> > function, the main interesting function in mod_backhand is ByLoad which as
> > far as I know is Apache specific and relies on the Apache scoreboard (or a
> > patched version of this)
>
>The problem of writing your own is that it needs to be in
>the lightweight server - thus all in C.

My understanding is that Apache::Backhand for mod_perl exists. So you could 
theoretically reserve mod_perl on your front end server just for writing 
backhand logic. Since you can preload the handlers and they would 
presumably be small, tight code, it wouldn't have the same effect as 
running an application on the front-end.

But you're right. C is the preferred method.

> > Non apache servers won't have this scoreboard file although perhaps you
> > could program your own server(s) to emulate one if it's not mod_backhand.
> >
> > The other requirement that non-apache servers may have for optimal use 
> with
> > mod_backhand is that the load balanced servers may need to report
> > themselves to the main backhand server as one of the important 
> functions is
> > ByAge to weed out downed servers (and servers too heavily loaded to report
> > their latest stats).
>
>If a failed connection would set the status as 'down' and periodic
>retries checked again, this would take care of itself.

Yes, but I don't think mod_backhand does this. At least it's not described 
in the docs. That's why it's considered load balancing not a failover 
solution. However, it is my belief that some simple things like this do 
belong in backhand. My caveat to this opinion is that I do not use backhand 
and am not an expert into the reasons for design decisions.

> > Otherwise, if you need to load balance a set of non-apache servers evenly
> > and don't need ByLoad, you could always just use mod_rewrite with the
> > reverse_proxy/load balancing recipe from Ralf's guide. This solution would
> > get you up and running fast. But the main immediate downside (other 
> than no
> > true *load* balancing) is the lack of keep-alive upgrading.
>
>I'll accept randomizing as reasonable balancing as long as I
>have fine grained control of the URL's I send to each destination.
>The real problem with the rewrite randomizer is the complete
>lack of knowlege about dead backend servers.  I want something
>that will transparently deal with machines that fail.

Yes. mod_rewrite won't do that.  But neither will backhand I believe.

> > I am also not sure if mod_log_spread has hooks to work with 
> mod_backhand in
> > particular which would make mod_rewrite load balancing (poor man's load
> > balancing) less desirable. I suspect mod_log_spread is not
> > backhand-specific although made by the same group but having not played
> > with this module yet, I couldn't say for sure.
>
>If you can run everything through a single front end apache
>you can use that as the 'real' log.  There is some point
>where this scheme would not handle the load and you would
>need one of the connection oriented balancers instead of
>a proxy, but a fairly ordinary pentium should be able to
>saturate an ethernet or two if it is just fielding static
>files and proxying the rest.   You would also need a
>fail-over mechanism for the front end box, but this
>could be a simple IP takeover and there are some programs
>available for that.

Yeah but then when you have two front-end servers load balanced on the IP 
level, you would need to still merge the logs somehow. mod_log_spread 
builds this architecture for you and (in theory , maybe practice as well) 
is faster than mysql logging for combining logs of web servers (syslog is 
unreliable and any other db just too slow probably).

Later,
    Gunther

Reply via email to