[squid-users] Originserver load balancing and health checks in Squid reverse proxy mode

[Amos Jeffries]

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