> On 23 May 2017, at 09:16, Jim Riggs <apache-li...@riggs.me> wrote: > >> On 18 May 2017, at 13:22, Rainer Jung <rainer.j...@kippdata.de> wrote: >> >> Am 18.05.2017 um 19:46 schrieb Jim Jagielski: >>> Based on feedback from various sessions: >>> >>> o A new-kind of "hot standby" in mod_proxy which kicks >>> in whenever a worker moves out of the pool (ie, doesn't >>> wait until all workers are out)... ala a redundant >>> hard drive. >> >> Maybe "spare worker" (and we could have more than one such spares). > > Exactly. I am already working on some code for this, though it to seems to > necessarily be a bit convoluted in the current codebase. > > The way we treat a "hot standby" in mod_proxy_balancer is as a last-ditch > effort to return something. I.e. *all* workers are unavailable, so then we > use the hot standby. (This problem can actually be solved a different way by > setting a high value for lbset.) > > In my mind, though, what is proposed here is actually how I actually expect a > "hot standby" to work. Think of it more like a "hot spare" in disk RAID > terms. That is, if *any* worker is unavailable, the hot spare will be used > (or at least added to the list of potential workers...still to be determined > by the lbmethod implementation). > > Example: > > <Proxy "balancer://mycluster"> > BalancerMember "http://192.168.1.50:80"; > BalancerMember "http://192.168.1.51:80"; > BalancerMember "http://192.168.1.52:80"; > BalancerMember "http://192.168.1.53:80"; status=+H > </Proxy> > > In this case, .53 will only get used if .50, .51, and .52 are *all* > unavailable. > > <Proxy "balancer://mycluster"> > BalancerMember "http://192.168.1.50:80"; > BalancerMember "http://192.168.1.51:80"; > BalancerMember "http://192.168.1.52:80"; > BalancerMember "http://192.168.1.53:80"; status=+R # new "hot spare" status > BalancerMember "http://192.168.1.54:80"; status=+R # new "hot spare" status > </Proxy> > > In this case, if .50 becomes unavailable, .53 (or .54 depending on > implementation) will be treated as an available worker for the lbmethod to > potentially choose. If 2 or more of .50, .51, and .52 become unavailable, > both .53 and .54 would be available to be chosen. > > So, instead of having a single fallback option when *all* workers are dead, > we will have a way of trying to ensure that a specific number of workers (3 > in the example above) are always available...just like a hot spare drive > plugs into the RAID array when one of the members dies. In our case, though, > once the main worker recovers, the hot spare will go back to being a hot > spare (except for matching routes). > > Comments welcome.
As promised, balancer hot spare support: https://bz.apache.org/bugzilla/show_bug.cgi?id=61140
