|
On 2004-06-22T13:04:08,
Brett Simpson <simpsonb@xxxxxxxxxxxxxxxxxxxxxx> said:
> I have been doing some research into several application switch
> technologies and in the course of evaluating them I think I have a few
> ideas for LVS.
>
> For systems that are not local to LVS and do not have the capability of
> being tunneled then you might be able to do the following:
>
> Method one (DoubleNAT):
> Setup an Iptables NAT that will allow the LVS director to access the
> remote machine on a local hidden address. Then setup an LVS-NAT to the
> NAT'ed address. This would make it completely transparent to teh client
> although a performance hit for doing NAT twice would happen.
I'm wondering what this is supposed to gain in addition to LVS-NAT
alone? Which is already perfectly transparent to the client...
> Method two (Proxy based):
> Setup a Squid or some other type of reverse proxy back to the remote
> server on the LVS director. Then setup an LVS-NAT to the proxied
> address.
Again, what's this supposed to provide?
> Method three (NAT/DR):
> Setup an Iptables NAT that will allow the LVS realservers to access the
> remote machine by IP address. Setup LVS-DR for your realservers.
Again, I don't get it at all; what's new here? Of course LVS-NAT needs
to be accompanied with a iptables NAT if the realservers are also to be
allowed a direct connection to the clients...
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>
--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company \ -- Samuel Beckett
|
