Jerome Tournier wrote:
> Hello,
> i don't really understand the differances between the following four lines for configuring mod_backhand:
> 1) broadcasting on the 10.0.5.0/24 on port 4445
> 2) the same but explicitly binding to the 10.0.5.10 interface
> 3) multicasting to 240.220.221.20 on port 445
> 4) the same but explicitly binding to the 10.0.5.10 interface
The second and fourth don't actually bind to a specific interface. They fill
out one of the announced structure to contain that IP address. If you have
amchine with multiple IPs and you explicitly want other machine to proxy to
_one specific_ IP on a machine, then that machine should explicitly say
"w.x.y.z is my IP" mod_backhand will guess at your IP address using a
gethostbyname(gethostname()) sort of method. This often will return the
public interface of a machine. If you have two interfaces and you want all of
the proxying to be happening over the internal network, you may need to
explicitly state your IP.
It also allows you to lie about your IP. This is a more complicated "feature"
that can allow for simpile HTTP accelerators and complicated failure models.
> I thought that broadscasting mean to every machine ont the net, while multicasting is to a number of machines. But the rest ??
Yes. Broadcasting means to send messages to all machines on a given subnet.
Typically the broadcast address is the highest IP address not the lowest. For
example, in the 192.168.10.0/24 network, 192.168.10.0 describes the network
and 192.168.10.255 describes the broadcast. You _can_ use 192.168.10.0 as the
broadcast address and it will almost always work, but it is antiquated and
considered bad style.
> I have another question of general order concerning mod_backhand. Is there a primary server and the other are secondary servers, or are they all at the same level ?
They are all peers fromt he perspective of mod_backhand. This doesn't mean
that you cannot configure your set up in a master/slave fashion. If you want
to have a single front end machine, then do whatever it takes to make sure
that end-users only connect to that machine (a single IP in the DNS records or
a single IP in VIP). If this is done, users will always contact the front
machine and the front machine can either service the request itself or proxy
to a "better" back-end machine. The back-end machine's will never proxy
anything because mod_backhand gaurantees never to proxy the same request
twice.
But from the configuration stand-point, the machines could be identical.
> If i have a cluster of 3 servers, each of them must have exactly the same applications (i mean the same cgi programms, ...), or not. I suppose yes.
No necessarily. This completely depends on the rules you define for load
balancing. If a machine is particularily weak or has very little RAM and you
have a set of requests that would stress the machine too heavily, it should be
very easy to make sure that machine doesn't get that type of request (and thus
the CGI would not _need_ to be installed there).
A good example is architecture differences. Perhaps you have an application
that will only run on Sun and you have a cluster of 8 Intels and 2 Suns. If
you named your machines www-x86-1, www-x86-2, ..., www-x86-8 and www-sun4u-1,
www-sun4u-2, then you could say that for a certain class of requests that the
sun4u boxes are the only candidates:
<Directory /path/to/64bit-sun4u-apps/>
BackhandFromSO libexec/byHostname.so byHostname sun4u
</Directory>
If you don't like this particular method (it isn't the fastest), you can write
your own candidacy function that will select the machines that you like.
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7