Re: AW: AW: [squid-users] detecting dead parent problem - understanding parent and icp

Hey Markus,

Why is a very hard question while not folding all the cards in-front of me.
I will not tell you what have changed from 2.7 to 3.2 since almost
everybody knows that 2.7=c 3.2=c\c++ and some other stuff.
But I can understand your problem and I can offer you couple things.
First use my helper just to improve the current situation.
What you are describing is one of the couple regressions involved while
upgrading the whole internet...
There is constantly one part of the internet that is down and we cannot
change it since it's such a wide network.
So first to try to overcome the problem we need to provide with a
mechanism that does that check for you.
If my script is not enough to make an environment stable for production
I suspect the problem is deeper(from my point of view).
If you are up for the task to develop this point in squid code and kind
of port or redesign the way squid recognize a cache_peer down state it
would be wonderful for many admins.

If you do want more help We can try to see your conf and try to make it
possible for your network to become more stable.

Just one point: is this PC access the proxy as a forward proxy or the
proxy intercepts the requests?

Eliezer

On 07/03/2013 03:01 PM, Rietzler, Markus (RZF, SG 324 /
<RIETZLER_SOFTWARE>) wrote:
> we have setup a squid hierarchy in our environment.
>
> all PCs are talking to a local proxy_user in their location (up to 150 locaitons).
> those proxy_user will have setup parent-proxies. with different acl we define wether it is an intranet or an internet access and will forward the request to proxy_inter or proxy_intra.
>
> so:
>
> PC -> proxy_user [some ACL]-> proxy_inter -> proxy_dmz -> {internet}
> -> proxy_intra
>
> in fact we have at the moment 4 separate servers working as proxy_inter and proxy_intra. so it really means
>
>
> PC -> proxy_user [some ACL]-> proxy_inter1
> -> proxy_inter2
> -> proxy_inter3
> -> proxy_inter4
>
> we do this as HA and fallback. so in the past we could just shut down proxy_inter1 and proxy_inter2 without any problem. ok, the load on the remaining proxies (inter2, inter3) will increase but this can be handled and the user won't suffer (much/at all) from missing one of the four parents. proxy_user will detect the dead parent and will switch to the remaining parents. if proxy_inter1 comes back it will used again. so we have a very robust setup. where we can shutdown server1 or stop squid (proxy_inter1) on server1.
>
> this all worked very well with squid 2.7. we have upgraded to squid 3.2 and with the same setup we had one big problem. I have to add, that the proxie_user now runs in smp-mode with 2 workers defined. if all proxies are up everything is ok. surfing the internet is fast and reliable. but after a electricity failure only two of our four central servers came up. so we only had proxy_inter1 and proxy_inter3 running, inter2 and inter4 were dead. now the problem was, that the load on inter1 and inter3 was absolutely ok, no problem. load on proxy_user seems also ok, but you could not surf very well, all requests were sloooooow and some of the failed completely.
>
> so just going from squid 2.7 to 3.2 had changed the behavior with dead parents.
>
> I am looking for a reason, why 3.2 will behave so bad in this case.
>
>
>> >I would imaging you have a PC and on it 4 proxies as cache_peers and you
>> >would like to not have an option for a connection to be down??
>> >If do and it's on a PC then what version of squid are you using?
>> >ICP is not to detect if the proxy is up but to*know* if the proxy has
>> >the specific cache object in case it's on one of the 4 the request would
>> >pass thorough it.
>> >there is another option that existed on squid 2.X that checks if the
>> >cache_peer is up.
>> >I built a helper that can help you detect if there is a problem in on of
>> >the cache_peers to minimize the downtime to very very low.
>> >https://github.com/elico/squid-
>> >helpers/tree/master/squid_helpers/proxy_hb_check
>> >
>> >the above link contains the helpers which are very simple but are not
>> >optimized for very high-load.
>> >You can optimize the usage of a similar helper when used with squid
>> >internal ttl for 2 secs and use the src IP instead of the url which is
>> >changing all the time.
>> >
>> >If you have more questions feel free to continue this thread.
>> >If you have an idea on how to integrate the feature into squid many will
>> >be happy.
>> >
>> >Best Regards,
>> >Eliezer
>> >
> hi eliezer,
>
>
Received on Wed Jul 03 2013 - 22:04:24 MDT