Re: [squid-users] poor mans load balancing

On 8/02/2012 11:20 p.m., Carsten Ralle wrote:
>>> we run a special installation using three DSL lines in parallel using
>>> the following layout with two squid servers
>>> Is there a configuration (preferably without ICP) to transparently use
>>> all three lines in parallel for a connection (e.g. HTTP/FTP-download or
>>> data streaming) ?
>> http://wiki.squid-cache.org/Features/AclRandom
> Amos, thanks for pointing me to your feature.
>
> May be I got this wrong, but as far as I understand the feature, it
> "only" changes traffic from a cache to the upper next parent cache.

No. The feature is only an ACL which produces a random true/false
result. How you use itin the config determine what happens.

* use it on cache_peer_access and it is relevant to which peer gets used
(or not). Balancing load over different upstream peers

* use it on tcp_outgoing_address and it determines what IP address Squid
sends from. With appropriate OS routes that could mean Squid triggering
each TCP connection to take a different line randomly.

Both of these are useful in different ways to load balance traffic.

>
> What I was looking for is a "line sharing" the other way around
> (downstream traffic):
>
> client -> Cache1 -> line -> Cache2 -> Webserver (>Request)
> <- Cache1<- lines<- Cache2<------' (<Reply)
> ^
> |
> line sharing needed
>
> Did I get this right or is there a way to configure Cache2 to use
> separate lines for downstream traffic using your random ACLs ?

Individual IP packets can take paths like that because each one is
separately address with source and destination details.

HTTP does not work that way. The reply MUST come back on the same TCP
connection the requests went out on. Squid can vary the IP address it
uses, and trigger different routing for that whole connection
request/reply sequence. But that is as far as Squid can go.

The MTCP bonding stuff Andrew pointed you at works down at the TCP level
so all the Squid layer is aware of is a larger capacity single "line".
Far more efficient than anything Squid could do.

Amos
Received on Wed Feb 08 2012 - 11:13:55 MST