[squid-users] Centralized Squid - design and implementation

Kinkie gkinkie at gmail.com
Sun Nov 16 16:22:43 UTC 2014


On Sun, Nov 16, 2014 at 4:54 PM, alberto <alberto.furia at gmail.com> wrote:
> Hello everyone,
> first of all thanks to the community of squid for such a great job.

Hello Alberto,

[...]

> I have some questions that I would like to share with you:
>
> 1. I would like to leave the solution we are using now (wpad balancing). In
> a situation like the one I have described, centralized squid serving the
> spokes/branches, which is the best solution for clustering/HA? If one of the
> centralized nodes had to "die" I would like client machines not to remain
> "hanging" but to continue working on an active node without disruption. A
> hierarchy of proxy would be the solution?

If you want to maximize the efficiency of your balancing solution, you
probably want a slightly different approach: instead of using the
client-ip as hashing mechanism, you want to hash on the destination
host.
e.g. have a pac-file like (untested, and to be adjusted):

function FindProxyForURL(url, host) {
   var dest_ip = dnsResolve(host);
   var dest_hash= dest_ip.slice(-1) % 2;
   if (dest_hash)
     return "PROXY local_proxy1:port; PROXY local_proxy2:port; DIRECT";
   return "PROXY local_proxy2:port; PROXY local_proxy1:port; DIRECT"
}
This will balance by the final digit of the destination IP of the
service. The downside is that it requires DNS lookups by the clients,
and that if the primary local proxy fails, it takes a few seconds (up
to 30) for clients to give up and fail over to secondary.

local_proxies can then either go direct to the origin server (if
intranet) or use a balancing mechanism such as carp (see the
documentation for the cache_peer directive in squid) to maximize
efficiency, especially for Internet destinations.

The only single-point-of-failure at the HTTP level in this design is
the PACfile server, it'll be up to you to make that reliable.

> 2. Bearing in mind that all users will be AD authenticated, which url
> filtering/blacklist solution do you suggest?
> In the past I have worked a lot with squidguard and dansguardian but now
> they don't seem to be the state of the art anymore.
> I've been thinking about two different solutions:
>   2a. To use the native acl squid with the squidblacklist.org lists
> (http://www.squidblacklist.org/)
>   2b. To use urlfilterdb (http://www.urlfilterdb.com/products/overview.html)

I don't know, sorry.

> 3. Which GNU/Linux distro do you suggest me? I was thinking about Debian
> Jessie (just frozen) or CentOS7.

http://wiki.squid-cache.org/BestOsForSquid

-- 
    Francesco


More information about the squid-users mailing list