On Fri, 18 Mar 2011, Edouard Zorrilla wrote:

My scenario is to use two Squids working as forwarding proxy : SquidA and SquidB. If SquidA fails users should be switched to the SquidB.

this is very similar to what I have.

What I do is to run two systems with squid on each system. I have the vis-hostname set the same for both of them, and that name resolves to a VIP that moves between the two systems if one fails. I use heartbeat (http://linux-ha.org) to manage the VIP and detect that a system has failed.

by having squid running all the time on both boxes, the failover is very fast.

however, by having squid running on each system, anything that happens on one system is not known by the other system, so if you do authentication or anything like that, when a failover happens users will need to re-authenticate. Also, the cache will be empty and have to be rebuilt.

David Lang

If I decide to go with PAC files the workstation is the one that decide where to go. My concern is, where should I store the PAC file so that It can also be redundant let say saved in two places ?

Thanks.!.

-----Original Message----- From: Jakob Curdes
Sent: Friday, March 18, 2011 9:49 AM
To: squid-users@squid-cache.org
Subject: Re: [squid-users] Squid in HA.


Hey Guys,

Could you confirm what would be the scenario for Squid working in HA ?.,
That depends on your setup ... we have squid running in a resource group
with winbind (for authorization against AD), the respective internal
gateway IP, and pingd resources that monitor external access and DNS
resolution. If one of these resources fails to run or the internet/DNS
is not reachable, the whole group will migrate to the second server.
Setups are identical otherwise, we synchronize configuration files of
squid etc via separate methodds (rsync via ssh), so we do not need to
use a distributed filesystem for this. This is a version 1 heartbeat
setup; we are currently experimenting with pacemaker and corosync but
are still struggling to put everything together on a CentOS 5.5 box.

HTH,
Jakob Curdes



Reply via email to