On 18 Aug 2011, at 15:35, "Sam Skipsey" <[log in to unmask]> wrote:
......
>
> I think that we'd be happy with 2 squids in a load-balanced
> configuration here, not least because the network distance for CVMFS
> -> another squid is going to be about the same as that to RAL... that
> said, there's something to be said for multiple levels of resiliency.
Just bear in mind that you don't really need to configure the squids to know about each other, the CVMFS client knows how to failover - both between squid caches and between replicas - and is better at managing it than round robin at least.
But having a pair locally is definitely a good idea, or you risk vastly increasing your network traffic, and more important slowing your jobs down. Thee is no significant risk of overloading the replicas.
Ian
>
> Sam
>
> On 18 August 2011 15:25, Ewan MacMahon <[log in to unmask]> wrote:
>> Hi all,
>>
>> I've just had an interesting lesson in what happens to cvmfs
>> when its one and only squid server dies underneath it, and
>> now I'm thinking about getting some redundancy into the
>> system.
>>
>> cvmfs itself supports multiple squidd, so it's just a matter
>> of having multiple squid servers available. The Tier 1 has
>> a couple, but for everyone else I was wondering whether it
>> would make sense to handle this in a similar manner to how
>> we deal with the Frontier squids and have cross-site failover?
>>
>> As far as I can see we could:
>> - use the same basic idea,
>> - use the exact same relationships, so everyone fails over
>> their cvmfs squid to the same place they fail over their
>> Frontier squid (which makes sense because in a lot of
>> cases they're the same squid),
>> - have everyone fail over to the Tier 1,
>> - something else,
>> - nothing at all, and just leave it to each site to run
>> a pair of squids.
>>
>> I think I'd favour either the second or third options, but
>> I'd be interested to know what everyone thinks, and indeed
>> how everyone else with deployed cvmfs is handling this now.
>>
>> Ewan
>>
|