|
(tcp 1day, tcpfin 1day) cause even if connection is closed correctly the
users real server sesion can still be a running..
hmm, don't understand this. You're not talking about the client launching a
job and then disconnecting?
on the real server, the client is given a windows desktop and they can
have multiple applications running..
the following situations can happen to end the tcp exchange between client
and real server
a) logout of the real server, real server then closes all of their
applications, stops their desktop session from running and correctly does
a finack packet exchange ending the session.
(if the client reconnects they can be balanced(directed) to any real
server since they don't have a desktop+applications running on any real
server)
b) 'disconnect' (windows option) from the real server, the realserver puts
their session in a disconnected state. Their desktop and application are
still running. a finack packet exchange happens ending that tcp
connection. After 10 minutes the realserver auto-logs off any
'disconnected' sessions, shuts the applications down and kills the
desktop, this time can be adjusted.
(if the client reconnects in this 10 minute window, the director should
point them back at their disconnected session. the real server will then
give them their running desktop and applications back.
if the client reconnects after the 10 minute window, the director should
balance them as a new session since they no longer have a
desktop+applications running on any real server )
c)The client shuts down and/or closes inappropriately the real server sits
there, leaves the desktop and applications active. now here is were
weirdness happens.
In testing if the client computer is a linux box and is still accessible
the real server will close out the connection(broken connection tcp
handshake attempt? handled correctly?)
In testing if the client computer is any of windows xp workstations my
department maintains, is still accessible or becomes accessible later
(reboot, powered down and then back on later, etc) the real server will
close out the connection(broken connection tcp handshake attempt? handled
correctly?)
If the client computer is the weird 1/3 of my customers
home/office/whatever computer (ones with who knows what on them, or how
they are configured) the desktop+apps just sit there running on the real
server no closing of the connection happens.. (failer of some kind, wacko
config? I don't know I cant really reproduce it, maybe they have some weird
retarded personal router appliance at home???) real server kills off the
active (but idle) desktop+applications in 1 day (there is a active but idle
session autologout after x time setting on the real servers) these clients
are the troublesome ones cause if they login a few times they will wind up
with a active but idle desktop+application session on each real server
if the client computer (either testing or customers) does not turn back on
and/or has no network connectivity. the desktop+apps just sit their active
but idle tell they hit the 1 day auto logoff
d)If a client computer leaves their session active but idle (ie leaves
stuff running but goes home for the weekend) then their session is killed
by the 1 day auto logoff (this is the reason for setting a 1 day
auto-logoff, so a client can go away for a day but still have stuff
running if they choose to leave their session running on a work/home
computer)
*some of these issues would be addressed by l7 balancing but currently the
only commercial products that can do l7 balancing cost big $$$. their is a
'free' l7 balancing client (for terminal server traffic only). however it
requires you to use their proprietary client... which means I would not be
able to allow macs or linux boxes to connect and would have to train users
to use the proprietary client. (the majority of my customers just use
whats available on their computer already since they are 90% winders users
and have the winders client already installed per default)*
*my customers = faculty, staff, and students at the university I work for*
if yes, where is the approprate place to put that setting so if a reboot
(hopefully wont ever happen, unless a kernel change takes place)
this setting gets restored auto-magicly?
presumably you have ipvsadm run from an init script when you boot the
computer?
(this is a debian stable box)
ipvsadm is started from a linked init script in /etc/rc2.d
it loads its saved rules from /etc/ipvsadm.rules
so can I place --set x y z in /etc/ipvsadm.rules? this didn't seem
appropriate cause ipvsadm wont dump the change their when it rewrites that
file upon a shutdown.
should I edit the init script then or is their a more correct place?
thanks!!!!!
-joseph
_________________________________________________________________________
Info: Email:
Joseph T. Duncan duncan@xxxxxxxxxxxxx
109 Kidder Hall
Corvalis Or 97333
|
