LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Persistence and source port of connections

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Persistence and source port of connections
From: DoronR <DoronR@xxxxxxxxxx>
Date: Thu, 22 Jan 2004 13:13:54 +0000
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 RouteMy 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. 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.

Thanx,

Doron.   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. 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.

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>