RE: [squid-users] Parent Proxy's, Not Failing over when Primary Parent is Down.

> Thanks Amos, I was looking at the 3.0 page for cache_peer definition since
> I am running 3.0 STABLE14, so I never saw those monitor options. I am not
> running anything that requires the 3.0 branch so I could switch to 2.7 to
> solve this problem. I would like to know if there are plans to include
> these options under the 3.x branches in the future? As I would prefer my
> configuration doesn't depend on an option that will not be available in
> the foreseeable future.

Yes they are on the roadmap for porting. Just not in 3.0 or 3.1.

Amos

>
> Thanks,
> ���� Dean Weimer
> ���� Network Administrator
> ���� Orscheln Management Co
>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: Thursday, April 30, 2009 11:39 PM
> To: Dean Weimer
> Cc: crobertson_at_gci.net; squid-users_at_squid-cache.org
> Subject: Re: [squid-users] Parent Proxy's, Not Failing over when Primary
> Parent is Down.
>
> Dean Weimer wrote:
>> -----Original Message-----
>> From: crobertson_at_gci.net [mailto:crobertson_at_gci.net]
>> Sent: Thursday, April 30, 2009 2:13 PM
>> To: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] Parent Proxy's, Not Failing over when Primary
>> Parent is Down.
>>
>> Dean Weimer wrote:
>>> I have a current Parent child proxy configuration I have been testing,
>> its working with the exception of some sites not failing over to second
>> parent when primary parent goes down.
>>> In the test scenario I have 2 parent proxies, and one child proxy
>> server, the parents are each configured twice using an alias IP address.
>> This is done to load balance using round robin for the majority of web
>> traffic yet allow some sites that we have identified to not work
>> correctly with load balancing to go out a single parent proxy.
>>>
>>
>> Since Squid 2.6 there has been a parent selection method called
>> "sourcehash", which will keep a client-to-parent-proxy relationship
>> until the parent fails.
>>
>> I considered this, but was concerned that after a failed proxy server,
>> the majority of my load would be on one server, and not taking advantage
>> of both links when the problem is resolved.
>>
>>> The load balanced traffic works as expected, the dead parent is
>> identified and ignored until it comes back online. The traffic that
>> cannot be load balanced is all using HTTPS (not sure HTTPS has anything
>> to do with the problem or not), when I stop the parent proxy 10.50.20.7
>> (aka 10.52.20.7) the round-robin configuration is promptly marked as
>> dead. However a website that has already been connected to that is in
>> the NONBAL acl just returns the proxy error from the child giving a
>> connect to (10.52.20.7) parent failed connection denied.
>>
>> Hmmm... You might have to disable server_persistent_connections, or
>> lower the value of persistent_request_timeout to have a better response
>> rate to a parent failure with your current setup.
>>
>> Also considered this, but figured it would break some sites that are
>> working successfully with load balancing because they create a
>> persistent connection, and making the request timeout to low would
>> becoming annoying to the users. Also as the default is listed at 2
>> minutes, I noticed that even after as much as 5 minutes that the
>> connection would not fail over.
>>
>>> It will not mark the non load balanced parent dead, closing and
>> restarting the browser doesn't help. It will change the status to dead
>> however if I connect to another site in the NONBAL acl. Going back to
>> the first site, I can then connect, even though I have to log in again,
>> which is expected and why these sites cannot be load balanced.
>>> Does anyone have any ideas short of writing some sort of test script
>> that will cause the parent to be marked as dead, if it fails without any
>> user intervention.
>>> Here is the cache peer configuration from the child proxy. FYI, I
>> added the 5 sec timeout to see if it had any effect, and it didn't with
>> the exception of speeding up the detection of the dead load balanced
>> proxy.
>>> ## Define Parent Caches
>>> # Cache Peer Timeout
>>> peer_connect_timeout 5 seconds
>>> # Round Robin Caches
>>> cache_peer 10.50.20.7 parent 8080 8181 name=DSL2BAL round-robin
>>> cache_peer 10.50.20.6 parent 8080 8181 name=DSL1BAL round-robin
>>> # Non Load Balanced caches
>>> cache_peer 10.52.20.7 parent 8080 8181 name=DSL2
>>> cache_peer 10.52.20.6 parent 8080 8181 name=DSL1
>>>
>>> ## Define Parent Cache Access rules
>>> # Access Control Lists
>>> acl NONBAL dstdomain "/usr/local/squid/etc/nonbal.dns.list
>>> # Rules for the Control Lists
>>> cache_peer_access DSL2BAL allow !NONBAL
>>> cache_peer_access DSL1BAL allow !NONBAL
>>> cache_peer_access DSL2 allow NONBAL
>>> cache_peer_access DSL1 allow NONBAL
>>>
>>> Thanks,
>>> Dean Weimer
>>> Network Administrator
>>> Orscheln Management Co
>>
>> Chris
>>
>> I am currently doing some testing by creating access control lists for a
>> couple nonexistent sub domains on our own domain. This then just
>> accesses the error page from the parent proxy for nonexistent domain, so
>> it shouldn't put an unnecessary load on the internet links testing.
>> Then allowing each one through one of the non balanced parents. By
>> accessing that page with my browser it causes the parent to be marked
>> dead.
>>
>> I could look at writing a script to access these pages through the child
>> proxy every so many seconds to cause the parent to be marked as dead.
>> It's kind of a hacked solution, but hopefully it would keep the users
>> from having too much down time in the event that one proxy goes down.
>
> Since 2.6 there have also been a set of monitor* options to do this in
> various ways when ICP feedback is insufficient or not available.
>
>>
>> It would probably be preferable though to query ICP directly and then do
>> a reconfigure on the child squid to exclude that parent from its
>> configuration. If anyone can tell me where to find the information on
>> how to do an ICP query that would save me some time, and be greatly
>> appreciated, in the mean time I will start searching or worse yet if
>> that fails sniffing network traffic to write an application to mimic the
>> squid query.
>
> http://www.squid-cache.org/Versions/v2/2.7/cfgman/cache_peer.html
> http://www.squid-cache.org/Doc/config/icp_port/
> http://www.squid-cache.org/Doc/config/icp_access/
>
> You may find other useful info in there for questions you have not yet
> asked as well.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14
> Current Beta Squid 3.1.0.7
>
Received on Sat May 02 2009 - 04:48:15 MDT