Re: [squid-users] ICP and sibling peers in reverse proxies?

Christian Tzolov wrote:
> Hi Amos,
>
> Thanks for your immediate response,
>
>> Yes. you can set the peers as siblings and configure the proxy-only
>> option.
>
> I did that but now I face another problem. How can I make both squid
> nodes use the same hostname for their cached object's Keys?
>
> For example the same response returned by Apache_1 and cached on Squid_1
> will have a Key like: http://Squid_1/resource?id=1 while on Squid_2 the
> same response will be identified as: http://Squid_2/resource?id=1
>

WTF? properly configured and current Squid uses the hostname the client
requested. If the objects are publicly living at different URI they are
different objects.

> If the same response is cached with different Keys on each Squid node I
> am worried that the ICP will be useless. It will fail to match the
> request to the resource on the remote Squid sibling?
> If the above assumption is true how can we configure/force Squid to use
> URL that is unique amongst all siblings?

You have a public FQDN domain name (or several) which all objects live
inside. These are served by the apache, just as if the apache are
directly in contact with the clients.

Squid are configured such that any requests for those specific FQDN are
routed at the internal apache.

DNS is configured such that external clients requesting the FQDN are
told the public IP of squid (or of the LB passing things straight to squid).

Config examples are here:
   http://wiki.squid-cache.org/SquidFaq/ReverseProxy

>
>> It may not be the optimal setup though.
>
> Please elaborate on this? Any other ideas are welcomed!

I'm not too clued up on the details myself to have a good answer. Its
likely someone can provide a better method than straight ICP.

What I do know is that ICP increases the bandwidth flow between the
squids, and in your design case the data flow to prevent duplication at
each squid increases that even further.

Theoretical Worst case with that exact config;
   one squid ends up with all the data cached, and the other just pulls
every request through it. Effectively making the initial load-balancing
redundant.

My choice would be to keep the redundant caches, and parent each squid
off BOTH apaches. For redundant data source if their apache died.
I'm pretty sure you didn't state all your requirement specs or limits
though in the earlier request so the decision is still up to you.

Amos

>
> Thank you,
> Christian
>
>> -----Original Message-----
>> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
>> Sent: Thursday, October 02, 2008 3:58 AM
>> To: Christian Tzolov
>> Cc: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] ICP and sibling peers in reverse proxies?
>>
>>> Dear all,
>>>
>>> If we conceder the following deployment diagram:
>>>
>>> INTERNET
>>> |
>>> +--------------+
>>> |Load Balancer |
>>> +--------------+
>>> | |
>>> +-------+ +-------+
>>> |Squid_1| |Squid_2|
>>> +-------+ +-------+
>>> | |
>>> +--------+ +--------+
>>> |Apache_1| |Apache_2|
>>> +--------+ +--------+
>>>
>>> There the squid servers are configured as reverse proxies in front
> of
>>> the apache backend (original/parent) servers.
>>>
>>> The apache servers are identical. That means that the same HTTP/Get
>>> request performed on either of them will always produce the same
>>> response. As a result the all responses will be cached twice. Once
> on
>>> squid_1 and again on squid_2.
>>>
>>> Is it possible to avoid the redundancy explained above with the help
> of
>>> the ICP protocol and configuring both squid servers as sibling
> peers?
>> Yes. you can set the peers as siblings and configure the proxy-only
>> option.
>> It may not be the optimal setup though.
>>
>> Amos
>

-- 
Please use Squid 2.7.STABLE4 or 3.0.STABLE9