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 == 22.214.171.124, eth1 = 126.96.36.199]
> > I can do this:
> > [telnet 188.8.131.52 8082, connects, talks to squid. no probs.]
> > ipvsadm -A 184.108.40.206:9999 -s wrr
> > ipvsadm -a 220.127.116.11:9999 -R 18.104.22.168:8082
> > Looks good. Except, uh, it doesn't work. When I try to connect to
> > 22.214.171.124 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?