httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: mod_proxy / mod_proxy_balancer
Date Wed, 06 May 2009 13:03:51 GMT
On 06.05.2009 14:35, jean-frederic clere wrote:
> Jess Holle wrote:
>> Rainer Jung wrote:
>>> Yes, I think the counter/aging discussion is for the baseline, i.e. when
>>> we do not have any information channel to or from the backend nodes.
>>> As soon as mod_cluster comes into play, we can use more up-to-date real
>>> data and only need to decide how to interprete it and how to interpolate
>>> during the update interval.
>> Should general support for a query URL be provided in
>> mod_proxy_balancer?  Or should this be left to mod_cluster?
> Can you explain more? I don't get the question.
>>  Does mod_cluster provide yet another approach top to bottom (separate
>> than mod_jk and mod_proxy/mod_proxy_ajp)?
> Mod_cluster is just a balancer for mod_proxy but due to the dynamic
> creation of balancers and workers it can't get in the httpd-trunk code
> right now.
>>  It would seem nice to me if mod_jk and/or mod_proxy_balancer could do
>> health checks, but you have to draw the line somewhere on growing any
>> given module and if mod_jk and mod_proxy_balancer are not going in
>> that direction at some point mod_cluster may be in my future.
> Cool :-)

There are at several different sub systems, and as I understood
mod_cluster it already carefully separates them:

1) Dynamic topology detection (optional)

What are our backend nodes? If you do not want to statically configure
them, you need some mechanism based on either

- registration: backend nodes register at one or multiple topology
management nodes; the addresses of those are either configured, or they
announce themselves on the network via broad- or multicast).

- detection: topology manager receives broad- or multicast packets of
the backend nodes. They do not need to know the topology manager, only
the multicast address

More enhanced would be to already learn the forwarding rules (e.g. URLs
to map) from the backend nodes.

In the simpler case, the topology would be configured statically.

2) Dynamic state detection

a) Livelyness
b) Load numbers

Both could be either polled by (maybe scalability issues) or pushed to a
state manager. Push could be done by tcp (the address could be sent to
the backend, once it was detected in 1) or defined statically). Maybe
one would use both ways, e.g. push for active state changes, like when
an admin stops a node, poll for state manager driven things. Not sure.

3) Balancing

Would be done based on the data collected by the state manager.

It's not clear at all, whether those three should be glued together
tightly, or kept in different pieces. I had the impression the general
direction is more about separating them and to allow multiple
experiments, like mod_cluster and mod_heartbeat.

The interaction would be done via some common data container, e.g.
slotmem or in a distributed (multiple Apaches) situation memcache or

Does this make sense?



View raw message