Re: [squid-users] Re: Can Squid Load Balancing be Dynamic/Conditional against SNMP Monitoring?

From: Amos Jeffries <>
Date: Tue, 16 Aug 2011 12:38:38 +1200

 On Mon, 15 Aug 2011 14:50:46 -0500, Billie Martin wrote:
> I meant to include the documentation that I had found on this:
> ... including:
> Pen:
> Linux Virtual Server:
> Keepalived:
> VRRPd:
> Pen looks promising - anyone use it? Does it work WITH Squid or as
> an
> alternative? I like that "It allows several servers to appear as
> one
> to the outside and automatically detects servers that are down and
> distributes clients among the available servers. This gives high
> availability and scalable performance. The load balancing algorithm
> keeps track of clients and will try to send them back to the server
> they visited the last time."
> On Mon, Aug 15, 2011 at 2:33 PM, Billie Martin wrote:
>> I understand how Squid can be configured as a Load Balancer rotating
>> round-robin among a set of web servers IP addresses:

 Yes, balance_on_multiple_ip is available. Though none of what you talk
 about below is related to it.

>> -

 NP: tcp_outgoing_address is the packet source address. Has nothing
 directly related to do with load balancing the destination. Although,
 you can do what you like with the packet after sending so load balancing
 could get involved via LVM etc if you like.

 Where balance_on_multiple_ip works round-robin on connection
 destination address, tcp_outgoing_address in the above config is doing
 the similar rotation to the connection source address.

>> -
>> The problem is that if one of those web servers is down (either
>> administratively or unplanned), Squid will continue to send traffic
>> to
>> it, right?

 With balance_on_multiple_ip that is a problem. One of several, which
 are why its disabled by default these days.

 When using the tcp_outgoing_address tricks, you are at the mercy of the
 NIC interface being up or down AND assigned that IP. There are a few
 cases where its actually needed, but tcp_outgoing_address should be
 avoided in the current Internet whenever possible.

 When using the cache_peer load balancing the peer is constantly
 monitored for both RTT and connection errors. Some of the balancing
 algorithms use RTT to shift traffic.
  Squid-3.1 or later provide connect-fail-limit= to tune the number of
 errors (older squid hard-coded to 10) before dropping the peer out of
 selection choices. When "DEAD" only an occasional HTTP connect attempt,
 ICMP ping, ICP ping, HTCP ping, or netdb request is made. If any of
 those background fetches succeeds its detected live again and traffic
  Squid- and later provide a configurable sized set of
 destination choices. Each is tried until one succeeds with fast

 Yes its possible to add an SNMP query ("ping") to this set of things
 monitoring cache_peer states. Patches welcome. Look in src/
 for the above mentioned "Ping" examples.

>  If SNMP is enabled on Squid (see below), can Squid monitor
>> the web servers over SNMP and dynamically allocate traffic based on
>> whether the servers are up or not?

 If by "the web servers" you mean cache_peer which trust and allow you
 to send SNMP then yes. If you mean any general server being contacted
 DIRECT (ie balance_on_multiple_ip) then no. IRcache or NLANR network
 reportedly got people complaining about "hacking" by the normal ICMP
 packets for testing and adjusting link speed (echo and pmtu discovery).
 I'd hate to guess what the uproar about SNMP probes would be.

>  If this is possible, how might it
>> be configured, and where might it be documented?
>> Is there a better way to do this?  Would it be better to manage the
>> dynamic process with Heartbeat and Linux HA (with
>>, even if there was only a
>> single Squid server and not a cluster?
>> I would greatly appreciate ANY discussion on this.  Advantages,
>> disadvantages, configurations, alternatives, etc.  Many thanks in
>> advance.

 Look to Squid cache_peer mechanisms for outbound traffic. Look to DNS
 and HA tools for inbound, Squid is not involved with those.

Received on Tue Aug 16 2011 - 00:38:42 MDT

This archive was generated by hypermail 2.2.0 : Tue Aug 16 2011 - 12:00:02 MDT