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 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? > It may not be the optimal setup though. Please elaborate on this? Any other ideas are welcomed! Thank you, Christian > -----Original Message----- > From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] > Sent: Thursday, October 02, 2008 3:58 AM > To: Christian Tzolov > Cc: squid-users@xxxxxxxxxxxxxxx > Subject: Re: 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
