|
Wensong Zhang wrote:
>
> Hi Rob,
>
> If you want to upgrade your virtual proxy server, I strongly suggest
> you try VS-Tunneling or VS-DRouting. Because they are really
> efficient to build a virtual proxy server.
Yup, I will be going the Direct Routing method, as that seems to be the
nicest way -- but, as it's been running for most of a year now with NAT,
I didn't wanna start fiddling with it - I just wanted to make it work.
Now I've got it working, I can take one machine out of the cluster and
set up a different sort of load balancing that way.
> > [Background. eth0 == 203.63.158.2, eth1 = 203.63.12.1]
> >
> > I can do this:
> >
> > [telnet 203.63.12.1 8082, connects, talks to squid. no probs.]
> >
> > ipvsadm -A 203.63.158.2:9999 -s wrr
> > ipvsadm -a 203.63.158.2:9999 -R 203.63.12.1:8082
> >
> > Looks good. Except, uh, it doesn't work. When I try to connect to
> > 203.63.158.2 9999 (both locally and remotely) I get a connection
> > refused.
> >
>
> Your command is to use VS-DR, because it is the default if you
> don't specify the dispatching technique.
Yup. I thought direct routing would be the best for a 'local' host?
> As for VS-NAT, you should add -m option (masquerading).
> By the way, the VS-NAT cannot direct the connection to
> the other port on its own interfaces, because the response
> packets cannot be rewritten back.
I'm using NAT on the other machines, but I thought direct routing would
be the way to do it for that machine.
> Please check the VS-NAT, VS-Tunneling and VS-DRouting pages
> on LVS project, which were updated several days ago.
I did have a look, but none of the pages say 'This doesn't work with a
local connection' so I assume they all did. So what should I be using
for the local connection?
--Rob
|
