hot standby in proxy added
I've folded in my impl of hot-standby for proxy workers... check out trunk. I'm sure there is tuning to be done, but it's a functional impl that minimizes the code touched.
Re: hot standby in proxy added
On 07/11/2006 10:41 PM, Jim Jagielski wrote: > I've folded in my impl of hot-standby for proxy workers... > check out trunk. I'm sure there is tuning to be done, but > it's a functional impl that minimizes the code touched. Just to be sure that I got the correct understanding of the hot-standby worker: The hot-standby worker is the last resort if the site would be otherwise dead. The hot-standby worker can be used e.g. to display a maintenance page or a simpler version of the site or if you can affort the full site from an environment that only consumes power during a healthy state of the site. This would be different from a disabled worker which would be elected if the session route matches, but which would not be elected by a balancer algorithm. This is the way it works in mod_jk, but currently does not work in mod_proxy_balancer. Once I get some spare cycles I would like to make this work and make the small changes needed for this. With this feature you can prefer "local" workers, but you can keep session stickyness for requests that do not origin from this "local" worker. Regards Rüdiger
Re: hot standby in proxy added
Ruediger Pluem wrote: > > > > On 07/11/2006 10:41 PM, Jim Jagielski wrote: > > I've folded in my impl of hot-standby for proxy workers... > > check out trunk. I'm sure there is tuning to be done, but > > it's a functional impl that minimizes the code touched. > > Just to be sure that I got the correct understanding of the hot-standby > worker: > > The hot-standby worker is the last resort if the site would be otherwise dead. > The hot-standby worker can be used e.g. to display a maintenance page or a > simpler > version of the site or if you can affort the full site from an environment > that > only consumes power during a healthy state of the site. > > This would be different from a disabled worker which would be elected if the > session > route matches, but which would not be elected by a balancer algorithm. This > is the > way it works in mod_jk, but currently does not work in mod_proxy_balancer. > Once I > get some spare cycles I would like to make this work and make the small > changes needed > for this. > With this feature you can prefer "local" workers, but you can keep session > stickyness > for requests that do not origin from this "local" worker. > This is actually coming :) My thoughts are how to make this better; overloading the concept of "disabled" workers to mean multiple things depending on different situations seems glocky to me. Stopped should mean stopped, disabled should mean disabled. I do like the distance attribute and am looking at the best way to impl something similar while still keeping things as abstracted out as possible. Almost a sort of "balancer set" would be nice, where, for example, you define a balancer set with some members as set #1, and they would "always" be chosen (and looked at for LB) and set #2 (and later) would only be considered if no one in set #1 is available. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: hot standby in proxy added
Jim Jagielski schrieb: > Ruediger Pluem wrote: >> >> On 07/11/2006 10:41 PM, Jim Jagielski wrote: >> The hot-standby worker is the last resort if the site would be otherwise >> dead. >> The hot-standby worker can be used e.g. to display a maintenance page or a >> simpler >> version of the site or if you can affort the full site from an environment >> that >> only consumes power during a healthy state of the site. >> ... > I do like the distance attribute and am looking at the best > way to impl something similar while still keeping things as > abstracted out as possible. Once you've got "distance", hot-standby is implied by hot-standby=maximum(distance). Although it would be necessary to explain this special (and important) case in documentation, after having "distance" there would be no need for an extra hot-spare impl. Rainer
Re: hot standby in proxy added
> -Ursprüngliche Nachricht- > Von: Jim Jagielski > Gesendet: Mittwoch, 12. Juli 2006 00:55 > An: dev@httpd.apache.org > Betreff: Re: hot standby in proxy added > > > > My thoughts are how to make this better; overloading the concept > of "disabled" workers to mean multiple things depending on > different situations seems glocky to me. Stopped should mean > stopped, disabled should mean disabled. But what should be the difference between stopped and disabled in this case? > > I do like the distance attribute and am looking at the best > way to impl something similar while still keeping things as > abstracted out as possible. Almost a sort of "balancer set" > would be nice, where, for example, you define a balancer > set with some members as set #1, and they would "always" be > chosen (and looked at for LB) and set #2 (and later) would only > be considered if no one in set #1 is available. ...or if no one matches the given route in #1? Regards Rüdiger
Re: hot standby in proxy added
Rainer Jung wrote: > > Jim Jagielski schrieb: > > Ruediger Pluem wrote: > >> > >> On 07/11/2006 10:41 PM, Jim Jagielski wrote: > >> The hot-standby worker is the last resort if the site would be otherwise > >> dead. > >> The hot-standby worker can be used e.g. to display a maintenance page or a > >> simpler > >> version of the site or if you can affort the full site from an environment > >> that > >> only consumes power during a healthy state of the site. > >> > > ... > > > I do like the distance attribute and am looking at the best > > way to impl something similar while still keeping things as > > abstracted out as possible. > > Once you've got "distance", hot-standby is implied by > hot-standby=maximum(distance). Although it would be necessary to explain > this special (and important) case in documentation, after having > "distance" there would be no need for an extra hot-spare impl. > Yes, and that's why it's confusing. I can also see cases where you would want a hot-standby available at the same distance as well (check to see if there's a hot standby first, before checking hosts at a greater "distance"). IMO, just because something is done one way in mod_jk doesn't mean that it makes sense to copy the exact naming, etc over to mod_proxy. People who do HTTP proxying and LB have one set of "expectations" which occasionally do not map to how mod_jk has done things. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: hot standby in proxy added
Jim Jagielski schrieb: > Yes, and that's why it's confusing. I can also see cases > where you would want a hot-standby available at the same > distance as well (check to see if there's a hot standby > first, before checking hosts at a greater "distance"). You are totally right, I missed that one. > > IMO, just because something is done one way in mod_jk doesn't > mean that it makes sense to copy the exact naming, etc over > to mod_proxy. People who do HTTP proxying and LB have one set > of "expectations" which occasionally do not map to how mod_jk > has done things. I didn't want to have it work exactly like mod_jk, I simply forgot about your above use case. I'm not totally happy with mod_jk, because it grew over a long time, whenever a special new use case appeared, but it lacks consistency of configurations options and how they interact.
Re: hot standby in proxy added
Rainer Jung wrote: > > I'm not totally happy with mod_jk, because it grew > over a long time, whenever a special new use case appeared, but it lacks > consistency of configurations options and how they interact. :) That's the nice thing about the proxy module is that we're able to start from "scratch" :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
