- From: Roberto Peon <grmocg@gmail.com>
- Date: Tue, 10 Apr 2012 07:36:32 -0700
- To: Per Buer <perbu@varnish-software.com>
- Cc: Nicolas Mailhot <nicolas.mailhot@laposte.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNfEBZvxJY-g-C9ejXgUxTWwhn37EF3Hm9JwnGOeF-=UVw@mail.gmail.com>
On Apr 10, 2012 6:01 AM, "Per Buer" <perbu@varnish-software.com> wrote: > > Hi Nicolas, list, > > On Tue, Apr 10, 2012 at 12:36 PM, Nicolas Mailhot > <nicolas.mailhot@laposte.net> wrote: > > > > Le Mar 10 avril 2012 11:23, Per Buer a écrit : > >> Nicholas, list, > >> > >> On Tue, Apr 10, 2012 at 8:56 AM, Nicolas Mailhot > >> <nicolas.mailhot@laposte.net> wrote: > >>> > >>> > >>> > So, if the proxy farm fails to hash incoming requests on source IP or > >>> > target URL then this might happen. > >>> > >>> That breaks load balancing as soon as your network is big enough, with > >>> different parts that get active at different points of the day. > >> > >> Sorry if I seem to miss the point, but why would it break? Are you worried > >> that one point in the farm would get too hot? > > > > I'm worried first that the activity distribution changes over time (so a > > static table does not work), and second that any network-wide state (such as > > an hashtable) is a contention point and potential spof. > > The load balancers derrive the correct proxy from the URL through a > hash algorithm. > The only state would lie on the number of active proxies. Altering the > number of proxies > requires a bit of thinking and you might want to rehash at some point > which will of > course be painful. Sorry if I might state the obvious here but this is > really quite > stateless and there is no SPOF here and no contention point. We've > used this on quite > large scale with reverse proxies and it works like a charm. This isn't stateless, and claims that it is are in error. The state is external to the connection (as you have identified earlier). The fact that it is external doesn't make it any less important. You are right that there isn't a SPOF... there are N points of failure instead, any of which can cause problems. > > > Making an individual > > gateway smarter is simple (scaling the farms is just the matter of adding new > > boxes). Making balancing smart and robust when some gateways or even some > > physical processing sites can go down at any time is hard. The above statement is important! -=R > > > > That's why direct browser-to-proxy communication will always be preferred and > > more reliable than depending on a magical holistic hashtable balancer. > > Round-robin is dumb but robust and stateless. > > > >>> And anyway even if your solution was possible, you still get unhappy users > >>> that serial refresh because they're not seeing initial progress in their web > >>> clients > >> > >> If the loadbalancer was balancing on target URLs the request would end up at > >> the same proxy. The proxy should be smart enough to coalesce the request > >> into the ongoing one and this one could feed the user a couple of bytes so > >> at the client understands that there is some progress on the download as > >> some proxies have done for years. > > > > Can't do when inspecting for malware. (..) > > Sure. This has been done for years. It was an absolute necessity when dealing > with earlier versions of IE. Feeding it the first 10 bytes of > something was considered > safe enough and would keep the browser from timing out. So giving it > one byte every > 30 seconds or so would buy us 5 minutes. > > I think this is perfectly doable withing the current framework and without the > need to add further complexities to the protocol. > > -- > Per Buer >
Received on Tuesday, 10 April 2012 14:37:02 UTC