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. Rainer
