|
On Wed, 2004-06-23 at 10:02, Lars Marowsky-Bree wrote:
> 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...
The whole point is to take a remote host in a remote location that
cannot use one of the existing methods (LVS-NAR, LVS-DR, or LVS-TUN) due
to one of the following problems.
1: The realserver is remote and doesn't use a director as it's gateway
and hence won't work with LVS-NAT.
2: The realserver doesn't have an OS that works with LVS-TUN. i.e.
Netware.
3: The realserver doesn't work with LVS-DR. i.e. Netware.
4: You have an administrator that's unwilling to make changes to his
realserver to support LVS but your required to provide LVS failover.
Thanks,
Brett
|
