|
So he may not be receiving your reply.
Ulrich if you want source nat on your LVS box, you'll have to do:
1) Create a loadbalancer:
ipvsadm -A -t 192.168.200.100:443
# add real servers
2) Create the source nat rule for this loadbalancer:
iptables -t nat -A POSTROUTING -m ipvs --vaddr 192.168.200.100/32
--vport 443 -j MASQUERADE
3) Set sysctl setting to allow conntrack on vs
sysctl net.ipv4.vs.conntrack=1
So it seems what you want is possible and not difficult at all...
Regards,
Tom
On 10/17/2013 02:51 PM, Graeme Fowler wrote:
> Hi
>
> On 17 Oct 2013, at 07:48, "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
> wrote:
>> I'm not subscribed to the list, so I hope someone will receive it anyway:
> Yes we did, but if people reply to the list then you won't see it unless
> you're watching an archiver somewhere...
>
>> I could pretty well use LVS for a load-balance, high-availability scenario
>> like distributing SMTP requests to different servers, but the setup seems so
>> complicated that I won't do. Reading the documentation, I felt that the NAT
>> (masq) mechanism would be the most elegant for my requirements. However as
>> it tuned out it did not work (as for many others). The reason is simple: LVS
>> rewrites the destination TSAP (IP address and port), but it leaves the
>> source TSAP unchanged. So any replies from a real server go to the original
>> sender, instead of the LVS host
> That's right. In NAT mode, the realservers don't talk directly to anything
> but the director.
>
>> The proposed solution is to set the LVS host as default gateway on any real
>> server. This has several problems:
>> 1) You create a SPoF on the LVS host
>> 2) You create a network bottleneck on the LVS host (_all_ traffic from a
>> real goes to the LVS host which must be a router)
>> 3) If LVS host and real server are not in the same subnet, you cannot route
>> from the real server to the LVS directly
>> 4) You cannot have two different LVS hosts that use different services on
>> the same real host
> That's NAT mode for you.
>
>> I reall wonder why you don't rewrite the source TSAP (in addition to the
>> destination TSAP) as well so that the sender of the packet seems to be the
>> LVS host. On a second rewrite the LVS destination TSAP would be rewritten to
>> the original requester. I feel this would work like a charm:
>> 1) The real server will reply to the LVS host automatically
>> 2) Only LVS traffic needs to go through LVS host
>> 3) LVS host does not need to be a router (after rewriting the destination, I
>> think)
>> 4) LVS host and real server can be in different subnets
>> 5) You can use one real server from different LVS hosts
>>
>> Did I overlook something that makes this impossible or impractical?
> Yes. You've sort of described both DR and TUN modes here, except for the
> source IP being rewritten. LVS/IPVS is *not a proxy*, it's a fancy router. If
> you want to do this with source rewriting, use a system such as haproxy.
>
> NAT mode is most useful where the realservers don't require any special
> configuration apart from their default gateway.
>
> DR and TUN modes require extra configuration on the realservers, but do away
> with the SPOF and bottleneck in the director.
>
> Graeme
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
