[squid-users] Originserver load balancing and health checks in Squid reverse proxy mode
Chris
ml+squidusers at kisswebdev.com
Tue Feb 9 15:17:15 UTC 2021
Oh, that lib won't help, sorry, forget about my pinger_program path
So do I have to recompile squid myself and than install the pinger as
described here:
https://wiki.squid-cache.org/SquidFaq/OperatingSquid#Using_ICMP_to_Measure_the_Network
?
On 09.02.21 16:03, Chris wrote:
> Hi,
>
> thank you Amos, this is bringing me into the right direction.
>
> Now I know what I'll have to debug: the pinger.
>
> Cache.log shows:
>
> 2021/02/09 14:49:27| pinger: Initialising ICMP pinger ...
> 2021/02/09 14:49:27| pinger: ICMP socket opened.
> 2021/02/09 14:49:27| pinger: ICMPv6 socket opened
> 2021/02/09 14:49:27| Pinger exiting.
>
> and that last line "pinger exiting" looks like a problem here.
>
> Squid is used as a package from ubuntu bionic, it's configured with
> "--enable-icmp" as stated by squid -v.
>
> Now I explicitly wrote a "pinger_enable on" and the pinger_program
> path (in this case: "/usr/lib/squid/pinger" ) into the squid.conf (as
> well as icmp_query on) and reconfigured but the cache.log still shows:
>
> "Pinger exiting"
>
> So I don't understand why the pinger is exiting. The pinger_program is
> owned by root and has 0755 execution rights. Normal ping commands do
> work and show the one originserver at ttl=53 and time=50 while the
> other is at ttl=56 and time=155 - so a RTT comparison for
> weighted-round-robin should work here.
>
> Any hints on how I can find out why the pinger is exiting? Right now
> I'm debuging with debug_options ALL,1 44,3 15,8 but don't see a reason
> why the pinger exits.
>
> The Originservers are defined by (with icp/htcp disabled):
>
> cache_peer [ipv4_address_srv1] parent [http_port] 0 no-digest
> no-netdb-exchange weighted-round-robin originserver name=srv1
> forceddomain=[domainname]
>
> cache_peer [ipv4_address_srv2] parent [http_port] 0 no-digest
> no-netdb-exchange weighted-round-robin originserver name=srv2
> forceddomain=[domainname]
>
>
> Thank you for your help,
>
> Chris
>
>
>
>
>
> On 09.02.21 04:23, Amos Jeffries wrote:
>> On 9/02/21 3:40 am, Chris wrote:
>>> Hi all,
>>>
>>> I'm trying to figure out the best way to use squid (version 3.5.27)
>>> in reverse proxy mode in regard to originserver health checks and
>>> load balancing.
>>>
>>> So far I had been using the round-robin originserver cache peer
>>> selection algorithm while using weight to favor originservers with
>>> closer proximity/lower latency.
>>>
>>
>> Ok.
>>
>>
>>> The problem: if one cache_peer is dead it takes ages for squid to
>>> choose the second originserver. It does look as if (e.g. if one
>>> originserver has a weight of 32, the other of 2) squid tries the
>>> dead server several times before accessing the other one.
>>>
>>
>> The DEAD check by default requires 10 failures in a row to trigger.
>> This is configurable with the connect-fail-limit=N option.
>>
>>
>>> Now instead of using round-robin plus weight it would be best to use
>>> weighted-round-robin. But as I understand it, this wouldn't work
>>> with originserver if (as it's normally the case) the originserver
>>> won't handle icp or htcp requests. Did I miss sth. here? Would
>>> background-ping work?
>>
>> Well, kind of.
>>
>> ICP/HTCP is just a protocol. Most origin servers do not support them,
>> but some do. Especially if the server is not a true origin but a
>> reverse-proxy.
>>
>>
>>>
>>> I tried weighted-round-robin and background-ping on originservers
>>> but got only an evenly distributed request handling even if ones
>>> originservers rtt would be less than half of the others. But then
>>> again, those originservers won't handle icp requests.
>>
>> RTT is retrieved from ICMP data primarily. Check your Squid is built
>> with --enable-icmp, the pinger helper is operational, and that ICMP
>> Echo traffic is working on all possible network routes between your
>> Squid and the peer server(s).
>>
>>
>>>
>>> So what's the best solution to a) choose the originserver with the
>>> lowest rtt and b) still have a fast switch if one of the
>>> originservers switches into dead state?
>>
>>
>> Check whether the RTT is actually being measured properly by Squid
>> (debug_options ALL,1 44,3 15,8). If the peers are fast enough
>> responding or close enough in the network RTT could come out as a 0
>> value or some N value equal for both peer. ie. neither being "closer".
>>
>>
>> Amos
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
More information about the squid-users
mailing list