Re: [squid-users] icap loadbalacing

From: Sean Austin C. Critica <sean.critica_at_gmail.com>
Date: Sat, 26 Jun 2010 14:38:12 +0800

On Sat, Jun 26, 2010 at 2:29 AM, guest01 <guest01_at_gmail.com> wrote:
> Hi guys,
>
> I am currently implementing a proxy solution with squid (3.1.4) as
> caching/authentication proxy and a mcafee webwasher as content filter.
> Besides some other issues, it seems to work. Unfortunately, we have
> way too much traffic, only one squid and one webwasher cannot handle
> that (we suppose, we don't have real performance values yet). That's
> why we have to use a loadbalancer which will distribute (round robin
> or whatever, we could even use DNS) the traffic to the squids. That's
> not an issue either, the bigger problem is, that I can specify only
> ONE icap server per squid, right?
> So I only see two possibilities:
> 1) use the same count of squids and webwasher with a 1:1 mapping from
> ONE squid to exactly ONE webwasher
> 2) use a loadbalancer in front of the webwashers and configure a VIP
> address to which the squid will talk to
>
> Number 1 is not really an option, because we are currently having more
> webwashers than squids.
> Number 2 is the preferred solution, but I am not sure if ICAP is
> really loadbalanceable? The are a couple of problems we might run
> into. The most important question, is it necessary that both request
> (respmod and reqmod) will be sent to the same ICAP server? If not,
> then everything should be ok with the loadbalancing. I am also not
> sure about downloads which will be checked by the icap server.
>
> Anyway, my final question, is ICAP loadbalanceable? Will there be
> problems (either with downloading files, ...) if requests will be
> submitted to different webwashers?
>
> Thanks, best regards
> John
>

The ICAP protocol in itself, like HTTP, is stateless. REQMOD and
RESPMOD requests generated by the same HTTP transaction are
considered two distinct ICAP transactions. If your ICAP server
complies with this, there should be no problem.

-- 
Sean
Received on Sat Jun 26 2010 - 06:38:16 MDT

This archive was generated by hypermail 2.2.0 : Sat Jun 26 2010 - 12:00:03 MDT