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