> 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@xxxxxxxxxxxxx] > Sent: Thursday, April 30, 2009 11:39 PM > To: Dean Weimer > Cc: crobertson@xxxxxxx; squid-users@xxxxxxxxxxxxxxx > Subject: Re: Parent Proxy's, Not Failing over when Primary > Parent is Down. > > Dean Weimer wrote: >> -----Original Message----- >> From: crobertson@xxxxxxx [mailto:crobertson@xxxxxxx] >> Sent: Thursday, April 30, 2009 2:13 PM >> To: squid-users@xxxxxxxxxxxxxxx >> Subject: Re: 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 >
