What Mark said. :) We have this exact same setup now. My only advice would be to make sure there is enough difference in your backend peer names in the config.
The spec for CARP is supposed to take into account that peer names might be similar, but we had to name our backend peers with enough uniqueness to get the distribution to be close to equal. For suggestions on peer names that might inject enough entropy into the hash distribution, we've found an excellent source to be: http://en.wikipedia.org/wiki/Category:The_Muppets_characters Good luck, john allspaw flickr operations ----- Original Message ---- > From: Mark Nottingham <[email protected]> > To: Chris Woodfield <[email protected]> > Cc: Squid Users <[email protected]> > Sent: Tuesday, March 17, 2009 10:11:09 AM > Subject: Re: [squid-users] CARP question > > > On 17/03/2009, at 7:44 AM, Chris Woodfield wrote: > > > Hi, > > > > Had a question about squid's CARP implementation. > > > > Let's say I have a farm of squids sitting behind an SLB, and behind those I > have a set of parent caches. If I were to enable CARP on the front-end > caches, > is the hash algorithm deterministic enough to result in a URL request seen by > more than one edge cache to be directed to the same parent cache? > > Yes (keeping in mind that they can move around if the set of servers > considered > 'up' changes, and of course different FE caches will have a different idea of > what set is 'up' at any particular point in time). > > > > Or will each front-end cache have its own hash assignments compared to the > others? > > > > Also, how does CARP handle parent server removals and/or additions (i.e. > > are > hash "buckets" reassigned gracefully or are they all redistributed)? Is this > behavior also deterministic between multiple front-end squids? > > It is deterministic, and the idea is to cause the least disruption. Search on > 'consistent hashing' for the math; it's the same technique used in Akamai, > Hadoop/BigTable, etc. > > Cheers, > > > -- > Mark Nottingham [email protected]
