Re: Redirection and Load Balancing

On Thu, 6 Aug 1998, John Cougar wrote:

> Date: Thu, 6 Aug 1998 19:26:24 +1000 (EST)
> From: John Cougar <cougar@telstra.net>
> To: Stephen Ollis <ollis@att.net.au>
> Cc: squid-users@ircache.net
> Subject: Re: Redirection and Load Balancing
> Resent-Date: Thu, 6 Aug 1998 02:27:50 -0700 (PDT)
> Resent-From: squid-users@ircache.net
>
> On Tue, 30 Jun 1998, Stephen Ollis wrote:
>
> > I'm just curious: what does everyone else use for Redirection
> > and Load Balancing on a farm of proxy servers?
> >
> > I've been looking at the Alteon AceSwitch, which has been getting
> > good reviews from around the place.. are there any other contenders?
>
> I don't recall a big response for this issue from the list, but here's my
> 2c worth.
>
> The Alteon switch is designed to do clustering of like-minded servers in a
> redundant and load balanced fashion, and it does this well by acting as a
> proxy device (ie: you configure it with a proxy IP address and setup a
> load balanced cluster of servers hanging from it).
>
> I've played around with a few different configurations with it, but
> haven't yet successfully got it to act as a single point Squid proxy.
> What I mean is: it'll load balance TCP/HTTP sessions across multiple
> servers fine, but I couldn't get it to forward ICP reliably, since the
> proxy ports must be configured along with the proxy IP address.
>
> I tried to solve this issue by configuring a proxy-UDP port to handle ICP
> transactions, thinking that the ICP packet would get routed into the
> back-end cluster to one of the hosts, who would then ask the other hosts
> if they had the object (if that particular host didn't - I hope you get
> the picture), but, when the proxy-ICP port was configured, the Squid hosts
> couldn't get ICP transactions to one-another. There are a number of ways
> around this (that I've thought of) but I haven't got it going yet (viz:
> it's not that simple!).
 
If each proxy had dual nic's then it should solve your problem.
The clients talk to the proxies through the external NIC group via the
alteon switch and the proxies talk to each other through the internal NIC
group via a different switch/hub.

> I've discussed this problem with the Alteon dudes, and they acknowledge
> that there _is_ a problem and I don't know if they plan to do anything
> about it (yet).
>
> This is not to say that the switch won't work with Squid ... it will, and
> I believe that the layer-4 feature set (which is expanding at a phenomenal
> rate) now includes URL hashing so that if you have multiple cache hosts
> hanging of the back end, then the switch will will route URLs to
> particular hosts, thereby increasing the hit rate (and decreasing the
> load-balancing? was my question, to which I did not get a satisfactory
> answer).
>
> Just don't expect to be able to use ICP ... yet.
 
By introducing an alteon switch you are essentially trying to scale squid.
Well, ICP doesnt scale well, so maybe its not going to be a problem for you
after all given the introduction of cache digests in 1.2.

> You should also be warned that although the load balancing features appear
> to be a great benefit (as indeed they are when all is well), you are
> introducing a single point of failure for a cluster multiple devices.
>
> Sigh ... back to DNS round-robin! :-))
 
It's very difficult and expensive to eliminate all single points of failure
in a clustered solution.
The only cost effective method I know of is to implement the balancing in the
client. In this case the browser.
You could certainly do it in the network, but its going to be an expensive
solution if you want to cover all bases.

Given that the alteon switch does not eliminate all single points of failure,
I wonder whether a PC running Unix that balances packets between systems behind
it would be a cheaper alternative. (i.e. Similar to cisco's local director,
but not so pricey).

-- 
Regards
Peter Marelas