httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: load balancer "cluster" set
Date Mon, 31 Jul 2006 18:10:17 GMT
Jim Jagielski wrote:
> I'm trying to figure out which impl of the the
> LB cluster set makes the most sense and would appreciate
> the feedback.
> Basically, I see 2 different methods:
>    1. Members in all cluster sets which have the same or
>       lower set numbers are checked
>    2. Only members is a specific set number are checked. If
>       none are usable, skip to the next cluster set.

We have two different use cases for grouping. On is the case, where the 
targets keep some state and replicate the state only to some of the 
other targets. If the set of targets is split into disjoint replication 
groups, it would make sense to use any other member of the same 
replication group, in case the sticky member is dead. This situation 
might be used e.g. for a tomcat cluster, where we only can do one to all 
replication. So a huge cluster needs to be split into disjoint 
replication groups. So for a sticky situation and a request that 
contains a target ID, I think 2 makes the most sense.

In case the backends use a more elaborate replication scheme, 
mod_proxy_balancer would need some additional way of getting the 
information about replication members, like encoding them into the 
Cookie. Unfoirtunately, theres no standard for this.

If we are in a non-sticky session, or the request has no target ID, we 
are back to pure load-balancing (no routing). In this case I think there 
should be a way of expressing preferences for target workers. That's 
closer to number 1.

For mod_jk 1.2.18 we included "distance" as a measurement of preference 
for the non-sticky case (and the case, where we are sticky, but the 
wohle cluster set is down), and we have domain since about 2 years to 
configure replication sets.

I assume his is, what Mladen is after. So my answer would be: some of 1. 
and some of 2, depending on the request info and the target status.

I would love, if someone came up with a more consistent model.


View raw message