RE: [squid-users] Alteon + squid

From: Chemolli Francesco (USI) <ChemolliF@dont-contact.us>
Date: Wed, 17 Jul 2002 10:24:58 +0200

> just a thought i've developed... when u are using the
> Alteon load balancer, how do u ensure that u don't
> have duplicate information across your cache
> servers.... do u do this by using Squid cache-peering
> feature... this is important, as u wouldn't want to
> have the same object on each cache server... as u
> maximise efficiency and hit rate...

I use cache-digests and ICP, which means that I _do_
have some duplicate content, it shouldn't be much though.

I think you're getting the problem from the wrong angle.
If you really want to do url-based load-balancing
(and I really think you shouldn't, it's not worth the effort),
I think you'd better do it at the client level.
Doing otherwise means IMO to go into big BIG hairy messes
when you account for NTLM auth and its damned
connection-orientedness.

You can for instance set up two (or three or four) services
on the virtual server on the alteon, on different ports.
Then set up a proxy.pac so that it goes preferably on
one of those (and the others as backup) depending
on the target host.

So for instance, supposing that you want to balance
.com vs. non-.com:

Define two a server-groups with your proxies pooled by target domain
and a virtual server, then 2 services on different ports
pointing to the two server-groups. DO NOT USE complex real-server
selection metrics. Use leastconns or bandwidth, and BY ALL MEANS
turn session affinity (persistent binding) ON.

Do a proxy.pac which is something like this:

function findProxyForUrl(host,url) {
        if (host.substring(whatever_args)==".com")
                return "PROXY VIP:3128; PROXY VIP:3129";
        return "PROXY VIP:3129; PROXY VIP:3128";
}

I'll leave fixing up the broken syntax as an exercise to the reader.

This said, I recommend NOT to do this. The duplicate content is
not much in my experience
(provided that you use cache-peer's proxy-only option),
and it's not really worth the split in processing power and resources.

-- 
	/kinkie 
Received on Wed Jul 17 2002 - 02:27:23 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:09:17 MST