httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: mod_proxy / mod_proxy_balancer
Date Wed, 06 May 2009 13:11:42 GMT
Rainer Jung wrote:
> 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
> similar.
> Does this make sense?

I've been working around #1 by using pre-designated port ranges for 
backends, e.g. configuring for balancing over a port range of 10 and 
only having a couple of servers running in this range at most given 
times.  That's fine as long as one quiets Apache's error logging so that 
it only complains about backends that are *newly* unreachable rather 
than complaining each time a backend is retried.  I supplied a patch for 
this some time back.

#2 and #3 are huge, however, and it would be good to see something firm 
rather than experimental in these areas sooner than later.

Jess Holle

View raw message