Search squid archive

Re: Originserver load balancing and health checks in Squid reverse proxy mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux