LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

RE: Persistence and source port of connections

To: "LinuxVirtualServer.org usersmailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: Persistence and source port of connections
From: "Doron Rabia" <DoronR@xxxxxxxxxx>
Date: Sun, 25 Jan 2004 10:23:28 +0200
> My problem is somewhat similar, but wierd :
>
> I use ldirector master/backuop on the real server with wlc ,and direct
> route :
>
> IP Virtual Server version 1.0.6 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
>   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
> UDP  10.17.33.101:5101 wlc persistent 300
> TCP  10.17.33.101:5101 wlc persistent 300
>   -> 10.17.33.51:5101             Local   1      0          0
>   -> 10.17.33.99:5101             Route   1      0          0
> TCP  10.17.33.101:8080 wlc persistent 300
>   -> 10.17.33.51:8080             Local   1      0          0
>   -> 10.17.33.99:8080             Route   1      0          0
>
> My problem is that the application that listens to the talarian-tcp port
> (5101) also registeres the destination socket. It always expectes to
> talk to the same socket.
> What happenes is, that after TCP connection time out , when the client
> is accessing the cluster port , if the connection was on the backup
> ldirector server (which is also a real server) ,then lvs will create a
> new connection , meaning a new socket (port changes). That causes the
> application to hang , because it knows about the expired connection's
> port and not the new one.

Are you talking about the expired connection that was originally created on
the primary Director?


>This would have seen normal behaviour to me,
> except for the fact that on the master ldirector node  the behaviour is
> different : The connection stays alive although TCP timeouts have passed
> and the cluster no longer sees the connection. When the client sends
> data over the 'dead' connection, it comes alive on lvs with the same
> port as before (after all, the server still keeps the connection and lvs
> is using that).
> My question is : is there a way to make the backup ldirector/real server
> act the same as the master ldirector/real server  so that the
> application will not hang due to socket changes afer timeout ?
> Increasing TCP timeout to a large value (i.e : ipvsadm --set 43200 0 0)
> could be prioblematic solution, as I need very long timeouts.
>

At failover time the open sockets on the backup Director may survive when
the backup Director aquires the VIP (of course the localnode connections to
the primary Directory are dropped anyway), but that's not going to happen at
failback time automatically. You may be able to rig something up with
ipvsadm using the --start-daemon master/backup but it is not supported
"out-of-the-box" with Heartbeat+ldirectord. (I think this might be easier on
the 2.6 kernel btw). Perhaps what you want to acheive is only possible with
dedicated Directors not using LocalNode mode.

--Karl



I may have not explained myself correctly and I'm sorry for that :
The issue is not with ldirectors failover, but rather different behavior of
connections on real server that ldirector master is running on, and the real 
server that does not run ldirector (or is being ldirector stand by).
On the real server that also has ldirector running, the connections are kept
alive although TCP timeout has passed, which is good for my application which 
looks the specific socket (ipvsadm -Lc does not show them though only lsof -i). 
On the other server, that does not run ldirector (or ldirector is in stand by 
mode), the application on the client side hangs after TCP timeout ,because the 
ldirector will create a new connection (new socket) for the request that comes 
from the client.
I'm using ldirectors with master and backup daemons up , but it has no affect 
of the behavior I have described.
My question is  : Is there away to replicate the (although strange) behavior of 
'supposed to be dead but are alive' connections on the other real server as 
well?

Thanx,

Doron.
-------------------------------------------------------------------------------------

The information contained in this message is proprietary of Amdocs,

protected from disclosure, and may be privileged.

The information is intended to be conveyed only to the designated recipient(s)

of the message. If the reader of this message is not the intended recipient,

you are hereby notified that any dissemination, use, distribution or copying of 

this communication is strictly prohibited and may be unlawful. 

If you have received this communication in error, please notify us immediately

by replying to the message and deleting it from your computer.

Thank you.


-------------------------------------------------------------------------------------
<Prev in Thread] Current Thread [Next in Thread>