On Wed, Nov 25, 2009 at 03:39:36PM -0800, David Lutterkort wrote: > On Wed, 2009-11-25 at 13:16 -0800, Luke Kanies wrote: > > On Nov 25, 2009, at 12:38 PM, Markus Roberts wrote: > > > > > One possibility we're overlooking here (I'm not making any claims > > > apart from the fact that it's a distinct solution) is to bind a run > > > to a server on the initial exchange (e.g. do a redirect from the > > > generic "puppetmaster pool" URL to an equivalent but more specific > > > "the particular puppetmaster who's handling you for this run" URL). > > > Session based web services sometimes use this technique. > > > > > > I'm amenable but I've no idea how common/supportable this is. Is this > > often how load balancers work? I'd expect that if someone wants to > > throw up an F5 in front of their masters that the F5 would be the only > > route through to the masters, and I'd (somewhat naïvely) expect there > > not to be another route to the masters. > > Webapps usually get around that with 'sticky' loadbalancing - > essentially, the loadbalancer can be told to look for a cookie and/or > request parameter in the request and then makes sure that requests with > the same cookie value always get routed to the same server.
Actually most loadbalancers geared for high-performance use the sticky approach but do NOT parse anything in the request. The stickyness (stay with the same realserver in the pool) is implemented by looking at the ipaddress from the client doing the request and routing that to the same realserver in the pool on subsequent requests within a timeout. Request parsing is prohibitively expensive and avoided, anything that can be determined by staying within layer-3 tcp/ip is preferable from performance point of view. This is true for F5 loadbalancers I believe (depending on config), it is most certainly true for linux-ipvs based loadbalancing which we deploy. > In the Java world, that's what the infamous jsessionid request parameter > and cookie are for. Different kind of loadbalancing, more proxy-alike and probably handled by the applicationserver or a semi-initelligent http frontend (nginx/apache) Regards, Ramon van Alteren -- Hyves System Engineering Frederiksplein 42 | 1017 XN Amsterdam T + 31 (0)206242081 | F +31 (0)207508329 [email protected] | ramon71.hyves.nl | www.hyves.nl
pgpBy0Ws88slf.pgp
Description: PGP signature
