Strategies for splitting load across varnish instances? Andavoiding single-point-of-failure?

[Willy Tarreau]

Poul-Henning Kamp <phk at phk.freebsd.dk> wrote :
> >Let's get back to consistent hashing and it's use...
> >
> >Correct me if I am wrong, but doesn't this mean that adding a new
> >varnish instance implies a full rehash ?
> 
> Yes, that is pretty much guaranteed to be the cost with any
> stateless hashing.

No, not with the consistent hashing algorithm. This is a very
interesting technique. The hash is not as well distributed as
common hash algorithms, but each new server only takes one
small part of other server's job. If a server goes down, its
job is redistributed on other ones without the other ones'
jobs being redistributed.

Please read here for more info :

   http://www.spiteful.com/2008/03/17/programmers-toolbox-part-3-consistent-hashing/

This has been implemented in haproxy precisely for caches. You can
enable it in any backend by simply specifying "hash-type consistent".
Moreover, you get the benefit of the slowstart feature, which means
that a server may be progressively reintroduced into the farm during
a warm up period instead of taking a big hit at once when it's seen
up.

Someone asked about the advantages of hashing URLs for caches. It's
simple, it's just to optimise requests placement : send a request to
the cache that is the most likely to already have fetched the same
object and have it in cache. Do that while monitoring your network
bandwidth. I think you'll observe a reduction when switching from
anything to url_hash.

Hoping this helps,
Willy